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]
Depends on what you mean by offline, but we're able to interact with UI and trigger mutations while offline, and it will replay the graphql calls in correct order once online again.
With Firestore, even when offline you still see your edits in your query results (flagged as such). This cannot be done with GraphQL, as the meaning of a GraphQL mutation is arbitrary, so the client can't change the offline query results accordingly.
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.
This isn't necessarily true. I helped build a business on top of AppEngine. We did $80m gross in our first year. Our bill went up to about $500 a month. Why so low? Because we designed the system to scale from the start. We became experts in how to make the system work for us. We knew what would end up costing us money, so we engineered it from the start so it wouldn't cost us money.
Here is the case study written after I left the company...
I looked at what you're doing. I don't want to learn to write GraphQL markup in a new DSL. Honestly, what you've created is a solution looking for a problem.
Do you prefer a UI? Like Hasura, AppSync, 8base, and firebase? The DSL is very very close to GraphQL’s SDL though, so learning it shouldn’t take more than 5 minutes.
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/
Yeah GraphQL APIs are not tedious to work with, I LOVE GraphQL Codegen for TypeScript and it works very well with my DSL. What's tedious is building a GraphQL API, not consuming it.
Firebase is a whole suite of tools/services for building online apps. These apps can do things, like talk to a database.
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.
I have an iOS Flutter and a webapp that talks to this as a backend for my business. It is private and all low usage, but I like the idea that this is infinitely scalable and doesn't require any effort to maintain.
Infinitely scalable's a bit of myth in my experience. We've switched firebase app to a small postgres instance and have seen all of our performance issues magically melt away.
Cloud Firestore how does that relate to Datastore? Really wish Google would allow multi-region Cloud SQL like AWS allows with RDS. Datastore is such a pain to use with its index requirements
Cloud Firestore scales just fine, like any database, you have to know how to work with it. You switched from a nosql database to a sql database... two totally different performance profiles.
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.
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.
- 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.
> 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
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.
200ms would likely be fine (although not ideal), but I've seen more like to 3000ms with Firebase Cloud Functions, and have heard stories of similar with AWS Lambda.
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.
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.
100% yes. If you want to leave Nhost for some reason we'll help you with that.
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).
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.
Sorry I fail to see the big distinction between Firebase realtime synchronization and graphql subscriptions. There might be one, and I just don't see it as I'm not intimately familiar with Firebase.
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.
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.
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!