4 ms·

this is conceptually very cool, and graphql can be great, but hooking graphql straight up to a persistent datastore as a means of exposing things to external/fr

this is conceptually very cool, and graphql can be great, but hooking graphql straight up to a persistent datastore as a means of exposing things to external/front-end clients is an absolutely terrible idea and nothing is going to change my mind.

datalopers 4y ago
Data Exfiltration As A Service
- eurasiantiger 4y ago
  I thought that was an Azure trademark… But really, with proper authentication in place and preferably built-in to a GraphQL-enabled datastore, a GraphQL server can more secure than your average self-implemented HTTP API. The latter can easily leak through e.g. haphazard app-level joins. Meanwhile, the GraphQL server can secure things at object level, much like if people actually integrated their frontend authentication all the way to their (No)SQL server.
- jdc0589 4y ago
  thats honestly not my biggest issue with it, but its also a problem (a solvable one though)
theogravity 4y ago
When I run PostGraphile, I have it behind another backend because of this concern. It does spare you from having to write SQL, but instead you have to write the GQL documents. It also spares me from having to come up with pagination SQL as PostGraphile handles that in pagination cases, along with text searches. PostGraphile also lets you selectively expose which tables / fields should be available to a GQL client, but if PostGraphile itself can be attacked, then yes, an FE client could get to the underlying DB.
- spoiler 4y ago
  What does this "middle end" do? Does it proxy to PostGraphile, or does it do something with the query beforehand? Or does it not proxy it at all?
  - theogravity 4y ago
    Can be a mix of both or a straight proxy to what the client is allowed to access. For example, if you need to perform multiple operations on the same resource in a single call, the middle tier would do those multi-operations instead of the FE client. You're pretty much having the middle tier act as the business logic layer as the FE client(s) doesn't have to worry about calling a sequence of operations to do a task, and instead just have to call a single operation on the middle tier instead.
    - spoiler 4y ago
      Ah alright. So you do complex input (example) transformation as part of the business logic in the middle tier, and then forward it to the db? Does that mean you parse the query in the middle end too, or just parts of it (I'm not that knowledgeable about gql, so sorry if the question makes no sense)? We are soon going to be evaluating a similar idea at work, so I'm just curious how it works. If it's lengthy you don't have to go into too much detail if it's a bother to explain!
      - ramesh31 4y ago
        It's called a "BFF" (Backend For Frontend) https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf?gi=cfe66890e78c https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-i... It's a really nice pattern particularly for multi-client applications consuming the same resources. Instead of trying to make a single REST api work for desktop, mobile, and web, you can have a BFF for each which all share the same GQL definitions and data access patterns, but can have platform specific routing/handling/auth logic.
      - theogravity 4y ago
        The middle tier does not have to be a GQL server; it can be REST or some other protocol like gRPC. The middle tier has a GQL client that calls the PostGraphile backend. Yes to your question overall. As another reply states, it's exactly a backend for a frontend.
spoiler 4y ago
I understand that sentiment, since I was similar before, but I've come to realise that it's little different from from slapping an ActiveRecord-style ORM and framework on top of it. The difference is where you encode access rules. With frameworks they're in code, with graphql adapters, they're declaratively managed (idk if this project does it, only talking conceptually, but Hasura does it). This is kinda better when you think about it because it's easier to simulate/validated the ACL. And on top of that, it's possible to build no-code interfaces on top of it to manage those rules by anyone in an organisation. Add hooks and you can add complex business along side these access rules, without encumbering the business logic with ACLs. I realise this is a bit idealistic, but I don't think it's an unachievable goal with the current tech we have out there. With all that said... Even though I sound like a proponent of this now, I'd still be a bit nervous and on the fence about having this in production.
andrew_ 4y ago
I dislike working with closed-minded folks for reasons such as this. Where's the danger in exposing GraphQL to a read-only replica containing non-sensitive data?
- gsvclass 4y ago
  GraphQL takes security pretty seriously the way we think of GraphQL as a DSL for bulding APIs. The queries you issue in DEV are saved to an allow list and only those queries are compiled in production. Any other queries (or changes to existing queries) from the client is ignore. So you can use it to expose your primary DB. It's really no different that you writing code to build an HTTP endpoint, except of-course here you only write GraphQL
gsvclass 4y ago
GraphJin DOES NOT hook GraphQL straight to a DB. It is a backend service which in DEV mode saves queries to an allow list and in production on queries from this list are allowed to be run. GraphQL does not mean clients are allowed to change the query willy nilly in production that would be a nightmare. Also in production the query is compiled into a db prepared statement the first time and then on queries after validation go directly to the prepared statement. This is no different than a hand written HTTP endpoint + ORM. Addition if using the standalone service is not for you then you can use GraphJin as sort of an ORM within your own http handlers. The question around why use it is complex. Some reasons even nested queries and mutations are compiled to a single SQL query. Knowledge of indexes is used to write a fast query. Support for things like joining again Postgres Array columns, JSON columns, fast cursor pagination, Graph queries using recursive CTEs, full-text search and a lot more out of the box and will work on Postgres, Mysql, Cockroach, Yugabyte and I'm working on more.
- jdc0589 4y ago
  > GraphJin DOES NOT hook GraphQL straight to a DB. It is a backend service which in DEV mode saves queries to an allow list and in production on queries from this list are allowed to be run. GraphQL does not mean clients are allowed to change the query willy nilly in production that would be a nightmare. Thats "straight to a db" by my definition. But I agree that saved/allowlisted queries are a key problem that needs to be solved in any prod environment, regardless of tooling you are using. I'm not saying there isn't a use case for it, but I think there is a better solution 100% of the time. I am clearly not the target audience for this though, so my opinion is kind of irrelevant. In my world graphql is a tool for aggregating microservices in to a supergraph, when you are at a point that a monolithic DB (or a couple of them) with data from lots of different domains no longer exists. In that sort of environment, which is an extremely common use case for gql, doing this to expose your domain data in a graph breaks microservice isolation patterns and directly ties your domain contracts to internal datamodels; both of which are almost always bad long-term. If the problem you are trying to solve is "spend less time building http endpoints for CRUD apps", then something like graphjin is a win, but I'd argue it not a pattern you'll want to use forever. If you are using graphql to aggregate cross domain services in a large engineering organization, this is a bad idea.

datalopers 4y ago

Data Exfiltration As A Service

eurasiantiger 4y ago
I thought that was an Azure trademark… But really, with proper authentication in place and preferably built-in to a GraphQL-enabled datastore, a GraphQL server can more secure than your average self-implemented HTTP API. The latter can easily leak through e.g. haphazard app-level joins. Meanwhile, the GraphQL server can secure things at object level, much like if people actually integrated their frontend authentication all the way to their (No)SQL server.
jdc0589 4y ago
thats honestly not my biggest issue with it, but its also a problem (a solvable one though)

theogravity 4y ago

When I run PostGraphile, I have it behind another backend because of this concern. It does spare you from having to write SQL, but instead you have to write the GQL documents. It also spares me from having to come up with pagination SQL as PostGraphile handles that in pagination cases, along with text searches. PostGraphile also lets you selectively expose which tables / fields should be available to a GQL client, but if PostGraphile itself can be attacked, then yes, an FE client could get to the underlying DB.

spoiler 4y ago
What does this "middle end" do? Does it proxy to PostGraphile, or does it do something with the query beforehand? Or does it not proxy it at all?
- theogravity 4y ago
  Can be a mix of both or a straight proxy to what the client is allowed to access. For example, if you need to perform multiple operations on the same resource in a single call, the middle tier would do those multi-operations instead of the FE client. You're pretty much having the middle tier act as the business logic layer as the FE client(s) doesn't have to worry about calling a sequence of operations to do a task, and instead just have to call a single operation on the middle tier instead.
  - spoiler 4y ago
    Ah alright. So you do complex input (example) transformation as part of the business logic in the middle tier, and then forward it to the db? Does that mean you parse the query in the middle end too, or just parts of it (I'm not that knowledgeable about gql, so sorry if the question makes no sense)? We are soon going to be evaluating a similar idea at work, so I'm just curious how it works. If it's lengthy you don't have to go into too much detail if it's a bother to explain!
    - ramesh31 4y ago
      It's called a "BFF" (Backend For Frontend) https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf?gi=cfe66890e78c https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-i... It's a really nice pattern particularly for multi-client applications consuming the same resources. Instead of trying to make a single REST api work for desktop, mobile, and web, you can have a BFF for each which all share the same GQL definitions and data access patterns, but can have platform specific routing/handling/auth logic.
    - theogravity 4y ago
      The middle tier does not have to be a GQL server; it can be REST or some other protocol like gRPC. The middle tier has a GQL client that calls the PostGraphile backend. Yes to your question overall. As another reply states, it's exactly a backend for a frontend.

spoiler 4y ago

I understand that sentiment, since I was similar before, but I've come to realise that it's little different from from slapping an ActiveRecord-style ORM and framework on top of it. The difference is where you encode access rules. With frameworks they're in code, with graphql adapters, they're declaratively managed (idk if this project does it, only talking conceptually, but Hasura does it). This is kinda better when you think about it because it's easier to simulate/validated the ACL. And on top of that, it's possible to build no-code interfaces on top of it to manage those rules by anyone in an organisation. Add hooks and you can add complex business along side these access rules, without encumbering the business logic with ACLs. I realise this is a bit idealistic, but I don't think it's an unachievable goal with the current tech we have out there. With all that said... Even though I sound like a proponent of this now, I'd still be a bit nervous and on the fence about having this in production.

andrew_ 4y ago

I dislike working with closed-minded folks for reasons such as this. Where's the danger in exposing GraphQL to a read-only replica containing non-sensitive data?

gsvclass 4y ago
GraphQL takes security pretty seriously the way we think of GraphQL as a DSL for bulding APIs. The queries you issue in DEV are saved to an allow list and only those queries are compiled in production. Any other queries (or changes to existing queries) from the client is ignore. So you can use it to expose your primary DB. It's really no different that you writing code to build an HTTP endpoint, except of-course here you only write GraphQL

gsvclass 4y ago

GraphJin DOES NOT hook GraphQL straight to a DB. It is a backend service which in DEV mode saves queries to an allow list and in production on queries from this list are allowed to be run. GraphQL does not mean clients are allowed to change the query willy nilly in production that would be a nightmare. Also in production the query is compiled into a db prepared statement the first time and then on queries after validation go directly to the prepared statement. This is no different than a hand written HTTP endpoint + ORM. Addition if using the standalone service is not for you then you can use GraphJin as sort of an ORM within your own http handlers. The question around why use it is complex. Some reasons even nested queries and mutations are compiled to a single SQL query. Knowledge of indexes is used to write a fast query. Support for things like joining again Postgres Array columns, JSON columns, fast cursor pagination, Graph queries using recursive CTEs, full-text search and a lot more out of the box and will work on Postgres, Mysql, Cockroach, Yugabyte and I'm working on more.

jdc0589 4y ago
> GraphJin DOES NOT hook GraphQL straight to a DB. It is a backend service which in DEV mode saves queries to an allow list and in production on queries from this list are allowed to be run. GraphQL does not mean clients are allowed to change the query willy nilly in production that would be a nightmare. Thats "straight to a db" by my definition. But I agree that saved/allowlisted queries are a key problem that needs to be solved in any prod environment, regardless of tooling you are using. I'm not saying there isn't a use case for it, but I think there is a better solution 100% of the time. I am clearly not the target audience for this though, so my opinion is kind of irrelevant. In my world graphql is a tool for aggregating microservices in to a supergraph, when you are at a point that a monolithic DB (or a couple of them) with data from lots of different domains no longer exists. In that sort of environment, which is an extremely common use case for gql, doing this to expose your domain data in a graph breaks microservice isolation patterns and directly ties your domain contracts to internal datamodels; both of which are almost always bad long-term. If the problem you are trying to solve is "spend less time building http endpoints for CRUD apps", then something like graphjin is a win, but I'd argue it not a pattern you'll want to use forever. If you are using graphql to aggregate cross domain services in a large engineering organization, this is a bad idea.