I no longer work at Firebase / Google, but two points:
1. There may be issues with the GCP integrations & UX/DX, but GCP integration is good for many customers and necessary for the future of the business.
One of the common failure modes for the 2011-2014 crop of Backend-as-a-Service offerings was their inability to technically support large customers. The economics of developer tooling are a super-power-law. So, if you hope to pay your employees you'll need to grow with your biggest customers.
Eventually, as they become TheNextBigThing, your biggest customers end up wanting the bells and whistles that only a Big Cloud Platform provide.
This was a part of the reason we chose to join Google, and why the Firebase team really really really pushed hard to integrate with GCP at a project, billing, and product level (philosophy: Firebase exposed the product from the client, GCP from the server) despite all the organizational/political overhead.
2. I'm excited to see the current crop of app platforms emerge. It has been 10 years since we launched (https://hackertimes.com/item?id=3832877) and there are now some great innovations in the space. I like the way Supabase (https://supabase.com/) has exposed Postgres and InstantDB (https://www.instantdb.com) graphdb+realtime is really promising.
While this seems reasonable, surely there’s a caveat here:
If you have a successful popular product (firebase) and a not particularly successful or well loved product (GCP), does mixing A into B make sense?
It might make technical sense to have the robust engineering capabilities of B to support A.
…but if it’s driving customers away from A, because it’s starting to look like what they don’t like from B…
All I can say is that there seems to be a lot of pressure for GCP to succeed, and I’m pretty skeptical that the changes to firebase are being made for the sake of making that product better.
Betty had a bit of butter, but the butter was bitter, so she mixed the bitter butter with the better butter to make the bitter butter better but it made the better butter bitter…
It's from Google, they deprecate things every 6 months including APIs your app is using, if you don't follow your app will be down pretty quickly. AWS nearly never do breaking changes.
AWS GameSparks.
Being shut down end of November and bringing down one of my favorite games with it, because the devs were foolish enough to believe what you believe, that AWS sticks with its products.
It's AWS page says Preview, meaning it has never gotten to an official stable release. It's like using a beta/rc product, there is an explicit warning this is not the final version and it might not get anywhere.
But since Firebase is from Google now, anyone who worries about Google deprecating products have equal worries whether Firebase is based on GCP or not.
Outside of HN, I find developers (at least in Europe) often prefer GCP and businesses have full faith in the offering because of the Google stamp.
For Azure I have yet to find a developer who likes it, but businesses are drawn to it due to the packaging with other Microsoft services (eg you buy office 364, teams, Active Directory and Azure together in a Enterprise package) and businesses have full faith in the Microsoft stamp of approval.
Same, of all the people I've interacted with, it's AWS and GCP which are liked (AWS mostly for features, GCP more for UX/DX), Azure is at best accepted and the only reasons anyone uses are "we were already a MS partner/shop".
> If you have a successful popular product (firebase) and a not particularly successful or well loved product (GCP), does mixing A into B make sense?
Firebase is more successful than GCP? In what way?
> Betty had a bit of butter, but the butter was bitter, so she mixed the bitter butter with the better butter to make the bitter butter better but it made the better butter bitter…
> > Betty had a bit of butter, but the butter was bitter, so she mixed the bitter butter with the better butter to make the bitter butter better but it made the better butter bitter…
> ?
They are saying that taking a good thing and combining it with a bad thing, doesn't make the bad thing good. It makes the good thing bad.
I have no "dog in this fight" (side note, any better phrases to use there?) but just explaining what they tried to convey.
This is interesting, is this the fate of every upstart PaaS, to
be acquired by an Amazon, Google, Microsoft, Oracle etc. I see it might be necessary but also feels like a long con. You got popular because of not being the stuffy, complex, corporate thing. Then you slowly become one.
This is why more and more I will err on the side of foss. I am investing my learning time into linux tools (bash and tmux for eg) even when using windows. Maybe even get back into vim. Because these tools will probably be the same after I die, or at least heavily backward compatible.
Windows got in the way of my web development and I only learned that when I switched to Linux. Years later, I don't need Windows anymore and I'm so glad to escape that bloatware and spyware of an OS.
Now I do gaming, video editing and programming all on Linux (ZorinOS) and it feels and looks so good.
It inherently creates the need to make sure that the games can run on Linux, even if on a compatibility layer. This will only incentivize more people to try Linux and devs to create better tools and support systems.
It's not the utopia we expect but it does get us close to it.
I have a very similar take (although I’ve been using Linux since it was distributed on floppies :), and I definitely prefer working with indies, but I will say that one of the things I really like about Supabase is that everything is available open source.
So even if they are merged with one Borg or another, I would expect to have sufficient time to deploy my own infra if it looks like it’s all going to go pear shaped.
I'm the founder of WunderGraph (https://wundergraph.com) and I'd like to mention it as an open source alternative as well.
What makes WunderGraph different is the focus on integrations. You can easily integrate internal and 3rd party APIs, and choose your own client. We generate code e.g. using swr, so you can build on top of existing ecosystems.
We're also currently building a cloud version, which uses fly.io machines to be able to scale functions to zero and even run a SQLite database that can "sleep". I'd love to hear people's opinion.
Hi James. Thanks for commenting. Just wanted to let you know that your HN profile is outdated based on this comment. It says you are "Now leading product for Firebase at Google."
Thanks James, I remember Firebase coming to Citrix in Santa Barbara to discuss being aquired. Wonder if you participated in those meetings? So glad they did not buy and ruin you! Ha
Thanks! Fwiw, we do plan to open source in the future :) For now we want to iterate with a small group of users. Feel free to drop me a line if you want to hack with us.
I no longer work at Firebase / Google, but two points:
1. There may be issues with the GCP integrations & UX/DX, but GCP integration is good for many customers and necessary for the future of the business.
One of the common failure modes for the 2011-2014 crop of Backend-as-a-Service offerings was their inability to technically support large customers. The economics of developer tooling are a super-power-law. So, if you hope to pay your employees you'll need to grow with your biggest customers.
Eventually, as they become TheNextBigThing, your biggest customers end up wanting the bells and whistles that only a Big Cloud Platform provide.
This was a part of the reason we chose to join Google, and why the Firebase team really really really pushed hard to integrate with GCP at a project, billing, and product level (philosophy: Firebase exposed the product from the client, GCP from the server) despite all the organizational/political overhead.
2. I'm excited to see the current crop of app platforms emerge. It has been 10 years since we launched (https://hackertimes.com/item?id=3832877) and there are now some great innovations in the space. I like the way Supabase (https://supabase.com/) has exposed Postgres and InstantDB (https://www.instantdb.com) graphdb+realtime is really promising.