20 ms·

We're moving on from Firebase

344 points by jackconsidine 4y ago

endisneigh 4y ago
It’s sad to see people invest in things like firebase without understanding my the technology. Right tool for the right job. If you don’t need scale then you don’t need firebase. If you need joins, don’t use firebase, etc etc. If one insist on using a proprietary managed database I’d use Spanner.
- johndfsgdgdfg 4y ago
  I absolutely agree. Moreover with any Google products you will never know when they will shut it down or hike the prices like they have done countless times.
  - endisneigh 4y ago
    In my opinion one should refrain from any managed service that can’t be self hosted. Not clear to me why the authors don’t use managed Postgres. Supabase is close enough I suppose. Personally I don’t see what you get with supabase vs an Orm and vanilla managed Postgres.
    - moooo99 4y ago
      The appeal for firebase is that you can get away without your own backend for quite a while. It's perfectly feasible to consume databases directly from your frontend app without having to deal with a lot of caching or networking concerns, the firebase SDK does that for you. You basically get a complete API layer without having to write a lot of code yourself. It is very similar with stuff like auth handling, which is also tightly integrated into the database offering. This makes development incredibly easy, especially in early stages and if you're starting out as a solo/small scale project. It is even better if you don't have an in depth knowledge about backend development/architecture and just want to build a product. You don't get any of those benefits with a regular managed Postgres offering, at least not that I'm aware of. Supabase comes a lot closer to firebase than a regular managed postgres + ORM offering would but you also get an oepn source project that you could potentially self-host. from what I heard self-hosting Supabase is possible, but a rather complex undertaking. There is some documentation around it, but is definitely a lot more complex than using their hosted offering is.
- danielvaughn 4y ago
  I’ve been pretty critical of Firebase on HN, perhaps too strongly. My experiences with it have all been the same, it goes like this: Client has a new-ish codebase that was written by relatively inexperienced front end developers. They aren’t confident enough in the backend, and are attracted to Firebase because it lets them write everything from the front end. Then they proceed to create the most convoluted DB model and a spaghetti backend that’s split between the front-end repo and various cloud functions. In practical terms it’s been a nightmare every time, for me personally.
  - trefoiled 4y ago
    It's amazing just how accurately this describes my exact experience as a FE engineer tasked with creating a newish codebase for a client.
- deleted 4y ago
  [deleted]
  - deleted 4y ago
    [deleted]
- nicoburns 4y ago
  Is Firebase even capable of supporting high scale? My experience with it has been that performance is pretty poor when working with large datasets.
  - rockwotj 4y ago
    Firebase is a large suite of products - are you talking about the Realtime Database? The answer is it depends on what "high scale" is. There are parts of the RTDB that didn't scale well when I worked on it (indexes are built in memory on demand so building the initial index is slow), but there are projects that could fix that.
  - bootloop 4y ago
    Realtime Database? No. Firestore however, scales as most GCP services do and is it's in-house built replacement.
skywhopper 4y ago
The CLI complaints, while relatable, are pretty minor. It seems they believe shell scripting is a dirty hack. But in that case, why not just write a clean program to pull the values in the form they want from the API or SDK?
- hinkley 4y ago
  Part of my evolution with regard to Single Responsibility Principle has been to start exposing command lines for some modules. It makes it a lot easier to write integration tests for one, but it also helps people know the interaction boundaries of a particular module. Because if they aren’t in the dependency list, either the program doesn’t work or it doesn’t talk to that code. It’s also a lovely bit of friction to Kitchen Sink Syndrome, because it’s just that little extra pain in the ass to cross link everything to everything instead of gating it through nexus modules versus leaf modules. The CLIs usually stay as debugging tools, but in some cases they have gotten incorporated into more complex tools, such as to add more hints and hyperlinks to out deployment management tools.
- jstrong 4y ago
  I dunno. There's nice CLI interfaces and there's one's that make things annoyingly hard to do. I haven't used firebase ever but I have had that problem before.
glacials 4y ago
As a side-project Firebase user, I empathize with it being slowly consumed by GCP. I don’t have the time or inclination to learn GCP for a side project. I opted for Firebase because it had a great developer experience. As time toes on and more and more Firebase features are redirected to GCP equivalents, the DX value prop is being drained out of the product and I’m left not even understanding my own infrastructure. I’m thankful the author pointed out Supabase, it seems like a great alternative.
- inlined 4y ago
  [cloud functions for firebase manager] I understand that the decision to shuffle users to GCP for logs was controversial. It wasn’t decided, as some have said here, because some director had an OKR to fluff up; it was because our UX team couldn’t keep up with the sheer amount of innovation in GCP’s observability suite. Check out Daniel Lee’s talk next Tuesday on observability and cloud functions for firebase for some cool tricks. Did you know, for example, that you can jump into the trace for a log line in GCP? That you can create custom metrics with alerts? That you can filter by structured log segments? I think a tutorial could smooth over the transition, but I think this decision was for the best. If you want a super simple logs reader for in-the-moment analysis, try the CLI command “firebase functions:logs”
  - holografix 4y ago
    What if 741 new features are introduced to Cloud Logging, will these be forced onto the Firebase user? Oppression of choice is a real problem. Firebase must cherry pick the best of the new features and wrap it in their own UX in order to stay relevant. Being booted into a completely new and unfamiliar UX with dozens of knobs and dials is a jarring experience. It might not have been a managers OKR but it’s very obvious that in an effort not to lose the “whales” your casting the new too widely and potentially killing a lot of smaller fish.
  - glacials 4y ago
    I appreciate your reply and I believe every word you have said. Thank you for the hard work and thought you and your team have put into your products, and I'm sorry to hear if anyone is casting you as faceless corporate politicians reaching for meaningless goals. I know exactly how that feels. To be frank with my feedback, I am a person who uses Firebase for a side project. I don't have the mental capacity to watch an ~hour talk for each piece of GCP infra I don't understand. I liked Firebase because I could understand it intuitively through its UX. I'm sure the GCP features are very helpful and innovative and I'd get a great ROI from the talk if I worked on them for my full-time job. But some weeks, an hour is all I have. I'm an app developer and I would just like to deploy my app please, and have the rest fade into the background, or at least integrate with my existing workflows. Thanks for all your hard work. I understand if "side project developers" is not the top of your funnel. But I hope you hear my feedback.
simscitizen 4y ago
> We plan to do more research on scalability, since column-based databases can’t grow as big as their NoSQL counterparts. This one sentence makes me question this firm's expertise. "Column-based database" has a meaning, and Postgres definitely isn't one of them.
- duxup 4y ago
  I’m confused by that line and it made me wonder about their experience or PoV as well. But as someone who doesn’t word smith good, could just be that.
- deleted 4y ago
  [deleted]
- jackconsidine 4y ago
  Author here- poor choice of words, thanks for pointing out. I was getting at the fact that SQL systems don't scale as well horizontally (it's difficult to distribute the same column across multiple machines), and inadvertently used a technical term connoting something else.
  - randomdata 4y ago
    > I was getting at the fact that SQL systems don't scale as well horizontally Google, for example, claims that BigQuery, which uses SQL, scales horizontally. Funnily enough, it is also column-based. Row-stores, like MySQL Cluster, can also scale horizontally and uses SQL. But no matter what you are at the mercy of CAP theorem. Pick your poison.
    - jackconsidine 4y ago
      100% agree on the CAP theorem conundrum. I didn't know that BigQuery was SQL under the hood, interesting.
      - randomdata 4y ago
tmountain 4y ago
Is there anything like Firebase that lets you use SQL like schemas instead of their data store? That would fill a nice niche for some use cases I have been working with.
- endisneigh 4y ago
  Managed cockroachdb, along with some others like fly.io.
- rossfishkind 4y ago
  Supabase is awesome and open-source
- gman83 4y ago
  I've been playing with Pocketbase which uses SQLite: https://pocketbase.io/ https://pocketbase.io/
- PKop 4y ago
  Supabase
- hn_throwaway_99 4y ago
  It's really easy to add a Google Cloud SQL database in GCP which then can be accessed by, for example, Firebase Cloud Functions. It's also very easy to mix/match parts of Firebase with GCP. For example, you can very easily deploy a server-side API on a plethora of GCP technologies (i.e. App Engine, Cloud Run, a dedicated Compute instance, etc.), deploy a front end with Firebase Hosting, use Firebase Auth for user authentication, then when you call your backend API you can verify the authentication using the Firebase Admin APIs.
- _query 4y ago
  Check out thin.dev https://thin.dev/ https://thin.dev/ It uses SQL DDL statements literally as the building blocks for everything.
- fakedang 4y ago
  Supabase
alexose 4y ago
From the article: "Being closed-source, you don’t have the implicit assurance that Firebase will always be around (like Parse), nor can you reliably depend on a specific API version." Firebase is amazing, but I'll never use it for anything that's meant to last more than a year. I don't trust the API to remain stable, and I _especially_ don't trust Google to keep it running for the long term.
- deleted 4y ago
  [deleted]
- garren 4y ago
  Exactly. s/closed-source/google/ I've not used Firebase, but seeing as it's not, as far as I can tell, "core" Google (i.e., not related to search or advertising explicitly), I'd be concerned about relying on it in any substantial, business-critical, way.
  - inlined 4y ago
    I’m not a VP and there is no way to promise that we’ll “never” be shut down, but Firebase is a successful product and additionally drives a lot of Cloud usage (which is certainly “core”!). I just don’t see any reason why a VP would need to sunset firebase to balance any books.
