An introduction to JavaScript SDK for CloudEvents

In today's world of serverless functions and microservices, events are everywhere. The problem is that they are described differently depending on the producer technology you use.

Without a common standard, the burden is on developers to constantly relearn how to consume events. Not having a standard also makes it more difficult for authors of libraries and tooling to deliver event data across environments like SDKs. Recently, a new project was created to help with this effort.

CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms, and systems. In fact, Red Hat OpenShift Serverless Functions uses CloudEvents. For more information about this new developer feature, see Create your first serverless function with Red Hat OpenShift Serverless Functions.

The CloudEvents specification

The specification's goal isn’t to create yet another event format and try to force everyone to use it. Rather, we want to define common metadata for events and establish where this metadata should appear in the message being sent.

It is a simple spec with simple goals. In fact, a CloudEvent requires only four pieces of metadata:

• type describes what kind of event this might be (e.g., a “create” event).
• specversion denotes the version of the spec used to create the CloudEvent.
• source describes where the event came from.
• id is a unique identifier that is useful for de-duping.

There are other useful fields, like subject, which when combined with source can add a little more context to where the event originated.

As I mentioned, the CloudEvents specification is only concerned with the common metadata listed above, and the location where this metadata is placed when sending the event.

Currently, there are two event formats: Binary, which is the preferred format, and structured. Binary is recommended because it is additive. That is, the binary format only adds some headers to the HTTP request. If there is a middleware that doesn’t understand CloudEvents, it won’t break anything, but if that system is updated to support CloudEvents, it starts working.

Structured formats are for those who don’t have any format currently defined and are looking for guidance on how things should be structured.

Here is a quick example of what those two event formats might look like in raw HTTP:

// Binary

Post  /event HTTP/1.0
Host: example.com
Content-Type: application/json
ce-specversion: 1.0
ce-type: com.nodeshift.create
ce-source: nodeshift.dev
ce-id: 123456
{
  "action": "createThing",
  "item": "2187"
}


// Structured

Post  /event HTTP/1.0
Host: example.com
Content-Type: application/cloudevents+json

{
  "specversion": "1.0"
  "type": "com.nodeshift.create"
  "source": "nodeshift.dev"
  "id": "123456"
  "data": {
    "action": "createThing",
    "item": "2187"
  }
}

JavaScript SDK for CloudEvents

Of course, we don’t want to have to format these events manually. That is where the JavaScript SDK for CloudEvents comes in. There are three main goals that an SDK should accomplish:

• Compose an event.
• Encode an event for sending.
• Decode an incoming event.

Installing the JavaScript SDK is like using any other Node module:

$ npm install cloudevents

Now that we’ve seen what a CloudEvent is and how it is useful let's take a look at an example.

Create a new CloudEvent

First, we are going to create a new CloudEvent object:

const { CloudEvent } = require('cloudevents');

// Create a new CloudEvent
const ce = new CloudEvent({
 type: 'com.cloudevent.fun',
 source: 'fun-with-cloud-events',
 data: { key: 'DATA' }
});

If we log this out with the object's built-in toJSON method, we might see something like this:

console.log(ce.toJSON());

{
 id: '...',
 type: 'com.cloudevent.fun',
 source: 'fun-with-cloud-events',
 specversion: '1.0',
 time: '...',
 data: { key: 'DATA' }
}

Sending the message

Next, let's look at how to send this over HTTP using the binary format.

First, we need to create our message in the binary format, which you can do easily with the HTTP.binary method. We will use the CloudEvent from the previous example:

  const message = HTTP.binary(ce);
  //const message = HTTP.structured(ce); // Showing just for completeness

Again, if we log this out, it might look something like this:

 headers: {
   'content-type': 'application/json;',
   'ce-id': '...',
   'ce-type': 'com.cloudevent.fun',
   'ce-source': 'fun-with-cloud-events',
   'ce-specversion': '1.0',
   'ce-time': '...'
 },
 body: { key: 'DATA' }
}

Now that the message has been formatted properly, we can send it by using a library like Axios.

Note that the CloudEvents SDK doesn’t handle sending messages; it only handles formatting the message headers and message body. This allows you to use any HTTP library you want to send the message.

const axios = require('axios')

axios({
 method: 'post',
 url: 'http://localhost:3000/cloudeventy',
 data: message.body,
 headers: message.headers
}).then((response) => {
 console.log(response.data);
});

We are sending a POST request to the “cloudevent-y” REST endpoint. In this example, I have used a simple Express.js application, but you can use any framework you like.

Receiving the message

Once we have the message, we can use the HTTP.toEvent method to convert it back into a CloudEvent object.

const express = require('express');
const { HTTP } = require('cloudevents');

const app = express();

app.post('/cloudeventy', (req, res) => {
  const ce = HTTP.toEvent({
                  headers: req.headers, 
                  body: req.body
  });
 console.log(ce.toJSON());
 res.send({key: 'Event Received'});
});

Again, the log output looks similar to what we saw when we output the CloudEvent object:

{
 id: '...',
 type: 'com.cloudevent.fun',
 source: 'fun-with-cloud-events',
 specversion: '1.0',
 time: '...',
 data: { key: 'DATA' }
}

Conclusion

To learn more about the JavaScript SDK for CloudEvents, check out the GitHub project. For more information about the history, development, and design rationale behind the specification, see the CloudEvents Primer.