12

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?

Improve this question
3
  • Which database/orm, etc. are you the most familiar with? That's probably what will get you there the fastest. – Robert Harvey Mar 12 '17 at 18:42
  • For this project I'd probably be using some technologies I haven't used before, so there would be some learning either way... – Magnus W Mar 13 '17 at 1:57
  • Do you just need data storage or are you trying to utilize the instant push capability as well? If you don't see that as business logic, each front-end technology can just handle it directly with it's own connection code. Not sure an ORM will do this. – JeffO Mar 16 '17 at 16:12
5

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

Improve this answer
1

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.

Improve this answer
2
  • Can't say as I agree with this. I've worked in this industry for 20 years, and have worked on my share of small CRUD applications, but there is almost always some business logic. Even if it's just custom validations or tax calculations, there's always something. – Jules May 19 '17 at 7:45
  • I agree with your comment. I am not saying there is zero business logic; what I am saying is that it is not big enough to deserve a separate layer. I would contend if those validations or calculations really belong to a business layer and not data or presentation layer (particularly custom validations tend to match my definition of data logic), but the point is not to be purist on where it should be classified, but pragmatic on where to code it. – Bruno Guardia May 19 '17 at 20:00
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.