Live data from Hacker News

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

graphqlize.org

1–10 of 61 posts

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

#2
I have been planning a graphql adapter for presto, so we can query graphql apis as though they were sql tables.

I guess it is inevitable that somehow some sql database will be exposed via graphql, and someone will use something like presto to make it appear to be an SQL database again...

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

#5
post #3

Interested in comparing with Postgraphile. Besides JVM vs TypeScript.

Looks like early day project. Had this exact project in mind when working with Postgraphile. JVM tooling around databases are amazing. Using clojure on top of that foundation with honey-sql was something I wish existed. Good luck! I might look into helping build it someday.

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

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

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

#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(userId=uuid) {
          name
          salary
      }
  }
Say you add some hacks on top of this to only allow users to query their own employee data, believing this provides adequate security.

The next day, someone creates a Manager object, a relation from employee to Manager, and Manager to employee.

Now, without having consider security for a second, you've granted all employees the ability to query each other:

  query {
      employee(userId=uuid) {
          name
          salary
          manager {
              employees {
                  name
                  salary
              }
          }
      }
  }
To say that these problems occur in the wild frequently is an understatement. Since these graphql frameworks also expose introspection capabilities, discovering these exploits can be automated using crawlers. If you write a bug like this, and you will, people will find it.

Please, please stop encouraging people to directly expose their databases through an API.

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

#9
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(…

The solution to this should be to use the db's security/permissions model.

For example, with postgres: https://stackoverflow.com/questions/49261452/combining-row-l...

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

#10
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(…

I agree that this is indeed a problem, but your proposed cure is unnecessarily onerous. At least with Hasura's equivalent product, allowing queries on related objects is an opt-in process for the admin, after each related object is defined.

I think a better piece of advice is: Please stop allowing people to query relational models automatically, and surface a separate locked-down schema for the GraphQL user.

These GraphQL over DB tools have real value. I've moved from using OpenResty to Hasura in order to surface Postgres APIs, and the time saved has been significant.

Post reply on HN