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

GraphQLize: JVM library to build GraphQL API instantly from PostgreSQL and MySQL

graphqlize.org

Post reply on HN
Print view View original

41–50 of 61 posts

Re: GraphQLize: JVM library to build GraphQL API instantly from PostgreSQL and MySQL

#41

Post by miles-po »

snuxoll wrote: post #40
tensor wrote: post #38

Earlier quoted context omitted.

We'll have to agree to disagree. Writing a manual security layer that doesn't understand your data model is one of the worst things you can do. Multiple databases? Now you're also manually doing integrity and probably manually doing joins. That's a ton of extra things to go wrong. As an example, consider a query that is fairly complex. How exactly are you going to make resuable security tests for it? How do you know…

> If you are using a relational database to its full extent, there is nothing as secure as built in row level security. You wouldn't dream of doing integrity checks outside the database, why do security? This isn’t exactly PostgreSQL’s fault, but mapping application users to database roles is not as easy in pretty much any framework I’ve worked compared to implementing basic post-retrieval filters. I absolutely think…

If you're trying to map app users to DB users for more than 1,000 users, you're doing it wrong. Roles at that scale tend to be more vague: admin, hr, analysis, etc. Users (and tags) go in a table. Then row-level security authorizes through the user table for individual queries.

Row-level security is absolutely not dependent upon DB roles. Table-level security on the other hand is sufficiently coarse-grained that mapping GRANT/REVOKE to applied roles should be feasible.

If you're punting all of this security to the app layer, that's your prerogative, but don't pretend that it's somehow more straightforward or secure. If it seems simpler at the app layer, you may very well be missing something.

Re: GraphQLize: JVM library to build GraphQL API instantly from PostgreSQL and MySQL

#42

Post by dismantlethesun »

hn_throwaway_99 wrote: post #33
dismantlethesun wrote: post #31

Earlier quoted context omitted.

If you really do that, people tend to accuse you of doing RPC and not building a "true" API, because you're creating a lot of special case functions for the remote caller's business case.

That is exactly what GraphQL is designed to do. Taken straight from the spec: > Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that. The whole point of GraphQL is that since each client asks for exactly the fields they want, h…

I was speaking of higher-level abstractions than that. For instance, do you have your API allow all possible arbitrary aggregations for your data or do you only special case the 3 or 4 that are pertinent to your business model?

Doing the former leads to basically reimplementing SQL in GraphQL. Doing the latter leads to functions like `resolve_month_over_month_profit_and_loss_segemented_by_sector`.

Re: GraphQLize: JVM library to build GraphQL API instantly from PostgreSQL and MySQL

#43

Post by miles-po »

tensor wrote: post #39
moehm wrote: post #37

Earlier quoted context omitted.

What's the problem with views?

You can't insert/update/delete data in views in all cases, and they can make debugging performance more challenging, but otherwise nothing. I think they are underused. I rarely see people using views at all, let alone using them as a test aid (composing big queries from smaller more easily tested views), or using them to define interfaces to an internal data model.

For the most part, you can insert/update/delete.

See: INSTEAD OF triggers.

That is unless you're using MySQL/MariaDB, in which case views are the least of your worries.

Re: GraphQLize: JVM library to build GraphQL API instantly from PostgreSQL and MySQL

#44

Post by adamredwoods »

siquick wrote: post #19

Been playing around with GraphQL in the last day or so and just can't see any reason to use it over REST (or REST + an ORM). Am I missing something? Is it just so people don't have to learn SQL?

I've been using it lately, too, and think of it as a database to connect databases and return json. Yet another layer in the ever-growing stack.

Re: GraphQLize: JVM library to build GraphQL API instantly from PostgreSQL and MySQL

#45

Post by miles-po »

paulryanrogers wrote: post #12
holtalanm wrote: post #11

Earlier quoted context omitted.

i was thinking this, too. http://postgrest.org/en/v6.0/ comes to mind. Its security is based on postgres user permissions.

Separate DB user per application user makes connection pooling difficult. And PostgreSQL has more costly connections

Row-level security is not at all dependent upon DB users/roles. Storing app user data in a table for lookup is sufficient. Storing the user info in a session config value as provided by JWT can be even better.

Basic database table replication will suffice for the former. No replication required for the latter.

Re: GraphQLize: JVM library to build GraphQL API instantly from PostgreSQL and MySQL

#46

Post by miles-po »

mooted1 wrote: post #7

For the love of god, this is never how GraphQL was intended to be used. The official graphql website is very clear: https://graphql.org/learn/authorization/ > Delegate authorization logic to the business logic layer If you take security or performance debugging seriously, you should never expose database models through APIs directly in a production app. To illustrate, say you have an Employee model: query { employee(…

Let's be clear: many folks today are directly exposing their databases through REST. The API protocol really doesn't matter. CRUD has no affinity for any one technology or methodology.

GraphQL is no more vulnerable to crawlers than any REST server with OpenAPI on it. And yes, introspection can be disabled.

It's not like tools like Hasura, Prisma, or Postgraphile have no security baked into their products, often via a cryptographically signed JWT.

Query cost analysis. Query depth limits. Query pattern allow lists.

And that's all assuming the GraphQL server has a public IP, which is far from a certainty (just like REST).

Re: GraphQLize: JVM library to build GraphQL API instantly from PostgreSQL and MySQL

#47

Post by dehrmann »

dismantlethesun wrote: post #31
brunoc wrote: post #26

I feel that by using these types of tools you could really miss out on a fantastic opportunity to create a schema that models the business domain as accurately and elegantly as you want to make it, regardless of the underlying service topology or the databases behind it. That's what I find the most attractive about GraphQL. Large companies and companies that have grown fast often have all kinds of APIs made at differ…

If you really do that, people tend to accuse you of doing RPC and not building a "true" API, because you're creating a lot of special case functions for the remote caller's business case.

If you want a snappy UI, you have to do this. All those extra round trips and extra data start to add up.

Re: GraphQLize: JVM library to build GraphQL API instantly from PostgreSQL and MySQL

#49

Post by [deleted] »

miles-po wrote: post #41
snuxoll wrote: post #40

Earlier quoted context omitted.

> If you are using a relational database to its full extent, there is nothing as secure as built in row level security. You wouldn't dream of doing integrity checks outside the database, why do security? This isn’t exactly PostgreSQL’s fault, but mapping application users to database roles is not as easy in pretty much any framework I’ve worked compared to implementing basic post-retrieval filters. I absolutely think…

If you're trying to map app users to DB users for more than 1,000 users, you're doing it wrong. Roles at that scale tend to be more vague: admin, hr, analysis, etc. Users (and tags) go in a table. Then row-level security authorizes through the user table for individual queries. Row-level security is absolutely not dependent upon DB roles. Table-level security on the other hand is sufficiently coarse-grained that mapp…

[deleted]
Post reply on HN