6 ms·

Postgraphile is a better alternative. Then there's also Hasura, 8Base and XGeneCloud. Did I miss anyone?

by jensneuse 6y ago

np_tedious 6y ago
Most (or all?) of those are GraphQL rather than REST.
- masklinn 6y ago
  Given that, despite the project name, the tool described by TFA is pretty obviously RPC over HTTP rather than anything resembling Fielding's description, graphql would would just as well.
  - michelpp 6y ago
    Sorry but I disagree, PostgREST is REST. For example URLs map to resources and it uses HTTP verbs. GraphQL does not.
    - masklinn 6y ago
      > Sorry but I disagree Feel free to. But maybe consider that "taking advantage of HTTP" != "REST". > PostgREST is REST. The primary if not sole distinction of a REST system according to the creator of the concept is hyperlinking. From what I understand of postgrest, hyperlinking is nonexistent. > For example URLs map to resources Which doesn't really matter when these URLs are magic strings. It's also not really true, URLs are a mix of procedures (/tsearch, literally everything below /rpc) and function names, really, to be passed a bundle of parameters through query strings. And the project itself recommends using stored procedures (and views) when exposing the system to any sort of untrusted environments. > it uses HTTP verbs Not actually relevant to REST, and serving as little more than a form of namespacing.
      - steve-chavez 6y ago
        > URLs are a mix of procedures (/tsearch, literally everything below /rpc) and function names Perhaps you'd be surprised in knowing that a resource can be a stored procedure, quoting Roy Fielding[1]: "a single resource can be the equivalent of a database stored procedure, with the power to abstract state changes over any number of storage items" In general I think PostgREST's REST implementation is evolving. Also, we've had Roy Fielding giving feedback[2] on an issue before. Once we fix that issue, we'll ask him if he thinks if PostgREST is REST. I have a feeling that he might reply positively :-]. We'll see. [1]:https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-743 https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... [2]: https://github.com/PostgREST/postgrest/issues/1089#issuecomment-515184613 https://github.com/PostgREST/postgrest/issues/1089#issuecomm...
        masklinn 6y ago
        > Perhaps you'd be surprised in knowing that a resource can be a stored procedure, quoting Roy Fielding[1]: I'll direct you to the title of the post to which this comment is associated. >> REST APIs must be hypertext-driven > I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Now maybe I missed all the hypertext in postgrest, but given all of its documentation obviously fails the criteria of > A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). I don't see how it could be in any way REST. > Also, we've had Roy Fielding giving feedback[2] on an issue before. That is feedback on an issue of HTTP implementation and compliance, it has nothing to do with REST. Now look I really don't mind APIs being good HTTP citizens and having nothing to do with hypermedia, and that REST is an interesting idea doesn't mean it's a good idea (at least for programmatic APIs). But it's like people saw a picture of a baby in a bath, went "well I don't need the pink thing in the middle but I'd sure like to wash up a bit", and when others point out they're carrying around a jug of soapy water which they insist is a baby called Fred those others get called "Baby purists"[-1]. [-1] https://news.ycombinator.com/item?id=25171460 https://news.ycombinator.com/item?id=25171460
        np_tedious 6y ago
- xgenecloud 6y ago
  XgeneCloud[1] supports REST as well. https://github.com/xgenecloud/xgenecloud https://github.com/xgenecloud/xgenecloud
fulafel 6y ago
That seems to be a GraphQL thing so not a direct alternative.
michelpp 6y ago
Postgraphile and PostgREST can be used side by side, they provide different interfaces but can talk to the same database. Two for the price of one!
SahAssar 6y ago
Better based on what?
- jensneuse 6y ago
  Just personal taste. Without knowing the actual use case it doesn't make sense to judge. However, there's one thing that GraphQL CRUD APIs will always win over REST CRUD APIs and that's n+1. Smart enough GraphQL middlewares can turn any Query into a single SQL statement whereas with REST it can very easy become a waterfall of hundreds or thousands of requests. But again, if you don't have nested data you might not this feature.
  - SahAssar 6y ago
    Postgrest has resource embedding that even works over join tables, so most relations should be no problem to include in a single request.
  - steve-chavez 6y ago
    PostgREST has solved n+1 with resource embedding[1] since 2015(maybe a year before Postgraphql/Postgraphile was born). So GraphQL does not pose an inherent advantage over REST for doing this. [1]: http://postgrest.org/en/v7.0.0/api.html#resource-embedding http://postgrest.org/en/v7.0.0/api.html#resource-embedding
    - jensneuse 6y ago
      I didn't know. Really nice!