- asciimike 4y ago
  The RTDB APIs have remained stable and available since ~2012. Storage has existed in the same way since ~2016. Do you have some specific examples of build APIs changing on you in ways that break your applications?
  - alexose 4y ago
    The first application I wrote for Firebase was back in 2015, before it was acquired. I don't remember the specific issues, but I know I spent about the same amount of time trying to keep it running post-acquisition as I did building the app in the first place. I tried again in 2019 and got burned by Cloud Functions Node runtime changing underneath me. Edit: I should point out that averaging a single breaking change every five years means that an application has a 20% chance of being affected each year. I'm not willing to roll the dice, generally speaking.
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?
lordofgibbons 4y ago
>Authentication out of the box is nice. (Built-in Firebase email-verification is, in our opinion, a poor experience though). >Firebase mandates Google / GSuite sign-in Is Firebase authentication different from GCP Identity Platform? I've read the docs for both Firebase and Identity Platform and the lines seem blurred.. Do these issues extend to Identity platform? I haven't heard of many people using it, but it looks very feature-rich.
- dilatedmind 4y ago
  They are the same, there is also some functionality for managing firebase auth users in the gcp console.
- hn_throwaway_99 4y ago
  Yes, they are the essentially the same (again, more confusing branding). Firebase Auth is great, with the notable exception that I am worried it will become Google project #2898 to die on the vine. It has received virtually no substantive updates for about 2.5 years. The last big one was they added SMS 2FA in early 2020. Given that Google themselves has long ago stated SMS is insecure for 2FA, it's ridiculous they have no other options, nor have they said anything about adding options in their official channels. Here's a post from Dec 2021 in the google groups forum, and again there have been no real substantive updates since: https://groups.google.com/g/firebase-talk/c/RBRdDHPybC8 https://groups.google.com/g/firebase-talk/c/RBRdDHPybC8 > Is Firebase Authentication dead? > I apologize for the inflammatory subject line, but I think this is an important matter that the Firebase and Google team should be transparent about. > What does the future of Firebase Authentication look like? Is it in maintenance mode? Is there any roadmap for future development? > I migrated my user base to the Firebase platform a few years ago, mainly based on their Authentication platform. It looked like it had a lot of promise. There was a lot of development going on with it at the time. Although it didn't have all features I wanted, the pace of development seemed to show a good trend line going in that direction. At the time, they said MFA was on the roadmap. I considered other AaaS options, but chose Firebase Auth based on where I thought it was going in the future. > Fast forward a few years, and it seems like there is no activity any more with Firebase Auth. I'm still waiting for TOTP and WebAuthN MFA. SMS is not a no-starter, and even Google has said that SMS is not secure MFA. There is no way to control the password strength policy, nor lock-out behavior when incorrect passwords are entered. > Now I need to make a decision: whether to stick with Firebase Auth, or to move on to a different AaaS platform. Will Firebase Auth pick up the feature development pace again, or is it on a long death spiral? I'd appreciate insight from Google what their plans are in a concrete way. > Thank you.
norwalkbear 4y ago
For videogame development, firebase is godsend. Just an absolute easy way to add features into mobile games. Core competencies of most game devs aren't web stacks. I can see how web devs might feel differently.
- giancarlostoro 4y ago
  Also could see it for mobile devs trying to get an idea going.
  - fakedang 4y ago
    I thought the same way, but I think now Supabase is much better than Firebase. Simply because you get a lot more functionality from the postgresql DB compared to the nosql DB.
    - endisneigh 4y ago
      It’s sad how people don’t use things for their intended use case. The main thing you’re buying with firebase is scalability
      - paulgb 4y ago
        “Intended” according to whom? The firebase landing page makes a couple references to being scalable, but otherwise it doesn’t appear that using Firebase at a smaller scale is outside its intended scope at all.
        endisneigh 4y ago
        Intended accordingly to the technology, not marketing
        paulgb 4y ago
        What does “intended according to the technology” even mean? Just because software is built to scale up, doesn't mean that using it at a smaller scale goes against its intention. Marketing copy aside, it's not as if the technical docs discourage people from using it for non-scale use cases.
joshe 4y ago
Google's internal developer hazing and poor DX surely have something to do with this. I've talked with multiple ex coworker developers at Google about the 3 to 6 months it takes to actually figure out how to deploy something. Also the constant overhead of approvals and oddball systems (gerrit!) thereafter. Eventually good DX seems unimportant and even associated with failure. Real programmers grovel to weird dependancies and find out stuff the hard way. There's a better alternate universe where Firebase and 2010 era Google App Engine are the template for GCP.
- kotlin2 4y ago
  I still have no idea how to navigate a Gerrit PR. I sometimes land on one trying to investigate a bug in Chromium or something like that. I’m sure Gerrit’s approach has some benefits, but it definitely fails at showing a simple before and after view, i.e. “here’s what changed.”
  - hinkley 4y ago
    When change is hard people start over. Anything in your system that adds friction to modifying existing code (be it source structure, lack of static analysis tools, build shenanigans, diff tool) encourages people to copy instead, or reinvent.
- SkittlesNTwix 4y ago
  > internal developer hazing Could you expand upon what you mean by this part?
  - piotrkaminski 4y ago
    Not OP, but I'm guessing they're referring to the "readability" approval process, which can sometimes be pretty brutal. (Or at least that was the case a decade ago, don't know how it's evolved since.)
- hinkley 4y ago
  People with a high pain threshold create systems that require a high pain threshold. That filters out a lot of people with a low tolerance for bullshit. Then the “indispensability” of people who built job security into the system filters again.
eikaramba 4y ago
I have to also mention https://directus.io/ https://directus.io/ here. Coming from Strapi, Feathers.js and Supabase i have to admit it is the closest competitor to Supabase i know. There are things Supabase is doing better but the Admin Interface and the Customization Capabilities of Directus are just unmatched.
- soulofmischief 4y ago
  How would you compare it to Feathers?
- threatofrain 4y ago
  https://appwrite.io https://appwrite.io
seibelj 4y ago
> We love PostgreSQL which Supabase utilizes. We plan to do more research on scalability, since column-based databases can’t grow as big as their NoSQL counterparts. I would argue there are very, very few types of problems NoSQL solves better than relational DB, and the “benefit” of quickly deploying schema changes is actually a nightmare later on. That it took so long for these devs to realize this is… perplexing
- klabb3 4y ago
  If you have more write queries than a single machine can handle you're in trouble though, right? Not defending NOSQL in any other way, but this could be a legit requirement for some apps, no?
  - parasubvert 4y ago
    There are over a dozen distributed SQL database projects out there, and as many middleware to shard SQL databases. Some of the worlds largest properties , eg. Meta , largely run on MySQL. Eg. https://engineering.fb.com/2016/08/31/core-data/myrocks-a-space-and-write-optimized-mysql-database/ https://engineering.fb.com/2016/08/31/core-data/myrocks-a-sp...
  - seibelj 4y ago
    A firehose of ingestion is a specific problem that can be solved. But basing your entire application on a nosql data store is a mistake - quick and dirty now for pain and tears later.
hilti 4y ago
I‘ve been using Firebase and Firestore extensively in past projects, because I was attracted by it‘s simplicity on first sight. Then there’s the day you need some relational queries. It‘s somehow possible, but you need to rethink your data structure. Then you figure out, that the realtime part of Firebase is CPU intense and slows down your browser. Call me nuts, crazy or whatever - I‘ve replaced most of these applications with SQLite (WAL enabled) and use either server-side-events (SSE) for almost realtime notification or the HTTP streaming API. It works perfectly for my needs and is pretty simple to deploy.
- honzajde 4y ago
  How would you handle "db-notifications" with sqlite - to my knowledge this is a reason why you would need postgresql with its' (pg) NOTIFY
  - b3morales 4y ago
    SQLite calls this an "update hook": https://www.sqlite.org/c3ref/update_hook.html https://www.sqlite.org/c3ref/update_hook.html
    - rockwotj 4y ago
      SQLDelight had neat built in support for this https://cashapp.github.io/sqldelight/ https://cashapp.github.io/sqldelight/
    - hilti 4y ago
      Exactly! Or in some cases I create a view - for example a highscore list - that is queried by a simple server-side script and sends the data as JSON to the client.
- marviel 4y ago
  You should check out supabase -- it takes this pattern (with a Postgres backend instead) and packages it up in an open source, cloud hosted but also self-hostable model
tlarkworthy 4y ago
Supabase has distributes consistency issues and not suitable for multiplay/offline first. I am annoyed at firebase for real technical reasons like Firebase auth can delay page load by several seconds. So the real alt to firebase (on web) is replicache IMHO
- marviel 4y ago
  Can you speak more about the issues with Supabase you describe?
  - tlarkworthy 4y ago
    https://twitter.com/tomlarkworthy/status/1561099104356159488?t=QAwEroZUIyHCJCiBUGNSTA https://twitter.com/tomlarkworthy/status/1561099104356159488...
zackmorris 4y ago
My recollection is that progress on Firebase stopped when Google bought it, and I haven't followed it for almost a decade. Does anyone know if these basic features were ever added? 1) It used to download the whole state (write history) upon startup. Did they ever update it to send a snapshot, or a partial view of the data with lazy-loading for additional nodes? 2) Did they ever provide a simple push notification service? That was pretty much the only thing missing to be able to run Firebase without another server. 3) Were node aliases/shortcuts ever implemented, so a node could be a reference to another node? That would have greatly reduced the need for a SQL JOIN alternative. Also, after having done some cloud dev ops work, I can't endorse it from any provider at this time, as the burden of securing things like user permissions is beyond what humans are generally capable of, so I consider them an anti-pattern. A better pattern is token-based authentication for everything, using standard web metaphors and REST APIs, so that every service behaves like a sandboxed root user with limited abilities granted. I also wouldn't use any cloud service without Terraform or a similar declarative infrastructure manager. Meaning that the best cloud service is basically the best Terraform configuration, providing a higher level of abstraction like Heroku, which largely defeats the purpose of direct cloud hosting in the first place. So.. the cloud is no substitute for Firebase, and if it goes that route, it will be no surprise if customers jump ship.
- duxup 4y ago
  >Firebase stopped when Google bought it I duno about that. I've seen lots of new features for Firebase for a number of years now.
