Microservice-based architecture proof of concept

[acelaya]

Shlink is now packaged as a single service, which includes several sub responsibilities.

Current architecture could look like this:

The same entry point is used for the API and the handling of visits on shortened URLs. This mixes certain concepts and forces to have checks in order to see the type of response that has to be returned for HTTP requests.

Also, the CLI tool is part of shlink as well. That gives it direct access to internal services via a different entry point, but this tool could be consuming the REST API instead.

So if shlink was split into different components, the architecture could look like this:

With this approach Shlink would be split into 3 main components:

• The web, which would just receive the requests to short URLs, register the visit and redirect to the long URL. It would also manage QR codes and previews.
• The API, which would handle the CRUD of short URLs, and would be consumed by the web in order to notify visits and match long URLs to short URLs.
• The CLI tool, which would basically be an API client but for the command line.

Shlink currently also has a few parts dedicated to the installation and configuration of the service itself. This could also be separated to a different tool, which could be responsible of setting-up the latest three components, as well as the web client if requested.

Editable diagrams can be found here

---

Edited, 2018-11-04

Of course, this approach introduces complexity, as well as new problems which are not present with the monolithic approach.

• The web component would have to do at least two API calls on every request, making the process a little bit slower.
  Of course, having an in-memory cache would remove the "parse short code" call, but if the short URL is edited, the cache should be invalidated somehow.
• If the installer is separated, probably users would get confused about what is needed to actually get shlink up and running. "Should I download shlink?", "Should I download shlink-installer?". Those questions would come up.
• Some components would need to be released at the same time. If a new customizable option is introduced in shlink, a new shlink installer version would be required to handle it.