-
Notifications
You must be signed in to change notification settings - Fork 7
Use plugins per protocol approach #311
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
Changes from all commits
1245723
dff6ac1
5a2ce9f
a373ba2
61ac1e6
ef73fd6
12c1c78
522b8a2
e978974
d77a73f
74ff061
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
# frozen_string_literal: true | ||
|
||
require_relative '../rpc_v2_cbor/error_handler' | ||
require_relative '../rpc_v2_cbor/handler' | ||
require_relative '../stubbing/rpc_v2_cbor' | ||
|
||
module Smithy | ||
module Client | ||
module Plugins | ||
# @api private | ||
class RpcV2Cbor < Plugin | ||
# @api private | ||
option(:codec) { CBOR::Codec.new } | ||
# @api private | ||
option(:stubber) { Stubbing::RpcV2Cbor.new } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this override other protocol plugins? or do we have to do something like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The idea would be the default/winning protocol would always define a stubber config that knows how to stub. I am open to other ideas. In v3 we had all of the classes in a switch case but requires core/client to know about all protocols. |
||
|
||
handler(Client::RpcV2Cbor::Handler) | ||
handler(Client::RpcV2Cbor::ErrorHandler, step: :sign) | ||
end | ||
end | ||
end | ||
end |
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
# frozen_string_literal: true | ||
|
||
module Smithy | ||
module Client | ||
module Stubbing | ||
# @api private | ||
class NullProtocol | ||
def stub_data(_config, _operation, _data) | ||
HTTP::Response.new | ||
end | ||
|
||
def stub_error(_config, _error_code) | ||
HTTP::Response.new | ||
end | ||
end | ||
end | ||
end | ||
end |
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.
(not sure where to put this so leaving comments here)
What is the CX to swap protocols? How do they fall back on the "default" protocol? You should include these examples in the PR description. If we are going with this approach, we should have a plan outlined to accommodate it.
I don't recall if we plan to load all the supported protocol plugins from the get-go or just have customers
.remove_plugin
and.add_plugin
....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.
Also - I think you shared this offline but PR description should include ways to mitigate situations where we DO need to make changes to the response body prior to parsing. For historical context.
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.
The CX is to do add plugin and remove plugin. I'm also extremely skeptical that customers will care about this functionality at all as a normal client configurable, so I think any "friction" is not a huge concern for us. From my experience, customers just want the service to function, and we should by default use something standard and performant. I don't think we care to really outline how to do all this unless there is reason to, like with an operational event.