Stack công nghệ của cutty.dev — những lựa chọn có ý thức
Điều gì nằm bên dưới cutty.dev và tại sao. Không truyền giáo — triết lý: một stack nhàm chán, ổn định, lưu trữ tại EU và quyền riêng tư được tích hợp sẵn vào kiến trúc mà một người có thể duy trì.
Hầu hết các bài viết "my tech stack" đều là một danh sách đầy tự hào về những thứ mới nhất. Nhìn xem, tôi có cái này, tôi có cái kia, và đây là một thư viện cực kỳ mới từ tuần trước. Bài viết này sẽ khác.
Bởi vì sự thật là khi bạn tự mình điều hành một dự án, bạn không tìm kiếm thứ gì đó thời thượng nhất. Bạn đang tìm kiếm thứ gì đó không khiến bạn phải thức giấc vào lúc ba giờ sáng. Và đó chính là ý nghĩa của toàn bộ stack công nghệ cutty.dev này: nhàm chán thay vì thời thượng, phong cách châu Âu thay vì kiểu Mỹ, riêng tư ngay từ nền tảng, và đủ đơn giản để một người có thể tự mình quán xuyến.
Tôi sẽ trình bày lần lượt, như thể đang giải thích điều này với bạn bên tách cà phê.
Astro được render phía server (và tại sao không phải thứ gì đó "hay ho hơn")
cutty.dev là Astro với cơ chế render phía máy chủ (server-side rendering). Mỗi yêu cầu đều đi qua máy chủ, tạo ra trang web và gửi về mã HTML hoàn chỉnh. Nhàm chán ư? Chính xác là như vậy.
Tôi muốn ba điều: rendering trên máy chủ mà không cần bộ máy cồng kềnh, hỗ trợ đa ngôn ngữ tốt ngay lập tức, và tốc độ mà không có sự dư thừa. Astro cung cấp tất cả những điều đó, và mã nguồn vẫn giữ được sự rõ ràng. Khi tôi quay lại với nó sau hai tháng nghỉ ngơi, tôi biết chính xác điều gì đang diễn ra ở đó. Đối với một dự án solo, điều này đáng giá hơn bất kỳ tiện ích thời thượng nào mà sau một năm không còn ai hỗ trợ nữa.
Một tệp thay vì cơ sở dữ liệu với pháo hoa
SQLite. Một cơ sở dữ liệu, một tệp duy nhất trên ổ đĩa. Thêm vào đó là một lớp truy vấn giao tiếp với TypeScript, vì vậy khi tôi thay đổi cấu trúc dữ liệu, lỗi sẽ hiển thị ngay trong trình soạn thảo chứ không phải trên môi trường production vào lúc nửa đêm.
Tại sao lại là cái này? cutty là "read-heavy". Ai đó nhấp vào một liên kết rút gọn, chúng ta thực hiện đọc và tăng bộ đếm. Chỉ vậy thôi. SQLite có thể xử lý lưu lượng như vậy một cách dễ dàng, cho đến những con số thực sự lớn mỗi ngày. Còn sao lưu thì sao? Bạn chỉ cần sao chép tệp. Xong. Không cần các nghi thức nhân bản (replication), không cần các kịch bản mà không ai nhớ chúng hoạt động như thế nào.
Hãy cẩn thận với một điều này, vì đây là một cái bẫy phổ biến: mọi người nghe thấy "SQLite" và nghĩ rằng đó là "một món đồ chơi cho dự án để qua môn". Không phải vậy đâu. Càng ít các thành phần chuyển động thì càng ít thứ có thể bị hỏng. Đây không phải là việc tiết kiệm chi phí bằng cách giảm chất lượng, mà là một quyết định có tính toán.
Máy chủ đặt tại Châu Âu và đó không phải là sự ngẫu nhiên
Máy chủ chuyên dụng tại EU. Có TLS riêng, reverse proxy với HTTPS tự động, ứng dụng trong container.
Đây là nền tảng cho cách cutty xử lý dữ liệu. Tôi biết chính xác nơi chúng được lưu trữ vật lý (đối với các khách hàng thuộc EU và GDPR, đây không phải là một điều thú vị, mà là một điều kiện bắt buộc), tôi không bị ràng buộc vào một nhà cung cấp duy nhất, không có gì tự động bị rò rỉ ra bên kia đại dương, và chi phí thì có thể dự đoán được thay vì biến động theo lưu lượng truy cập.
Đúng vậy, các nền tảng tiện lợi từ phương Tây sẽ giúp khởi đầu nhanh hơn. Bạn chỉ cần click, deploy, và nó hoạt động. Chỉ có điều bạn phải trả giá bằng việc dữ liệu người dùng của bạn sẽ nằm ở đâu. Đối với tôi, đó là một thỏa thuận không hề hời.
Bản dịch tự tạo mô hình riêng, tại máy của mình
cutty nói 25 ngôn ngữ. Nó được dịch bởi một mô hình AI mã nguồn mở, chạy cục bộ trên cơ sở hạ tầng của tôi. Tôi không gửi văn bản từ giao diện đến bất kỳ nhà cung cấp bên thứ ba nào.
Lợi ích là thực tế. Một bản dịch đơn lẻ không tốn chi phí. Tôi có toàn quyền kiểm soát chất lượng và có thể cập nhật chúng bất cứ khi nào tôi muốn. Và máy móc luôn cần đến mắt người, vì vậy mỗi ngôn ngữ trong số 25 ngôn ngữ này đều đã được xem xét. Nhưng sự thật là việc tôi thực hiện điều đó tại chính nơi của mình có nghĩa là quyền riêng tư không phải là một mục trong bảng giá. Nó là một đặc tính của cách mà toàn bộ hệ thống được xây dựng.
Tailwind, các container và một vài quyết định nhỏ hơn
Phong cách? Utility-first, chính là Tailwind. Không CSS-in-JS, không các tệp style riêng biệt, mọi thứ đều nằm ngay trong template. Tôi không lãng phí thời gian vào việc nghĩ tên class, các style không được sử dụng cũng sẽ không xuất hiện trên trang cuối cùng, và thiết kế luôn nhất quán vì bản thân hệ thống đã bắt buộc như vậy. Đối với một người, mỗi phút không bị lãng phí vào những việc vặt đều cực kỳ quan trọng.
Triển khai là Docker. Cùng một môi trường ở cả máy cục bộ và trên production, chấm dứt tình trạng "chạy được trên máy tôi". Và nếu khi nào cần thiết, tôi có thể chuyển toàn bộ sang một máy chủ khác chỉ trong khoảng nửa giờ. Tính di động chính là một hình thức của sự độc lập một cách thầm lặng.
Tôi đã rút ra được điều gì
Một stack nhàm chán sẽ giành chiến thắng. Astro, SQLite, Tailwind, containers. Mọi thứ đều đã trưởng thành, đã được kiểm chứng và có tài liệu đầy đủ. Không có gì bị hỏng vào thời điểm bạn ít cần đến nó nhất.
Hosting tại EU đã sẵn sàng cho môi trường production, thực sự đấy. Cái ý tưởng rằng "bạn phải dùng đến đám mây lớn của Mỹ thì mới thực sự nghiêm túc" chỉ là một câu chuyện viễn tưởng. AI nội bộ cũng rất khả thi, không cần phải gửi dữ liệu tới API bên ngoài để có được bản dịch chất lượng tốt. Và điều cuối cùng: một người có thể tung ra thứ trông như công sức của cả một đội ngũ. Chỉ cần nhớ rằng thời gian còn đắt hơn tiền bạc, và hãy cân nhắc kỹ từng mảnh ghép dưới góc độ đó.
Khi bạn xây dựng một thứ gì đó của riêng mình, hãy tự hỏi bản thân một câu hỏi với mỗi công nghệ: liệu một năm nữa tôi có thể tự mình duy trì nó không? Nếu không, thì có lẽ bạn đã có câu trả lời.
Tất cả hoạt động tại đây: cutty.dev. Và nếu bạn muốn thảo luận về bất kỳ quyết định nào trong số này, hãy viết cho [email protected], tôi sẽ phản hồi ngay trong ngày.