"Full-stack" trên CV đọc như một lựa chọn, một cú định vị có tính toán. Của mình thì không. Suốt bốn năm rưỡi, những hệ thống mình làm — tool nghiệp vụ nội bộ, admin panel, các service tích hợp — tại mỗi thời điểm chỉ có đúng một kỹ sư gắn vào, và người đó là mình. Không có đồng nghiệp frontend để đưa cái dashboard, không có team ops để đưa cái deploy. Cái stack không phải thứ mình trải rộng ra để ôm. Nó là thứ không có ai khác đứng lên.
Cái ràng buộc đó hoá ra dạy được những thứ mà một cái ghế chuyên môn hoá sẽ không dạy, và nó cũng tính phí đàng hoàng. Cả hai nửa đều đáng viết ra.
Cái dashboard là cú review API nhanh nhất bạn từng nhận
Bài học tinh khiết nhất đến từ việc dựng một admin dashboard tiêu thụ chính API của mình. Không phải API của đồng nghiệp, nơi phép lịch sự làm đệm cho phản hồi — API của mình, nơi mọi đường tắt trong thiết kế quay về đúng bàn mình trong vòng một tiếng.
Pagination hết trừu tượng ngay khoảnh khắc bạn render cái bảng. Error shape hết trừu tượng ngay khoảnh khắc bạn phải cho một con người thấy vì sao thao tác của họ hỏng, và phát hiện API của mình trả về ba định dạng lỗi khác nhau tuỳ theo tầng nào ném ra. Empty state hết trừu tượng khi màn hình thật đầu tiên là một khách hàng chưa có dữ liệu, và câu trả lời của endpoint cho "chưa có gì" không phân biệt được với "có gì đó vừa hỏng".
Từng cái trong số đó đều vô hình khi nhìn từ trong backend ra. Cái API trông như đã xong. Contract đủ hết các field. Phải đi tiêu thụ nó — một cái bảng React, một cái hook TanStack Query, một buổi chiều — mới lộ ra chữ "xong" đã giấu những gì. Từ đó tới giờ mình vẫn review API trên giấy, nhưng mình vẫn tin một màn hình tiêu thụ thật hơn bất kỳ lượng đọc nào.
Ship rồi mới biết config nào là config thật
Bài học chiều ngược lại chạy từ frontend về backend. Hồi thiết kế service, mình từng coi configuration là sự hào phóng: cái gì cũng cho thành setting, biết đâu có người cần. Deploy rồi vận hành đúng cái service đó chữa dứt bệnh ấy. Config tách thành hai giống loài rất khác nhau — những giá trị có người thật sự đổi dưới áp lực vào một giờ oái oăm, và những giá trị configurable chỉ vì làm cho nó configurable tạo cảm giác chỉn chu. Loại thứ hai không phải sự linh hoạt. Nó là diện tích bề mặt: thêm cách để hai môi trường lệch nhau, thêm chỗ cho một giá trị sai ngồi nấp. Chỉ có vận hành mới nói cho bạn biết cái nào thuộc loại nào, vì chỉ có vận hành mới cho thấy núm nào từng thật sự bị vặn.
Vận hành dạy rằng rollback là một tính năng
Phía deployment — Docker, Kubernetes, Helm, Rancher, PM2, GitLab CI — dạy bài học thẳng thừng nhất: rollback là tính năng phải xây trước khi cần đến. Pipeline của bọn mình là manual một cách có chủ đích; một con người bấm nút, và bước production đòi xác nhận tường minh trước khi chạy. Mỗi lần push là bump một patch version. Cái thói quen cuối nghe như ghi sổ, cho tới cú deploy hỏng đầu tiên, khi "rollback" chỉ là một mệnh lệnh thật nếu "back về đâu" có câu trả lời chính xác. Một version cho mỗi lần push nghĩa là câu đó lúc nào cũng trả lời được.
Không mảnh máy móc nào trong đó được xây vào cái tuần bạn cần nó. Nó được xây từ trước, bởi người từng đứng ở phía vận hành của chính cú deploy của mình và còn nhớ cảm giác khi câu trả lời cho "hiện production đang chạy cái gì" là một cái nhún vai.
Cái giá, nói thật
Rộng không phải là sâu, và vờ như hai cái là một là cách "full-stack" biến thành một uyển ngữ. Có những mảng mình biết đủ để dựng được cái cần dựng, và đủ để biết một chuyên gia sẽ dựng tốt hơn: tối ưu hiệu năng database ở tầng sâu hơn mấy cái index và query shape mình tự suy luận được; accessibility và animation phía frontend làm cho tử tế thay vì tạm ổn; security vượt quá mức vệ sinh tiêu chuẩn; phần ruột Kubernetes bên dưới cái tầng mình vận hành. Mình chủ động giữ cái danh sách đó luôn mới. Cách giữ cho sự trải rộng được trung thực là nói ra được, mà không cần bị dồn vào chân tường, phần nào bạn sẽ giao cho chuyên gia — và đã thật sự đi xin một người như thế khi mức cược xứng đáng.
Vì sao nó quan trọng trên một platform tích hợp
Phần lãi thật nằm ở chính loại hệ thống mình đang làm bây giờ. Một platform tích hợp là một sợi xích: cái bảng React bắn một cú search, một cái queue toả nó ra các worker, worker map cái request sang thứ tiếng mà supplier nói — JSON nếu may, SOAP với body XML nếu không — và câu trả lời đi bộ ngược cả sợi xích về.
Khi sợi xích đó đứt, cú hỏng gần như không bao giờ tự khai nó đứt ở mắt nào. Triệu chứng nổi lên ở đầu này còn nguyên nhân sống ở đầu kia. Người dò được cái request đi trọn quãng đường — người từng viết cái bảng frontend, cái consumer của queue, và cái mapping XML, và từng deploy cả ba — là người tìm ra được nó gãy ở đâu, vì không ranh giới nào trên con đường đó là bức tường đối với họ.
Mình sẽ không kê con đường này thành đơn thuốc; nó được giao chứ không được chọn, và nó lấy đi phần chiều sâu mà đôi lúc mình vẫn tiếc. Nhưng trên một hệ thống mà toàn bộ công việc là băng qua các ranh giới, việc đã từng băng qua tất cả chúng ít nhất một lần không phải là huy hiệu. Nó là bộ đồ nghề debug.