Một AI app builder có thể xử lý cả React và Flutter không?

Xây dựng ứng dụng web React và ứng dụng di động Flutter bằng hai công cụ AI riêng biệt có vẻ hợp lý cho đến khi quy tắc dùng chung đầu tiên thay đổi. Khi đó, một công cụ cập nhật luồng trên trình duyệt, công cụ kia vẫn giữ giả định của hôm qua, còn cơ sở dữ liệu lại chấp nhận cả hai phiên bản. Sự phân chia công việc tưởng như rõ ràng đã biến thành việc tích hợp.

Với đa số đội ngũ nhỏ, một AI app builder là lựa chọn tốt hơn, miễn là nó có thể tạo các codebase React, Flutter và backend riêng, cho phép truy cập mã nguồn, đồng thời để mỗi ứng dụng phát hành độc lập. «Một công cụ» nên có nghĩa là một ngữ cảnh lập kế hoạch và một hợp đồng hệ thống. Nó không nên có nghĩa là một ứng dụng khổng lồ, một lịch phát hành chung, hay cố dùng chung mã giao diện giữa TypeScript và Dart.

Phương án khác vẫn có thể hiệu quả. Hai công cụ chuyên biệt hợp lý khi các đội web và di động riêng đã sở hữu ứng dụng của mình, hợp đồng API được quản trị bên ngoài cả hai công cụ, và tổ chức chấp nhận chi phí phối hợp. Nếu thiếu các điều kiện đó, công cụ thứ hai sẽ thêm một ranh giới mà ai đó phải theo dõi trong suốt vòng đời sản phẩm.

Bạn cần một AI app builder hay hai công cụ?

Chọn một công cụ khi cùng một sản phẩm, backend, mô hình dữ liệu và hệ thống danh tính phục vụ cả hai ứng dụng. Chỉ chọn hai công cụ khi chuyên môn hóa theo nền tảng đáng giá hơn ngữ cảnh dùng chung và bạn có người được giao bảo trì ranh giới đó.

Các điểm số dưới đây giả định một nhà sáng lập hoặc đội ngũ sản phẩm nhỏ, một API Go, một cơ sở dữ liệu PostgreSQL, một ứng dụng web React và một ứng dụng di động Flutter. Điểm 5 nghĩa là cách tiếp cận này hỗ trợ vấn đề đó mà hầu như không cần phối hợp thủ công. Điểm 1 nghĩa là đội ngũ phải tự xây dựng và giám sát mối kết nối còn thiếu.

Các con số này là công cụ hỗ trợ quyết định, không phải đánh giá sản phẩm. Nếu một ứng viên không xuất được mã nguồn, không mô hình hóa được backend thực tế, hoặc ép web và di động vào một lần triển khai, hãy giảm điểm mạnh. Tương tự, thiết lập hai công cụ có thể được cộng điểm khi một đội nền tảng trưởng thành sở hữu hợp đồng API, dịch vụ danh tính, chính sách phát hành và kiểm thử tương thích.

Đừng đếm số màn hình hay câu lệnh. Hãy đếm các nơi có quyền quyết định. Bạn cần một nơi quyết định cho từng sự thật nghiệp vụ, một hợp đồng API, một chính sách danh tính và một chuỗi migration. React và Flutter là bên sử dụng những quyết định đó.

Logic nghiệp vụ dùng chung phải nằm phía sau cả hai ứng dụng

Đặt quyền hạn, quy tắc giá, trạng thái chuyển đổi của quy trình, hạn mức và các kiểm tra bảo vệ dữ liệu được lưu trong backend. React và Flutter có thể lặp lại những kiểm tra nhẹ để phản hồi nhanh, nhưng API phải đưa ra quyết định cuối cùng.

Các đội ngũ thường gọi hai thứ khác nhau là «logic dùng chung». Mã nguồn dùng chung nghĩa là cả hai ứng dụng nhập cùng một phần triển khai. Hành vi nghiệp vụ dùng chung nghĩa là cả hai ứng dụng nhận cùng một kết quả từ một nơi có thẩm quyền. React và Flutter dùng các ngôn ngữ cũng như mô hình giao diện khác nhau, nên ép chúng dùng chung phần triển khai thường tạo ra một tầng trừu tượng thứ ba khó hiểu hơn cả hai ứng dụng. Thay vào đó, hãy chia sẻ hành vi qua API.

