4 ms·

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" develop

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.
- Sebb767 6y ago
  > 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? I think you partially misunderstood the parent comment - he was talking about requiring the internet for building the app ("Who in 2021 is building web apps with no internet access [while developing]?"), but you responded to using web apps w/o internet ("Who in 2021 is building web apps [for use] with no internet access?"). A bit of your point still stands, but, as the sister comment correctly pointed out, when you're building a web app for offline usage, Firebase is not the right choice of technology.
  - vageli 6y ago
    I don't think that is true. Having worked in regulated environments, the depedencies are mirrored internally with something like artifactory and must be approved for use after a license vetting, etc. The application build process would not touch the public internet to retrieve any content.
    - kelnos 6y ago
      I think you're missing the original point. If your app is built on top of something like Firebase, then clearly your org has approved that use. So when developing the app, you should have access to Firebase. If your org has not approved any cloud services, then you can run everything on your development machine (database, webapp, cache, etc.), or a provisioned dev environment if the full stack is too heavy for a single workstation.
arcturus17 6y ago
> Why can't you just use a "live" development environment in Firebase? I have a live (as in online) dev environment with its own DB, which is good for most database reading/writing. However, for Firebase Functions (FaaS), I really don't like the dev experience of using an online environment. You have increased latency for everything, but above all, logging is terrible. So you have to set up the local emulators, which is not nearly as easy as doing `python manage.py runserver` or `nodemon` or what have you. I had problems with the setup this morning, and I've had to modify the code to write to the emulators instead of live functions depending on the environment (there is no way to do it purely through env variables, you have to do it though code). I'll grant that it's improved massively over the last year or so - when I started the project I couldn't get the emulators to work at all, and SO and Github were riddled with issues on the topic. On the topic of databases, I say it's good for most reading and writing, but last time I checked the data from emulated databases is not persisted so it's only good for fleeting tests, but not for playing around with data locally. I'm sure I'm not alone in that I often like to play around with bulk operations (such as big initializations or fetching) and manually explore the data (the "live" data explorer in the form of Firebase console web app is atrocious, there are infinitely better local solutions like pgAdmin, or the JetBrains' database explorers) All in all the DX is just about acceptable, but I'm not impressed given that the product is almost a decade old, massively adopted, and led by Google. My original point is I believe web frameworks give me "tighter" DX, and I don't see a reason to pick Firebase over other options as a complete stack most of the time.
- endless1234 6y ago
  The complete emulator suite seems to be mostly suited for running tests. When working on firebase functions, I find running only them (`firebase emulators:start --only functions`), with everything else connected to the dev firebase project online, works pretty well. Persistent data but fast feedback loop for what I'm working on. You do need some scripts to manage what you are connecting to from the front end, as if you're just working on that it's probably nicer to not need the emulators at all. I agree that it's just barely acceptable. I wish the web console wasn't so slow, and the data explorer needs a major overhaul.
kube-system 6y ago
> Who in 2021 is building web apps with no internet access? Over the past 20 years, a lot of software development has shifted to apps that run in the client's browser. But, there are still a lot of computers which are not connected to the internet. Sometimes it is because of security, sometimes environmental factors, sometimes it is simply because the use case does not necessitate it. I have a computer that uses a web app that isn't connected to the internet on my desk right now -- a printer.
nicoburns 6y ago
My company was doing this when I joined (and to some extent still does this, but most of our data is in postgres now). It works ok as a development environment, but it's massively constraining for automated testing. With a local instance, I can just spin a new one up for each test run. You can't do that with firebase projects (they do now provide an emulator which is just about workable).
bpicolo 6y ago
I imagine mostly because deploying to the cloud is slow - it would be the new waiting for compiling. A fast-paced edit-compile-debug cycle is a huge development productivity benefit, and doing it via unit/integration tests and what have you is nice, but not equivalent.

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.
Sebb767 6y ago
> 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? I think you partially misunderstood the parent comment - he was talking about requiring the internet for building the app ("Who in 2021 is building web apps with no internet access [while developing]?"), but you responded to using web apps w/o internet ("Who in 2021 is building web apps [for use] with no internet access?"). A bit of your point still stands, but, as the sister comment correctly pointed out, when you're building a web app for offline usage, Firebase is not the right choice of technology.
- vageli 6y ago
  I don't think that is true. Having worked in regulated environments, the depedencies are mirrored internally with something like artifactory and must be approved for use after a license vetting, etc. The application build process would not touch the public internet to retrieve any content.
  - kelnos 6y ago
    I think you're missing the original point. If your app is built on top of something like Firebase, then clearly your org has approved that use. So when developing the app, you should have access to Firebase. If your org has not approved any cloud services, then you can run everything on your development machine (database, webapp, cache, etc.), or a provisioned dev environment if the full stack is too heavy for a single workstation.

arcturus17 6y ago

> Why can't you just use a "live" development environment in Firebase? I have a live (as in online) dev environment with its own DB, which is good for most database reading/writing. However, for Firebase Functions (FaaS), I really don't like the dev experience of using an online environment. You have increased latency for everything, but above all, logging is terrible. So you have to set up the local emulators, which is not nearly as easy as doing `python manage.py runserver` or `nodemon` or what have you. I had problems with the setup this morning, and I've had to modify the code to write to the emulators instead of live functions depending on the environment (there is no way to do it purely through env variables, you have to do it though code). I'll grant that it's improved massively over the last year or so - when I started the project I couldn't get the emulators to work at all, and SO and Github were riddled with issues on the topic. On the topic of databases, I say it's good for most reading and writing, but last time I checked the data from emulated databases is not persisted so it's only good for fleeting tests, but not for playing around with data locally. I'm sure I'm not alone in that I often like to play around with bulk operations (such as big initializations or fetching) and manually explore the data (the "live" data explorer in the form of Firebase console web app is atrocious, there are infinitely better local solutions like pgAdmin, or the JetBrains' database explorers) All in all the DX is just about acceptable, but I'm not impressed given that the product is almost a decade old, massively adopted, and led by Google. My original point is I believe web frameworks give me "tighter" DX, and I don't see a reason to pick Firebase over other options as a complete stack most of the time.

endless1234 6y ago
The complete emulator suite seems to be mostly suited for running tests. When working on firebase functions, I find running only them (`firebase emulators:start --only functions`), with everything else connected to the dev firebase project online, works pretty well. Persistent data but fast feedback loop for what I'm working on. You do need some scripts to manage what you are connecting to from the front end, as if you're just working on that it's probably nicer to not need the emulators at all. I agree that it's just barely acceptable. I wish the web console wasn't so slow, and the data explorer needs a major overhaul.

kube-system 6y ago

> Who in 2021 is building web apps with no internet access? Over the past 20 years, a lot of software development has shifted to apps that run in the client's browser. But, there are still a lot of computers which are not connected to the internet. Sometimes it is because of security, sometimes environmental factors, sometimes it is simply because the use case does not necessitate it. I have a computer that uses a web app that isn't connected to the internet on my desk right now -- a printer.

nicoburns 6y ago

My company was doing this when I joined (and to some extent still does this, but most of our data is in postgres now). It works ok as a development environment, but it's massively constraining for automated testing. With a local instance, I can just spin a new one up for each test run. You can't do that with firebase projects (they do now provide an emulator which is just about workable).

bpicolo 6y ago

I imagine mostly because deploying to the cloud is slow - it would be the new waiting for compiling. A fast-paced edit-compile-debug cycle is a huge development productivity benefit, and doing it via unit/integration tests and what have you is nice, but not equivalent.