6 ms·

For me, Firebase is mostly about convenience/development ease: 1. Authentication? Firebase Authentication 2. Database? Firebase Cloud Firestore. Sometimes, you

by anta40 4y ago

For me, Firebase is mostly about convenience/development ease: 1. Authentication? Firebase Authentication 2. Database? Firebase Cloud Firestore. Sometimes, you don't need SQL. 3. Push notification? Firebase Cloud Messaging 4. File storage? Firebase Cloud Storage All of my needs are served by single platform. Seems like Supabase handles all of them, except #3. Let's try :)

hn_throwaway_99 4y ago
The other thing that is really nice about Firebase is that it pretty seamlessly integrates with GCP. For example, with your #2, it's really, really easy to spin up a postgres DB on Google Cloud SQL and then access that DB from a Firebase Function. While it can get confusing sometimes, I think Firebase has done a good job "overlaying" their functionality set on top of GCP infrastructure, e.g. "Cloud Functions for Firebase" is really just a very thin layer on top of GCP Cloud Functions, Firebase Auth is basically the same thing as Google Identity Platform, etc. The author of the blog post sees that as a negative in some areas, but I don't. FWIW, I looked through the authors list of Firebase "cons", and as someone who has used Firebase for years, none of those have really been a concern for me. My biggest concern is that there are areas of Firebase that have been calling out for love for years, particularly Firebase Auth, but they've gotten virtually no updates. Apparently nobody at Google sees making these straightforward but important improvements as a path toward getting a promotion.
- fakedang 4y ago
  > For example, with your #2, it's really, really easy to spin up a postgres DB on Google Cloud SQL and then access that DB from a Firebase Function God no. The last time I checked, Firebase functions had intensively bad latency times for me. So bad that I decided to learn AWS Lambdas to get my work done. And yes, Lambda just blew Firebase and GCP functions out of the water.
  - asciimike 4y ago
    > God no. The last time I checked, Firebase functions had intensively bad latency times for me. Was this cold start latency specifically or request latency in general? Do you know what region you were deployed in?
  - hn_throwaway_99 4y ago
    I don't know when you tried this, but I don't think this is valid anymore: 1. If cold start times are a big deal, you can now set a minimum number of instances with Cloud Functions so they don't scale to 0. You can also now set concurrency on Cloud Functions so one function can run multiple requests simultaneously on a single function. 2. There are tons of other serverless options if you want to, say, have a Firebase front end but a backend API served in your language of choice that uses the Firebase Admin API to do whatever you want, e.g. App Engine or Cloud Run.
    - moring 4y ago
      > you can now set a minimum number of instances with Cloud Functions so they don't scale to 0 You can set that, but the setting gets ignored and latency is still abysmal. That was literally the reason we moved our backend to Cloud Run.
  - jsmith99 4y ago
    Firebase functions are just GCP functions. To reduce latency you can keep them warm for quite a small fee.
  - inlined 4y ago
    [cloud functions for firebase manager] Lambda is indeed an innovative and solid product. Cloud functions for firebase has been getting a lot better recently too! The biggest innovations lately has been our release of v2. V2 is built on Run and can support concurrent executions in the same container. This dramatically reduces the number of cold starts, and makes min instances reservations even cheaper if you want to eliminate cold starts for a given workload. Plus, Firebase lets you configure CPU separately from memory in V2, so you can give functions extra oomph if they need it. Docs are at [1] Finally, Firestore’s SDK was slower than we liked in GCF so we’ve done a number of improvements there. About half a year ago we redesigned the SDK so we could lazy load the networking layer. This lets you handle Firestore events without loading the bulk of the SDK. We have a more extreme update in the works that will let you configure the Firestore SDK to prefer REST over gRPC so you can avoid heavy dependencies in latency sensitive/event driven environments like GCF. [1]: https://firebase.google.com/docs/functions/beta https://firebase.google.com/docs/functions/beta
