Mesg-js: seperate service and application code to different pkgs

Current pkg name is mesg-js. We can create an organization in npm an use it as a prefix and have two different packages as @org/service and @org/application. Which is very convenient. We also did the similar thing with Go clients.

Agree with that it will make more sense than having to do a .application() or .service().
Also what about calling it @org/core instead of @org/application if we are not doing the when/then layer.

I also like the @org/xxx naming for NPM.
Agree with anthony, let’s use @mesg/core and @mesg/service.


Should we use one github repository or one per npm package?

@mesg/core is also nice but it would be nice if we can provide a similar api. For example, if we have require(’@org/service’).grpc() for accessing service gRPC APIs, I think we should follow the same naming pattern for core as well(require(’@org/core’).grpc()).

Should we use one github repository or one per npm package?

I think we can separate them to make it easier separating CI tasks? There is no much difference tho. Maybe we can create two repos as js-core & js-service.

The javascript library has been reorganized with a mono repo (https://github.com/mesg-foundation/js-sdk) and the following lib:

  • @mesg/cli: Command line interface to create/test/deploy services and processes and manage your MESG node.
  • @mesg/api: This library responsible for the communication with the MESG Engine API.
  • @mesg/service: Handles the connection with the MESG Engine, some authentication, and finally, the functions for your service to listen to tasks sent by the engine or emit events that your service needs to expose to the engine.
  • @mesg/application: This library lets you connect to the MESG engine to listen for any event or result that you might be interested too. It also allows you to execute a task, either synchronously or asynchronously.
  • @mesg/compiler: This library let you compile your services and/or processes.