Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hasura GraphQL Engine and SQL Server

github.com

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Hasura GraphQL Engine and SQL Server

#21

Post by diveanon »

tango12 wrote: post #6
diveanon wrote: post #3

Happy customer on Postgres who just signed a large contract that needs SQL support. Love the product and the team, keep up the great work. Out of curiosity is support for multiple roles in the works?

Yes! We announced experimental support earlier and here's the new spec we're implementing that will support all databases and remote schemas too. 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 "ro…

Role inheritance will really simplify our permissions system, looking forward to seeing that go live.

Those client libraries are interesting. We are using introspection queries and graphql-codegen to generate react hooks and typescript types for our schema and its working really well.

Re: Hasura GraphQL Engine and SQL Server

#22

Post by nerdywordy »

We have layered Hasura over an existing set of SQL Server databases to provide a public facing API for our product. [1]

Overall the experience has been fantastic. The performance and authorization scheme is very good. It has allowed us to wash our hands clean of bespoke endpoint writing for our enterprise customers with complex integration requirements (for the most part... waiting on mutations!).

One thing I wish was handled differently would be Same Schema, Different Database support.

We have multiple multi-tenant databases as well as many single tenant databases. All share the exact same table structure. As it stands, we have to maintain a separate Hasura instance for each of these databases as the table names conflict and there is no way to rename or reference them differently. That leaves us with the minor annoyance of needing to instruct users on their appropriate server prefix (server1.fast-weigh.dev/graphql vs server2.fast-weigh.dev/graphql... etc). Yes, we could proxy in front of these and route accordingly. But that's just one more layer to deal with and maintain.

It sure would be nice to have a single instance to maintain that could handle database availability based on the role of the incoming request.

Even with the minor inconvenience of multiple instances, I 10/10 would recommend. It's a huge timesaver assuming you've got the data access problems it seeks to make easy.

[1]: https://fast-weigh.com / https://docs.fast-weigh.dev

Re: Hasura GraphQL Engine and SQL Server

#26

Post by dahdum »

neural_thing wrote: post #19

I am now building on Hasura. Love the experience overall, but some aspects are frustrating. For example, setting up authentication for a React Native (Expo) app with Auth0 is quite cumbersome, and the docs are a bit out of date.

In your setup, Hasura is verifying a claim inside the JWT returned from Auth0 right? The only Hasura configuration I remember was setting the Auth0 public key and creating roles. I struggled with React/Cognito/AzureAD/Amplify but Hasura wasn't the pain point.

Re: Hasura GraphQL Engine and SQL Server

#28

Post by nirvdrum »

I'm overall very impressed with Hasura, but have found it cumbersome to work with if using UUID primary keys because it won't map them as the GraphQL ID type [0]. There are plenty of people using Hasura successfully in production environments, so I'm curious how others handle it. I'm hoping the answer isn't "just use int PKs", but it'd be helpful to know if it is.

[0] -- https://github.com/hasura/graphql-engine/issues/3578

Re: Hasura GraphQL Engine and SQL Server

#29

Post by simonw »

tpetry wrote: post #24
nerdbaggy wrote: post #23

It’s pretty cool how Hasura uses/abuses Postgres JSON support to be able to run many queries in the same “command”

Can you elaborate on what they are doing?

I can take a guess.

PostgreSQL's JSON tooling makes it much easier to build SQL queries that return different shaped data from different tables in a single query.

The row_to_json() function for example turns an entire PostgreSQL row into a JSON object. Here's a query I built that uses that to return results from two different tables, via some CTEs and a UNION ALL: https://simonwillison.net/dashboard/row-to-json/

    with quotations as (
      select 'quotation' as type, created,
      row_to_json(blog_quotation) as row
      from blog_quotation
    ),
    blogmarks as (
      select 'blogmark' as type, created,
      row_to_json(blog_blogmark) as row
      from blog_blogmark
    ),
    combined as (
      select * from quotations
      union all
      select * from blogmarks
    )
    select * from combined order by created desc limit 100
Even more interesting is what you can do with json_agg - it lets you combine results from other tables. Here's a demo that solves the classic problem of needing to include data from a table at the end of a many-to-many relationship (in this case the tags on entries on my blog): https://simonwillison.net/dashboard/json-agg-demo/

    select
      blog_entry.id, title, slug, created,
      json_agg(json_build_object(blog_tag.id, blog_tag.tag))   
    from
      blog_entry
        join blog_entry_tags on blog_entry.id = blog_entry_tags.entry_id
        join blog_tag on blog_entry_tags.tag_id = blog_tag.id
    group by
      blog_entry.id
    order by
      blog_entry.created desc
    limit 10
(Both these demos use https://django-sql-dashboard.datasette.io/ )
Post reply on HN