Send Review Comment to Broker

Image

The main dashboard of our bookstore features a comment section where readers can view comments from others and submit their own through a text input area. While the process appears straightforward - click a button, and the comment is posted - the underlying mechanism is powered by a robust event-driven architecture.

What Knative features will we learn about?

  • Knative Eventing Broker
  • Knative Eventing Sink
  • Knative SinkBinding

What does the deliverable look like?

Image

In simple words: after the user clicks on the submit button in the frontend, the comment will show up in the event-display service.

Implementation

Step 0: Know the basics

Image

In the world of microservices and REST APIs, we often refer to requests as the primary method of communication between services. However, in an event-driven architecture, the smallest unit is an event. Knative Eventing adheres to the CloudEvents specification, making it essential to understand this concept before moving forward. Learn more about CloudEvents here before proceeding!

Step 1: Understand Book Review Service

Image

The book review service is our Node.js API server, playing a crucial role in our event-driven architecture. It’s essential to understand how it operates, as it receives events and processes them appropriately.

Image

Key Concepts: Broker and SinkBinding

Before we dive into the code, let’s clarify two important concepts:

  • Broker: Acts as the central point in the event-driven architecture, routing events to the correct destinations.
  • SinkBinding: This Knative Eventing component automatically injects the Broker’s address into the environment variable K_SINK, ensuring that the Node.js server always has the correct address without manual updates.

You will get a deeper understanding along the way.

Image

Let’s examine the node-server/index.js file, starting with the /add function. When a user submits a comment through the frontend, it is first received by this endpoint.

  1. app.post('/add', async (req, res) => {
  2.   try {
  3.     const receivedEvent = HTTP.toEvent({headers: req.headers, body: req.body});
  4.     const brokerURI = process.env.K_SINK;
  6.     if (receivedEvent.type === 'new-review-comment') {
  7.       const response = await fetch(brokerURI, {
  8.         method: 'POST',
  9.         headers: {
  10.           'Content-Type': 'application/cloudevents+json',
  11.           'ce-specversion': receivedEvent.specversion,
  12.           'ce-type': receivedEvent.type,
  13.           'ce-source': receivedEvent.source,
  14.           'ce-id': receivedEvent.id,
  15.         },
  16.         body: JSON.stringify(receivedEvent.data),
  17.       });
  18.     }
  19.   } catch (err) {
  20.     console.error(err);
  21.   }
  22. });

Receiving Events: The /add endpoint receives events from the frontend. It uses CloudEvents’ SDK to convert the incoming request into a CloudEvent object:

  1. const receivedEvent = HTTP.toEvent({headers: req.headers, body: req.body});

Determining Broker Address: The Broker’s address is dynamically assigned in the cluster. The Node.js server retrieves this address from the environment variable K_SINK:

  1. const brokerURI = process.env.K_SINK;

You may wonder who told the environment variable about the address? That’s Knative SinkBinding.

Event Filtering: The service checks the event type. If it’s a new-review-comment, it forwards the event to the Broker:

  1. if (receivedEvent.type === 'new-review-comment') {
  2.   // logic that forwards the event, see below
  3. }

Forwarding Events Logic: The event is forwarded to the Broker with the appropriate CloudEvent headers:

  1. const response = await fetch(brokerURI, {
  2.   method: 'POST',
  3.   headers: {
  4.     'Content-Type': 'application/cloudevents+json',
  5.     'ce-specversion': receivedEvent.specversion,
  6.     'ce-type': receivedEvent.type,
  7.     'ce-source': receivedEvent.source,
  8.     'ce-id': receivedEvent.id,
  9.   },
  10.   body: JSON.stringify(receivedEvent.data),
  11. });

Image

Exploring Other Functions

The Node.js server contains other functions that follow a similar pattern, with detailed comments explaining their functionality:

  • /insert: Receives CloudEvents and inserts the payload into the PostgreSQL database.
  • /comment: Creates a WebSocket connection with the frontend to transport comments from the database.

