3 ms·

Firebase taught me, for a B2B2C kind of app: 1) Relational databases are more flexible: you model your data according to the actual "relations" between them, i

Firebase taught me, for a B2B2C kind of app: 1) Relational databases are more flexible: you model your data according to the actual "relations" between them, instead of how you want to query them. This makes it easier to add new views/queries to your application. 2) Joins are necessary 3) In a very short time, you need complex authentication logic and it is very hard to do it without looking at the requested (and related) data directly. Best way to do this is a good-old rdbms + server app 4) Moving more logic from servers to clients forces you to be more careful about client versions, duplicate logic among different clients (iOS, Android, Web, Dashboard)

dozzie 9y ago
> 2) Joins are necessary > 4) Moving more logic from servers to clients forces you to be more careful [...] Back to the very old architecture of client-server-database instead of client-database that was proven dumb long time ago. The client-server-database architecture was happily ditched by the crowd that builds dynamic websites and calls them "web applications", so now everybody rediscovers that it actually is a poor idea for client to talk to database directly.
- le-mark 9y ago
  I agree with this, to a point. But what's missing in this discussion are the things that firebase (and others) brought to the table that were new; real time push, and adminless backend ("serverless" term they and other others try to popularize fails to describe what it actually is). I'm personally thankful the nosql hype has finally subsided, and everyone recognizes it for what it is, a tool in the box. Not everyone has made that realization yet, as other posts in this thread indicate. Server pushing data enables some really useful things, the archetypical example being online chat. Adminless backends are also very attractive to a lot of people, in particular front end devs who just want to build, not do a poor (insecure) job admining servers. I personally lament this "everyone's a server admin" culture we have come into in recent years. But those innovations aren't enough to make up for the deficits the author, and many here are describing. Like others have said, use Firebase for what it's intended, and when you really need to scale, be prepared to roll your own solution.

dozzie 9y ago

> 2) Joins are necessary > 4) Moving more logic from servers to clients forces you to be more careful [...] Back to the very old architecture of client-server-database instead of client-database that was proven dumb long time ago. The client-server-database architecture was happily ditched by the crowd that builds dynamic websites and calls them "web applications", so now everybody rediscovers that it actually is a poor idea for client to talk to database directly.

le-mark 9y ago
I agree with this, to a point. But what's missing in this discussion are the things that firebase (and others) brought to the table that were new; real time push, and adminless backend ("serverless" term they and other others try to popularize fails to describe what it actually is). I'm personally thankful the nosql hype has finally subsided, and everyone recognizes it for what it is, a tool in the box. Not everyone has made that realization yet, as other posts in this thread indicate. Server pushing data enables some really useful things, the archetypical example being online chat. Adminless backends are also very attractive to a lot of people, in particular front end devs who just want to build, not do a poor (insecure) job admining servers. I personally lament this "everyone's a server admin" culture we have come into in recent years. But those innovations aren't enough to make up for the deficits the author, and many here are describing. Like others have said, use Firebase for what it's intended, and when you really need to scale, be prepared to roll your own solution.