Hacker News Reader

The flakey firebase local emulator is the bane of my existence, and poorly documented to boot.

On top of the Googlized clickops, there's the whole Firebase vs Google cloud situation, where you end up having to drop down to "real" google cloud for certain specific features. The docs appear to be detailed but you often end up with more questions than answers.

If you are ever thinking about using firebase, give Supabase a try. The emulator works well, the dashboard is there for prototyping but you can just write SQL to clearly define your database and migrations. Since it's just postgres you have a clear route to leave Supabase if you should ever want to.

Just curious, what’s flakey about it?

I’m not at Google anymore but I was a core contributor to the Firebase emulators project when I was. I can think of many flaws with the emulators but flakey is a new one to me

It often just crashed with an error. Now I am a Windows user, so MMMV, and this might be the reason. In some places the behaviour was slightly different and I had to work around that. I don't recall the specifics. And the idea of a test suite that starts the emulator, runs the tests and gives a result, that can reliably run.... well I gave up on that.

I see this kind of post all of the time. If you’re using relational data with a key value store you’re doing it wrong. You can do anything you can do with a relational database with a key value store, but there are trade offs since now you have to heavily denormalize for performance and figure out how to keep things reasonably consistent.

Firebase is not an alternative to Postgres alone. You need an actual API server. The value of Firebase is you don’t need that, nor do you need to worry about ops, authentication, queues or other things.

The issue the OP found could have been easily fixed by simply reading the docs, but that seems to be a rare activity these days.

There is no such thing as “relational data” here. There is the data I need to store to implement my app. No matter how I shaped it, it was suboptimal. Where it might shine is a subsystem like chat with just messages. Oh just got a flashback about Firebase rules. That alone is a time sink where you could have got the project done in Rails already :-)

The hard work of using Firebase’s apis, libraries, reading it’s docs (which are detailed but badly organized) is more than the delta between not needing a backend. And for a non trivial app you will end up using functions: infact if you want a guarantee that your user has a name then you will need to write a function. And that is… a backend, like writing an app.route statement.

While NodeJS+Postgres is my go-to, I think it's harder than you're making it sound. Firebase would probably be easier for someone who's new to this altogether or somewhere in between.

There's still nothing that holds your hand through a proper client-server interface, good relational schema design, and all the glue in between. Partially because nobody agrees on what those are.

From this post I can tell you’re not really understanding how Firebase is supposed to be used, which is fine. For you it’s better to use the traditional approach with database and app server.

And yes, there is such a thing as relational data. If you do not believe this then you really shouldn’t use Firebase (or dynamodb for that matter).

I know I am holding it wrong etc! But I really tried in earnest, as a fanboy of firebase, for quite a long time. The problems I had were with basic things. You have companies, a company can have many users, users might belong to more than one company (hello Slack...) and then there can be relationship between users.

Putting aside the problem between chair & keyboard.

Another difference is more if you make a mistake in your relational schema, you can SQL your way out of it - add an extra join or group by. And you can also fairly easily migrate you way out of it to a new schema that is the right structure.

This requires actual code with firebase, and a lot of patience, and probably a lot more downtime. So you need more of a waterfall approach, I would suggest, to design a schema ahead of time, and know all of your requirements. NoSQL document-oriented schemas just aren't flexible (unless the DB supports something like materialized views to help you get out of it)

Firebase's whole premise is seamless syncing between locally cached data and your backend. If you "just use Postgres", life is simpler until your user goes offline/runs out of mobile data/whatever, and then they're immediately screwed.

This is the exact use-case I want to optimize for. Offline-first with robust and seamless syncing. Firebase keeps promising it but I would love to find more transparent tools that work better on mobile + web.

I feel this needs a framework (not a library) to take care of it all. Abstract away the webbyness. Something like Elm, with a type that represents data, and behind the scenes it does all the ServiceWorker and syncing crap for you.

https://electric-sql.com/

https://www.powersync.com

https://watermelondb.dev

https://replicache.dev

