4 ms·

It's probably not super popular to suggest that REST isn't the be-all and end-all when it comes to web APIs, but I'm interested in a future that lets us integra

by brandur 10y ago

It's probably not super popular to suggest that REST isn't the be-all and end-all when it comes to web APIs, but I'm interested in a future that lets us integrate with APIs more quickly and more safely. I'm interested to hear about what people think about the subject. (I'm the author.)

daurnimator 10y ago
I'm a big fan of postgrest (https://github.com/begriffs/postgrest/ https://github.com/begriffs/postgrest/). It creates a RESTful HTTP API out of your existing postgres schema. It practically eliminates the need to write a CRUD backend.
- ruslan_talpa 10y ago
  Usually when you say CRUD people tend to think "limited functionality" and PostgREST is a bit more then "basic CRUD" as i am sure you know. It's interface is powerful enough to support GraphQL on top (since this is the topic of this thread :) https://subzero.cloud/ https://subzero.cloud/ )
- brandur 10y ago
  Yes, PostgREST is awesome :) It turns out that most of what is usually expressed in implementation code assuming that you're hitting a dumb backend is just as well-served by SQL functions and schemas. This probably breaks down for larger projects, but it certainly has its place, and I can imagine something very similar be done for GraphQL.
  - ruslan_talpa 10y ago
    I don't think it breaks down (as long as most of the data comes form the database). For example i know exactly how paymoapp.com (similar to basecamp) is structured , i consider it to be a fairly large system and i know for a fact that PostgREST can support that. As for the "very similar be done for GraphQL", there is https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql which was based on postgrest ideas. Another approach would be to build graphql on top of postgrest (my comment below)
irq-1 10y ago
Thinking about the problems with client-side SQL seems informative[0]: * Security; allowing evaluation rather than a describing results. * DDL; Data Structure and Types need to be learned out-of-band. Ideally we want a sort-of interactive INFORMATION_SCHEMA over http, so our tools can inform us about types/structure and we always have updated info as we write queries. * Performance; Stored Procedures (server-side) protect against a client making poor joins; ORMs requesting too much data, etc... * Info about Security: client side SQL doesn't know what rights it has, or you could say that a client account can't see the big picture of DDL. The understanding of rights is all communicated through non-API means. * Info about Performance: clients don't know rate limits, current system load, what system admins consider reasonable data sizes or reasonable analytic calculations, etc... I don't know what GraphQL does for each of those issues, but I'd love to hear. [0] I recently setup InfluxDB which has a (private) web interface that takes raw SQL-ish, and it's so convenient.
- brandur 10y ago
  So I think it's a bit of a misconception that GraphQL is going to essentially map to SQL in the backend. Essentially, it's up to the service provider to decide what query paths and mutations are available in GraphQL, and design their schema accordingly. So for example, if you allowed "comments" to be queried within a "user", you'd make sure that users could be looked up efficiently by their ID, and that comments could be loaded in bulk efficiently based on user ID. You'd also make sure that your implementation for both those operations is secure. It's not too dissimilar to REST in that you're still very much designing what your API should look like and not exposing anything else.
- djmashko2 10y ago
  I cover a lot of these thoughts in my post about misconceptions about GraphQL coming from REST here: https://dev-blog.apollodata.com/graphql-the-next-generation-of-api-design-f24b1689756a#.ph8196t2j https://dev-blog.apollodata.com/graphql-the-next-generation-...

by brandur 10y ago

daurnimator 10y ago

I'm a big fan of postgrest (https://github.com/begriffs/postgrest/ https://github.com/begriffs/postgrest/). It creates a RESTful HTTP API out of your existing postgres schema. It practically eliminates the need to write a CRUD backend.

ruslan_talpa 10y ago
Usually when you say CRUD people tend to think "limited functionality" and PostgREST is a bit more then "basic CRUD" as i am sure you know. It's interface is powerful enough to support GraphQL on top (since this is the topic of this thread :) https://subzero.cloud/ https://subzero.cloud/ )
brandur 10y ago
Yes, PostgREST is awesome :) It turns out that most of what is usually expressed in implementation code assuming that you're hitting a dumb backend is just as well-served by SQL functions and schemas. This probably breaks down for larger projects, but it certainly has its place, and I can imagine something very similar be done for GraphQL.
- ruslan_talpa 10y ago
  I don't think it breaks down (as long as most of the data comes form the database). For example i know exactly how paymoapp.com (similar to basecamp) is structured , i consider it to be a fairly large system and i know for a fact that PostgREST can support that. As for the "very similar be done for GraphQL", there is https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql which was based on postgrest ideas. Another approach would be to build graphql on top of postgrest (my comment below)

irq-1 10y ago

Thinking about the problems with client-side SQL seems informative[0]: * Security; allowing evaluation rather than a describing results. * DDL; Data Structure and Types need to be learned out-of-band. Ideally we want a sort-of interactive INFORMATION_SCHEMA over http, so our tools can inform us about types/structure and we always have updated info as we write queries. * Performance; Stored Procedures (server-side) protect against a client making poor joins; ORMs requesting too much data, etc... * Info about Security: client side SQL doesn't know what rights it has, or you could say that a client account can't see the big picture of DDL. The understanding of rights is all communicated through non-API means. * Info about Performance: clients don't know rate limits, current system load, what system admins consider reasonable data sizes or reasonable analytic calculations, etc... I don't know what GraphQL does for each of those issues, but I'd love to hear. [0] I recently setup InfluxDB which has a (private) web interface that takes raw SQL-ish, and it's so convenient.

brandur 10y ago
So I think it's a bit of a misconception that GraphQL is going to essentially map to SQL in the backend. Essentially, it's up to the service provider to decide what query paths and mutations are available in GraphQL, and design their schema accordingly. So for example, if you allowed "comments" to be queried within a "user", you'd make sure that users could be looked up efficiently by their ID, and that comments could be loaded in bulk efficiently based on user ID. You'd also make sure that your implementation for both those operations is secure. It's not too dissimilar to REST in that you're still very much designing what your API should look like and not exposing anything else.
djmashko2 10y ago
I cover a lot of these thoughts in my post about misconceptions about GraphQL coming from REST here: https://dev-blog.apollodata.com/graphql-the-next-generation-of-api-design-f24b1689756a#.ph8196t2j https://dev-blog.apollodata.com/graphql-the-next-generation-...