💾 Archived View for dioskouroi.xyz › thread › 24929732 captured on 2020-10-31 at 00:57:54. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
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!
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]
disclaimer: I made RxDB
[1]
https://github.com/pubkey/rxdb
[2]
https://hasura.io/learn/graphql/react-rxdb-offline-first/int...
Can it do 'offline first for couple of months'?
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.
Yes. It can even work fully without any server synchronization. It is just a db in the browser, sync is optional.
Thanks for responding, meant for inside a mobile phone app, but I'll assume it can also be used for that then.
> 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.
> Is there a story for offline support? Is there perhaps a react library that could help here?
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/
Last I checked Apollo had a persistent cache but not true offline support.
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.
Oh! That’s impressive I think last time I used it mutations couldn’t be triggered offline.
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.
If you haven't, you should join the CouchDB slack. People there are quite helpful.
https://couchdb.apache.org/#chat
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...
https://cloud.google.com/customers/gearlaunch
How about hosting your own serverless functions, PostgreSQL storage, and GraphQL server on DigitalOcean?
https://github.com/pragmalang/pragma
I've been working on this for the past 14 months. Would love some feedback.
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.
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/
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.
is building the API for me.
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.
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.
> 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?
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.
What do you run on it or use it for? Anything to share?
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.
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.
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
Firestore is the next generation:
https://cloud.google.com/datastore/docs/firestore-or-datasto...
Ah yeah, I was mostly talking about the database offerings. The cloud functions can scale infinitely.
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 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.
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.
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.
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!
> 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.
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).
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.
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.
I have been bitten by Firebase scalability restrictions before, so good to see alternatives coming up. How do you compare to Supabase (
)?
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 think I've read something about Supabase adding authentication recently or they are working on it (
https://supabase.io/docs/library/authentication/
).
Thanks for the mention - I’m a cofounder of Supabase.
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 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.
This is why it's easy to wake up early every morning! Thanks!
Have I missed something?
How is this Open Source?
Every Nhost project runs on open source software:
- 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.
When I decide to migrate off, will you give me all your custom glue to keep my website running?
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 am curious about this as well
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.
The project is open-source, any feedback is highly appreciated:
https://github.com/anasbarg/pragma
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...
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.
How is auth implemented? Is keycloak or another oss package used or was it custom written?
It's our own implementation. We support email/password and different OAuth providers (github, google, facebook etc)
https://github.com/nhost/hasura-backend-plus
Congrats on shipping! This looks amazing
Thanks! What you’ve done with Vercel has been a great inspiration for us.
We got lots of customers using Nhost for the backend, and Vercel for the frontend. Great combo!
Are there any docs/issues/comments anywhere with information on how to self-host this?
https://github.com/nhost/hasura-backend-plus
https://nhost.github.io/hasura-backend-plus/
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.
https://docs.nhost.io/graphql/subscription
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...
It polls the database every second for every subscription? How does that scale to a lot of subscriptions?
You can read about it in detail here:
https://hasura.io/blog/1-million-active-graphql-subscription...
This is not the same at all as live synchronization between devices, also, the Firebase SDK clients allow for offline data persistence.
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.
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.