0. Getting started
The generic schema of Workty architecture:
- Workty The single unit of code written on Javascript, Python, Java, Go that stored in compressed form in database. It is used as a template for workty instance and always owned by superuser.
- Workty instance The instance of template workty that run on worker with coderunners and always owned by end-users.
- Workties repository The storage of compressed workties (zip) in database. Every workty should be added into repository to be able for access for end-users.
- Workties cluster The set of workers connected in Ethernet network.
- Worker The single board computers such as Raspberry Pi, Banana Pro, etc that connected in cluster and used to run workties.
- Worker device The synonym of worker
- Borrowed worker The process of borrowing worker (single core) for execution of workty instance. The worker is being borrowed until the workty instance execution has been completed (successfully or not).
- Free worker The process of freeing worker (single core) after execution of workty instance has been completed (successfully or not).
- Workflow The set of workties that runs on workers one by one (sequential logic circuit). It uses finite state machine automation for computing (FSM).
- Supervisor It is a heart of backend code and controls the users connections through web sockets, interaction with rest api server, managing the list of contexts. Implemented as singleton.
- Context The set of API (facade) on backend. At this moment following types of context are implememted: account, workflow, workty, payment, device, ui-settings. Implemented as singletons.
- Coderunner The single unit of code written on Javascript and executed on worker to run workty instance.
- End-users The group of users that use Workty service with browser (Frontend API) and Rest API.
The generic schema of interactions between participants.
