4 ms·

Workers are network addressible which seems to directly respond to one of the complaints in the article. Beautifully, if you call one Worker from another they h

Workers are network addressible which seems to directly respond to one of the complaints in the article. Beautifully, if you call one Worker from another they have a decent chance of running on not just the same server, but in the same process. When one Worker calls another its data doesn't even leave user-space, even if the two Workers are owned by different people. Imagine calling a third-party API and having your request never even need to leave the process to be handled.

hueving 8y ago
If the request never has to leave the process, that means there isn't anything the third party API is doing that persists state or calls out to another backend. In that case, wouldn't it just be better to import this third party API directly as code and call it for significantly better reliability, performance, and reduced complexity?
- woah 8y ago
  Then your engineers are responsible for maintaining and updating it. Calling to a third party allows you to offload that.
- zackbloom 8y ago
  There are advantages in being able to have a security barrier between your code and that of your customers, and that you can push releases etc without having to update every downstream consumer. More importantly though, we're working on incorporating storage in a meaningful way.
  - jayd16 8y ago
    If the third party code is running in the same process than the security is managed by V8 (or whatever runtime). Does such a thing exist in other managed languages? Does anyone know if C# or Java(for example) have the concept of untrusted libraries?
    - regularfry 8y ago
      Dunno about managed runtimes, but the whole thing sounds isomorphic to running a bunch of untrusted docker containers in a single qemu VM.
    - heavenlyblue 8y ago
      You could think of "untrusted library" as of a wrapper around an HTTP API. The code you don't run, but depend upon it's results.

hueving 8y ago

If the request never has to leave the process, that means there isn't anything the third party API is doing that persists state or calls out to another backend. In that case, wouldn't it just be better to import this third party API directly as code and call it for significantly better reliability, performance, and reduced complexity?

woah 8y ago
Then your engineers are responsible for maintaining and updating it. Calling to a third party allows you to offload that.
zackbloom 8y ago
There are advantages in being able to have a security barrier between your code and that of your customers, and that you can push releases etc without having to update every downstream consumer. More importantly though, we're working on incorporating storage in a meaningful way.
- jayd16 8y ago
  If the third party code is running in the same process than the security is managed by V8 (or whatever runtime). Does such a thing exist in other managed languages? Does anyone know if C# or Java(for example) have the concept of untrusted libraries?
  - regularfry 8y ago
    Dunno about managed runtimes, but the whole thing sounds isomorphic to running a bunch of untrusted docker containers in a single qemu VM.
  - heavenlyblue 8y ago
    You could think of "untrusted library" as of a wrapper around an HTTP API. The code you don't run, but depend upon it's results.