- asciimike 4y ago
  > My recollection is that progress on Firebase stopped when Google bought it, and I haven't followed it for almost a decade. Firebase launched an alpha in April 2012 and got acquired in 2014, so I'm not sure how you've stopped following it for a decade because it's only existed for about that. > 1) It used to download the whole state (write history) upon startup. Did they ever update it to send a snapshot, or a partial view of the data with lazy-loading for additional nodes? Yes, that feature shipped in 2014. > 2) Did they ever provide a simple push notification service? That was pretty much the only thing missing to be able to run Firebase without another server. Firebase integrated with Google Cloud Messaging in 2016. Cloud Functions (which was also 2016-17) allowed operation without a server. > 3) Were node aliases/shortcuts ever implemented, so a node could be a reference to another node? That would have greatly reduced the need for a SQL JOIN alternative. No, the guidance was to duplicated data across paths (when Cloud Functions existed, folks used them).
james_cowling 4y ago
Firebase has been a huge influence but with the rise of serverless there are a new generation of platforms people should be checking out instead, such as Convex, Supabase, etc. Convex in particular is designed far more for end-to-end consistency rather than just a database to talk to: https://docs.convex.dev/understanding/convex-vs-firebase https://docs.convex.dev/understanding/convex-vs-firebase
- temp_praneshp 4y ago
  Consider adding a disclaimer that you're the founder of Convex
  - redanddead 4y ago
    Exhibit A in reasons to probably not use convex
  - james_cowling 4y ago
    Yep that’s me! I have my full name on here so wasn’t hiding but good point to be clear about disclosing.
    - ranguna 4y ago
      > full name on here so wasn’t hiding Unrelated to the OP's suggestion.
coys 4y ago
Jack Considine is always a good read
coupdejarnac 4y ago
I see Supabase's Realtime hasn't reached the production milestone yet. How far away is that? I'm interested in using it for an offline first app. Watermelon sync would be nice.
- kiwicopple 4y ago
  It’s pretty close - we just added Presence and Broadcast. As soon as we are confident that they are stable at scale then we will consider it GA (probably a few months)
abraxas 4y ago
> You also therefore can’t truly run Firebase locally. To me this is just incredible. As an old timer who learned the ropes in the late eighties it never crossed my mind (what with computers always getting faster) that we would once again face the situation that developers can't run their software locally. It's like a bloody throwback to the sixties and the days of punchcards and timesharing systems. Thanks but no thanks! It's such a friction factor that all other benefits of the platform get overshadowed by this. It's the same reason I'm vehemently opposed to my team using AWS Lambdas for anything non-trivial. And no, SAM is not the answer here.
- imachine1980_ 4y ago
  correct me if i'm wrong, you can run lambdas locally whit firecracker, lost all the benefits of serverless (you are self-hosting) but you can do it if you need it.
  - paulgb 4y ago
    Lambdas are run on Firecracker, but firecracker is just a runtime, it doesn’t include the rest of the FaaS stack Lambda provides.
- easton 4y ago
  > It's the same reason I'm vehemently opposed to my team using AWS Lambdas for anything non-trivial. And no, SAM is not the answer here. I’ve had to start using Lambda at work and this is my biggest problem. Waiting minutes to see if it was a typo or if there’s a larger problem is terrible. I miss Docker.
  - spion 4y ago
    SST (https://sst.dev/ https://sst.dev/) has been a game-changer for me, it makes serverless bearable.
- deleted 4y ago
  [deleted]
tc08 4y ago
TL:DR; We don't want to use GCP and we don't like that Google.is intergrating Firebase into it. As someone who is running on GCP, I can't wait for them to fully merge Firebase into the GCP dashboards. Not a high vakue article, really...
klabb3 4y ago
It's funny because Google pretty much invented this model that users want and love. App Engine was launched in 2008, before GCP, before docker and before Cloud was a term, basically. It had a globally replicated persistence layer, job queues, auth, scale to 0, a generous free tier, a fully fledged local dev server and a single command to deploy, and all config lived in a single file. At the time it was really innovative, and attracted a lot of hip startup- and college grad types. The reason people liked it is, imo, because it was a single product with multiple features. GCP OTOH, has been about decoupling (or loosely coupling) the product suite, and users are supposed to pick and choose from a giant array of half-products. Simply being aware of all products, their interoperability and predicting the cost is a full time job, easily (it's mostly large enterprise who can absorb that cost). There's nothing wrong with the pick-and-choose model, if your products are simple, low level, and interoperable. But the product suite has grown organically, seemingly without coherence, so there's very little in terms of paved paths to walk – it's so confusing. When a shining star like Firebase comes along (2014) Google clearly knows not to mess with it too much. But even Firebase isn't strong enough to resist the gravitational pull of the GCP behemoth.
- lowbloodsugar 4y ago
  Yeah I was there. It was great because it was, apparently, impossibly cheap. Then they decided to take it out of beta and jack the prices. People who were spending $10/mo suddenly had $1000/mo bill. Never trust google.
  - klabb3 4y ago
    Yeah I don't think PaaS should ever be proprietary in terms of API surface. It's just perverse incentives, you get subsidized until market saturation, and then they jack up the prices. The cloud providers should, imo, compete on uptime, resilience, performance, etc. Kinda like the VPS or VPN providers of today.
    - asciimike 4y ago
      Let's take a quick example of S3: GCS was able to take the same API and they both compete on uptime, performance, etc. Price/GB has remained stable or decreased with new tiering options over time. Managed K8s clusters, SQL databases, etc. are all competing in similar ways. If folks want to build proprietary APIs, and people choose to use them because they are faster/better/cheaper/more suited to a particular use case, I'm not sure why that's a bad thing. Engineering is tradeoffs, proprietary API surface is one of many things people consider.
pier25 4y ago
I've been using Firebase since 2016 in production. Still have a couple of projects there but I will not start another project with Firebase. I would only use it for quickly prototyping something that I'm 100% sure will be trashed later. Otherwise there are just too many issues with it for anything remotely serious.
- asciimike 4y ago
  Not saying there aren't issues, but would you mind elaborating on some of the issues you've experienced?
  - swid 4y ago
    I ran into unexpected difficulties from Firestore - the queries only allow 1 range clause, the transactions only allow up to 500 updates, and you can either search 1 collection or all of them with the same name. This was a problem for us when applying a template to the schedule - templates could have over 500 appointments (so difficult to apply the template in 1 tx), and not being allowed two ranges meant we could test the appointment starts but not the end. The collection issue came up because we had appointments off of users off of orgs. It was impossible to search all the users within an org/tenant the way we set it up. Either search in 1 user or all users in all orgs. We ditched all of firebase and I’m happy we made that decision early enough.
  - pier25 4y ago
    Where to start... The databases are completely useless for anything other than trivial demos. Cloud functions are plagued by cold starts and deploy usually takes minutes. These are by far the worse cloud function offering in the market right now. Storage is fast but it is extremely overpriced. The JS client used to be super heavy. I think they've improved that with tree shaking but still, if you're using all their services, you will end up with huge JS bundle just for the Firebase stuff. All your app becomes deeply locked in into Firebase. It's designed so that you have to invest a huge dev effort if you want to leave. Firebase could have adopted standards like GraphQL or maybe added a PG offering like Supabase, but no. The static hosting is probably one of the slowest options in the market. At least that was the case in 2020 when I did these benchmarks. https://www.pierbover.com/posts/static-hosting-benchmark-2020/ https://www.pierbover.com/posts/static-hosting-benchmark-202... Honestly I could go on but just don't use Firebase.
patientplatypus 4y ago
neom 4y ago
Very tangentially.. In the early days of DigitalOcean, I was fortunate enough to spend time with most of the devtool CEOs, Leibert, Polvi, Hykes, Newcomb, Collison, etc etc etc. All very smart guys. However James (and Sara!) was one of the most brilliant thinkers I came across. It's always been somewhat of a shame to me he didn't keep building firebase independently. Knowing him (shyguy), I'm not surprised he sold it to google, but I feel like we need to make more space for shy/guys/gals/*. How many of you think Dokku is awesome? But are we doing enough to support folks like Jeff Lindsay (shyguy)? Yeah, firebase was awesome when James was still working on it, people like him and Jeff Lindsay (@progrium) are surely brilliant thinkers. How do we support them (shy-folk ceo)? (https://news.ycombinator.com/item?id=7844457 https://news.ycombinator.com/item?id=7844457)
- jamest 4y ago
  Those words are far too kind! Most of the credit goes to my co-founder, Andrew, and the whole team who gave nothing short of everything to build it.
  - neom 4y ago
    You did a great job James. Yes Andrew and Sara and the team were pivotal, but you CEO'd it... I'll never forget when you showed me that weird arcade game y'all used to demo, the paradigme shifting was high and you did a fantastic job of explaining why. Hope you're well old friend. :)
- deleted 4y ago
  [deleted]
esskay 4y ago
No mater how good Firebase or any of Google's cloud offerings are I could never trust them enough not to just decide to pull the plug one day like they eventually do with every product they launch. They've made themselves untrustworth, and not just from the usual privacy issues.
- campbel 4y ago
  Yep. Partnering with Google feels like building on sand sometimes.
- redanddead 4y ago
  Yeah google should address this
