They were all amazed and many use Hasura in production today in their apps.
For myself, I was so enthusiastic about Hasura and I always had Google Firebase in the back of my mind. Google Firebases DX is really good. I really liked it. But I did not like their tech (noSQ / REST / vendor lock-in).
Nhost is like Google Firebase but with PostgreSQL and Hasura (GraphQL). Right now providing database, API, auth and storage. Here is a short demo: https://www.youtube.com/watch?v=MWB5RXzlJM8
I feel very fortunate to be able to work with such awesome open source software and the success of Hasura makes me so happy, because they are, as mentioned in the comments field before me, a game-changer!
If you love hasura and want something like firebase, please check out the tutorial with hasura + RxDB. It is like having a firebase with better offline-first and more features and of course without vendor lock-in.
What I liked with Firebase was how easy and fast everything was. One-click create a new project and everything was ready to use.
It's this developer experience I want to mimic with Nhost. By providing a managed backend with simple to use js-sdk (https://github.com/nhost/nhost-js-sdk).
i have heard (from multiple founders in the space) that the hosted db business is a difficult one to be in. see for reference graphcool's switch to prisma.
i suspect that mainly applies to venture backed businesses - it could be a great lifestyle biz
I'm sorry that we are not doing a better job marketing Nhost. We have been very focused on the product but we hope to get the word out better in the future. Because you are not alone. There are lots of developers with the same problem, that just want things to work.
Hopefully, we will be mentioned in the documentation for Hasura.
Hasura does provide a hosted version (EDIT: not a hosted version) (Hasura Pro). You can read more about it here: https://hasura.io/hasura-pro
I'm running a full production algorithmic trading platform, and our frontend interactions are handled by Hasura. For me, the appeal was in writing all the business logic as Postgresql triggers, which (provided they're written as true SQL and not plpgsql), scale beautifully with load. Hasura has a real appeal when you're keen to do your important logic in SQL.
I'm considering trying Hasura (or preferably something that can run on SQL Server as that's what we use in production. For me it feels as if trying to do the entire app through Hasura is the wrong approach. But, if we apply CQRS and treat reads different than writes then if we just use it for all of the reads in the system it could eliminate a tonne of code for us. The transactional code can still all go through entity framework and rest APIs.
Early nhost user here! Elitan's platform is a great way to get started quickly with Hasura, and he was also fantastic with helping me out on some then-undocumented components. Always grateful when a developer takes time to do a 1:1 call.
Firebase user here. I love Firebase because it offers so many components that (usually) play well together: Databases, Authentication, Machine Learning, Storage, Crash Reporting, Analytics, Messaging etc.
@elithan this looks awesome man. The one thing keeping me in the firebase ecosystem is the firestore rules (basically quick CRUD permissions). Does nhost provide something similar?
Hasura has this feature, but unfortunately it seems like its part of their "pro/enterprise" offering and not the OS version. https://hasura.io/hasura-pro
I started with Hasura and I implemented it on two business projects. It was a great first step but the lack of customization quickly became an issue. Having the logic split between several services was another big issue (Hasura + firebase auth + serverless functions for any logic). Ultimately it resulted in a slower development speed than what we were doing at my company before using Hasura (custom GraphQL backend development).
Several months ago we switched to Postgraphile, and it solved the issues mentioned above. The plugin system allows us to implement the custom logic in a simple and performant way, whether it's a custom validation on a mutation or tweaking the GraphQL type system. And all the logic is centralized in one project. It's clean, fast and testable.
Another big advantage is that Postgraphile relies on Postgres RLS for permissions, which allows us to manage it using normal SQL migrations. In comparison, we had a lot of pain evolving an existing permission schema on Hasura.
Postgraphile can also automatically expose a Relay compliant schema, supporting Relay connections. It's not possible with Hasura.
Except for pure read-only GraphQL APIs, I strongly recommend looking into Postgraphile over Hasura.
I've been working on GraphQL services since 2015. I worked on the design of the precursor to postgraphile; it was called postgraphql. Hadn't heard of Hasura before today, but it looks interesting.
The primary complaints I hear from others about GraphQL are observability and the learning curve for devs who are new to it. I think these projects add a lot of value with tools like the GraphQL playground (similar to GraphiQL but better), middleware extensibility for observation/analytics, their documentation, and most importantly the starter/boilerplate projects.
IMO, the preferred option today is Prisma. They have a non-production-ready v2 that is available for testing. But even v1 is good for an enterprise product; and they're working on migration/codemod to get onto v2 when it's ready.
But the other big piece of the puzzle is deciding on a GraphQL client. It seems like most choose Apollo + Redux, but Relay is, without a doubt in my mind, the better library/framework for consuming GraphQL in the frontend. Facebook designed React, Relay, and GraphQL to work together really nicely. Relay takes some re-learning to think about frontend data dependencies and caching, but it's really well designed.
I think GraphQL on its own has value as a centralized contract between frontend and backend services, and is a nice query and mutation language; but without Relay I don't think you get the full benefits of all the hard work that goes into the GraphQL service design. And teams/organizations that end up with Apollo/Redux designs suffer from complexities around cache management that Relay does a better job of reducing.
Curious if you were active on the precursor to postgraphile why you feel Prisma is a better option. It's been my experience as well, but would love to hear what the deciding factors were for you.
Curious to know what you think of the React + RPC (e.g. https://github.com/reframejs/wildcard-api) + PostgreSQL stack in comparison to React + Relay + GraphQL + PostgreSQL?
RPC tightly couples frontend and backend. Decoupling is usually only needed for (very) large applications; while getting there you migrate from RPC to GraphQL.
I ultimately chose Postgraphile over Hasura. Mostly because the Postgraphile codebase seemed way hackable, written in TS/JS with a plugin architecture. I've tried some Haskell and that's just a whole nother world I don't have time to learn. So far it's working great for me.
I've always been a huge fan of the Graphile (aka postgraphile) approach. It's just an open-source library, that you can run as a binary when you're just getting started. But when you start getting deep in production territory, it's extensively pluggable and you can gradually swap everything out for your own code, contribute/fork if you need (it's just TS), etc. Full control.
I love the Hasura folks too, and they're a funded startup rather than a one-person operation relying on donations. Open source is hard, and benjie (creator of graphile and many other things, he's incredible) could use some help: https://www.patreon.com/benjie
I made the same evaluation 2 months ago and came to the same decision.
But in my case it was because my existing database is a fairly complicated beast with a lot of updating through stored procedures on views. Hasura wanted to have control of what is happening in the database and there was zero chance that it would agree with the existing triggers about what should happen or how it worked. (Example of an issue, Hasura wants to own the view and view structure so that it can make real time subscriptions work.)
By contrast Postgraphile was happy to be pointed at a schema of views for just what it should see, read a https://www.graphile.org/postgraphile/smart-tags-file/ and believe what it was told there about the underlying database structure, and then expose an API that showed what I wanted it to show without breaking what was under the hood.
FWIW, I went the other way, mostly because I found the GraphQL queries that I wrote in Hasura to be much nicer to read than the equivalents that I got with Postgraphile.
Hasura is a game-changer. I'm never writing CRUD backend apps again by hand.
Combine Hasura (automatic GraphQL on top of PostgreSQL) with React Admin (low code CRUD apps) and you can build an entire back office admin suite or form app (API endpoints and admin front end) in a matter of hours.
These aren't the same things. Hasura is not an admin interface, although it provides something like one. It's an application API.
The django admin interface is not usable by a frontend as an application API.
Django requires you to "meta-model" you have to write Python classes that map to your tables, this is usually duplicate work.
Django's ORM must support many databases, so it produces "least common denominator" SQL and is (stock) oblivious to Postgres' many enhanced data features, you are forced to use various community sourced extensions to get access to features that have been in postgres now for many years.
Django's security system is django only. You are forced to go through django for access control across your business. Eventually this abstraction leaks, and someone starts logging into the db from some other framework and now you have two problems.
This is my opinion and I'm sure I'll get downvoted for it, but Django, Rails, Node, all the Java frameworks, all the meta-modeling and NIH syndroming, are all utterly obsolete. Everything they do can be done in 99% SQL by a data scientist with the help of a competent DBA. "Web application programming" is going to go the way of the dodo bird and devs who don't start learning higher level skills like complex SQL, statistical modeling, linear algebra, and to either be a competent DBA or learn how to treat them fairly with be the first batch of programmers "automated out of a job" by tools like Hasura.
The advantage is React Admin is back end agnostic and you can tap into the huge React ecosystem. And with Hasura you get automatic GraphQL endpoints (Django nor Rails Active Admin do this - you have to create models first vs just a schema with Hasura) which can be used for more than just your admin backend.
Looks cool! I cloned it and ran it locally. I noticed there was no backend running locally, and then saw it points to https://low-code-api.herokuapp.com/v1/graphql. Is the code running there available in a repo too? It would be super nice if you could link to it from the project README.
Part of what I'm doing is working on a CRUD backend.
The thing has a bunch of complex business and authorization rules. Not to mention a bunch of per-client customization. There's also some neat handling around versioning and copy-on-write type behavior to provide a mix of immutability and space saving.
To me, this is CRUD because: most resources literally have 4 endpoints (create, index, update and delete). We write a ton of tests to cover all the cases. It's time consuming, even tedious, and it's boring / simple compared to the user facing stuff we do.
I've never touched GraphQL, so can that really save me months of work? Or would it save me about as much time as Rails would (which would be not a lot) ?
Last time I looked at GraphQL it was only a time-saver if you could rely on significant amounts of automagic for the GraphQL->DB Query step. So if your use case & stack allow for that, yeah, maybe it'll save you significant time.
Its main effect is to move app logic query writing to the frontend, in something that's not SQL, which some folks seem to really like. But it's still got to get turned into whatever your data sources actually speak at some point, just like REST or anything else. If there's nothing magically doing that for you or if the magic turns out to suck, you'll be doing it manually.
[EDIT] to make it more clear, here are your possibilities:
1) a. GraphQL queries -> b. Queries for one or more kinds of datastore
2) a. REST requests -> b. Queries for one or more kinds of datastore
You shift choices about how to query kinda forward in 1, but that means you need a very general and flexible GraphQL query handler to make step 2 happen, and if that doesn't exist or is insufficient you have to write it. That is, obviously, more work than 2, in which 2b is where the choices you'd make in 1a happen, so that layer doesn't need to be as flexible.
TL;DR the apparent flexibility and responsibility-shifting of GraphQL isn't free and is in fact quite expensive (and, if I may, risky)... unless it is free because someone's already done the work, for your particular use case and stack.
GraphQL by itself won't save you time, and might even increase it (it's a huge buy-in). You'd still have to implement the logic for those 4 endpoints, except now in a more complicated system.
In contrast, tools like Hasura and Postgraphile can potentially save you time because they generate the GraphQL part for you. Then you only need to handle the authN/authZ parts – in theory, at least.
If you're up for it, I'd love to chat and see if Hasura could've worked in your case[1]! Especially on the read side, if we're able to model the authz with Hasura your API consumers get a rich read API "for free" and Hasura can delegate the CUD stuff to your existing REST APIs.
Hasura aside, GraphQL will save your API consumers time more than anything else. Like the other comment/reply to this, you still have to build a GraphQL server.
Tangentially related: As a side project, I've been building a backen-as-a-servive platform with a GQL interface derived from the data model and business logic.
I looked at Hasura a while back, and to be honest I thought it was the antithesis of all the things I loved about GraphQL so I moved on. Perhaps someone can convince me differently?
The thing I love most about GraphQL is that serves as the perfect contract layer between the front end and the backend. A very productive development method I've used is to have the front end and back end teams agree on the GraphQL types (often times having the front end folks actually write the types), quickly mock things out, then have the front end folks go implement the front end and the back end folks provide the real resolver implementations.
The things I love about this is that it really simplifies and hides the backend details from the front ends. With things like Hasura, you are directly exposing your DB schemas to the front end, essentially tightly coupling them together. That has always been a recipe for disaster whenever a project gets sufficient scale or complexity in my opinion.
Again, it was a long time ago when I dug into Hasura, but this whole concept of "Directly expose my DB schema as GraphQL" is the exact opposite of what I love about GraphQL in the first place.
Do you really need to decouple frontend and backend in the first place?
Why not separating concerns instead of separating technologies? Tight coupling of UI with database but decoupling of e.g. admin UI/backend from end-user UI/backend.
I'm the author of a Node.js RPC implementation (https://github.com/reframejs/wildcard-api) and the idea is the exact opposite of what you are prescribing: highly coupled frontend business logic with database schema/queries. Makes things so much simpler, in my experience.
After trying Hasura, Prisma, and PostGraphile, my conclusion is that PostGraphile is way ahead of all this. Please all have a look at PostGraphile, it is amazing, even more than Hasura!
That was my conclusion looking at them both last year. Hasura had an amazing first-time UX, but postgraphile felt like it was built with production concerns in mind (testing, integrating with larger codebases, easy to add custom or wrap generated CRUD resolvers in js/ts). The most off-putting thing to me, at the time, was that Hasura's solution for auth was to spin up a separate auth service. I prefer a flexible monolith for anything with less than 10 devs working on it. Looks like postgraphile has started paying attention to the first-time UX, but still not as friendly as Hasura's: https://github.com/graphile/starter
Both feel kind of limited by forcing you to encode a ton of logic in SQL which must be migrated vs a mongoid model you can just tweak and commit, but I guess I'm old school and what's old is new again.
While I like and enjoy many aspects of code generation such as this or Prisma, In real world scenario it just doesn’t feel right.
Imagine a very simple scenario, you want to add some validation based on business requirements, in order to do that you have to have a server with custom endpoints or a custom graphql server (thus copy most of what hasura generates) to implement your own validation
The only situation in which I consider this a really good solution is in a CQRS system where the database attached to hasura is read only via graphql and the data is inserted by other services making it a typesafe single source of truth to read from
Writes (mutations) are delegated to a REST endpoint, the GraphQL mutation response can be synchronously (blocking mutation) or asynchronously consumed (mutation + subscription).
Often times that’s not needed if you actually use the full power of PG. CHECK constraints go a long way, and where they don‘t go, PG/PSQL goes pretty much a long way.
For internal or prototypical use cases, that can be totally sufficient, however you‘re right that you‘ll eventually want good error messages, observability and much more other custom logic.
What I‘m still searching for is something that works like Hasura or PostgREST and then offers „upgrades“, first via configuration, later via custom code hooks.
That would be pretty awesome from a migration path perspective.
Check out Postgraphile, it allows you to start off with introspection, then customise it with comments, then add custom bits in node.
Both Hasura and Postgraphile also support schema stitching from what I know, so you should be able to extend it that way also (more complicated obviously)
Related, How does one receive a webhook in Hasura? Say I need to take some action on a Stripe rest webhook. All the docs show sending events somewhere, how about receiving and transforming data from 3rd parties?
A huge benefit that tools like Hasura, Postgraphile and PostgREST provide is using the native in-database row level security model.
Consider Django. Your django app logs into the database typically as a user with elevated permission that is a superset of all permissions required by your users. Postgres has no idea that django is acting on behalf of many users, all it sees is this django super-like user. If an attacker roots your Django instance, they have the same privileges. If your PHB decides to "help" and log in with creds found in the source code, the damage could be catastrophic.
Products like Hasura, Postgraphile and PostgREST switch databse roles on the fly per-request. The user that these tools logs in as typically has almost no privileges. You must be the bearer of a valid JWT token to elevate privileges, and then you only get to the level of the user you stole the token from. There is NO super-like user.
> A huge benefit that tools like Hasura, Postgraphile and PostgREST provide is using the native in-database row level security model.
I agree with your overall comment. Note that Hasura doesn't use the native row level security in Postgres. They implement the layer themselves. There are two reasons:
1) Hasura is older than the first release of Postgres that included the row level security feature.
2) Their implementation scales better when there are a lot of users subscribed to the same GQL Subscription. When using row level security, every user's query result looks different, so they need to create a database subscription / polling for each user GQL Subscription. Their implementation allows them to have a single PG subscription (well they mostly do polling), get all the data back, then strip down on the way out to the GQL subscribers.
the Graphene implementation for Django brings up a Relay GraphQL server so fast. The best part is that at compile time it ensures your GraphQL schema confirms to the Relay standard, enforcing correct naming. You really don't have to think about much.
Totally agree. I recently greenfielded a new project and hasura, postgraphile and Postgrest were all tools I trialed. Hasura has the best “get up and go” but ultimately postgrest was simpler and more intuitive—graphql is cool, but for one person/small team projects it feels like complexity overkill. The added abstraction over rest is just unnecessary with postgrest’s resource embedding. I liked having an admin interface that hasura provided, but really, dbeaver is often just as usable.
It's also really nice, I think the appeal of Hasura is to leverage all the GraphQL clients. Things like Apollo save a lot of time in React and iOS for example since they abstract the whole service layer. I'm not sure if something similar exists for PostgREST.
Readit News
After going through multiple different stacks such as MeteorJS, Firebase, building my own REST/GraphQL API etc. Nothing really felt right.
That was until I found out about Hasura.
I actually had to assemble a quick meetup at the co-working space I was on (true story) to show everybody this software. Hasura Tweet: https://twitter.com/HasuraHQ/status/1068145251267895300?s=20
They were all amazed and many use Hasura in production today in their apps.
For myself, I was so enthusiastic about Hasura and I always had Google Firebase in the back of my mind. Google Firebases DX is really good. I really liked it. But I did not like their tech (noSQ / REST / vendor lock-in).
So, I decided to start https://nhost.io.
Nhost is like Google Firebase but with PostgreSQL and Hasura (GraphQL). Right now providing database, API, auth and storage. Here is a short demo: https://www.youtube.com/watch?v=MWB5RXzlJM8
I feel very fortunate to be able to work with such awesome open source software and the success of Hasura makes me so happy, because they are, as mentioned in the comments field before me, a game-changer!
https://hasura.io/blog/building-an-offline-first-web-app-wit...
It's this developer experience I want to mimic with Nhost. By providing a managed backend with simple to use js-sdk (https://github.com/nhost/nhost-js-sdk).
Do you know why Hasura don't provide a managed service themselves?
Also, I wonder if Hasura will eventually move to a MongoDB-like license.
i suspect that mainly applies to venture backed businesses - it could be a great lifestyle biz
Hopefully, we will be mentioned in the documentation for Hasura.
Hasura does provide a hosted version (EDIT: not a hosted version) (Hasura Pro). You can read more about it here: https://hasura.io/hasura-pro
How do we add business logic ?
Folks @hasura, where do we learn about haskell ? any helpful pointers much appreciated.
1. Actions - https://hasura.io/docs/1.0/graphql/manual/actions/index.html
2. https://3factor.app/
3. Remote schemas - https://hasura.io/docs/1.0/graphql/manual/remote-schemas/ind...
Check out the result here: http://www.hedgecheap.com
Awkwardly. Good luck
Thanks again!
Which parts of Firebase is Nhost replacing?
Next on the road map: Cloud Functions, Hosting, Crash Reporting.
We try to go from the core and outwards. Hope it makes sense.
Together with Nhost's auth system and Hasura, it's easier than Firebase.
Deleted Comment
https://www.graphile.org/postgraphile/
https://hasura.io/
https://www.prisma.io/
There are plenty of "REST API in a box" solutions as well:
https://github.com/PostgREST/postgrest
https://github.com/prest/prest
https://resthapi.com/
Several months ago we switched to Postgraphile, and it solved the issues mentioned above. The plugin system allows us to implement the custom logic in a simple and performant way, whether it's a custom validation on a mutation or tweaking the GraphQL type system. And all the logic is centralized in one project. It's clean, fast and testable.
Another big advantage is that Postgraphile relies on Postgres RLS for permissions, which allows us to manage it using normal SQL migrations. In comparison, we had a lot of pain evolving an existing permission schema on Hasura.
Postgraphile can also automatically expose a Relay compliant schema, supporting Relay connections. It's not possible with Hasura.
Except for pure read-only GraphQL APIs, I strongly recommend looking into Postgraphile over Hasura.
The primary complaints I hear from others about GraphQL are observability and the learning curve for devs who are new to it. I think these projects add a lot of value with tools like the GraphQL playground (similar to GraphiQL but better), middleware extensibility for observation/analytics, their documentation, and most importantly the starter/boilerplate projects.
IMO, the preferred option today is Prisma. They have a non-production-ready v2 that is available for testing. But even v1 is good for an enterprise product; and they're working on migration/codemod to get onto v2 when it's ready.
But the other big piece of the puzzle is deciding on a GraphQL client. It seems like most choose Apollo + Redux, but Relay is, without a doubt in my mind, the better library/framework for consuming GraphQL in the frontend. Facebook designed React, Relay, and GraphQL to work together really nicely. Relay takes some re-learning to think about frontend data dependencies and caching, but it's really well designed.
I think GraphQL on its own has value as a centralized contract between frontend and backend services, and is a nice query and mutation language; but without Relay I don't think you get the full benefits of all the hard work that goes into the GraphQL service design. And teams/organizations that end up with Apollo/Redux designs suffer from complexities around cache management that Relay does a better job of reducing.
RPC tightly couples frontend and backend. Decoupling is usually only needed for (very) large applications; while getting there you migrate from RPC to GraphQL.
I love the Hasura folks too, and they're a funded startup rather than a one-person operation relying on donations. Open source is hard, and benjie (creator of graphile and many other things, he's incredible) could use some help: https://www.patreon.com/benjie
But in my case it was because my existing database is a fairly complicated beast with a lot of updating through stored procedures on views. Hasura wanted to have control of what is happening in the database and there was zero chance that it would agree with the existing triggers about what should happen or how it worked. (Example of an issue, Hasura wants to own the view and view structure so that it can make real time subscriptions work.)
By contrast Postgraphile was happy to be pointed at a schema of views for just what it should see, read a https://www.graphile.org/postgraphile/smart-tags-file/ and believe what it was told there about the underlying database structure, and then expose an API that showed what I wanted it to show without breaking what was under the hood.
(shameless plug)
https://www.apollographql.com/
Combine Hasura (automatic GraphQL on top of PostgreSQL) with React Admin (low code CRUD apps) and you can build an entire back office admin suite or form app (API endpoints and admin front end) in a matter of hours.
This adaptor connects react-admin with Hasura: https://github.com/Steams/ra-data-hasura-graphql
Here's a reference application I put together: https://github.com/cpursley/react-admin-low-code
The django admin interface is not usable by a frontend as an application API.
Django requires you to "meta-model" you have to write Python classes that map to your tables, this is usually duplicate work.
Django's ORM must support many databases, so it produces "least common denominator" SQL and is (stock) oblivious to Postgres' many enhanced data features, you are forced to use various community sourced extensions to get access to features that have been in postgres now for many years.
Django's security system is django only. You are forced to go through django for access control across your business. Eventually this abstraction leaks, and someone starts logging into the db from some other framework and now you have two problems.
This is my opinion and I'm sure I'll get downvoted for it, but Django, Rails, Node, all the Java frameworks, all the meta-modeling and NIH syndroming, are all utterly obsolete. Everything they do can be done in 99% SQL by a data scientist with the help of a competent DBA. "Web application programming" is going to go the way of the dodo bird and devs who don't start learning higher level skills like complex SQL, statistical modeling, linear algebra, and to either be a competent DBA or learn how to treat them fairly with be the first batch of programmers "automated out of a job" by tools like Hasura.
The advantage is React Admin is back end agnostic and you can tap into the huge React ecosystem. And with Hasura you get automatic GraphQL endpoints (Django nor Rails Active Admin do this - you have to create models first vs just a schema with Hasura) which can be used for more than just your admin backend.
Deleted Comment
I love Django, but even its amazing ORM has limitations. I can't imagine what it's like to deal with something similar but on the frontend instead...
The thing has a bunch of complex business and authorization rules. Not to mention a bunch of per-client customization. There's also some neat handling around versioning and copy-on-write type behavior to provide a mix of immutability and space saving.
To me, this is CRUD because: most resources literally have 4 endpoints (create, index, update and delete). We write a ton of tests to cover all the cases. It's time consuming, even tedious, and it's boring / simple compared to the user facing stuff we do.
I've never touched GraphQL, so can that really save me months of work? Or would it save me about as much time as Rails would (which would be not a lot) ?
Its main effect is to move app logic query writing to the frontend, in something that's not SQL, which some folks seem to really like. But it's still got to get turned into whatever your data sources actually speak at some point, just like REST or anything else. If there's nothing magically doing that for you or if the magic turns out to suck, you'll be doing it manually.
[EDIT] to make it more clear, here are your possibilities:
1) a. GraphQL queries -> b. Queries for one or more kinds of datastore
2) a. REST requests -> b. Queries for one or more kinds of datastore
You shift choices about how to query kinda forward in 1, but that means you need a very general and flexible GraphQL query handler to make step 2 happen, and if that doesn't exist or is insufficient you have to write it. That is, obviously, more work than 2, in which 2b is where the choices you'd make in 1a happen, so that layer doesn't need to be as flexible.
TL;DR the apparent flexibility and responsibility-shifting of GraphQL isn't free and is in fact quite expensive (and, if I may, risky)... unless it is free because someone's already done the work, for your particular use case and stack.
In contrast, tools like Hasura and Postgraphile can potentially save you time because they generate the GraphQL part for you. Then you only need to handle the authN/authZ parts – in theory, at least.
Hasura aside, GraphQL will save your API consumers time more than anything else. Like the other comment/reply to this, you still have to build a GraphQL server.
[1] I'm twitter.com/tanmaigo or tanmaig@hasura.io
Posting here as it may be of interest to readers: l https://massiveinference.com
Dead Comment
The thing I love most about GraphQL is that serves as the perfect contract layer between the front end and the backend. A very productive development method I've used is to have the front end and back end teams agree on the GraphQL types (often times having the front end folks actually write the types), quickly mock things out, then have the front end folks go implement the front end and the back end folks provide the real resolver implementations.
The things I love about this is that it really simplifies and hides the backend details from the front ends. With things like Hasura, you are directly exposing your DB schemas to the front end, essentially tightly coupling them together. That has always been a recipe for disaster whenever a project gets sufficient scale or complexity in my opinion.
Again, it was a long time ago when I dug into Hasura, but this whole concept of "Directly expose my DB schema as GraphQL" is the exact opposite of what I love about GraphQL in the first place.
Why not separating concerns instead of separating technologies? Tight coupling of UI with database but decoupling of e.g. admin UI/backend from end-user UI/backend.
I'm the author of a Node.js RPC implementation (https://github.com/reframejs/wildcard-api) and the idea is the exact opposite of what you are prescribing: highly coupled frontend business logic with database schema/queries. Makes things so much simpler, in my experience.
Both feel kind of limited by forcing you to encode a ton of logic in SQL which must be migrated vs a mongoid model you can just tweak and commit, but I guess I'm old school and what's old is new again.
- it is made in typescript and can be integrated as a library directly in a JS project
- it is very easy to extend with plugins
- it is very easy to customize and run on an existing database
- it is « database first » in the sense that the schema is created based on the DB schema and some additional annotations
- it is really free open source software with a non-VC backed business model
- it is extremely performant
Imagine a very simple scenario, you want to add some validation based on business requirements, in order to do that you have to have a server with custom endpoints or a custom graphql server (thus copy most of what hasura generates) to implement your own validation
The only situation in which I consider this a really good solution is in a CQRS system where the database attached to hasura is read only via graphql and the data is inserted by other services making it a typesafe single source of truth to read from
Writes (mutations) are delegated to a REST endpoint, the GraphQL mutation response can be synchronously (blocking mutation) or asynchronously consumed (mutation + subscription).
Will give it a try, thanks
For internal or prototypical use cases, that can be totally sufficient, however you‘re right that you‘ll eventually want good error messages, observability and much more other custom logic.
What I‘m still searching for is something that works like Hasura or PostgREST and then offers „upgrades“, first via configuration, later via custom code hooks.
That would be pretty awesome from a migration path perspective.
Both Hasura and Postgraphile also support schema stitching from what I know, so you should be able to extend it that way also (more complicated obviously)
Deleted Comment
Here's an example for a regex for validating email from one of our community calls: https://youtu.be/-9jX21PKyk0?list=PLTRTpHrUcSB8Dp3hk5SiVNHNP...
Consider Django. Your django app logs into the database typically as a user with elevated permission that is a superset of all permissions required by your users. Postgres has no idea that django is acting on behalf of many users, all it sees is this django super-like user. If an attacker roots your Django instance, they have the same privileges. If your PHB decides to "help" and log in with creds found in the source code, the damage could be catastrophic.
Products like Hasura, Postgraphile and PostgREST switch databse roles on the fly per-request. The user that these tools logs in as typically has almost no privileges. You must be the bearer of a valid JWT token to elevate privileges, and then you only get to the level of the user you stole the token from. There is NO super-like user.
I agree with your overall comment. Note that Hasura doesn't use the native row level security in Postgres. They implement the layer themselves. There are two reasons: 1) Hasura is older than the first release of Postgres that included the row level security feature. 2) Their implementation scales better when there are a lot of users subscribed to the same GQL Subscription. When using row level security, every user's query result looks different, so they need to create a database subscription / polling for each user GQL Subscription. Their implementation allows them to have a single PG subscription (well they mostly do polling), get all the data back, then strip down on the way out to the GQL subscribers.
the Graphene implementation for Django brings up a Relay GraphQL server so fast. The best part is that at compile time it ensures your GraphQL schema confirms to the Relay standard, enforcing correct naming. You really don't have to think about much.
[1]http://postgrest.org/
The scope is smaller than GraphQL, but some of the interesting benefits - like smarter and more optimized requests - are available with PostgREST.