Generative AI đang ngày càng trở thành một phần phổ biến trong các ứng dụng mobile. Khi xây dựng một tính năng AI, developer thường bắt đầu với kiến trúc như sau:

Ứng dụng Mobile
    ↓
Backend API
    ↓
Nhà cung cấp LLM

Với các hệ thống AI phức tạp, kiến trúc này hoàn toàn hợp lý.

Backend có thể cần xử lý:

RAG (Retrieval-Augmented Generation)
Vector database
Workflow LangChain / LangGraph
Tool calling
Business rule
Conversation memory
Multi-agent orchestration
Kiểm soát truy cập
Quản lý prompt
Theo dõi mức sử dụng
Tích hợp với hệ thống nội bộ

Nhưng nếu tính năng AI thực tế lại rất đơn giản thì sao?

Ví dụ:

Một ứng dụng mobile chỉ cần một chatbot, nơi người dùng gửi tin nhắn, hệ thống kết hợp tin nhắn đó với prompt và Gemini tạo ra câu trả lời.

Trong trường hợp này, việc thêm một backend service có thể làm tăng khối lượng hạ tầng và công việc bảo trì nhiều hơn giá trị mà backend thực sự mang lại.

Firebase AI Logic cung cấp một cách tiếp cận khác.

Thay vì:

Ứng dụng Mobile
    ↓
Backend API
    ↓
LangChain / LangGraph
    ↓
Gemini API

chúng ta có thể đơn giản hóa kiến trúc thành:

Ứng dụng Mobile
    ↓
Firebase AI Logic
    ↓
Gemini

Firebase AI Logic cung cấp client SDK cho phép ứng dụng mobile và web gọi Gemini API trực tiếp từ application code. Hiện tại SDK hỗ trợ Swift cho nền tảng Apple, Kotlin/Java cho Android, JavaScript cho Web, Dart cho Flutter và Unity.

Firebase AI Logic hỗ trợ Gemini thông qua hai lựa chọn provider:

Từ đó xuất hiện một câu hỏi thực tế về kiến trúc:

Làm thế nào để đưa một tính năng AI lên production nhanh hơn mà không over-engineer hệ thống?

Kiến trúc truyền thống

Giả sử chúng ta đang xây dựng một chatbot đơn giản trong ứng dụng mobile.

Kiến trúc backend có thể như sau:

┌─────────────────────┐
│   Ứng dụng Mobile   │
└─────────┬───────────┘
          │ HTTPS
          ▼
┌─────────────────────┐
│     Backend API     │
│                     │
│ - Authentication    │
│ - Tạo prompt        │
│ - API proxy         │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│    Gemini API       │
└─────────────────────┘

Thiết kế này hoàn toàn hợp lệ.

Tuy nhiên, nếu backend thực tế chỉ làm nhiều hơn một chút so với:

const response = await model.generateContent([
  SYSTEM_PROMPT,
  userMessage,
]);

return response.text;

thì đáng để đặt câu hỏi:

Backend này có thực sự tạo ra đủ giá trị để đáng với công sức xây dựng và vận hành hay không?

Trong production, một backend service thường kéo theo thêm nhiều trách nhiệm:

Deployment pipeline
Container hoặc serverless runtime
Logging
Monitoring
Scaling
Authentication middleware
Secret management
API rate limiting
Error handling
Cấu hình hạ tầng
Security patching

Với các AI workflow phức tạp, phần overhead này là hợp lý.

Với một tính năng AI đơn giản, có thể không cần như vậy.

Firebase AI Logic hoạt động như thế nào?

Firebase AI Logic được thiết kế để cho phép ứng dụng mobile và web gọi Gemini thông qua Firebase client SDK.

Một kiến trúc đơn giản có thể như sau:

┌─────────────────────┐
│   Ứng dụng Mobile   │
│                     │
│ Firebase AI Logic   │
│ SDK                 │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Firebase AI Logic   │
│ Proxy / Gateway     │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│      Gemini         │
└─────────────────────┘

