Open Source Firebase Alternative with GraphQL(nhost.io)
nhost.io
Open Source Firebase Alternative with GraphQL
https://nhost.io/
45 comments
Yea Nhost is a Backend as a Service (BaaS) but I'm not sure Firebase has "won".
Whant we hear form our users is that they like Nhost because of:
- Open Source
- SQL (Postgres)
- GraphQL (Hasura)
- GitHub Integratoin (like Vercel & Netlify)
> for tech people it's just as easy to spin up an instance in some cloud somewhere.
I think this is the biggest missconseption.
Just look at Vercel and Netlify. They host html/css/js as a core business and they have million of users combined. Why? Because they make it extreamly easy for developers to be *productive* and they hook into developers' workflow with Git.
Most of our users at Nhost can spin up servers and infrastructure on their own, but are they using their time optimally by doing so? Or should they instead spend time building what's important for their business and users?
Whant we hear form our users is that they like Nhost because of:
- Open Source
- SQL (Postgres)
- GraphQL (Hasura)
- GitHub Integratoin (like Vercel & Netlify)
> for tech people it's just as easy to spin up an instance in some cloud somewhere.
I think this is the biggest missconseption.
Just look at Vercel and Netlify. They host html/css/js as a core business and they have million of users combined. Why? Because they make it extreamly easy for developers to be *productive* and they hook into developers' workflow with Git.
Most of our users at Nhost can spin up servers and infrastructure on their own, but are they using their time optimally by doing so? Or should they instead spend time building what's important for their business and users?
>Yea Nhost is a Backend as a Service (BaaS) but I'm not sure Firebase has "won".
Firebase is a nightmare since they folded it into GCP. As a standalone product it was complete, easy to grok, and simple to secure. Now I feel like I literally need to hire a CISSP to make sure my whole company wont be hosed by a single security rule misconfiguration buried somewhere in GCP.
Firebase is a nightmare since they folded it into GCP. As a standalone product it was complete, easy to grok, and simple to secure. Now I feel like I literally need to hire a CISSP to make sure my whole company wont be hosed by a single security rule misconfiguration buried somewhere in GCP.
Last I checked you can't actually access the underlying Postgres database through standard DB connections, the marketing is misleading.
Perhaps Forebase was the first one to do it right, the biggest features were Real-Time and as you've mentioned, Push notifications. Everyone else has been attempting to compete. The big win for us is that many of these solutions are open source. Shout-out to Supabase and shout-out to Postgresql which allows for this to be possible.
Firebase is a great solution but...
It's closed source and locks you into Google Cloud.
You can't self host. And since it's pay for use, you can end up with large unexpected bills for a variety of reasons.
It doesn't have full text search.
It doesn't have a relational database.
I'm sure there are more things. Firebase is awesome but it's definitely not the ultimate solution.
It's closed source and locks you into Google Cloud.
You can't self host. And since it's pay for use, you can end up with large unexpected bills for a variety of reasons.
It doesn't have full text search.
It doesn't have a relational database.
I'm sure there are more things. Firebase is awesome but it's definitely not the ultimate solution.
Firebase at it's core is just Google Cloud, same with AWS Amplify just being various AWS services neatly delivered. I imagine some people are using the exact same services just through Google Cloud and AWS. Cloud Messaging == SNS, Lambda == Cloud Functions, Firestore == DynamoDB etc.
I think you might be underestimating their reach though, they're very popular in app development shops, since an app developer doesn't need to know how to build a serverside application in order to get an app that needs remote services working.
I think you might be underestimating their reach though, they're very popular in app development shops, since an app developer doesn't need to know how to build a serverside application in order to get an app that needs remote services working.
I’m primarily a frontend developer. The task i hate most is dev-ops like stuff and dealing with Aws in any capacity. If i was to create a start up I would 100% use something like this or Supabase.
Let us know if you need any help getting started! [email protected]
FWIW I speak to quite a few early-stage startup CTOs, and Firebase is extremely popular among app developers.
Additionally looks like some very high profile apps are using it, or at least have done so in the past: https://cloud.google.com/blog/topics/startups/bereal-creates...
Additionally looks like some very high profile apps are using it, or at least have done so in the past: https://cloud.google.com/blog/topics/startups/bereal-creates...
AWS now has a firebase copy-cat, Amplify. I thought Parse was still being maintained by the community. Appwrite is another offering in the space.
The mobile push service is indeed a great feature from Firebase, which we will also implement when possible. We already provide a realtime API through GraphQL subscriptions.
How does this compare to Supabase? Is this easily self hostable? I'm seeing lots of movement in this space and it's getting harder to keep track.
There is a lot of movement indeed in this space. Here are a few things that I think we at Nhost are doing well:
- Open Source: Nhost is open source. Some competitors are, too, and some are not.
- Infrastructure: Our infrastructure is set up to handle anything from side-projects to companies with hyper-scale. Each service, except the Postgres database, is stateless and can scale horizontally.
- UI: The Nhost Dashboard, although under development, will give us an edge in the next six months. Most database and backend dashboards look like they were built by engineers (without designers) in 1997. There is so much room for innovation.
- Tech: We're using well-used and open source technologies with little to no abstractions in our stack, from SQL (Postgres) to GraphQL (Hasura), to Node.js for Serverless Functions. Here I see competitors using either old technologies or building abstractions, forcing them to re-invent already solved problems, and forcing users to re-learn already battle-tested solutions.
- Workflow: We're not just an "infrastructure company." The goal with Nhost is to make developers as productive as possible. We have a CLI for local development and a GitHub integration that automatically deploys your backend (just like Netlify & Vercel). This way, our customers can focus on their business and users instead of figuring out development workflows. Here I see competitors either building custom in-house branching solutions outside Git or nothing.
In the end, I'm glad to see competition in this space. The winner of healthy competition is developers who can pick the services that best suit their needs. And that's the ultimate goal. To empower developers to build.
- Open Source: Nhost is open source. Some competitors are, too, and some are not.
- Infrastructure: Our infrastructure is set up to handle anything from side-projects to companies with hyper-scale. Each service, except the Postgres database, is stateless and can scale horizontally.
- UI: The Nhost Dashboard, although under development, will give us an edge in the next six months. Most database and backend dashboards look like they were built by engineers (without designers) in 1997. There is so much room for innovation.
- Tech: We're using well-used and open source technologies with little to no abstractions in our stack, from SQL (Postgres) to GraphQL (Hasura), to Node.js for Serverless Functions. Here I see competitors using either old technologies or building abstractions, forcing them to re-invent already solved problems, and forcing users to re-learn already battle-tested solutions.
- Workflow: We're not just an "infrastructure company." The goal with Nhost is to make developers as productive as possible. We have a CLI for local development and a GitHub integration that automatically deploys your backend (just like Netlify & Vercel). This way, our customers can focus on their business and users instead of figuring out development workflows. Here I see competitors either building custom in-house branching solutions outside Git or nothing.
In the end, I'm glad to see competition in this space. The winner of healthy competition is developers who can pick the services that best suit their needs. And that's the ultimate goal. To empower developers to build.
It looks like it's self-hostable using docker, so a no-go for me.
Why not extract the Docker image then (just a .tar.gz) and run it "raw"?
looks more like a Hasura distribution than a distinct tool?
Nhost CEO here.
Hasura GraphQL Engine is one of the open source tools we're using for the Nhost stack. But it's "only" one of the open source technologies we're using.
Others are:
- Postgres. Who doesn't love Postgres?
- Hasura Auth: https://github.com/nhost/hasura-auth
- Hasura Storage: http://github.com/nhost/hasura-storage
- Serverless Functions (Node.js)
On top of that we have SKDs in JS/TS/React/Next.js/Vue.
And a CLI for local development and a GitHub integration so you can deploy your backend just like you deploy your frontend with Netlify and Vercel.
Hope that clarifies a bit.
Hasura GraphQL Engine is one of the open source tools we're using for the Nhost stack. But it's "only" one of the open source technologies we're using.
Others are:
- Postgres. Who doesn't love Postgres?
- Hasura Auth: https://github.com/nhost/hasura-auth
- Hasura Storage: http://github.com/nhost/hasura-storage
- Serverless Functions (Node.js)
On top of that we have SKDs in JS/TS/React/Next.js/Vue.
And a CLI for local development and a GitHub integration so you can deploy your backend just like you deploy your frontend with Netlify and Vercel.
Hope that clarifies a bit.
Can you tell who develops Hasura Auth and Hasura Storage? You? Or did you fork it and extend it?
Both are built by us, yes.
Hasura Auth has 1M+ pulls on Docker Hub and we have JS SDKs for both Auth and Storage.
Code: https://github.com/nhost/nhost/tree/main/packages
Docs: https://docs.nhost.io/reference/javascript
Hasura Auth has 1M+ pulls on Docker Hub and we have JS SDKs for both Auth and Storage.
Code: https://github.com/nhost/nhost/tree/main/packages
Docs: https://docs.nhost.io/reference/javascript
Both developed in-house from Nhost' engineers and OSS https://github.com/nhost/hasura-storage
https://github.com/nhost/hasura-auth
built to leverage Hasura's features and driven by users needs
built to leverage Hasura's features and driven by users needs
why would i use this instead of just paying Hasura?
in other words: what’s your moat?
in other words: what’s your moat?
Just paying Hasura gets you just Hasura (at least before Neon it used to)
NHost gets you Hasura, the underlying postgres db, pre-configured auth with JWTs, blob storage, functions and a client-side library to get all of that working together with nearly zero configuration.
edit: also, Hasura's cheapest offering ($100 / month) is still prohibitively expensive for indie projects (That's just Hasura - you would have to add database costs, auth costs and blob storage costs to that $100).
NHost gets you Hasura, the underlying postgres db, pre-configured auth with JWTs, blob storage, functions and a client-side library to get all of that working together with nearly zero configuration.
edit: also, Hasura's cheapest offering ($100 / month) is still prohibitively expensive for indie projects (That's just Hasura - you would have to add database costs, auth costs and blob storage costs to that $100).
Just to add to the comment: you also have backups, automatic logs on all services, raw access to postgres (you can do whatever you want with it), custom integration with stripe, plus specific dashboard for users, database, and storage.
It's freaking crazy
It's freaking crazy
Here's an image that illustrate it well: https://i.imgur.com/5Zn8tfS.png (from our website).
We also provide SDKs in JS, TS, React, Next.js, and Vue: https://docs.nhost.io/reference/javascript
We also provide SDKs in JS, TS, React, Next.js, and Vue: https://docs.nhost.io/reference/javascript
Was it tested, by chance, to run with Cockroachdb or Yugabytedb? We are migrating off non distributed solutions and the Postgres native solutions we tried just weren't easy to set up and use, while the two newcomers are. Any advise in that direction? We are using Yugabyte mostly now for testing if everything works and if it's robust; so far it works very well -> we were very happy with Cockroach, but not with the license.
Hasura CEO here. If you're trying or evaluating using hasura (or nhost) along with Yugabyte / Cockroach feel free to reach out (email in bio). Happy to have our team help with any architecture or benchmarking things you might run into!
Same here. Drop me a line at [email protected] if you need any help.
If I understand it correctly, Nhost depends on S3.
So Nhost is either not vendor-neutral, or must be used alongside with AGPL S3 implementations.
So Nhost is either not vendor-neutral, or must be used alongside with AGPL S3 implementations.
Storage is using S3. We use AWS S3 at Nhost, but you can use Minio (open source) if you self-host.
But the good thing with Nhost is that it's open source, so if you want to implement something other than S3 as the core storage layer, you can do so: https://github.com/nhost/hasura-storage
But the good thing with Nhost is that it's open source, so if you want to implement something other than S3 as the core storage layer, you can do so: https://github.com/nhost/hasura-storage
Looks interesting, though I’d hesitate to tie my infra to GraphQL out of the box. Unless I’m mistaken
Most of the users I've seen using Nhost (and Hasura) treat data/the db as the source. Given that you have raw access to postgres, you are also the full owner of your data and you can swap interfaces as you see fit (I've seen users use Hasura internally and not expose it to the internet)
Notice, also, that Hasura has support for REST endpoints.
Notice, also, that Hasura has support for REST endpoints.
Ah nice, didn’t catch that thanks. As long as it’s an option lol.
If you don’t care for object-level caching, you can always query a GraphQL endpont with just a simple HTTP client.
I _just_ started using Firebase and I'm already worried about cost. Is this a drop in replacement for it ? All my code will work against nhost , just change the config files ? Or what does the transition look like at the moment ?
Very excited for this!
Very excited for this!
Better to migrate to something open-source without vendor lock-in while small. If you need any help to understand what would be needed, feel free to email me at [email protected].
why hasura instead of postgraphile?
I've used Hausra since 2018 and it has turned out great:
- 28k stars on GitHub
- Unicorn Startup with $136M in funding
- Notable users of Hasura GraphQL Engine: Netlify, Walmart, Airbus, Atlassian, Nhost ;)
- Support for multiple databases (Postgres, MS SQL, BigQuery, etc)
- Hasura Console (UI)
- Hasura handles row AND column level permissions instead of only Postgres row-level security.
- Database Event Triggers
- Overall a bigger communtity, great docs, lots of example.
- 28k stars on GitHub
- Unicorn Startup with $136M in funding
- Notable users of Hasura GraphQL Engine: Netlify, Walmart, Airbus, Atlassian, Nhost ;)
- Support for multiple databases (Postgres, MS SQL, BigQuery, etc)
- Hasura Console (UI)
- Hasura handles row AND column level permissions instead of only Postgres row-level security.
- Database Event Triggers
- Overall a bigger communtity, great docs, lots of example.
Great way to invite a mud-slinging contest ;^)
Evaluate them both, use whichever fits your usecase/you like best.
Evaluate them both, use whichever fits your usecase/you like best.
Definitely should evaluate both. Still curious about nhost's perspective.
Postgraphile is built out of wet noodles (JavaScript) and Hasura is Haskell. That's enough for me. JavaScript doesn't belong on the backend.
Just curious what the market size is for these types of services? It doesn't seem like anyone really uses them; for tech people it's just as easy to spin up an instance in some cloud somewhere. For non technical people, well these types of services still seem to be too complex.
I think the one thing Firebase has going for it, that is a differentiator is it's mobile push service that pushes to both iOS and Android. There aren't many options there.