3 ms·

I don't want to avoid that.

vore 4y ago
Then I think you are in for a world of pain when you need to e.g. change how the underlying storage of your data looks but don't want to change the end user API. A lot of the time, the access patterns of an end user talking to your backend really don't match up to the access patterns of your backend talking to your database.
- dventimihasura 4y ago
  I have a layer of indirection between my end user API and my underlying storage, so that I can change the storage without changing the API. There's no pain involved.
  - vore 4y ago
    Then... why not just use Postgres directly from your end user API's backend? You might as well use an ORM and cut out a layer of overhead from having to marshal data in an out of PostgREST and point of failure from having to run it.
    - dventimihasura 4y ago
      PostgreSQL + PostgREST IS my "API backend." They're one and the same. There are no other layers. Using an ORM would ADD a layer, not subtract one. Perhaps what you're asking is, "Why not just have your user interface connect directly to PostgreSQL and issue SQL statements?"
  - sokoloff 4y ago
    How does that square with: > I don't want to avoid [coupling my application schema to my database schema] It seems like you built a layer of indirection to specifically allow the thing you said you didn’t want to do a couple posts up. (I think your indirection layer is a good idea; I’m curious what your previous post meant in light of that.)
    - dventimihasura 4y ago
      It doesn't. I wasn't addressing "coupling your application schema to your database schema." I was addressing "change how the underlying storage of your data looks but don't want to change the end user API" in the parent comment. > It seems like you built a layer of indirection to specifically allow the thing you said you didn’t want to do a couple posts up No, because my layer of indirection is in the database in the form of views and procedures. I could be wrong, but I took "coupling my application schema to my database schema" to be something like "having your HTTP API depend on objects in the database", which it does because of the way that postgREST works. If that's the kind of coupling we're talking about, then that's the kind of coupling I would rather embrace than avoid.

vore 4y ago

Then I think you are in for a world of pain when you need to e.g. change how the underlying storage of your data looks but don't want to change the end user API. A lot of the time, the access patterns of an end user talking to your backend really don't match up to the access patterns of your backend talking to your database.

dventimihasura 4y ago
I have a layer of indirection between my end user API and my underlying storage, so that I can change the storage without changing the API. There's no pain involved.
- vore 4y ago
  Then... why not just use Postgres directly from your end user API's backend? You might as well use an ORM and cut out a layer of overhead from having to marshal data in an out of PostgREST and point of failure from having to run it.
  - dventimihasura 4y ago
    PostgreSQL + PostgREST IS my "API backend." They're one and the same. There are no other layers. Using an ORM would ADD a layer, not subtract one. Perhaps what you're asking is, "Why not just have your user interface connect directly to PostgreSQL and issue SQL statements?"
- sokoloff 4y ago
  How does that square with: > I don't want to avoid [coupling my application schema to my database schema] It seems like you built a layer of indirection to specifically allow the thing you said you didn’t want to do a couple posts up. (I think your indirection layer is a good idea; I’m curious what your previous post meant in light of that.)
  - dventimihasura 4y ago
    It doesn't. I wasn't addressing "coupling your application schema to your database schema." I was addressing "change how the underlying storage of your data looks but don't want to change the end user API" in the parent comment. > It seems like you built a layer of indirection to specifically allow the thing you said you didn’t want to do a couple posts up No, because my layer of indirection is in the database in the form of views and procedures. I could be wrong, but I took "coupling my application schema to my database schema" to be something like "having your HTTP API depend on objects in the database", which it does because of the way that postgREST works. If that's the kind of coupling we're talking about, then that's the kind of coupling I would rather embrace than avoid.