The diagram (created with asciiflow) below illustrates a very high-level overview of SI's calling stack. There are other components and paradigms that aren't displayed, but this diagram is purely meant to show the overall flow from "mouse-click" onwards.
┌───────┐ ┌─────────┐
│ pinga ├───│ council │
└───┬───┘ └─────────┘
│
│
│
┌─────┐ ┌─────┐ ┌──┴──┐ ┌──────────┐
│ web ├───┤ sdf ├───┤ dal ├───┤ postgres │
└─────┘ └─────┘ └──┬──┘ └──────────┘
│
┌────────────────┘
│
┌─────┴────┐ ┌──────────────────┐ ┌─────────┐ ┌───────────────────┐
│ veritech ├───┤ deadpool-cyclone ├───┤ cyclone ├ ─ ─> │ execution runtime │
│ │ │ │ │ │ │ (e.g. lang-js) │
└──────────┘ └──────────────────┘ └─────────┘ └───────────────────┘
- web: the primary frontend web application for SI
- sdf: the backend webserver for communicating with
web
- dal: the library used by
sdf
routes to "make stuff happen" (the keystone of SI) - pinga: the job queueing service used by the
dal
to execute non-trivial jobs vianats
- council: the DependentValuesUpdate job's synchronization service, used by
dal
vianats
to avoid race conditions when updating attribute values - veritech: a backend webserver for dispatching functions in secure runtime environments
- deadpool-cyclone: a library used for managing a pool of
cyclone
instances of varying "types" (i.e. HTTP, UDS) - cyclone: the manager for a secure execution runtime environment (e.g.
lang-js
) - lang-js: a secure-ish (don't trust it) execution runtime environment for JS functions
- postgres: the database for storing SI data
- nats: the messaging system used everywhere in SI, by
pinga
,council
,dal
andsdf
(for multicast websocket events)
It's worth noting that our database has many stored procedures (i.e. database functions) that perform non-trivial logic. While the dal is the primary "data access layer" for the rest of the SI stack, it does not perform all the heavy lifting.