Architecture
Getint.io is a separated / isolated platform developed, maintained, deployed independently from apps / software which integration is supported within a platform.Its a stand-alone, clustered, modern
Architecture of the the geitnt.io platform was conscious, thoughtful choice.
Modern software, possible to be also installed by enterprise customers on their servers, was one of the key requirements we put up at the same beginning.
Standalone, separate platform brings several advantages, when few of them are:
- Independence from the supported apps / software integrations that are possible with using getint.io. E.g. getint.io can be deployed and improved without a need to publish every time to the particular App marketplace (e.g. Asana or Jira marketplace)
- Supported apps, like Jira, are not at all impacted by loading up getint.io add-on. Getint.io will not impact boot up or behaviour of the target app / software
Below you can find some key technologies that we are using within getint.io. If you would like to find out more details about the low-level components / dependencies, please contact with us.
- Spring
- React
- PostgreSQL 11
- NGINX
Nginx - is used as a load balancer pointing incoming request to the proper clusters
React - is used as a frontend technology to build modern UI
Spring - application framework on top of which whole business logic of platform is build up
PostgreSQL - relational database system management where all the configurations of created integrations are stored, as well as all historical data about performed synchronizations
Because platform is a separate, stand-alone solution, approach of periodic changes fetching is used to obtain data that should be synchronized from one app / software to another.
When the integration e.g. between Jira and ServiceNow is created, its first run will ask both sides to provide items that changed after the timestamp equal to current time stamp (lets call it TIMESTAMP 1). Another run of that integration which will happen after a specified delay (in seconds), will ask for items that were changed after TIMESTAMP 1. Start of that second run is captured (lets call it TIMESTAMP 2). Next run will ask for items that changed after TIMESTAMP 2, and start of that third run will be captured as well. That cycle of changes fetching will be repeated until integration is disabled or deleted.
There is an option to specify minimum a delay between end of integration run and before another run. Although, when SaaS deployment is used it can be minimum 180 seconds, while when On-Premise, there is no restrictions.
Last modified 1yr ago