2 ms·
I have clients with apps that are pushing the boundaries of Firebase. I have strongly suggested the move to Azure or Amazon "serverless" - Azure Functions or Am
by intrasight 9y ago
I have clients with apps that are pushing the boundaries of Firebase. I have strongly suggested the move to Azure or Amazon "serverless" - Azure Functions or Amazon Lambda. I get strong pushback due to "cost and complexity" concerns. I respond that of course "real" development and operations is going to be more complex and expensive than the "toy" proof-of-concept they build with Firebase. But this has been an issue in my career for decades - users get hooked on on RAD tools (Rapid Application Development) and are then shocked that adding "10% more features" will add 1000% to the cost.
- RonanTheGrey 9y agoThere is this pervasive belief in software that "everything should be easy!" which has never made any sense to me. For RAD, sure. But for anything that grows beyond that? A few core reasons why it can't (and won't) be, at least until AI is running the world: * Any non-trivial application can explode in complexity quite quickly, even with well-designed data boundaries and code flows * The human brain is incapable of managing said complexity in any effective way * We must therefore break this complexity into consumable pieces that fit inside our heads * Which means redesigning those data boundaries and data flows, in order to make them fit in our heads, which inevitably moves the complexity around the system RAD tools HIDE all that complexity but the moment you need to move it, you can't. So you end up having to re-implement. I am using Firebase for an app I do not expect to ever exceed a few thousand users - it is an app for a local business that is quite popular, but limited in geographical scope. So it's a good choice. I wouldn't pick it for larger apps whose potential growth is not so limited. I'd take the hit up front to properly build an architecture that can scale (but doesn't, at first, per Martin Fowler).