3 ms·

From the docs: > It is recommended that you don’t expose tables on your API schema. Instead expose views and stored procedures which insulate the internal deta

by piaste 6y ago

From the docs: > It is recommended that you don’t expose tables on your API schema. Instead expose views and stored procedures which insulate the internal details from the outside world. This allows you to change the internals of your schema and maintain backwards compatibility. It also keeps your code easier to refactor, and provides a natural way to do API versioning. Which is, you'll notice, the same best practice used for decades by DBAs who need to serve multiple applications connecting to the same database. (Also, it's not exactly uncommon that a data store API would have a single client which you control - eg. a single webapp, an internal application... in which case you can go nuts with breaking changes.)

systemvoltage 6y ago
> Which is, you'll notice, the same best practice used for decades by DBAs who need to serve multiple applications connecting to the same database. Clearly, the Database's job contrary to what the name suggests is to not only stick data into it but also a bunch of business logic that's essentially untestable. No one needs domain models when you've got database tightly coupled with behavior and logic of your business. What could go wrong? The whole point of the API is that it is a repository for accessing the data from one or more databases, and packaging it up for the user to consume. It imports domain models which are totally isolated from the rest of the dependencies. The data doesn't even have to be in the database and can come from multiple sources such as S3 or whatever. It can consume data from the user and kick off various processes or insert into the database. It is a generic interface that does more than just CRUD in the DB.
- mojzu 6y ago
  You can use pgTAP for postgres unit testing, with docker you can make the process pretty fast too. Id highly recommend looking into the features/extensions of postgres, there's a lot of great stuff that goes beyond just being a database which can save a lot of time and grief depending on the application. There is a risk of mixing storage/business logic, and you might end up being tied to postgres, but it's manageable using functions/views/schemas. And its also a really convenient place to do some business logic, as all your data is right there and available via a very expressive/extensible query language.
- piaste 6y ago
  If your API needs to serve data that lives in multiple sources, then PostgREST is definitely not the right tool. It is, however, a pretty common design to have all your data flowing into a database, and being served from there. Indeed, it's probably the simplest and most common design for a basic web application. PostgREST or Hasura can do excellent work there.

by piaste 6y ago

systemvoltage 6y ago

> Which is, you'll notice, the same best practice used for decades by DBAs who need to serve multiple applications connecting to the same database. Clearly, the Database's job contrary to what the name suggests is to not only stick data into it but also a bunch of business logic that's essentially untestable. No one needs domain models when you've got database tightly coupled with behavior and logic of your business. What could go wrong? The whole point of the API is that it is a repository for accessing the data from one or more databases, and packaging it up for the user to consume. It imports domain models which are totally isolated from the rest of the dependencies. The data doesn't even have to be in the database and can come from multiple sources such as S3 or whatever. It can consume data from the user and kick off various processes or insert into the database. It is a generic interface that does more than just CRUD in the DB.

mojzu 6y ago
You can use pgTAP for postgres unit testing, with docker you can make the process pretty fast too. Id highly recommend looking into the features/extensions of postgres, there's a lot of great stuff that goes beyond just being a database which can save a lot of time and grief depending on the application. There is a risk of mixing storage/business logic, and you might end up being tied to postgres, but it's manageable using functions/views/schemas. And its also a really convenient place to do some business logic, as all your data is right there and available via a very expressive/extensible query language.
piaste 6y ago
If your API needs to serve data that lives in multiple sources, then PostgREST is definitely not the right tool. It is, however, a pretty common design to have all your data flowing into a database, and being served from there. Indeed, it's probably the simplest and most common design for a basic web application. PostgREST or Hasura can do excellent work there.