4 ms·

There are trade offs when you couple your front end to your database structure. Additionally, if you are using a lossy intermediate query representation instea

• ruslan_talpa 7y ago
  when it comes to these tools, all your statements are wrong, give them 5 minutes and check our their capabilities (there is no coupling and joins in frontend) :)
• 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 ago
    That’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 ago
      I 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 ago
        It's amazing that at PostgREST we have reached the same pattern for exposing the API(views + sps). Thanks a lot for sharing.