quickthrower2 4y ago
I enjoyed reading this having battled with firebase on a personal project. It has just enough quirks that I now prefer postgres unless I need all of the firebase features desperately. > It seems that GCP is cannibalizing the Firebase developer environment. Yeah as a latecomer I got this impression and rolled my eyes. I imagined a debate in the office between an passionate Firebase OG and a Google exec holding an OKR portfolio, the passionate engineer trying to delay the inevitable gobbling up of firebase! For me Firebase has lot of cuts, maybe not 1000 but things like: * No formal definition of rules, just some very scant documentation. Much of it is undocumented or can only be found in SO answers. * Emulator fatigue! Like Azure storage, the emulator is a good approximation to the real thing but you end up chasing down bugs locally when it is an emulator quirk. Postgres OTOH you run the same thing in prod. Same for mongodb, mssql, mysql etc. * Firebase admin sdk has a completely different API to the normal sdk to do all the same things! I get it: smaller JS bundles, but why not just reuse a lot of those changes in admin? * You have to have a local file with authentication secrets to a cloud db in order to run the emulator! I just have a test deployment for this but it feels unnecessary. * I don’t think the model of letting users upload json directly to collections is secure- unless you are a genius with firebase rules. This might be more of a general criticism of nosql over http. CouchDB might have the same issues I guess. * Rules bugs like if you do a query with clauses your rules don’t have access to the entire object just the queried fields. You need to add ghost fields to the query to make the rule run properly. Probably more things I forgot about too. I am even tempted to reverse engineer rules to write a proper guide. If that sounds interesting let me know. Finally I prefer open source stuff for a lot of the usual reasons. So closed source stuff has to be beyond excellent to make sense to me to use.
- asciimike 4y ago
  > I am even tempted to reverse engineer rules to write a proper guide. If that sounds interesting let me know. No need to reverse engineer them, I built them, so I'm happy to answer any questions you may have (to the best of my memory). > * I don’t think the model of letting users upload json directly to collections is secure- unless you are a genius with firebase rules. This might be more of a general criticism of nosql over http. CouchDB might have the same issues I guess. It's a general criticism of any "access your database/storage bucket/etc. directly from the client" product--everyone has to build _some_ authZ mechanism that lives in between the client and the server, whether it's Firebase Rules, Postgres Row Level ACLs, Lambda Authorizers, etc. Otherwise you're writing your own authZ code on your own server, which has it's own set of issues. > * No formal definition of rules, just some very scant documentation. Much of it is undocumented or can only be found in SO answers. I don't think https://firebase.google.com/docs/rules https://firebase.google.com/docs/rules is the best documentation ever, but I'm not sure "scant" is the word I'd use to describe it. What are the main areas you think are missing?
jamest 4y ago
[Firebase founder] 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://news.ycombinator.com/item?id=3832877 https://news.ycombinator.com/item?id=3832877) and there are now some great innovations in the space. I like the way Supabase (https://supabase.com/ https://supabase.com/) has exposed Postgres and InstantDB (https://www.instantdb.com https://www.instantdb.com) graphdb+realtime is really promising.
- gedy 4y ago
  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
- quickthrower2 4y ago
  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.
  - 4y ago
deleted 4y ago
[deleted]
inlined 4y ago
Hi there, I’m the manager of Cloud Functions for Firebase. I wanted to note that Firebase is getting better for large deployments and we’re continuing to invest in the area. First, the article might have been written before our recent feature to skip deployments of unmodified functions. If the source, env, and secret metadata SHA has not changed, we skip deploying that function. At minimum, this means large deployments that fail can be retried and make progress (more on that below). Second, we’ve started investing in a feature called “codebases.” At its simplest, codebases are multiple folders of functions. This makes it easier to deploy single codebases, but it also means you’re likely to skip deploys of functions in codebases other than the ones you’re working on. If you want to invoke functions in another codebase, consider a Pub/Sub, Task Queue, or Eventarc Custom Event (coming in a few weeks) function depending on the feature set that suits you best. Codebases are just getting started and we have hopes to develop this feature in the future. Finally, we’ve set aside budget in Q4 to rewrite part of the core of our deployment logic to improve the way we batch, backoff, and retry function deployments in the face of quotas (yes, they are retried multiple times, even when we give up due to quota errors). We hope to substantially raise the reliability of 100+ function deployments.
- bcjordan 4y ago
  That's awesome to hear there's ongoing investment in the Firebase/GCP functions space! I'm in touch with many game developers who use or considered Firebase Functions/GCP Functions for their backends/player data web services. Figure I'd pass along the primary gotchas/complaints I hear, since it sounds like many of them are being actively addressed in the work you mentioned: - Time from deployment to availability feels very long compared to alternatives. Firebase Functions (even for 1-3 functions) can be 1-3 minutes long. I've heard it's much longer for more functions (/ maybe region dependent?) - Cold Starts are a major pain to deal with. Workarounds like minInstances are expensive/subvert the scale to $0 value proposition/don't solve latency in the scale-up case, and are charged per function. Some devs refactor their backend to be a single function endpoint to work around this and minimize cost which seems to contradict the small functions development style demonstrated in the docs. - It'd be nice to have more serverless-friendly datastore primitives within the GCP ecosystem that can (1) scale to $0/mo base for pricing, (2) handle high write throughput (including per entry) and (3) support serverless connections well. RTDB, Firestore, Datastore, Memorystore, Spanner, Alloy etc. don't quite nail all those points. Something based on Spanner or an elastic sort of Memorystore that really scale down to $0 for cost could be amazing. Some are migrating to Cloud Run to have concurrency per function, though it sounds like Cloud Functions v2 gets very close to that use case once it's available across all regions. I love Firebase Functions since it really nails the use case of: (1) start from $0, prototype your application quickly, (2) scale up to withstand practically infinite traffic at reasonable cost without having to change any code, (3) seamlessly graduate to using more of a high quality cloud platform without having to change any code. It's rare to find and other efforts haven't matched the overall dev UX. Outside of cold start spikes the platform is very stable and hands-off, and has incredible logging/metrics/alerting available from the GCP side. Separately I worry the GCP ecosystem is missing a story around cheap/fast edge functions and integrations with next-gen frontend tooling which often rely on many quick API calls. (It would be interesting to see something like a Firebase acquisition & integration targeting that world of tooling) If there were a scale to $0 edge datastore like PlanetScale/UpStash + scale to $0 edge functions offering with the simplicity and GCP-integration of Firebase it would be awesome.
LAC-Tech 4y ago
it is impossible to do anything remotely similar to a SQL join. Therefore, developers must embrace the ethos of NoSQL by distributing relational data ahead of time. Can someone help me translate this? Are they saying that since there's no joins they store their aggregates denormalised upfront? Or what?
habosa 4y ago
Re: Extracting a machine-readable CI token Don’t do that! Firebase CI tokens are not a good way to authorize with Firebase anymore. Use a GCP Service Account which you can scope very precisely and remotely adjust permissions / track usage.
tinyprojects 4y ago
I really miss firebase function logs. Even though it was a bit glitchy at times, it was the perfect simplified overview of everything on my backend, and fitted well with the simple UI of firebase. I'm sure I'll get used to Google Cloud logs - but it just feels really out of place now.
philliphaydon 4y ago
> We love PostgreSQL which Supabase utilizes. We plan to do more research on scalability, since column-based * SQL databases can’t grow as big as their NoSQL counterparts. Nonetheless, Supabase came at the right time. > * Edit: poor choice of words Where do people get this idea that sql cannot scale or grow? Ever since this fad of “NoSQL” we have ended up with these false claims everywhere.
- parasubvert 4y ago
  That’s what’s called successful marketing, at least with a segment of developers that never looked hard at databases, and bought into the NoSQL claims. The decades long market debates over network, hierarchical, object vs SQL databases are also a distant memory for most. There’s good technical reasons SQL remains dominant, but again, a segment of folks aren’t incentivized to learn why.
sebag1507 4y ago
[I work at Firebase, but opinions are mine] First and foremost I appreciate the time you spent putting together the article. Feedback is a gift and always welcome. I'll address your main point: Firebase and GCP. Over the past decade, developers have consistently turned to Firebase as the fastest way to take their idea to market, thanks to an innovative client-first model and a singular focus on developer experience. Our goal is to provide a comprehensive and "opinionated" platform that just works, saving considerable development and maintenance time. We consciously build some of our services on top of GCP primitives like Cloud Storage and Cloud Functions. This allows us to best apply our team in continuing with our mission, while also making sure that our users never outgrow the platform in any dimension (security, scalability, compliance, etc). You bring up excellent points as far as our UX and better integration opportunities. My goal is not to necessarily push developers to GCP. The way I see it is that both platforms serve users with different use cases and preferences. Some will use one over the other, and many will use both. I would love to continue the conversation and I hope you don’t mind if I try to reach out.
- jackconsidine 4y ago
  I appreciate the thoughtful response. I do see that the GCP primitives power Firebase. Feel free to reach out any time- jack at koptional dot com
diceduckmonk 4y ago
> Google Cloud Console dashboard…GCP is cannibalizing the Firebase developer environment. From an ops perspective, that makes sense. But axing the simplified cloud experience of Firebase removes much of its value > GCP favoritism… Why Firebase Hosting requires Cloud Function list authorization confounds me Someone gained promotion credits for these “migrations”. It’s turtles most of the way up. The bricklayers justify projects that are aligned with some director level’s visionary initiative to unify and consolidate GCP. If there was real vision, the fragmented and disjointed documentations and code packages should be normalized, but that is out of scope when you’re operating on promotion-cycle level timescales. On an orthogonal about cloud functions lost permissions, we wanted to list our cloud functions and since we used OAuth2 the most granular OAuth2 scope we requested involved the ability to write to GCP as a whole. Point being, there’s a pattern with GCP of forcing people to migrate to features that are half baked if not abandoned (again, promotion).

