-
Notifications
You must be signed in to change notification settings - Fork 5
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
ETOS SSE v2alpha #91
ETOS SSE v2alpha #91
Conversation
I recommend reviewing from this commit, to start: 28adb70 |
6227d24
to
ce25c02
Compare
Rebased. Will add tests as well |
} | ||
|
||
// TestSSECreateStream tests that the CreateStream endpoint works. | ||
// Does not test the authorization middleware! |
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 what the point of this comment is? If we going forward want to incorporate middleware testing in this test, then I'd rather the comment said this with a TODO included and/or a corresponding issue.
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.
It's just a warning so that we don't falsely believe that authorization is tested here.
Applicable Issues
Not applicable, but I based this change on #89 since that made my config management easier.
Description of the Change
Add a SSE v2alpha.
SSE v2 will utilize RabbitMQ streams instead of polling the log listener container of the suite runner.
SSE v2 will have authentication for starting up new streams.
Added a new authorization service for creating and verifying tokens. Added these to the SSE v2alpha.
Added a new service for generating tokens. Shall be used by the ETOS client to generate a token to use for streaming SSE.
The authorization service and key service shall be used in the future for ETOS APIs.
I am aware of a few unfinished parts. This is intentional as I want to get eyes on this right now before continuing.
Alternate Designs
There are many. Considered kafka for a bit, but since we are already using RabbitMQ that seemed like a better choice.
Considered doing something that could listen to RabbitMQ and store messages in files that could be served to users. The complexity of this service was deemed too high.
I made the choice of creating one stream per SSE connection instead of having a single ETOS stream where we could filter out messages. According to "The Internet(tm)" RabbitMQ deals better with many small streams rather than one large and we hade some difficulty getting "Last-Event-ID" to work properly using a single stream.
Possible Drawbacks
We have not yet created a service for dealing with stream retention. Right now we will create all streams and never delete them. This must be fixed before v2.
Sign-off
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Signed-off-by: Tobias Persson [email protected]