Architecture overview
Basic architecture
Tines is a Rails application that uses a PostgreSQL database for its persistent data storage and Redis for its cached data storage and message queuing.
It features two core application containers: tines-app and tines-sidekiq. tines-app runs the Rails server for web application hosting/receiving webhooks. tines-sidekiq runs background worker processes. Both containers read and write to and from the PostgreSQL database and Redis cache - they don't communicate directly, instead, they swap data and messages through PostgreSQL/Redis.
Both the tines-app and tines-sidekiq containers use the same tines-app Docker image with different entry points (start-tines-app and start-tines-sidekiq respectively).
The tines-app and tines-sidekiq containers both make requests to external services to run your automation stories.
The tines-sidekiq container may be optionally configured to periodically load new Action templates from Tines (at integrations.tines.com) and to send basic version and feature usage information back to Tines (at hq.tines.io).
A tines-nginx container is usually deployed in front of the tines-app container to terminate SSL. Alternatively, any load balancer, load balancer service, or reverse proxy can fill this role.
Serving the web application
A user's browser connects via HTTPS to the Tines web application via the tines-nginx container or an LB/reverse proxy, which terminates the SSL connection and connects to the tines-app container over HTTP.
Running Actions on tines-sidekiq
The Tines product features 7 different types of automation "Actions", 3 of which cause Tines to connect to external services: IMAP, Email (SMTP), HTTP Request.
When a user "runs" an Action via the web application, a task is enqueued in the Redis cluster by the tines-app container. The tines-sidekiq container reads from this queue, reads related data from the PostgresSQL database and performs the Action, which may result in a HTTP, SMTP or IMAP request to an external server.
The data gathered from these requests is stored in an "event" in the PostgresSQL database.
Actions can also run as a result of an upstream Action running successfully, or on a schedule. When this happens, a task is enqueued in the Redis cluster by the tines-sidekiq container for each Action that will run.
Testing Actions on tines-app
When "test" mode is invoked via the web application, the tines-app container directly executes the Action (rather than enqueuing it via the Redis instance for later execution by the tines-sidekiq container).
When this happens, the tines-app container may itself make a HTTP, SMTP or IMAP request to an external server.
Receiving webhooks
An external service may post webhooks to the tines-app container through the same tines-nginx container or LB/reverse proxy used to host the web application.
When a webhook is received, the data is stored in an event in the PostgresSQL database. Further downstream Actions may be executed in turn by the tines-app container enqueuing tasks in the Redis cluster.