3 ms·

> and for that applications you should build something custom. Given the spirit of the original post, I think avoiding "build something custom" is the point.

> and for that applications you should build something custom. Given the spirit of the original post, I think avoiding "build something custom" is the point. It should be a toggle in the database. > you don't have a 1:1 mapping between the database schema and the API (and if you do, you shouldn't, since a change of the internal database representation will require a change of the API and will break clients) I'd argue this is a huge problem. When DB and API get out of sync it creates so much complexity, especially when working in a relational model, and things become impossible to change, or make client caching really difficult. > The application when updates the data can publish it to whatever subscription system it wants to notify clients. This is so much complexity though, compared with the experience of Firebase. Good for keeping more devs employed though.

alerighi 5y ago
> This is so much complexity though, compared with the experience of Firebase. Good for keeping more devs employed though. The solution of Google is not less complex. Rather the complexity is hidden, that if all goes well is good, when things start to not work as expected it means weeks spent in debugging and trying to work around the issue. And we are not even talking about the possibility that Google changes API or closes down the service entirely, or it makes it more expensive, the so called vendor lock-in. At the other side a custom solution takes more time to develop initially, but then is entirely under your control, if something doesn't work you know how to fix it because you built it, you are not bounded to a particular platform, and there is not the possibility that Google decides to change the API in an incompatible way and you have to do extra work just to make things work as they did before, you decide when and if to update the software.

alerighi 5y ago

> This is so much complexity though, compared with the experience of Firebase. Good for keeping more devs employed though. The solution of Google is not less complex. Rather the complexity is hidden, that if all goes well is good, when things start to not work as expected it means weeks spent in debugging and trying to work around the issue. And we are not even talking about the possibility that Google changes API or closes down the service entirely, or it makes it more expensive, the so called vendor lock-in. At the other side a custom solution takes more time to develop initially, but then is entirely under your control, if something doesn't work you know how to fix it because you built it, you are not bounded to a particular platform, and there is not the possibility that Google decides to change the API in an incompatible way and you have to do extra work just to make things work as they did before, you decide when and if to update the software.