Allow GraphQL endpoint to be conditionally included. Closes #209

[zachfeldman]

Summary

Adds a Rails configuration option to include /graphql only if it is true.

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[zachfeldman]

@waiting-for-dev could you take a glance at this when you get a chance? Thank you!

[waiting-for-dev]

Hey @zachfeldman, many thanks for sending this change request. I'd like to understand the context here better. Given that the endpoint will only be made available when you install the extension into your project, in which situation would you like to turn it off? Is the idea to have the configuration act like a feature flag? I can think of two approaches that don't involve moving the feature flag upstream:

• You can have gem "solidus_graphql_api", require: false in your Gemfile. Probably not helpful as it doesn't happen at runtime, but as I don't know your use case yet, maybe it's worth pointing out.
• As we're doing with the new Stripe extension or the new admin, instead of monkey-patching the core routes, we can have the route defined in SolidusGraphqlApi::Engine and write the mount line to the application's config/route when running bin/rails g solidus_graphql_api:install. We can say that's our new recommendation for extensions, and that would allow you to change the code in any way you need.

What do you think?

[zachfeldman]

Hey @waiting-for-dev thanks for the fast response here!

The use case is that we're testing GraphQL in development, but also in our Review Apps and Staging env on Heroku that are "production" environments. So just putting them in a specific group in the Gemfile doesn't really cut it.

We don't want to turn it on in prod yet because we haven't analyzed the security implications of it, nor is our new front end ready for prime time quite yet.

I think option 2 would work really well, and I know that's how you're doing it with the new admin. If you are down with that based on the above, I can change my PR to do this instead and also edit the README!

[waiting-for-dev]

I think option 2 would work really well, and I know that's how you're doing it with the new admin. If you are down with that based on the above, I can change my PR to do this instead and also edit the README!

That would be awesome, @zachfeldman. Looking forward to it. Please, let me know if you need any help.

[zachfeldman]

@waiting-for-dev I copied from the main Solidus repo and this seems to work locally for me when using this branch and running the generator - how's that?

[waiting-for-dev]

Hey, @zachfeldman, it looks like the GraphQL controller is not found. That's probably because we're not mounting the engine into the host application. We need to inject something like the following in the host routes:

mount SolidusGraphqlApi::Engine, at: '/graphql'

And define the route in the engine config/routes.rb file.

I tried locally, but still it didn't work. I run out of time today, but I'll try again tomorrow unless you're quicker than me 🙂

[zachfeldman]

@waiting-for-dev this commit seems to do it right for me! LMK if you have any opinions about the URL structure or the class name for routing, glad to adjust.

[zachfeldman]

@waiting-for-dev updated!

[waiting-for-dev]

Thanks a lot for working on this, @zachfeldman! ❤️