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
sdfroutes to "make stuff happen" (the keystone of SI) - pinga: the job queueing service used by the
dalto execute non-trivial jobs vianats - council: the DependentValuesUpdate job's synchronization service, used by
dalvianatsto 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
cycloneinstances 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,dalandsdf(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.