Một điểm quan trọng là:

Firebase AI Logic không đơn giản là nhúng Gemini API key vào APK hoặc IPA rồi gọi trực tiếp Gemini REST API.

Firebase AI Logic có một proxy service nằm giữa client SDK và Gemini API provider. Đây là một phần quan trọng trong security model của Firebase AI Logic.

Demo Flutter: Gọi Gemini chỉ với vài dòng code

Sau khi cấu hình Firebase cho project Flutter, phần tích hợp cơ bản khá ngắn:

import 'package:firebase_ai/firebase_ai.dart';
import 'package:firebase_core/firebase_core.dart';
import 'firebase_options.dart';

// Initialize FirebaseApp
await Firebase.initializeApp(
  options: DefaultFirebaseOptions.currentPlatform,
);

// Initialize the Gemini Developer API backend service
// Create a `GenerativeModel` instance with a model that supports your use case
final model =
      FirebaseAI.googleAI().generativeModel(model: 'gemini-3.7-flash');

// Provide a prompt that contains text
final prompt = [Content.text('Write a story about a magic backpack.')];

// To generate text output, call generateContent with the text input
final response = await model.generateContent(prompt);
print(response.text);

AI call từ client-side có thể bị lạm dụng không?

Đây thường là mối lo lớn nhất khi gọi AI trực tiếp từ client.

Nếu request được gửi từ ứng dụng mobile, attacker có thể thử:

Decompile APK
Kiểm tra network request
Reverse-engineer luồng xử lý của ứng dụng
Viết script để gửi request tự động
Tiêu thụ quota của Gemini
Tạo ra chi phí ngoài dự kiến

Firebase xử lý một phần vấn đề này bằng Firebase App Check.

Bắt đầu từ ngày 2 tháng 11 năm 2026, Firebase App Check enforcement sẽ là yêu cầu bắt buộc để sử dụng Firebase AI Logic.

Điều đó có nghĩa là request tới Firebase AI Logic phải vượt qua bước xác minh App Check, giúp loại bỏ traffic không đến từ instance hợp lệ của ứng dụng.

Về mặt khái niệm:

Ứng dụng Mobile
    │
    │ App attestation
    ▼
App Check
    │
    │ Token hợp lệ
    ▼
Firebase AI Logic
    │
    ▼
Gemini

App Check không biến mobile client thành một server đáng tin cậy.

Nó giải quyết một vấn đề khác:

Request này có thực sự đến từ một instance hợp lệ của ứng dụng mà chúng ta chấp nhận hay không?

Đây là một lớp bảo vệ quan trọng khi đưa Generative AI lại gần client hơn.

Rate limiting vẫn cần thiết

App Check không nên là lớp bảo vệ duy nhất.

Ngay cả người dùng hợp lệ cũng có thể gửi quá nhiều request.

Firebase AI Logic hỗ trợ per-user rate limit có thể cấu hình, bên cạnh rate limit và quota của Gemini provider được chọn.

Ví dụ:

Mức sử dụng dự kiến:
5–10 request / phút / người dùng

Giới hạn cấu hình:
20 request / phút / người dùng

Do đó, bảo vệ production có thể được chia thành nhiều lớp:

Request
   │
   ▼
App Check
   │
   ▼
Per-user Rate Limit
   │
   ▼
Gemini API Quota
   │
   ▼
Gemini

Đây là kiến trúc hợp lý hơn nhiều so với:

Ứng dụng Mobile
    ↓
Gemini REST API
    ↓
API key nhúng trong ứng dụng

Server Prompt Templates: Không cần nhúng prompt vào ứng dụng mobile

Một lý do phổ biến khiến developer xây AI backend là:

“System prompt có chứa các chỉ dẫn nghiệp vụ, vì vậy không thể đặt nó trong ứng dụng mobile.”

Mối lo này là hợp lý.

