Eventstreams #206
Merged
Eventstreams #206
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…implementation work
…otocol builders instead)
…eric builder base
Add support for all Http2 options.
mullermp
reviewed
Jul 31, 2024
| module EventStream | ||
|
|
||
| # EventStreamHandler for the the {Client#start_event_stream} operation. | ||
| # Register event handlers using the +#on_<event_name>+ methods |
There was a problem hiding this comment.
Yeah, it needs markup markdown but I think maybe we don't care to do that.
| end | ||
| end | ||
|
|
||
| module EventStream |
There was a problem hiding this comment.
Up to you, but if the shapes are guaranteed to not clash, I don't see a need for the nesting.
| @@ -225,6 +242,50 @@ private void renderOperation(RubyCodeWriter writer, OperationShape operation) { | |||
| .closeBlock("end"); | |||
| } | |||
|
|
|||
| private void renderEventStreamOperation( | |||
There was a problem hiding this comment.
Yeah, that makes sense. As long as it's somewhat consistent across all things (builders, parsers, etc).
| module Hearth | ||
| module EventStream | ||
| # Represents a HeaderValue in an EventStream::Message. | ||
| class HeaderValue |
There was a problem hiding this comment.
It's fine to use header in that case, just making sure the naming is correct
| # @param input | ||
| # @param context | ||
| # @return [Output | EventStream::AsyncOutput] | ||
| def call(input, context) |
| # frozen_string_literal: true | ||
|
|
||
| module Hearth | ||
| module EventStream |
…uge method). Refactor in both builders and parsers.
mullermp
approved these changes
Aug 1, 2024
…e only the sign method and expect it to return the signature)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Add support for event streams.
Changes in Hearth
Changes in Codegen
Testing
TODO
Event Stream Implementation Details
Output events
The http2 client gets an Http2 connection from the pool. An Http2 connection may support multiple streams.
Http2 connections have an independent thread which reads from the connection and writes the data to the Http/2 (the gems) http2 client which automaticaly will send the data to the correct stream.
Handlers on the stream will write that data to the response body.
The response body is set to an EventStream decoder (which has a write method and takes the data). This works from both Http1 and Http2.
The Decoder uses a MessageDecoder (these are protocol specific, but currently only one implementation.) and for each message in the chunk it will call
the user configured Event Handler's emit method.
The EventHandler will parse the message and based on headers (eg type), will call different parsing methods. For modeled events, these are
the specific type's code generated Parsers in the Parsers::EventStream module.
Once parsed, user's registered event handlers for the specific type are called with the event.
All of this is done in the non-main thread.
Input Events
For h2/bi directional streaming operations with input events, the operation returns an operation specific AsyncOutput. That
output object has "signal_" methods for each event type. That method uses a code generated builder to build a Message from the params.
The message is then encoded and signed by the Encoder. The output object has a reference to the EventStream encoder.
The Encoder keeps a prior_signature state that is used to keep track of event signing state. The output object also has a reference to the stream.
the encoded and signed message is then sent to the stream.
The async output also allows controlling the state of the stream - either with join or kill.
The event streams handlers middleware creates the Encoder and sets it to the body of the request. When the streams are established in
the http2 client the stream is set on the body (if it responds to it).
Initial requests in Http2 event streams:
For protocols that support http traits (eg httpHeader) - then they MUST NOT have members serialized to the body. These requests are easy,
the headers (and uri path/query ect) are sent when connecting.
For RPC protocols (no http trait support), then we need to send the initial request as an event message. When the Encoder is created, we take the initial body (which the operation builder must serialize as a Message) and create a read method on the encoder. The http2 client will then read data from the Encoder and send it immediatly after the header and before any other user signaled events. This also ensures that signing state is kept in the encoder correctly.
Important Codegen decisions/hooks:
ProtocolGenerators need to return the correct transport to use for event streams. For some protocols this may be based on properties of the trait (eg, rpcv2 and most aws protocols define these) - so these methods may need to inspect the model.
We have a new EventStream module that has the generated Handlers (one per operation with event stream outputs) and AsyncOutput classes (one per operation with event inputs).
Builders and Parsers each have a sub EventStream module with the builders/parses for events. These may use other parsers in the module.
Most of the building and parsing of events is protocol agnostic (ie, setting type headers, handling @eventHeaders trait, determining if its implicit/explicit payload, ect) so there is a lot of logic in the base classes, with limited abstract methods that protocls msut implement. However, its designed to be highly extensibe and all of the default methods are protected and could be overwritten if needed.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.