Do you have direct experience with any of these and especially experience using them with mobile offline-first + sync?

Most apps are online by default these days and don’t even gracefully degrade without internet. Firebase does have the offline DB, but it had a ton of more features and I wouldn’t say the offline db is the only selling point of FB.

https://supabase.com/blog/react-native-offline-first-waterme... may be of interest. https://supabase.com/blog/postgres-crdt seems to be abandoned but would be the next logical step beyond this.

It's worth noting that Firebase doesn't have a true offline-first architecture, but rather cloud-first: By default, queries run against the cloud and results of those specific queries are temporarily cached on the client. By default Firestore will try to reach the server first before falling back to the local cache, which can result in a subpar UX on a patch network connection. It does also provide store-and-forward of updates from client to server. But it's not a true offline-first architecture since it does not preemptively sync a database to the local user device for offline-by-default access.

Regarding Postgres, that is where tools like PowerSync (disclosure: co-founder) and ElectricSQL are useful, which are both sync layers for Postgres for offline-first architecture.

All roads lead back to RDBMS, it's amazing how this piece of theory just works.

I'm coming to this conclusion as well.

Something like DynamoDB can be great for simple data. I liked the idea of Graphql (technically the API query and not the database). Both of them turn into hot garbage once you get into complex data, especially if it's being aggregated from multiple sources. Or maybe the systems I work with just implemented them poorly.

> this piece of theory

Key words right there. The relational model is a timeless mathematical model for data that gains both logical consistency and adaptability as a result. It has and will continue to stand the test of time.

And in practice it has a superpower: agility. The pointy haired boss wants your OLTP to be an OLAP, and you can kind of hack it. You want to put the user's birthday on the settings page this quarter? Sure. Even if that is in another table. You can even make it efficient.

I mean FFS I can get a process to write more rows/sec to AuroraPG than Dynamo with needed semantics, with less code and lower IOP cost

In my experience, the roads lead back to SQL. It deviates from the relational model. It may even be that SQL was successful because it deviated from the relational model. Perhaps the theory doesn't just work?

Roads lead back to SQL because it became a de facto industry standard for "relation-like" stuff.

Can you give an example of a query that cannot be expressed well in relational algebra, but can be in SQL because it deviates from that?

> Roads lead back to SQL because it became a de facto industry standard for "relation-like" stuff.

But what was in question is why SQL is the standard. Did it take that position because of its deviation? If so, that would suggest the theory doesn't just work. Without actually profiling, I suspect that the deviation allows some real-world optimizations to take place, enabling SQL databases to be faster than something with strict adherence to the theory. That would be a good reason why you might have to choose SQL over a strict alternative.

> Can you give an example of a query that cannot be expressed well in relational algebra

Seems not. CloudFlare blocked the submission, complaining that I was submitting a SQL query, which it thinks is a security concern for some reason...

In lieu, just think about what a relation is and how SQL is not relational. Even some of the simplest select queries you can imagine can demonstrate your request.

It took that position because it was what the first viable RDBMS used, pretty much. Similar to how JavaScript became the standard PL for browsers.

The simplest SQL queries map perfectly to relational algebra, so I'm still unclear as to what you had in mind. The two major deviations that SQL has over strict relational algebra are non-uniqueness of rows in a table, and NULL. The first one rarely comes up in practice, and any bag of non-unique rows can be trivially mapped to a bag of unique tuples simply by adding synthetic IDs to them. And SQL NULL semantics is widely considered to be a mess even by many users of SQL itself. With respect to performance, NULLs can be implemented very cheaply while optimizing their relational equivalent (1:0-or-1 relation) requires a little bit more effort on the DB side, but it's still such a simple pattern that I don't see a problem here.

> It took that position because it was what the first viable RDBMS used

Then wouldn't we be using LINUS today rather than SQL? "Viable" is quite hand wavy, so maybe you don't consider MRDS to have been viable enough for some reason. But even once relational databases were moving into the mainstream, there was no clear winner between SQL and QUEL for quite a long time. Even what is arguably the most beloved DBMS of all time, Postgres, picked the QUEL horse originally.