Giả sử một đơn hàng chỉ có thể chuyển từ draft sang submitted khi có ít nhất một dòng hàng và tài khoản còn hoạt động. Nếu mỗi ứng dụng sở hữu quy tắc đó, chẳng mấy chốc sẽ có bốn phiên bản: kiểm tra biểu mẫu của React, trạng thái nút của Flutter, trình xử lý gửi trên web và trình xử lý gửi trên di động. Mọi thay đổi chính sách phải được đưa đến mọi nơi trước khi bất kỳ ứng dụng nào phát hành. Một bản di động cũ có thể vẫn được cài trong nhiều tháng.

Backend nên cho biết hành động nào được phép và thực thi lại quy tắc khi nhận hành động:

{
  "order_id": "ord_4821",
  "status": "draft",
  "allowed_actions": ["submit"],
  "version": 7
}

Ứng dụng quyết định cách hiển thị hành động. Máy chủ quyết định liệu submit có hợp lệ ở phiên bản 7 hay không. Nếu một yêu cầu khác thay đổi đơn hàng trước, máy chủ trả về xung đột thay vì để người ghi cuối cùng âm thầm thắng.

Tài liệu React khuyến nghị một nguồn chân lý duy nhất cho mỗi phần trạng thái. Hướng dẫn đó áp dụng trong cây giao diện trên trình duyệt, không phải cho toàn bộ sản phẩm có nhiều ứng dụng. Cha chung của một ứng dụng web và ứng dụng di động là hợp đồng backend. Đưa trạng thái nghiệp vụ lâu dài về đó cũng tuân theo cùng ý tưởng ở ranh giới hệ thống.

Hướng dẫn kiến trúc của Flutter tách view và view model khỏi repository và service. Hướng dẫn này cũng nói service bao bọc các điểm cuối API bên ngoài, còn repository chuyển đổi kết quả của chúng thành mô hình miền. Đó là ranh giới tốt phía ứng dụng. Đừng hiểu repository như quyền được xây dựng lại chính sách máy chủ bằng Dart. Repository di động có thể lưu đệm, thử lại và ánh xạ dữ liệu, nhưng không được trở thành nơi có thẩm quyền thứ hai về việc đơn hàng có thể được gửi hay không.

Một số logic đúng là nên giữ riêng theo ứng dụng: định dạng đầu vào, cách hiển thị ngoại tuyến, điều hướng, hoạt ảnh và xử lý quyền thiết bị. Ứng dụng di động có thể xếp hàng một bản nháp khi ngoại tuyến, còn ứng dụng web lưu ngay. Khi kết nối trở lại, cả hai phải gửi cùng một lệnh đến cùng một quy tắc máy chủ.

PostgreSQL phải nằm sau một API

Cả gói React lẫn ứng dụng Flutter đều không nên kết nối trực tiếp đến PostgreSQL. Chúng là các ứng dụng phân tán, nơi người dùng có thể xem xét, sao chép và sửa đổi mã cùng chi tiết kết nối.

Tài liệu PostgreSQL mô tả xác thực ứng dụng khách là việc máy chủ cơ sở dữ liệu quyết định liệu một ứng dụng khách có thể kết nối với tư cách người dùng cơ sở dữ liệu được yêu cầu hay không. Cơ chế đó bảo vệ kết nối cơ sở dữ liệu. Nó không hiểu rằng Alice được sửa đơn hàng 42 nhưng không được sửa đơn hàng 43, hoặc một bản di động cũ không được dùng trạng thái chuyển đổi quy trình vừa thêm. Phân quyền ứng dụng phải nằm trong API.

