Bắt đầu từ một thực tế: AI không nên nằm thẳng trong UI

Ở giai đoạn đầu, rất nhiều team làm theo cách tự nhiên nhất:

• Frontend gọi backend

• Backend gọi model

• Model trả kết quả

• Frontend hiển thị

Flow này đủ tốt cho một prototype. Nhưng khi sản phẩm bắt đầu có:

• Nhiều loại request

• Nhiều nguồn dữ liệu

• Nhiều bước xử lý

• Cần retry, logging, fallback

• Cần track token/cost

• Cần phối hợp nhiều model hoặc tool

thì cách “một request đi thẳng từ UI sang model” bắt đầu lộ giới hạn.

Lý do rất đơn giản: AI thường không phải một hàm xử lý thuần túy kiểu “input vào, output ra” nữa. Nó dần trở thành một workflow có trạng thái, có rủi ro, có ngoại lệ, và có những bước mà product cần kiểm soát chặt hơn là chỉ “gọi API”.

Đó là lúc kiến trúc phải có thêm một lớp trung gian rõ ràng hơn.

Nhìn kiến trúc theo 4 lớp

Nếu phải giải thích ngắn gọn, tôi thường nhìn một ứng dụng AI-enabled theo 4 lớp:

1. Frontend / experience layer

Đây là nơi người dùng tương tác:

• Chat UI

• Form nhập dữ liệu

• Màn hình tạo nội dung

• Dashboard gợi ý

• Màn hình review kết quả AI

Với Full Stack JS, lớp này thường là:

• React

• Next.js

• TypeScript

Nhưng điều quan trọng không nằm ở framework. Điều quan trọng là frontend không nên gánh quá nhiều logic AI. UI nên tập trung vào:

• Thu input

• Hiển thị trạng thái

• Phản ánh tiến trình xử lý

• Render output

• Hỗ trợ review / feedback / retry

Nói cách khác, frontend là nơi trải nghiệm AI được bộc lộ ra, nhưng không nên là nơi “điều phối AI”.

2. Application / API layer

Đây là lớp backend gần với product nhất. Nó xử lý:

• Auth

• Request validation

• Session/user context

• API contract

• Business rules cơ bản

• Routing theo feature

Trong hệ Full Stack JS, lớp này thường là:

• Next.js server routes

• Node.js API layer

• Hoặc một backend service bằng Express / NestJS / Fastify

Nhiều team dừng ở đây và gọi luôn model từ lớp API. Điều đó có thể ổn ở giai đoạn đầu. Nhưng khi use case tăng lên, lớp này rất nhanh bị phình ra nếu nó vừa làm business API, vừa làm AI workflow coordinator.

Đó là lý do lớp thứ ba trở nên quan trọng.

3. Orchestration layer

Đây là lớp nhiều team thiếu nhất lúc đầu, nhưng lại là nơi quyết định một sản phẩm AI-enabled có vận hành được hay không.

Orchestration layer là nơi xử lý:

• Chọn model nào

• Ghép prompt / context

• Gọi tool nào trước, tool nào sau

• Đọc dữ liệu từ đâu

• Fallback khi model lỗi

• Retry logic

• Phân nhánh theo loại task

• Gom output từ nhiều bước

• Logging, tracing, usage tracking

• Đôi khi cả human-in-the-loop

Nếu không có lớp này rõ ràng, logic AI sẽ bị rải khắp nơi:

• Một ít trong frontend

• Một ít trong API route

• Một ít trong service helper

• Một ít trong background job

• Một ít trong prompt file

• Và cuối cùng không ai nhìn ra toàn bộ flow nữa

Đây là chỗ AI integration bắt đầu mất kiểm soát.

4. Data / infrastructure layer

AI-enabled product thường không chỉ cần một database.

Ngoài database chính, rất dễ phát sinh thêm:

• Object storage cho file

• Vector store hoặc retrieval index

• Job queue

• Cache

• Logging/observability stack

• Usage analytics

• Secret/config management

Tùy use case, có thể cần:

• PostgreSQL/MySQL cho application data

• Redis cho cache hoặc queue

• S3-compatible storage cho file

• Queue worker cho task nặng

• Search/vector layer cho retrieval

Lớp này không mới với product engineering, nhưng AI khiến nó trở nên quan trọng hơn vì hệ thống bắt đầu có nhiều bước không đồng bộ, nhiều loại dữ liệu phi cấu trúc, và nhiều điểm cần theo dõi hơn.

Full Stack JS mạnh ở đâu trong bài toán này?

Có lý do khiến nhiều team thích dùng Full Stack JS để build AI-enabled product.

