-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic GraphQL Schema #58
Comments
Is this ultimately a desired feature? Alternatively we could run Hasura over the main RCOS API. |
We could do that honestly. It's desired if we intend to continue exposing an API as part of telescope but we could separate that concern to another service (temporarily or permanently) and there are definitely valid reasons why we might do that. |
I would really push Hasura, just because then it's all pulled from Postgres itself. However the REST vs GraphQL debate is something @Apexal and I went into a lot, and we eventually settled on REST with PostgREST. We ultimately came to the conclusion that while GraphQL adds a lot of features, PostgREST has similar versions of the most important features and uses a much more well understood and ubiquitous REST interface. This API has to outlast us, so we have to be extremely conservative about our technical decisions. |
That makes sense. It seems like whatever we do, having to manually build out a GraphQL API in rust is not a great option currently. It would take a lot of work and might not be as featureful as as Hasura or as conservative as a REST API. With that in mind I'm gonna make a branch removing juniper and GraphQL from this project for now. If we decide later that we do want Telescope to expose an API then we can add them back then. |
There may be some benefits to being able to dynamically generate the GraphQL schema for Juniper. This is not yet currently possible. I will keep an eye on graphql-rust/juniper#7 and other Juniper issues like it.
The text was updated successfully, but these errors were encountered: