How It Works
The short version
You describe the application. The application runs from that description.
There is no step in between where the description is turned into program code. The description itself, held in a database, is what the running system reads. That single decision is where every other property of GTSuite comes from, including the ones that sound too good on the previous page.
The pieces
| Piece | What it is | Who touches it |
|---|---|---|
| The Designer | A desktop application for describing pages, data and behaviour | Whoever builds and maintains the application |
| The definitions | Pages, fields, layouts, rules, statements, menus, permissions, translations, stored as data | Produced in the Designer, published to the server |
| The server | Node.js: serves the definitions, executes the statements, enforces the rules | Installed once, then left alone |
| The client | Angular and Ionic: one generic application that renders any page from its definitions | Your users, in a browser or on a phone |
| Your database | Your business data, in a standard relational database | Yours, readable with your own tools |
Note what is missing from that list: a code repository for your application. Your application is not a program that has to be built, versioned and deployed. It is a set of rows.
What happens when something has to change
- Describe the change in the Designer: the extra field, the new rule, the different layout.
- Validate it. The Designer knows the shape a valid definition has, so a good part of what would otherwise be a bug is caught before anything is published.
- Publish. The definitions go to the server.
- Refresh. The next time the page is opened, it is the new page.
No compilation, no deployment window, no coordinating a release with the people who are trying to work. And because publishing is per page, changing one screen cannot disturb the others.
The honest limits
Standard pages, which is to say the large majority of any business application, need no code at all: lists, forms, master and detail, filters, enquiries, dashboards. They are all rendered by the same generic client from their definitions.
Some things genuinely are code, and we do not pretend otherwise. A page with unusual interaction, a specialised calculation or an integration with an outside system can have its own component alongside the generic one. What matters is the proportion: the exceptional stays exceptional instead of becoming the normal way to add a screen.
Your data stays your data
The definitions and your business data are separate things in separate places. Your orders, invoices, movements and customers live in a standard relational database, Oracle or PostgreSQL among others, in tables with names that mean something.
The practical consequence is worth stating plainly: your existing reporting tools keep working, your DBA can read the schema, your backups are ordinary database backups, and if you ever part company with us the data is not hostage to anything. The same applies to the definitions, which are rows in tables that can be read and exported.
Technical note: the platform can also sit on a database you already have. Several of the systems now running on GTSuite work against schemas that predate it by years, which is what makes it usable as a new front on an existing back office rather than a replacement of everything at once.
Where it runs
The same installation runs on our hosted service or inside your own infrastructure, and it can move from one to the other. Where your data physically sits stays a decision you make, not a consequence of the software you chose.
The best way to understand this
It is to watch a page appear without anybody writing code. Confirm an email address and you get a live system to use, the technical documentation behind it, and guided exercises that walk you through building working pages from nothing.