This will hopefully be the first part of a series which shines some light on the technical aspects and backgrounds of the Hedgehog IDE. As the first part, I want to write about the languages, frameworks and tools we are using. If you want to volunteer for the project, this article is also a good entry point!
Before the actual implementation of the API, all endpoints with their request and response data were defined using the open API specification. This not only allows to be able to develop against the interface while it is still work in progress, but also helps to keep a good overview and document the endpoint in a proper, standardized way. Using this definition file, it is moreover possible to generate boilerplate code and human-readable documentation.
The backend part of the implementation are basically adapters for the related model classes. As an example, listing 11.5 shows the backend implementation
of the real-time sensor updates. In order to reduce the number of messages and
On the client side, the process works vice versa. As soon as a Socket.IO
event is triggered, the appropriate callback is called, updating affected UI components. However, when using real-time communication in combination with the REST service, some timing difficulties arise. Processes as stared via the REST API, whereas their termination is an asynchronous event and therefore send via Socket.IO. When executing a short program (for example a single print statement), a race condition applies since the process termination event should be received by the client, before the corresponding HTTP request that created the process returns. As a result, the frontend it not yet aware of the process’ PID and does not recognize the termination message. To solve this problem, incoming messages are cached while the HTTP request is still in progress and processed as soon as the PID is available. The same procedure is used for stream data as this could be potentially lost as well.