[ahpearce]

That is not always a great idea. There is a reason APIs exist, and backend service layers exist on top of databases. It is a larger abstraction of the interface design pattern.

It only makes sense if you're absolutely sure you'll never need to extend or change the interaction between front-end and back-end.

Think just about schema migrations on the database. If you change your schema, you have to change your front-end. Maybe that's okay for the time, but that can get out of hand pretty quickly.

On the other hand, with a service layer, you could completely decouple that dependency on the front-end, by providing the front-end an interface (the service layer / API). The migrations on the database layer don't affect the front-end whatsoever, because the front-end communicates with the interface. You can change the underlying implementation without changing the front-end's interaction with the interface.

http://best-practice-software-engineering.ifs.tuwien.ac.at/p...

[steve-chavez]

Don't forget that the database is not only tables. Abstraction can be done at the SQL level with views.

With views you can maintain backwards compatibility despite migrations happening. No need to change your front-end.

Check this section of the PostgREST docs for more details:

http://postgrest.org/en/v7.0.0/schema_structure.html#schema-...

[ahpearce]

Yeah, views can definitely fit certain use cases. I've just never encountered cases where I eventually don't need to /do something else/ in between those two layers. Granted I'm doing a lot of systems integration on a lot of complex legacy infrastructure, so that might just be me!