Step 2: Create Broker

Image

The Broker acts as a router in your event-driven application, receiving events and routing them to the correct destination.

  • 1: Create a new YAML file named node-server/config/200-broker.yaml and add the following content:

node-server/config/200-broker.yaml

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Broker
  3. metadata:
  4.     name: bookstore-broker
  • 2: Apply the YAML file:
  1. kubectl apply -f node-server/config/200-broker.yaml

You will see the following output:

  1. broker.eventing.knative.dev/bookstore-broker created

Alternatively, use the Knative CLI kn to create the Broker:

  1. kn broker create bookstore-broker

You will see the following output:

  1. Broker 'bookstore-broker' successfully created in namespace 'default'.

Verify

Running the following command to list the Brokers:

  1. kubectl get brokers

You should see the Broker bookstore-broker with READY status as True.

  1. NAME               URL                                                                                 AGE     READY   REASON
  2. bookstore-broker   http://broker-ingress.knative-eventing.svc.cluster.local/default/bookstore-broker   7m30s   True    
  3. ``` Troubleshooting
  5. If there are issues, use the following command to diagnose:

kubectl describe broker bookstore-broker

  2. ### **Step 3: Create a SinkBinding between the Node.js server and Broker**
  4. ![Image](/projects/knative-1.15-en/99858f748aca582c1817981ab23b37f3.png)
  6. Hardcoding URLs to connect with Kubernetes services in your application can be limiting and inflexible. A SinkBinding dynamically injects the URL of the Kubernetes service into your application.
  8. Learn more about SinkBinding [here]($ff39f04f5a00adab.md) and the [spec schema]($5e26a03e3ec0beff.md)!
  10. **Create a SinkBinding:**
  12. -   1: Create a new YAML file named `node-server/config/300-sinkbinding.yaml` and add the following content:
  14. _node-server/config/300-sinkbinding.yaml_

apiVersion: sources.knative.dev/v1 kind: SinkBinding metadata: name: node-sinkbinding spec: subject: apiVersion: apps/v1 kind: Deployment selector: matchLabels: app: node-server sink: # In this case, the sink is our Broker, which is the eventing service that will receive the events ref: apiVersion: eventing.knative.dev/v1 kind: Broker name: bookstore-broker

  2. -   2: Apply the YAML file:

kubectl apply -f node-server/config/300-sinkbinding.yaml

  2. You will see the following output:

sinkbinding.sources.knative.dev/node-sinkbinding created

  2. Verify
  4. Running the following command to list the sinkbindings:

kubectl get sinkbindings

  2. You should see the sinkbinding `node-sinkbinding` with `READY` status as `True`.

NAME SINK AGE READY REASON node-sinkbinding http://broker-ingress.knative-eventing.svc.cluster.local/default/bookstore-broker 2m43s True 

  2. ### **Step 4: Create event-display service**
  4. ![Image](/projects/knative-1.15-en/9231a6b8b4b99d49e27d17544d0c6235.png)
  6. Event display is a debugging tool in Knative Eventing that allows you to use it as a temporary destination (a.k.a sink) for your event to go.
  8. **Create an Event Display Service:**
  10. -   1: Create a new YAML file named `node-server/config/100-event-display.yaml` and add the following content:
  12. _node-server/config/100-event-display.yaml_

apiVersion: apps/v1 kind: Deployment metadata: name: event-display spec: replicas: 1 selector: matchLabels: app: event-display template: metadata: labels: app: event-display spec: containers:

  1.     - name: event-display
  2.       image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display
  3.       ports:
  4.         - containerPort: 8080

apiVersion: v1 kind: Service metadata: name: event-display spec: selector: app: event-display ports:

  1. - protocol: TCP
  2.   port: 80
  3.   targetPort: 8080

type: ClusterIP

  2. -   2: Apply the YAML file:

kubectl apply -f node-server/config/100-event-display.yaml

  2. You will see the following output:

deployment.apps/event-display created service/event-display created

  2. Verify
  4. Running the following command to list the pods:

kubectl get pods

  2. You should see the pod `event-display-XXXXXXX-XXXXX` in "Running" status.

NAME READY STATUS RESTARTS AGE bookstore-frontend-7b879ffb78-9bln6 1/1 Running 0 91m event-display-55967c745d-bxrgh 1/1 Running 0 4m44s node-server-644795d698-r9zlr 1/1 Running 0 4m43s

  2. ### **Step 5: Create a Trigger that connects the Broker and event display**
  4. ![Image](/projects/knative-1.15-en/ee52c5320dd2fcb85cddb5ed1b4ee580.png)
  6. A Trigger is able to forward the event to the correct destination based on the [CloudEvent's attributes]($ac05bc7e59a9782a.md#:~:text=Knative%20Eventing%20uses%20standard%20HTTP%20POST%20requests%20to%20send%20and%20receive%20events%20between%20event%20producers%20and%20sinks.%20These%20events%20conform%20to%20the%20CloudEvents%20specifications%2C%20which%20enables%20creating%2C%20parsing%2C%20sending%2C%20and%20receiving%20events%20in%20any%20programming%20language.). It is the connector between the Broker and the event destination.
  8. A Filter in the Trigger will **filter the events based on the filter condition**. You will specify your filter condition in the Trigger’s YAML file. **If no filter is specified, the Trigger will forward all the events that the Broker received.**
  10. ![Image](/projects/knative-1.15-en/935a3c195869fd9483de51a5093df077.png)
  12. There is also a concept called [Channel]($40c5ba33df0435f1.md) in Knative, and generally speaking, you can treat Broker & Trigger without filter the same as Channel & Subscription.
  14. Learn more about Broker & Trigger [here]($2797fa15f0d5cd00.md)!
  16. **Create a Trigger:**
  18. ![Image](/projects/knative-1.15-en/af19a212b3a85a886c6778057cb97e7a.png)
  20. Here we are creating a Trigger that will send all the events to event-display.
  22. ![Image](/projects/knative-1.15-en/d5b5320c9268cf2a081c3b77df62e797.png)
  24. -   1: Create a new YAML file named `node-server/config/200-log-trigger.yaml` and add the following content:
  26. _node-server/config/200-log-trigger.yaml_

This Trigger subscribes to the Broker and will forward all the events that it received to event-display.

apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: name: log-trigger spec: broker: bookstore-broker subscriber: ref: apiVersion: v1 kind: Service name: event-display

  2. -   2: Apply the YAML file:

kubectl apply -f node-server/config/200-log-trigger.yaml

  2. You will see the following output:

trigger.eventing.knative.dev/log-trigger created

  2. Verify
  4. Running the following command to list the Triggers:

kubectl get triggers

  2. The Trigger `log-trigger` should have `READY` status as `True`.

NAME BROKER SUBSCRIBER_URI AGE READY REASON log-trigger bookstore-broker http://event-display.default.svc.cluster.local 6m2s True 

  2. ### **Validate**
  4. ![Image](/projects/knative-1.15-en/0f639b159a82f208c372b4e59c312c2a.png)
  6. Open the logs of the event-display with the following command:

kubectl logs -l=app=event-display -f

  2. Verify
  4. Type something in the comment box in the UI and click the submit button. The comment should appear in the event-display service with the following output:

☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: new-review-comment source: bookstore-eda id: unique-comment-id datacontenttype: application/json Extensions, knativearrivaltime: 2024-05-19T05:27:36.232562628Z Data, { “reviewText”: “test” } ```

Next Step

Image

Please make sure you pass the Validate test before proceeding.

Go to Deploy ML workflow: Sentiment Analysis 1 - Send Comments to Broker - 图10