Question: When to use extensions vs more services?

[nhynes]

According to my understanding, the following comparison is true of extensions and services used instead of extensions.

Feature	Extension	Service
Provides access to inner bindings	✅	✅
Loaded into	every isolate	own isolate
CPU overhead	very low	low
Memory overhead	O(num_workers), small constant factor	O(1), high constant factor
Binding isolation	high	very high
Typescript compatibility	okay	minimal
Ideal for	convenience, efficiency	separation, composability

Is this all fair to say? There's not much documentation for extensions or wrapped bindings, and they're not used very often, so I wasn't able to find answers elsewhere.

[mikea]

@nhynes there are multiple things that might be confusing:

• Extensions as in [1] . These provide new modules to apps (or to other internal features)
• Wrapped Bindings as in [2]. These are used to provide new bindings with new apis different from underlying implementations (http for a service).

All of this can be definitely accomplished by user code, but the point of using extensions mechanism is late binding: it lets you update the implementation without updating applications.

There's not much documentation for extensions or wrapped bindings

Most of it is in workerd.capnp and in the extensions example. Will be happy to extend if you prod me in the right direction. PRs are welcome too.

they're not used very often

They are actually used under the hood in workers when you use some types of services (don't remember which). This feature was mostly designed for service providers (somebody who runs workerd) and not for application developers. Though I imagine it could be useful for some late-binding deployment scenarios too, e.g. providing different module implementation to different app instances.

[1]

workerd/src/workerd/server/workerd.capnp

Line 873 in 9757dcb

struct Extension {

[2]

workerd/src/workerd/server/workerd.capnp

Line 477 in 9757dcb

struct WrappedBinding {