mrtksn 4y ago
Firebase is super convenient and works very well for the most part but my heart races every time I receive an e-mail from them. A silly mistake can cost you so much money and they tend to word the e-mails strongly.
- quickthrower2 4y ago
  I am not convinced it is: frameworks on nodejs, ruby, php etc. can give you most of it pretty simply for less expended hours. For any project that doesn’t care about webscaling: which is 99%
  - mrtksn 4y ago
    Sure, you can do everything yourself but when you use Firebase all that is no longer your concern. It works as if you are interacting with 3rd party API, which means you only care about the request working and you don't care how exactly they are working behind the scenes which means you care about the actual stuff you are building. Firebase does have some issues but the core premise is solid and IMHO everything will be like that as we go forward.
    - quickthrower2 4y ago
      I am not sure doing this yourself is that problematic. You can get a managed postgres - and that is most of the ops work done. The rest is npm i this/that. The effort is approximately the same as the effort go get to know firebase. I might be speaking as a jack of all trade so it seems easier to me. For a frontend only dev who needs a backend it might be different.
      - mrtksn 4y ago
        Of course it’s not that hard but why do it when you can not do it an do something more productive?
        quickthrower2 4y ago
mritchie712 4y ago
#3 is pretty simple to do in Supabase depending on what you mean. If you just need a webhook hit when some data changes, pretty easy to set up with Hooks (https://github.com/supabase/supabase/discussions/3588 https://github.com/supabase/supabase/discussions/3588). There's also `subscribe` (https://supabase.com/docs/reference/javascript/subscribe https://supabase.com/docs/reference/javascript/subscribe)
- asciimike 4y ago
  I believe they mean mobile push notifications (e.g. APNS/FCM), which ultimately flow through Apple and Google.
- anta40 4y ago
  What I mean is mobile push notification. Once I felt tempted to replace FCM with nats.io, turned out there were several cases need to handled. Oh well, back to FCM. At least, it's free.
antihero 4y ago
It made subscribing to updates really easy and that was cool
romanovcode 4y ago
"Start your project with a Postgres database" This is the main selling point of Supabase. Indeed, sometimes you don't need SQL. But in most cases you need SQL. Or you make awkward Firestore workarounds that are prone to introduce bugs and will definitely introduce complexity.
swyx 4y ago
i mean. is a world with fewer push notifications really that bad?

by anta40 4y ago

hn_throwaway_99 4y ago

The other thing that is really nice about Firebase is that it pretty seamlessly integrates with GCP. For example, with your #2, it's really, really easy to spin up a postgres DB on Google Cloud SQL and then access that DB from a Firebase Function. While it can get confusing sometimes, I think Firebase has done a good job "overlaying" their functionality set on top of GCP infrastructure, e.g. "Cloud Functions for Firebase" is really just a very thin layer on top of GCP Cloud Functions, Firebase Auth is basically the same thing as Google Identity Platform, etc. The author of the blog post sees that as a negative in some areas, but I don't. FWIW, I looked through the authors list of Firebase "cons", and as someone who has used Firebase for years, none of those have really been a concern for me. My biggest concern is that there are areas of Firebase that have been calling out for love for years, particularly Firebase Auth, but they've gotten virtually no updates. Apparently nobody at Google sees making these straightforward but important improvements as a path toward getting a promotion.

fakedang 4y ago
> For example, with your #2, it's really, really easy to spin up a postgres DB on Google Cloud SQL and then access that DB from a Firebase Function God no. The last time I checked, Firebase functions had intensively bad latency times for me. So bad that I decided to learn AWS Lambdas to get my work done. And yes, Lambda just blew Firebase and GCP functions out of the water.
- asciimike 4y ago
  > God no. The last time I checked, Firebase functions had intensively bad latency times for me. Was this cold start latency specifically or request latency in general? Do you know what region you were deployed in?
