Drafting a design and architecture document

LibreTime is currently missing a design document, to lead the global decision made in the LibreTime development.

I remember a document explaining the different parts of the project some time ago, It was on the old mkdocs website, I’ll try to resurrect this document.

Initial thoughts

From the few issues I read with design decision that have been proposed, some want to build a micro service architecture, others are heading to a monolithic API with an external Playout service.

Right now I feel we are without global vision for this application. And this lead to having the person provide a contribution to impose his idea. While I understand we cannot afford turning down contributions, we still need to have some kind of road map and design decision to prevent the project from being monkey patched every time someone want to implement an fix/feature.

For example, in #1592, I am working to replace pika with kombu in the Analyzer, it might might sens if we want to work in a micro service architecture, but has no point if we merge the analyzer inside a celery/worker task. While we still want to rely on a hardly functional multi tenant feature for the analyzer.

Another example, in #1501, I think we should not drop rabbitmq which gives advanced routing capabilities, but it does makes less sens to have such tool in a monolithic architecture. It seem that we will always have the communication between the API and playout, which is why I feel having rabbitmq will reduce some of the work required for playout. But again, this should be part of a design decision.

I also don’t know if we try to keep SAAS feature while we want for any newcomers to be able to install the app. As both don’t have the same needs and handling both is sometimes a huge amount of work.

After the community meeting

During the community meeting, we have discussed the lack of such document with @paddatrapper and we agreed that we should start drafting one.

I don’t think the microservice architecture is right way to go, it does not fix or improve any problematic situation in LibreTime. If we want to properly split code by concerns they are plenty of ways to do it.

The multi tenant feature does not seem to be used by anyone that we know, and brings complexity to the project. Spinning an additional analyzer instance for an additional client isn’t much overhead in my opinion. I think that 1 client for 1 LibreTime stack is the right way to go, while we can put aside icecast or reverse proxies or such infrastructure tool that still can be easily shared in a multi client perspective.

I see 2 main component in LibreTime, ‘Create the schedule’ and ‘Play the schedule’. The schedule creation component is a monolithic application, with the frontend talking to the django API. The Play block has it’s own requirements in terms of logic and uptime, and should be left aside.

Original schema without playout > api communication

With the design briefly described above, I found answers to some of my questions:

  • #1592 is useless if we plan to merge the analyzer as a worker task. This merge is a low priority as the current celery stack (php + celery v5) is blocking any easy improvements.
  • #1501 we should keep RabbitMQ anyways, it bring a powerful routing capability needed between the 2 main components, and while we don’t head towards a microservice architecture, anyone can plug his own tool in it.

Please give us feedback

Maybe my ticket does not sound open for changes, but I would love to hear from those who disagree or have better ideas, and discuss with them.

Please note that if someone if pushing towards a particular design (that we should agree on anyway), that person should consider contributing to the project. As I don’t see the myself working on something I am not comfortable with and without the person that had the idea in the first place.