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

31–40 of 61 posts

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

#31

Post by dismantlethesun »

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.

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

#32

Post by hn_throwaway_99 »

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…

I completely agree. I've posted about this before in discussions about Hasura, but I feel that all these "expose your DB as a GraphQL endpoint" are setting themselves up for a world of hurt down the road.

GraphQL is a fantastic tool to enable an API that maps extremely closely to the front end (check the spec, that is exactly what it was intended to do); instead building it so it exactly matches your DB schema is a huge mistake IMO.

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

#33

Post by hn_throwaway_99 »

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.

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, having those "special case functions" is not a problem because other clients don't need to ask for those fields.

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

#34

Post by tensor »

meritt wrote: 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.

Security is done via row level access control, a system that is vastly better then the ad-hoc systems people reinvent outside the database for every application.

You also absolutely take the time to think through what should and should not be exposed to end users. Either you creates a namespace for your API with views that expose only the necessary data, or with something like Postgraphile you can specify which functionality, columns, and tables are hidden. Personally I prefer the view approach as it decouples your API from the database implementation.

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

#35

Post by tensor »

hn_throwaway_99 wrote: post #32
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…

I completely agree. I've posted about this before in discussions about Hasura, but I feel that all these "expose your DB as a GraphQL endpoint" are setting themselves up for a world of hurt down the road. GraphQL is a fantastic tool to enable an API that maps extremely closely to the front end (check the spec, that is exactly what it was intended to do); instead building it so it exactly matches your DB schema is a h…

Two points, if your DB schema doesn't model your domain correctly you're doing it wrong to start with. And two, views are typically used to decouple the raw database tables from whatever you want to expose to others, be those other developers or in this case external API users.

Modelling databases this way has fallen out of favour for various reasons, but it becomes extremely useful and relevant again with systems like Hasura.

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

#36

Post by sbilstein »

tensor wrote: post #34
meritt wrote: 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.

Security is done via row level access control, a system that is vastly better then the ad-hoc systems people reinvent outside the database for every application. You also absolutely take the time to think through what should and should not be exposed to end users. Either you creates a namespace for your API with views that expose only the necessary data, or with something like Postgraphile you can specify which funct…

RLS is one of the shittiest things about Postgraphile and why I decided against for one project and am doing my best to root it out of a current project.

RLS is difficult to unit test, to configure with flags, not portable to secondary stores, and requires knowledge of arcane database features.

When you put some private data on a cache somewhere and query it, now you need to write your access layer twice since the other one is so tightly coupled to the database.

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

#37

Post by moehm »

tensor wrote: post #35
hn_throwaway_99 wrote: post #32

Earlier quoted context omitted.

I completely agree. I've posted about this before in discussions about Hasura, but I feel that all these "expose your DB as a GraphQL endpoint" are setting themselves up for a world of hurt down the road. GraphQL is a fantastic tool to enable an API that maps extremely closely to the front end (check the spec, that is exactly what it was intended to do); instead building it so it exactly matches your DB schema is a h…

Two points, if your DB schema doesn't model your domain correctly you're doing it wrong to start with. And two, views are typically used to decouple the raw database tables from whatever you want to expose to others, be those other developers or in this case external API users. Modelling databases this way has fallen out of favour for various reasons, but it becomes extremely useful and relevant again with systems li…

What's the problem with views?

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

#38

Post by tensor »

sbilstein wrote: post #36
tensor wrote: post #34

Earlier quoted context omitted.

Security is done via row level access control, a system that is vastly better then the ad-hoc systems people reinvent outside the database for every application. You also absolutely take the time to think through what should and should not be exposed to end users. Either you creates a namespace for your API with views that expose only the necessary data, or with something like Postgraphile you can specify which funct…

RLS is one of the shittiest things about Postgraphile and why I decided against for one project and am doing my best to root it out of a current project. RLS is difficult to unit test, to configure with flags, not portable to secondary stores, and requires knowledge of arcane database features. When you put some private data on a cache somewhere and query it, now you need to write your access layer twice since the ot…

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 that an error in the query won't expose unexpected data, or that a modification to the query that introduces and error exposes unexpected data? Your security now has to be customized to every query like this.

The alternative case is that you only use super simple queries so that you can write resuable security checks. But now I'm going to ask why you are using a relational database in the first place? Because almost certainly you're doing manual joins in this scenario and incurring huge performance hits.

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?

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

#39

Post by tensor »

moehm wrote: post #37
tensor wrote: post #35

Earlier quoted context omitted.

Two points, if your DB schema doesn't model your domain correctly you're doing it wrong to start with. And two, views are typically used to decouple the raw database tables from whatever you want to expose to others, be those other developers or in this case external API users. Modelling databases this way has fallen out of favour for various reasons, but it becomes extremely useful and relevant again with systems li…

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.

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

#40

Post by snuxoll »

tensor wrote: post #38
sbilstein wrote: post #36

Earlier quoted context omitted.

RLS is one of the shittiest things about Postgraphile and why I decided against for one project and am doing my best to root it out of a current project. RLS is difficult to unit test, to configure with flags, not portable to secondary stores, and requires knowledge of arcane database features. When you put some private data on a cache somewhere and query it, now you need to write your access layer twice since the ot…

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 bringing security into the database is good, but it’s also not straightforward to integrate in even assuming you know how to define the necessary database elements.

Post reply on HN