5 ms·

I really like this approach for mostly crud apps. What is missing is - something to conveniently version control database objects - something to conveniently

I really like this approach for mostly crud apps. What is missing is - something to conveniently version control database objects - something to conveniently debug stored procedures. Maybe directly from vscode or your preferred editor. If those two things get solved somehow, pg could be a really awesome application server.

ruslan_talpa 7y ago
for the first one, read my other comments, this is solved. The second one, you can start here https://www.pgadmin.org/docs/pgadmin4/4.13/debugger.html https://www.pgadmin.org/docs/pgadmin4/4.13/debugger.html
- deepersprout 7y ago
  > for the first one, read my other comments, this is solved. > The second one, you can start here https://www.pgadmin.org/docs/pgadmin4/4.13/debugger.html https://www.pgadmin.org/docs/pgadmin4/4.13/debugger.html I think Starter Kit and the pgAdmin debugger lack in convenience. If you write C# or node js code in your preferred editor, you can debug it there. You can debug your express routes, webapi or resteasy controllers in vscode/vs/eclipse/intellij without leaving the file you later commit to git. Starter Kit and the pgAdmin debugger are fine tools, but they come nowhere close to how you work with a js, C#, java, python or whatever you like codebase. The development workflow with stored procedures imho is broken, and I think that is one of the main reasons people do not use them much.
  - ruslan_talpa 7y ago
    It's true that a tool developed by 1-2 ppl recently is not a convenint as the tools developed by armies of developers over decades :) but, when it comes to PostgREST way of building apis, the debugging does not have the same meaning as in other ecosystems. an api backed by postgres+postgrest is 80% tables and views declarations ... how do you debug a view ... it makes no sense. You just define it and say "select * from view" (even from your IDE) and see if you get what you expect, that's why one can do a lot (develop complex apis) with less (limited debug tools)
    - deepersprout 7y ago
      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.
- j88439h84 7y ago
  > something to conveniently version control database objects I read your comments but couldn't find the answer. What did I miss?
  - ruslan_talpa 7y ago
    https://github.com/subzerocloud/subzero-cli https://github.com/subzerocloud/subzero-cli your code is in files (so git ...) and you edit files adn save them and the new version is loaded to the database and you can make the new api call and see it in action

ruslan_talpa 7y ago

for the first one, read my other comments, this is solved. The second one, you can start here https://www.pgadmin.org/docs/pgadmin4/4.13/debugger.html https://www.pgadmin.org/docs/pgadmin4/4.13/debugger.html

deepersprout 7y ago
> for the first one, read my other comments, this is solved. > The second one, you can start here https://www.pgadmin.org/docs/pgadmin4/4.13/debugger.html https://www.pgadmin.org/docs/pgadmin4/4.13/debugger.html I think Starter Kit and the pgAdmin debugger lack in convenience. If you write C# or node js code in your preferred editor, you can debug it there. You can debug your express routes, webapi or resteasy controllers in vscode/vs/eclipse/intellij without leaving the file you later commit to git. Starter Kit and the pgAdmin debugger are fine tools, but they come nowhere close to how you work with a js, C#, java, python or whatever you like codebase. The development workflow with stored procedures imho is broken, and I think that is one of the main reasons people do not use them much.
- ruslan_talpa 7y ago
  It's true that a tool developed by 1-2 ppl recently is not a convenint as the tools developed by armies of developers over decades :) but, when it comes to PostgREST way of building apis, the debugging does not have the same meaning as in other ecosystems. an api backed by postgres+postgrest is 80% tables and views declarations ... how do you debug a view ... it makes no sense. You just define it and say "select * from view" (even from your IDE) and see if you get what you expect, that's why one can do a lot (develop complex apis) with less (limited debug tools)
  - deepersprout 7y ago
    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.
j88439h84 7y ago
> something to conveniently version control database objects I read your comments but couldn't find the answer. What did I miss?
- ruslan_talpa 7y ago
  https://github.com/subzerocloud/subzero-cli https://github.com/subzerocloud/subzero-cli your code is in files (so git ...) and you edit files adn save them and the new version is loaded to the database and you can make the new api call and see it in action