7 ms·

Let's say you need to get a field back that is already in the database table, but that wasn't previously returned by the GraphQL endpoint. All you have to do on

Let's say you need to get a field back that is already in the database table, but that wasn't previously returned by the GraphQL endpoint. All you have to do on the front end is ask for it and GraphQL will populate it for you on the server.

BerislavLopac 4y ago
Assuming the backend actually supports mapping of that particular field.
_3u10 4y ago
For external users of the API this can be quite helpful when you’re looking for the password column on the users table. For some reason I don’t think graphql actually works this way. Can’t quite put my finger on why allowing access to any column on a table might be a really bad idea.
- HelloNurse 4y ago
  Putting passwords in a database, and that database behind some kind of service that allows queries, is a stupid mistake that can be implemented with SOAP, CORBA, a remote shell, or any other protocol or API style. I don't think GraphQL makes the problem worse except by encouraging experimentation by putting an unusually powerful query language in the hands of the users
  - jonhohle 4y ago
    Ancestors of your post are suggesting exposing entire DB schemas (I would assume mechanically). While that could also be the case in other protocols, typical an IDL is used to separately define the API layer. Of course it’s completely possible to generate a WSDL, etc. from a DB schema, in practice I’ve never seen it done.
    - HelloNurse 4y ago
      My point is that passwords shouldn't be stored in the "normal" database where some clever architect might expose entire DB schemas to external access. If clever architects manage to expose the carefully segregated database of the small and secure authentication module, they cannot claim it was an accident or someone else's fault,
- charcircuit 4y ago
  >Can’t quite put my finger on why allowing access to any column on a table might be a really bad idea. Privacy
sholladay 4y ago
A world where the front end can access any database field it wants sounds like a security / privacy nightmare to me. Of course there are ways to prevent data from being returned but that’s fragile.
- purerandomness 4y ago
  How does GraphQL help here?
- netik 4y ago
  This isn’t remotely a problem. Field by field granular security is trivial to implement in GraohQL
  - hamandcheese 4y ago
    I have to disagree with you there. It is possible, but it causes other annoying problems. For example, field-level security pretty much means every field could be null at any time. Depending on your graphql server implementation, this might cause an entire request to fail rather than just that field to be omitted, unless you change your schema to where everything is nullable. Checking every field can also easily lead to performance issues, because it’s not uncommon for a large, complex graphql request to have hundreds or thousands of fields (particularly when displaying lists of data to a user).
    - withinboredom 4y ago
      Not to mention GraphQL wasn’t designed with security and user-state in mind. It was an afterthought that was bolted on, varying from framework implementation to implementation.
      - jfengel 4y ago
        How the heck was that not on their minds from day 1? It's the most obvious question to ask about a project like that.
ahepp 4y ago
Why not just query the database directly then?
- eatYourFood 4y ago
dragon-hn 4y ago
If your GraphQL schema is just a mapping of database tables, in my experience you are in for a world of hurt in the future.
- crispyalmond 4y ago
  At my workplace they made this decision before I started and I can fully agree with this. It's essentially a typed REST without any of the benefits. No joins, everything is multiple calls away to perform a "full" query. I don't even want to think about undoing this mess.
- vidarh 4y ago
  It's possible to do this without it getting painful, but you need to annotate the database schema with a lot of meta data. We don't use GraphQL, but we do use an API that is mostly generated from meta data about the schema and permissions on a per field basis, with the ability to override on a per table basis. To the API consumer it's invisible if they're referring to something that refers directly to a real database columns or to a method on a model class that doesn't correspond directly to the database (e.g. the user "password" attribute is Effectively there are two schemas: the API schema and the database schema, it's just that the API schema is "prepopulated" from introspecting the database schema using Sequel (Ruby ORM), with the model classes translating between the two, with a synthesised default mapping. The "API schema" includes more granular type information suitable for the frontend, and permissions, including type information returned to the frontend to provide default client side form rendering and validations (also enforced on the server, of course). It also auto-generates documentation pages with example data, inspired by Airtable's doc pages. But key to avoiding what you describe is that these are all easily overridable defaults, and the permissions default to allowing no columns, so while the db schema introspection makes it quick to expose things where a direct mapping makes sense, it also makes it easy to avoid. Unlike GraphQL we explicitly avoided allowing you to request arbitrary complex sets of data, but what you can do is expose queries by defining model metadata for them that either wraps suitable views or custom queries. We have a UI to allow us to define and store custom queries and views for e.g. reporting needs, so we can prototype new API needs in the browser writing just queries with some metadata annotation. It gets us the flexibility of being able to quickly return exactly the desired data, while retaining control over the queries and complexity.