Postgraphile is a better alternative. Then there's also Hasura, 8Base and XGeneCloud. Did I miss anyone?

np_tedious 6y ago

Most (or all?) of those are GraphQL rather than REST.

masklinn 6y ago
Given that, despite the project name, the tool described by TFA is pretty obviously RPC over HTTP rather than anything resembling Fielding's description, graphql would would just as well.
- michelpp 6y ago
  Sorry but I disagree, PostgREST is REST. For example URLs map to resources and it uses HTTP verbs. GraphQL does not.
  - masklinn 6y ago
    > Sorry but I disagree Feel free to. But maybe consider that "taking advantage of HTTP" != "REST". > PostgREST is REST. The primary if not sole distinction of a REST system according to the creator of the concept is hyperlinking. From what I understand of postgrest, hyperlinking is nonexistent. > For example URLs map to resources Which doesn't really matter when these URLs are magic strings. It's also not really true, URLs are a mix of procedures (/tsearch, literally everything below /rpc) and function names, really, to be passed a bundle of parameters through query strings. And the project itself recommends using stored procedures (and views) when exposing the system to any sort of untrusted environments. > it uses HTTP verbs Not actually relevant to REST, and serving as little more than a form of namespacing.
    - steve-chavez 6y ago
      > URLs are a mix of procedures (/tsearch, literally everything below /rpc) and function names Perhaps you'd be surprised in knowing that a resource can be a stored procedure, quoting Roy Fielding[1]: "a single resource can be the equivalent of a database stored procedure, with the power to abstract state changes over any number of storage items" In general I think PostgREST's REST implementation is evolving. Also, we've had Roy Fielding giving feedback[2] on an issue before. Once we fix that issue, we'll ask him if he thinks if PostgREST is REST. I have a feeling that he might reply positively :-]. We'll see. [1]:https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-743 https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... [2]: https://github.com/PostgREST/postgrest/issues/1089#issuecomment-515184613 https://github.com/PostgREST/postgrest/issues/1089#issuecomm...
      - masklinn 6y ago
        > Perhaps you'd be surprised in knowing that a resource can be a stored procedure, quoting Roy Fielding[1]: I'll direct you to the title of the post to which this comment is associated. >> REST APIs must be hypertext-driven > I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Now maybe I missed all the hypertext in postgrest, but given all of its documentation obviously fails the criteria of > A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). I don't see how it could be in any way REST. > Also, we've had Roy Fielding giving feedback[2] on an issue before. That is feedback on an issue of HTTP implementation and compliance, it has nothing to do with REST. Now look I really don't mind APIs being good HTTP citizens and having nothing to do with hypermedia, and that REST is an interesting idea doesn't mean it's a good idea (at least for programmatic APIs). But it's like people saw a picture of a baby in a bath, went "well I don't need the pink thing in the middle but I'd sure like to wash up a bit", and when others point out they're carrying around a jug of soapy water which they insist is a baby called Fred those others get called "Baby purists"[-1]. [-1] https://news.ycombinator.com/item?id=25171460 https://news.ycombinator.com/item?id=25171460
        np_tedious 6y ago
xgenecloud 6y ago
XgeneCloud[1] supports REST as well. https://github.com/xgenecloud/xgenecloud https://github.com/xgenecloud/xgenecloud

fulafel 6y ago

That seems to be a GraphQL thing so not a direct alternative.

michelpp 6y ago

Postgraphile and PostgREST can be used side by side, they provide different interfaces but can talk to the same database. Two for the price of one!

SahAssar 6y ago

Better based on what?

jensneuse 6y ago
Just personal taste. Without knowing the actual use case it doesn't make sense to judge. However, there's one thing that GraphQL CRUD APIs will always win over REST CRUD APIs and that's n+1. Smart enough GraphQL middlewares can turn any Query into a single SQL statement whereas with REST it can very easy become a waterfall of hundreds or thousands of requests. But again, if you don't have nested data you might not this feature.
- SahAssar 6y ago
  Postgrest has resource embedding that even works over join tables, so most relations should be no problem to include in a single request.
- steve-chavez 6y ago
  PostgREST has solved n+1 with resource embedding[1] since 2015(maybe a year before Postgraphql/Postgraphile was born). So GraphQL does not pose an inherent advantage over REST for doing this. [1]: http://postgrest.org/en/v7.0.0/api.html#resource-embedding http://postgrest.org/en/v7.0.0/api.html#resource-embedding
  - jensneuse 6y ago
    I didn't know. Really nice!