3 ms·

This is nothing like what you're describing. Postgrest is not an ORM, it just takes rows from your database and sends them to the client. It encourages you to

This is nothing like what you're describing. Postgrest is not an ORM, it just takes rows from your database and sends them to the client. It encourages you to write SQL. Write a decent SQL schema. Write SQL views on top of that schema to provide the rows to your API. Even write SQL functions to modify the data in reaction to client calls! If you hate ORMs and love SQL (specially Postgres, because it's amazing) this is the tool you should be using.

hudo 7y ago
Postgrest is RRM actually- rest relational mapper. My point is - exposing db over HTTP (REST, GraphQL, ...) is bad architectural design and idea.
- cerberusss 7y ago
  So what is the alternative that you propose?
- ruslan_talpa 7y ago
  between postgrest/postgraphile/hasura there are 30k stars, have all those ppl fallend for this "dumb" idea :)? You say "expose db" and imply that one would directly give access to the core tables and in this way coupling the api to the data model (one should expose only views and stored procedures) and making the api inflexible. Or are you saying this is insecure, and if so, can you describe how one would "break" this?
- shantly 7y ago
  > My point is - exposing db over HTTP (REST, GraphQL, ...) is bad architectural design and idea. I'm with you that exposing a fairly free-form query language over HTTP seems like something that's gonna bite several someones in the ass pretty hard at some point (GraphQL) but what's that got to do with PostgREST?
  - ruslan_talpa 7y ago
    actually .... :) Postgrest has the same "capabilities" as GraphQL so if one is not carefull and jsut (naively) exposes tables with millions of rows with just postgrest (and no propper indexes) it can get bad fast since the client could create queries that join and return a lot of data. That's why one does not deploy postgrest alone but use it in a setting like this https://github.com/subzerocloud/postgrest-starter-kit https://github.com/subzerocloud/postgrest-starter-kit where you at the proxy level can say things like "return 400 if the client did not provide at least 2 filters for the table" or "allow filtering on column a and b because they have indexes but not on c" But again, those are things to consider when you have datasets exceding hundreds of K or millions, you don't need to care about this when you have tables with 10s of Ks
    - shantly 7y ago
      Well sure they have the same capabilities from a certain perspective, in that both ultimately send data from a database to a client, but GraphQL does this entirely through a fairly free-form query language with either auto-generated or custom mapping code to turn that into DB queries (though in all cases it has to handle a fairly flexible query set or "shape", or else what's the point of using GraphQL), while PostgREST requires views and stored procedures to handle all but the most trivial cases. I think the latter's way less likely than the former to cause unexpected problems or force tons of defensive coding and cause anxious, sleepless nights—PostgREST seems to me closer to what's normal for any more traditional DB-to-HTTP-client CRUD glueware (Rails, Django—like 99% of the dynamic web, really) when it comes to inherent risk factor. Exposing a poorly-indexed table can happen in any ol' Rails API app with the usual lazy 3-line controller methods bouncing about its codebase—that's the same level of risk in any system using a database, more or less. I don't see PostgREST as being more likely to cause that to happen. GraphQL's trickier, especially from a performance perspective, because the scope of a query is so hard to determine or account for up-front, and it's hard to confidently answer the question "what's the largest possible scope of a request to this endpoint?".
      - ruslan_talpa 7y ago

hudo 7y ago

Postgrest is RRM actually- rest relational mapper. My point is - exposing db over HTTP (REST, GraphQL, ...) is bad architectural design and idea.

cerberusss 7y ago
So what is the alternative that you propose?
ruslan_talpa 7y ago
between postgrest/postgraphile/hasura there are 30k stars, have all those ppl fallend for this "dumb" idea :)? You say "expose db" and imply that one would directly give access to the core tables and in this way coupling the api to the data model (one should expose only views and stored procedures) and making the api inflexible. Or are you saying this is insecure, and if so, can you describe how one would "break" this?
shantly 7y ago
> My point is - exposing db over HTTP (REST, GraphQL, ...) is bad architectural design and idea. I'm with you that exposing a fairly free-form query language over HTTP seems like something that's gonna bite several someones in the ass pretty hard at some point (GraphQL) but what's that got to do with PostgREST?
- ruslan_talpa 7y ago
  actually .... :) Postgrest has the same "capabilities" as GraphQL so if one is not carefull and jsut (naively) exposes tables with millions of rows with just postgrest (and no propper indexes) it can get bad fast since the client could create queries that join and return a lot of data. That's why one does not deploy postgrest alone but use it in a setting like this https://github.com/subzerocloud/postgrest-starter-kit https://github.com/subzerocloud/postgrest-starter-kit where you at the proxy level can say things like "return 400 if the client did not provide at least 2 filters for the table" or "allow filtering on column a and b because they have indexes but not on c" But again, those are things to consider when you have datasets exceding hundreds of K or millions, you don't need to care about this when you have tables with 10s of Ks
  - shantly 7y ago
    Well sure they have the same capabilities from a certain perspective, in that both ultimately send data from a database to a client, but GraphQL does this entirely through a fairly free-form query language with either auto-generated or custom mapping code to turn that into DB queries (though in all cases it has to handle a fairly flexible query set or "shape", or else what's the point of using GraphQL), while PostgREST requires views and stored procedures to handle all but the most trivial cases. I think the latter's way less likely than the former to cause unexpected problems or force tons of defensive coding and cause anxious, sleepless nights—PostgREST seems to me closer to what's normal for any more traditional DB-to-HTTP-client CRUD glueware (Rails, Django—like 99% of the dynamic web, really) when it comes to inherent risk factor. Exposing a poorly-indexed table can happen in any ol' Rails API app with the usual lazy 3-line controller methods bouncing about its codebase—that's the same level of risk in any system using a database, more or less. I don't see PostgREST as being more likely to cause that to happen. GraphQL's trickier, especially from a performance perspective, because the scope of a query is so hard to determine or account for up-front, and it's hard to confidently answer the question "what's the largest possible scope of a request to this endpoint?".
    - ruslan_talpa 7y ago