The issue I have with these automatic "backend from your DB" service is:
* For the simple case, they seem like they are as good as a simple backend service, albeit easier to set up.
* For more complex cases (e.g. external dependencies, complex business logic), they seem so much more difficult to make work that I can't imagine anyone _not_ setting up a separate service to handle those scenarios. Maybe you can do everything with stored procedures, but Hasura, Postgraphile, et al. all seem to suggest that you should stand up a separate service for this.
* Once you've got a separate service where your complexity lives, that's going to be the meat of your project.
* Is it really worth it to introduce a separate dependency & pattern just to scaffold the easy parts more quickly? The consistency of having a single data access pattern between the client and all parts of your service seems like it would outweigh not needing to write a little code to proxy queries through your backend by far.
I guess it really depends on the app - if it's really just a view layer, or if the RUD* has very little logic to it and it's expected that the complexity of the backend logic really won't grow over time (never seen this...) then sure, it could be a fit.
Until then it seems like yet another MVP optimization that gets thrown away as soon as the app needs to grow up.
> * For the simple case, they seem like they are as good as a simple backend service, albeit easier to set up.
Agreed.
> * For more complex cases (e.g. external dependencies, complex business logic), they seem so much more difficult to make work that I can't imagine anyone _not_ setting up a separate service to handle those scenarios. Maybe you can do everything with stored procedures, but Hasura, Postgraphile, et al. all seem to suggest that you should stand up a separate service for this.
You should stand up a separate service for this regardless of your choice of web server.
A web server should not be handling complex business logic cases, for many reasons but one obvious one is synchronous wait times. PostgREST or not, bigger job should go into a work queue, which should take just a few milliseconds.
The second reason a work queue is better is that it is more secure. Your web process can be given the absolute minimal privileges, say INSERT only on the queue table. The queue worker can have more privileges. The important upside is that user facing systems cannot take "complex business logic" actions by way of security enforcement.
> * Once you've got a separate service where your complexity lives, that's going to be the meat of your project.
I agree, but that will happen regardless of your web server.
> * Is it really worth it to introduce a separate dependency & pattern just to scaffold the easy parts more quickly?
Quickness is only one tiny advantage of PostgREST. Native security on database objects, streaming responses without buffering, using every available postgres feature that no other database supports without third-party plugins to your web framework, that's just the beginning, but yeah it's a hell of a lot quick and easier to use too.
> Postgraphile, et al. all seem to suggest that you should stand up a separate service for this.
PostGraphile maintainer here; with the exception of recommending job queues for work that can/should be completed asynchronously (which is a good idea no matter what server you use) I do not recommended setting up a separate service for this kind of thing. PostGraphile is highly extensible, you can implement most things in JS (or TypeScript) natively in Node.
* For the simple case, they seem like they are as good as a simple backend service, albeit easier to set up.
* For more complex cases (e.g. external dependencies, complex business logic), they seem so much more difficult to make work that I can't imagine anyone _not_ setting up a separate service to handle those scenarios. Maybe you can do everything with stored procedures, but Hasura, Postgraphile, et al. all seem to suggest that you should stand up a separate service for this.
* Once you've got a separate service where your complexity lives, that's going to be the meat of your project.
* Is it really worth it to introduce a separate dependency & pattern just to scaffold the easy parts more quickly? The consistency of having a single data access pattern between the client and all parts of your service seems like it would outweigh not needing to write a little code to proxy queries through your backend by far.
I guess it really depends on the app - if it's really just a view layer, or if the RUD* has very little logic to it and it's expected that the complexity of the backend logic really won't grow over time (never seen this...) then sure, it could be a fit.
Until then it seems like yet another MVP optimization that gets thrown away as soon as the app needs to grow up.