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 mobile apps' developers who could not afford (or don't need) to deploy their own backend. While most of the services are quite transversals: storage, login, analytics, and messages service, it's true that it also 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 having backend dedicated to host and run business-specific operations.
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.
Q: I guess the alternative would be to create a backend that contains the business logic and uses Firebase for its 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 having 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 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