exorelay: make responsibilities consistent

[charlierudolph]

Currently the go and javascript forms are very different in what they are responsible for / what is left in exoservice. I believe this was a result of the very different times they were written and

• exorelay
  • go
    • interface to receive all message
    • interface to send a message
  • js
    • interface to register handlers for specific messages
    • interface to send a message and receive the first reply
• exoservice
  • go
    • interface to register handlers for specific message
  • js
    • small wrapper around exorelay (very little code)

---

I think we should make this consistent so that exorelay does the following things

• interface to receive all message
• interface to send a message

Thus exorelay is left as the low level way of dealing with exocom for anyone that wants to build on top of it instead of using exoservice. This was the idea we went with in the go version

---

Then we can update exoservice with a few methods:

• interface to send a message and receive the first reply
  • currently implemented in js exorelay
  • the helper function used in go exoservice does this but it is not available for use standalone
• interface to register handlers for specific messages
  • currently implemented in js exorelay
  • currently implemented in go exoservice

---

If accepted, this would involve moving js code from exorelay to exoservice and adding a missing features to go exoservice.@kevgo @alexdavid @hugobho thoughts?

[kevgo]

I am not against this. Just want to point out that the APIs for both ExoRelay-JS and Exoservice-JS were designed for two very specific use cases:

• exorelay: for front-end micro-services. In those situations one usually has an existing code base (for example an express-based web server), all we want to do is make it able to talk to Exocom. Typically I want to be able to handle particular messages. Not much need to also implement routing of messages.
• exoservice: for back-end micro-services. All I want here is handle incoming messages and send replies.

What is the use-case for the lower-level Exorelay where I get all received messages and then have to do the routing myself?

If we find one, maybe we do a three-way split? (1) low-level Exorelay, (2) high-level Exorelay (1 + message router + reply handling), (3) Exoservice.

[charlierudolph]

I'm suggesting moving high level exorelay into exoservice so it can be used for both (bootstrap for the main services and the ability to create an instance directly for the other methods)

I don't know the low level use case. In the go version, I believe it was in order to abstract away what we always want the exocom libraries to be responsible for (websockets / marshalling messages) and thats it. I believe that was mostly @alexdavid's idea where everything else was pushed out exoservice. I'm not certain if we want

[kevgo]

So, the exoservice NPM module would provide a CLI binary as well as an ExoService class that one can instantiate in code? In this case, we could merge the ExoRelay into that NPM module as well.

[charlierudolph]

exoservice no longer has the binary. It has the bootstrap method for services. Yes, we could technically put all of these into a single exorelay module that has the three API levels which each build upon each other.

• Low level
  • send a message
  • get all received message
• Mid level
  • send a message, get reply
  • create handler for a given message name
• High level
  • provide handlers in an object like format where the key is the message name and the value is the handler

Go currently has low level and high level. JS has mid level and high level

Hard part is what to name each of these. The high level is a bootstrap method currently. Don't know what the names of mid level and low level instances would be called as each would deal with creating an instance.

[kevgo]

What about:

1. ExoRelay
2. ExoMessenger
3. ExoService

[charlierudolph]

I like exorelay and exoservice. Thoughts on giving the low level the new name. Could be something like ExoConnect

[kevgo]

ExoSocket?

[charlierudolph]

Fine by me