As a side effect, it can simplify and make metacom code more readable and maintainable - protocol code is in one place, no need to check Contracts.md and it can be covered with tests (as in the first example).
It also simplifies integration with systems where you can't use metacom as a package. For example, using k6 for API load testing you can write scripts in JS, but it's not a node env and there's no module resolution like in node. Having metacom protocol serialization/deserialization in one file you can copy/past it and integrate the rest with what is exposed by k6 and use to load test metarhia applications.
Is your feature request related to a problem? Please describe.
Metacom packet structure would come in handy everywhere where there is a need to build communication over messages: For example:
redisstreamspostMessageand basically anywhere where you have only messages and want to build RPCs, events, or streams over it.Describe the solution you'd like
Extract protocol code to
lib/protocol.js, export it from metacom. Example implementation: https://github.com/mprudnik/metacom/commit/c2c6cc1e2c29e57b60e8e6ec5ea56b65305f53a0 It also can be reused in metacom itself: https://github.com/mprudnik/metacom/commit/c08692eb69dfa6c772208c898fdd18ef1f11c1f0Additional context
As a side effect, it can simplify and make metacom code more readable and maintainable - protocol code is in one place, no need to check Contracts.md and it can be covered with tests (as in the first example). It also simplifies integration with systems where you can't use metacom as a package. For example, using
k6for API load testing you can write scripts in JS, but it's not a node env and there's no module resolution like in node. Having metacom protocol serialization/deserialization in one file you can copy/past it and integrate the rest with what is exposed byk6and use to load test metarhia applications.