Kết nối trực tiếp từ React đặc biệt không thể chấp nhận vì trình duyệt sẽ cần truy cập mạng đến cơ sở dữ liệu và thông tin đăng nhập phải có trong mã được tải xuống. Đóng gói mật khẩu trong Flutter chỉ che giấu nó cho đến khi ai đó trích xuất ứng dụng. Bảo mật theo hàng có thể tăng cường phòng vệ bên trong PostgreSQL, nhưng không biến ứng dụng khách không đáng tin thành một bên ngang hàng an toàn với cơ sở dữ liệu. Bạn vẫn cần các điểm cuối ổn định, kiểm soát lưu lượng, giới hạn đầu vào, ngữ cảnh kiểm toán và nơi để phát triển schema mà không làm hỏng các bản đã cài.

Hãy dùng cấu trúc có một ranh giới ứng dụng công khai:

React client  \
               -> HTTPS API -> domain rules -> PostgreSQL
Flutter client /

Cấp cho API một vai trò cơ sở dữ liệu bị giới hạn. Giữ thông tin đăng nhập migration ngoài ứng dụng đang chạy. Hãy chạy migration như một tác vụ triển khai riêng, với quy trình xem xét và khôi phục riêng. Cách phân chia này giới hạn những gì một tiến trình API bị xâm nhập có thể làm và ngăn cả hai ứng dụng biết thông tin đăng nhập cơ sở dữ liệu.

Hai công cụ AI đôi khi tạo ra hai backend vì mỗi công cụ muốn có một dự án hoàn chỉnh. Hãy từ chối kết quả đó trừ khi hai dịch vụ là một cách chia miền có chủ đích. Một backend web và một backend di động cùng ghi vào các bảng giống nhau sẽ tạo ra phân quyền trùng lặp, giao dịch không nhất quán và hai nơi phải sửa cho mỗi thay đổi schema. Backend mỏng dành cho từng giao diện có thể hợp lý khi mỗi ứng dụng cần hình dạng phản hồi khác nhau, nhưng các bộ chuyển đổi đó nên gọi cùng một dịch vụ miền thay vì ghi đè lên nó.

Hãy kiểm tra ranh giới bằng cách đơn giản nhưng hiệu quả. Tìm trong các kho mã React và Flutter được tạo chuỗi kết nối PostgreSQL, biến máy chủ cơ sở dữ liệu, driver SQL và thông tin đăng nhập dịch vụ đặc quyền. Chỉ cần tìm thấy bất kỳ thứ nào trong mã ứng dụng là không đạt vòng xem xét kiến trúc. Cấu hình ứng dụng đúng chỉ chứa URL cơ sở của API, cấu hình danh tính công khai và các cài đặt tính năng không bí mật.

Migration cơ sở dữ liệu cũng cần tương thích ngược. Trước hết hãy thêm một cột cho phép rỗng hoặc một bảng mới, triển khai mã xử lý được cả hai dạng, bổ sung dữ liệu nếu cần, chuyển cách đọc, rồi chỉ xóa trường cũ khi các ứng dụng còn được hỗ trợ không phụ thuộc vào nó nữa. Việc phân phối di động khiến khoảng thời gian cuối này dài hơn nhiều so với phần lớn đội ngũ chỉ làm web nghĩ.

Xác thực có một nơi có thẩm quyền và hai bộ điều hợp ứng dụng

Dùng một bên phát hành danh tính, một hồ sơ người dùng và một chính sách phân quyền phía máy chủ, sau đó triển khai bộ điều hợp phiên riêng cho trình duyệt và di động. Xác thực chứng minh ai đang gọi. Phân quyền quyết định người gọi đó được làm gì. Trộn lẫn hai việc này dẫn đến các điểm cuối chấp nhận token hợp lệ rồi tin rằng ứng dụng sẽ tự ẩn các hành động bị cấm.

Ứng dụng React thường xử lý chuyển hướng trên trình duyệt, cookie hoặc token, bảo vệ yêu cầu liên trang và các thẻ có thể tranh chấp khi làm mới. Flutter phải xử lý deep link, việc ứng dụng bị tạm dừng, lưu trữ trên thiết bị và callback của hệ điều hành. Những khác biệt đó lý giải cho mã ứng dụng riêng. Chúng không lý giải cho thư mục người dùng riêng hay ý nghĩa khác nhau của các vai trò.