Ứng dụng mobile luôn có thể bị reverse-engineer ở một mức độ nào đó.

Tuy nhiên, Firebase AI Logic hiện hỗ trợ Server Prompt Templates.

Với server prompt templates, prompt, schema và model configuration được lưu ở server-side. Ứng dụng client chỉ gửi template ID cùng các input variable cần thiết.

Ví dụ, thay vì hard-code:

SYSTEM PROMPT:

Bạn là người đánh giá đào tạo bán hàng.

Hãy đánh giá cuộc hội thoại dựa trên:
- Đặt câu hỏi
- Lắng nghe
- Đề xuất
- Logic
- Chốt sale

Trả về JSON theo schema này...

bên trong ứng dụng mobile, client có thể gọi:

// Initialize the Gemini Developer API backend service.
// Create a `TemplateGenerativeModel` instance.
var _model = FirebaseAI.googleAI().templateGenerativeModel()

var customerName = 'Jane';

var response = await _model.generateContent(
        // Specify your template ID
        'my-first-template-v1-0-0',
        // Provide the values for any input variables required by your template.
        inputs: {
           'customerName': customerName,
        },
      );

var text = response?.text;
print(text);

trong khi system instruction thực tế được quản lý ở server-side.

Server prompt templates mang lại một số lợi ích rõ ràng:

Prompt không bị lộ trực tiếp trong client code
Có thể cập nhật prompt mà không cần phát hành phiên bản ứng dụng mới
Schema và model configuration có thể được quản lý phía server
Version của prompt có thể phát triển độc lập với application release

Template-only Mode

Firebase AI Logic cũng cung cấp template-only mode.

Khi tính năng này được enforce, Firebase AI Logic sẽ chặn các request không sử dụng server prompt templates. Đây là setting áp dụng trên toàn project đối với các request đi qua Firebase AI Logic.

Luồng xử lý trở thành:

Ứng dụng Mobile
    ↓
Template ID + Input
    ↓
Firebase AI Logic
    ↓
Server Prompt Template
    ↓
Gemini

thay vì:

Ứng dụng Mobile
    ↓
System Prompt tùy ý
    ↓
Gemini

Điều này thay đổi đáng kể quyết định về kiến trúc.

Trước đây, chúng ta có thể mặc định:

System Prompt nhạy cảm
        ↓
Phải dùng Backend

Với Firebase AI Logic:

System Prompt nhạy cảm
        ↓
Server Prompt Template
        ↓
Template-only Mode
        ↓
Có thể không cần Backend riêng

Firebase cũng khuyến nghị kết hợp template-only mode với input validation để giảm nguy cơ lạm dụng và prompt injection.

Server Prompt Templates không thay thế hoàn toàn Backend

Điểm phân biệt quan trọng là:

Bảo vệ prompt khác với bảo vệ một nghiệp vụ kinh doanh.

Server prompt templates phù hợp để quản lý:

System prompt
Tiêu chí đánh giá
Output schema
Model configuration
Cấu trúc prompt
Input validation
Versioning prompt

Nhưng chúng không biến ứng dụng mobile thành một trusted execution environment.

Vì vậy:

Prompt nhạy cảm
      ↓
Server Prompt Template
      ↓
Có thể không cần Backend

trong khi:

Nghiệp vụ kinh doanh nhạy cảm
      ↓
Trusted Backend

vẫn là kiến trúc đúng trong nhiều trường hợp.

Khi nào vẫn nên dùng Backend?

Firebase AI Logic có thể loại bỏ dedicated AI backend cho nhiều use case AI đơn giản.

Tuy nhiên, vẫn có những trường hợp backend là lựa chọn phù hợp hơn.

1. RAG và dữ liệu private

Nếu AI cần truy cập:

Tài liệu nội bộ
Database private
Vector Search
Enterprise Search
Dữ liệu khách hàng
Knowledge Base của công ty

backend thường là nơi phù hợp cho retrieval pipeline.

