discussion: async-graphql vs jupiter and diesel vs tokio-postgres vs sqlx

[olexiyb]

@clifinger did you know about async-graphql
At this moment this solution has more features and I feel better then use of jupiter.
I personally followed the implementation of twentyfive-stars and liked the interface more than Jupiter. Jupiter supports async, but not released yet and Jupiter lack of good documentation when async-graphql has excellent book

During the investigation, I came across sqlx and found this native rust driver feature to verify SQL during the build is awesome and helps to find bugs before the actual run.

There are actually 3 choices:

• diesel
• tokio-postgres
• sqlx

I have tried all 3 and finally stopped on sqlx, diesel is crazy complex and not native driver, tokio-postgres is too basic and sqlx is a very good balanced generic solution and I feel performance would be better as it does not have a dependency on libpq (C driver)

I think, that for Bollerplate we need to pick the best solutions on the market and diesel and Jupiter are not the best

[LegNeato]

Not to be rude, but your info is wrong and presented as fact. Please refrain from making such sweeping statements.

Juniper has a book that covers just as much if not more:

https://graphql-rust.github.io/juniper/master/

async-graphql appears to have more features but many of them do not belong in a library and push async-graphql into framework territory. Juniper is firmly in the library camp. It's mainly preference and what you are looking for. The GraphQL featurset is the same for both (minus interfaces on Juniper master, which we are revamping). If there are missing GraphQL features, please file tasks on Juniper!