OWASP Mobile Application Security Cheat Sheet khuyên không nhúng cứng thông tin đăng nhập và nên dùng token truy cập có thể thu hồi, được lưu bằng cơ chế bảo mật riêng của từng nền tảng. Hãy làm theo nguyên tắc này, nhưng nhớ rõ lưu trữ an toàn có thể và không thể làm gì. Nó giảm nguy cơ token bị lấy dễ dàng từ tệp. Nó không thể khiến một thiết bị đã bị xâm nhập trở nên đáng tin, nên API vẫn kiểm tra hạn dùng, đối tượng nhận, bên phát hành, trạng thái tài khoản và quyền trong mọi thao tác được bảo vệ.

Hãy viết hợp đồng xác thực trước khi yêu cầu bất kỳ ứng dụng nào triển khai màn hình:

Access token: short lived, sent to the API
Refresh mechanism: rotated or invalidated by the identity system
Logout: ends the local session and revokes server-side refresh authority
Account disabled: API rejects new operations even if a client still shows cached data
Role changed: next authorized request uses current server policy

Bài kiểm tra cho thấy rõ nhất không phải đăng nhập thành công. Hãy vô hiệu hóa một tài khoản khi cả hai ứng dụng đang mở. Yêu cầu được bảo vệ tiếp theo từ mỗi ứng dụng phải thất bại theo cùng một cách, dữ liệu riêng cục bộ phải được xóa theo chính sách và không ứng dụng nào được lặp vô tận để làm mới. Sau đó đổi vai trò và xác minh một màn hình cũ không thể thực hiện hành động cũ.

Tránh đặt sự thật về vai trò trong claim token lâu hơn thời gian bạn có thể chấp nhận phân quyền cũ. Claim có thể giúp giao diện hiển thị nhanh, nhưng máy chủ nên tham chiếu chính sách hiện tại cho những thao tác nhạy cảm. Nếu thay đổi vai trò phải có hiệu lực ngay, token tự chứa có thời hạn dài mang vai trò cũ sẽ đi ngược yêu cầu đó.

Một công cụ được chấm 4 thay vì 5 ở đây vì ngữ cảnh dùng chung không loại bỏ công việc bảo mật riêng theo nền tảng. Công cụ có thể tạo cả hai bộ điều hợp, nhưng con người vẫn cần kiểm thử chuyển hướng trình duyệt, deep link di động, tranh chấp khi làm mới, sai lệch đồng hồ, thu hồi và hành vi khôi phục thiết bị.

Một hợp đồng giữ React và Flutter nhất quán

Hãy coi mô tả API là đầu vào xây dựng cho cả hai ứng dụng và là cam kết tương thích với các phiên bản đã phát hành. Một câu lệnh bằng văn xuôi không phải hợp đồng vì hai lần tạo có thể hiểu cùng một câu theo cách khác nhau.

OpenAPI là lựa chọn thực tế cho API HTTP. Hãy xác định trường yêu cầu, trường phản hồi, nội dung lỗi, yêu cầu xác thực và mã định danh thao tác ổn định. Tạo hoặc tự duy trì các ứng dụng khách TypeScript và Dart mỏng từ tài liệu đó, rồi giữ hành vi ứng dụng trong hook React và repository Flutter thông thường. Mã ứng dụng khách được tạo nên có thể thay thế, đừng chôn các quyết định sản phẩm vào đó.

Đoạn này làm rõ xung đột phiên bản:

/orders/{orderId}/submit:
  post:
    operationId: submitOrder
    requestBody:
      required: true
      content:
        application/json:
          schema:
            type: object
            required: [expected_version]
            properties:
              expected_version:
                type: integer
    responses:
      "200":
        description: Order submitted
      "409":
        description: Order changed since the client loaded it

Nguồn chân lý là hành vi máy chủ cùng hợp đồng đã được kiểm tra. Các kiểu TypeScript và Dart được tạo là những hình chiếu. Nếu một công cụ sửa kiểu ở ứng dụng mà không thay hợp đồng, quy trình xây dựng nên ghi đè hoặc từ chối thay đổi đó.