344 points by jackconsidine 4y ago

It’s sad to see people invest in things like firebase without understanding my the technology. Right tool for the right job. If you don’t need scale then you don’t need firebase. If you need joins, don’t use firebase, etc etc. If one insist on using a proprietary managed database I’d use Spanner.

johndfsgdgdfg 4y ago
I absolutely agree. Moreover with any Google products you will never know when they will shut it down or hike the prices like they have done countless times.
- endisneigh 4y ago
  In my opinion one should refrain from any managed service that can’t be self hosted. Not clear to me why the authors don’t use managed Postgres. Supabase is close enough I suppose. Personally I don’t see what you get with supabase vs an Orm and vanilla managed Postgres.
  - moooo99 4y ago
    The appeal for firebase is that you can get away without your own backend for quite a while. It's perfectly feasible to consume databases directly from your frontend app without having to deal with a lot of caching or networking concerns, the firebase SDK does that for you. You basically get a complete API layer without having to write a lot of code yourself. It is very similar with stuff like auth handling, which is also tightly integrated into the database offering. This makes development incredibly easy, especially in early stages and if you're starting out as a solo/small scale project. It is even better if you don't have an in depth knowledge about backend development/architecture and just want to build a product. You don't get any of those benefits with a regular managed Postgres offering, at least not that I'm aware of. Supabase comes a lot closer to firebase than a regular managed postgres + ORM offering would but you also get an oepn source project that you could potentially self-host. from what I heard self-hosting Supabase is possible, but a rather complex undertaking. There is some documentation around it, but is definitely a lot more complex than using their hosted offering is.
danielvaughn 4y ago
I’ve been pretty critical of Firebase on HN, perhaps too strongly. My experiences with it have all been the same, it goes like this: Client has a new-ish codebase that was written by relatively inexperienced front end developers. They aren’t confident enough in the backend, and are attracted to Firebase because it lets them write everything from the front end. Then they proceed to create the most convoluted DB model and a spaghetti backend that’s split between the front-end repo and various cloud functions. In practical terms it’s been a nightmare every time, for me personally.
- trefoiled 4y ago
  It's amazing just how accurately this describes my exact experience as a FE engineer tasked with creating a newish codebase for a client.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
nicoburns 4y ago
Is Firebase even capable of supporting high scale? My experience with it has been that performance is pretty poor when working with large datasets.
- rockwotj 4y ago
  Firebase is a large suite of products - are you talking about the Realtime Database? The answer is it depends on what "high scale" is. There are parts of the RTDB that didn't scale well when I worked on it (indexes are built in memory on demand so building the initial index is slow), but there are projects that could fix that.
- bootloop 4y ago
  Realtime Database? No. Firestore however, scales as most GCP services do and is it's in-house built replacement.

skywhopper 4y ago

The CLI complaints, while relatable, are pretty minor. It seems they believe shell scripting is a dirty hack. But in that case, why not just write a clean program to pull the values in the form they want from the API or SDK?

hinkley 4y ago
Part of my evolution with regard to Single Responsibility Principle has been to start exposing command lines for some modules. It makes it a lot easier to write integration tests for one, but it also helps people know the interaction boundaries of a particular module. Because if they aren’t in the dependency list, either the program doesn’t work or it doesn’t talk to that code. It’s also a lovely bit of friction to Kitchen Sink Syndrome, because it’s just that little extra pain in the ass to cross link everything to everything instead of gating it through nexus modules versus leaf modules. The CLIs usually stay as debugging tools, but in some cases they have gotten incorporated into more complex tools, such as to add more hints and hyperlinks to out deployment management tools.
jstrong 4y ago
I dunno. There's nice CLI interfaces and there's one's that make things annoyingly hard to do. I haven't used firebase ever but I have had that problem before.

glacials 4y ago

As a side-project Firebase user, I empathize with it being slowly consumed by GCP. I don’t have the time or inclination to learn GCP for a side project. I opted for Firebase because it had a great developer experience. As time toes on and more and more Firebase features are redirected to GCP equivalents, the DX value prop is being drained out of the product and I’m left not even understanding my own infrastructure. I’m thankful the author pointed out Supabase, it seems like a great alternative.

inlined 4y ago
[cloud functions for firebase manager] I understand that the decision to shuffle users to GCP for logs was controversial. It wasn’t decided, as some have said here, because some director had an OKR to fluff up; it was because our UX team couldn’t keep up with the sheer amount of innovation in GCP’s observability suite. Check out Daniel Lee’s talk next Tuesday on observability and cloud functions for firebase for some cool tricks. Did you know, for example, that you can jump into the trace for a log line in GCP? That you can create custom metrics with alerts? That you can filter by structured log segments? I think a tutorial could smooth over the transition, but I think this decision was for the best. If you want a super simple logs reader for in-the-moment analysis, try the CLI command “firebase functions:logs”
- holografix 4y ago
  What if 741 new features are introduced to Cloud Logging, will these be forced onto the Firebase user? Oppression of choice is a real problem. Firebase must cherry pick the best of the new features and wrap it in their own UX in order to stay relevant. Being booted into a completely new and unfamiliar UX with dozens of knobs and dials is a jarring experience. It might not have been a managers OKR but it’s very obvious that in an effort not to lose the “whales” your casting the new too widely and potentially killing a lot of smaller fish.
- glacials 4y ago
  I appreciate your reply and I believe every word you have said. Thank you for the hard work and thought you and your team have put into your products, and I'm sorry to hear if anyone is casting you as faceless corporate politicians reaching for meaningless goals. I know exactly how that feels. To be frank with my feedback, I am a person who uses Firebase for a side project. I don't have the mental capacity to watch an ~hour talk for each piece of GCP infra I don't understand. I liked Firebase because I could understand it intuitively through its UX. I'm sure the GCP features are very helpful and innovative and I'd get a great ROI from the talk if I worked on them for my full-time job. But some weeks, an hour is all I have. I'm an app developer and I would just like to deploy my app please, and have the rest fade into the background, or at least integrate with my existing workflows. Thanks for all your hard work. I understand if "side project developers" is not the top of your funnel. But I hope you hear my feedback.

simscitizen 4y ago

> We plan to do more research on scalability, since column-based databases can’t grow as big as their NoSQL counterparts. This one sentence makes me question this firm's expertise. "Column-based database" has a meaning, and Postgres definitely isn't one of them.

duxup 4y ago
I’m confused by that line and it made me wonder about their experience or PoV as well. But as someone who doesn’t word smith good, could just be that.
deleted 4y ago
[deleted]
jackconsidine 4y ago
Author here- poor choice of words, thanks for pointing out. I was getting at the fact that SQL systems don't scale as well horizontally (it's difficult to distribute the same column across multiple machines), and inadvertently used a technical term connoting something else.
- randomdata 4y ago
  > I was getting at the fact that SQL systems don't scale as well horizontally Google, for example, claims that BigQuery, which uses SQL, scales horizontally. Funnily enough, it is also column-based. Row-stores, like MySQL Cluster, can also scale horizontally and uses SQL. But no matter what you are at the mercy of CAP theorem. Pick your poison.
  - jackconsidine 4y ago
    100% agree on the CAP theorem conundrum. I didn't know that BigQuery was SQL under the hood, interesting.
    - randomdata 4y ago

tmountain 4y ago

Is there anything like Firebase that lets you use SQL like schemas instead of their data store? That would fill a nice niche for some use cases I have been working with.

endisneigh 4y ago
Managed cockroachdb, along with some others like fly.io.
rossfishkind 4y ago
Supabase is awesome and open-source
gman83 4y ago
I've been playing with Pocketbase which uses SQLite: https://pocketbase.io/ https://pocketbase.io/
PKop 4y ago
Supabase
hn_throwaway_99 4y ago
It's really easy to add a Google Cloud SQL database in GCP which then can be accessed by, for example, Firebase Cloud Functions. It's also very easy to mix/match parts of Firebase with GCP. For example, you can very easily deploy a server-side API on a plethora of GCP technologies (i.e. App Engine, Cloud Run, a dedicated Compute instance, etc.), deploy a front end with Firebase Hosting, use Firebase Auth for user authentication, then when you call your backend API you can verify the authentication using the Firebase Admin APIs.
_query 4y ago
Check out thin.dev https://thin.dev/ https://thin.dev/ It uses SQL DDL statements literally as the building blocks for everything.
fakedang 4y ago
Supabase

alexose 4y ago

From the article: "Being closed-source, you don’t have the implicit assurance that Firebase will always be around (like Parse), nor can you reliably depend on a specific API version." Firebase is amazing, but I'll never use it for anything that's meant to last more than a year. I don't trust the API to remain stable, and I _especially_ don't trust Google to keep it running for the long term.

deleted 4y ago
[deleted]
garren 4y ago
Exactly. s/closed-source/google/ I've not used Firebase, but seeing as it's not, as far as I can tell, "core" Google (i.e., not related to search or advertising explicitly), I'd be concerned about relying on it in any substantial, business-critical, way.
- inlined 4y ago
  I’m not a VP and there is no way to promise that we’ll “never” be shut down, but Firebase is a successful product and additionally drives a lot of Cloud usage (which is certainly “core”!). I just don’t see any reason why a VP would need to sunset firebase to balance any books.
