I don’t like working with ORMs for tons of joins and I don’t like denormalizing in tables, so I tend to write CTE-based JSON generating views for apps. (Yes, these are not high traffic apps...)<p>Hasura has been such a joy to work with against these dbs that I am willing to try and let the query abstraction do more of the output assembly with joins, etc via graphql.<p>No knock on the Prisma family of tools, and props also to subzerocloud and postgraphile/postgraphql, but I feel like hasura’s relationship with pg is more natural than anybody else’s. [edit: more compatible with the way I approach pg - YMMV and don’t hesitate to try the others they are solid too.]
This is a nice micro-tutorial, but it does <i>not</i> build you a production ready system. You don't seem to get backups, redundancy, automated updates, replicability, or anything else that most people would view as mandatory. It seems just show how to rapidly setup a one-off pet server?
GraphQL is really nice for the client. But I have an hard time believing that this flexibility given to the client (over well defined REST endpoints for example) doesn't <i>hardly</i> impact the complexity of the queries to make to the database!<p>How it is possible for a product like Prisma/Hasura to be able to generate the complex logic of the queries required to handle real world logic <i>and</i> support that extra client flexibility? In my experience even regular SQL ORMs are often a bottleneck in a REST application and you need to fallback to (or only use) plain SQL.<p>And even if you can fallback to hand written SQL in those GraphQL backends (I hope so!), the extra complexity of the queries to make is still there because of GraphQL.
Interesting that GraphQL popped up on the front page today. Spent a good portion yesterday digging through docs and tutorials about getting it setup in place of REST for my new project. Do the client side benefits REALLY outweigh the added complexity on the server side, particularly for light/minimal API calls? REST is certainly easier to whip up on the server side, and it's not like it adds a ton of overhead on the client side.
So at this point it seems we are going back to how software was developed before web. Clients interact directly with database through a query language. In this case GraphQL is an equivalent of SQL and "custom GraphQL resolvers" are an equivalent of stored procedures, triggers and other business logic.<p>I wonder if we will see databases expose GraphQL access layers directly.
How would you compare this to Prisma's free tier? I've been working through a tutorial series that uses that and it's pretty nice in dev. I've not skipped ahead to the deployment story for that though.
I am trying to understand the infra around using something like Hasura (or graphQL in general).
If I wanted to make a site like HN, do I just use a hosted DB with hasura on top? Do I need to have HaProxy/NGinx for the reverse proxy between the client and Hasura?<p>What about caching of the results? All 100 viewers to my popular post will see the same page content and comments.
Can I serve this from a cache insetad of the db, if I am using graphQL?<p>How will horizontal scaling work? replication? etc. I know Hasura may not be directly involved in these but I would appreciate any thoughts on these all the same.