3 ms·

For company-internal webapps, we found that Postgres and Postgraphile [1] usually replaces the need for any other backend. You can do a lot with SQL and databas

For company-internal webapps, we found that Postgres and Postgraphile [1] usually replaces the need for any other backend. You can do a lot with SQL and database functions. If you're worried that the application is coupled too tightly to the database, create another database schema just with views and functions as an abstraction layer. If something can't be done in a Postgres stored procedure, like rendering graphics as SVG or PNG image, use the python language just in this stored procedure. The postgres+postgraphile combination is really powerful! We used to build GraphQL backends with Python and Ariadne before. [1] https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/

berkes 4y ago
Where do you maintain the business logic? And how does an RCS or some version management work with this? It sounds simple. And I like simple. But superficially looking at it, it sounds too simple.
- thallix14 4y ago
  I should say that the applications are largely for read-only data access. We define not null, unique etc. database constraints to ensure data problems are detected during import. An application for data entry used stored procedures as GraphQL mutations where more complex logic for data validation was required. So one parameterized procedure can check its inputs and update multiple tables in one transaction, or raise an error if the validation failed. We also used postgres policies for row-level access control in one application. The policy functions could rely on the logged in user being already validated and present in a SQL variable (we set that variable in a postgraphile javascript hook). The database schema and stored procedures are just one or multiple SQL files which are in version control. I also commit example GraphQL queries, which indicate how a schema can be used and can serve as a manual test case.

berkes 4y ago

Where do you maintain the business logic? And how does an RCS or some version management work with this? It sounds simple. And I like simple. But superficially looking at it, it sounds too simple.

thallix14 4y ago
I should say that the applications are largely for read-only data access. We define not null, unique etc. database constraints to ensure data problems are detected during import. An application for data entry used stored procedures as GraphQL mutations where more complex logic for data validation was required. So one parameterized procedure can check its inputs and update multiple tables in one transaction, or raise an error if the validation failed. We also used postgres policies for row-level access control in one application. The policy functions could rely on the logged in user being already validated and present in a SQL variable (we set that variable in a postgraphile javascript hook). The database schema and stored procedures are just one or multiple SQL files which are in version control. I also commit example GraphQL queries, which indicate how a schema can be used and can serve as a manual test case.