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.
Well done!
typingmonkey 1273 days ago [-]
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]
Last I checked Apollo had a persistent cache but not true offline support.
gedy 1272 days ago [-]
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.
yencabulator 1270 days ago [-]
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.
jamil7 1272 days ago [-]
Oh! That’s impressive I think last time I used it mutations couldn’t be triggered offline.
kall 1273 days ago [-]
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.
atmosx 1272 days ago [-]
> I've been trying to get Couchdb to work with my own proxies for about a year and it is a big pain point.
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 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.
duiker101 1272 days ago [-]
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.
latchkey 1272 days ago [-]
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've been working on this for the past 14 months. Would love some feedback.
latchkey 1273 days ago [-]
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.
anasbarg 1273 days ago [-]
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.
latchkey 1272 days ago [-]
UI for what?
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/
anasbarg 1272 days ago [-]
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.
> I'm on firebase/cloud functions. I pay ~$10/month for their smallest cloud sql postgres instance
I don't know much about firebase. How does firebase relate to postgresql?
latchkey 1273 days ago [-]
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.
mescalito 1273 days ago [-]
What do you run on it or use it for? Anything to share?
latchkey 1273 days ago [-]
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.
nicoburns 1273 days ago [-]
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.
latchkey 1273 days ago [-]
Firebase is a service that encompasses a bunch of things.
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.
wdb 1272 days ago [-]
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
Ah yeah, I was mostly talking about the database offerings. The cloud functions can scale infinitely.
latchkey 1272 days ago [-]
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.
elitan 1273 days ago [-]
I was thinking about this too.
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.
solarkraft 1272 days ago [-]
You can't host Firebase yourself.
If they decide to kick you out, hike the price or Google buries it you have a gigantic problem.
latchkey 1272 days ago [-]
None of what I have is tied specifically to google/firebase. It would be a day or two of work to move off to slightly different APIs.
elitan 1273 days ago [-]
Hi.
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 1273 days ago [-]
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.
elitan 1273 days ago [-]
Interesting and thanks for the feedback!
- 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!
nicoburns 1273 days ago [-]
> 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.
If you can solve this then you're on to a winner.
elitan 1272 days ago [-]
Interesting. Are cold starts such a good problem? Cold starts with Node (Javascript) seems to be around 200ms.
But the best thing would probably be to have it as an option. Scale down to 0 (cold starts) or 1 (no cold starts).
nicoburns 1271 days ago [-]
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.
ctrlaltdylan 1273 days ago [-]
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.
elitan 1273 days ago [-]
Yea it's a constant trade off between offering a good service with a good and easy pricing.
If you have custom needs I can help you out. Just send me an email: johan@nhost.io.
inian 1273 days ago [-]
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/)?
elitan 1273 days ago [-]
Thanks.
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 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.
chris_st 1273 days ago [-]
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.
elitan 1273 days ago [-]
This is why it's easy to wake up early every morning! Thanks!
We automatically configure and host these open source softwares as part of your Nhost project.
mike_d 1272 days ago [-]
When I decide to migrate off, will you give me all your custom glue to keep my website running?
elitan 1272 days ago [-]
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).
technoplato 1272 days ago [-]
I am curious about this as well
wayneftw 1273 days ago [-]
Are there any docs/issues/comments anywhere with information on how to self-host this?
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...
elitan 1272 days ago [-]
Interesting. When we've talked to our customers they like the predictable pricing (like our 3 pricing tiers).
But I agree with what you say. Having a "pay for what you use" is in a sense more fair, but less predictable.
Scarbutt 1273 days ago [-]
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.
This is not the same at all as live synchronization between devices, also, the Firebase SDK clients allow for offline data persistence.
snorremd 1273 days ago [-]
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.
luminati 1273 days ago [-]
How is auth implemented? Is keycloak or another oss package used or was it custom written?
elitan 1273 days ago [-]
It's our own implementation. We support email/password and different OAuth providers (github, google, facebook etc)
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.
[0] https://www.apollographql.com/docs/react/
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.
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...
https://cloud.google.com/customers/gearlaunch
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/
I don't know much about firebase. How does firebase relate to postgresql?
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.
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.
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:
https://supabase.io/blog/2020/08/05/supabase-auth
https://supabase.io/docs/library/user-management
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).
https://nhost.github.io/hasura-backend-plus/
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.
https://github.com/nhost/hasura-backend-plus
We got lots of customers using Nhost for the backend, and Vercel for the frontend. Great combo!