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 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.
Typically, an Application Load Balancer (ALB) is deployed in front of the tines-app container.
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 template-data.tines.com) and to send basic version and feature usage information back to Tines (at hq.tines.io).
Serving the web application
A user's browser connects via HTTPS to the Tines web application via an ALB. The ALB 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 an 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 an 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 ALB 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.
Connecting to a SQL database
Outside of the core two containers, Tines also provides a separate container, called sql-over-http, that allows the HTTP Request Action in the product to communicate with a SQL database (currently only PostgreSQL databases are supported).
An HTTP Request Action can be configured to invoke the sql-over-http service via an HTTP request, which will, in turn, connect to the target database and execute the given SQL statement.
To connect to Snowflake databases, we recommend using the Snowflake SQL API.