does it makes sense to use rocket with PostgRest ?

[commandline-be]

Reading https://postgrest.org/en/v9.0/tutorials/tut0.html it feels like comming home to sane design again. I'd glanced at ORM but it felt totally alien.

Yet, i still have rocket on my list to learn more about by coding. Does it makes sense to combine both to deliver a performant and robust website ?

Thinking here of how PostgRest responds with JSON i assume i can simply have Rocket such results into a web page template etc. ?

Br,

JL

[IniterWorker]

Hi @commandline-be,

I will respond technically,

Yes, you can use Rocket to communicate with a micro-service like PostGRest.

• Use a route to call your remote API is very common in a micro-services architecture.

But, I can't say if it is what you need.

B. r

[commandline-be]

I think it will work well for me and make writing a web application easier to maintain.

[tobymurray]

Using a dedicated application server on top of something like PostgREST (or PostGraphile) is definitely possible and I'm sure is used somewhere. As a trivial example I have an Express (Node) and PostGraphile app here that does exactly that though with different frameworks. If PostgREST is doing all the interesting work, it may not be a great project to learn Rocket - echoing data from a separate web service is not the typical use case, so you might have some trouble finding supporting documentation/best practices/etc. Then again, if you're just mucking around, why not?

On the one hand, it seems inevitable to add a "real" application server just to get a sane programming language instead of having to write all your business logic in stored procedures and and custom views. If you have very strong SQL skills, maybe this is not a barrier. On the other hand, it really makes you question "why bother having two web services?". Have you looked at non-ORM solutions like SQLx? If your main goal is to avoid ORMs, it's well worth considering when compared to adding a whole extra web service.

[tobymurray]

Have you looked at something like SQLx, that will make the database accessible in Rust without trying to tackle the ORM problem?

[commandline-be]

To me SQLx doesn't appear to solve what PostGRest appears to solve. If PGRest doesn't work out i'll check SQLx for sure.

[tobymurray]

I agree PostgREST doesn't solve the same problem as SQLx, I guess what I'm suggesting is I have not seen success trying to avoid SQL entirely (if that's your goal) and introducing a webservice based on SQL seems even more heavy-handed than an ORM. Ultimately I imagine you'll end up with significantly greater volume and more complex database implementations to get the right content out of PostgREST compared to writing the relevant database calls yourself. So from that limited perspective, to answer your original question of "does it make sense", I would answer "no, when compared to other options e.g. SQLx".

That said, it's better to try something and get it to the point where you know than sit and speculate. Best of luck!

[commandline-be]

Review PGRest i think it is the perfect solution for me. It offloads the database to an API which i can query from and get results into Rocket in a format supported by Rocket. It makes database queries an integral part of the URL space. Meaning i can focus entirely on a web application in Rocket.

If the word web-service would be a metric for weight i'd agree, in this case it appears rather light weight and suitable for the low volume sites i have in mind.

[somehowchris]

Totally with you guys. Just wanna throw something in.

Using rocket as a „middleman“ only makes sense if you have some transformation, validation, default responses, loopbacks, retires or authentication in mind. If you would just like to have your urls shortened and structured you might wanna look into nginx as you would literally say go from x (i.e. /customers) to y (i.e. /core/customers?include=oders) (didn‘t look up PostgRest so excuse me for that random example) with ease and no need for real code or compilation overhead. (Nginx is still written in C++ and C, so still damn fast)

This would make the options:

• frontend (i.e. tauri) -> Rocket -> PostgRest -> Postgres (if you need to leverage custom logic on the Rocket backend)
• frontend (i.e. tauri) -> nginx -> PostgRest -> Postgres (if you just would like to structure your backend calls from the frontend)
• frontend (i.e. tauri) -> PostgRest -> Postgres (if you anyway would expose PostgRest (not really advocating for that))
• frontend (i.e. tauri) -> Rocket -> Postgres (if you use something like SQLx or diesel.rs to get the maximum amount of speed (network transfers, transforms,.. still take some time for option 1))
• (frontend (i.e. tauri) -> Postgres, Yes this option exists, PLEASE just do not do it 😄 the hackers number 1 choice for attacks )