= Problem
[RESTBase](https://www.mediawiki.org/wiki/RESTBase) is a pretty complex piece of software. It currently:
- serves as the main entry point for the [public REST API](https://en.wikipedia.org/api/rest_v1/)
- provides a large storage solution for caching and/or storing responses to REST API calls
- acts as a storage solution for the back-end services powering the API
Serving all these functions not only makes RESTBase complicated to improve and operate, but it also limits severely the way other entities in the environment can interacts with its storage.
= Solution
In order to decrease the complexity and allow the back-end services to use the storage layer directly (and therefore, more efficiently), we are going to separate RESTBase into two different services: one acting as the REST API router and proxy, and the other providing the appropriate storage semantics to both the API router and the existing RESTBase back-end services.
Internally, RESTBase is already pretty modularised, which eases making the split: there are two main routing hierarchies - `/v1` and `/sys`. The former exposes the (public) REST API, while the latter is used internally only for business logic and storage-layer access. The idea is to have `/v1` and the business-logic part of `/sys` in the front-end service, and the rest of `/sys` to reside in the back-end service and have it exposed to the WMF production environment. The back-end service will remain co-located with Cassandra on the physical nodes, while the front-end service will be running in #kubernetes .
= Steps
This is a tracking ticket, so the actual solutions to each of the steps involved will be addressed and discussed on the relevant tickets. Here we are providing just a list of things that need to happen.
[] {T220761}
[] {T220461}
[] Split the execution paths
[] Deploy the front-end service
[] Deploy the back-end service