Kiểm thử hợp đồng nên kiểm tra những hành vi mà schema tĩnh không thể diễn đạt. Gửi đơn hàng trống và mong nhận cùng mã lỗi từ yêu cầu do cả hai ứng dụng tạo. Gửi lại một yêu cầu với expected_version cũ và mong nhận 409. Gửi giá trị enum không xác định vào fixture của ứng dụng cũ và kiểm tra rằng nó xử lý an toàn thay vì bị văng.

Ưu tiên thay đổi API theo hướng bổ sung. Các trường phản hồi tùy chọn mới thường an toàn khi ứng dụng bỏ qua trường không biết. Xóa một trường, biến trường tùy chọn thành bắt buộc hoặc dùng lại giá trị enum với ý nghĩa mới có thể làm hỏng bản di động đã cài. Chỉ phiên bản hóa điểm cuối khi không thể giữ nguyên ý nghĩa. Việc tăng phiên bản theo thói quen chỉ chuyển gánh nặng tương thích sang nhiều thư mục hơn.

Có một khuyến nghị phổ biến là chia sẻ mô hình miền trong gói đa nền tảng. Nghe có vẻ hiệu quả vì đơn hàng, tài khoản và hóa đơn xuất hiện ở cả hai ứng dụng. Trên thực tế, gói TypeScript và Dart vẫn cần cách tuần tự hóa, xử lý null, xử lý ngày tháng và công cụ phát hành riêng. Hãy tạo dạng dữ liệu truyền tải từ một hợp đồng, rồi để mỗi ứng dụng ánh xạ chúng sang mô hình giao diện cục bộ. Các định nghĩa dùng chung rất hữu ích. Mô hình chạy dùng chung bị ép buộc thì không.

Hợp đồng cũng làm hai công cụ khả thi hơn. Nó tạo cho mỗi công cụ một ranh giới mà chúng không thể tùy tiện diễn giải lại. Nhưng ai đó ngoài cả hai phiên tạo phải sở hữu thay đổi hợp đồng, kiểm tra tương thích và ghi chú phát hành. Nếu không ai có việc đó, hợp đồng sẽ chậm hơn các phần triển khai.

Lịch phát hành nên giữ độc lập

Hãy phát hành ứng dụng web, ứng dụng di động và API theo lịch riêng ngay cả khi một công cụ tạo cả ba. Việc tạo có phối hợp không đòi hỏi triển khai có phối hợp.

React thường có thể đến tay người dùng trong vài phút sau triển khai. Bản di động phải qua kiểm duyệt kho ứng dụng và người dùng có thể hoãn cập nhật. Vì vậy API phải hỗ trợ bản web hiện tại và mọi phiên bản di động còn trong thời gian hỗ trợ của đội ngũ. Kế hoạch phát hành cho rằng mọi ứng dụng sẽ cập nhật cùng lúc sẽ thất bại ngay ở lần kiểm duyệt bị chậm hoặc phát hành theo giai đoạn đầu tiên.

Dùng ma trận tương thích cho từng thay đổi:

Các từ trong ô quan trọng hơn số phiên bản. Chúng buộc đội ngũ phải nói rõ ứng dụng cũ thực sự làm gì. Hãy giữ ma trận trong kế hoạch thay đổi và chuyển các khẳng định trong đó thành kiểm thử khi có thể.

Một đợt phát hành tính năng an toàn thường theo thứ tự này:

1. Thêm cấu trúc cơ sở dữ liệu và hành vi API tương thích ngược.
2. Phát hành ứng dụng hiểu phản hồi mới nhưng chưa hiển thị tính năng.
3. Theo dõi lỗi và tín hiệu tương thích trước khi bật ghi dữ liệu.
4. Bật tính năng bằng khả năng do máy chủ kiểm soát hoặc cài đặt tài khoản.
5. Chỉ xóa các đường cũ sau khi hết thời gian hỗ trợ.

Cờ tính năng hữu ích để kiểm soát mức độ hiển thị, không phải để sửa schema không tương thích. Nếu ứng dụng cũ bị văng khi phân tích trường hoặc enum bắt buộc mới, tắt một nút sau khi khởi động sẽ không cứu được nó. Khả năng tương thích phải nằm trong thiết kế payload.

