3 ms·
Super cool. If I understand correctly: - There's no IDL file, like a .proto file. Instead, weaver looks for marker interfaces by embedding weaver.Implements[T]
by sa46 4y ago
Super cool. If I understand correctly:
- There's no IDL file, like a .proto file. Instead, weaver looks for marker interfaces by embedding weaver.Implements[T].
- Weaver interfaces must be serializable, which explicitly support protobufs. Was the intent to be able to port gRPC services to weaver?
- Weaver maintains a list of deployments, and each deployment has components. Components may only communicate with components belonging to the same deployment. Sounds like a way to implement atomic deploys.
- Named listeners are mapping over a net.Listener?
Sidenote: I'm going to steal the metrics implementation. I haven't found a lightweight metrics implementation for GCP.
- rdgrandl 4y agoThis is a great summary. Some comments: - Service Weaver implements its own serialization mechanism which is very efficient/achieves high performance. - You write an application as components (where each component is defined by an interface). You can deploy the same application using different deployers: (1) on the local machine as single/multi process; (2) on GKE and we also have an experimental (3) SSH deployer that allows you to deploy across a cluster of machines reachable over SSH. - However, the abstractions around deployment are agnostic to the deployment environment (local, cluster, cloud), hence someone can improve/write new deployers without deep knowledge of Service Weaver internals.