Tôi vừa phải đưa một service markdown ra khỏi API của mình

Tôi vừa phải đưa một service markdown ra khỏi API của mình

Tin ngắn hàng ngày dành cho bạn
  • Từ lâu rồi suy nghĩ làm thế nào để tăng sự hiện diện thương hiệu, cũng như người dùng cho blog. Nghĩ đi nghĩ lại thì chỉ có cách chia sẻ lên mạng xã hội hoặc trông chờ họ tìm kiếm, cho đến khi...

    In cái áo này được cái tắc đường khỏi phải lăn tăn, càng đông càng vui vì hàng trăm con mắt nhìn thấy cơ mà 🤓

    (Có tác dụng thật nha 🤭)

    » Xem thêm
  • Một vòng của sự phát triển nhiều dự án khá là thú vị. Tóm tắt lại trong 3 bước: Thấy một cái gì đó phức tạp -> Làm cho nó đơn giản đi -> Thêm thắt tính năng cho đến khi nó phức tạp... -> Quay trở lại vòng lặp mới.

    Tại sao lại như vậy? Để mình lấy 2 ví dụ cho các bạn thấy.

    Markdown ra đời với mục tiêu tạo ra một định dạng văn bản thô "dễ viết, dễ đọc, dễ dàng chuyển thành một dạng gì đó như HTML". Vì thời đó chẳng ai đủ kiên nhẫn mà vừa ngồi viết vừa thêm định dạng cho văn bản hiển thị ở trên web như thế nào. Ấy vậy mà giờ đây người ta đang "nhồi nhét" hoặc tạo ra các biến thể dựa trên markdown để bổ sung thêm nhiều định dạng mới đến mức... chẳng nhớ nổi hết cú pháp.

    React cũng là một ví dụ. Từ thời PHP, việc khát khao tạo ra một cái gì đó tách biệt hẳn giao diện người dùng và phần xử lý logic chính của ứng dụng thành 2 phần riêng biệt cho dễ đọc, dễ viết. Kết quả là các thư viện UI/UX phát triển rất mạnh mẽ, mang lại khả năng tương tác với người dùng rất tốt, còn phần logic ứng dụng thì nằm ở một máy chủ riêng biệt. Bộ đôi Front-end, Back-end cũng từ đấy mà thịnh hành, không thể thiếu anh bồi bàn REST API. Ấy vậy mà giờ đây React trông cũng không khác biệt gì so với PHP là mấy, kéo theo là cả Vue, Svelte... lại cùng quy tất cả về một mối.

    Cơ mà không phải vòng lặp là xấu, ngược lại vòng lặp này mang tính tiến hoá nhiều hơn là "cải lùi". Nhiều khi lại tạo ra được cái hay hơi cái cũ thế là người ta lại dựa trên cái hay đó để tiếp tục lặp. Nói cách khác là chắc lọc tinh hoa từng tí một tí một á 😁

    » Xem thêm
  • Song song với các dự án chính thức thì thi thoảng mình vẫn thấy các dự án "bên lề" nhằm tối ưu hoặc cải tiến ngôn ngữ theo khía cạnh nào đó. Ví dụ nature-lang/nature là một dự án hướng tới cải tiến Go, mang lại một số thay đổi nhằm giúp cho việc sử dụng Go trở nên thân thiện hơn.

    Nhìn lại mới thấy hao hao JavaScript 😆

    » Xem thêm

Vấn đề

Hôm cuối tuần vừa rồi tôi ngồi lại nghiên cứu về các giải pháp tăng khả năng SEO cho 2coffee. Tôi nhận ra có một phương pháp mà tôi chưa áp dụng đó là CLS. Nói nôm na thì điểm CLS thể hiện mức độ thay đổi bố cục trang web. Một ví dụ đơn giản là người dùng đang xem trang web của bạn thì đột nhiên văn bản bị nhảy xuống nhường chỗ cho hình ảnh đang tải. Hành động này gây ra một số khó chịu với người dùng bởi vì việc thay đổi bố cục đột ngột như thế trong khi đọc gây ra một sự khó chịu, nếu thay vì văn bản mà là một nút bấm mà người dùng đang định bấm vào thì sao? Cảm giác hụt hẫng như vừa bị "chơi" một vố vậy.