Ví dụ:

Mobile
   ↓
Backend
   ↓
Retriever
   ↓
Vector DB / Search
   ↓
Gemini

Server prompt template không phải là RAG engine.

2. AI workflow phức tạp

Nếu AI workflow trông như sau:

User Request
     ↓
Classifier
     ↓
Planner
     ↓
Retriever
     ↓
Tool A
     ↓
Tool B
     ↓
Validator
     ↓
Gemini

thì orchestration framework như LangGraph vẫn mang lại giá trị thực sự.

Các workflow này thường cần:

State management
Retry
Branching
Tool execution
Multi-step processing
Human approval
Long-running job

Đây không còn là một lần gọi model đơn giản.

3. Nghiệp vụ kinh doanh cần độ tin cậy cao

Nếu AI có thể kích hoạt các thao tác như:

Tạo đơn hàng
Hủy đơn hàng
Hoàn tiền
Thay đổi quyền
Phê duyệt giao dịch
Cập nhật record private

các thao tác đó cần authorization đáng tin cậy ở server-side.

Ví dụ:

Người dùng:
“Hoàn tiền đơn hàng #123”
       ↓
AI
       ↓
Kiểm tra điều kiện hoàn tiền
       ↓
Kiểm tra trạng thái thanh toán
       ↓
Thực hiện hoàn tiền

Backend vẫn nên chịu trách nhiệm về:

Authentication
Authorization
Business validation
Transaction integrity
Audit logging

AI response không nên tự trở thành một quyết định authorization.

4. Private API và server-side tool

Nếu model cần gọi:

CRM
ERP
Payment Gateway
Internal API
Database
Email Service
Admin API

thì vẫn cần backend hoặc trusted server-side tool layer.

API credential và privileged operation không nên tồn tại trong ứng dụng mobile.

5. Compliance, auditing và governance

Một số hệ thống cần quản lý tập trung:

Log AI request
Prompt history
Audit output
Moderation
Cost allocation
User-level usage control
Compliance policy
Data retention policy

Trong các trường hợp này, dedicated backend hoặc AI gateway vẫn có thể là kiến trúc tốt hơn.

Server Prompt Templates vẫn có giới hạn

Server Prompt Templates hiện là một tính năng ở trạng thái Preview, nghĩa là tính năng này có thể tiếp tục thay đổi và có thể không được áp dụng SLA hoặc deprecation policy thông thường.

Firebase cũng tài liệu hóa các capability chưa được Server Prompt Templates hỗ trợ đầy đủ. Ví dụ, Gemini Live model hiện chưa được hỗ trợ bởi Server Prompt Templates.

Vì vậy, nếu ứng dụng phụ thuộc vào các capability chưa được template hỗ trợ, việc bật template-only mode có thể làm những request đó bị block.

Điểm này cần được kiểm tra trước khi enforce template-only mode trong production.

Lợi ích của việc bỏ Dedicated AI Backend

Với use case AI đơn giản, lợi ích lớn nhất không nhất thiết là chi phí hạ tầng.

Lợi ích lớn hơn là giảm độ phức tạp của kiến trúc.

Kiến trúc truyền thống

Mobile
  ↓
API Gateway
  ↓
Backend
  ↓
AI SDK / Framework
  ↓
Gemini

Team phải duy trì:

Ứng dụng Mobile
+
Backend Repository
+
CI/CD
+
Runtime
+
Infrastructure
+
Secrets
+
Monitoring
+
Scaling
+
AI Integration

Firebase AI Logic

Mobile
  ↓
Firebase AI Logic
  ↓
Gemini

Hoặc khi cần bảo vệ prompt:

Mobile
  ↓
Firebase AI Logic
  ↓
Server Prompt Template
  ↓
Gemini

Team có thể tập trung nhiều hơn vào:

Ứng dụng Mobile
+
Firebase Configuration
+
Prompt Templates
+
Tính năng AI

