17

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, 2017 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
    Mar 13, 2017 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, 2017 at 16:12

3 Answers 3

Reset to default
8

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 and became a platform for developers of apps that could not afford to build and deploy their own backend.

Most of the Firebase featured services are transversals (storage, login, analytics, and messages service) but few address the problem in question.

It's true that Firebase provides with Cloud Functions (sort of lambdas) which can be used to perform business-specific rules. However, for enterprise applications or large applications with a complex domain, this kind of support falls short. Even if we manage to implement the business with cloud functions, the overall could make the solution very hard to maintain. Mainly for the complexity.

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 is 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.

You could also hire a hosting service with Web support and host the JavaScript yourself.

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 to roll out our database somewhere on the cloud. Of course, I would not suggest this if we were implementing the middleware or the back-end of 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 temporarily.

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

Instead of coupling our clients to all sorts of services we don't manage and control, we deploy a server-side application from where we look after 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
  • 1
    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, 2017 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, 2017 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 and acknowledge that you have read and understand our privacy policy and code of conduct.

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