💝 Event receiver & stream via Server-Sent Events

[cardil]

Fixes SRVCOM-2287

Changes

• 💝 Event receiver & stream via server-sent events
• 🎁 React+Typescript frontend app
• 🧹 Simplified build

Explanation

The UI was extracted from both backends (they had used server-side rendering before), into a separate React app written in Typescript.

This React app is now built into a set of static files, which are packaged as a webjar for easy consumption on both backends (especially in the Java one). The frontend application, of course, can be started in development mode, either running on stubs, or connecting to the real backend.

Both backends have the event receiver implemented at POST /events. Both backends have the Server-Sent Events (SSE) endpoint implemented at GET /events. You can connect to it in streaming mode using tools like HTTPie (the connection will be left hanging, and any new events will be delivered to the client, CloudEvents are encoded as structured):

$ http :8080/events
HTTP/1.1 200 OK
Content-Type: text/event-stream
X-SSE-Content-Type: application/cloudevents+json
transfer-encoding: chunked

data:{
    "data": {
        "greeting": "Welcome",
        "number": 94,
        "who": "Developer82"
    },
    "datacontenttype": "application/json",
    "id": "38d021ba-db7b-67df-98e9-e1a3be37ca53",
    "source": "//devdata",
    "specversion": "1.0",
    "time": "2023-02-10T07:33:55+01:00",
    "type": "com.redhat.openshift.knative.showcase.hello.Hello"
}

The React frontend have also the dedicated UI component that connects to that event stream and presents it in a nice table:

Related issues

During the developments I've stumbled on a number of upstream issues, I needed to work around:

• Can't resolve 'http' error when using on React app cloudevents/sdk-javascript#534
• SseUtil unexpectedly stores headers in Serialisers.EMPTY_MULTI_MAP quarkusio/quarkus#31559
• RESTEasy Reactive SSE doesn't provide method annotations, nor actual headers to MessageBodyWriter quarkusio/quarkus#31587
• [restful-ws] Allow configuring default writer encoding for CloudEventsProvider cloudevents/sdk-java#533
• [restful-ws] Doesn't work with Quarkus Reactive in Native mode cloudevents/sdk-java#546

/kind enhancement

[cardil]

A self-review 😼

[cardil]

/cc @mgencur
/cc @jrangelramos
/cc @pierDipi
/cc @rhuss
/cc @matzew

[mgencur]

Hi @cardil , thanks for implementing the new features. I have only tested one part of it (the frontend which sends evens repeatedly) but I have a left a number of comments.

This application is named "OpenShift Knative Showcase" or "Knative Showcase" and it mentions Knative in many places. It also says it "showcase the Knative features".
For me, this application shows sending and receiving CloudEvents in a nice way. It can be used side-by-side with Knative Eventing to show events that are sent/received. But it doesn't have/show Knative features. So, mentioning "Knative" all over the place is misleading at this point.
I don't know what will be the future of this application. Do you have any plans for functionality that would demonstrate Knative features?
Thanks

[cardil]

I have only tested one part of it (the frontend which sends evens repeatedly)

Well, this frontend app, by in development mode, by default work on stubs. Those stubs simulate receiving events continuously. But, that's just a simulation.

This application is named "OpenShift Knative Showcase" or "Knative Showcase" and it mentions Knative in many places. It also says it "showcase the Knative features". For me, this application shows sending and receiving CloudEvents in a nice way. It can be used side-by-side with Knative Eventing to show events that are sent/received. But it doesn't have/show Knative features. So, mentioning "Knative" all over the place is misleading at this point.

The eventing bits (event receive, and streaming) are just coming in this PR. This app already has a number of features that's helpful to showcase Serving functionality.

Have you seen the README? Especially after the changes in this PR (a little cleanup). There are a couple of things that help showcase Serving:

• fast app boot (requirement for Serving scale from zero),
• support for $PORT (automatically set by Serving),
• support for $DELAY (to help showcase scaling),
• support for $GREET (to help showcase traffic distribution, as different revisions will have different output)

Also, already in, is the sending of the event to the $K_SINK, which obviously helps to showcase Eventing, especially the SinkBinding.

So, I think this app already helps showcase Knative features, and this PR only adds to that.

[mgencur]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cardil, mgencur

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [cardil,mgencur]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cardil]

Thanks, @mgencur, for the review!

I'll create issues and link here:

• Make README clear and understandable #13
• Consider moving the K8x manifest examples to the top folder #14
• Received events should be logged in human-readable form #15
• Event streaming shouldn't be limited to the number of threads in executor service #16
• Container images should be built by makefiles, and mostly on amd64 platform #17
• Express app doesn't support event collector at POST / #18
• Missed events in the startup of the React app #19