Support for extending or customising the runtime?

[tom-sherman]

Is this planned/possible to support?

Some use cases I'm thinking of:

• Changing the exports/event handler semantics
• Adding new global JS APIs
• Adding JS APIs that can use new types of bindings/services

[jasnell]

Much of that will fall under the category of new feature development and we will be handling that very carefully. The best approach is to open a discussion or issue early to propose and discuss possible features before writing any code.

[tom-sherman]

@jasnell Ah, I was more thinking like workerd having some sort of plugin interface to allow for adding stuff to the runtime. Does this align with the goals of the project? If not I'm happy to extend/customise via a fork before suggesting changes up stream, but I can imagine much of the extensions wouldn't really be relevant to include in workerd mainline as they'd be things like "a KV-like API backed by DynamoDB" (for example).

[penalosa]

For things like a KV API with a different backing, that's supported out of the box! workerd supports pluggable KV, R2 etc... interfaces, and you should be able to implement the KV API backed by DynamoDB (see miniflare for an example of how this is done with KV persisted to disk)

[kentonv]

Hi Tom,

The code today is structured internally so that it's possible to add custom APIs and event handlers. Specifically, the full set of available APIs is controlled by the class WorkerdApiIsolate in src/workerd/server/workerd-api.{h,c++}. Essentially, if you fork the server directory, you can add new APIs here without having to fork the rest of the codebase.

HOWEVER, we do not currently make any promises about stability of internal APIs. E.g. WorkerdApiIsolate implements the Worker::ApiIsolate interface. This interface could change at any time. You will have to be ready to update your code as needed, or be willing to pin to a particular version of workerd.

We might add a more flexible mechanism for custom APIs in the future, perhaps especially to support Workers for Platforms use cases, but this is something we need to design carefully in coordination with our product management team.

(I'm converting this issue to a discussion since I don't think there's an action item for us, but happy to answer questions about this.)