Hai công cụ có thể mạnh về đóng gói theo nền tảng. Một công cụ tập trung di động có thể hiểu metadata kho ứng dụng và quyền thiết bị tốt hơn, còn công cụ tập trung web có thể xử lý triển khai trình duyệt tốt. Chỉ chấm điểm phát hành cao hơn cho cách dùng hai công cụ nếu các thế mạnh đó lớn hơn công sức bổ sung để phối hợp mức sẵn sàng của API, mức hiển thị tính năng và thời gian hỗ trợ.

Hãy để mã định danh bản phát hành xuất hiện trong nhật ký và báo cáo lỗi. Mỗi yêu cầu API nên mang tên ứng dụng và mã định danh bản dựng không bí mật để người vận hành phân biệt lỗi hồi quy trên trình duyệt với hành vi của bản di động cũ. Đừng tin mã định danh đó cho phân quyền vì ứng dụng có thể giả mạo nó.

Hoàn tác có ba ý nghĩa khác nhau

Hoàn tác ứng dụng, hoàn tác máy chủ và hoàn tác dữ liệu giải quyết các lỗi khác nhau, nên cần quy trình riêng. Coi chúng như một nút «hoàn tác» duy nhất là cách một bản phát hành có thể khôi phục trở thành mất dữ liệu.

Triển khai React thường có thể chuyển lưu lượng về một artifact trước đó. Hoàn tác trên di động thường có nghĩa là dừng phát hành theo giai đoạn và gửi một bản sửa, còn thiết bị đã cập nhật có thể vẫn giữ phiên bản lỗi. API phải chịu được cả hai phiên bản trong khoảng thời gian đó.

Mã máy chủ chỉ có thể hoàn tác nếu cơ sở dữ liệu vẫn tương thích với bản nhị phân cũ. Migration theo hướng bổ sung thường cho phép điều này. Migration đổi tên cột tại chỗ, viết lại ý nghĩa hoặc xóa dữ liệu thì có thể không. Hãy dùng migration mở rộng rồi thu gọn: thêm biểu diễn mới, để cả hai phiên bản mã hoạt động, chuyển dữ liệu, chuyển cách đọc và xóa biểu diễn cũ sau.

Hoàn tác dữ liệu là phần nguy hiểm. Khôi phục ảnh chụp nhanh cơ sở dữ liệu sẽ xóa các ghi chép hợp lệ được tạo sau thời điểm chụp. Với nhiều sự cố production, sửa tiếp sẽ an toàn hơn: triển khai mã đã sửa, xác định các hàng bị ảnh hưởng bằng truy vấn kiểm toán và áp dụng thay đổi bù trừ có phạm vi hẹp. Ảnh chụp nhanh bảo vệ trước thảm họa, nhưng không phải thay thế tùy tiện cho migration có thể đảo ngược.

Hãy xem một lỗi điển hình. Bản triển khai API thêm delivery_window là trường bắt buộc. Ứng dụng web mới gửi nó. Bản di động đang chờ duyệt thì không. Đội ngũ đổi cột cơ sở dữ liệu thành NOT NULL, rồi các lần gửi từ di động cũ bắt đầu trả lỗi máy chủ. Chỉ hoàn tác ứng dụng web không thay đổi gì. Chỉ hoàn tác API có thể thất bại nếu bản nhị phân cũ không đọc được schema mới. Khôi phục toàn bộ cơ sở dữ liệu sẽ loại bỏ các đơn hàng không liên quan.

Cách khôi phục đúng là để API chấp nhận trường còn thiếu, gán giá trị mặc định đã ghi rõ hoặc hoãn chuyển đổi, rồi trả trường đó là tùy chọn đến khi hỗ trợ di động đủ rộng. Khi đó đội ngũ có thể sửa các bản ghi bị ảnh hưởng mà không quay lùi các ghi chép không liên quan. Lỗi ban đầu không phải thiếu nút hoàn tác. Nó là một chuỗi không tương thích.

Với mọi thay đổi, hãy viết bốn dòng này trước khi triển khai:

Web rollback: artifact and routing action
Mobile containment: rollout stop, affected builds, fixed build path
API rollback: compatible binary and schema range
Data repair: query, owner, backup point, and forward correction

