4 ms·

Well this is timely. Just this morning, I’ve been extending a Firebase app I developed for a very large enterprise customer, and I’ve been constantly reminded

Well this is timely. Just this morning, I’ve been extending a Firebase app I developed for a very large enterprise customer, and I’ve been constantly reminded of some of the things the author speaks about as I tried to recreate the FaaS environment locally. Not only did I waste valuable time setting everything up locally when the same would’ve been trivial in an old-school web framework; I now have an explosion of environment permutations and smells in my code, and I don’t completely trust that local and prod will behave the same so I will have to do extra testing. Despite Firebase coming a long way - some of these local emulation facilities plainly didn’t exist or barely worked a couple of years ago - there is no way I would choose it for a new project. The only module that has genuinely saved me time is auth; none of the rest have made me happier or more efficient than a web framework. Even for prototyping (the reason why I picked Firebase initially) I would still pick Django or Express or whatever else over this. (And I haven’t even delved into the big elephant in the room, which is lock-in.) Regarding costs and scalability there are a gazillion (fairly easy) things I could’ve done to achieve a similar cost range bringing my own stack. FaaS and the like may have their particular use cases but for anything that has even the slightest potential to turn into a full-blown app I’d go for a good old monolith every time.

btown 6y ago
For realtime requirements, I'm keeping a close eye on Supabase, which is building an open-source realtime Firebase-style API on top of the Postgres WAL. Theoretically, it's just Postgres with a bunch of services on top, so if you bring your own database migration and fixtures system, you could run a copy locally. Not sure that tooling is fully there yet (and it could use some of the model-layer bells and whistles I remember from the days when Meteor was the way you'd go for realtime), but the dev experience is very promising: https://github.com/supabase/realtime/blob/master/examples/next-js/pages/index.js#L36 https://github.com/supabase/realtime/blob/master/examples/ne... https://github.com/supabase/supabase https://github.com/supabase/supabase
- arcturus17 6y ago
  Yes, I also think that realtime is something where Firebase or Supabase may help. The app I'm talking about has no such requirements, and likely won't have them ever. Even then, if I were to build an app with a predictable realtime requirement I would (a) find a full-stack framework with this as a core feature (b) use a framework without this core capability, but look very hard for the simplest library that would allow me to pull off the requirements, and only if all else fails do (c) which is to isolate the realtime component into something like Firebase and build everything else in the core stack. (I haven't tried Supabase, but from what I understand it might fall more into (b) than (c), since you can bring your own infra)
  - btown 6y ago
    One of my favorite apps, Clubhouse.io (the project management solution, not the controversial audio social network), mimics realtime by just having a really, really optimized polling endpoint for the last timestamp the project was touched, then the client refreshes as needed (which would hit cache if you account for distributed systems propagation, if you even need to worry about that). It's an amazingly simple solution and one I'd recommend for anything in B2B modalities.
pwdisswordfish0 6y ago
A thing I've been noticing is that PaaS companies (e.g. Netlify, Cloudflare, Heroku) are shipping tools that let you test locally on your own machine. The experience is unmatched. I'd bet it's what led Google to (attempt to) do the same thing for Firebase, although I've noticed as well that their emulation is still off. Overall, I hope this is a trend that continues. The fact that these things are sometimes baked into their clients, which are usually freely licensed and developed in the open, available for patching, is something that hugely eliminates some of the lock-in risk associated with building on top of platforms. Worst case scenario? The company either goes out of business, deprecates some corner of its platform that you're relying on, or becomes prohibitively expensive to use, so you spin up a VPS and daemonize the client. This doesn't work for large projects, but for anything that is relatively small (but not so small as to characterize the development costs as trivial), it's sufficient.
- arcturus17 6y ago
  Well my experience with Heroku has always been that the code barely cares that it's being hosted there: a few config/environment variables here and there and that's it. Nothing to do with Firebase, where your project structure, front-end code, scripting utilities, config files, etc. become coupled with Firebase even if you try your best to contain the coupling. I'm interested, what does Heroku offer in the way of "local testing" anyway? I just use a web framework's normal test runners in my local shell.
- q845712 6y ago
  anecdote: about a year ago we had a Rails app on heroku and ran into a problem where the tests passed locally but hung in the remote heroku-CI pipeline. We followed the instructions for running the tests locally but ultimately weren't able to reproduce the hang, despite it happening every time in Heroku CI. Their support was good but ultimately it felt like some developers in the CI/container/platform team poked at it for some time-boxed session and couldn't figure out exactly what was going wrong. The problem had started after upgrading some gems, and we eventually solved it by upgrading some other (unrelated) gems. Somehow there was a very precise set of gem-versions that were incompatible with something else in the hosted environment. I've forgotten details but the tests that hung involved capybara or some part of the front-end / "integration" testing, which IMO tends to be flakier than backend-only tests. Anyway sharing here just to note that while thankfully it was a CI issue and not a production issue, it did convince me that "test locally on your own machine" tooling still had some subtle gaps vs. what was happening in "the cloud."
craftinator 6y ago
> I now have an explosion of environment permutations and smells in my code, and I don’t completely trust that local and prod will behave the same so I will have to do extra testing. I always run into this problem with microservice architectures, and it's a pain. There might be a B2B opportunity there, "recreate my distributed architecture as a service" or something...
- toomanybeersies 6y ago
  > recreate my distributed architecture as a service Isn't that essentially Docker Compose?
toomanybeersies 6y ago
I'll preface this by saying that I haven't even looked at Firebase in 5 years, so apologies if I'm completely off base. Why can't you just use a "live" development environment in Firebase? Obviously this isn't practical for some cloud services due to cost (AWS Redshift is the first example that comes to mind), but I don't see this being an issue with Firebase. If a company is paying six figure salaries to their developers, surely they can afford to give them dev environments on whatever cloud provider they use. Requiring an internet connection doesn't seem like it would be an issue either. Who in 2021 is building web apps with no internet access? I can tether to my phone practically anywhere, and even when I'm on a flight I have Wifi access. The product I work on uses a few live AWS services in dev, and for the past 5 or so years everything I've worked on has needed some kind of internet access to run. I can count on one hand the number of times this has been an issue. Dev/Prod parity is a good thing in my books. It's been more common for me to run into issues on prod due to slight differences in how things work between running things on my MacBook and on AWS, not just due to services emulators being different to the real thing, but due to intrinsic differences between running things on a MacBook and on remote Linux servers (even with docker).
- touisteur 6y ago
  > Who in 2021 is building web apps with no internet access? Defense contractors? Government entities? Entities worried about chain of trust in packages? Choice of upgrade path instead of forced? Ability to keep working when the net is down? There's a reason for lots of people to still want 'on prem' and to not want to have the whole Internet as a dependency.
  - maccard 6y ago
    How many of those people running airgapped systems are using firebase or s3 though?
    - lmeyerov 6y ago
      Due to govcloud, S3 + docker is increasingly normal. We're helping a team who have that... but not much else (ex: no outside internet). In utilities/industrial... docker, but not s3.
modernlearner 6y ago
I liked Firebase for prototyping, but for the same reasons you mentioned, I feel I should have just gone with Redis or something else that I can easily run locally. I get the feeling that Firebase (and some parts of AWS) are meant as services for larger enterprises that are really hooked on GCP (or AWS).
samsterngoogle 6y ago
I work on the Firebase team and have been working on the Firebase Emulator Suite for the past year or so. We really want every Firebase developer to be able to run their app locally and offline, although I'll be the first to admit there are rough edges. If you or anyone else wants to discuss this more and give us some specific feedback on what went wrong, please reach out: * https://groups.google.com/g/firebase-talk - our mailing list, good for open-ended discussion * https://github.com/firebase/firebase-tools - GitHub repo for the Firebase CLI and emulators if you have specific bugs to report. Or if you want to reach me personally I'm samstern@google.com, always happy to chat 1:1 about this stuff.

btown 6y ago

For realtime requirements, I'm keeping a close eye on Supabase, which is building an open-source realtime Firebase-style API on top of the Postgres WAL. Theoretically, it's just Postgres with a bunch of services on top, so if you bring your own database migration and fixtures system, you could run a copy locally. Not sure that tooling is fully there yet (and it could use some of the model-layer bells and whistles I remember from the days when Meteor was the way you'd go for realtime), but the dev experience is very promising: https://github.com/supabase/realtime/blob/master/examples/next-js/pages/index.js#L36 https://github.com/supabase/realtime/blob/master/examples/ne... https://github.com/supabase/supabase https://github.com/supabase/supabase

arcturus17 6y ago
Yes, I also think that realtime is something where Firebase or Supabase may help. The app I'm talking about has no such requirements, and likely won't have them ever. Even then, if I were to build an app with a predictable realtime requirement I would (a) find a full-stack framework with this as a core feature (b) use a framework without this core capability, but look very hard for the simplest library that would allow me to pull off the requirements, and only if all else fails do (c) which is to isolate the realtime component into something like Firebase and build everything else in the core stack. (I haven't tried Supabase, but from what I understand it might fall more into (b) than (c), since you can bring your own infra)
- btown 6y ago
  One of my favorite apps, Clubhouse.io (the project management solution, not the controversial audio social network), mimics realtime by just having a really, really optimized polling endpoint for the last timestamp the project was touched, then the client refreshes as needed (which would hit cache if you account for distributed systems propagation, if you even need to worry about that). It's an amazingly simple solution and one I'd recommend for anything in B2B modalities.

pwdisswordfish0 6y ago

A thing I've been noticing is that PaaS companies (e.g. Netlify, Cloudflare, Heroku) are shipping tools that let you test locally on your own machine. The experience is unmatched. I'd bet it's what led Google to (attempt to) do the same thing for Firebase, although I've noticed as well that their emulation is still off. Overall, I hope this is a trend that continues. The fact that these things are sometimes baked into their clients, which are usually freely licensed and developed in the open, available for patching, is something that hugely eliminates some of the lock-in risk associated with building on top of platforms. Worst case scenario? The company either goes out of business, deprecates some corner of its platform that you're relying on, or becomes prohibitively expensive to use, so you spin up a VPS and daemonize the client. This doesn't work for large projects, but for anything that is relatively small (but not so small as to characterize the development costs as trivial), it's sufficient.

arcturus17 6y ago
Well my experience with Heroku has always been that the code barely cares that it's being hosted there: a few config/environment variables here and there and that's it. Nothing to do with Firebase, where your project structure, front-end code, scripting utilities, config files, etc. become coupled with Firebase even if you try your best to contain the coupling. I'm interested, what does Heroku offer in the way of "local testing" anyway? I just use a web framework's normal test runners in my local shell.
q845712 6y ago
anecdote: about a year ago we had a Rails app on heroku and ran into a problem where the tests passed locally but hung in the remote heroku-CI pipeline. We followed the instructions for running the tests locally but ultimately weren't able to reproduce the hang, despite it happening every time in Heroku CI. Their support was good but ultimately it felt like some developers in the CI/container/platform team poked at it for some time-boxed session and couldn't figure out exactly what was going wrong. The problem had started after upgrading some gems, and we eventually solved it by upgrading some other (unrelated) gems. Somehow there was a very precise set of gem-versions that were incompatible with something else in the hosted environment. I've forgotten details but the tests that hung involved capybara or some part of the front-end / "integration" testing, which IMO tends to be flakier than backend-only tests. Anyway sharing here just to note that while thankfully it was a CI issue and not a production issue, it did convince me that "test locally on your own machine" tooling still had some subtle gaps vs. what was happening in "the cloud."

craftinator 6y ago

> I now have an explosion of environment permutations and smells in my code, and I don’t completely trust that local and prod will behave the same so I will have to do extra testing. I always run into this problem with microservice architectures, and it's a pain. There might be a B2B opportunity there, "recreate my distributed architecture as a service" or something...

toomanybeersies 6y ago
> recreate my distributed architecture as a service Isn't that essentially Docker Compose?

toomanybeersies 6y ago

I'll preface this by saying that I haven't even looked at Firebase in 5 years, so apologies if I'm completely off base. Why can't you just use a "live" development environment in Firebase? Obviously this isn't practical for some cloud services due to cost (AWS Redshift is the first example that comes to mind), but I don't see this being an issue with Firebase. If a company is paying six figure salaries to their developers, surely they can afford to give them dev environments on whatever cloud provider they use. Requiring an internet connection doesn't seem like it would be an issue either. Who in 2021 is building web apps with no internet access? I can tether to my phone practically anywhere, and even when I'm on a flight I have Wifi access. The product I work on uses a few live AWS services in dev, and for the past 5 or so years everything I've worked on has needed some kind of internet access to run. I can count on one hand the number of times this has been an issue. Dev/Prod parity is a good thing in my books. It's been more common for me to run into issues on prod due to slight differences in how things work between running things on my MacBook and on AWS, not just due to services emulators being different to the real thing, but due to intrinsic differences between running things on a MacBook and on remote Linux servers (even with docker).

touisteur 6y ago
> Who in 2021 is building web apps with no internet access? Defense contractors? Government entities? Entities worried about chain of trust in packages? Choice of upgrade path instead of forced? Ability to keep working when the net is down? There's a reason for lots of people to still want 'on prem' and to not want to have the whole Internet as a dependency.
- maccard 6y ago
  How many of those people running airgapped systems are using firebase or s3 though?
  - lmeyerov 6y ago
    Due to govcloud, S3 + docker is increasingly normal. We're helping a team who have that... but not much else (ex: no outside internet). In utilities/industrial... docker, but not s3.

modernlearner 6y ago

I liked Firebase for prototyping, but for the same reasons you mentioned, I feel I should have just gone with Redis or something else that I can easily run locally. I get the feeling that Firebase (and some parts of AWS) are meant as services for larger enterprises that are really hooked on GCP (or AWS).

samsterngoogle 6y ago

I work on the Firebase team and have been working on the Firebase Emulator Suite for the past year or so. We really want every Firebase developer to be able to run their app locally and offline, although I'll be the first to admit there are rough edges. If you or anyone else wants to discuss this more and give us some specific feedback on what went wrong, please reach out: * https://groups.google.com/g/firebase-talk - our mailing list, good for open-ended discussion * https://github.com/firebase/firebase-tools - GitHub repo for the Firebase CLI and emulators if you have specific bugs to report. Or if you want to reach me personally I'm samstern@google.com, always happy to chat 1:1 about this stuff.