- hn_throwaway_99 4y ago
  I don't know when you tried this, but I don't think this is valid anymore: 1. If cold start times are a big deal, you can now set a minimum number of instances with Cloud Functions so they don't scale to 0. You can also now set concurrency on Cloud Functions so one function can run multiple requests simultaneously on a single function. 2. There are tons of other serverless options if you want to, say, have a Firebase front end but a backend API served in your language of choice that uses the Firebase Admin API to do whatever you want, e.g. App Engine or Cloud Run.
  - moring 4y ago
    > you can now set a minimum number of instances with Cloud Functions so they don't scale to 0 You can set that, but the setting gets ignored and latency is still abysmal. That was literally the reason we moved our backend to Cloud Run.
- jsmith99 4y ago
  Firebase functions are just GCP functions. To reduce latency you can keep them warm for quite a small fee.
- inlined 4y ago
  [cloud functions for firebase manager] Lambda is indeed an innovative and solid product. Cloud functions for firebase has been getting a lot better recently too! The biggest innovations lately has been our release of v2. V2 is built on Run and can support concurrent executions in the same container. This dramatically reduces the number of cold starts, and makes min instances reservations even cheaper if you want to eliminate cold starts for a given workload. Plus, Firebase lets you configure CPU separately from memory in V2, so you can give functions extra oomph if they need it. Docs are at [1] Finally, Firestore’s SDK was slower than we liked in GCF so we’ve done a number of improvements there. About half a year ago we redesigned the SDK so we could lazy load the networking layer. This lets you handle Firestore events without loading the bulk of the SDK. We have a more extreme update in the works that will let you configure the Firestore SDK to prefer REST over gRPC so you can avoid heavy dependencies in latency sensitive/event driven environments like GCF. [1]: https://firebase.google.com/docs/functions/beta https://firebase.google.com/docs/functions/beta

mrtksn 4y ago

Firebase is super convenient and works very well for the most part but my heart races every time I receive an e-mail from them. A silly mistake can cost you so much money and they tend to word the e-mails strongly.

quickthrower2 4y ago
I am not convinced it is: frameworks on nodejs, ruby, php etc. can give you most of it pretty simply for less expended hours. For any project that doesn’t care about webscaling: which is 99%
- mrtksn 4y ago
  Sure, you can do everything yourself but when you use Firebase all that is no longer your concern. It works as if you are interacting with 3rd party API, which means you only care about the request working and you don't care how exactly they are working behind the scenes which means you care about the actual stuff you are building. Firebase does have some issues but the core premise is solid and IMHO everything will be like that as we go forward.
  - quickthrower2 4y ago
    I am not sure doing this yourself is that problematic. You can get a managed postgres - and that is most of the ops work done. The rest is npm i this/that. The effort is approximately the same as the effort go get to know firebase. I might be speaking as a jack of all trade so it seems easier to me. For a frontend only dev who needs a backend it might be different.
    - mrtksn 4y ago
      Of course it’s not that hard but why do it when you can not do it an do something more productive?
      - quickthrower2 4y ago

mritchie712 4y ago

#3 is pretty simple to do in Supabase depending on what you mean. If you just need a webhook hit when some data changes, pretty easy to set up with Hooks (https://github.com/supabase/supabase/discussions/3588 https://github.com/supabase/supabase/discussions/3588). There's also `subscribe` (https://supabase.com/docs/reference/javascript/subscribe https://supabase.com/docs/reference/javascript/subscribe)

asciimike 4y ago
I believe they mean mobile push notifications (e.g. APNS/FCM), which ultimately flow through Apple and Google.
anta40 4y ago
What I mean is mobile push notification. Once I felt tempted to replace FCM with nats.io, turned out there were several cases need to handled. Oh well, back to FCM. At least, it's free.

antihero 4y ago

It made subscribing to updates really easy and that was cool

romanovcode 4y ago

"Start your project with a Postgres database" This is the main selling point of Supabase. Indeed, sometimes you don't need SQL. But in most cases you need SQL. Or you make awkward Firestore workarounds that are prone to introduce bugs and will definitely introduce complexity.

swyx 4y ago

i mean. is a world with fewer push notifications really that bad?