Where to put business logic if using Firebase?

Question

I'm about to start developing a single page web application that is very simplified a multi user documentation system. The front end will probably use Angular2.

The project has a short deadline, so I've been looking for "shortcuts", i.e. using various ready made services instead of implementing everything from scratch.

I will need some kind of backend to store the application data. I've looked around and found Firebase, which seems to take away some of the work of creating a separate backend and API to communicate with the front end.

But that also means I would have to put the business logic in the front end, in the Angular2 web app, right?

So if I some day in the future would like to make a mobile app front end, I would have to duplicate the business logic code?

I guess the alternative would be to create a backend that contains the business logic and uses Firebase for it's data storage, but that seems a bit weird (couldn't I just use an ORM or something directly in my backend to achieve the same result without a lot more work?)

How do people usually structure these kinds of apps, if they want to make use of Firebase for example?

Answer 1

Q: But that also means I would have to put the business logic in the front-end, in the Angular2 web app, right?

Yes. If it's not backed by a server, the business should be implemented somewhere.

After Google's acquisition, Firebase evolved to become a platform for developers of mobile apps who could not afford to deploy their own backend.

While most of the services are transversals (storage, login, analytics, and messages service), it's true that Firebase provides with Cloud Functions (sort of lambdas) which can be used to perform some business-specific rules. However, for enterprise applications or large applications with a complex domain and business logic, this kind of supports falls short.

So, as you may guess, Firebase doesn't exempt us from backing our apps with our own backend (where we put or business) at the same time we use it (Firebase) for other purposes.

Q: So if I someday in the future I would like to make a mobile app front-end, I would have to duplicate the business logic code?

Not necessarily. If the web app is built on Angular, cross platforms like NativeScript may allow you to reuse the web components, libs, utilities, models, etc. I haven't delved into the subject so I can't assure you full compatibility. The key lays on TypeScript, both Angular and NativeScript requires us to code on TS.

The matter then is where we host the Javascript for its distribution and versioning. A word CDN.

Q: I guess the alternative would be to create a backend that contains the business logic and uses Firebase for the data storage, but that seems a bit weird (couldn't I just use an ORM or something directly in my backend to achieve the same result without a lot more work?)

Some considerations.

On one hand, hosting, rolling out, managing and maintaining a database is no little thing. Not to mention handling security, scalability, availability, etc. So, having a DB provider looking after these things is interesting. It's not a crazy idea these days rolling out our database somewhere on the cloud. Of course, I would not suggest this if we were implementing the middleware and back-ends for a bank. But it could make sense for the client's session, user's profiles, preferences and this sort of data that usually lives on the client-side or data we don't care about on the server-side because it's not relevant to the business.

On the other hand, having our back-end is useful for a simple reason, decoupling.

Instead of coupling our clients to all sort of services we don't manage and control, we deploy a server-side application from where we look after of these things so that our clients don't have to worry about issues like services shutdowns or breaking changes. Additionally, we gain on simplicity because our back-end acts like a facade.

Q: How do people usually structure these kinds of apps, if they want to make use of Firebase for example?

It varies widely from project to project. For instance, we use Firebase + back-end.

• Firebase DB to share data between devices-accounts-sessions. Also as a changelog, when our backend is temporarily unavailable clients send the write operations to the log, which is synchronized later.

• Firebase Cloud Messages provides us with upstream/downstream push notifications and topics. We use the service for pub/sub message exchange.

• Firebase analytics Mostly for metrics.

• Back-end for everything strictly related to the business

Answer 2

Short answer: Don't use business logic.

Long answer: You describe an application that seem small enough not to have a separate business logic; evaluate if you really have such business logic in the first place; a lot of business logic can be reduced by the data design, and a little by the presentation layer. Many small systems are mostly CRUD and don't have any real business logic; a lot of times I have seen two or three layers of classes that are just passthrough objects leaving space for a future that will never arrive.

You may start with an API right out of Firebase, and later introduce an additional layer for business logic when you find there is some real need for it, as long as you design your contract well enough for the service to keep a stable signature while the implementation behind may change.

Answer 3

see https://stackoverflow.com/questions/54994228/how-to-minimise-firebase-function-latency

Cloud Firestore is the primary and only connection between front-end and backend. Of course some logic can be within the front-end, but for security that can typically only be for the user's benefit offline. You should implement security on the Cloud Firestore collections themselves, securing on roles or whatever you need.

Then, use Cloud Functions that are called from a Cloud Firestore trigger.

You SHOULD never call a Cloud Function from a front-end application.