Không phải vì JavaScript “hợp AI” hơn ngôn ngữ khác theo nghĩa kỹ thuật thuần túy. Mà vì hệ sinh thái này khá phù hợp với việc build nhanh một chuỗi trải nghiệm liền mạch từ UI đến service layer.

Một stack kiểu:

• Next.js

• React

• TypeScript

• Node.js

• Queue / worker

• Relational DB

• Redis

• Cloud deployment

thường đủ để build khá nhiều loại sản phẩm AI-enabled ở giai đoạn đầu và giữa.

Điểm mạnh của cách này là:

• Cùng một ngôn ngữ xuyên nhiều lớp

• Tốc độ phát triển nhanh

• Frontend và backend gần nhau hơn

• Dễ chia sẻ types, validation schema, domain model

• Dễ iterate product

Nhưng điểm yếu cũng rõ: vì làm nhanh được nên rất dễ “gói tất cả vào một app”, dẫn tới việc lớp orchestration không bao giờ được tách ra cho rõ, và toàn bộ logic AI nằm lẫn với logic sản phẩm.

Cái bẫy của Full Stack JS không phải là không đủ mạnh.
Cái bẫy là quá tiện để nhét mọi thứ vào cùng một chỗ.

Một flow đơn giản nhưng lành mạnh hơn

Nếu mô tả một kiến trúc tương đối thực dụng cho sản phẩm AI-enabled, tôi sẽ hình dung flow như thế này:

Người dùng thao tác ở frontend.
Frontend gửi request tới application API.
API xác thực request, nạp user context, kiểm tra rule cơ bản.
Sau đó API chuyển việc sang orchestration layer.
Orchestration layer quyết định:

• Gọi model nào

• Có cần retrieval không

• Có cần tool hay workflow bổ sung không

• Có chạy đồng bộ hay đẩy qua background job không

Kết quả sau cùng mới được đưa ngược lên frontend, hoặc được ghi lại để frontend polling / stream / refresh theo trạng thái.

Nghe có vẻ dài hơn cách “frontend gọi model”. Nhưng đó là cái giá cần thiết để hệ thống đủ tỉnh táo khi số lượng use case tăng lên.

Khi nào nên xử lý đồng bộ, khi nào nên đẩy thành job?

Đây là quyết định kiến trúc rất thực tế.

Không phải mọi AI feature đều nên trả kết quả ngay trong một request-response cycle. Có những thứ đủ nhẹ để làm đồng bộ:

• Generate đoạn text ngắn

• Summarize input nhỏ

• Classify dữ liệu đơn giản

• Gợi ý câu trả lời nhanh

Nhưng có những thứ nên đi qua queue/job:

• Xử lý tài liệu lớn

• Multi-step reasoning

• Retrieval từ nhiều nguồn

• Tạo báo cáo dài

• Chạy pipeline nhiều bước

• Xử lý file audio/video

• Post-processing hoặc validation

Rất nhiều trải nghiệm AI tệ không đến từ model yếu. Nó đến từ việc kiến trúc cố nhồi một workflow dài vào một request đồng bộ, khiến:

• UI chờ quá lâu

• Timeout

• Retry lặp

• Trạng thái mơ hồ

• Khó quan sát lỗi

Khi có orchestration layer và job layer rõ, bài toán này dễ kiểm soát hơn nhiều.

AI feature thường không chết vì model, mà chết vì reliability

Đây là chỗ nhiều team nhận ra hơi muộn.

Làm một AI feature để demo thường không khó lắm. Gọi model được, output nhìn ổn, ai cũng thấy “hay”.

Cái khó hơn nhiều là làm cho nó:

• Ổn định

• Đo được

• Debug được

• Kiểm soát chi phí được

• Có fallback khi model không đáng tin

• Không phá UX khi output kém

Cho nên nếu thiết kế kiến trúc cho AI-enabled product, đừng chỉ nghĩ đến model call. Hãy nghĩ đến:

• Timeout

• Retry policy

• Fallback response

• Guardrails

• Logging prompt / response metadata

• Observability theo feature

• Feedback loop từ user

• Versioning prompt / workflow

Nếu không có những lớp này, AI feature rất dễ rơi vào trạng thái “lúc được lúc không”, mà team không biết thật ra nó đang hỏng ở đâu.

Retrieval, prompt, tool calling: đừng để chúng sống rải rác

Một lỗi thiết kế khá phổ biến là:

• Prompt nằm hardcode trong route

• Retrieval logic nằm trong một helper file khác

• Tool calling viết trong service riêng

• Post-processing lại ở chỗ khác nữa

Kết quả là sau vài sprint, không ai dám chạm vào flow đó vì sửa một chỗ có thể kéo hỏng chỗ khác.