Nếu backend trước đây chỉ tồn tại để:

Nhận Request
       ↓
Gắn System Prompt
       ↓
Gọi Gemini
       ↓
Trả Response

thì Server Prompt Templates làm giảm đáng kể lý do phải duy trì backend đó.

Ít Network Hop hơn và ít thứ phải vận hành hơn

Kiến trúc truyền thống:

Mobile
 → API Gateway của chúng ta
 → Backend của chúng ta
 → Gemini
 → Backend của chúng ta
 → Mobile

Firebase AI Logic:

Mobile
 → Firebase AI Logic
 → Gemini
 → Mobile

Firebase vẫn có hạ tầng nằm giữa client và Gemini.

Khác biệt không phải là:

“Không còn server nữa.”

Khác biệt là:

Team không còn phải tự xây dựng và vận hành một dedicated AI proxy server.

Điều này giúp giảm:

Thiết lập hạ tầng
Deployment
Monitoring
Trách nhiệm scaling
Bảo trì backend

Còn pricing thì sao?

Firebase AI Logic hỗ trợ Gemini Developer API với cả free tier và paid tier.

Paid tier yêu cầu Firebase project phải được liên kết với Cloud Billing, đồng nghĩa với việc sử dụng gói Blaze pay-as-you-go.

Điểm quan trọng là:

Không cần backend không có nghĩa là không cần quản trị chi phí.

Firebase cung cấp công cụ để theo dõi cost, usage và các metric liên quan đến Firebase AI Logic.

Một cấu hình production vẫn nên kết hợp:

App Check
+
Per-user Rate Limits
+
Gemini API Quotas
+
Budget Alerts
+
Token / Usage Monitoring

Khi nào Firebase AI Logic phù hợp?

Một tính năng AI có flow như sau là ứng viên phù hợp:

User Input
    ↓
Prompt
    ↓
Gemini
    ↓
Response

Ví dụ:

Chatbot đơn giản
Rewrite
Translation
Summarization
Classification
Grammar correction
Content suggestion
Image understanding
Tương tác multimodal cơ bản

Nếu prompt cần được bảo vệ:

User Input
    ↓
Server Prompt Template
    ↓
Gemini
    ↓
Response

Firebase AI Logic vẫn có thể xử lý mà không cần dedicated backend.

Một cách thực tế hơn để phân loại kiến trúc AI

Thay vì bắt đầu mọi tính năng AI bằng:

LangChain
+
LangGraph
+
Vector Database
+
Redis
+
Backend API
+
Worker

chúng ta có thể chọn kiến trúc dựa trên độ phức tạp thực tế.

Level 1 — Direct AI Feature

Mobile
   ↓
Firebase AI Logic
   ↓
Gemini

Phù hợp cho:

Rewrite
Summary
Simple Chat
Classification

Level 1.5 — Protected Prompt

Mobile
   ↓
Firebase AI Logic
   ↓
Server Prompt Template
   ↓
Gemini

Có thể kết hợp với:

App Check
+
Template-only Mode
+
Rate Limiting

Phù hợp cho:

System prompt do server quản lý
Hướng dẫn đánh giá
Hành vi AI được tiêu chuẩn hóa
Prompt configuration được quản lý độc lập với application release

Level 2 — AI với Trusted Business Logic

Mobile
   ↓
Backend
   ↓
Gemini

Phù hợp cho:

Private API
Business authorization
Sensitive operation
Centralized auditing

Level 3 — RAG

Mobile
   ↓
Backend
   ↓
Retriever
   ↓
Vector DB / Search
   ↓
Gemini

Phù hợp cho:

Trợ lý tri thức nội bộ
Q&A tài liệu doanh nghiệp
Truy xuất knowledge private

Level 4 — AI Workflow / Agent

Mobile
   ↓
Backend
   ↓
LangGraph / Agent Workflow
   ├── Planner
   ├── Retriever
   ├── Tools
   ├── APIs
   └── Validator
          ↓
        Gemini