Diễn biến

Blog của tôi thường có một đến nhiều ảnh trong bài viết nhưng đa phần là sẽ có một hình ảnh mở đầu đại diện cho cả bài. Vì vậy khả năng văn bản được tải xuống sau đó hình ảnh nhảy ra bất thình lình hoàn toàn có thể xảy ra. Đặc biệt là với người dùng thiết bị di động với tốc độ mạng chậm hoặc cấu hình yếu.

cls thấp

Có một cách để giải quyết vấn đề này đó là bạn cần phải chỉ định chiều cao (height) cho hình ảnh. Lúc đầu tôi nghĩ chỉ cần thiết lập width: 100%; height: auto là đủ, nhưng tôi đã sai lầm vì nếu không xác định height rõ ràng trình duyệt không xác định được chiều cao của ảnh để đặt trước chỗ. Tóm lại, nếu muốn đặt chỗ, bạn cần xác định được height. Lúc này những vấn đề bắt đầu xảy đến.

  • Thứ nhất là không thể thiết lập height cố định cho tất cả hình ảnh được vì kích thước của chúng không đồng nhất, nếu làm như thế có thể khiến tất cả ảnh khác bị méo mó.
  • Giải pháp tôi nghĩ đến là chỉ định height rõ ràng cho từng ảnh trong trình soạn thảo bài viết. Sau đó kết hợp với thuộc tính css aspect-ratio: attr(width) / attr(height) có thể giúp tôi co dãn hình ảnh một cách thoải mái. Tưởng chừng mọi việc đã được giải quyết thì lúc này một vấn đề khác lại xuất hiện.

Đó là bài viết của tôi lưu ở dạng markdown, ở định dạng này tôi có thể dễ dàng soạn thảo bài viết mà không đụng chạm đến những đoạn mã HTML phức tạp. Lợi ích của markdown là giúp tôi lưu trữ bài viết được "sạch" hơn. Sau đó, để lấy ra bài viết, tôi dùng một thư viện hỗ trợ chuyển markdown thành HTML. Vấn đề là thư viện tôi đang sử dụng không hỗ trợ việc thêm thuộc tính cho thẻ <img>.

Tôi cố tìm một thư viện khác nhưng có vẻ không cái nào làm được. Tôi thử đọc mã nguồn của thư viện đang sử dụng để tìm giải pháp nhưng có vẻ điều này vượt ngoài tầm với. Phần vì không hiểu phần vì không muốn tốn nhiều thời gian. Khi đó tôi chợt nghĩ nếu đang sử dụng Node thì hẳn đã có hàng tá thư viện làm tốt điều này (Cho ai chưa biết thì tôi đang sử dụng Golang để viết API).

Quả không sai, chỉ qua một vài lần tìm kiếm tôi đã tìm ra được showdown hỗ trợ thêm thuộc tính vào thẻ <img>. Lúc này phải nói thật thư viện Golang không có cửa so với Javascript. Một phần do cộng đồng JS rất lớn nên hầu như thư viện nào cũng có.

Việc này dẫn đến quyết định tách hẳn một service chuyên để parse markdown bằng Javascript dựa trên showdown. Nhưng làm sao thì làm, phải đảm bảo được tốc độ gọi service "gần" như hàm native trong Go. Vì thế tôi quyết định triển khai gRPC và sử dụng các cuộc gọi nội bộ (internal).

Phương pháp

Cho những ai chưa biết, gRPC là một Framework có thể được dùng để gọi hàm từ một service khác với tốc độ và độ tin cậy cao. Cũng giống như REST, gRPC sử dụng HTTP để truyền tải thông tin nhưng là HTTP/2.

