Arnica application structure - from applications to nano services

Application is a top level entity. Application consists of modules. Application owns configuration, data sources, events, activity, permissions, resources, and access control type metadata.

Application has one or more modules.

Module includes API containers. Each module is a collection of API containers, usually sharing similar deployment or infrastructure characteristics. For example, one module could be system services, not exposed to end users, and another module could be user services, which users directly interact with.

API container consists of a set of web services, related to one task.  API container is a smallest deployment unit. When an API container is deployed, all its web services are deployed as well. 

Web service could be a stand-alone programming script, or a script which calls nano services in the same API container. Nano services, unlike web services, are not exposed outside of the API container. 

Nano services could also call other nano services within the same API container. 

Because nano services are not exposed outside of the API container, many supporting features of applications such as authentication, authorization, activity logging, events, etc. are not applicable to them. Web services take care of such features on behalf of nano services. This makes nano services very light and efficient when they are used, even in programming loops. 

Nano services may be written in various languages - Arnica script, Golang, SQL, C#, C++, etc.

Arnica WebScript manages all 5 levels of application components - from design, source management, compiling, to deployment and runtime.