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

51–60 of 85 posts

Re: Hasura GraphQL Engine and SQL Server

#51

Post by ddek »

the_arun wrote: post #44
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?

Why not use UUID as primary keys?

Can't speak for all dbs, but many use a clustered index on the primary key. In this case, the physical rows are stored in the order of the index, rather than just pointers to the rows.

If you are inserting non-sequential data into a clustered index, every insert results in a non-trivial rearrangement of the rows. UUIDs are not sequential, so at scale you will experience performance issues if you are using UUID primary keys and the PK index is clustered.

You won't notice this until significant scale, however. You can still use a unique identifier alongside an incrementing primary key, and you could choose to use a more compact format than the UUID. 8 base32 characters have over a trillion combinations, and are nowhere near as unsightly in a URL.

Re: Hasura GraphQL Engine and SQL Server

#52

Post by Topgamer7 »

the_arun wrote: post #44
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?

Why not use UUID as primary keys?

Prevents good data clustering on disc. Probably less of an issue since most DB's are probably run on ssd's now.

Re: Hasura GraphQL Engine and SQL Server

#53

Post by bpicolo »

nerdywordy wrote: post #22

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 wa…

https://hasura.io/blog/announcing-hasura-graphql-engine-2-0/

Multi-tenancy seems like their main 2.0 push

Re: Hasura GraphQL Engine and SQL Server

#54

Post by piaste »

nerdywordy wrote: post #22

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 wa…

> 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.

We have the exact same scenario and solved in with the exact same workaround. As things stand, spinning up the Hasura instance is currently the last piece of the process we need to automate before we are fully able to onboard new clients without manual ops action.

Hasura V2, currently in alpha, is supposed to support multitenancy as its flagship new feature. However, the "same object name in different database" issue is still open and on the roadmap, so presumably it's a _very_ early alpha.

Re: Hasura GraphQL Engine and SQL Server

#55

Post by _3u10 »

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…

In the case that there IS an index page that enumerates all entities you are correct. However, many systems don't provide such an index page.

In many cases it's useful for a page to be publicly accessible yet, not indexable.

This is why sites like YouTube have an "unlisted" level of permission, UUID keys are a convenient way to implement that level of access control.

UUID keys are very useful for distributed systems where a local machine wants to generate a unique key locally, and then later upload it to a centralized store. It's especially helpful in third normal form databases where often you'll need to create objects that reference each other via the primary key.

Re: Hasura GraphQL Engine and SQL Server

#56

Post by piaste »

willeh wrote: post #42

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 metadat…

Hasura doesn't need to be your _only_ API. We use it as a time-saver for basic CRUD queries, but we do have a traditional REST webservice for everything else (in fact, Hasura was added later). Hasura just spares that backend code from being 95% soul-killing CRUD.

Re: Hasura GraphQL Engine and SQL Server

#57

Post by holtalanm »

Topgamer7 wrote: post #52
the_arun wrote: post #44

Earlier quoted context omitted.

Why not use UUID as primary keys?

Prevents good data clustering on disc. Probably less of an issue since most DB's are probably run on ssd's now.

best solution is to use int/long primary keys, with a uuid column that has a unique index. then the uuid can be used with public-facing apis.

Re: Hasura GraphQL Engine and SQL Server

#58

Post by mping »

ddek wrote: post #51
the_arun wrote: post #44

Earlier quoted context omitted.

Why not use UUID as primary keys?

Can't speak for all dbs, but many use a clustered index on the primary key. In this case, the physical rows are stored in the order of the index, rather than just pointers to the rows. If you are inserting non-sequential data into a clustered index, every insert results in a non-trivial rearrangement of the rows. UUIDs are not sequential, so at scale you will experience performance issues if you are using UUID primar…

Can't uuids be time based?

Re: Hasura GraphQL Engine and SQL Server

#59

Post by gip »

We've built and launched our community platform on Hasura + PG RDS. Row-level permission has been a time-saver to launch a product quickly. Stability has been great - our Hasura container hasn't crashed / restarted in the last 9 months.

Their are downsides (it has proven frustrating for us to implement the authentication part for a role that is not user or admin) but I would definitely recommend Hasura to experienced developpers.

Re: Hasura GraphQL Engine and SQL Server

#60

Post by sastraxi »

yevpats wrote: post #4

The space is def interesting and the product probably lowers the barrier to entry for development. My main question will be why would you use it against plain/open-source PostgreSQL RBAC + GraphQL server or something like https://www.graphile.org/postgraphile/ ?

A couple years ago I built toy backends for the same app using both technologies so they could be compared as-directly-as-possible. The code* takes you through the architectural decisions: https://github.com/sastraxi/great-bear-postgraphile and https://github.com/sastraxi/great-bear-hasura

Edit: I forgot that I was trying a "learning repository" pattern where I put longform comments throughout the code. A little more difficult to discover than markdown, as I've learned.

Post reply on HN