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.
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?)
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