Dashboard vs file api config

[Martin]

@nicodeceulaer

Cloud setup of tyk. So API config is using database, not file based.

I think there’s some confusion here, there are four setups:

1. Cloud based setup with our cloud
2. Cloud based setup with a local hybrid gateway, configuration is stored in our cloud system,
3. On-premise (or your own cloud, e.g. AWS, Azure) with dashboard and gateway - here the dashboard stores the API definitions for you in MongoDB
4. On-premise (or your own cloud, e.g. AWS, Azure) without dashboard - i.e. file-based installation, a.k.a Community Edition

In options 1,2 and 3 the Dashboard REST API can be used to programmatically add APIs to the setup, and in v2.3 of the software there will be an import/export API that makes it easier to create repeatable setups with the dashboard.

In option 4, it is purely file-based, and file-synchronisation across gateways is up to the implementer, we solve the centralisation / clustering problem at Tyk with the Dashboard.

@nicodeceulaer

What is the easiest way to provision the API configuration in a repeatable way (ie scripted in some way). I’m looking for the easiest way to import the file config into the dashboard I guess?

If you are moving from a file-bnased to a dashboard-based approach, you can just use the Dashboard REST API to create the APIs in your new dashboard. In v2.2 it is more difficult to make this repeatable (retain IDs etc), but in v2.3, as mentioned above (released this week), it is easy.

@nicodeceulaer

I’m a bit puzzled why the big cloud setup seems to be less foreseen for the automation of the setup whereas the small setup has a nice file-based approach?

The small setup that uses a file-based approach is the lowest-common-denominator setup of the gateway, the idea here is:

1. What is the minimum requirements for someone to get started with Tyk - with Community Edition, it’s Redis and a few files
2. For larger organisations, if you want a GUI etc, then it is assumed that the GUI / Management layer setup is more permanent (i.e. not designed for immutable architecture), so the dashboard provides a centralised configuration, and once set up, allows for simple gateway deployment without having to sync files - gateways here are suitable for immutable architecure, so they can be torn down and horizontally scaled without the need for syncing files etc. But you ge tthe flexibility of being able to manage the APIs that those gateways manage via na API and via a GUI centrally without re-deployment.
3. For extra large orgs, you can decouple the gateways from the dashboard using our MDCB component (Multi Data Center Bridge), here you can have many gateways, autoscaling across many data centers with their own, isolated, Redis DBs, and here again, you don;t script the dashboard setup, but your deployments at the application layer are easy to replicate because everything is centralised via the MDCB master layer.

So bottom line, in v2.3 we make it easier to backup and recreate core elements of a dashboard setup, but the idea is that the dashboard and data layer are not torn-down and replicated all the time, whereas your gateways should autoscale easily and be hot-configurable from a central management layer.

Scripting a dashboard setup is quite straightforward, you use a combination of the admin and dashboard REST APIs to set up the orgs and users and then add your APIs either via the GUI or via the REST API - the objects are the same as the file-based mechanism.

To answer the original question: There are two configurations of Tyk: File based or DB-backed,there is no in-between.