Phù hợp cho:

AI Agent
Workflow phức tạp
Multi-step automation
Hệ thống AI sử dụng nhiều tool

Đừng dùng kiến trúc Level 4 cho một bài toán Level 1

Generative AI đã mang đến nhiều công nghệ:

LangChain
LangGraph
Vector Databases
Embeddings
Rerankers
Agent Frameworks
MCP
AI Gateways

Tất cả đều giải quyết những vấn đề thực tế.

Nhưng việc chúng tồn tại không có nghĩa là mọi tính năng AI đều cần chúng.

Nếu yêu cầu thực tế chỉ là:

Input
  ↓
Prompt
  ↓
Model
  ↓
Output

thì kiến trúc cũng có thể đơn giản tương ứng.

Kết luận

Firebase AI Logic giúp việc đưa tính năng Generative AI vào ứng dụng mobile và web trở nên dễ dàng hơn bằng cách cung cấp một tập hợp capability có thể sử dụng trực tiếp từ client:

Firebase AI Logic SDK
+
App Check
+
Per-user Rate Limiting
+
Server Prompt Templates
+
Template-only Mode

Server prompt templates cho phép prompt, schema và configuration được giữ ở server-side thay vì hard-code trong ứng dụng mobile. Template-only mode còn có thể bắt buộc các request đi qua Firebase AI Logic phải sử dụng các template đó.

Điều này không có nghĩa Firebase AI Logic thay thế mọi backend.

Backend vẫn quan trọng khi AI cần:

Dữ liệu private
RAG
Trusted business operation
Private API
Complex orchestration
Compliance hoặc centralized auditing

Thông điệp chính là:

Hãy dùng kiến trúc đơn giản nhất nhưng vẫn đáp ứng được các yêu cầu về security, business và operation.

Trước khi thêm API Gateway, Backend Service, LangChain, LangGraph, Redis, Vector Database hoặc Agent Framework vào một tính năng AI đơn giản, có lẽ chúng ta chỉ cần hỏi:

“Tính năng AI này có thực sự cần backend không?”

Phát hành tính năng AI nhanh hơn với Firebase AI Logic

Kiến trúc truyền thống

Firebase AI Logic hoạt động như thế nào?

Demo Flutter: Gọi Gemini chỉ với vài dòng code

AI call từ client-side có thể bị lạm dụng không?

Rate limiting vẫn cần thiết

Server Prompt Templates: Không cần nhúng prompt vào ứng dụng mobile

Template-only Mode

Server Prompt Templates không thay thế hoàn toàn Backend

Khi nào vẫn nên dùng Backend?

1. RAG và dữ liệu private

2. AI workflow phức tạp

3. Nghiệp vụ kinh doanh cần độ tin cậy cao

4. Private API và server-side tool

5. Compliance, auditing và governance

Server Prompt Templates vẫn có giới hạn

Lợi ích của việc bỏ Dedicated AI Backend

Kiến trúc truyền thống

Firebase AI Logic

Ít Network Hop hơn và ít thứ phải vận hành hơn

Còn pricing thì sao?

Khi nào Firebase AI Logic phù hợp?

Một cách thực tế hơn để phân loại kiến trúc AI

Level 1 — Direct AI Feature

Level 1.5 — Protected Prompt

Level 2 — AI với Trusted Business Logic

Level 3 — RAG

Level 4 — AI Workflow / Agent

Đừng dùng kiến trúc Level 4 cho một bài toán Level 1

Kết luận

Tài liệu tham khảo

Bài viết liên quan

AI dựng mô hình 3D từ bản vẽ ba hình chiếu — dùng SDF để nắm “hình dạng sơ bộ”

Khi dạy robot đấu sumo, chúng lại thành thạo lariat, điệu nhảy Cossack và không chiến

Phát triển Agent Skill hỗ trợ báo giá từ các yêu cầu mơ hồ