But SQL was generally considered easier to understand for the layman, perhaps in large part because it was less strict with respect to the theory. This may be another reason why it won.

> Similar to how JavaScript became the standard PL for browsers.

I don't know how similar that is. I'm not sure there was ever another realistic alternative you could have ever chosen. The only real attempt to change that, VBScript, was likely to not work half the time due to not having the right dependencies on the host system, making it impractical for real-world use.

Maybe not anymore, but for a time there were practical alternatives to SQL.

> The first one rarely comes up in practice

The first one is the most common source of SQL bugs I see out in the wild. Complex joins can become quite unintuitive because of it. Nothing you can't learn around, and of course work around, but something you have to always be mindful of. As such, I'm not sure I agree that it rarely comes up in practice.

Not to mention I see a lot of people making use of that fact. It is a useful quality in practical applications. It also comes up quite a bit in practice because, frankly, often you don't want rows to be unique.

In practical applications, you pretty much always have synthetic row IDs in cases where there aren't any natural ones.

I think it would be more helpful if you could give a specific example of a simple SQL query that does not map nicely to a relational expression, since it's kind of hard to discuss the specifics in these vague terms.

I don't understand what you are looking for. There is no specific SQL query I know of that could not expressible in relational calculus in some manner. But that also has nothing to do with the discussion.

The discussion is about why SQL became the standard. Being first is not it. It wasn't first. It was second, but QUEL came along hot on its heels before SQL established itself. It was approximately another decade after that before SQL solidified dominance.

- Was there a specific technical reason to choose SQL over QUEL/LINUS?

- Was there a specific human reason to choose SQL over QUEL/LINUS?

- Was it just random chance and if we were to do it all over again we are just as likely to see QUEL/LINUS become the standard instead?

Firebase is a whole platform with auth, file storage, functions, etc besides just its DB feature, but maybe this wasn't always the case. Anyway, yes, I don't look past Postgres unless I have a very specific reason.

Maybe I'm like a Luddite or something, but I feel like I keep hearing about Firebase but still have no idea what it really is or why/how I would use it in a project. I'm just sitting here on my own building projects with mostly Postgresql DBs, once in a while MySQL, and not suffering massive security breaches. Thanks I suppose for giving me a data point that I'm most likely not missing anything.

It’s a hands—off database and auth service, initially intended to be directly accessed by thick clients, with little to no backend logic (although they have since added FaaS).

When mobile apps started out, most had little to no online features.

As the mobile apps market grew, more and more of these apps started requiring account persistence, sharing content with other users, real-time online interactions, etc.

That's when Backend as a Service became a thing (eg Parse), targeting developers with little to no server-side experience. And that's when Firebase popped up.

Ahhh Backend As A Service. I guess that makes sense. Not something I could see myself ever using, but I suppose I can see how somebody might use it if they don't know how to write and run their own backends or don't have authority to spin one up.

Guess I'm a little lucky in that I can spin up personal backend services just for kicks, and even though DayJob is pretty corporate and locked down, I can still spin up a new backend on my own with not much oversight as long as it doesn't touch certain sensitive things.

Thanks for a brief and clear description - it's surprising how few people can't seem to write one, and how many official corporate sites bury what their service actually does behind 10 pages of marketing fluff and stock photos.

When I was evaluating Firebase a few years back, the thing that most annoyed me was that their frontend library wasn't open source. Google just shipped an obfuscated and minified JS library. The lack of source mixed with their terrible docs made it a non-starter for me.

I remember having some issue, and thought: well, it's JS, let me just check the source like I normally would! Only to find out that you couldn't browse the full client source code anywhere. At that point my only option was to reverse engineer the minified source which just seemed silly and like a waste of time.

Firebase moat has nothing to do with their frontend library, which anyone could reverse engineer with a little bit of time. And yet they still kept it closed source. I don't know if anything has changed since then, but that was the primary reason why I lost interest in the service.

