Call for Proposals: Future of LibreTime MVC

[hairmare]

Hi all,

The MVC based Web-Interface in airtime_mvc/ is based on Zend Framework 1.x which has recently reached its EOL date on 2016-09-28.

Due to this something needs to be done. We can probably get away with using the framework for a little while longer, but need to start finding a consensus on how to replace it ASAP.

If you have a proposal on how to proceed, please post a new issue with the proposal and link to it from here. I'm going to make a list of the proposals in here and maybe we can use GitHub reactions like 👍 and 👎 to vote on them.

Proposals

• TBD (I'll link to all of them here)

[Robbt]

In my opinion the most straight forward solution would be to migrate LibreTime to Zend Framework 2.x - here is a migration guide. https://framework.zend.com/manual/2.1/en/migration/overview.html

[hairmare]

As a former customer of Zend (and at the time potential user of that guide) I would rather not go down that route. It basically amounts to a complete rewrite of almost everything while not having any pointers that really help :( IMO Zend screwed paying customers with that guide.

Personally I'd rather rewrite to something less complex than ZF2/3, maybe Silex or similar, at least that's the proposal I was planning to flesh out when I find some time (likely post-3.0.0).

[TheCrealm]

Is there a trend for a specific Framework?

Should it be more simple like Flight or Silex or more powerful like Symfony or Laravel (my personal favourite)?

[hairmare]

I think those are the questions we need to find a consensus on. I'm not sure if there are any new trends in PHP community at large.

We should also ask ourselves if and how we would like to decouple the js/jQuery/angular parts from the PHP parts.

[bburton]

It goes without saying that eventually decoupling the UI from the backend would be a good approach for several reasons. I can't speak to pros and cons of the different frameworks but if one of them that's widely used and well supported has better support for REST API's then that should be a consideration if it would be helpful in completing REST API support.

[gattytto]

key features must be: long-term support and platform-agnostic (since it's a frontend), so I'd say to use js and go (golang) instead of php-based frameworks.

there's a big hype on virtualization+containerization of things and looking at kubernetes (google!) approach of things, one can see their "dashboard" divided in two parts, one is a golang backend that communicates with the real api, and then a pure js frontend, which looks and feels nice, and works pretty well.

To divide the frontend in backend+frontend might sound pretty silly, but not at all in terms of High Availability.

https://github.com/kubernetes/dashboard/blob/master/docs/devel/code-structure.md

just my 2 cents, keep up the good work, this is a great project

[Robbt]

Well I doubt that we will transition over to Go vs. Python because so much of the backend has already been written in Python and so rewriting everything is not likely. But I think a separation of the API that interacts with the Python backend that actually schedules the tracks and interacts with liquidsoap is probably a good idea.

In my mind it would be ideal for the frontend to be separated from the backend via a well documented API. The project appears to be moving in that direction but more work needs to be done on the API and more work needs to be done on the Python end of things as well.

But like hairmare said just decoupling the javascript/angular stuff from the PHP end of things would help simplify programming etc. At this point adding even a simple feature involves touching a lot of different codepoints and languages (php, javascript, python) and interacting with a few different javascript libraries.

[gusaus]

Is this something that can be done in parallel with other priorities and milestones https://github.com/LibreTime/libretime/projects/2? Both could be set up as goals on https://opencollective.com/libretime if/once the project scope is defined.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 5 months. It will be closed if no activity occurs in the next month.
Please chat to us on discourse or ask for help on our chat if you have any questions or need further support with getting this issue resolved.
You may also label an issue as pinned if you would like to make sure that it does not get closed by this bot.

[zklosko]

@paddatrapper continuing from #1122 discussion...

But like hairmare said just decoupling the javascript/angular stuff from the PHP end of things would help simplify programming etc. At this point adding even a simple feature involves touching a lot of different codepoints and languages (php, javascript, python) and interacting with a few different javascript libraries.

Decoupling helps build modularity and works great with containers, but creates complexity instead of simplifying. As we're planning the rewrite now (Vue frontend, Django API), we still have to change code in multiple libraries/sections, though only in two languages. If we're aiming to keep the project simple, we should minimize modularity in the project. I'd like to propose one of the following:

1. Switching to Node.js for both the UI and the API: templating (Node/JS), client logic (Node/JS), server logic (Node/JS), and backend (Python), or
2. Sticking with the Django API and rewriting the UI to use Django's server-side functionality: templating (Django/Python), client logic (JS), server logic (Django/Python), and backend (Python)

Either way, we cut back on the amount of libraries/sections. I think option 2 would be best because Django has functionality like user auth and i18n built in and we've already built the new API using Django. We can build Vue interactivity into pages by coding Vue into our HTML and JS files without needing needing to bundle our code with Webpack; the rest (i.e. most templating, user auth, i18n, basic forms) can be done in Django and rendered on the server.

I know decoupling is sexy but it puts a lot of pressure on the client to offer up a good experience for the user. Browsing LinkedIn usually lets me down because my browser has to request everything and build the page before I see anything, which makes me feel like I'm on dial-up because of how slow it is. Speed and durability are more important than a glossy UI for broadcast-grade software, in my opinion, and we should have that be our main focus.

Just my two cents. I'd really like to hear @hairmare's take on this since he's already started with the Vue frontend.

[paddatrapper]

I agree that 2 is better than 1. However, the issue I see with using server side rendering is that we are then defining everything twice - once for the API and once for the view. For example, if we want to add a view for an advertising media library, we have to design an API call, a view render function, template and javascript to make it all work. With a SPA, we implement the API call and template. Then the javascript logic comes out of the frontend templating work automatically.

[zklosko]

Okay, I think I see what you're saying.

[paddatrapper]

Though I agree that we want to try keep things as simple as possible. We already have 5 independent different services, which is a bit of a nightmare...