Bumps version number to 0.11.0, though all changes are additive
Also fixes a small issue when unwrapping Request.path where an empty string would cause the request to fail unintentionally.
While we actually kind of support GraphQL requests right out of the box, because really they're just weird POST requests, this PR attempts to lay the groundwork for some better support.
One of the big advantages of GraphQL is that you can know the entire schema ahead of time, and can potentially use that to save yourself a lot of time by generating things like inputs and output models ahead of time.
This is obviously a lot more work, and involves generating code and compile time, so since it's not strictly required to use a GraphQL API it seems worth tackling separately, if at all.
I don't love the current implementation's handling for unwrapping querys from files, especially the fatalError part, but realistically I think you want to catch any potentially errors well before the app gets into the hands of users, so maybe it's okay. I think we should lean on encouraging users using a tool like Postman to manage generating, testing and storing .graphql queries rather than writing them directly into Xcode for this reason.
As always, naming things is hard and I'm open to any suggestions that might make things clearer
For #96
Bumps version number to 0.11.0, though all changes are additive
Also fixes a small issue when unwrapping
Request.pathwhere an empty string would cause the request to fail unintentionally.While we actually kind of support GraphQL requests right out of the box, because really they're just weird POST requests, this PR attempts to lay the groundwork for some better support.
One of the big advantages of GraphQL is that you can know the entire schema ahead of time, and can potentially use that to save yourself a lot of time by generating things like inputs and output models ahead of time.
This is obviously a lot more work, and involves generating code and compile time, so since it's not strictly required to use a GraphQL API it seems worth tackling separately, if at all.
I don't love the current implementation's handling for unwrapping querys from files, especially the
fatalErrorpart, but realistically I think you want to catch any potentially errors well before the app gets into the hands of users, so maybe it's okay. I think we should lean on encouraging users using a tool like Postman to manage generating, testing and storing.graphqlqueries rather than writing them directly into Xcode for this reason.As always, naming things is hard and I'm open to any suggestions that might make things clearer