[RFC] Improving/rethinking the trigger events processing

[NamesMT]

The current implementation simply declares a custom method (TRIGGER) and lets hono internal processes mostly everything, this approach allows a familiar syntax with normal hono routes and allowing using the same processing logic via with the current adapter but poses some limitation:

• fixTriggerRoutes is required if basePath / .route grouping is used.
• Only one route is possible for each source of event.

In lambda-voie, I designed the .eventRoute (trigger events) processing to be able to register multiple routes for the same eventSource (like: aws:s3), so that we could do many things for the same event and it would returns an object containing all responses from all registered handlers, something like:

app.eventRoute('aws:s3', 'log')
app.eventRoute('aws:s3', 'copyToPrivateStoreIfNeeded') // If condition met then copy and returns the new path
app.eventRoute('aws:s3', 'emailIfNeeded') // If condition met then sends email and returns true

One event comes in and it returns something like:

const res = {
  log: true,
  copyToPrivateStoreIfNeeded: "a/b/c.file",
  emailIfNeeded: false,
}

It was amazing and supports the usecase of a complex applications, like what if both api/book/* and api/user/* both wants to register a trigger handler on aws:s3?.

I hope we could bring it to this adapter too.

[NamesMT]

I have just released a canary version for the PoC of the new processing of trigger routes, here is some notable features:

• Multiple routes is now possible to be registered for the same eventSource, as in the first post.
  • You can use $! (rootTakeover) and $= (rootReturn) as the route id for some edge cases such as returning a stream.
• Factory pattern, less of weird getTriggerPath() and manual .on('TRIGGER') method declare, now just create a factory from the root instance, import it anywhere and triggerFactory.on(eventSource, routeId, ..handlers), fully middleware handlers support just like normal Hono route!
  • It's possible to also allow factory to be created from sub-instances and still works but I don't think it's a good pratice, so for now only the routes declared from the factory created from the root instance will be effective.
• The internal triggers context uses it's own Hono instance, to decouple from your main Hono router, this is because most likely you will have many middlewares and env bindings registered that is not compatible/intended for the trigger event.
  • You could register middlewares for the trigger routes by accessing .internalApp on the factory.