[HN Gopher] We're moving on from Firebase
___________________________________________________________________
We're moving on from Firebase
Author : jackconsidine
Score : 232 points
Date : 2022-10-15 15:42 UTC (7 hours ago)
(HTM) web link (koptional.com)
(TXT) w3m dump (koptional.com)
| LAC-Tech wrote:
| _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?
| skywhopper wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pier25 wrote:
| 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 wrote:
| Not saying there aren't issues, but would you mind elaborating
| on some of the issues you've experienced?
| swid wrote:
| 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.
| glacials wrote:
| 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 wrote:
| [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"
| habosa wrote:
| 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.
| zackmorris wrote:
| 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.
| asciimike wrote:
| > 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).
| duxup wrote:
| >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.
| anta40 wrote:
| "Did they ever provide a simple push notification service?"
|
| Yes, it's called FCM (Firebase Cloud Messaging). One of the
| Firebase components that is available at no cost:
| https://firebase.google.com/pricing.
| joshe wrote:
| 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.
| [deleted]
| asciimike wrote:
| > 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.
|
| In typical developer environments, you end up with a bell curve
| of "easy things are relatively easy (host a static site, 30
| seconds), but some things end up being totally impossible
| (build a global CDN with 99.999... availability)."
|
| Developing at Google is not at all like this: building anything
| at Google is medium-hard. It takes longer to do simple things,
| but at the same time, basically nothing is technically
| impossible. In many cases, doing the hard things is much easier
| than elsewhere because, yeah, sure, you have to set up 20
| different config files, but those config files abstract damn
| near anything a production system needs to operate.
|
| Example: I wanted to add improved image serving functionality
| (e.g. imgix style URL params), and I was able to integrate the
| existing infra Photos uses in about 15 lines of code and a few
| hours. I don't think there are too many places in the world
| where it's possible to provide that functionality in an
| afternoon. Why it never shipped is a separate story involving
| non-technical reasons (cross-PA politics).
|
| > Also the constant overhead of approvals and oddball systems
| (gerrit!) thereafter.
|
| IIRC only the Android codebase used Gerrit, the rest of
| Firebase and GCP were on Google3. The approvals and other
| stuff... true.
|
| > Eventually good DX seems unimportant and even associated with
| failure.
|
| I think this comes down to a definition of "good DX". I think
| the HN definition (indeed by default one) is "how quickly can I
| solve for an issue using the happy path." Indeed, Firebase
| solves that for a good number of problems (why people use it,
| why there are people who love it).
|
| At some point though, you can't solve for _all_ use cases along
| the happy path (see e.g. SAML, ABAC, any $ENTERPRISE_FEATURE).
| If you want to expand the business, you need to solve for some
| things that don't have a perfect happy path, and that's where
| things start getting messy.
|
| IMO, the goal of Firebase's acquisition was to keep Firebase
| solving the 80-90% of things that had a happy path, and GCP was
| the remaining 10-20% where folks had to break out of to do
| arbitrary things. It seems like a lot of folks in other threads
| here are complaining about that because the abstractions leak
| out--I think it's a fair criticism, but I also am not entirely
| sure how to solve for that.
| joshe wrote:
| Great nuance, thanks for commenting.
|
| DX to me is reduced cognitive load. We are all operating at
| the limits of abilities, better DX expands the scope of what
| we can accomplish in our weeks and months.
|
| Often things sold as DX are absolute garbage dead end
| schlock, like a Flash to iphone app builder or something. So
| I get some of the indifference (google's not yours). But I
| don't think we should think of it that way.
|
| Just on your last paragraph, I think it started that way.
| That Firebase would be the competent general problem solver
| that you might need to break out of. Firebase and App Engine
| have tended to weaken over time, so that you needed to move
| to GCP more often. Ideally Firebase would get more powerful,
| cover more cases, and have higher quota limits. Instead it
| feels like they are being degraded or abandoned rather than
| embraced.
|
| I've never gotten the impression that at google DX was
| lionized. Examples of doing this well culturally are pre-
| Salesforce Heroku, Github, vscode, and Stripe.
|
| A github/heroku style culture doing GCP would crush all
| competitors. Instead if anything GCP is a little worse than
| AWS.
| asciimike wrote:
| > Just on your last paragraph, I think it started that way.
| That Firebase would be the competent general problem solver
| that you might need to break out of. Firebase and App
| Engine have tended to weaken over time, so that you needed
| to move to GCP more often. Ideally Firebase would get more
| powerful, cover more cases, and have higher quota limits.
| Instead it feels like they are being degraded or abandoned
| rather than embraced.
|
| I think I mentioned this on another thread, but the
| "weakening" you mention is "strengthening integrations with
| other parts of the platform." I think the general thought
| here is that an App Engine or a Firebase is a local
| maximum, and in exchange for trading off deeper
| integration, there is a platform wide global maximum that
| is achievable.
|
| Pre-acquisition Heroku, GitHub, Firebase, etc. all were
| able to achieve local maxima, which led to acquisition, and
| subsequent attempts to globally optimize.
|
| Dev tools is a brutal business: if you're lucky, 80% of
| your customers cost you money, 15% break even, and 5% are
| where 80-90% of your revenue comes from. A better DX
| typically only gets you more customers in the bottom 95%
| bracket, because it's easier to onboard people who can get
| from 0 to 1 than from 10 to 100 (or 100 to 1000). Deeper
| integrations into the features on the far side of the curve
| tend to get prioritized and look a lot like what folks here
| are discussing as negatives.
|
| > I've never gotten the impression that at google DX was
| lionized. Examples of doing this well culturally are pre-
| Salesforce Heroku, Github, vscode, and Stripe.
|
| It's not, for the reasons others have pointed out about
| people being smart enough to figure out the solution
| regardless of the DX, etc.
| kotlin2 wrote:
| 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 wrote:
| 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.
| jeffbee wrote:
| Googlers deploy software on production systems on Day 2 of
| their on-boarding training. I've never worked anywhere that had
| as straightforward and usable developer tools.
| asciimike wrote:
| Running `borgcfg up` is very different than spending weeks
| writing monarch configs :P
|
| I totally agree that Google's tooling is _legendary_ when you
| understand it all, but I also agree that having to learn
| 15-20 different config languages to get a service running in
| production was pretty damn painful when we only had three
| months to do it. There's also been a good amount of work in
| the world outside of google to get tooling to a similar place
| (and in many cases, without 20 years of baggage).
| jeffbee wrote:
| I guess the trick is to understand that it's all protobufs
| anyway, and the config langs are just ways of generating
| protobufs.
|
| Outside of Google, it is useful to understand that, for
| example, Helm is not part of Kubernetes, in the same way
| that borgcfg is not part of borg and many people use borg
| without borgcfg.
| asciimike wrote:
| Truly, all we did was move data from one proto to
| another...
| SkittlesNTwix wrote:
| > internal developer hazing
|
| Could you expand upon what you mean by this part?
| piotrkaminski wrote:
| 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 wrote:
| 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.
| patientplatypus wrote:
| quickthrower2 wrote:
| 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 wrote:
| > 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 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?
| quickthrower2 wrote:
| > 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).
|
| What I think is needed is a definitive guide that approaches
| all the angles:
|
| * Beginner intro
|
| * Cookbook
|
| * Full docs
|
| * Data architecture tips
|
| * Limits of rules and when to use a function instead
|
| Having to ask questions is the annoying thing. Because it is
| a blocking affect on your flow as a developer.
|
| I found that your team has gone to great lengths to help
| people online answer their questions.
|
| But the DX of having a great reference guide would be nice.
|
| Then surface area of firebase being so big I feel like this
| might be seperate from the Google firebase docs that cover a
| lot of stuff already.
| combyn8tor wrote:
| I always thought a rules "learning" mode in the emulator would
| be useful. While the mode is switched on, the rules are set to
| allow read/write everywhere. Run your app and simulate a
| typical end user interaction. After you're done, the learning
| mode writes a set of the most restrictive rules possible based
| on the data read/writes from the simulated interaction.
|
| I think this would make a good starting point for new apps.
| quickthrower2 wrote:
| It would be good. However security has to be thought about
| alot I don't think AI is there yet.
| simscitizen wrote:
| > 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.
| jackconsidine wrote:
| 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 wrote:
| _> 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 wrote:
| 100% agree on the CAP theorem conundrum. I didn't know that
| BigQuery was SQL under the hood, interesting.
| randomdata wrote:
| SQL is a protocol. I'm not sure I would consider that
| "under the hood". What happens under the hood is up to
| the implementer, and implementations can vary widely
| (BigQuery is quite unlike Postgres, for example). It is
| the visible part that makes up a particular public API
| designed for interacting with databases.
|
| Conceivably even Firestore could expose SQL as one of its
| APIs. In fact, I once built a tool to do exactly that so
| I could perform ad-hoc Firestore queries using SQL.
| Worked beautifully.
| cachemiss wrote:
| Correct, a common mistake people make is conflating these
| things. I wrote this several years ago about MongoDB:
|
| One thing that helps is if people stop referring to
| things as SQL / NoSQL as what ends up happening is
| various things get conflated.
|
| When talking about stores, it's important to be explicit
| about a few things:
|
| 1. Storage model
|
| 2. Distribution model
|
| 3. Access model
|
| 4. Transaction model
|
| 5. Maturity and competence of implementation
|
| What happens is people talk about "SQL" as either an NSM
| or DSM storage model, over either a single node, or
| possibly more than that in some of the MPP systems, using
| SQL as an access model, with linearizable transactions,
| and a mature competent implementation.
|
| NoSQL when most people refer to it can be any combination
| of those things, as long as the access model isn't SQL.
|
| I work on database engines, and it's important to
| decouple these things and be explicit about them when
| discussing various tradeoffs.
|
| You can do SQL the language over a distributed k/v store
| (not always a great idea) and other non-tabular /
| relational models and you can distribute relational
| engines (though scaling linearizable transactions is
| difficult and doesn't scale for certain use cases due to
| physics, but that's unrelated to the relational part of
| it).
|
| Generally people talk about joins not scaling in some
| normalized form, but then what they do is just
| materialize the join into whatever they are using to
| store things in a denormalized model, which has its own
| drawbacks.
|
| As to the comment above you, SQL vs NoSQL also doesn't
| have anything to do with the relative maturity of
| anything. Some of the newer non-relational engines have
| some operational issues, but that doesn't really have
| anything to do with their storage model or access method,
| it just has to due with the competence of the
| implementation. MongoDB is difficult operationally not
| because it's not a relational engine, but because it
| wasn't well designed.
|
| Just like people put SQL over non-tabular stores, you can
| build non-tabular / relational engines over relational
| engines (sharding PostgreSQL etc.). In fact major cloud
| vendors do just that.
| rockwotj wrote:
| Firestore in Datastore mode actually has this feature,
| it's called GQL (it's not real SQL but similar)
| https://cloud.google.com/datastore/docs/concepts/queries
| tomhallett wrote:
| It seems like there are a few different terms being
| tossed around here, and it's hard to tell which one is
| being discussed.
|
| * How is the data stored? "Columnar" (column oriented) vs
| "Row Oriented" vs Document
|
| * How do you query the data? SQL vs json (elastic
| search/mongo)
|
| With any discussions on performance, while it is true
| that any database which has ACID compliance will struggle
| at very large scale, if the solutions being discussed are
| firebase or superbase, it _feels_ like that is an issue
| which is not relevant yet. If you are having scaling
| issues with superbase, I would look at a few different
| things (indexes, application caching, work_mem, replicas,
| etc) way before i look at a different database engine.
| simonw wrote:
| I'd caution against believing that NoSQL databases as a
| category are more scalable than relational databases.
|
| We have decades of experience scaling relational databases at
| the moment, including horizontally - Flickr was using read-
| replicas and sharding MySQL back in 2005.
| duxup wrote:
| 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]
| esskay wrote:
| 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.
| redanddead wrote:
| Yeah google should address this
| campbel wrote:
| Yep. Partnering with Google feels like building on sand
| sometimes.
| tmountain wrote:
| 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.
| hn_throwaway_99 wrote:
| 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.
| PKop wrote:
| Supabase
| endisneigh wrote:
| Managed cockroachdb, along with some others like fly.io.
| _query wrote:
| Check out thin.dev https://thin.dev/ It uses SQL DDL statements
| literally as the building blocks for everything.
| rossfishkind wrote:
| Supabase is awesome and open-source
| b-lee wrote:
| SurrealDB is getting there soon. You should check it out!
| gman83 wrote:
| I've been playing with Pocketbase which uses SQLite:
|
| https://pocketbase.io/
| IceWreck wrote:
| Directus. Its really well built and polished. It supports
| postgres, mysql, etc.
|
| If you're looking for something lighter, then use Pocketbase
| which uses SQLite.
| fakedang wrote:
| Supabase
| alexose wrote:
| 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]
| rockwotj wrote:
| FWIW it mentions Parse is open source, but Parse wasn't open
| sourced until the service was shutdown. Also AFAIK the open
| source version wasn't want was running internally in production
| crizzlenizzle wrote:
| Same here. I'm always curious as to what things Google is
| building and providing, but I'm so afraid that things will
| break within the next 18 months, because Google suddenly
| decides to ditch it again.
| garren wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| asciimike wrote:
| > 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.
|
| Nit: Firebase was acquired in Oct 2014. New functionality
| was launched in early 2016, and the major change that would
| have affected you at that point was the auth system, but
| that should have been a one time change with low ongoing
| maintenance.
|
| > 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.
|
| What technologies are you using on a routine basis that
| fall into a category you consider acceptable?
| KronisLV wrote:
| > What technologies are you using on a routine basis that
| fall into a category you consider acceptable?
|
| Can't speak for them, but some LTS GNU/Linux distros have
| a decent track record, for example, I've had fairly few
| issues with Debian, Ubuntu or even CentOS back in the
| day. The worse I've had was CentOS xrdp package breaking
| for no good reason, or unattended upgrades in Debian
| breaking GRUB in my homelab once, here's a rant about it:
| https://blog.kronis.dev/everything%20is%20broken/debian-
| and-...
|
| Some languages out there have a pretty long and boring
| releases cadence, for example, in the case of Java, JDK 8
| has been around for almost 10 years, JDK 11 and JDK 17
| will be around for about 5 years each. Migrating between
| versions can be pretty painful, but within the bounds of
| a version, generally there are fairly few bugs and issues
| to be found. Even the feature updates, like new GC
| implementations, are largely optional and you don't get
| the rug pulled out from under your feet.
|
| Some databases out there also have been supported for
| long, for example, MySQL 5.7 and MySQL 8 won't quite make
| it to 10 years of being supported, but will get pretty
| close. They remain compatible with the drivers out there
| in the wild pretty well and even though there can be
| things like performance regressions, I can't recall _that
| many_ problems that necessitated changes due to any
| breakages, more like non-critical slowdowns and such
| until you get a patch.
|
| I think that there are a few software packages like that
| in any domain, whether you're talking about operating
| systems and kernels, programming languages or databases.
| That said, things can get murky depending on how you use
| them: something like Apache httpd or Apache Tomcat can be
| regarded as relatively stable, but that stability gets
| worse, the more modules/plugins you install. Same with
| operating systems and running a huge amount of different
| software on them.
|
| Focusing on stable software isn't something that we as an
| industry do that much, admittedly, everyone just wants
| greater velocity and more features to meet whatever
| business goals are relevant, which doesn't fare too well
| for the folks who care about stability and keeping things
| running long term.
| abraham wrote:
| Any node.js function as a service is going to have the same
| problem.
| james_cowling wrote:
| 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
| temp_praneshp wrote:
| Consider adding a disclaimer that you're the founder of Convex
| redanddead wrote:
| Exhibit A in reasons to probably not use convex
| james_cowling wrote:
| Yep that's me! I have my full name on here so wasn't hiding
| but good point to be clear about disclosing.
| abraxas wrote:
| > 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.
| [deleted]
| [deleted]
| spiffytech wrote:
| While I feel the same way about local dev, I think the industry
| as a whole is indifferent.
|
| Every place I've worked that's adopted into AWS/Azure gave up
| on running apps locally. And everything becomes harder because
| of it.
|
| And now there's a push to not even run your editor locally -
| the next trend is your whole development experience happening
| in the browser connected to a cloud dev environment.
| klabb3 wrote:
| _Violently agreeing._
|
| We really need completely open source stack for the
| applications themselves, and few enough deps that they can run
| and be debugged locally. Not only that, but one shouldn't need
| to provision a cluster and configure certs just to run some
| business logic that's unrelated to infrastructure.
| asciimike wrote:
| Honestly curious, do you have examples or thoughts of what
| this might look like? What is the core primitive upon which
| you want to build that is zero config but highly scalable?
| klabb3 wrote:
| Tbh I don't have the experience to give advice or reviews.
|
| That said, check out Nats.io. It's basically just a
| messaging system but it's beautifully abstracted,
| horizontally scalable and runs locally from a small binary.
| It largely removes the need for much middleware like load
| balancers. They've also recently added persistence features
| for streams and KV stores.
|
| It doesn't solve every problem but I do think a message
| system is a very good core abstraction to build other
| things on top of.
| abraxas wrote:
| We had this in the early 2000s. It was called J2EE
| application servers. All external dependencies were
| specified in terms of interfaces. Granted a lot of them
| were needlessly convoluted but the premise was good.
| inlined wrote:
| Most of firebase's backend services have local emulators. Some
| even use the same codebase as production (real-time database).
| We're also rewriting the functions emulator to use the
| functions-framework like prod (our emulator predated functions
| framework).
| nix23 wrote:
| I had a customer, big "big" database >10TB used just
| internally, they paid 1000's of dollars monthly for "cloud",
| installed 2 redundant server's with backup's snapshot's just
| everything. Performance increased 5 time's, cost decreased 10
| time's reliability increased 2 times (not a really reliable
| internet access there) the system is running now since 7 years
| with nearly no intervention. Cloud is not the answer to
| anything...but to some (workloads) it is...the right tool for
| the work....
| imachine1980_ wrote:
| 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 wrote:
| Lambdas are run on Firecracker, but firecracker is just a
| runtime, it doesn't include the rest of the FaaS stack Lambda
| provides.
| easton wrote:
| > 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 wrote:
| SST (https://sst.dev/) has been a game-changer for me, it
| makes serverless bearable.
| jamest wrote:
| [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) and there are now
| some great innovations in the space. I like the way Supabase
| (https://supabase.com/) has exposed Postgres and InstantDB
| (https://www.instantdb.com) graphdb+realtime is really promising.
| throwoutway wrote:
| Hi James. Thanks for commenting. Just wanted to let you know
| that your HN profile is outdated based on this comment. It says
| you are "Now leading product for Firebase at Google."
| jamest wrote:
| Thanks, fixed!
| solarkraft wrote:
| Wow, InstantDB's approach looks just about perfect. I hope
| somebody implements a FOSS version so it can take over the
| world.
| nezaj wrote:
| Thanks! Fwiw, we do plan to open source in the future :) For
| now we want to iterate with a small group of users. Feel free
| to drop me a line if you want to hack with us.
| gedy wrote:
| 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 wrote:
| 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.
| NayamAmarshe wrote:
| Windows got in the way of web development and I only learned
| that when I switched to Linux. Years later, I don't need
| Windows anymore and I'm so glad to escape that bloatware and
| spyware of an OS.
|
| Now I do gaming, video editing and programming all on Linux
| (ZorinOS) and it feels and looks so good.
| doctor_eval wrote:
| I have a very similar take (although I've been using Linux
| since it was distributed on floppies :), and I definitely
| prefer working with indies, but I will say that one of the
| things I really like about Supabase is that everything is
| available open source.
|
| So even if they are merged with one Borg or another, I would
| expect to have sufficient time to deploy my own infra if it
| looks like it's all going to go pear shaped.
| quickthrower2 wrote:
| Yes Supabase seems like a good bet. Parse is a good
| comparison: if you relied on them you can now host it
| yourself.
| neom wrote:
| 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)
| [deleted]
| jamest wrote:
| 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 wrote:
| 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. :)
| tlarkworthy wrote:
| 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
| tc08 wrote:
| 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...
| anta40 wrote:
| 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 :)
| mrtksn wrote:
| Firebase is super convenient and works very well for the most
| part but my heart races every time I receive an e-mail from
| them. A silly mistake can cost you so much money and they tend
| to word the e-mails strongly.
| quickthrower2 wrote:
| I am not convinced it is: frameworks on nodejs, ruby, php
| etc. can give you most of it pretty simply for less expended
| hours. For any project that doesn't care about webscaling:
| which is 99%
| mrtksn wrote:
| Sure, you can do everything yourself but when you use
| Firebase all that is no longer your concern. It works as if
| you are interacting with 3rd party API, which means you
| only care about the request working and you don't care how
| exactly they are working behind the scenes which means you
| care about the actual stuff you are building.
|
| Firebase does have some issues but the core premise is
| solid and IMHO everything will be like that as we go
| forward.
| anta40 wrote:
| Far point. We've read various stories on HN how people got
| their Firebase billing skyrocketed. One of the lessons
| learnt: efficient DB access.
| asciimike wrote:
| > A silly mistake can cost you so much money and they tend to
| word the e-mails strongly.
|
| They tend to word emails strongly to affect action.
|
| As for the cost overruns: I don't know anyone who wrote one
| of those blog posts (or emailed support) who didn't get their
| bill refunded.
|
| We can argue about spending caps or hard limits (which people
| generally dislike for their production apps), but the people
| side of the business is (or at least was) solid.
|
| Source: worded emails strongly to affect action at Firebase
| and refunded a number of bills.
| mritchie712 wrote:
| #3 is pretty simple to do in Supabase depending on what you
| mean. If you just need a webhook hit when some data changes,
| pretty easy to set up with Hooks
| (https://github.com/supabase/supabase/discussions/3588).
|
| There's also `subscribe`
| (https://supabase.com/docs/reference/javascript/subscribe)
| anta40 wrote:
| What I mean is mobile push notification. Once I felt tempted
| to replace FCM with nats.io, turned out there were several
| cases need to handled. Oh well, back to FCM. At least, it's
| free.
| asciimike wrote:
| I believe they mean mobile push notifications (e.g.
| APNS/FCM), which ultimately flow through Apple and Google.
| antihero wrote:
| It made subscribing to updates really easy and that was cool
| hn_throwaway_99 wrote:
| 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 wrote:
| > 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 wrote:
| > God no. The last time I checked, Firebase functions had
| intensively bad latency times for me.
|
| Was this cold start latency specifically or request latency
| in general? Do you know what region you were deployed in?
| hn_throwaway_99 wrote:
| I don't know when you tried this, but I don't think this is
| valid anymore:
|
| 1. If cold start times are a big deal, you can now set a
| minimum number of instances with Cloud Functions so they
| don't scale to 0. You can also now set concurrency on Cloud
| Functions so one function can run multiple requests
| simultaneously on a single function.
|
| 2. There are tons of other serverless options if you want
| to, say, have a Firebase front end but a backend API served
| in your language of choice that uses the Firebase Admin API
| to do whatever you want, e.g. App Engine or Cloud Run.
| inlined wrote:
| [cloud functions for firebase manager] Lambda is indeed an
| innovative and solid product. Cloud functions for firebase
| has been getting a lot better recently too!
|
| The biggest innovations lately has been our release of v2.
| V2 is built on Run and can support concurrent executions in
| the same container. This dramatically reduces the number of
| cold starts, and makes min instances reservations even
| cheaper if you want to eliminate cold starts for a given
| workload. Plus, Firebase lets you configure CPU separately
| from memory in V2, so you can give functions extra oomph if
| they need it. Docs are at [1]
|
| Finally, Firestore's SDK was slower than we liked in GCF so
| we've done a number of improvements there. About half a
| year ago we redesigned the SDK so we could lazy load the
| networking layer. This lets you handle Firestore events
| without loading the bulk of the SDK. We have a more extreme
| update in the works that will let you configure the
| Firestore SDK to prefer REST over gRPC so you can avoid
| heavy dependencies in latency sensitive/event driven
| environments like GCF.
|
| [1]: https://firebase.google.com/docs/functions/beta
| jsmith99 wrote:
| Firebase functions are just GCP functions. To reduce
| latency you can keep them warm for quite a small fee.
| eikaramba wrote:
| I have to also mention 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 wrote:
| How would you compare it to Feathers?
| threatofrain wrote:
| https://appwrite.io
| endisneigh wrote:
| 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.
| danielvaughn wrote:
| 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 wrote:
| 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]
| [deleted]
| nicoburns wrote:
| Is Firebase even capable of supporting high scale? My
| experience with it has been that performance is pretty poor
| when working with large datasets.
| bootloop wrote:
| Realtime Database? No. Firestore however, scales as most GCP
| services do and is it's in-house built replacement.
| rockwotj wrote:
| 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.
| johndfsgdgdfg wrote:
| 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 wrote:
| 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 wrote:
| 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.
| seibelj wrote:
| > _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 wrote:
| 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?
| lordofgibbons wrote:
| >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 wrote:
| They are the same, there is also some functionality for
| managing firebase auth users in the gcp console.
| hn_throwaway_99 wrote:
| 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
|
| > 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.
| coys wrote:
| Jack Considine is always a good read
| [deleted]
| hilti wrote:
| 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 wrote:
| 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 wrote:
| SQLite calls this an "update hook":
| https://www.sqlite.org/c3ref/update_hook.html
| rockwotj wrote:
| SQLDelight had neat built in support for this
|
| https://cashapp.github.io/sqldelight/
| hilti wrote:
| 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.
| norwalkbear wrote:
| 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.
| jm20 wrote:
| Thoughts on Firebase vs Playfab?
| giancarlostoro wrote:
| Also could see it for mobile devs trying to get an idea going.
| fakedang wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| Intended accordingly to the technology, not marketing
| paulgb wrote:
| 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.
| endisneigh wrote:
| It's a key value store. People complain about that it
| doesn't have joins. It's not a relational database. Just
| one example.
|
| It works best as a simple document store.
| paulgb wrote:
| Ah, gotcha, I see the connection now.
| duxup wrote:
| A large amount of the tutorial videos out there make
| scalability without having to really think about it a big
| selling point, among others.
| giancarlostoro wrote:
| Fair I am not saying it is the only option. Parse was
| really neat before I ever heard of Firebase, Meta acquired
| them but at least they released it somewhat open source.
| coupdejarnac wrote:
| 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.
| inlined wrote:
| 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.
| klabb3 wrote:
| 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.
| djit wrote:
| I miss the App Engine days. As you said it was ahead of its
| time, simple, straightforward and cheap!
| asciimike wrote:
| > 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.
|
| "There are two ways to make money, bundling and unbundling." -
| Jim Barksdale
|
| The quote is mostly provided in jest, but at the same time
| there are many customers who want something totally bundled
| that solves 90% of their problems in 20 minutes but literally
| can't solve the last 10%, and there are other customers that
| want generic building blocks that can solve 100% of their
| problems, even if it takes years to do.
|
| I think it makes sense that Google offers customers both.
|
| > But even Firebase isn't strong enough to resist the
| gravitational pull of the GCP behemoth.
|
| Part of the reason we got acquired is because of the above: we
| knew that we had a number of limitations (e.g. infra
| scalability) that could be solved, and we knew that GCP had DX
| problems offering a bundled mobile offering (App Engine wasn't
| "mobile" focused).
|
| And that acquisition really paid dividends: we were able to
| build a _ton_ of "bundled" services for Firebase by 2016, and
| continue deeper integrations with GCP (Storage, Functions,
| Firestore, Auth, etc.). There are definitely UX differences
| (some of them intentional, due to different audiences), some
| not (e.g. it seems like not having an integrated log viewer is
| a DX miss, though my assumption is that staffing on the
| Firebase side is down so the decision was made to just send
| folks to the GCP console :/).
| snovv_crash wrote:
| I believe it was the inventor of Regex who said:
|
| Easy things should be easy, and complicated things should be
| possible.
|
| The problem with GCP is that a bog-standard setup is
| considerably more complicated than it was before. Maybe the
| config files are roughly the same, but there isn't a single
| dashboard where you can see everything from storage to
| instance usage to queue delays anymore. Instead there are a
| bunch of dashboards, each with way too much detail for
| getting a broad overview of your metrics.
| asciimike wrote:
| > I believe it was the inventor of Regex who said:
|
| > Easy things should be easy, and complicated things should
| be possible.
|
| Was he being serious when he said that? I'd hardly call
| regex a technology where easy things are easy and
| complicated things are possible (there are plenty of
| impossible things in regex implementations e.g.
| backtracking in RE2).
| js2 wrote:
| It is an adage from Alan Kay and correctly worded is
| "Simple things should be simple, complex things should be
| possible." It wasn't about any specific technology but
| rather for what they were building at PARC.
|
| https://www.quora.com/What-is-the-story-behind-Alan-Kay-
| s-ad...
|
| Larry Wall adopted it for Perl, but he's still not the
| inventor of regular expressions:
|
| "In a nutshell, Perl is designed to make the easy jobs
| easy, without making the hard jobs impossible."
|
| https://www.quora.com/What-is-the-origin-of-the-phrase-
| make-...
| andirk wrote:
| How about: easy + common things should have tools built
| for them out-of-the-box, and complicated things should be
| offered a path to the bare metal.
| js2 wrote:
| > App Engine was launched in 2008, before GCP, before docker
| and before Cloud was a term
|
| Cloud computing was a term at least as far back as 1999. We
| didn't have the technology quite right that soon, but we had
| the idea and the term:
|
| https://en.wikipedia.org/wiki/Opsware
|
| https://www.wired.com/2000/08/loudcloud/
|
| Archived version of Wired article: https://archive.ph/TeLPQ
| lowbloodsugar wrote:
| 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 wrote:
| 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 wrote:
| 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.
| klabb3 wrote:
| True, I didn't mean to come off as a purist. I think it
| depends on the service provided and it's maturity level.
| If you need basics like auth, persistence etc i think
| those parts should be open, at the very least have a
| stable API that has >1 provider. (The SRE analogy would
| be a SPOF).
|
| For things like push- and email notifications, it makes
| more sense that a provider is involved (although APIs
| should probably still be open). New innovations can
| always start out proprietary, and the inventors can
| always offer support and managed infra for OSS projects.
|
| Why? I believe the health and future innovations within
| the tech sector relies on healthy competition, and imo,
| that means that the majority of standard services have
| multiple providers to choose from. The only way to
| migrate from one provider to another is through
| standardized, or open, APIs. VPCs is a pretty good
| example of this: I can get the premium option from GCP or
| AWS, and have uptime, bandwidth, and choose a DC from all
| over the world. OTOH, I can get a cheaper, local one,
| depending on my needs.
___________________________________________________________________
(page generated 2022-10-15 23:00 UTC)