-
Notifications
You must be signed in to change notification settings - Fork 474
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ApiVersion coercion_modes and fetch_known_versions from Shopify #600
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a couple questions but no show stoppers
@versions = {} | ||
def latest_stable_version | ||
warn( | ||
'[DEPRECATED] ShopifyAPI::ApiVersion.latest_stable_version is deprecated and will be removed in a future version.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a recommended way to do this same thing after this method is removed? Is this just discouraged going forward?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we wanted to discourage anyone trying to set the version to the latest version automatically since it's likely to break apps. Bumping to the latest version should hopefully be intentional.
It can still be computed however since each ApiVersion has a latest_supported
attribute, its just a little more work.
ShopifyAPI::Meta.admin_versions.find(&:latest_supported?)
works at the expense of another api call, but we could also cache the versions in Meta.admin_versions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
latest_supported_version is used by the ShopifyApp gem https://github.com/Shopify/shopify_app/blob/0900ddcb2f268f6efe3e184739ee83eeab3a0020/lib/generators/shopify_app/install/install_generator.rb#L12 to run the generators.
It can now use ShopifyAPI::Meta.admin_versions.find(&:latest_supported?)
to find that info.
updated per @alexaitken 's comments on slack. ApiVersion now supports two coercion modes. The default will just accept whatever handle you give it and leave it to the server to deal with any invalid versions, probably what you would want in production since you should have everything tested already. The second stricter mode will not allow you to set any version that is not pre-defined. Setting Little more flexibility for different developers for different environments. Readme still needs to be updated and this needs a rebase |
a17c1f5
to
18ac855
Compare
Just pushed an update and rebased against master. I made When using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor comments, and the README needs updating, but approach LGTM.
|
||
def self.define_version(version) | ||
@versions ||= {} | ||
def define_known_versions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might call this fetch_known_versions
to be explicit that it involves a remote lookup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think I had that at first and at some point changed it back to minimize the number of changes or something? 🤔 It sorta made sense at the time, but I think you're right that fetch is a better choice.
Not sure if I should just rename this or alias it and issue a depreciation warning
lib/shopify_api/api_version.rb
Outdated
|
||
@versions[version.name] = version | ||
end | ||
def clear_defined_versions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clear_known_versions
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same concern as define/fetch_known_versions
02b828a
to
66e9427
Compare
README.md
Outdated
ShopifyAPI::ApiVersion.fetch_known_versions | ||
``` | ||
|
||
Known versions are fetched and cached from https://app.shopify.com/services/apis.json. Trying to use a version outside this set will raise an error. To switch back to naïve lookup and create a version if its not found, call `ShopifyAPI::ApiVersion.version_lookup_mode = :define_on_unknown` (this is the default mode). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should maybe mention that this set currently-supported APIs only
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well it includes release candidate as well which is unsupported.
Just pushed an update that cleans up a few things. I suppose this is a good time to summarize the whole change again. New
ChangedShopifyAPI::ApiVersionClass methods
Instance Methods
Misc
DeprecatedApiVersion
Removed
|
66e9427
to
815e7e0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach is great, after living with API Versioning for a while I think it's clear we should leave it up to developers to define which versions they're using.
Related to this, I'm not sure developers will use predefined_only
, as its a more involved setup and extra request when they could just set and forget. I'm okay with it being available though, as it could be useful in our tooling and shopify_app
s generators as discussed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can close #603 and go with this setup.
should this be a breaking change that requires a major version bump @nwtn @tylerball
sweet. I'll fix these merge conflicts and 🚢 |
aa71979
to
1b9b8de
Compare
fixed merge conflicts and rebased after merging #605. I added a new commit to add more methods to ApiVersion::NullVersion so it raises a more useful error if you try to call any of the new methods added to ApiVersion (like handle, display_name, verified?, etc). |
minor renames
method renames and minior refactor rebase cleanup
1b9b8de
to
0ee8d7e
Compare
Forgot about this on friday. Rebased again and it should be good to merge as soon as CI is done. @tylerball did we want to release this as version 8.0.0? Is there anything else we need to include in a major version bump? |
This PR allows us to dynamically define api_versions based on the response from https://app.shopify.com/services/apis.json
This removes the need to manually updated the gem every time a new version is released or set to end of life.
When the gem is required, we define a set of known versions from the unauthenticated
services/apis.json
endpoint and everything behaves more or less like it did before. If an unknown version is attempted to be set (ie as of today,2020-04
ortaco-42
) an UnknownVersion error is raised with all known versions as message.If for some reason the known_version_set cannot be initialized at start, then we default to assuming the version is valid, and rely on the server to handle the request and return an error if necessary. Developers can retry defining the version set by calling
ShopifyAPI::ApiVersion.define_known_versions
at anytime. Any version that was fetched from the server will havepersisted?
return true, and any on the fly version instances would return false.ApiVersion attributes were solidified internally at shopify I think after version support was added to the gem, so I also deprecated and aliased methods like
#name
and#stable?
to#handle
and#supported?