Multi-Service Architecture

[Ronin11]

First off, thanks for all the cool work you've done with this. I've been waiting for something like toit to play with some different ideas for IOT.

So, I'm trying to get a better understanding of the desired architecture when it comes to services. I was viewing services as a lightweight thread/process. And something that could potentially be hot-swapped without having to do a full system recompile.
Looking through the code and docs, it's not clear to me if this is the intended operation for these things, or if they should be treated more like applications with dynamically linked libraries to be shared with other applications loaded onto the device.

I was attempting to build something like this:

Where every service basically managed its own scope (potentially spinning up dependent services) and exposed whatever methods were needed, and then just tie everything together.
Is this far outside of the intended use of services? Is using the Resource class a better way of handling this idea?

[kasperl]

I think this is a pretty good use of services. The services themselves do not really care if they are used from within one container or if they are used across containers.

The container is like a process. You can start new ones using spawn and they run independently from each other. A typical use case for containers is providing services to other containers, but a single container can easily provide implementations of multiple different services.

The container -- not the service per se -- is the entity that can be hot-swapped, so you could decide to run the whole GUI service in one container or split it out into more than one container, depending on your needs.

There is more information available here: #869.

[Ronin11]

Ok, so the spawn keyword is used for the creation of containers. What's the difference between spawn and task?

In my main, should I be spawning all of the dependent services?

[kasperl]

Tasks are light-weight, cooperatively scheduled threads of execution that all run within the same address space (the container). They are useful for doing multiple concurrent things that need to coordinate. You cannot hot-swap a single task from within a container; they live and die with the container.

In your main, I would probably start with tasks and focus on getting the basic services up and running. Often the trick is to find a good and reasonably narrow API for your services, so the service boundaries are easy to grok.

[Ronin11]

Cool! Makes sense. So if we:
`

main:
   spawn:: 
     create_ble_service
     create_gui_service
....

`
That would create both services in the same container like so:

and this:
`

main:
   spawn:: 
     create_ble_service
  spawn::
     create_gui_service
....

Would give everything its own container?:

So, then it makes sense to me that you could compile a bunch of containers, host them, and then update and add containers from the device itself right? I haven't been able to find any docs around this part.

[kasperl]

The easiest way to experiment with multiple containers might be through the Jaguar tooling. Jaguar allows you install and uninstall containers on a device via WiFi, so instead of spawning from your code you can tell Jaguar to spawn the containers for you. The benefit is that Jaguar then allows the hot-swap updating.

https://github.com/toitlang/jaguar#installing-services-and-drivers

The Jaguar service that runs on your device when you use the tooling is entirely implemented in Toit, so you can of course do the same thing from your own app:

https://github.com/toitlang/jaguar/blob/main/src/jaguar.toit