Firestore
To be fair I meant only Firestore really, not Firebase the Platform. Ok, Firestore is not dead. It is quite popular. But it sh...
For further actions, you may consider blocking this person and/or reporting abuse
Hey Jonathan, this is a really insightful article, thanks so much for writing it 👏
I work at Prisma and shortly want to react to this. It seems like you're referring to Prisma 1, which was used to create a GraphQL server for your databases (similar to Hasura or Postgraphile).
However, the latest version of Prisma is actually a new kind of ORM (so it falls into the same category of tools as Sequelize or TypeORM rather than being related to GraphQL). Prisma solves the same kind of database problems developers as these tools, but approaches these in an entirely new way.
You can read more about it here: The Complete ORM for Node.js & TypeScript
Fireship also released a YouTube video about Prisma that might be worth checking out: Prisma in 100 seconds.
Hope this helps!
I need to test Prisma out. I thought Prisma 2 used GraphQL under the hood, and was just a JSON to GraphQL Client API? Very intrigued!
Firebase is dead. Jk it's not I don't mean firebase I mean Firestore. Sell actually firestore is really popular I mean I wish it was.
Dude f off with your click bait what a way to ruin your credibility.
I think my point here is that the development of Firestore is dead, and Firestore is not to be confused with Firebase. I'm hoping they change that.
Also apologies, I was having a crabby morning... It is a nice article, just had a "rahhhh" moment after being bait and switched a little upon reading the article :) but you got me to click it.. so that's part of the job i guess :)
Your article is good and I understand your point. It's one worth making. But, I think you also get my point that if you state in this comment that "Firestore is not to be confused with Firebase" then you go and name your article "Firebase is dead" and then go on to talk about Firestore is dead but not actually Firebase.. that is intentionally misleading.. it is confusing and contradictory.
Hi Scott. I honestly thought that was a good title when I finished it at 1 in the morning. However, I changed it to be more precise.
Check out Directus too (graphql, rest, db connected to knex in custom endpoints if you want direct db queries, auth, Any relational db...)
Woot! Some STRONG opinions here!! I love it!. Great assessment breakdown.
As you write, a lot of this has to do with the use case. Fbase and its integration with Firestore, its ability to host both front and back end, and the simplicity of its auth across providers all make it really great for an MVP and initial launch als "don't let the perfect be the enemy of the good"
Also, refactoring aside, there's an issue with ver.9? That's news to me. This isn't an Angular 1->2 jump. What's the"controversy?
Some people didn't like the Firebase 9 changes. I personally like it better now.
Hey Jonathan, lot of great insights in the article loved it.
Have you ever tried AstraDB ? (astra.datastax.com). It is based on noSQL Apache Cassandra with OSS Gateway on top of it named Stargate.io.
Scalable => 💯 (Cassandra better strength)
Realtime Data Support => 💯
A JS/TS Client Side API (or GraphQL) => 💯 GraphQL + JS client (github.com/datastax/astrajs)
Middleware Security => the Stargate layer does the security,
Cloud Hosted DbaaS Option => 💯
No Vendor Lock-In => 💯 , OSS Cassandra + OSS Stargate (sample docker compose github.com/datastax/astra-sdk-java...)
ACL with Login Methods => 💯 , Token will hold claims
Relational (SQL or Graph) => No, graph should come later this year though
(I work there, ping me if you need something)
Cheers.
I will check it out!
Besides the article title being clickbait....
This reminds me of the saying "it's not the hammer's fault that it won't drive a screw. It's the carpenter's"
Use the right database for the job. Relational is good at OLTP data. Document makes sense when you don't want to join 6 tables to simply render a webpage. For transactions use time oriented dbs like timescale or wide column. If you need text search ship the data to elastic.
The best advice is to not worry about any of these issues until you need to scale horizontally. If you still don't want to bother with any of that too then just pick a new sql system like cockroachdb or even better just use a cloud provider like memsql, dynamo or cosmos.yeah your going to pay for it but then you can focus on building great things instead of worrying about n+1 problems and over fetching of rows.
The point of a database is to persist data... Use cases are many and that is reflected in the choices at our disposal. Moral: Pick the right tools for the task at hand.
Well put. I am a firm believe that you should use the right tool for the job. That being said, people need to see the alternatives that CAN do what Firestore can't do out of the box. That is what this post is about. I believe competition creates innovation.
Well if that's what the post is about how about a title that reflects that??
You've already debunked the two statements in your post title
Hi Michael. I really didn't mean for this post to be click bait, I just had a lot of ideas I wanted to put in one post, and maybe I chose the title poorly. Perhaps it should have been a question instead of a statement.
I don't think I agree with those statements.
Most people join the Firebase platform due to Firestore. Firebase is still in development, but Firestore is not. The development is definitely dead on Firestore, and I purposely want to get their attention and call them out on that. Every other database grows after a year in features, but they have stopped.
I also do believe there WILL be a nearly perfect database, perhaps as early as next year. We shall see.
I am a firm believer that you should not have to manage two databases, when one database should add simple features like Full Text Search and Counters. MongoDB is a perfect example of how this should be done.
J
Let me take a different angle here. According to Gartner the database market size is a 60+ BILLION dollar industry. If there's going to be one perfect database in 2023, then there are a bunch of companies out there spending a lot of resources on what surely seems like a hopeless cause.
Hey there is no doubt we are seeing convergence in the industry as each product works to scale horizontally and adopt different data models (relational, search, document, wide-column, key-value, Realtime, timeseries, and graph.) One thing the industry is learning from each other is that each model has an appropriate use case, and no one model is the "best".
Sure Moore's law and the cloud will eventually make some of these decisions less relevant, but never irrelevant.
Cloud providers creating back-ends as services with pay as you go auto scale - like firebase - are what will really make databases irrelevant to programmers. And I for one, welcome it. I'd rather build interesting applications and spend my time on user experience than coding up DTOs, repository patterns, REST endpoints and graphQL interfaces so that I can self host on Kubernetes or swap out my back end databases on a whim. Been there, done that. Anyone is right to argue that using these services create lock in - especially if your code is not designed to be loosely coupled - but the real question is - why should it matter in 2022?
There will always be a need for SQL and data engineering, for example shipping data changes in real time from cloud firestore into some other database more conducive to ad-hoc analytics. But these skills will not be required of full stack developers of the future.
People in 90's be like "Machines and Robots will take over the world" after 2020, and here we are looping through firestore docs, and checking if our read counts doesn't increase rapidly 🙄. At some point I think It is happening I mean It is controlling us 🤔. (Just kidding! No can do!)
You might want to check out ArangoDB
arangodb.com/
It is my fav graph database. It scales more like MongoDB, so not as easily horizonal as Firestore, but not bad. For analytics, ArangoDB is pretty cool.
When you are using ArangoDB for more transactional UI stuff, it still is good - but I found an issue when using graph traversals for data sets... pagination. I think this might be an issue with all graph databases. When you do a traversal query, it would make sense that the order is deterministic - but there really isn't a good "start at". You have to traverse the whole graph regardless on each page. Maybe there is something that I was missing.
I do agree with you that Firestore really needs some query improvements. There is a lot I like about Google Cloud. What I don't like about Google is that they tend to focus only on what is trending. Firestore is still better than AWS's DynamoDB, but then there is AWS DocumentDB now. Google needs to do something here.
I don’t think all Graph databases have that problem and can index differently. My issue with Arrangodb, like Tigergraph, is the price. Need to see examples to compare. Thanks for info.
Well, it is open source with the Apache v2 license.
github.com/arangodb/arangodb
Similar to how MongoDB worked, they make money on the enterprise extras that are probably necessary for large scale deployments. However, you can roll a cluster or a single server on some compute. They also have Oasis, which is like Atlas.
All that said, I do like Firestore's pay as you grow model and GCP has a great free tier for prototyping. Most databases, if you still want performance, requires a minimum buy-in regardless of use. Sometimes the difference of a few hundred a month can pause experimental projects. I really hope Google does some nice updates to Firestore.
can’t you combine an AQL Traversal with the high-level operation LIMIT or use a FILTER to only include a subset of the ascending indexes?
Yes. But then your next page, you are running your traversal again.
One suggestion I read is to put a key/value of a random value then run a weighted traversal using that random number as a weight. That creates a deterministic response. Helps a bit. Still, if you traverse and return 100 responses then want 101 to 200, then you are still running the full traversal.
In a SQL or NoSQL, your more likely to be skipping items on an index. That is much faster than running a traversal then skipping. If your traversal is deterministic then the second page might return unexpected results.
I like Supabase, but still won't use it in production because of how strong google is - with their own infrastructure and everything
Redis is an amazinggggg choice for a database too. But still, I'd stick to SQL and firebase for now, just because of the good infrastructure
So, in light of these comments, I changed the title. I am here to give to the community, and I will try and do better with my titles :)
Yeah Firestore is a really poor choice for things that need to count and naive implementations of aggregations would cost a fortune. I'm going to check out your list of Graph databases as I last looked a couple of years ago. For now, my goto solution is JSON in MySQL with an enhanced MongoDB query language for the server that can handle joins and aggregates (and that publishes an API that uses GraphQL).
not a single mention of postgres... has been renamed to supabase ?
it is indeed not to compare with firestore; but as supabase totally relies on it, it should be given credits. i also see nhost positionning itself as a supabase competitor; also relying completely on postgres.
with redis, both have been around for decades. kind of recently, neon for postgres, somehow promoted by vercel, is something to look into
As someone with an obsession for testing data transport/storage software, I find this awesome. Give keystonejs a try! It is a code-first graphql headless cms that generates a Prisma schema and graphql server (with admin panel).
I'd be curious to hear what you think about StaticBackend. I started the project in end of 2019, now a MIT-licensed free and open-source backend API.
In my biased opinion, it's way closer than Firebase than what Supabase is doing, since Supabase is auth and database. StaticBackend provides most of the common building blocks for typical web/mobile applications. Things like sending emails, scheduled tasks, worker queue, resizing images on top of the classic auth, database, storage and realtime.
Aggregates are WIP. Otherwise, it seems to fit the bill of what you're looking for.
GitHub repo: github.com/staticbackendhq/core
Was swayed by this article to try out Supabase about two months ago. So far, quite happy with my database and auth, definitely saved a lot of time and considering to use it again. Also works great with TanStack React Query!
All that's left is seeing how it performs and scales, which I doubt I will encounter anytime soon for small-mid size projects
Thanks!
Maybe I do not quite understand the details, but just using a wrong title to get people to read it is not good. Sad, because I kinda like how you wrote this.
We humbly ask that you take a look at schemafreesql.com. It emphasizes rapid application development. Has a SQL backend like edgedb but can integrate with most any sql db. Is Object Orientated but schemaless. Objects are classless and untyped. NOT a ORM.
Cloud version only for now. Multi cloud coming soon and self hosted version in the works.
Don't forget Redis. It is great but you have host it in cloud somewhere.
Redisgraph would be the way to go for me because it is relational. It is also cloud hosted. However, it does not scale well horizontally (from my understanding), can get very expensive, and most importantly, there is no middleware. I am a big fan of redisgraph either way.
Try Supabase and Redis.Redis has come along a long way and now it is flexible to use.
Only thing I don't like about Prisma is that they don't officially support arm64v8 so can't use it on a Raspberry PI 4.. (Or at least I haven't found a way to yet)