---
# System prepended metadata

title: Single API
tags: [jobbatical]

---

# Single API

API is shared by all SaaS client and ourselves. One API means it includes routing between DBs(**if** that's absolutely required) and dealing with the SaaS-client-specific configuration.

Benefits:

* Simplicity of dev: one central location for all the changes;
* Simplicity of debugging: always one central source for issues;
* Simpler integrations: one auth0 setup, etc.;

Cons:

* Scaling the releases: configuration, routing, logging;
* Scaling the operations/application: performance, DB sizes, buckets, etc.;
* Reliability: mistakes **will** affect all clients;
* Privacy: data is guarded only by the quality of the development work;
* 

# Separate

There will be multiple instances of APIs running - at least one per SaaS client. That will push more routing and configuration logic to infrastructure and create separation one cannot cross **inside** a API - developer mistakes have smaller consequences. On the other hand, sharing and syncing data between those APIs can be a problem(but that will be a problem even with one API **if** we need to spread out the data between DBs).

Benefits:

* scaling operations/application
* Isolation: smaller blast radius
* Security: 
* Progressive deployments can be done outside of application code;
* Privacy
* Flexibility with deployments: server location, db location, etc.;

Cons:

* Scaling the releases: integrations need to be created for each new deployment(analytics, hotjar, buckets, databases, etc.);
* Complexity on the infrastructure side;

# Notes

Custom integrations should be implemented outside the the main api, for intance with webhooks.

Data separation and travel - agencies have to work with multiple platforms? Us? import/export? Authentication between those platforms?

PipeDrive example. They don't offer a service to their clients. We do? Do we need to create a protocol to exchange data between the platforms?

###### tags: `jobbatical`