Có nhiều lý do để tôi quyết định lựa chọn gRPC. Thứ nhất là tôi muốn service chỉ được gọi nội bộ (không có ý định publish), thứ hai là tốc độ và thứ ba là phân biệt rạch ròi giữa các service gọi nội bộ và các service được publish - điều mà gRPC đang thể hiện tốt.

Triển khai gRPC có khuynh hướng phức tạp hơn so với REST. Bạn sẽ phải viết nhiều mã hơn và triển khai các cuộc gọi gRPC phức tạp hơn. Nhưng bù lại là sự tin cậy và tốc độ, thật đáng để đánh đổi.

markdown là tên gọi của service này. markdown được viết bằng Node. Trong markdown chỉ có một file .proto rất đơn giản có một hàm:

syntax = "proto3";
package hicoffee.markdown;

service Markdown {
  rpc ConvertMarkdownToHTML (ConvertMarkdownToHTMLRequest) returns (ConvertMarkdownToHTMLReply) {}
}

message ConvertMarkdownToHTMLRequest {
  string markdown = 1;
}

message ConvertMarkdownToHTMLReply {
  string html = 1;
}

Triển khai của Node cũng rất đơn giản:

const PROTO_PATH = __dirname + '/protos/markdown.proto';

require('dotenv').config();
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');
const { ConvertMarkdownToHTML } = require('./handlers/markdown');

const packageDefinition = protoLoader.loadSync(
  PROTO_PATH,
  {
    keepCase: true,
    longs: String,
    enums: String,
    defaults: true,
    oneofs: true
  });
const markdown_proto = grpc.loadPackageDefinition(packageDefinition).hicoffee.markdown;

function convertMarkdownToHTML(call, callback) {
  callback(null, { html: ConvertMarkdownToHTML(call.request.markdown) });
}

function main() {
  const server = new grpc.Server();
  server.addService(markdown_proto.Markdown.service, { ConvertMarkdownToHTML: convertMarkdownToHTML });
  server.bindAsync(process.env.ADDRESS, grpc.ServerCredentials.createInsecure(), () => {
    server.start();
    console.log(`Server running at ${process.env.ADDRESS}`);
  });
}

main();

Chỉ có một hàm xử lý chính là ConvertMarkdownToHTML, hàm này đơn giản chỉ sử dụng thư viện showdown để chuyển markdown thành HTML rồi trả về kết quả.

Trong Go, triển khai client để gọi sang markdown có phần hơi mất thời gian. Về cơ bản vẫn là dựa vào file .proto để gọi hàm, chỉ có một lưu ý là bạn cần qua một bước build .proto thành hai tệp *.pb.go thì mới sử dụng được.

$ protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative protos/markdown.proto

Bạn đọc xem thêm hướng dẫn cũng như cách build tại Protocol Buffer Compiler Installation.

Cuối cùng để kiểm tra markdown có hoạt động, tôi sử dụng phần mềm bloomrpc. bloomrpc là một GUI client cho phép gọi gRPC một cách nhanh chóng và đơn giản.

kiểm tra hàm markdown

Vì các cuộc gọi là nội bộ nên tôi không triển khai thêm phần xác thực client. Nếu bạn có ý định triển khai gRPC công cộng hãy xem xét đến bảo mật.

Cuối cùng tôi triển khai tất cả lên máy chủ và chúng hoạt động đúng như mong đợi.

Tổng kết

Không vấn đề nào mà không thể giải quyết, giải pháp giải quyết vấn đề phụ thuộc vào kinh nghiệm của bạn mà đi từ đơn giản đến phức tạp. Nếu như tôi chỉ biết mỗi Go, không biết đến gRPC... thì mọi chuyện có thể sẽ đi theo hướng khác. Hy vọng qua bài viết này mang đến cho bạn đọc thêm một phương pháp giải quyết vấn đề nữa. Không có cách nào là tốt nhất mà chỉ có cách phù hợp nhất, bời vì tốt chỉ mang tính tương đối còn phù hợp thì đi theo hoàn cảnh mà bạn lựa chọn.

Cao cấp
Hello

Bí mật ngăn xếp của Blog

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (0)

Nội dung bình luận...