asciimike 4y ago
The RTDB APIs have remained stable and available since ~2012. Storage has existed in the same way since ~2016. Do you have some specific examples of build APIs changing on you in ways that break your applications?
- alexose 4y ago
  The first application I wrote for Firebase was back in 2015, before it was acquired. I don't remember the specific issues, but I know I spent about the same amount of time trying to keep it running post-acquisition as I did building the app in the first place. I tried again in 2019 and got burned by Cloud Functions Node runtime changing underneath me. Edit: I should point out that averaging a single breaking change every five years means that an application has a 20% chance of being affected each year. I'm not willing to roll the dice, generally speaking.

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?

lordofgibbons 4y ago

>Authentication out of the box is nice. (Built-in Firebase email-verification is, in our opinion, a poor experience though). >Firebase mandates Google / GSuite sign-in Is Firebase authentication different from GCP Identity Platform? I've read the docs for both Firebase and Identity Platform and the lines seem blurred.. Do these issues extend to Identity platform? I haven't heard of many people using it, but it looks very feature-rich.

dilatedmind 4y ago
They are the same, there is also some functionality for managing firebase auth users in the gcp console.
hn_throwaway_99 4y ago
Yes, they are the essentially the same (again, more confusing branding). Firebase Auth is great, with the notable exception that I am worried it will become Google project #2898 to die on the vine. It has received virtually no substantive updates for about 2.5 years. The last big one was they added SMS 2FA in early 2020. Given that Google themselves has long ago stated SMS is insecure for 2FA, it's ridiculous they have no other options, nor have they said anything about adding options in their official channels. Here's a post from Dec 2021 in the google groups forum, and again there have been no real substantive updates since: https://groups.google.com/g/firebase-talk/c/RBRdDHPybC8 https://groups.google.com/g/firebase-talk/c/RBRdDHPybC8 > Is Firebase Authentication dead? > I apologize for the inflammatory subject line, but I think this is an important matter that the Firebase and Google team should be transparent about. > What does the future of Firebase Authentication look like? Is it in maintenance mode? Is there any roadmap for future development? > I migrated my user base to the Firebase platform a few years ago, mainly based on their Authentication platform. It looked like it had a lot of promise. There was a lot of development going on with it at the time. Although it didn't have all features I wanted, the pace of development seemed to show a good trend line going in that direction. At the time, they said MFA was on the roadmap. I considered other AaaS options, but chose Firebase Auth based on where I thought it was going in the future. > Fast forward a few years, and it seems like there is no activity any more with Firebase Auth. I'm still waiting for TOTP and WebAuthN MFA. SMS is not a no-starter, and even Google has said that SMS is not secure MFA. There is no way to control the password strength policy, nor lock-out behavior when incorrect passwords are entered. > Now I need to make a decision: whether to stick with Firebase Auth, or to move on to a different AaaS platform. Will Firebase Auth pick up the feature development pace again, or is it on a long death spiral? I'd appreciate insight from Google what their plans are in a concrete way. > Thank you.

norwalkbear 4y ago

For videogame development, firebase is godsend. Just an absolute easy way to add features into mobile games. Core competencies of most game devs aren't web stacks. I can see how web devs might feel differently.

giancarlostoro 4y ago
Also could see it for mobile devs trying to get an idea going.
- fakedang 4y ago
  I thought the same way, but I think now Supabase is much better than Firebase. Simply because you get a lot more functionality from the postgresql DB compared to the nosql DB.
  - endisneigh 4y ago
    It’s sad how people don’t use things for their intended use case. The main thing you’re buying with firebase is scalability
    - paulgb 4y ago
      “Intended” according to whom? The firebase landing page makes a couple references to being scalable, but otherwise it doesn’t appear that using Firebase at a smaller scale is outside its intended scope at all.
      - endisneigh 4y ago
        Intended accordingly to the technology, not marketing
        paulgb 4y ago
        What does “intended according to the technology” even mean? Just because software is built to scale up, doesn't mean that using it at a smaller scale goes against its intention. Marketing copy aside, it's not as if the technical docs discourage people from using it for non-scale use cases.

joshe 4y ago

Google's internal developer hazing and poor DX surely have something to do with this. I've talked with multiple ex coworker developers at Google about the 3 to 6 months it takes to actually figure out how to deploy something. Also the constant overhead of approvals and oddball systems (gerrit!) thereafter. Eventually good DX seems unimportant and even associated with failure. Real programmers grovel to weird dependancies and find out stuff the hard way. There's a better alternate universe where Firebase and 2010 era Google App Engine are the template for GCP.

kotlin2 4y ago
I still have no idea how to navigate a Gerrit PR. I sometimes land on one trying to investigate a bug in Chromium or something like that. I’m sure Gerrit’s approach has some benefits, but it definitely fails at showing a simple before and after view, i.e. “here’s what changed.”
- hinkley 4y ago
  When change is hard people start over. Anything in your system that adds friction to modifying existing code (be it source structure, lack of static analysis tools, build shenanigans, diff tool) encourages people to copy instead, or reinvent.
SkittlesNTwix 4y ago
> internal developer hazing Could you expand upon what you mean by this part?
- piotrkaminski 4y ago
  Not OP, but I'm guessing they're referring to the "readability" approval process, which can sometimes be pretty brutal. (Or at least that was the case a decade ago, don't know how it's evolved since.)
hinkley 4y ago
People with a high pain threshold create systems that require a high pain threshold. That filters out a lot of people with a low tolerance for bullshit. Then the “indispensability” of people who built job security into the system filters again.

eikaramba 4y ago

I have to also mention https://directus.io/ https://directus.io/ here. Coming from Strapi, Feathers.js and Supabase i have to admit it is the closest competitor to Supabase i know. There are things Supabase is doing better but the Admin Interface and the Customization Capabilities of Directus are just unmatched.

soulofmischief 4y ago
How would you compare it to Feathers?
threatofrain 4y ago
https://appwrite.io https://appwrite.io

seibelj 4y ago

> We love PostgreSQL which Supabase utilizes. We plan to do more research on scalability, since column-based databases can’t grow as big as their NoSQL counterparts. I would argue there are very, very few types of problems NoSQL solves better than relational DB, and the “benefit” of quickly deploying schema changes is actually a nightmare later on. That it took so long for these devs to realize this is… perplexing

klabb3 4y ago
If you have more write queries than a single machine can handle you're in trouble though, right? Not defending NOSQL in any other way, but this could be a legit requirement for some apps, no?
- parasubvert 4y ago
  There are over a dozen distributed SQL database projects out there, and as many middleware to shard SQL databases. Some of the worlds largest properties , eg. Meta , largely run on MySQL. Eg. https://engineering.fb.com/2016/08/31/core-data/myrocks-a-space-and-write-optimized-mysql-database/ https://engineering.fb.com/2016/08/31/core-data/myrocks-a-sp...
- seibelj 4y ago
  A firehose of ingestion is a specific problem that can be solved. But basing your entire application on a nosql data store is a mistake - quick and dirty now for pain and tears later.

hilti 4y ago

I‘ve been using Firebase and Firestore extensively in past projects, because I was attracted by it‘s simplicity on first sight. Then there’s the day you need some relational queries. It‘s somehow possible, but you need to rethink your data structure. Then you figure out, that the realtime part of Firebase is CPU intense and slows down your browser. Call me nuts, crazy or whatever - I‘ve replaced most of these applications with SQLite (WAL enabled) and use either server-side-events (SSE) for almost realtime notification or the HTTP streaming API. It works perfectly for my needs and is pretty simple to deploy.

honzajde 4y ago
How would you handle "db-notifications" with sqlite - to my knowledge this is a reason why you would need postgresql with its' (pg) NOTIFY
- b3morales 4y ago
  SQLite calls this an "update hook": https://www.sqlite.org/c3ref/update_hook.html https://www.sqlite.org/c3ref/update_hook.html
  - rockwotj 4y ago
    SQLDelight had neat built in support for this https://cashapp.github.io/sqldelight/ https://cashapp.github.io/sqldelight/
  - hilti 4y ago
    Exactly! Or in some cases I create a view - for example a highscore list - that is queried by a simple server-side script and sends the data as JSON to the client.
marviel 4y ago
You should check out supabase -- it takes this pattern (with a Postgres backend instead) and packages it up in an open source, cloud hosted but also self-hostable model

tlarkworthy 4y ago

Supabase has distributes consistency issues and not suitable for multiplay/offline first. I am annoyed at firebase for real technical reasons like Firebase auth can delay page load by several seconds. So the real alt to firebase (on web) is replicache IMHO

marviel 4y ago
Can you speak more about the issues with Supabase you describe?
- tlarkworthy 4y ago
  https://twitter.com/tomlarkworthy/status/1561099104356159488?t=QAwEroZUIyHCJCiBUGNSTA https://twitter.com/tomlarkworthy/status/1561099104356159488...

zackmorris 4y ago

My recollection is that progress on Firebase stopped when Google bought it, and I haven't followed it for almost a decade. Does anyone know if these basic features were ever added? 1) It used to download the whole state (write history) upon startup. Did they ever update it to send a snapshot, or a partial view of the data with lazy-loading for additional nodes? 2) Did they ever provide a simple push notification service? That was pretty much the only thing missing to be able to run Firebase without another server. 3) Were node aliases/shortcuts ever implemented, so a node could be a reference to another node? That would have greatly reduced the need for a SQL JOIN alternative. Also, after having done some cloud dev ops work, I can't endorse it from any provider at this time, as the burden of securing things like user permissions is beyond what humans are generally capable of, so I consider them an anti-pattern. A better pattern is token-based authentication for everything, using standard web metaphors and REST APIs, so that every service behaves like a sandboxed root user with limited abilities granted. I also wouldn't use any cloud service without Terraform or a similar declarative infrastructure manager. Meaning that the best cloud service is basically the best Terraform configuration, providing a higher level of abstraction like Heroku, which largely defeats the purpose of direct cloud hosting in the first place. So.. the cloud is no substitute for Firebase, and if it goes that route, it will be no surprise if customers jump ship.

