Add ShopifyAPI::Context.host to allow for localhost support

[nelsonwittwer]

Description

The default CLI is to use localhost for OAuth instead of using a tunnel 🎉 . We have an assumption throughout the codebase that the https scheme is used. In order to get localhost to work with this gem, we need remove that assumption.

This adds the following:

• Adds the ShopifyAPI::Context.host which will include the scheme, name, and port of the host app
• Adds the ShopifyAPI::Context.host_scheme helper to return http or https for the few edge cases when we'd need it

The host is set by the configuration, ENV variable, or deduced from host_name.

This will work with backward compatibility and won't need updated configs to work. We will update shopify_app's generated config to include host.

How has this been tested?

Please, describe the tests that you ran to verify your changes.

I'll be developing another PR in the shopify_app gem in tandem with this. I'll ensure that I can get localhost as well as tunnel with https to work with this gem.

Checklist:

• My commit message follow the pattern described in here
• I have performed a self-review of my own code.
• I have added tests that prove my fix is effective or that my feature works.
• I have updated the project documentation.
• I have added a changelog line.

[paulomarg]

Just nits and questions!

[paulomarg]

Would it make sense to store host as a URI to make it easier to handle later?

[andyw8]

👍

I read some advice a while ago which said that primitives should be only on the boundaries of your system, e.g. where you're reading or outputting data, but within the app boundaries you should aim to work with richer types. Can't say I've managed to fully do that, but I like the concept.

[nelsonwittwer]

Ya great callout, in an earlier version I had exposed the URI object in fact. When building links with that URI object I found myself needing to compose the host scheme, host, custom port, and path it and it became way too verbose. Since host has been used to encapsulate all of those ideas it seemed to be a better tradeoff for simplicity.

In this case I'm using the URI parse method so I didn't need to write regex to be a little more readable.

[andyw8]

All looks good in terms of code – I think some of the names could be more precise, but I understand we may locked into some things for backwards compatibility.

[andyw8]

Hmm, the naming doesn't feel right here, I wouldn't expect host to include a protocol.

[andyw8]

(maybe call it host_with_scheme?)

[nelsonwittwer]

I agree, the naming here isn't as precise as I'd hope. We use host name to imply the needed scheme. For that consistency I think we should leave it as is :(

[resistorsoftware]

This is busted in my life. Here is why. I use Puma Dev to name my localhost. So I have a name and port. It works! So to Shopify App, my App is configured as https://myapp.test and that works fine, as under the hood, this gets converted to an ngrok tunnel and away we go. But you cannot use this host for webhooks. Nope. For webhooks to work you need to provide an actual reachable URI which is https://myapp.ngrok.io

Unfortunately, this change with webhooks is now writing all my localhost webhooks as https://myapp.test//webooks/app_uninstalled as an example, which is not reachable. So I am screwed now when my older working pattern is used with this new code.

Why is it this way? I dunno. But it is. Is there a way to register a webhook and not have it play havoc with the provided callback URL?

In the Shopify App if I use this:

 config.webhooks = [
    {topic: "app/uninstalled", path: "webhooks/app_uninstalled"}
  ]

The webhook I find registered in the store is https://myapp.test/webhooks/app_uninstalled which is unreachable. That is because my host is indeed myapp.test. But the reality is, webhooks work perfect when I use a manual setup and set the callback URL to be https://myapp.ngrok.io

This is frustrating.