Closed sevenseacat closed 4 months ago
I wonder if we could get away with something simpler, and just put this in our getting started guide (and then in the installer once I get to ash_graphql
. Like add a hello_world
and say "this place holder is to give you something working from the outset. Once you have at least one query in one of your resources, you can remove it".
That would certainly be a lot easier to implement!
I think there are probably pros and cons for both ways - if a sample query is added in the app, I can see devs leaving it there, or maybe getting the wrong idea and thinking that you need to add custom queries to interact with resources.
But if it's added dynamically from ash_graphql I can see devs thinking its too much magic, how can I disable/remove it, etc.
I'll leave it up to you when you look at the installer!
This has been implemented by altering the getting started guide. Not as fancy as doing something automatically, but also much easier to do. We can revisit at a later date potentially to do something automatically as well.
Is your feature request related to a problem? Please describe.
When going through the setup experience, there's no way to verify that everything has been set up correctly, before starting to add resources to your API. When the generated schema is empty, your app won't compile (Absinthe errors out, saying there must be at least one query in the schema).
Describe the solution you'd like
If we had a sample query generated if the schema was empty, users could verify that everything is set up correctly, see the playground, etc. and test the query out.
It could be a super simple query, eg. a
sayHello
query that resolves to{:ok, "Hello from AshGraphql!"}
As soon as the user starts adding resources and queries to their API, the sample query would disappear as it is no longer needed.
Describe alternatives you've considered
The alternative is that we add a sample query to the schema file, when we generate it in the user's app (with the Igniter generator, as part of a setup task...) The generated schema would have the empty query and mutation blocks, and we could put a small query in there, but it would probably never be removed by most users.
Express the feature either with a change to resource syntax, or with a change to the resource interface
N/A
Additional context
I mentioned that I would take a look at implementing this, and I did look into the code, but couldn't really figure out how all the pieces hung together. So here's a proposal for it!