Một công cụ giúp ích khi ảnh chụp nhanh và lịch sử lập kế hoạch của nó bao quát thay đổi liên quan, nhưng hãy kiểm tra phạm vi. Ảnh chụp nhanh mã nguồn, artifact đã triển khai và bản sao lưu PostgreSQL là các tài sản khác nhau. Một bài kiểm tra hoàn tác đáng tin cậy sẽ khôi phục từng tài sản trong môi trường dùng một lần và chứng minh ứng dụng cũ vẫn hoàn thành luồng ghi dữ liệu chính.

Hai công cụ làm tăng trách nhiệm tích hợp

Hai công cụ không giảm một nửa việc bảo trì. Chúng tạo ra hai lịch sử tạo mã, hai bộ giả định và một bề mặt tích hợp nằm ngoài cả hai.

Tháng đầu có thể trông nhanh hơn vì mỗi công cụ tạo ra mã quen thuộc với nền tảng. Chi phí xuất hiện khi thay đổi vượt qua ranh giới: đổi tên trường, sửa quyền, thêm trạng thái tài khoản, đổi hành vi đăng xuất hoặc ngừng hỗ trợ điểm cuối. Mỗi câu lệnh phải bao gồm hợp đồng hiện tại và hệ quả từ trạng thái phát hành của ứng dụng kia. Bỏ sót một chi tiết sẽ tạo ra mã nghe hợp lý, biên dịch được nhưng vẫn vi phạm hành vi sản phẩm.

Mẫu lỗi có thể dự đoán được. Công cụ web thêm archived vào enum và hiển thị đúng. Công cụ di động vẫn coi giá trị lạ là lỗi phân tích. API triển khai trước, một bản ghi đã lưu trữ xuất hiện trong danh sách của người dùng, và màn hình di động ngừng tải toàn bộ bản ghi. Mỗi thay đổi cục bộ đều có vẻ hợp lý. Không ai kiểm thử tổ hợp khác phiên bản.

Việc bảo trì cần một người sở hữu và một gói thay đổi lặp lại được:

• Thay đổi hành vi và quy tắc máy chủ sở hữu nó
• Phần khác biệt API và migration
• Các trường hợp chấp nhận của React
• Các trường hợp chấp nhận của Flutter
• Thứ tự phát hành và giới hạn hoàn tác

Gói đó cũng hữu ích với một công cụ, nhưng một ngữ cảnh lập kế hoạch có thể giữ nó gắn với toàn bộ thay đổi. Với hai công cụ, đội ngũ phải sao chép nó qua lại, ghi lại cả hai kết quả và dung hòa các chỉnh sửa mâu thuẫn. Tự động hóa có thể phát hiện schema bị trôi lệch, nhưng không thể quyết định cách diễn giải nào đúng với sản phẩm.

Đừng cho rằng xuất mã nguồn sẽ chấm dứt sự phụ thuộc vào công cụ. Mã xuất ra giúp bạn nắm quyền quản lý, điều này quan trọng, nhưng khả năng bảo trì phụ thuộc vào cấu trúc dễ đọc, kiểm thử, lựa chọn phụ thuộc, hướng dẫn xây dựng và đường đi rõ ràng để chỉ tạo lại phần đã đổi. Hãy xem dự án được tạo như thể công cụ biến mất vào ngày mai. Một lập trình viên React đủ năng lực có thể phát hành ứng dụng web, lập trình viên Flutter có thể xây dựng ứng dụng di động và lập trình viên backend có thể migration PostgreSQL mà không cần lịch sử trò chuyện ban đầu không?

Theo dõi việc bảo trì bằng các bằng chứng thông thường: lỗi kiểm thử hợp đồng, thời gian dung hòa thay đổi được tạo, số chỉnh sửa thủ công bị mất khi tạo lại, số phiên bản ứng dụng không còn hỗ trợ và kết quả diễn tập khôi phục. Tránh chỉ số phù phiếm như số dòng mã dùng chung. Một lượng nhỏ ánh xạ trình bày lặp lại có thể rẻ hơn một tầng chia sẻ quá khéo léo.

