When running exo setup make sure services define compatible messages.

[stefansavev-o]

This is one bottleneck when I faced developing multiple services. There were discrepancies between the message names, e.g. one service would define product.list while another one will expect product.lists. If this can be tackled by a warning it will be very useful. But the large point is that I want 'typesafe' messages. For example https://www.w3.org/TR/wsdl defines message format. A tool in big data for defining message formats is https://developers.google.com/protocol-buffers/. My point is a feature that enforces message formats at exo setup time will improve productivity and there are precedents for this. When you boot the service it can also check the formats at run time. We can also have versions of the formats.

Also: warnings for unconsumed messages, duplicate consumed messages and non-present messages.

[kevgo]

Hey @stefansavev-o! This feature is already implemented via the exo lint command:

Lints the Exosphere application in the current directory. This linter checks that all messages indicated to be sent by services of the application are received by one or more other services in the application and vice versa. This command must be called in the root directory of the application.

Moving forward, we have to extract this command out of Exopshere and make it part of Exocom. But for the time being, it should hopefully help with some of the headaches you are experiencing.

[kevgo]

Sorry that this wasn't documented. We really have to give documentation more love moving forward.

[stefansavev-o]

Thanks Kevin! I'll use that. Still I think the following makes sense. Run exo lint as part of exo setup and if you discover issues, emit a warning 'We've found .... Run exo lint for more information.' This is self-documentation as the commands points out to potentially useful documentation. Having wsdl or something similar has not been addressed. I think this makes sense in particular in a world where you refactor your message formats as you continuously develop on top of exosphere. If I would develop every day for exosphere, I can make my own scripts for this, but a selling point of the framework would be that it does that for you. There is a difference between a first time user and a seasoned user what knows how the system works. I think it's a great idea to architect for the first time user at least until exosphere gets more established.

[charlierudolph]

exo-lint is being moved into the exocom repo and being removed as a part of exosphere. Also exo-setup is now gone and has been consumed as part of exo-run.

You could run something like exocom-lint && exo run in order to verify the linter passes before running. We could potentially add a pre-run step to application.yml in order to specify that some command like must pass exo run. @kevgo @stefansavev-o thoughts?

[kevgo]

Yes, let's make the old exo-lint available as a stand-alone command called exocom-lint.

[charlierudolph]

@kevgo the more important question for this repo is whether or not we want to add a pre-run step to application.yml in order to specify that some command like must pass before exo run starts

[kevgo]

That's another great idea!

[kevgo]

On the other hand, I don't think running linters in production is a good idea. An application must be starting in production as it is, whether there are broken tests or linters or not. In that regard, the linter should be a part of the test suite, not the application startup routine. Maybe only run the lintersn before exo-run in dev mode?

[charlierudolph]

exo-run is dev only as far as I know. It won't be used in deployment

[kevgo]

True.

[kevgo]

Closing this in favor of #452