Invidious: [Discussion/Documentation] Replacing the Invidious backend / Current structure of Invidious/the Invidious codebase

Created on 24 Aug 2020  路  5Comments  路  Source: iv-org/invidious

This is something that I planned to ask in the Matrix room, but I think it's a good idea to have it available publicly.

@cloudrac3r : Since you are working on Second, do you think it's possible to have it become the backend of Invidious? (meaning that we just keep the frontend of Invidious, making things easier to fix (since it's not Crystal / is using youtube-dl)), or do you think it won't be doable?

@omarroth : Speaking of replacing the backend: what is the structure of the backend/frontend/api currently?

Is the frontend calling the API that will then call the backend to make request? Or is the frontend making call to the backend and the API is making call to the backend separately?

Also: Are the code of the 3 properly separated or is there (for example) some backend code in the frontend? In short: is it possible to even replace the backend "easily"?

question documentation

Most helpful comment

no matter what plan is being implemented this talk about backends and frontends show how important compatible interfaces are. there are countless projects dedicated to scraping youtube videos like newpipe, a jdownloader scraper, various kodi addons, yt-downloader, vlc. often developers spend so much effort in something that is already done that there is no more time for the actual application. once you already walked down that path there is no int in turning back but if anyone is doing a reimplentation please do not make the same mistake.

All 5 comments

I have only looked briefly at the Invidious source, but I don't _think_ it would be easy to replace its backend with API calls while keeping the rest of its code intact. _I'll wait for omar to weigh in on this though._

I _think_ it would require a lot of modifications in Crystal and I don't know Crystal.

I _think_ it's more practical to create a brand new front-end that can be used with any API implementation. We already have a few of these like CloudTube, FreeTube, LapisTube, and more.

As I already said, it might be possible to make Invidious into a front-end only, but _I expect_ that the modifications would be significant enough that this would require a person who actually knows Crystal.

I have only looked briefly at the Invidious source, but I don't think it would be easy to replace its backend with API calls while keeping the rest of its code intact. I'll wait for omar to weigh in on this though.

This is also what I concluded by looking at the layout of the source code.

I think it's more practical to create a brand new front-end that can be used with any API implementation. We already have a few of these like CloudTube, FreeTube, LapisTube, and more.

The thing is that lots of people (including me) really like/love the Invidious frontend, other than bugfix it doesn't really need anything, and having it usable without the current backend would be really nice.

I think it would require a lot of modifications in Crystal and I don't know Crystal.

Yeah this is why I said "In short: is it possible to even replace the backend "easily"?"

I think it's more practical to create a brand new front-end that can be used with any API implementation. We already have a few of these like CloudTube, FreeTube, LapisTube, and more.

This is true, but as I said before, some people like the Invidious frontend and it would be nice to have it (without having to recreate it).

As I already said, it might be possible to make Invidious into a front-end only, but I expect that the modifications would be significant enough that this would require a person who actually knows Crystal.

I truly hope the code is separated, but yeah, if it's not I don't see how it could be done without a Crystal developer.

I'm confused as to why you would want to do this. As @cloudrac3r mentioned there are other front-ends that would be better starting points if your goal is to use youtube-dl, Second, etc.

If you want to keep the frontend the *.ecr templates, CSS, JS, etc. should be mostly portable to whatever language you pick. Python has several that look similar to what Invidious uses.

I'm confused as to why you would want to do this.

The Invidious frontend is great, and out of the existing one, is the best one by far in my opinion.

As @cloudrac3r mentioned there are other front-ends that would be better starting points if your goal is to use youtube-dl, Second, etc.

Well, yeah but it's not as good imo.

If you want to keep the frontend the *.ecr templates, CSS, JS, etc. should be mostly portable to whatever language you pick. Python has several that look similar to what Invidious uses.

Good to know.

no matter what plan is being implemented this talk about backends and frontends show how important compatible interfaces are. there are countless projects dedicated to scraping youtube videos like newpipe, a jdownloader scraper, various kodi addons, yt-downloader, vlc. often developers spend so much effort in something that is already done that there is no more time for the actual application. once you already walked down that path there is no int in turning back but if anyone is doing a reimplentation please do not make the same mistake.

Was this page helpful?
0 / 5 - 0 ratings