Đặt logic kinh doanh ở đâu nếu sử dụng Firebase?


10

Tôi sắp bắt đầu phát triển một ứng dụng web duy nhất rất đơn giản hóa một hệ thống tài liệu đa người dùng. Mặt trước có thể sẽ sử dụng Angular2.

Dự án có thời hạn ngắn, vì vậy tôi đã tìm kiếm "phím tắt", tức là sử dụng nhiều dịch vụ làm sẵn khác nhau thay vì thực hiện mọi thứ từ đầu.

Tôi sẽ cần một số loại phụ trợ để lưu trữ dữ liệu ứng dụng. Tôi đã nhìn xung quanh và tìm thấy Firebase, dường như lấy đi một số công việc tạo một phụ trợ và API riêng biệt để liên lạc với giao diện người dùng.

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?

Vì vậy, nếu một ngày nào đó trong tương lai tôi muốn tạo một giao diện ứng dụng di động, tôi có phải sao chép mã logic nghiệp vụ không?

Tôi đoán giải pháp thay thế sẽ là tạo một phụ trợ chứa logic nghiệp vụ và sử dụng Firebase để lưu trữ dữ liệu, 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 kết quả tương tự mà không có công việc nhiều hơn?)

Làm thế nào để mọi người thường cấu trúc các loại ứng dụng này, nếu họ muốn sử dụng Firebase chẳng hạn?


Cơ sở dữ liệu / orm, vv mà bạn quen thuộc nhất? Đó có lẽ là những gì sẽ đưa bạn đến đó nhanh nhất.
Robert Harvey

Đối với dự án này, có lẽ tôi đang sử dụng một số công nghệ mà tôi chưa từng sử dụng trước đây, vì vậy sẽ có một số cách học ...
Magnus W

Bạn chỉ cần lưu trữ dữ liệu hoặc bạn đang cố gắng sử dụng khả năng đẩy ngay lập tức? Nếu bạn không coi đó là logic kinh doanh, mỗi công nghệ mặt trước có thể xử lý trực tiếp bằng mã kết nối của chính nó. Không chắc chắn một ORM sẽ làm điều này.
JeffO

Câu trả lời:


2

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


1

Câu trả lời ngắn: Đừng sử dụng logic kinh doanh.

Câu trả lời dài: Bạn mô tả một ứng dụng dường như đủ nhỏ để không có logic kinh doanh riêng biệt; đánh giá nếu bạn thực sự có logic kinh doanh như vậy ngay từ đầu; rất nhiều logic nghiệp vụ có thể được giảm bớt bởi thiết kế dữ liệu và một chút bởi lớp trình bày. Nhiều hệ thống nhỏ chủ yếu là CRUD và không có logic kinh doanh thực sự; rất nhiều lần tôi đã thấy hai hoặc ba lớp lớp chỉ là những đối tượng vượt qua để lại không gian cho một tương lai sẽ không bao giờ đến.

Bạn có thể bắt đầu với một API ngay từ Firebase và sau đó giới thiệu một lớp bổ sung cho logic nghiệp vụ khi bạn thấy có nhu cầu thực sự cho nó, miễn là bạn thiết kế hợp đồng của mình đủ tốt để dịch vụ giữ chữ ký ổn định trong khi thực hiện phía sau có thể thay đổi.


Không thể nói như tôi đồng ý với điều này. Tôi đã làm việc trong ngành này được 20 năm và đã làm việc với phần ứng dụng CRUD nhỏ của mình, nhưng hầu như luôn có một số logic kinh doanh. Ngay cả khi đó chỉ là xác nhận tùy chỉnh hoặc tính thuế, vẫn luôn có một cái gì đó.
Jules

Tôi đồng ý với nhận xét của bạn. Tôi không nói là không có logic kinh doanh; Điều tôi đang nói là nó không đủ lớn để xứng đáng với một lớp riêng biệt. Tôi sẽ tranh luận nếu các xác nhận hoặc tính toán đó thực sự thuộc về một lớp nghiệp vụ chứ không phải dữ liệu hoặc lớp trình bày (đặc biệt là các xác nhận tùy chỉnh có xu hướng phù hợp với định nghĩa của tôi về logic dữ liệu), nhưng vấn đề không phải là thuần túy về nơi nó nên được phân loại, nhưng Thực dụng về nơi để mã nó.
Bruno Guardia

0

xem /programming/54994228/how-to-minimise-firebase-feft-latency

Cloud Firestore là kết nối chính và duy nhất giữa front-end và backend. Tất nhiên một số logic có thể nằm trong giao diện người dùng, nhưng để bảo mật thường chỉ dành cho lợi ích của người dùng ngoại tuyến. Bạn nên tự thực hiện bảo mật trên các bộ sưu tập Cloud Firestore, đảm bảo vai trò hoặc bất cứ điều gì bạn cần.

Sau đó, sử dụng Hàm đám mây được gọi từ trình kích hoạt Cloud Firestore.

Bạn KHÔNG bao giờ gọi Chức năng đám mây từ ứng dụng giao diện người dùng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.