4 ms·
This is a common misunderstanding and I think a big reason why people are reluctant to try this type of architecture. The idea here is not to couple client code
by felixyz 7y ago
This is a common misunderstanding and I think a big reason why people are reluctant to try this type of architecture. The idea here is not to couple client code to the database structure. You should expose schemas that contain views on top of the basic schema, which provides good encapsulation and prvents both of the issues you bring up. (This was common 25 years ago, when server-side code often amounted to a db schema containing stored procedures.)
- konschubert 7y agoThat’s a step in the right direction but I’m not sure if it really solves the problem. But as I said, there are trade offs. I didn’t say it’s always a bad idea.
- felixyz 7y agoI agree there are always trade-offs, but at least as far as "losing a lot of he database performance" and "doing complex joins on your front end", I don't think there is anything in the PostgREST approach that would push in that direction. For more background on the performance part (Oracle-specific but most of it carries over) check out http://www.prohuddle.com/webinars/ToonKoppelaars/ThickDB.php http://www.prohuddle.com/webinars/ToonKoppelaars/ThickDB.php
- steve-chavez 7y agoIt's amazing that at PostgREST we have reached the same pattern for exposing the API(views + sps). Thanks a lot for sharing.