4 ms·

You don't debug views of course. But with postgREST you have to write your logic in stored procedures. So say I want to write an accounting app that has an invo

You don't debug views of course. But with postgREST you have to write your logic in stored procedures. So say I want to write an accounting app that has an invoice function. A view is not enough to create an invoice, because there are complex rules to apply to the data, so I have to write a SP. I need to debug that stored procedure, and if I have to install pgAdmin and switch from my very much loved and customized editor to debug my invoicing procedure, the workflow is broken, and so it comes that I will write that invoicing function in C#, java, python or js instead, because the tooling is better. Compare that to a node application: just open vscode, start editing away and press F5 to test it. If you want to debug it, add a breakpoint and step away. When you are done you commit and push to git. It should be the same with stored procedures.

ruslan_talpa 7y ago
Let's start with the fact that most of the data centric apis have a 80/20 split on read write, so there is virtually not SP in 80% of your api, so no need to debug 80% of the code :) so you "might" need stored procedures only for your write part and even then you need them when the input data needs to be split and sent to different tables. The complex "rules" are nothing more then "constraints" on your data which are split between the columns of the table and become so simple that there is almost nothing to debug. If it were the case that with postgrest one needs to write complicated stored procedures all over the place you'd be 100% correct. The thing is you don't need them in most cases and when you do they are short simple functions that deal with focused things so there is way less chance to get them wrong. This has been my experience with using this type of stack for apps like project management/invoicing.... etc (basically basecamp+freshbooks)
- deepersprout 7y ago
  Basically you are saying "I don't need stored procedures, therefore neither should you". If you don't use them clearly you don't need to debug them. That does not change what I said earlier: a difficult development workflow hinders their adoption.
  - ruslan_talpa 7y ago
    not exactly what i meant. it's true that it's not a polished workflow to debug stored procedures because you you have to jump from your editor to pgadmin but i don't think this is such a big deal for two reasons. - postgrest architecture is such that you rarely need stored procedures (not just me, all the projects), it's the exact same way ppl use databases without them (they just send queries to the db, same here). 90% of the code in this type of project is table/view definitions (with constraints) and appropriate grant/rls statements. So there is very little imperative code to debug. - The type of stored procedures used is quite simple, isolated and mostly self contained, a single function, maybe calling some other helper functions (you are always 2 levels deep at most) so it's not like in other envs where you have to follow the code jumps between hundreds of functions and classes.

ruslan_talpa 7y ago

Let's start with the fact that most of the data centric apis have a 80/20 split on read write, so there is virtually not SP in 80% of your api, so no need to debug 80% of the code :) so you "might" need stored procedures only for your write part and even then you need them when the input data needs to be split and sent to different tables. The complex "rules" are nothing more then "constraints" on your data which are split between the columns of the table and become so simple that there is almost nothing to debug. If it were the case that with postgrest one needs to write complicated stored procedures all over the place you'd be 100% correct. The thing is you don't need them in most cases and when you do they are short simple functions that deal with focused things so there is way less chance to get them wrong. This has been my experience with using this type of stack for apps like project management/invoicing.... etc (basically basecamp+freshbooks)

deepersprout 7y ago
Basically you are saying "I don't need stored procedures, therefore neither should you". If you don't use them clearly you don't need to debug them. That does not change what I said earlier: a difficult development workflow hinders their adoption.
- ruslan_talpa 7y ago
  not exactly what i meant. it's true that it's not a polished workflow to debug stored procedures because you you have to jump from your editor to pgadmin but i don't think this is such a big deal for two reasons. - postgrest architecture is such that you rarely need stored procedures (not just me, all the projects), it's the exact same way ppl use databases without them (they just send queries to the db, same here). 90% of the code in this type of project is table/view definitions (with constraints) and appropriate grant/rls statements. So there is very little imperative code to debug. - The type of stored procedures used is quite simple, isolated and mostly self contained, a single function, maybe calling some other helper functions (you are always 2 levels deep at most) so it's not like in other envs where you have to follow the code jumps between hundreds of functions and classes.