4 ms·

> All while avoiding the complexities of grpc, building Docker images, Kubernetes, service meshes, "serverless" frameworks, I don't think this will happen to b

> All while avoiding the complexities of grpc, building Docker images, Kubernetes, service meshes, "serverless" frameworks, I don't think this will happen to be honest. The WASM process still has to run somewhere, it's probably going to be wrapped up into those systems. Also all of the code written against existing system interfaces for IO etc will not be compatible with the WASM runtime, which means you'll have to run WASM + something else too (and the easiest path is probably going to be to use those "ops" systems you mentioned).

ReactiveJelly 6y ago
The advantage is that you have _one_ Docker container for hosting your wasm host, and they can use some clever communications inside there, instead of having many containers which have to find each other and communicate using only basic networking primitives. At work I have a Rust web server with basically two parts - What humans see (HTML), and what computers see (API) The API rarely changes, and I was thinking of splitting them into two services so that I could iterate on the human side without worrying about breaking the API side. But I don't want to do that because it means extra management overhead in Docker, extra build steps, etc. And the Docker image is unwieldy from having all of Debian packed in it. So 1 Docker image with 2 Wasm servers in it, is less overhead (of ops) and less risk. I should still use testing to prevent the API breaking, and I still have to figure out a deterministic way to get Wasm images into the server, and measure the performance overhead of Wasm, but it's a tempting option.
- justsomeuser 6y ago
  I agree, I have settled on a similar principle for the small systems I build: Reduce distributed state and message passing as much as possible, use only one process if possible. I think I have settled on a typed language using async and writing state to disk with SQLite. The async functions give me much more context than messaging (Golang, Erlang, GRPC etc) as they preserve the function call stack, SQLite is just the "sync" part of a SQL engine so no message passing there, and types give me machine checkable interfaces. It's going ok.

ReactiveJelly 6y ago

The advantage is that you have _one_ Docker container for hosting your wasm host, and they can use some clever communications inside there, instead of having many containers which have to find each other and communicate using only basic networking primitives. At work I have a Rust web server with basically two parts - What humans see (HTML), and what computers see (API) The API rarely changes, and I was thinking of splitting them into two services so that I could iterate on the human side without worrying about breaking the API side. But I don't want to do that because it means extra management overhead in Docker, extra build steps, etc. And the Docker image is unwieldy from having all of Debian packed in it. So 1 Docker image with 2 Wasm servers in it, is less overhead (of ops) and less risk. I should still use testing to prevent the API breaking, and I still have to figure out a deterministic way to get Wasm images into the server, and measure the performance overhead of Wasm, but it's a tempting option.

justsomeuser 6y ago
I agree, I have settled on a similar principle for the small systems I build: Reduce distributed state and message passing as much as possible, use only one process if possible. I think I have settled on a typed language using async and writing state to disk with SQLite. The async functions give me much more context than messaging (Golang, Erlang, GRPC etc) as they preserve the function call stack, SQLite is just the "sync" part of a SQL engine so no message passing there, and types give me machine checkable interfaces. It's going ok.