CloudEvent object about event-gateway-sdk HOT 7 OPEN

Right now we don't support import thing as it's not supported by Lambda.

Possible options:

1. separate module

const SDK = require('@serverless/event-gateway-sdk')
const Event = require('@serverless/cloudevents')

2. static field on SDK class

const SDK = require('@serverless/event-gateway-sdk')

const event = new SDK.Event(...)

3. no separate object (I'm personally +1 here as there is almost no changes to the current approach and also it follows existing pattern)

eventGateway.emit({
  eventType: 'user.created',
  eventTypeVersion: "1.0",
  source: 'dashboard.serverless.com'
})

@brianneisler any thoughts?

from event-gateway-sdk.

I think (3) should work, but we should also have a way for people to create a CloudEvent object and pass it to the emit() method, as in (1) and (2). This can help reduce boilerplate if you need to manipulate the Event in different branches of your code.

Can't we have multiple exports from a single package? I'd prefer that if possible. I don't love using multiple packages as in (1), and the new SDK.Event(...) syntax in (2) seems odd to me. I'm not a JS expert though.

from event-gateway-sdk.

Hmm, what about this...

We make a minimal cloudevents SDK and have it as a dependency in the eventgateway SDK.

In the beginning, the cloudevents SDK could be a class that has default properties already, so you don't have to add the cloudevent properties manually like the pass-in-a-object suggestion. That requires the user learn/add things manually, whereas the class can offer a full CloudEvent out-of-the-box w/ sane defaults which are easier and faster.

The class should also have methods, to create an Express.js-like experience for getting/setting props. Later we can add useful errors when someone has configured something incorrectly into the methods, which offers more value to users and helps the construct CloudEvents safely.

CloudEvents SDK

class CloudEvent {

  constructor() {
    this.eventType = null
    this.eventVersion = 0.1
    ...
  }

  // Set type
  type(type) {
     if (type) this.eventType = type
     return this.eventType
  }

  // Set version
  version(version) {
     if (version) this.eventVersion = version
     return this.eventVersion
  }

  // Set data
  data(data) {
     if (data) this.data = data
     return this.data
  }

  // emit
  emit() {
    // When initializing the CloudEvents SDK, you should be able to override the `emit()` function, so that it is middleware specific.  Since the EG SDK wraps the CloudEvents, we can bake this in.
  }
}

module.export = CloudEvent

Event Gateway SDK & User Experience

const EG = require('@serverless/event-gateway-sdk')
const event = new EG.CloudEvent()

// Design philosophy:  Sane defaults should allow you to do this immediately, to send a default "event.created" event.  Though this will never be used, it should be that easy...
event.emit()

// Instead, the user can use the methods to set the data easily before emitting
event.type('webapp.user.created')
event.version('0.1')
event.data({ email: '[email protected]' })
event.emit()

Other Suggestions:

• Make sure this works in the browser. This is a major use-case.
• Make sure this works in old Node versions. There are many Lambda functions using old Lambda versions. If we don't optimize for them, we severely limit our audience.
• Please design the SDK to keep the file size extremely small. The EG SDK is currently big due to dependencies (that really aren't necessary) and it slows down my deployments by 5x.
• Write boring code. It's an SDK. Make it accessible.

from event-gateway-sdk.

ES6 modules (import and multiple exports) is not supported by node 8 AFAIK. That's why the only options that we have are those from the previous post. We also need to remember that SDK has to work in the browser so something like

const SDK = require('@serverless/event-gateway-sdk')
const Event = require('@serverless/event-gateway-sdk/event')

won't work.

from event-gateway-sdk.

@ac360

// Design philosophy: Sane defaults should allow you to do this immediately, to send a default "event.created" event. Though this will never be used, it should be that easy...

I agree with this approach in general but what's the use case for "event.created"? Defaults should be meaningful and cover real, most popular use case.

const EG = require('@serverless/event-gateway-sdk')
const event = new EG.CloudEvent()
...
event.emit()

The issue with this approach is that emit will not know where to send the event. EG address is specified in SDK constructor. Prior to that we don't know the URL.

Current we have

eventGateway.emit({
  eventType: 'user.created',
  eventTypeVersion: "1.0",
  source: 'dashboard.serverless.com'
})

implemented.

from event-gateway-sdk.

// Design philosophy: Sane defaults should allow you to do this immediately, to send a default "event.created" event. Though this will never be used, it should be that easy...

I agree with this approach in general but what's the use case for "event.created"? Defaults should be meaningful and cover real, most popular use case.

Maybe we leave it blank and throw an error when trying to publish the event without a type?

The issue with this approach is that emit will not know where to send the event. EG address is specified in SDK constructor. Prior to that we don't know the URL.

If the CloudEvents SDK has a middleware option/config, and the EG wraps the CloudEvents SDK, then the EG SDK can auto-configure the middleware in the CloudEvents SDK, which can enable this.

from event-gateway-sdk.

We're currently discussing the CloudEvents SDK and we're working on the design here:

https://docs.google.com/document/d/1JIZxnV_w-dMrSAguG4bqog1vBlD94mm5aFjJlfb-R34

from event-gateway-sdk.