Design-First or Code-First: Pick, and Know the Cost

Worse is better: JSON versus XML

Mark Seemann cho rằng XML về mặt kỹ thuật vượt trội hơn JSON trong vai trò định dạng trao đổi dữ liệu, dù JSON được sử dụng rộng rãi hơn. Ông lập luận rằng danh tiếng kém của XML xuất phát từ các tiêu chuẩn phức tạp như SOAP, chứ không phải từ bản thân XML, vốn sở hữu hệ sinh thái tiêu chuẩn trưởng thành (XSD, XQuery, trình phân tích cú pháp streaming, hỗ trợ comment sẵn) mà JSON phải tái tạo thông qua công cụ bên thứ ba.

Lập trình viên nên đọc bài này để hiểu rõ những ưu nhược của XML và JSON trong việc chọn lựa công nghệ phù hợp cho các ứng dụng yêu cầu tính chính xác, mở rộng và tính tương thích tiêu chuẩn hóa cao.

Why I Stopped Calling Myself a Full-Stack Developer

Một chuyên gia công nghệ với 20 năm kinh nghiệm lập luận rằng danh xưng "Full-Stack …

Is Open Source Dead?

Việc sử dụng thư viện open source trở nên tốn kém hơn do chi phí duy trì, kiểm toán và phụ thuộc, trong khi LLMs giúp viết code rẻ hơn đáng kể. Giờ đây, chỉ nên dùng thư viện cho các lĩnh vực nhạy cảm bảo mật hoặc phức tạp, còn code đơn giản nên tự phát triển với sự hỗ trợ của LLM.

Làm việc với các dự án nhỏ hoặc logic đơn giản, hiểu cách tối ưu hóa giữa sử dụng thư viện mở nguồn và viết lại từ đầu sẽ giúp bạn tiết kiệm thời gian và tránh rủi ro khi phụ thuộc vào các công cụ lớn mà không kiểm soát được.

Monolith to Service Architecture

Di chuyển từ kiến trúc monolith sang microservices cần áp dụng các pattern cụ thể thay vì viết lại toàn bộ. Bốn chiến lược chính gồm: Strangler Fig (dần dần chuyển lưu lượng qua API gateway), Parallel Run (chạy song song để kiểm chứng), Collaborator (thêm microservices mới mà không sửa core), và Change Data Capture (đồng bộ dữ liệu real-time bằng Debezium/Kafka Connect). Các pattern này hiệu quả nhất khi kết hợp theo trình tự trong quá trình chuyển đổi.

Lập trình viên nên đọc bài này để hiểu cách chuyển đổi từ kiến trúc monolith sang microservices một cách chỉnh xác, ít rủi ro và tối ưu hóa hiệu suất, không phải là một thay đổi đột ngột mà là một quá trình thuần túy, có kế hoạch với các mẫu thiết kế hiệu quả.

CQRS Without the Astronaut Architecture

Bài viết hướng dẫn triển khai CQRS trong Node.js/TypeScript theo cách đơn giản, không cần cơ sở hạ tầng phức tạp như event sourcing hay message queues. CQRS ở đây chỉ là cách tổ chức code tách biệt logic ghi (commands) và đọc (queries), với ví dụ TypeScript cụ thể về rich write side và lean read side. Tác giả khuyên nên bắt đầu từ phân tách code đơn giản rồi nâng cấp dần khi cần thiết.

Lập trình viên nên đọc bài này để hiểu cách áp dụng CQRS một cách đơn giản và hiệu quả trong Node.js/TypeScript mà không cần phụ thuộc vào kiến trúc phức tạp, từ đó tối ưu hóa quy trình phát triển và bảo trì ứng dụng của mình.

Standalone JSON Schemas, Overlaid for Every Purpose

Thay vì nhúng mô hình dữ liệu vào components.schemas của tài liệu OpenAPI, bài viết đề xuất sử dụng các tệp JSON Schema độc lập với $id riêng trong thư mục schema/. Những schema này có thể tái sử dụng cho nhiều hệ thống (validation, generate code, docs, data warehouse) mà không phụ thuộc vào OpenAPI. OpenAPI overlays giúp điều chỉnh schema gốc cho mục đích cụ thể (như dịch description sang tiếng Đức) mà không thay đổi cấu trúc cốt lõi.

Lập trình viên nên đọc bài này để hiểu cách tối ưu hóa tái sử dụng và quản lý các định dạng dữ liệu độc lập từ OpenAPI, giúp giảm bớt sự phụ thuộc vào các tài liệu API cụ thể và mở rộng khả năng tái sử dụng cho nhiều công cụ khác nhau.

The Modular Monolith Boundary I Couldn't Take Back

Một lập trình viên chia sẻ kinh nghiệm khi ranh giới giữa hai module Catalog và Collaboration trong kiến trúc modular monolith dần trở nên không thể đảo ngược do yêu cầu kinh doanh buộc chuyển từ giao tiếp bất đồng bộ sang đồng bộ, khiến các module thực tế hoạt động như một khối thống nhất dù ranh giới vẫn tồn tại trên giấy. Bài viết khuyên nên coi ranh giới module là tạm thời, bắt đầu với ít module lớn hơn và chỉ tách nhỏ khi rõ ràng, đồng thời ưu tiên yêu cầu nhất quán hơn là trực giác về domain.

Lập trình viên nên đọc bài này để tránh rơi vào sai lầm khi cố gắng giữ các module độc lập trong một monolith mà thực tế đã bị "sáp nhập" nhờ yêu cầu tính nhất quán đồng bộ, khiến kiến trúc trở nên khó duy trì và mở rộng sau này.