Handling multiple schema, or multiply-authed same schema

[halostatue]

I’m really quite impressed with what I see of Maple, and I think that it’s a nicer experience than that provided by Neuron (especially with the generated documentation). However, there are some issues I see with the usability and extensibility of Maple, particularly in a large application where you may have reasons to connect to more than one GraphQL API or to construct to the same GraphQL API multiple times with different configuration parameters (e.g., bearer tokens or other identifiers).

We are building an application which will need to be able to connect to the Shopify Storefront GraphQL API for various users, and the way that Maple works prevents us from being able to do this. It is possible to do this with Neuron, but it requires that you have a separate process for each instance of an API.

As such, I’m getting ready to make a number of changes to Maple and I will be opening a PR for this when complete (it will probably be a single PR as I do not currently have the luxury of the time it would take to split this into smaller PRs, even if it can be). Note that I will implement these changes in a way that warns of the incompatibilities without entirely removing them in this version, if at all possible. Also, it is preferable that warnings be compile-time rather than run-time, so I will strive for that.

As of right now, here are my plans:

1. Generate the GraphQL code on use Maple instead of having to call generate_graphql_functions/0. When generate_graphql_functions/0 is called, a warning will be emitted.
2. Provide parameters for Maple code generation as the parameter to use Maple, options. If the values are not provided, emit a warning and pull them as is from Application.get_env/3.
3. If __MODULE__.Config already exists, emit a warning. Generate the provided parameters into module attributes (and functions) into __MODULE__.Config (or __MODULE__.AutoConfig if __MODULE__.Config already exists).
4. Change build_type_structs to accept another value, :module, which will generate them into __MODULE__.Types instead of Maple.Types. This should become the default behaviour.
5. Generate each generated function with an additional parameter, client (so /1 functions become /2, etc.) and provide a default value of nil. execute/2 will become execute/3 so that a client may be provided into each function for multi-tenancy use.

This last is probably backwards-incompatible as it means changing the Maple.Behaviours.HttpAdapter callbacks, but the last item is also the most important, as we must support more than one Shopify client in our application.

I realize this is somewhat out of the blue, and you may prefer not to take Maple in this direction; if this is the case, I will happily fork Maple and move forward with my changes independently of the direction you wish to take Maple. However, I think that these will be better changes for Maple overall, and I encourage you to consider them when I submit the PR (I have to do most of these changes in the next day or so, but may not have the PR ready for a week or so after that because of our delivery timeframe).

The only thing that I know that I will not be able to handle well with our changes, mostly because I do not currently have a need for them, is the subscription/websocket support. I am hopeful that the changes for those will be pretty easy, but it isn’t something I need right this moment.

[maxneuvians]

Hi @halostatue,

Your contribution would be more than welcome - the things you mention are problems I am aware of. Some versions back I did have a mechanism to pass the different arguments directly to the macro, but I changed that because my use case was satisfied with a global config. Also I was giving a demo at the Ottawa Elixir Meetup and wanted to get people excited about simplicity. :)

However, my next use case is actually also for a shopify app - so you are actually solving a problem for me.

Looking forward to the PR.

Thanks
Max

[halostatue]

Ok. As I get things closer, I will probably open a PR as a WIP so you can see the direction I am taking. I have the bits necessary to pass the configuration via use, and the tests still pass.

[maxneuvians]

Awesome!

[utf4]

Hey guys, Any news for the different configurations for one API (Shopify). I am building a Shopify app and I am in need of making queries for different shops (different shop URLs as well as auth token).

[maxneuvians]

Hi,
In the git version there is a way to set auth tokens using an additional header option:

https://github.com/maxneuvians/maple/blob/master/lib/maple/clients/http.ex#L52

it looks something like this:

query = Client.user("firstName,lastName}", [headers: conn.assigns.current_user.auth_header])

To make the URL dynamic you would need to be able to change this:

https://github.com/maxneuvians/maple/blob/master/lib/maple/clients/http.ex#L57

Which is also something you could potential configure per query, but the thing is that it generates all the functions from the schema from one URL at compile time, so if your compile time URL has different functions to the run time URL you will be in trouble.