Hai công cụ trở nên hợp lý khi hai đội đã vận hành theo cách này. Mỗi đội sở hữu ứng dụng của mình, một nhóm nền tảng sở hữu API và danh tính, còn kiểm thử tương thích tự động chạy trước khi phát hành. Trong bối cảnh đó, công cụ phù hợp với tổ chức. Một nhà sáng lập làm một mình không nên bắt chước sơ đồ tổ chức mà mình không có.

Bạn nên đưa ra quyết định thế nào?

Hãy chọn cách tiếp cận bằng cách chứng minh một thay đổi xuyên cả hai ứng dụng, không phải bằng cách so sánh tốc độ mỗi công cụ vẽ màn hình đầu tiên. Thử nghiệm nên có thay đổi schema, quy tắc phân quyền, bản di động cũ, các bản phát hành độc lập và diễn tập hoàn tác.

Yêu cầu các ứng viên một công cụ tạo một lát cắt dọc nhỏ: ứng dụng React và Flutter gửi cùng một lệnh đơn hàng đến API Go dùng PostgreSQL. Hãy đổi quy tắc sau khi cả hai ứng dụng hoạt động. Thêm trường tùy chọn, từ chối một vai trò, chỉ phát hành thay đổi web và khôi phục artifact máy chủ trước đó mà không mất các hàng mới. Xuất mã nguồn và chạy kiểm thử bên ngoài giao diện của công cụ.

Yêu cầu các ứng viên hai công cụ thực hiện cùng chuỗi đó với tài liệu OpenAPI đã được kiểm tra, cung cấp cho cả hai. Đo số thông tin bạn phải sao chép giữa các phiên và tần suất một công cụ chỉnh sửa ngoài ranh giới của nó. Hãy tính cả thời gian cần để chẩn đoán tình trạng trôi lệch, không chỉ thời gian tạo mã.

Dùng một công cụ nếu nó vượt qua các điều kiện này:

• Nó tạo các dự án React, Flutter và backend riêng quanh một hợp đồng.
• Nó giữ PostgreSQL phía sau backend và giữ bí mật ngoài ứng dụng.
• Nó hỗ trợ phát hành ứng dụng và máy chủ độc lập.
• Nó cho phép truy cập mã nguồn, trạng thái triển khai và các điểm khôi phục riêng biệt.
• Mã được tạo có thể xây dựng và kiểm thử mà không cần dựa vào lịch sử trò chuyện.

Chọn hai công cụ khi một năng lực chuyên biệt tạo khác biệt đáng kể cho kết quả di động hoặc web, đồng thời có một người được nêu tên sở hữu việc quản trị hợp đồng. «Kết quả di động trông đẹp hơn» là chưa đủ. Tích hợp thiết bị, hành vi hỗ trợ tiếp cận, đóng gói cho kho ứng dụng, hoạt động ngoại tuyến hoặc kỹ năng sẵn có của đội ngũ có thể là lý do đủ mạnh nếu lợi ích đó vẫn có giá trị sau khi tính chi phí bảo trì.

Koder.ai có thể tạo ứng dụng React, Go với PostgreSQL và Flutter từ một ngữ cảnh trò chuyện, cùng chế độ lập kế hoạch, xuất mã nguồn, triển khai và lưu trữ, ảnh chụp nhanh và hoàn tác. Tổ hợp đó phù hợp với kiến trúc một công cụ được mô tả ở đây, nhưng bạn vẫn nên thực hiện thử nghiệm lát cắt dọc vì danh sách tính năng không thể chứng minh đường phát hành và khôi phục của bạn.

Quyết định có thể thay đổi sau này. Một hệ thống có ranh giới rõ cho phép đội ngũ thay thế trình tạo React, trình tạo Flutter hoặc cả hai mà không phải chuyển quy tắc nghiệp vụ ra khỏi API. Hãy để kiến trúc đầu tiên giữ lại lựa chọn đó.

Bài kiểm tra khó chịu nhưng đơn giản: nếu công cụ di động biến mất vào ngày phát hành, bạn có thể giải thích hợp đồng API hiện tại, xây dựng ứng dụng đã xuất và tiếp tục phát hành không? Nếu câu trả lời phụ thuộc vào các câu lệnh được nhớ lại, hãy sửa mô hình sở hữu trước khi thêm một công cụ khác.