Live data from Hacker News

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

graphqlize.org

21–30 of 61 posts

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

#21
post #6

I understand this stuff is "cool" but this is only one step removed from db->query(input[sql]). I'm not talking about SQL injection either, I'm talking about wholesale data exfiltration of your entire database because you've auto-generated some slick GraphQL API and you don't take the time to think through what should, and should not, be exposed to end users or bother to implement any form of access control.

Seems like a good usecase for row-level permissions

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

#22
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 used it once upon a time to essentially allow joins across 3 separate databases that had all been developed/grown independently. Once you have certain kinds of resolvers between types, all sorts of neat stuff is possible. Ultimately, once we had time to update the applications, we merged the databases and dropped the GraphQL app entirely.

EDIT: It was awesome, and I kind of miss it, but it was too much to maintain within our constraints.

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

#23
post #6

I understand this stuff is "cool" but this is only one step removed from db->query(input[sql]). I'm not talking about SQL injection either, I'm talking about wholesale data exfiltration of your entire database because you've auto-generated some slick GraphQL API and you don't take the time to think through what should, and should not, be exposed to end users or bother to implement any form of access control.

It's yet another attempt to step back to two-tier. (It's the usual thesis-antithesis cycle. First, we had that, then we figured out it doesn't work so we turned towards three-tier then we saw that was pretty tedious so we started to look at two-tier again. But this time in a disguise.)

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

#24
post #6

I understand this stuff is "cool" but this is only one step removed from db->query(input[sql]). I'm not talking about SQL injection either, I'm talking about wholesale data exfiltration of your entire database because you've auto-generated some slick GraphQL API and you don't take the time to think through what should, and should not, be exposed to end users or bother to implement any form of access control.

Agreed. Incredibly bad idea and there are a few others like it that are very popular. Yikes.

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

#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 different time by different people with different standards. GraphQL lets you paper over that without breaking existing, revenue making code.

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

#27

Earlier quoted context omitted.

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

Pgbouncer

Does that help with fragmentation though? If the connecting user must be the same then it doesn't add much, except lower connection latency.

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

#29
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?

Client-side shaping of queried data without directly writing SQL against a back-end database, and without having to pre-arrange queried data structure with the back-end.

Wouldn't SPARQL be a better choice for this? It's an actual Web standard, unlike GraphQL so a better fit to general-purpose clients with no "pre-arranged queried structure".
Post reply on HN