Show HN: Nhost – Open source Firebase alternative with GraphQL
nhost.io
nhost.io
Using postgresql alone would make this super exciting. Adding graphql takes it to "giddy" level for me.
Is there a story for offline support? Is there perhaps a react library that could help here? The tutorial uses subscriptions, wonder what happens when the app goes offline?
This is so amazing. I'm going to play with it and Svelte and see how it goes.
Well done!
disclaimer: I made RxDB
[1] https://github.com/pubkey/rxdb
[2] https://hasura.io/learn/graphql/react-rxdb-offline-first/int...
Use case I'm thinking about:
- At first the mobile app has no account, db is used without online backend.
- Then user pays for premium features including online backup/sync.
- This user then is created and all the data will be put in the online db and syncs, etc.
- No local SQLite db or anything needs to sync, because you have this offline first database, that can handle offline only.
This seems like an obvious use case to me, but have had trouble figuring out best path forward.
If the interface is graphql, you should be able to use Apollo Client[0] which has offline support.
Can you please elaborate? What are you trying to do and why it's a pain?
I'm planning to use it for a side-project, the first in a long time, and I'm trying to wrap my head around it.
For that $10, I get database backups, custom domains and no idea what team projects are, but I can add others to my project. On top of that, I also get everything else that firebase offers... task queue (PubSub), log analysis, hosting, realtime database, analytics, ability to hire someone who knows firebase/gcp, google's entire devops team.
In order to get a bit closer to that level of features, I'd have to bump up to the $39/mo plan. While I appreciate the competition, this doesn't compete for me yet.
I don't know much about firebase. How does firebase relate to postgresql?
I think the main reason you'd want to use Nhost instead of Firebase is for the tech we use. Mainly Postgres and GraphQL and how we got all services (database, api, auth, storage) working together very nicely, just like Firebase.
Cloud Firestore is a nosql database offering on Firebase. Cloud SQL Postgres is a database offering on GCP.
Firebase Cloud Functions (FCF) are 'serverless functions'. You upload some code that looks like an Express app. I personally use the npm package 'apollo-server-cloud-functions' to provide Apollo Server GraphQL endpoints using 'type-graphql'. If you do it right, there is very little vendor lockin. I theoretically could use this same code on Nhost.
Since it is all Google, Firebase can 'talk' to anything on GCP. Thus, my FCF can use 'mikro-orm' to talk to my cloud sql postgres database.
I know, a lot of names... but once you wrap your head around it all, it starts to get a bit easier. The nice thing about all of this is that I get one small usage based bill every month and it just magically runs without any devops or thought on my part.
Do you mean Cloud Firestore?
To be clear, when I reference the infinite scalability, I mean the ability of cloud functions to spin up as many instances as I need.
In terms of database load, I'd fully expect to have to migrate to a larger instance, but that is also relatively easy with cloud sql postgres.
https://github.com/pragmalang/pragma
I've been working on this for the past 14 months. Would love some feedback.
The problem we’re solving is the tediousness of building a GraphQL API.
We decided to work on this 14 months ago because me and my co-founder have built many backend systems and 99% of the time it’s just CRUD, auth and some validation and transformation logic, yet it would still take a lot of time to get something done.
The problem is very clear to us, but we’re trying to refine the solution to have something that is 10x better than what is already in the market.
We went with the DSL route because we wanted to support as many languages as possible for “turing complete” logic and not get tied up to one language. Also, text is great, and running locally is even better because it gives you the freedom to integrate it into any system very easily, unlike UI-based cloud solutions which are neither text nor run locally.
The GraphQL API isn't tedious. I write one language, TypeScript. The rest is all automatically generated for me. Fully typesafe, easy to unit test, fast to add features, not much boilerplate. Check out: type-graphql + https://graphql-code-generator.com/
Now I wrote this as an answer to you, but it's in reality just speculation and the reason why I avoid Google (and Amazon) services like the plague. They are competitive but just the possibility of the above scenario happening would keep me up at night.
Here is the case study written after I left the company...
If they decide to kick you out, hike the price or Google buries it you have a gigantic problem.
We're excited to introduce you to Nhost!
When building web and mobile apps, developers spend a considerable amount of time just to have a working skeleton deployed and ready-to-use. Things like provisioning and configuring servers, creating and configuring a database, implementing an API, authentication and authorization for users, storage for files and images, and a bunch of other security related work. Creating and maintaining all this infrastructure takes hundreds of hours and manual tasks each year.
We believe that those things are better offloaded to domain experts so that you can focus on accelerating your product innovation and growth.
Nhost allows products to get a ready-to-use, secure and performant backend in roughly 40 seconds, rather than months by integrating a bunch of open-source (no vendor lock-in) components and best practices.
Let us know if you have any questions or suggestions, we would love to hear from you.
Some feedback:
- Have you considered offering compute? The ability to run a proper backend would be a dealbreaker for me. Not having a backend is advertised as simpler but in my experience it's the opposite, especially when integrating mobile apps that have a long lag time on updates. You simply don't get enough flexibility for complex tasks, even with something like Hasura. Heroku offers docker containers with fixed resources that might be a good way to go. If you could offer some kind of managed container service that allowed me to share resources between all my containers then even better. Maybe you could build something on / offer a managed version of https://github.com/dokku/dokku ?
- Managed Redis or some other in-memory caching service would also be super useful. This is really important for scaling efficiently.
- Do you have any kind of availability / durability guarantees? This is super important for us at $DAYJOB as we provide similar guarantees to our clients.
- Pricing seems reasonable, although a tier between Pro and Enterprise or a more "pay what you use" plan might be a good. We'd probably just about fit into the "Pro" tier for now but would be needing the Enterprise tier soon. We're currently paying more than the cost of the enterprise tier. However, that covers the cost of compute in addition to our databases and storage.
- Yes, either cloud functions (like Vercel's `/api` approach that we love) or docker containers (something like Google Cloud Run) will be one three big features we'll be working on next.
- Noted!
- Not right now. But as soon as we start getting those requests from customers we'll prioritise it.
- Noted!
Again, thanks for the feedback!
I'd love to use one of these serverless solutions (cloud run in particular looks great). But there is a key problem that they seem to share: cold starts. Our app doesn't see a lot of traffic, so we can happily run the entire thing on the equivalent of a small VM. If there was a massive traffic spike then I guess this would fall over, but we're an enterprise app so this is unliekly and we could fix that pretty quickly by provisioning more servers (in heroku this is as simple as dragging a slider). But even if we couldn't, falling over in abnormal conditions seems greatly preferable to there being a good chance of 3 seconds+ of latency being added to a normal everyday request.
If you can solve this then you're on to a winner.
But the best thing would probably be to have it as an option. Scale down to 0 (cold starts) or 1 (no cold starts).
The fundamental problem seems to be the VM-or-container-per-request model. That means as soon as you get an extra concurrent user you have another cold start even if you already had one resource going. Whereas with a classic backend one server (even a small one) can handle thousands of concurrent requests and thus you have plenty of breathing room to start up another server before the current one gets completely bogged down.
Is there a more flexible pricing plan in the works? A hobbyist app could still be storing a large amount of data but not charging much to justify a $300/m db bill.
If you have custom needs I can help you out. Just send me an email: johan@nhost.io.
Nhost and Supabase both use Postgres.
The difference is that we use GraphQL (Hasura) for the API layer. We also offer authentication (email/password + OAuth) and storage (Minio S3) with permissions.
I think I've read something about Supabase adding authentication recently or they are working on it (https://supabase.io/docs/library/authentication/).
Yes, we have released Auth, using Postgres Row Level Security and Netlify’s GoTrue.
Here are the links you’re looking for:
I don't really use Nhost for anything currently, but I'm definitely rooting for them. The product is really well made, and is exactly what I was looking for at the time (a completely managed Hasura instance). For their sake, I wish they didn't have to compete with the insanely generous free tier of Firebase, as that's nearly impossible to compete with as a new company. I think the Nhost pricing model becomes much more reasonable as you scale in size.
I hope to have the need to use Nhost again in the future. Would recommend.
- Database (PostgreSQL)
- GraphQL API (Hasura)
- Auth & Storage (Hasura Backend Plus)
- Storage server (Minio)
You can read more about self hosting here:
https://github.com/nhost/hasura-backend-plus
We automatically configure and host these open source softwares as part of your Nhost project.
We already helped one customer in India doing this. They are a consultant agency and their customer had a requirement to be on AWS (We currently use Digital Ocean).
It use PostgreSQL for storage, it supports serverless functions using OpenWhisk, it allows you to write authorization rules, and it sets up user authentication workflows.
The project is open-source, any feedback is highly appreciated: https://github.com/anasbarg/pragma
Personally I prefer the pay as you go, as it's fair for both parties. Whereas with tiered payments, someone is always paying more than they need...
But I agree with what you say. Having a "pay for what you use" is in a sense more fair, but less predictable.
Nhost seems to be based on the Hasura GraphQL server so you would implement live synchronization of data using GraphQL subscriptions. Hasura runs each subscription in a per second poll to get live data for each subscription. If the data changes it passes down the result to the graphql client.
https://github.com/hasura/graphql-engine/blob/master/archite...
Firebase data retrieval definitions and graphql subscriptions look very similar too me. Both methods allow you to describe some data record(s) or document(s) to be fetched, fetches it, and then listens for server notifications about data changes for it including the changeset or new data.
https://firebase.google.com/docs/database/admin/retrieve-dat...
That clients receive events in milliseconds with Firebase and potentially with a second delay with Hasura is a performance detail. The functionality still serves the same general purpose? When one client modifies some document or record immediately notify all subscribing clients.
We got lots of customers using Nhost for the backend, and Vercel for the frontend. Great combo!