While I was at Cloudflare, I loved working on the Workers platform.
Their decision to embed a programmable layer into the CDN has transformed the company into something far bigger.
This made me realize that every app should be extensible as deeply as possible - going beyond HTTP APIs and Webhooks.
Today, we've opened up our platform making it simple to bring next-generation extensibility to your application & safely execute end-user code in-process.
I believe we've all faced the desire to run user code, and as modern products become increasingly engrained in our workflows and stacks, this desire is stronger than ever. XTP makes it safe and easy to do this leveraging the power of WebAssembly. On top of this secure core, XTP provides authorization, code uploading, testing, simulation & validation, as well as easy to use SDKs to load and execute user code.
We're excited to open up this platform in public beta & are eager for your feedback!
I'd guess https://frida.re/ is the closest I know of for modifying software, but for sure isn't as easy as Violentmonkey. The advantage over your description of XTP is that both Frida and Violentmonkey don't require the permission of the target app/website, so that seems like a huge win
These are also super interesting customization / mod tools. I think you hit the nail on the head though, which is that XTP is something the software creator intentionally adds preempting new ideas from end-users.
Also, we have done a ton of work to make it very easy for a plugin developer to build against an extension point, using idiomatic generated libraries based on the apps’ specification. This means that a developer can generate plugin boilerplate (currently in Go, TS, Rust, Python, Zig, C++ and C#) and immediately start working with easily understandable functions and types. In contrast to even really good REST API docs, this feels extremely productive.
I would guess Members would be employees from my company who have access configure XTP and Guests would be the number of customer logins? And simulation runs is also self explanatory after reading the article, but I can't figure out what "Extension Points" and "Apps" could mean.
After looking further down the page I noticed that parts(?) of XTP are open source, now I'm more interested! How much does XTP differ from extism?
Thank you for the feedback on the terminology - I agree there is a lot packed into that pricing. To answer these quickly,
“Apps” represent your application that you’d like to let your user extend. You’d want an App in XTP for each of your environments, e.g. “cart-manager (prod)” and “cart-manager (dev)”
“Extension Points” are the places within “Apps” where plugin code runs, and can be well specified with a schema. This is the interface between the host app and the guest plugin. It contains the definitions of the plugins functions that the host can call, the host apps functions the plugin can call, and the types that go across that boundary.
Yes, lots of XTP is open source - mainly the Schema definition as well as all of the code generators that make it easy for plugin developers to build against the Extension Point interfaces. This short example exercise will give you a good idea about all that:
https://github.com/dylibso/xtp-integration-exercise
As far as XTP vs. Extism, XTP provides both a DX lift on top of Extism via binding code generation based on our XTP Schema - as well as a production-ready platform to intake, host & deliver plugins.
We also have a very capable testing framework and simulation feature that is partially open source and runs online in XTP platform to guarantee plugin behavior and performance before you run it inside your own application.
Reminds me of an idea: instead of having lots of orthogonal endpoints or using GraphQL, accept WASM modules as requests and provide the service as functions in the WASM environment.
Great idea! This would enable users to pass arbitrarily complex queries to the server, without introducing new endpoints for each use case. This is the genius of WebAssembly! Later we could also add some "default" query language on top of WASM, so you wouldn't have to fire up a proper compiler for simple queries. We could call this language e.g. Simple Query Language? Could be shortened as SQL.
FWIW, when experimenting with stuff like that, I never had a good experience with WASM. It might be nice for “traditionally compiled” languages, but for stuff like JS or Python (which is what you’d usually like to expose to users, rather than C++) it’s not that great of an experience, and at least for JS the runtimes aren’t compatible with common JS runtimes.
What I think is a bunch more promising in this area is Deno[0], which is a fully sandboxed-by-default JavaScript runtime, and as of Deno 2.0 recently is also compatible with Node APIs.
Based on the logos on their Subhosting[1] product landing page, they even seem to have a couple major companies using it for this very purpose.
Yes, Deno Subhosting is very cool - but it’s still basically just an HTTP call to another service. Even if you self host it.
XTP encourages you to actually run the user code _inside_ your own process - directly alongside your app code. This enables integrations with bidirectional capabilities that are just not possible with a network boundary between the host and guest.
While I was at Cloudflare, I loved working on the Workers platform. Their decision to embed a programmable layer into the CDN has transformed the company into something far bigger.
This made me realize that every app should be extensible as deeply as possible - going beyond HTTP APIs and Webhooks.
Today, we've opened up our platform making it simple to bring next-generation extensibility to your application & safely execute end-user code in-process.
I believe we've all faced the desire to run user code, and as modern products become increasingly engrained in our workflows and stacks, this desire is stronger than ever. XTP makes it safe and easy to do this leveraging the power of WebAssembly. On top of this secure core, XTP provides authorization, code uploading, testing, simulation & validation, as well as easy to use SDKs to load and execute user code.
We're excited to open up this platform in public beta & are eager for your feedback!
> This made me realize that every app should be extensible as deeply as possible
I believed that so strongly that I put my money into https://www.kickstarter.com/projects/shanecelis/emacsy-an-em... (and https://github.com/shanecelis/emacsy ) but as one can see it didn't shake out
I'd guess https://frida.re/ is the closest I know of for modifying software, but for sure isn't as easy as Violentmonkey. The advantage over your description of XTP is that both Frida and Violentmonkey don't require the permission of the target app/website, so that seems like a huge win
These are also super interesting customization / mod tools. I think you hit the nail on the head though, which is that XTP is something the software creator intentionally adds preempting new ideas from end-users.
Also, we have done a ton of work to make it very easy for a plugin developer to build against an extension point, using idiomatic generated libraries based on the apps’ specification. This means that a developer can generate plugin boilerplate (currently in Go, TS, Rust, Python, Zig, C++ and C#) and immediately start working with easily understandable functions and types. In contrast to even really good REST API docs, this feels extremely productive.
Congrats, I do really like the idea and especially the slogan!
Would recommend to explain the following terms on the landing page more thorughly:
25 Members 5 Apps 300 Authorized Guests 25 Extension Points 3k simulation runs
I would guess Members would be employees from my company who have access configure XTP and Guests would be the number of customer logins? And simulation runs is also self explanatory after reading the article, but I can't figure out what "Extension Points" and "Apps" could mean.
After looking further down the page I noticed that parts(?) of XTP are open source, now I'm more interested! How much does XTP differ from extism?
Thank you for the feedback on the terminology - I agree there is a lot packed into that pricing. To answer these quickly,
“Apps” represent your application that you’d like to let your user extend. You’d want an App in XTP for each of your environments, e.g. “cart-manager (prod)” and “cart-manager (dev)”
“Extension Points” are the places within “Apps” where plugin code runs, and can be well specified with a schema. This is the interface between the host app and the guest plugin. It contains the definitions of the plugins functions that the host can call, the host apps functions the plugin can call, and the types that go across that boundary.
Yes, lots of XTP is open source - mainly the Schema definition as well as all of the code generators that make it easy for plugin developers to build against the Extension Point interfaces. This short example exercise will give you a good idea about all that: https://github.com/dylibso/xtp-integration-exercise
As far as XTP vs. Extism, XTP provides both a DX lift on top of Extism via binding code generation based on our XTP Schema - as well as a production-ready platform to intake, host & deliver plugins.
We also have a very capable testing framework and simulation feature that is partially open source and runs online in XTP platform to guarantee plugin behavior and performance before you run it inside your own application.
Reminds me of an idea: instead of having lots of orthogonal endpoints or using GraphQL, accept WASM modules as requests and provide the service as functions in the WASM environment.
Yes! Especially with the ability for wasm code to call host-provided import functions, the module can do lots of really interesting things.
Here’s an example that might be interesting: https://nordicapis.com/beyond-the-http-api-webassembly-and-t...
(skip down to the part about Stripe and how a wasm integration pattern can power much more sophisticated bi-directional interactions).
Great idea! This would enable users to pass arbitrarily complex queries to the server, without introducing new endpoints for each use case. This is the genius of WebAssembly! Later we could also add some "default" query language on top of WASM, so you wouldn't have to fire up a proper compiler for simple queries. We could call this language e.g. Simple Query Language? Could be shortened as SQL.
Like I said, this is the genius of WebAssembly!
"All new ideas are dumb because they're a little bit like the old ideas", great take
Cool idea!
FWIW, when experimenting with stuff like that, I never had a good experience with WASM. It might be nice for “traditionally compiled” languages, but for stuff like JS or Python (which is what you’d usually like to expose to users, rather than C++) it’s not that great of an experience, and at least for JS the runtimes aren’t compatible with common JS runtimes.
What I think is a bunch more promising in this area is Deno[0], which is a fully sandboxed-by-default JavaScript runtime, and as of Deno 2.0 recently is also compatible with Node APIs.
Based on the logos on their Subhosting[1] product landing page, they even seem to have a couple major companies using it for this very purpose.
[0]: https://deno.com/
[1]: https://deno.com/subhosting
Yes, Deno Subhosting is very cool - but it’s still basically just an HTTP call to another service. Even if you self host it.
XTP encourages you to actually run the user code _inside_ your own process - directly alongside your app code. This enables integrations with bidirectional capabilities that are just not possible with a network boundary between the host and guest.
Deno allows WASM as well!