BerislavLopac 4y ago

Assuming the backend actually supports mapping of that particular field.

_3u10 4y ago

For external users of the API this can be quite helpful when you’re looking for the password column on the users table. For some reason I don’t think graphql actually works this way. Can’t quite put my finger on why allowing access to any column on a table might be a really bad idea.

HelloNurse 4y ago
Putting passwords in a database, and that database behind some kind of service that allows queries, is a stupid mistake that can be implemented with SOAP, CORBA, a remote shell, or any other protocol or API style. I don't think GraphQL makes the problem worse except by encouraging experimentation by putting an unusually powerful query language in the hands of the users
- jonhohle 4y ago
  Ancestors of your post are suggesting exposing entire DB schemas (I would assume mechanically). While that could also be the case in other protocols, typical an IDL is used to separately define the API layer. Of course it’s completely possible to generate a WSDL, etc. from a DB schema, in practice I’ve never seen it done.
  - HelloNurse 4y ago
    My point is that passwords shouldn't be stored in the "normal" database where some clever architect might expose entire DB schemas to external access. If clever architects manage to expose the carefully segregated database of the small and secure authentication module, they cannot claim it was an accident or someone else's fault,
charcircuit 4y ago
>Can’t quite put my finger on why allowing access to any column on a table might be a really bad idea. Privacy

sholladay 4y ago

A world where the front end can access any database field it wants sounds like a security / privacy nightmare to me. Of course there are ways to prevent data from being returned but that’s fragile.

purerandomness 4y ago
How does GraphQL help here?
netik 4y ago
This isn’t remotely a problem. Field by field granular security is trivial to implement in GraohQL
- hamandcheese 4y ago
  I have to disagree with you there. It is possible, but it causes other annoying problems. For example, field-level security pretty much means every field could be null at any time. Depending on your graphql server implementation, this might cause an entire request to fail rather than just that field to be omitted, unless you change your schema to where everything is nullable. Checking every field can also easily lead to performance issues, because it’s not uncommon for a large, complex graphql request to have hundreds or thousands of fields (particularly when displaying lists of data to a user).
  - withinboredom 4y ago
    Not to mention GraphQL wasn’t designed with security and user-state in mind. It was an afterthought that was bolted on, varying from framework implementation to implementation.
    - jfengel 4y ago
      How the heck was that not on their minds from day 1? It's the most obvious question to ask about a project like that.

ahepp 4y ago

Why not just query the database directly then?

eatYourFood 4y ago

dragon-hn 4y ago

If your GraphQL schema is just a mapping of database tables, in my experience you are in for a world of hurt in the future.

crispyalmond 4y ago
At my workplace they made this decision before I started and I can fully agree with this. It's essentially a typed REST without any of the benefits. No joins, everything is multiple calls away to perform a "full" query. I don't even want to think about undoing this mess.
vidarh 4y ago
It's possible to do this without it getting painful, but you need to annotate the database schema with a lot of meta data. We don't use GraphQL, but we do use an API that is mostly generated from meta data about the schema and permissions on a per field basis, with the ability to override on a per table basis. To the API consumer it's invisible if they're referring to something that refers directly to a real database columns or to a method on a model class that doesn't correspond directly to the database (e.g. the user "password" attribute is Effectively there are two schemas: the API schema and the database schema, it's just that the API schema is "prepopulated" from introspecting the database schema using Sequel (Ruby ORM), with the model classes translating between the two, with a synthesised default mapping. The "API schema" includes more granular type information suitable for the frontend, and permissions, including type information returned to the frontend to provide default client side form rendering and validations (also enforced on the server, of course). It also auto-generates documentation pages with example data, inspired by Airtable's doc pages. But key to avoiding what you describe is that these are all easily overridable defaults, and the permissions default to allowing no columns, so while the db schema introspection makes it quick to expose things where a direct mapping makes sense, it also makes it easy to avoid. Unlike GraphQL we explicitly avoided allowing you to request arbitrary complex sets of data, but what you can do is expose queries by defining model metadata for them that either wraps suitable views or custom queries. We have a UI to allow us to define and store custom queries and views for e.g. reporting needs, so we can prototype new API needs in the browser writing just queries with some metadata annotation. It gets us the flexibility of being able to quickly return exactly the desired data, while retaining control over the queries and complexity.