Supabase is the iPhone to Firebase's Palm V -- highly recommend, if you're a fellow millenial like me who grew up on mobile, and things like "much less code to just write a simple API backend for your thing" sounds like 6 months and paying another engineer.

EDIT:

loud buzzer

Careful, Icarus: "permissions can be setup to allow global read-writes" is a "vuln" of every system.

p.s. Any comment on why her blog has you guys "remembering Chattr" then getting a seedy Firebase pwner GUI, and yours has you diligently looking through .ai TLDs?

loud buzzer

Sorry, but supabase has a similar issue.

Another blog going over that has or will be made by Eva (referenced on the site)

Would be very interested in reading about SB. Has it already been posted?

> sounds like 6 months and paying another engineer.

If you take this approach, it's "pay now or pay later".

-- Fellow millenial

I think Supabase is much better than Firebase, but I find its security model worse; Firebase was very clearly designed with this in mind, while Supabase is just a Postgres DB with RLS as an afterthought.

One particular thing that annoys me with SB is that by default, or when you create a table with SQL, they're publicly accessible, which is very bad! (Firebase defaults to no access in production mode.)

In what way do you perceive it to be an after thought?

It's front-and-center constantly, and has _all_ access disabled by default on tables every time I use it.

It only has access disabled if you enable RLS on that table. If you do `CREATE TABLE`, or don't check the checkbox in the UI (TBF it's big and green and has a warning that's hard to miss), then access is public.

I guess my main concern is that it's hard to setup RLS correctly using SQL. Because it's two separate statements, if your `CREATE TABLE` succeeds, but the `CREATE POLICY` does not, you're also exposed. And it is more annoying than it should've been to test the rules (Firebase has a dedicated tool for that).

I now just use Supabase to host a normal Postgres that only my backend connects to. That works well.

I built a supabase app the past two days, and I agree.

I did find it a footgun that creating a table through SQL was not private by default. (Why doesn't Supabase apply RLS by default to tables created through SQL?)

Serverless also turned out to be more trouble than it was worth. In particular:

* Doing DB business logic in JS is gross.

* It's tricky to secure a table to be semi-public. e.g. you have a bookmark site and you don't want users to browse all URLs, just the ones they have bookmarked. The best solution appears to be disabling foreign-keys until transactions are done and then having a complicated policy.

* It's a pain to set up a CLI client that interacts with the DB. I think you have to copy-paste the access AND refresh tokens to it. I couldn't figure out a way to create my own API tokens.

A backend is nice, because it is private by default.

Don’t believe tables are readable by default even if you have defined any RLS policies for that table. I’m building something on SB right now and have been burned more than once because I thought that the absence of policy meant open access to everyone.

I just checked, and newly created tables without RLS are accessible to anyone: After running `CREATE TABLE x` in my SQL client (which succeeds with no warning), if I go back to the table UI on Supabase it says "WARNING: You are allowing anonymous access to your table". (It's good that there's a warning in the official interface, at least, but what if I use my own SQL client? What if my ORM is creating tables?)

Your confusion probably stems from how you can have RLS disabled, or RLS enabled with no policies. If you have RLS enabled with no policies, the access is restricted. But if RLS is disabled (or never enabled!), then your table is blasted to the entire internet.

This confusion kind of proves my point; if DB access from untrusted clients were baked into SQL since birth, RLS would probably be enabled by default.

The "when I create a table via SQL statements at shell it does what I say" isn't a vulnerability, I don't think.

The comment chain went long enough that I got confused and thought I was missing something, I started a brand new account, brand new project, brand new table, RLS is enabled by default, has a big recommended next to it highlighted, it is checked, the entire section is highlighted, and has documentation right below it. Source: https://imgur.com/a/X9oJ2i9

It's enabled by default, quite forcefully so

but I'm not a Postgres admin, maybe there's a stronger way you know of to enforce it, so you can prevent the footgun of CREATE TABLE?

I mean, I don't disagree, but what I'm saying is that SQL/Postgres (hence also Supabase) was not designed for databases accessed from untrusted clients, instead, it's an afterthought and it shows.

Whether it's a "vulnerability" or by design is another question, but it's definitely a footgun (particularly for new Supabase users that use an ORM like Prisma, which has its own UI and creates tables by itself).

The solution might just be to not let untrusted clients access your DB.

I don’t understand the RLS is disabled warning thing. I also have that warning on a project where I migrated to Supabase from a sql dump/restore from another PG instance.

I’m using supabase as “just Postgres” at the moment and the only access to the data comes from a server I control.

Could you explain how my data is being “blasted to the internet”?

Genuinely concerned if I’m grossly overlooking something.

If you don't use the client library (and never expose the anon key) you're most likely fine. If you do (even if just for Supabase Auth or so) your data is exposed and you need to enable RLS on all affected tables ASAP or an attacker can access the entire database, in a similar fashion in which OP did that with Firebase.

Gotcha, yeah I’m not using the client lib at all. Good to know.

> Firebase was very clearly designed with this in mind

Yes and no ;)