duxup 4y ago
>Firebase stopped when Google bought it I duno about that. I've seen lots of new features for Firebase for a number of years now.
asciimike 4y ago
> My recollection is that progress on Firebase stopped when Google bought it, and I haven't followed it for almost a decade. Firebase launched an alpha in April 2012 and got acquired in 2014, so I'm not sure how you've stopped following it for a decade because it's only existed for about that. > 1) It used to download the whole state (write history) upon startup. Did they ever update it to send a snapshot, or a partial view of the data with lazy-loading for additional nodes? Yes, that feature shipped in 2014. > 2) Did they ever provide a simple push notification service? That was pretty much the only thing missing to be able to run Firebase without another server. Firebase integrated with Google Cloud Messaging in 2016. Cloud Functions (which was also 2016-17) allowed operation without a server. > 3) Were node aliases/shortcuts ever implemented, so a node could be a reference to another node? That would have greatly reduced the need for a SQL JOIN alternative. No, the guidance was to duplicated data across paths (when Cloud Functions existed, folks used them).

james_cowling 4y ago

Firebase has been a huge influence but with the rise of serverless there are a new generation of platforms people should be checking out instead, such as Convex, Supabase, etc. Convex in particular is designed far more for end-to-end consistency rather than just a database to talk to: https://docs.convex.dev/understanding/convex-vs-firebase https://docs.convex.dev/understanding/convex-vs-firebase

temp_praneshp 4y ago
Consider adding a disclaimer that you're the founder of Convex
- redanddead 4y ago
  Exhibit A in reasons to probably not use convex
- james_cowling 4y ago
  Yep that’s me! I have my full name on here so wasn’t hiding but good point to be clear about disclosing.
  - ranguna 4y ago
    > full name on here so wasn’t hiding Unrelated to the OP's suggestion.

coys 4y ago

Jack Considine is always a good read

coupdejarnac 4y ago

I see Supabase's Realtime hasn't reached the production milestone yet. How far away is that? I'm interested in using it for an offline first app. Watermelon sync would be nice.

kiwicopple 4y ago
It’s pretty close - we just added Presence and Broadcast. As soon as we are confident that they are stable at scale then we will consider it GA (probably a few months)

abraxas 4y ago

> You also therefore can’t truly run Firebase locally. To me this is just incredible. As an old timer who learned the ropes in the late eighties it never crossed my mind (what with computers always getting faster) that we would once again face the situation that developers can't run their software locally. It's like a bloody throwback to the sixties and the days of punchcards and timesharing systems. Thanks but no thanks! It's such a friction factor that all other benefits of the platform get overshadowed by this. It's the same reason I'm vehemently opposed to my team using AWS Lambdas for anything non-trivial. And no, SAM is not the answer here.

imachine1980_ 4y ago
correct me if i'm wrong, you can run lambdas locally whit firecracker, lost all the benefits of serverless (you are self-hosting) but you can do it if you need it.
- paulgb 4y ago
  Lambdas are run on Firecracker, but firecracker is just a runtime, it doesn’t include the rest of the FaaS stack Lambda provides.
easton 4y ago
> It's the same reason I'm vehemently opposed to my team using AWS Lambdas for anything non-trivial. And no, SAM is not the answer here. I’ve had to start using Lambda at work and this is my biggest problem. Waiting minutes to see if it was a typo or if there’s a larger problem is terrible. I miss Docker.
- spion 4y ago
  SST (https://sst.dev/ https://sst.dev/) has been a game-changer for me, it makes serverless bearable.
deleted 4y ago
[deleted]

tc08 4y ago

TL:DR; We don't want to use GCP and we don't like that Google.is intergrating Firebase into it. As someone who is running on GCP, I can't wait for them to fully merge Firebase into the GCP dashboards. Not a high vakue article, really...

klabb3 4y ago

It's funny because Google pretty much invented this model that users want and love. App Engine was launched in 2008, before GCP, before docker and before Cloud was a term, basically. It had a globally replicated persistence layer, job queues, auth, scale to 0, a generous free tier, a fully fledged local dev server and a single command to deploy, and all config lived in a single file. At the time it was really innovative, and attracted a lot of hip startup- and college grad types. The reason people liked it is, imo, because it was a single product with multiple features. GCP OTOH, has been about decoupling (or loosely coupling) the product suite, and users are supposed to pick and choose from a giant array of half-products. Simply being aware of all products, their interoperability and predicting the cost is a full time job, easily (it's mostly large enterprise who can absorb that cost). There's nothing wrong with the pick-and-choose model, if your products are simple, low level, and interoperable. But the product suite has grown organically, seemingly without coherence, so there's very little in terms of paved paths to walk – it's so confusing. When a shining star like Firebase comes along (2014) Google clearly knows not to mess with it too much. But even Firebase isn't strong enough to resist the gravitational pull of the GCP behemoth.

lowbloodsugar 4y ago
Yeah I was there. It was great because it was, apparently, impossibly cheap. Then they decided to take it out of beta and jack the prices. People who were spending $10/mo suddenly had $1000/mo bill. Never trust google.
- klabb3 4y ago
  Yeah I don't think PaaS should ever be proprietary in terms of API surface. It's just perverse incentives, you get subsidized until market saturation, and then they jack up the prices. The cloud providers should, imo, compete on uptime, resilience, performance, etc. Kinda like the VPS or VPN providers of today.
  - asciimike 4y ago
    Let's take a quick example of S3: GCS was able to take the same API and they both compete on uptime, performance, etc. Price/GB has remained stable or decreased with new tiering options over time. Managed K8s clusters, SQL databases, etc. are all competing in similar ways. If folks want to build proprietary APIs, and people choose to use them because they are faster/better/cheaper/more suited to a particular use case, I'm not sure why that's a bad thing. Engineering is tradeoffs, proprietary API surface is one of many things people consider.

pier25 4y ago

I've been using Firebase since 2016 in production. Still have a couple of projects there but I will not start another project with Firebase. I would only use it for quickly prototyping something that I'm 100% sure will be trashed later. Otherwise there are just too many issues with it for anything remotely serious.

asciimike 4y ago
Not saying there aren't issues, but would you mind elaborating on some of the issues you've experienced?
- swid 4y ago
  I ran into unexpected difficulties from Firestore - the queries only allow 1 range clause, the transactions only allow up to 500 updates, and you can either search 1 collection or all of them with the same name. This was a problem for us when applying a template to the schedule - templates could have over 500 appointments (so difficult to apply the template in 1 tx), and not being allowed two ranges meant we could test the appointment starts but not the end. The collection issue came up because we had appointments off of users off of orgs. It was impossible to search all the users within an org/tenant the way we set it up. Either search in 1 user or all users in all orgs. We ditched all of firebase and I’m happy we made that decision early enough.
- pier25 4y ago
  Where to start... The databases are completely useless for anything other than trivial demos. Cloud functions are plagued by cold starts and deploy usually takes minutes. These are by far the worse cloud function offering in the market right now. Storage is fast but it is extremely overpriced. The JS client used to be super heavy. I think they've improved that with tree shaking but still, if you're using all their services, you will end up with huge JS bundle just for the Firebase stuff. All your app becomes deeply locked in into Firebase. It's designed so that you have to invest a huge dev effort if you want to leave. Firebase could have adopted standards like GraphQL or maybe added a PG offering like Supabase, but no. The static hosting is probably one of the slowest options in the market. At least that was the case in 2020 when I did these benchmarks. https://www.pierbover.com/posts/static-hosting-benchmark-2020/ https://www.pierbover.com/posts/static-hosting-benchmark-202... Honestly I could go on but just don't use Firebase.

patientplatypus 4y ago

neom 4y ago

Very tangentially.. In the early days of DigitalOcean, I was fortunate enough to spend time with most of the devtool CEOs, Leibert, Polvi, Hykes, Newcomb, Collison, etc etc etc. All very smart guys. However James (and Sara!) was one of the most brilliant thinkers I came across. It's always been somewhat of a shame to me he didn't keep building firebase independently. Knowing him (shyguy), I'm not surprised he sold it to google, but I feel like we need to make more space for shy/guys/gals/*. How many of you think Dokku is awesome? But are we doing enough to support folks like Jeff Lindsay (shyguy)? Yeah, firebase was awesome when James was still working on it, people like him and Jeff Lindsay (@progrium) are surely brilliant thinkers. How do we support them (shy-folk ceo)? (https://news.ycombinator.com/item?id=7844457 https://news.ycombinator.com/item?id=7844457)

jamest 4y ago
Those words are far too kind! Most of the credit goes to my co-founder, Andrew, and the whole team who gave nothing short of everything to build it.
- neom 4y ago
  You did a great job James. Yes Andrew and Sara and the team were pivotal, but you CEO'd it... I'll never forget when you showed me that weird arcade game y'all used to demo, the paradigme shifting was high and you did a fantastic job of explaining why. Hope you're well old friend. :)
deleted 4y ago
[deleted]

esskay 4y ago

No mater how good Firebase or any of Google's cloud offerings are I could never trust them enough not to just decide to pull the plug one day like they eventually do with every product they launch. They've made themselves untrustworth, and not just from the usual privacy issues.

campbel 4y ago
Yep. Partnering with Google feels like building on sand sometimes.
redanddead 4y ago
Yeah google should address this

quickthrower2 4y ago

