Choice of protocols and tecnologies for the back-end

[rockerbacon]

With the base architecture defined in #3, we can now go into more technical details and decide what technologies will be employed in each component and how the components will communicate with each other.

To make the initial experiment easier, we'll limit the scope to the back-end, that is, the Core and Module components and the interface for accessing core functionalities.

All choices must be made with cross-platform compatibility in mind, as this is one of the main premises of the project.

[rockerbacon]

To recap and document some initial conversations:

• Core
  • GoLang as the main language: minimal language with a smooth learning curve, no barriers for cross-platform compatibility and allows us to have other languages (C, C++, Java) as escape routes if necessary
  • HTTP for accessing functionality: usage of a network protocol makes it easily portable and accessible and it should be easy to integrate with our language of choice
• Module
  • Lua as the main language: there's still a considerable uncertainty on the requirements of modules. Lua is an obvious choice for the initial experiment, as it provides great flexibility both in regards to function and compatibility with other technologies
  • Embedding a Lua interpreter within the core is the standard manner to integrate Lua scripts within other software

The HTTP option is still vague.

• Would we use REST, SOAP, something else?
• What message format would we use? XML, JSON, Protobufs, something else?

[nlaranjeira01]

My suggestion is that we use REST as the architectural style for the interface and JSON as the data format for the communication of the components.

Why:

• SOAP uses XML, whose advantages (sending binary data) over JSON are negligible for our purposes. And personally I have no experience with SOAP, and its popularity has decreased. SOAP can be more secure with regard to data communication, but as we discussed earlier, the system components will run locally, and consequently the communication will also be.
• GraphQL is just too complex for this application, in my opinion.
• REST is simple and widely adopted, making it easier to maintain and to contribute in the future.
• JSON over Protobuf is preferred because the system will run locally and will not be data-intensive. So the benefits of using Protobuf for faster parsing and lower message size are not that impressive for our purposes. JSON is simple, human-readable (good for debugging) and is easier to implement and maintain.

[rockerbacon]

Agreed. REST HTTP using JSON will be enough for our current needs while keeping development simple.

[rockerbacon]

Summary of the final decision

• Core
  • GoLang as the main language: minimal language with a smooth learning curve, no barriers for cross-platform compatibility and allows us to have other languages (C, C++, Java) as escape routes if necessary
  • HTTP as the communication protocol: usage of a network protocol makes it easily portable and accessible and it should be easy to integrate with our language of choice
  • REST as the architectural style for the communication interfaces: simple and widely adopted, keeps interfaces uniformly organized with minimal development overhead
  • JSON as the data format for communications: having a human-readable format makes debugging easier and JSON is among the simplest and most widely adopted human-readable data formats
• Module
  • Lua as the main language: there's still a considerable uncertainty on the requirements of modules. Lua is an obvious choice for the initial experiment, as it provides great flexibility both in regards to function and compatibility with other technologies
  • Embedding a Lua interpreter within the core is the standard manner to integrate Lua scripts within other software