Tôi Dùng AWS Cognito Cho Startup Của Mình — Và Sẽ Không Bao Giờ Làm Lại
Bài viết chia sẻ trải nghiệm đau thương khi sử dụng AWS Cognito làm hệ thống xác thực cho startup, từ tài liệu rối rắm, thay đổi API gây sốc đến giới hạn tùy biến khó chịu. Tác giả cảnh báo các nhà phát triển nên cân nhắc kỹ lưỡng và thử nghiệm POC trước khi chọn Cognito, thay vì chỉ dựa vào sự tiện lợi của hệ sinh thái AWS.

Mở đầu: Ba ngày vật lộn với Cognito
Tôi đã dành ba ngày để cài đặt xác thực (authentication) cho startup của mình trước khi nhận ra có gì đó không ổn. Không phải kiểu "thiếu dấu chấm phẩy" mà là kiểu "đã làm đúng hết mọi bước theo tài liệu mà flow reset mật khẩu vẫn redirect sai chỗ."
Tôi mở 12 tab tài liệu, copy-paste mọi đoạn code mẫu, thậm chí xem cả video hướng dẫn từ một người có vẻ đã từng trải qua cơn ác mộng y hệt. Vấn đề là — tôi đã từng làm authentication nhiều lần rồi. Tôi từng vật lộn với Auth0, thuần phục Firebase Auth, thậm chí tự code một hệ thống JWT tùy chỉnh dù không đáng tự hào nhưng nó hoạt động. Vậy nên khi team nghiêng về Cognito vì "đã có sẵn trong hệ sinh thái AWS và 50.000 người dùng hoạt động hàng tháng đầu tiên miễn phí", tôi nghĩ: "Tệ đến mức nào chứ?"
Tôi hối hận vì mọi thứ.
Tài liệu viết cho năm đối tượng khác nhau cùng lúc
Đọc tài liệu Cognito giống như ai đó xay ba cuốn sách hướng dẫn riêng biệt thành hỗn hợp rồi rắc thêm vài câu trả lời Stack Overflow cũ kỹ cho có hương vị.
AWS cố phục vụ quá nhiều đối tượng cùng lúc: kiến trúc sư doanh nghiệp muốn hiểu giao thức định danh nền tảng, frontend developer chỉ muốn một form đăng nhập, mobile developer cần SDK gốc. Tài liệu cố gắng phục vụ tất cả, nên cuối cùng chẳng giúp ích được ai.
Tôi tìm "Cognito custom attribute validation" thì ra một trang bắt đầu bằng đoạn văn về directory schemas mà giả định tôi đã đọc bốn trang khác mà tôi không biết tồn tại. Không có một lộ trình tuyến tính rõ ràng. Chỉ là mạng lưới siêu liên kết và lời cầu nguyện.
Rồi đến code mẫu. Một nửa dành cho JavaScript SDK cũ, một số tham chiếu Amplify v1 API, còn lại dùng raw AWS SDK. Tài liệu không luôn nói rõ phiên bản nào đang được nhắc đến, khiến bạn phải làm thám tử với mấy câu import.
Ngày Amplify v6 phản bội tôi
Nói về phiên bản. Đây là chuyện khiến tôi thực sự bất ngờ.
Khi bắt đầu xây dựng, Amplify đang ở phiên bản 5. Tôi viết auth flow, test, commit, rồi chuyển sang tính năng khác. Vài tuần sau, tôi quay lại sửa bug và thấy vài cảnh báo deprecated trong console. Không vấn đề, tôi nghĩ, chỉ cần update lên phiên bản mới nhất.
Nhưng này — Amplify v6 không chỉ đổi vài chữ ký hàm. Nó tái cấu trúc hoàn toàn cách tương tác với Cognito. Những hàm tôi đã xây cả UI flow quanh chúng biến mất, được thay thế, tan biến. Bản migration guide thì tồn tại, nhưng cảm giác như bản đồ kho báu thiếu mất một nửa địa danh.
Tôi viết lại code. Không phải refactor — mà viết lại hoàn toàn. Logic authentication đang hoạt động hoàn hảo trên production phải xây dựng lại từ đầu vì nhóm phát triển thư viện quyết định API cũ không còn được ưu tiên. Đó không phải nâng cấp, mà là tình thế bị bắt làm con tin.
Local Development — Nỗi đau đặc biệt
Sự thật thú vị về Cognito: nó chạy trên cloud. Tôi biết, sốc thật. Nhưng điều đó có nghĩa là bạn không thể chạy instance local và test auth flow khi offline. Bạn luôn phải gọi đến endpoint AWS thật.
Có những công cụ như serverless-offline plugin hay local Cognito emulators cố gắng giải quyết khoảng trống này, nhưng chúng là dự án cộng đồng với mức độ bảo trì và độ chính xác khác nhau. Câu trả lời chính thức từ AWS gần như là "test trên cloud" — lời khuyên tuyệt vời trừ khi bạn đang trên máy bay, internet chập chờn, hoặc muốn vòng lặp phát triển nhanh không chờ network round trip.
Tôi mất một khoảng thời gian đáng xấu hổ để setup local mock mà không khớp hoàn toàn với thực tế, khiến bug lọt qua local rồi xuất hiện ở staging. Mục đích của local development là phát hiện lỗi sớm, còn Cognito thì ngược lại.
Muốn tùy biến? Tệ nhất là chỉ có logo
Điều này thật đau đớn.
Hosted UI mà Cognito cung cấp thì có hoạt động. Nó tồn tại, chạy được, đa số là vậy. Nhưng nếu bạn muốn giao diện giống thương hiệu của mình, không phải kiểu "AWS service mặc đồ giả trang", bạn sẽ có khoảng thời gian tệ hại.
Bạn có thể đổi logo. Có thể tinh chỉnh chút CSS qua console. Nhưng layout, cấu trúc, cảm giác tổng thể? Đó là ngôi nhà của AWS, còn bạn chỉ là người thuê phòng. Nếu cần gì hơn tùy biến cơ bản, lời khuyên từ cộng đồng thường là "tự xây UI bằng SDK." Nghe thì cũng hiểu, nhưng lúc đó hosted UI giúp được gì cho tôi?
Cấu hình chỉ email — Thứ phá vỡ tinh thần tôi
Để tôi kể khoảnh khắc tôi gần như ném laptop qua cửa sổ.
App của chúng tôi chỉ cần xác thực bằng email. Không username. Người dùng đăng ký bằng email, xác minh, đặt mật khẩu là xong. Khái niệm đơn giản, đúng không?
Tôi vào cài đặt user pool, cấu hình dùng email làm định danh đăng nhập. Setup attribute mappings, tạo sign-up flow. Mọi thứ có vẻ ổn cho đến khi tôi nhận ra Cognito xử lý "email" khác nhau tùy vào việc nó là core attribute, alias, hay custom attribute — và các tùy chọn nằm rải rác nhiều màn hình console với những phụ thuộc lẫn nhau không bao giờ được giải thích đầy đủ.
Tôi mắc lỗi trong setup ban đầu. Một lỗi nhỏ. Tôi cấu hình một thứ thành custom attribute trong khi lẽ ra phải là standard. Không vấn đề, tôi nghĩ, chỉ cần đổi lại.
Bạn không thể đổi nó.
Một khi attribute được tạo dạng custom, nó custom mãi mãi. Nếu scheme xác thực của bạn phụ thuộc vào mối quan hệ giữa các attribute mà cấu hình sai, lựa chọn của bạn là: xóa toàn bộ user pool và làm lại, hoặc xây quy trình migration phức tạp chuyển user sang pool mới với cấu hình đúng.
Với app production có user hoạt động, "cứ xóa đi" không phải là lựa chọn khả thi. Vậy là bạn phải viết script migration, xử lý reset mật khẩu trong pool mới, và xin lỗi người dùng vì sự bất tiện. Tất cả vì một dropdown trong console quá mơ hồ.
Bài học thực sự
Tôi không chỉ muốn than phiền vì chuyện đó quá dễ. Nhưng tôi muốn thành thật về những gì trải nghiệm này dạy tôi, vì có điều hữu ích ở đây ngoài câu "Cognito tệ."
Authentication không phải nơi để cắt giảm. Lập luận "đã có sẵn trong hệ sinh thái" rất hấp dẫn, nhưng sự gần gũi với hệ sinh thái không quan trọng nếu công cụ khiến bạn khổ sở mỗi lần chạm vào. Free tier hấp dẫn cho đến khi bạn tính số giờ công kỹ thuật bỏ ra để chiến đấu với tài liệu và viết lại code vì breaking API changes.
Lần tới, tôi sẽ chọn công cụ dựa trên trải nghiệm developer trước, không phải sự tiện lợi tích hợp AWS. Thời gian chúng tôi mất để debug Cognito có thể trả tiền cho vài năm dùng auth provider trả phí. Và chúng tôi đã ship nhanh hơn, ít pizza nguội lúc nửa đêm hơn.
Nếu bạn đang đọc bài này vì đang cân nhắc Cognito cho dự án của mình — tôi không bảo bạn phải làm gì. Nhưng tôi khuyên thế này: hãy xây một proof of concept nhỏ trước. Thứ gì đó không tầm thường — có custom attributes, xác minh email, flow reset mật khẩu. Cảm nhận thử. Bấm giờ. Đếm số tab tài liệu bạn mở khi kết thúc.
Nếu con số đó trên hai mươi, có lẽ nên cân nhắc lại.
Nhân tiện — tôi vẫn đang dùng Cognito cho dự án này. Chúng tôi đã đi quá xa để bây giờ gỡ ra. Nhưng mỗi lần mở AWS console và thấy cái user pool đó nằm im, tôi lại cảm thấy một sự bực bội âm ỉ, nhỏ nhẹ. Như kiểu ở chung với một người bạn không bao giờ rửa chén và cứ "mượn" đồ của bạn.
Bạn biết cảm giác đó mà.
Bài viết được biên tập bởi Lehuy.net — Chuyên trang tin tức công nghệ, AI, phần mềm, phần cứng và xu hướng số.