The original release of the Realtime Database didn't have security rules (though they were thought of at the time), and they were added in late 2013/early 2014 (IIRC). At that point, in the name of "easier getting started experience (don't force users to learn a custom DSL)", the default rules were `read: true, write: true`. As you might expect, it resulted in a high potential for this type of thing, and sophisticated customers cared _a lot_ about this.

This changed at some point post acquisition (probably 2016?) when the tradeoff between developer experience and customer security switched over to `false/false` (or picking something slightly more secure than `true/true`.

Firebase Security Rules were upgraded and added to Firebase (Cloud) Storage and Firestore, with both integrations being first class integrations, as _the whole point_ of those products was secure client-side access directly to the database from day 1.

The tricky part of all of any system in this space was designing a system that's simple enough to learn, highly performant, and also sufficiently flexible so as to answer the question "allow authentication based on $PHASE_OF_THE_MOON == WAXING_GIBBOUS" or some other sufficiently arbitrary enterprise parameter. Most BaaS products at the time optimized for the former, then the latter, and mostly not the flexibility; however, over time, it turns out that sufficiently large customers really only care about the last one! Looks like Firebase solved this recently with auth "blocking functions" (https://firebase.google.com/docs/auth/extend-with-blocking-f...) which is sort of similar to Lambda Authorizers (https://docs.aws.amazon.com/apigateway/latest/developerguide...), which I believe is a pretty good way of solving this problem.

Disclosure: Firebase PM from long ago

> "permissions can be setup to allow global read-writes" is a "vuln" of every system

Question is how much effort that is. It's scarily easy on Firebase, idk about Supabase.

Used it and can't actually recommend it. RLS policies slows down even simplest queries 1000x times sometimes, and postgres' current EXPLAIN ANALYZE isn't helping much. Testing app on it is still a pain. Default migration engine is oneway. Backed in database backups are close to useless. I mean, I managed to solve a lot of those issues for myself, but it still felt like I'm reinventing bicycles instead of doing actual work, and I still had a subpar experience.

I'll happily take 6 months pay to knock up a quick node api. :-). Just need to find a beach first.

What I found is you are right and FB is easier for the Millennial, Gen Z, Boomer or whatever IF everything you need can be done by rules and schema.

As soon as you need to write functions (because rules are not sophisticated enough or too slow/expensive, or you want to know why the thing got denied) then you are writing backend code.

It is actually easier to write the same code in a NextJS template - like there is less to learn, less docs to read. And then chuck it on Vercel which will deploy and devops it for you. So you have all the devops done for you like Firebase would and you have spent less time. Now if you are talking to postgres instead of firebase from the backend, it is actually easier IMO. A line to connect to pg. A line to issue a query.

Guess this is just my opinion, but it is less code to do so, less environment variable farting around, downloading a weird .json with all the credentials. If I were inclined I would write a blog post showing how much less lines of code are needed, how much less understanding is needed, and with the managed infra/DB offered by Vercel etc. you are still serverless, etc.

At that point, you might as well just use PostgREST.