I've used Hasura with GraphQL's client lib generators to generate an Elm client (which is then fully type safe in building queries). I'd consider this "full type safety over the API barrier".
It worked so well (all fully dockered, including the generator, not need to install anything locally), that I decided to publish it as a project of it's own. First time I actually achieved a zero-server-side-code setup that works for me. Enjoy:
I still remembered in 2018, after testing Hasura, when I had to call for an emergency meeting at my local co-working space because I was so blown away about how good Hasura was!
To see the progress by the Hasura team, and the welcoming community they've built around the product is amazing. I'm so grateful to be part of it.
I'm fortunate enough to be able to work with Hasura at my startup (https://nhost.io) where we're trying to make app development more accessible, and Hasura is a central part of our product.
I'm excited for the future of Hasura. Thanks to the whole Hasura-team for the amazing work!
This is great news. Hasura is... the best. A truly empowering piece of software. Along with React, TypeScript, xstate... not sure what I'd do without Hasura. Looking forward to upgrading when I get the chance. Thank you Hasura team!
Yes—I recently added that to my backend code and it's fantastic. Wished I had spent the couple hours and had done it sooner. The vscode plugin for graphql-codegen + TypeScript makes it so you can tweak and change with hardly any fear of breaking anything. My entire stack from Postgres to Hasura to backend to frontend is type safe, and core types flow down from the database.
> Makes it easy to keep the api compatible with the front end
If you use a strong typed lang (I used Elm) you get full type safety in GraphQL query building. Any change you make to your schema that breaks the queries will show up after regenerating the client. Sweet.
HasuraCon our annual user conference is happening today - virtual, free and recorded for posterity ofcourse. :)
There's a tonne of stuff talking about work happening in the Hasura engine, use-cases, best practices and patterns, especially building off the 2.0 release.
Some massive announcements around improvements in data-federation (what in a burst of creativity is called Remote Joins) as well.
I've been using both hasura and postgraphile on my projects recently. The main reason is that I'm so fed up with building crud controllers for simple APIs. Both hasura and postgraphile do the job.
If I were to compare these projects:
Hasura seems like a very well built and maintained project overall. With great documentation and easy to understand deployment process. I haven't hit any bottlenecks yet. I especially like the extensibility features such as webhooks. One major drawback for me is the language it is written in - haskell. Extending, patching, debugging will be hard in the future. I'm not even talking about hiring someone who knows haskell.
Postgraphile on the other hand is build on a more popular stack, but a less polished product in my opinion. Still does the job.
Also, for both hasura and postgraphile, I would like to see these projects support serverless deployments (aws lambda) out of the box. Is this something on your radar?
> Extending, patching, debugging will be hard in the future. I'm not even talking about hiring someone who knows haskell.
If your concerns are not about hiring someone that knows Haskell, what are they about? Sorry if the tone appears combative or accusative, this is a genuine question and I don't know how to put it another way. From my understanding hiring for Haskell is hard but the language itself is often praised. Maybe a lack of libraries?
Docker containers are a valid Serverless option nowadays. There are services like Cloud Run which work very well with them and usually are not hard to set up.
If you are interested by Hasura, don't care about the graphical interface and want more control over permissions, take a look at Postgraphile: https://www.graphile.org/postgraphile/ I've been using it for a year on multiple projects and it's awesome.
Both this and Hasura are build in Haskell. (I rather not expose someone else's service to the internet if that is dyn-typed/javascript and has full access to my database -- hence I like Hasura)
Which is then transpiled back to JS. I dont want to nag about XYZ language, but many of the remote exploits stem from dyn-langs just being way to permissive. Think of "eval(...)" or the capability to write to disk.
I’m using Hasura for the first time for my current startup, and it’s been a game changer for speed so far.
What I’m loving most about it is how is changes the team schedule. Let me explain.
Usually, we’d prototype out what we wanted to build, verify with users, then create the overall data models.
For every single new feature, we’d create API endpoints (REST or GraphQL) and then the front-end.
With Hasura (or Supabase or Firebase for that matter), we skip the API step for _most_ pages. If a page can be built 100% using CRUD operations, it’s a awesome!
If a page can’t be done this way (lots of multi-table transactions, TensorFlow, background processing needed), we hand it off to our Express.js app either through Hasura triggers or federated GraphQL to handle it.
In that case, the amount of work to do is the same as if we weren’t using Hasura.
After 13 years of Ruby on Rails development this has been a major change in how I build apps - but one I’m excited about. I wrote up a post detailing more about why I’m making the switch on my startups blog too if you’re curious: https://hardcover.app/blog/the-perfect-startup-tech-stack
We want Hasura to be a self-serve API for your data, so that the API is entirely managed and as a developer you can focus entirely on your domain's data and logic.
That said, we're not a 100% there for all use-cases and we'll keep evolving.
Because it's possible to incrementally use Hasura along with your own API service, it doesn't have to be a binary decision to use in the stack upfront. (eg: use Hasura just for reads, or just for subscriptions, or just to trigger logic when there's a data change event aka CDC)
Where it works well today:
- You have data / functions in database(s) that you want to bring to your GraphQL API in a secure, performant way
- You're able to bring in custom logic as stateless HTTP handlers that extend your API schema
Where it might not be worth the trade-off today:
- The API you're putting together has so much custom logic for each controller that you'd prefer building the whole thing yourself
In practice, given that one can extend Hasura's API with one's own API quite easily, our users end up saving 50-90% of work they'd have to hand-write. The performance and authz benefit for that chunk is huge because it's out of the box and "managed".
We're continuously working on making this easier and better so we can keep chipping away at that trade-off!
Shameless plug given we have our annual user conference today: I'm doing a session on "How to think in Hasura" and "How to incrementally adopt Hasura in your existing stack" that might be helpful for folks thinking about when to, when not-to, and how-to.
I found it so awkward to configure authorization and to apply custom logic that I went crawling back to Rails to get my current project shipped. For me, the value of a graphql API just isn't enough to move me. Typescript all the way down isn't that big a deal. It's great on the frontend... but the backend wasn't broke. No need to fix.
Not OP, but the fact that the auth config (and table tracking config for that matter) is very UI-orientated is a bit of a pain point for us. Of course it all turns into a metadata json file, but:
1. It's one great big file, which makes it pretty unwieldy to maintain, other than by exporting from a Hasura instance.
2. The format doesn't seem to be very well documented. Making hand-writing changes quite difficult.
Pretty much every other piece of software we use allows us to take a code-first approach. So Hasura is a bit awkward in comparison.
The CLI (esp. the new configv3), splits the metadata into modular YAML files for much easier config/review etc so that makes things easier. There's still more work to do here to make this easier.
Another option, if you're dealing with the metadata JSON directly, is also to write that entire metadata in code and spit out JSON.
@gavinray put together an amazing typescript SDK to write all the metadata in code:
There are plenty of exceptions to this, but as a general rule:
Should: mostly front end app where your need a mostly CRUD style access to a backend with permissions that can be expressed using their DSL and are comfortable with all your back end logic being in lambda functions.
Should not (and this is a stretch for me since I love hasura): a large high amount of idiosyncratic backend logic that you don’t want to but in lambda functions but want more of running app servers. For example, I wouldn’t put something like a Twitter or clubhouse clone on hasura. However, I may run some sub services on hasura.
Many prisma.io users tell us that they use prisma to implement complex business logic and then stitch it all together in hasura which exposes the final graphql API.
So it might even be feasible to use Hasura for more complex applications. I'm curious if there are specific reasons you see this not working well?
> with all your back end logic being in lambda functions.
Although this is recommended for NoOps and Scale, you can technically run all your backend logic on any full fledged servers that can run anywhere. Hasura just requires a HTTP endpoint for custom logic.
If you have an existing (supported) database and your team has decided for the benefits of GraphQL, Hasura is a slam dunk. If you have a non-supported dataset, or abstracting your business logic to cloud scalable services would be cost prohibitive, you might not need Hasura. But the cost testing it out is super low since it doesn't alter your underlying data - unless you use the API to mutate your database, but that's sort of self explanitory there. :D
In my mind, you shouldn't use Hasura when you can get away with Jamstack (ie static pre-compilation of your entire site, no backend at all). In those cases you can use other backends with less cognitive/operational overhead. For example, you could get away with using Airtable as a backend, or something similar.
Hasura, on the other hand, is good for proper apps where you really want fine, control over a user-facing backend. Hasura makes that fine control easier to attain than ever, but you don't always need that.
My sense of Hasura is that it's great for CRUD prototyping, but every usage ends up requiring a more fully fledged backend in the mix anyway?
Hasura can't implement your business logic. If Hasura is my first-stage backend, that means I need to reinvent a lot of the controls it would provide anyway - auth, graphql APIs to integrate into it, etc - for the servers that can do that business logic.
So it doesn't really feel like a choice between Hasura and a custom backend. You can have a custom backend, or both Hasura and also a custom backend. It's an excellent choice for killing off boilerplate CRUD, though.
You can implement a ton of it in stored procedures and check constraints, which I realize some people don't like, but I really like a lot. But yes, there are limits to what you can do with this, and testing PL/pgSQL or whatever language you use for your procedures is prohibitively difficult.
> but every usage ends up requiring a more fully fledged backend in the mix anyway?
So yes, I agree, if you use Hasura, you will end up with a backend as well. This backend will run your auth (if you don't go a third party route) and your Hasura Actions[0][1], which I think is fine.
> So it doesn't really feel like a choice between Hasura and a custom backend. You can have a custom backend, or both Hasura and also a custom backend. It's an excellent choice for killing off boilerplate CRUD, though.
That's my take, too. Hasura totally kills boilerplate CRUD, adds the ability to do rich GraphQL querying, and my favorite feature—declarative role-based authorization/access control—puts the icing on the cake.
Loved that you mentioned PL/pgSQL - consistently impressed by the amount of logic that can be implemented in database using that or plv8 or its cousins. I personally have feels about why that may be a good solution for a lot of small-to-mid-to-large size build outs.
But yeah, in terms of logic we definitely expect you're going to need at least one other service for auth in the stack (for simplicity that service could also be used for any logic-based work as well).
One of the things we pride ourselves on is being non-opinionated about the logic side of the stack and trying to create as many 'escape-hatches' as possible.
Want to use db eventing? - We can event out to an external service.
Setup a custom action? - We can toss those arguments out to an external service and return a response.
Want to do some magic™ using other GraphQL tooling like Prima or Graphene? You can mesh those in with remote schemas.
We really want to build a tool that helps onboard you into the GraphQL ecosystem, but then scales with you as your stack becomes more complicated.
Why would testing stored procedures be "prohibitely difficult"?
Just create a new test database, populate it with test data, call the function with test inputs and assert that the return value and the SQL dump of the resulting state of the database are what you expect.
That's a lot harder than unit testing, for me at least. When you have a small team (or a team consisting of 1 person :)) there are just so many other things you'll end up needing to do before properly verifying functions that "work."
Data transformations are a small subset of business logic. Talking to microservices, third party integrations, and email, for example, are other pieces.
Right, you'd use your API backend and tie them into Hasura with actions if you wanted them tied to Hasura. Of course you can't have your whole app in Hasura, and I don't think they make that claim? Maybe they did before they added actions, but I think they knew that a bit bogus so they added actions and before that had remote schemas.
Even in this context, Hasura could still be a great fit. If you have any form of existing database from the supported set in Hasura, then Hasura can still help by give you an instant read layer to that data. If you need to lock down parts of your data for the static site, or want to add a little bit of interactivity on top of the static site, or even if you just want to bring your own GraphQL layer to a tool like Gatsby - these are all great cases for Hasura still. It gives you super fast API access to existing data.
The Hasura pricing pages list SSO as being a "contact sales for pricing" feature. Does that mean endpoint authentication via JWT and Webhooks is only available to Enterprise customers or does the SSO pricing line item refer to something else other than this type of endpoint authentication?
The self-hosted community version has full access to JWT and webhook validation.
The SSO listed is a feature to integrate with the Hasura Cloud Dashboard for logging in and managing projects. Think Okta => Hasura Cloud => Hasura Project (Instance). We'll definitely take a look at wording it to make it more clear.
https://news.ycombinator.com/item?id=27549164