Kiến trúc tốt hơn là xem mỗi AI use case như một pipeline có tên, có ranh giới, có input/output rõ.

Ví dụ:

• generate_product_summary

• extract_invoice_fields

• suggest_support_reply

• build_candidate_shortlist

Mỗi pipeline nên có:

• Contract đầu vào

• Context cần dùng

• Bước retrieval nếu có

• Model config

• Tool steps nếu có

• Output schema

• Error/fallback behavior

Khi nhìn như vậy, team sẽ dễ hơn trong việc:

• Test

• Monitor

• Review

• Cải tiến

• Thay model hoặc thay prompt mà không phá luồng

Frontend cho AI không chỉ là nơi hiển thị text

Khi nói “AI-enabled product”, nhiều người hình dung ngay tới chatbox. Nhưng trên thực tế, frontend cho AI thường cần tinh tế hơn thế.

Một UI tử tế cho AI nên hỗ trợ được:

• Loading state rõ ràng

• Streaming nếu hợp lý

• Version/result comparison

• Inline review / approve / reject

• User feedback

• Fallback khi output không tốt

• Khả năng chỉnh sửa đầu ra thay vì ép người dùng chấp nhận toàn bộ

Điểm này quan trọng vì AI rarely gives perfect outputs every time. Một sản phẩm thông minh không giả vờ rằng AI luôn đúng. Nó thiết kế trải nghiệm để người dùng:

• Hiểu hệ thống đang làm gì

• Biết khi nào nên tin

• Biết khi nào nên sửa

• Không bị rơi vào trạng thái chờ đợi mơ hồ

Đó là chỗ frontend và orchestration phải nói chuyện tốt với nhau.

Khi nào cần agent, khi nào chỉ cần workflow?

Đây là chỗ rất dễ bị hype.

Nếu một flow đã khá rõ:

• Lấy dữ liệu từ A

• Gọi model để xử lý

• Validate output

• Ghi kết quả vào B

• Gửi phản hồi ra UI

thì rất có thể anh không cần agent. Anh chỉ cần một workflow được tổ chức tốt.

Agent chỉ nên được cân nhắc khi bài toán thật sự cần:

• Nhiều bước ra quyết định linh hoạt

• Chọn tool theo ngữ cảnh

• Lập kế hoạch giữa nhiều action

• Trạng thái mở, ít xác định từ trước

Còn với phần lớn product feature trong doanh nghiệp, workflow rõ ràng, guardrail chặt, và orchestration lành mạnh thường thực tế hơn nhiều.

Nói cách khác:
đừng dùng agent chỉ vì “nghe hiện đại hơn”.

Một kiến trúc tốt cho AI-enabled product thường có gì?

Nếu phải tóm gọn, tôi sẽ mong một hệ thống có các đặc điểm sau:

• Frontend rõ ràng, không ôm logic AI

• API layer giữ vai trò business contract

• Orchestration layer tách riêng và có cấu trúc

• Job/queue cho task dài hoặc nặng

• Persistence rõ cho dữ liệu ứng dụng và dữ liệu workflow

• Observability đủ để biết feature AI đang hoạt động ra sao

• Output có schema hoặc ít nhất có contract rõ

• Fallback và error handling được thiết kế từ đầu

• Prompt/workflow không bị hardcode rải rác

Không cần tất cả phải thật to ngay từ ngày đầu. Nhưng nếu ngay từ đầu team đã nhìn ra các lớp này, sản phẩm sẽ dễ lớn lên hơn rất nhiều.

Kết luận

Xây một ứng dụng AI-enabled với Full Stack JS không khó nếu mục tiêu chỉ là làm một demo có thể chạy. Cái khó hơn là xây được một hệ thống đủ rõ ràng để AI trở thành một phần vận hành được của sản phẩm.

Khi đó, câu hỏi không còn là:
“Làm sao để gọi model?”

Mà là:

• AI nên nằm ở lớp nào trong kiến trúc?

• Logic orchestration nằm ở đâu?

• Khi feature tăng lên, ai còn hiểu toàn bộ flow?

• Khi model fail, hệ thống phản ứng thế nào?

• Khi sản phẩm đi vào production, team quan sát và cải tiến feature AI bằng cách nào?

Với Full Stack JS, lợi thế lớn là tốc độ và sự liền mạch từ frontend đến backend. Nhưng để đi được xa hơn demo, team cần thêm một điều nữa: kỷ luật kiến trúc.

Vì cuối cùng, một sản phẩm AI-enabled tốt không phải là sản phẩm gọi được model ở nhiều chỗ nhất.

Nó là sản phẩm biết đặt AI đúng chỗ trong hệ thống.