I enjoyed reading this having battled with firebase on a personal project. It has just enough quirks that I now prefer postgres unless I need all of the firebase features desperately. > It seems that GCP is cannibalizing the Firebase developer environment. Yeah as a latecomer I got this impression and rolled my eyes. I imagined a debate in the office between an passionate Firebase OG and a Google exec holding an OKR portfolio, the passionate engineer trying to delay the inevitable gobbling up of firebase! For me Firebase has lot of cuts, maybe not 1000 but things like: * No formal definition of rules, just some very scant documentation. Much of it is undocumented or can only be found in SO answers. * Emulator fatigue! Like Azure storage, the emulator is a good approximation to the real thing but you end up chasing down bugs locally when it is an emulator quirk. Postgres OTOH you run the same thing in prod. Same for mongodb, mssql, mysql etc. * Firebase admin sdk has a completely different API to the normal sdk to do all the same things! I get it: smaller JS bundles, but why not just reuse a lot of those changes in admin? * You have to have a local file with authentication secrets to a cloud db in order to run the emulator! I just have a test deployment for this but it feels unnecessary. * I don’t think the model of letting users upload json directly to collections is secure- unless you are a genius with firebase rules. This might be more of a general criticism of nosql over http. CouchDB might have the same issues I guess. * Rules bugs like if you do a query with clauses your rules don’t have access to the entire object just the queried fields. You need to add ghost fields to the query to make the rule run properly. Probably more things I forgot about too. I am even tempted to reverse engineer rules to write a proper guide. If that sounds interesting let me know. Finally I prefer open source stuff for a lot of the usual reasons. So closed source stuff has to be beyond excellent to make sense to me to use.

asciimike 4y ago
> I am even tempted to reverse engineer rules to write a proper guide. If that sounds interesting let me know. No need to reverse engineer them, I built them, so I'm happy to answer any questions you may have (to the best of my memory). > * I don’t think the model of letting users upload json directly to collections is secure- unless you are a genius with firebase rules. This might be more of a general criticism of nosql over http. CouchDB might have the same issues I guess. It's a general criticism of any "access your database/storage bucket/etc. directly from the client" product--everyone has to build _some_ authZ mechanism that lives in between the client and the server, whether it's Firebase Rules, Postgres Row Level ACLs, Lambda Authorizers, etc. Otherwise you're writing your own authZ code on your own server, which has it's own set of issues. > * No formal definition of rules, just some very scant documentation. Much of it is undocumented or can only be found in SO answers. I don't think https://firebase.google.com/docs/rules https://firebase.google.com/docs/rules is the best documentation ever, but I'm not sure "scant" is the word I'd use to describe it. What are the main areas you think are missing?

jamest 4y ago

[Firebase founder] 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://news.ycombinator.com/item?id=3832877 https://news.ycombinator.com/item?id=3832877) and there are now some great innovations in the space. I like the way Supabase (https://supabase.com/ https://supabase.com/) has exposed Postgres and InstantDB (https://www.instantdb.com https://www.instantdb.com) graphdb+realtime is really promising.

gedy 4y ago
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
quickthrower2 4y ago
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.
- 4y ago

deleted 4y ago

[deleted]

inlined 4y ago

Hi there, I’m the manager of Cloud Functions for Firebase. I wanted to note that Firebase is getting better for large deployments and we’re continuing to invest in the area. First, the article might have been written before our recent feature to skip deployments of unmodified functions. If the source, env, and secret metadata SHA has not changed, we skip deploying that function. At minimum, this means large deployments that fail can be retried and make progress (more on that below). Second, we’ve started investing in a feature called “codebases.” At its simplest, codebases are multiple folders of functions. This makes it easier to deploy single codebases, but it also means you’re likely to skip deploys of functions in codebases other than the ones you’re working on. If you want to invoke functions in another codebase, consider a Pub/Sub, Task Queue, or Eventarc Custom Event (coming in a few weeks) function depending on the feature set that suits you best. Codebases are just getting started and we have hopes to develop this feature in the future. Finally, we’ve set aside budget in Q4 to rewrite part of the core of our deployment logic to improve the way we batch, backoff, and retry function deployments in the face of quotas (yes, they are retried multiple times, even when we give up due to quota errors). We hope to substantially raise the reliability of 100+ function deployments.

bcjordan 4y ago
That's awesome to hear there's ongoing investment in the Firebase/GCP functions space! I'm in touch with many game developers who use or considered Firebase Functions/GCP Functions for their backends/player data web services. Figure I'd pass along the primary gotchas/complaints I hear, since it sounds like many of them are being actively addressed in the work you mentioned: - Time from deployment to availability feels very long compared to alternatives. Firebase Functions (even for 1-3 functions) can be 1-3 minutes long. I've heard it's much longer for more functions (/ maybe region dependent?) - Cold Starts are a major pain to deal with. Workarounds like minInstances are expensive/subvert the scale to $0 value proposition/don't solve latency in the scale-up case, and are charged per function. Some devs refactor their backend to be a single function endpoint to work around this and minimize cost which seems to contradict the small functions development style demonstrated in the docs. - It'd be nice to have more serverless-friendly datastore primitives within the GCP ecosystem that can (1) scale to $0/mo base for pricing, (2) handle high write throughput (including per entry) and (3) support serverless connections well. RTDB, Firestore, Datastore, Memorystore, Spanner, Alloy etc. don't quite nail all those points. Something based on Spanner or an elastic sort of Memorystore that really scale down to $0 for cost could be amazing. Some are migrating to Cloud Run to have concurrency per function, though it sounds like Cloud Functions v2 gets very close to that use case once it's available across all regions. I love Firebase Functions since it really nails the use case of: (1) start from $0, prototype your application quickly, (2) scale up to withstand practically infinite traffic at reasonable cost without having to change any code, (3) seamlessly graduate to using more of a high quality cloud platform without having to change any code. It's rare to find and other efforts haven't matched the overall dev UX. Outside of cold start spikes the platform is very stable and hands-off, and has incredible logging/metrics/alerting available from the GCP side. Separately I worry the GCP ecosystem is missing a story around cheap/fast edge functions and integrations with next-gen frontend tooling which often rely on many quick API calls. (It would be interesting to see something like a Firebase acquisition & integration targeting that world of tooling) If there were a scale to $0 edge datastore like PlanetScale/UpStash + scale to $0 edge functions offering with the simplicity and GCP-integration of Firebase it would be awesome.

LAC-Tech 4y ago

it is impossible to do anything remotely similar to a SQL join. Therefore, developers must embrace the ethos of NoSQL by distributing relational data ahead of time. Can someone help me translate this? Are they saying that since there's no joins they store their aggregates denormalised upfront? Or what?

habosa 4y ago

Re: Extracting a machine-readable CI token Don’t do that! Firebase CI tokens are not a good way to authorize with Firebase anymore. Use a GCP Service Account which you can scope very precisely and remotely adjust permissions / track usage.

tinyprojects 4y ago

I really miss firebase function logs. Even though it was a bit glitchy at times, it was the perfect simplified overview of everything on my backend, and fitted well with the simple UI of firebase. I'm sure I'll get used to Google Cloud logs - but it just feels really out of place now.

philliphaydon 4y ago

> We love PostgreSQL which Supabase utilizes. We plan to do more research on scalability, since column-based * SQL databases can’t grow as big as their NoSQL counterparts. Nonetheless, Supabase came at the right time. > * Edit: poor choice of words Where do people get this idea that sql cannot scale or grow? Ever since this fad of “NoSQL” we have ended up with these false claims everywhere.

parasubvert 4y ago
That’s what’s called successful marketing, at least with a segment of developers that never looked hard at databases, and bought into the NoSQL claims. The decades long market debates over network, hierarchical, object vs SQL databases are also a distant memory for most. There’s good technical reasons SQL remains dominant, but again, a segment of folks aren’t incentivized to learn why.

sebag1507 4y ago

[I work at Firebase, but opinions are mine] First and foremost I appreciate the time you spent putting together the article. Feedback is a gift and always welcome. I'll address your main point: Firebase and GCP. Over the past decade, developers have consistently turned to Firebase as the fastest way to take their idea to market, thanks to an innovative client-first model and a singular focus on developer experience. Our goal is to provide a comprehensive and "opinionated" platform that just works, saving considerable development and maintenance time. We consciously build some of our services on top of GCP primitives like Cloud Storage and Cloud Functions. This allows us to best apply our team in continuing with our mission, while also making sure that our users never outgrow the platform in any dimension (security, scalability, compliance, etc). You bring up excellent points as far as our UX and better integration opportunities. My goal is not to necessarily push developers to GCP. The way I see it is that both platforms serve users with different use cases and preferences. Some will use one over the other, and many will use both. I would love to continue the conversation and I hope you don’t mind if I try to reach out.

jackconsidine 4y ago
I appreciate the thoughtful response. I do see that the GCP primitives power Firebase. Feel free to reach out any time- jack at koptional dot com

diceduckmonk 4y ago

> Google Cloud Console dashboard…GCP is cannibalizing the Firebase developer environment. From an ops perspective, that makes sense. But axing the simplified cloud experience of Firebase removes much of its value > GCP favoritism… Why Firebase Hosting requires Cloud Function list authorization confounds me Someone gained promotion credits for these “migrations”. It’s turtles most of the way up. The bricklayers justify projects that are aligned with some director level’s visionary initiative to unify and consolidate GCP. If there was real vision, the fragmented and disjointed documentations and code packages should be normalized, but that is out of scope when you’re operating on promotion-cycle level timescales. On an orthogonal about cloud functions lost permissions, we wanted to list our cloud functions and since we used OAuth2 the most granular OAuth2 scope we requested involved the ability to write to GCP as a whole. Point being, there’s a pattern with GCP of forcing people to migrate to features that are half baked if not abandoned (again, promotion).