This is very impressive. Congratulations!<p>What I'm not seeing is how do you envision enforcement of complex business rules when using this API. Examples (silly, but you get the idea):<p>- The price is only visible for projects of type "whatever".<p>- The price may only be updated when it is not closed (closed_date is null)<p>- The project is only visible on mondays<p>The other point I don't see is how do you expect to trigger side-actions when changes are made. For instance:<p>- Send an e-mail when a project is created<p>- Call a webhook when a post is modified<p>Finally, and this may be from my lack of expertise with GraphQL, how do you deal with recursive data structures? For instance, how would you store and fetch a tree of categories?
Hi HN! Super happy to announce the first open-source release of the Hasura GraphQL engine.<p>This is a standalone service that gives you GraphQL on Postgres. It comes with fine-grained access control that can integrate with any auth provider. It can also work with any existing postgres database as is, and allows you to expose select tables/views across your postgres schemas over GraphQL.<p>Looking forward to your feedback!
Nice work. There are several competitors in the automagic Postgres REST/GraphQL space, and you're nailing documentation and ergonomics here. Your site and the Hansura Console sets your project apart from the rest.
GraphQL is interesting although it doesn’t appear to be answer to designing better APIs (poor modularaization, monitoring, and tooling come to mind). “Mutations” look to be an afterthought, and schema/ui are not impressive either.<p>Above plus companies tripping hard to monetize tooling around something that you get completely for free with REST...<p>Even as UI engineer I don’t get the appeal of it - state, caching and all the “performance” tuning make it too complicated.
First glance reaction: Awesome, just the thing I need.<p>Then I saw the fine print: AGPL. Haskell.<p>The thing might be awesome, but the combination of the legal risk from AGPL (very little legal precedent for AGPL, especially outside the US, so the real legal implications of the license are very murky) and maintenance risk from Haskell (finding good Haskell developers is hard, and the learning curve is brutal), makes it a lot harder to choose.
I have a bit of a dumb question: where does GraphQL fit in a stack? I've seen in used primarily as a means of aggregating a bunch of disparate microservices, but then I see things like this that put it in the role of app server, almost. What advantages does this give over, for example, a Rails API (also on Postgres)? If it is supposed to fill the role of app server, how do you handle things more involved than simple CRUD operations? Like, if I sign up a user, how -- in a GraphQL world -- would I send a welcome email, typically?
I am very hesitant to couple the business logic of any application to the transport layer (GraphQL) or the persistence layer (Postgres) for that matter.
Impressive! How's it different from postgraphql (<a href="https://postgraphql.github.io/" rel="nofollow">https://postgraphql.github.io/</a>) or postgraphile (<a href="https://www.graphile.org/postgraphile/" rel="nofollow">https://www.graphile.org/postgraphile/</a>)?
As a newbie to GraphQL who is having some growing pains adopting a UI for a data warehouse that was basically bolted onto a REST API designed for backend queries, can someone help me understand what the pros and cons are for something like this vs hand rolling all of the backend GraphQL stuff yourself? We have been evaluating switching/offering a GraphQL backend for our UI to consume for our product since it seems well suited to our use case but so far the effort required has outweighed the gain we would get from it. Because of this a somewhat turnkey solution like above might be more appealing.
We at Sale Stock (fashion e-commerce in Indonesia) built an in-house system similar to this but more automatic and works with CockroachDB. Not open source yet, but might be interesting to you guys: <a href="https://speakerdeck.com/salestock/laskar-high-velocity-graphql-and-lambda-based-software-development-model" rel="nofollow">https://speakerdeck.com/salestock/laskar-high-velocity-graph...</a> (skip to around mid-way, first half is intro to GraphQL)
Great job!!! Looks awesome<p>I see that one of the ways you want to monetize this is by offering support. Providing support is a good approach to monetize an open source project but it’s not very scalable. Have you thought of any other ways you can monetize this?<p>If others in the HN community can pitch in with any ideas they have on how to monetize an open source project that would be great as well.
Really cool! Congrats.<p>It would be awesome if it could be made compatible with Postgraphile (<a href="https://www.graphile.org/postgraphile/introduction/" rel="nofollow">https://www.graphile.org/postgraphile/introduction/</a>)
I work with a Django app on Postgres, and I'm not sure how I would migrate that to GraphQL. How things play out in terms of django specific tables? What about relationships between tables? We mostly use the Django app to expose REST APIs, which deal with making complex queries using QuerySets to Postgres. Moving this to GraphQL mean that all the business logic that sits on the REST APIs need to be moved to the frontend?
Thank you for releasing this. I am impressed with Hasura! No knock on postgraphile, I am trying that out too as well as prisma, but this looks very well done and the boundaries are clear (like postgraphile, views are important to make things work). Your UI is going to make people happy.<p>I have two questions: 1. can I point the hasura cli at my local install? and 2. Can we have UUID fields? I'd like to use them as primary keys.
This is a good trend. Will we see more work aimed at separating the data model and human interface (to make programming with attributed graphs safe and convenient) from back end issues (how to store data and process queries efficiently, where traditional databases are already very advanced.)