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

41–50 of 85 posts

Re: Hasura GraphQL Engine and SQL Server

#41

Post by tehlike »

simonw wrote: post #29
tpetry wrote: post #24

Earlier quoted context omitted.

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…

this. JSON Agg fixes the cartesian product problem.

Imagine having a table with large rows, and another table to join with small data but many rows.

Normally you'd do a inner join of some sort, and the data from "large rows" would be duplicated many many times - json_agg simply fixes this.

you can actually do the full table without json_build_object, too you can do something like

select json_agg(t.) from ( select from table ) as t

this makes joining multiple tables together very very easy, and performant.

Re: Hasura GraphQL Engine and SQL Server

#42

Post by willeh »

I've used Hasura for a couple of projects but I feel somehow and sooner rather than later, a requirement shows up that you an't really solve with Hasura. I don't mean oh this is a bit awkward in Hasura but rather this needs to be fully custom code exposing its own graphql (which Hasura would do an excellent job of stitching together). That being said some of the operational challenges with Hasura specifically metadata and migrations are better solved using other solutions.

Prisma when combined with Apollo on the other hand makes it easy to build GQL handler, which can handle strange requirements but also makes it easy to avoid Hasura induced awkwardness.

The Hasura team seems very component however and I hope they will work out these issues.

Re: Hasura GraphQL Engine and SQL Server

#43

Post by steelbrain »

nirvdrum wrote: post #28

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/issue…

I don't have an answer for you but you do have my curiosity. Why did you choose UUIDs as primary keys?

Re: Hasura GraphQL Engine and SQL Server

#44

Post by the_arun »

steelbrain wrote: post #43
nirvdrum wrote: post #28

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/issue…

I don't have an answer for you but you do have my curiosity. Why did you choose UUIDs as primary keys?

Why not use UUID as primary keys?

Re: Hasura GraphQL Engine and SQL Server

#45

Post by zomglings »

steelbrain wrote: post #43
nirvdrum wrote: post #28

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/issue…

I don't have an answer for you but you do have my curiosity. Why did you choose UUIDs as primary keys?

With integer keys as an alternative?

UUID v4 keys don't give away information about the number of rows in a relation. You can directly use them in api responses.

In recent events, iirc, parler was so easy to scrape precisely because they were using int keys exposed in their api get endpoints.

Re: Hasura GraphQL Engine and SQL Server

#46

Post by JMTQp8lwXL »

zomglings wrote: post #45
steelbrain wrote: post #43

Earlier quoted context omitted.

I don't have an answer for you but you do have my curiosity. Why did you choose UUIDs as primary keys?

With integer keys as an alternative? UUID v4 keys don't give away information about the number of rows in a relation. You can directly use them in api responses. In recent events, iirc, parler was so easy to scrape precisely because they were using int keys exposed in their api get endpoints.

You could start with a large, non-zero value for the initial key, to obfuscate the true number of records in the collection.

Re: Hasura GraphQL Engine and SQL Server

#47

Post by Dystopian »

endisneigh wrote: post #16
tango12 wrote: post #15

Earlier quoted context omitted.

Query-plan caching is built-in and here's a docs link for response caching: https://hasura.io/docs/latest/graphql/cloud/response-caching...

Is caching not available if you don’t pay?it seems that hasura cloud is a paid offering. It also doesn’t seem like it works with the self hosted offering. Any plans for that?

Caching isn't discouraged or disabled in any way in the community edition of Hasura.

In terms of query-plan caching - which provides a lot of benefits for speeding up pre-query execution - that's already enabled by default as part of the Hasura engine.

Response caching is a little more complicated and requires a separate service outside of the main GraphQL server to keep the solution generalized (ex. redis, memcached, lots of other options).

We're definitely looking at ways to have some more examples as to how someone could go about rolling their own caching solution for self-hosted instances.

In the case of hosted solutions to caching, there's Hasura Cloud which pairs the cache with monitoring and some other usability and security niceties - but you could also use a service like GraphCDN (there are a couple other as well) in front of your Hasura instance which helps setup response caching.

Re: Hasura GraphQL Engine and SQL Server

#48

Post by zomglings »

JMTQp8lwXL wrote: post #46
zomglings wrote: post #45

Earlier quoted context omitted.

With integer keys as an alternative? UUID v4 keys don't give away information about the number of rows in a relation. You can directly use them in api responses. In recent events, iirc, parler was so easy to scrape precisely because they were using int keys exposed in their api get endpoints.

You could start with a large, non-zero value for the initial key, to obfuscate the true number of records in the collection.

The difference between IDs of multiple resources would still leak count information.

It also makes it too easy to paginate through relations for certain use cases where you may want obfuscation.

Re: Hasura GraphQL Engine and SQL Server

#49

Post by steelbrain »

zomglings wrote: post #45
steelbrain wrote: post #43

Earlier quoted context omitted.

I don't have an answer for you but you do have my curiosity. Why did you choose UUIDs as primary keys?

With integer keys as an alternative? UUID v4 keys don't give away information about the number of rows in a relation. You can directly use them in api responses. In recent events, iirc, parler was so easy to scrape precisely because they were using int keys exposed in their api get endpoints.

Security through obscurity is only sweeping the problem under the rug instead of addressing it IMPO. I don't know what Parler is or was, but I don't think sequential int IDs would be the major factor that would lead to a website being scraped.

There are generally two types of information in applications, "public" and "privileged". The former has the IDs and such discoverable by an index or explore page, the latter requires authentication and has user-specific permissions.

For both cases, if hiding IDs is the only access control on the backend, it's fundamentally flawed. For both cases, if the access control is implemented well (in addition to rate limiting), integer vs UUIDs don't make a difference.

What do you think?

Re: Hasura GraphQL Engine and SQL Server

#50

Post by kevan »

steelbrain wrote: post #49
zomglings wrote: post #45

Earlier quoted context omitted.

With integer keys as an alternative? UUID v4 keys don't give away information about the number of rows in a relation. You can directly use them in api responses. In recent events, iirc, parler was so easy to scrape precisely because they were using int keys exposed in their api get endpoints.

Security through obscurity is only sweeping the problem under the rug instead of addressing it IMPO. I don't know what Parler is or was, but I don't think sequential int IDs would be the major factor that would lead to a website being scraped. There are generally two types of information in applications, "public" and "privileged". The former has the IDs and such discoverable by an index or explore page, the latter re…

No one will argue that opaque identifiers is a sufficient security control but it's (slightly) better than nothing, at least it would've stopped a naive enumeration approach to scrape everything. Don't get distracted by that part, the main reason is many companies wouldn't want to publicly post a dashboard of how many users/entities/widgets they have for all to see but exposing sequential identifiers basically does that.
Post reply on HN