H: Nhưng điều đó cũng có nghĩa là tôi sẽ phải đưa logic kinh doanh vào giao diện người dùng, trong ứng dụng web Angular2, phải không?
Đúng. Nếu nó không được hỗ trợ bởi một máy chủ, doanh nghiệp nên được thực hiện ở đâu đó.
Sau khi mua lại của Google, Firebase đã phát triển để trở thành một nền tảng cho các nhà phát triển ứng dụng di động không đủ khả năng (hoặc không cần) để triển khai chương trình phụ trợ của riêng họ. Mặc dù hầu hết các dịch vụ đều khá ngang nhau: dịch vụ lưu trữ, đăng nhập, phân tích và tin nhắn, nhưng sự thật là nó cũng cung cấp Chức năng đám mây (loại lambdas) có thể được sử dụng để thực hiện một số quy tắc dành riêng cho doanh nghiệp. Tuy nhiên, đối với các ứng dụng doanh nghiệp hoặc các ứng dụng lớn có tên miền và logic kinh doanh phức tạp, loại hỗ trợ này bị thiếu.
Vì vậy, như bạn có thể đoán, Firebase không miễn cho chúng tôi có phần phụ trợ dành riêng cho việc lưu trữ và điều hành các hoạt động dành riêng cho doanh nghiệp.
H: Vì vậy, nếu một ngày nào đó trong tương lai tôi muốn tạo một ứng dụng di động, tôi có phải sao chép mã logic nghiệp vụ không?
Không cần thiết. Nếu ứng dụng web được xây dựng trên Angular, các nền tảng chéo như NativeScript có thể cho phép bạn sử dụng lại các thành phần web, libs, tiện ích, mô hình, v.v. Tôi chưa đào sâu vào chủ đề để tôi không thể đảm bảo cho bạn khả năng tương thích hoàn toàn. Khóa nằm trên TypeScript , cả Angular và NativeScript đều yêu cầu chúng tôi viết mã trên TS.
Vấn đề sau đó là nơi lưu trữ Javascript để phân phối và phiên bản . Một CDN từ .
H: Tôi đoán giải pháp thay thế sẽ là tạo một phụ trợ có chứa logic nghiệp vụ và sử dụng Firebase để lưu trữ dữ liệu của nó, nhưng điều đó có vẻ hơi lạ (tôi không thể sử dụng ORM hoặc thứ gì đó trực tiếp trong phần phụ trợ của mình để đạt được điều tương tự kết quả mà không có nhiều công việc hơn?)
Một số cân nhắc.
Một mặt, lưu trữ, triển khai, quản lý và duy trì cơ sở dữ liệu là điều không hề nhỏ. Chưa kể xử lý bảo mật, khả năng mở rộng, tính sẵn sàng, v.v ... Vì vậy, có một nhà cung cấp DB chăm sóc những điều này thật thú vị. Nó không phải là một ý tưởng điên rồ những ngày này có cơ sở dữ liệu của chúng tôi ở đâu đó trên đám mây. Tất nhiên, tôi sẽ không đề xuất điều này nếu chúng tôi đang triển khai phần mềm trung gian và back-end cho một ngân hàng. Nhưng nó có thể có ý nghĩa đối với phiên của khách hàng, hồ sơ người dùng, sở thích và loại dữ liệu này thường nằm ở phía khách hàng hoặc dữ liệu mà chúng tôi không quan tâm.
Mặt khác, có back-end của chúng tôi rất hữu ích vì một lý do đơn giản, tách rời .
Thay vì kết nối khách hàng của chúng tôi với tất cả các loại dịch vụ mà chúng tôi không quản lý và kiểm soát, chúng tôi triển khai một ứng dụng phía máy chủ từ nơi chúng tôi chăm sóc những điều này để khách hàng không phải lo lắng về các vấn đề như tắt máy hoặc phá vỡ dịch vụ thay đổi. Ngoài ra, chúng tôi đạt được sự đơn giản vì back-end của chúng tôi hoạt động như một mặt tiền.
H: Mọi người thường cấu trúc các loại ứng dụng này như thế nào, nếu họ muốn sử dụng Firebase chẳng hạn?
Nó rất khác nhau từ dự án để dự án. Chẳng hạn, chúng tôi sử dụng Firebase + back-end.
Firebase DB để chia sẻ dữ liệu giữa các thiết bị-tài khoản-phiên . Cũng như một thay đổi, khi phụ trợ của chúng tôi tạm thời không có sẵn, khách hàng sẽ gửi các thao tác ghi vào nhật ký, được đồng bộ hóa sau này.
Tin nhắn đám mây Firebase cung cấp cho chúng tôi các thông báo và chủ đề đẩy ngược dòng / xuôi dòng. Chúng tôi sử dụng dịch vụ để trao đổi tin nhắn pub / sub.
Phân tích Firebase Chủ yếu là cho các số liệu.
Back-end cho mọi thứ liên quan chặt chẽ đến doanh nghiệp