3 ms·

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 inv

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.

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.