This is so, so interesting. There have been lots of discussions about PouchDB and GunJs but they always seemed limited in the backend story. I've been trying to get Couchdb to work with my own proxies for about a year and it is a big pain point. But, the real time synchronization and offline support is so compelling with those stacks. Thinking in documents and only about your front end code (letting the library do the hard work of synchronization) removes a lot of stress.
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.
You should try RxDB. It is based on pouchdb and therefore supports offline first [1]. Also you can use the graphql replication so that you are not limited to couchdb backend. Also there is a course made by hasura about using RxDB with their backend [2]
There are react libraries that offer a basic level of offline support (urql, apollo). You can maybe query data you already have cached, perform mutations and optimistically update the cache offline while the update is hopefully queued (maybe persistent across restarts?) until you go back online. Nothing close to couchbase or realm sync though.
For some pricing perspective, I'm on firebase/cloud functions. I pay ~$10/month for their smallest cloud sql postgres instance and the rest of the usage pretty much falls under their free tier.
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.
And then, your projects start to scale hand your bill goes up exponentially. Firebase start to become 70% of your total business cost. You look for alternatives but soon realise that it would be an immense effort to move away since you have everything interconnected in Firebase. So you take it. Until one day, something changes: a policy, a feature, maybe your gmail account gets banned and your firebase closed. And you still have all the eggs in the same basket and can't move them.
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.
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.
This looks pretty great. Our SAAS product was initially based on Firebase, but we're in the process of migrating to almost the same stack that you are offering (but hosted on Heroku) as firebase is quite limiting
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.
That's a dramatic jump in pricing from 0-5 GBs to > 5 GBs.
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.
I have been bitten by Firebase scalability restrictions before, so good to see alternatives coming up. How do you compare to Supabase (http://supabase.io/)?
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 used Nhost a few months ago for a small project. The pricing was originally a huge block for me. I emailed them (elitan here on HN) to talk about pricing. He took my feedback and ended up giving me a big discount on a single project. Overall I was very impressed with the attention and customer service I got.
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.
I've been testing NHost the past few weeks, and I have to say that (A) it's fantastic, and (B) the support is even better. The combination of Postgres plus Hasura, plus a really nice smooth auth solution makes development and deploy fast and easy.
I've been working on a language for building GraphQL servers quickly.
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.
One of the biggest advantages to firebase is its Blaze Plan, in which you pay for how much you use each service. This project seems to only have the standard 3 tier plan...
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...
If it is really a Firebase alternative, how does it manage live synchronization of data between users? or "cloud functions"? didn't find anything on the website.
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.
[+] [-] xrd|5 years ago|reply
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!
[+] [-] typingmonkey|5 years ago|reply
disclaimer: I made RxDB
[1] https://github.com/pubkey/rxdb
[2] https://hasura.io/learn/graphql/react-rxdb-offline-first/int...
[+] [-] gedy|5 years ago|reply
If the interface is graphql, you should be able to use Apollo Client[0] which has offline support.
[0] https://www.apollographql.com/docs/react/
[+] [-] kall|5 years ago|reply
[+] [-] atmosx|5 years ago|reply
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.
[+] [-] Graphguy|5 years ago|reply
[+] [-] latchkey|5 years ago|reply
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.
[+] [-] duiker101|5 years ago|reply
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.
[+] [-] anasbarg|5 years ago|reply
https://github.com/pragmalang/pragma
I've been working on this for the past 14 months. Would love some feedback.
[+] [-] brunoqc|5 years ago|reply
I don't know much about firebase. How does firebase relate to postgresql?
[+] [-] solarkraft|5 years ago|reply
If they decide to kick you out, hike the price or Google buries it you have a gigantic problem.
[+] [-] elitan|5 years ago|reply
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.
[+] [-] nicoburns|5 years ago|reply
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.
[+] [-] ctrlaltdylan|5 years ago|reply
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.
[+] [-] elitan|5 years ago|reply
If you have custom needs I can help you out. Just send me an email: [email protected].
[+] [-] inian|5 years ago|reply
[+] [-] elitan|5 years ago|reply
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/).
[+] [-] buzzerbetrayed|5 years ago|reply
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.
[+] [-] chris_st|5 years ago|reply
[+] [-] elitan|5 years ago|reply
[+] [-] mkarliner|5 years ago|reply
[+] [-] elitan|5 years ago|reply
- 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.
[+] [-] wayneftw|5 years ago|reply
[+] [-] elitan|5 years ago|reply
https://nhost.github.io/hasura-backend-plus/
[+] [-] anasbarg|5 years ago|reply
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
[+] [-] gitgud|5 years ago|reply
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...
[+] [-] elitan|5 years ago|reply
But I agree with what you say. Having a "pay for what you use" is in a sense more fair, but less predictable.
[+] [-] Scarbutt|5 years ago|reply
[+] [-] snorremd|5 years ago|reply
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...
[+] [-] luminati|5 years ago|reply
[+] [-] elitan|5 years ago|reply
https://github.com/nhost/hasura-backend-plus
[+] [-] Rauchg|5 years ago|reply
[+] [-] elitan|5 years ago|reply
We got lots of customers using Nhost for the backend, and Vercel for the frontend. Great combo!