839 karma · joined February 14, 2015
Shared context is the second job nobody wants
he/him
tanmaig [at] promptql [dot] io
With Hasura, if you need want some server-side logic to be written away as an API, you could try 2 approaches:
1. Write a REST/GraphQL API in your favourite framework and bring them in as Actions/Remote-Schemas in Hasura. Hasura will add them to the GraphQL API. 2. If you like, and if its possible, you can also abstract away logic in database functions and then Hasura will expose them.
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:
https://github.com/hasura/graphql-engine/tree/master/contrib...
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.
Link here for those interested: https://hasura.io/events/hasura-con-2021/talks/architect-gui...
What were some of the authz pieces you struggled with?
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.
Link to talk here: https://hasura.io/events/hasura-con-2021/talks/architect-gui...
Sorry, I know it took a while, but we had to make sure we could make the upgrade path non-breaking given it was a massive release and this took longer than we expected!
Please do feel free to reach out if you need any help with the upgrade :)
Could you point us to the docs you were looking at for the auth0 integration?
https://hasura.io/docs/latest/graphql/cloud/response-caching...
Could you open a github issue with a rough proposal of how you'd like to specify this information?
For example: at a subscription level (with a directive or header), or via metadata built-on query collections [1] (what Hasura uses underneath for managing allow-lists).
[1]: https://hasura.io/docs/latest/graphql/core/api-reference/sch...
This becomes super useful for folks building new applications or new features against existing SQL Server systems (which is a rather large ecosystem beyond just the database, since so many products use SQL Server underneath too!)
Postgres was the first database we added support for!
https://hasura.io/docs/2.0/graphql/core/databases/postgres/i...
https://github.com/hasura/graphql-engine/issues/6991
General support for inherited roles is one of the things I'm most excited about because it makes a bunch of hard things around reusing and composition so easy.
This improvement plays really well along with things like "role-based schemas" so that GraphQL clients have access to just the exact GraphQL schema they should be able to access - which is in turn composed by putting multiple scopes together into one role.
Also interesting is how well this could play with other innovations on the GraphQL client ecosystem like gqless[1] and graphql-zeus[2] because now there's a typesafe and secure SDK for really smooth developer experience on the client side.
[1]: https://github.com/gqless/gqless [2]: https://github.com/graphql-editor/graphql-zeus
Has anyone tried that? Would love any notes/pointers!
Join data across the two to get the best of both basically. Hasura doesn't support Neo4j natively yet, but maybe using Neo4j's graphql wrapper as an input to Hasura perhaps?
Recently, we’ve been super excited about exploring the idea of GraphQL as almost an intermediate step in the API lifecycle. This helps bring certain benefits of GraphQL to other domains - esp non internally owned frontend app scenarios.
Most important thing is to be guided by real users though as we explore these ideas though, and REST to GraphQL interop was something people really wanted!
Here’s the spec: https://github.com/hasura/graphql-engine/blob/master/rfcs/re...
Has anyone on a "platinum"/"enterprise" google workspace plan received any relevant communication about what's happening and ETA on uptime?
Would love to hear what's been missing / painful and factor that into the roadmap.
Our docs page is just about live with the latest links so that you can try it out. I'll drop a note here when that happens.
Linking to the right time: https://youtu.be/djKPtyXhaNE?t=1128
TL;DR:
- GraphQL is a descriptive type system not prescriptive. This means that "String" maps to JSON String maps to Javascript utf8 string, but what type that maps to for C++ is not quite clear. Because there are many different ways to represent a string. So which one do we use? As opposed to protobuf client codegen which is prescriptive and unambiguous in what you get.
- Encoding custom scalars can cause some confusion because it's not clear what the spec of the custom scalar is. Although, there's been some recent work to make that a little better.[1]
- Impedance mismatch with nullability and union types because support is not uniform across languages
That looks like a really good start. Do you think it'll end up looking like JOOQ? Would be interesting to see how you get things like aggregations and perhaps even things like: `SELECT 1, 'hello'` to work. That would be the ultimate test!
Happy to help with any Hasura integrations whenever you're ready too! Let's chat again soon. :)
I see that Kretes uses Sqorn [1] for talking to the database.
I really like the looks of Sqorn, however iiuc, it doesn't support typescript right?
How does that piece work?
While Hasura + GraphQL can be used as an ORM (especially for serverless functions!), Hasura is designed to be used directly by clients as well.
Hasura has a metadata configuration system that works on top of an existing database that allows configuring mapping, relationships and most importantly permissions that make the GraphQL feasible to be used by even frontend apps. [1]
Further, Hasura has remote joins that can "join" across Postgres, GraphQL, REST sources and secure them. [2]
[1] https://hasura.io/blog/hasura-authorization-system-through-e...
[2]: https://hasura.io/blog/remote-joins-a-graphql-api-to-join-da...
For us, the risky choice in our stack [1] was Haskell. It's been amazing and has paid off immensely, but the challenges are very real. Over time we've wanted to go whole in on things like ReasonML too, but we haven't pulled the trigger or made safer choices, because that one golden ticket has been used up.
(I can't take credit for coming up with this, but I don't know who did! I'm sure it's already better articulated somewhere.)
It was a definitely a design goal for us to make the existing production database use-cases as seamless as possible.
Instead of adding a new DSL on top of the database, Hasura maps much of the DML subset of SQL over to GraphQL (tables, views, functions) so that we're not re-inventing that bit and the translation is restricted to the "relation set" to "tree" transformation. json aggregation and json operations in Postgres are phenomenal! Hasura's authz RLS-like layer injects authorization in as well to make that GraphQL API actually useful.
JOOQ has probably done the most phenomenal job in mapping almost all database constructs to a native language library, but there's a solid amount of type magic there which I'm not sure is portable to every language.
Quick heads up: The link on graphql schema generation and stitching seems to be broken. It points to a localhost URL.
The benefits for api consumers and frontend developers are quite clear. Easier ergonomics to explore the API and ability to collocate data fetching alongside UI components to automatically have a graphql api client optimise the data fetching required to load a screen/page itself itself.
The benefits of building a graphql api/service do seem harder to evaluate.
Even though authorization systems or database policies exist outside the "data" database, quite often that information is used during the data fetch right? Let's say the user has certain properties and then those properties of the user and attributes of the data are used to define a constraint which is usually applied as the data fetch query is made.
For example, our goal at Hasura is to allow developers to bring values from external systems as well in their rules, so that the authorization rule doesn't exclusively depend on values coming in from the same database. This is what makes Hasura useful on existing systems (alongside your existing complex codebase), especially when you're looking for extremely high read performance or subscriptions for example. I do want to emphasize that Hasura is far more valuable (in a business sense) for our users on existing systems that for new systems!
I'd love to hear examples from your experience about the ratio of authz where it could be declarative vs where it was necessarily imperative in code. The "values" in the constraint specification can come from anywhwere, the viewer entity, another database, but the constraint is declarative.
What's it been like at GraphLQ API for github? Specifically, do you have a sense for how complex the authorization for the data models is beyond "declarative" properties of the data and the viewer itself?