Repository Naming

[da2ce7]

I would like to open this discussion for the consideration of renaming some of the Torrust repositories.

In particular, I do not think that the "backend" / "fronted" scheme is representing our application structure accurately.

The backend/frontend combination implies some sort of 1:1 couplings: This naming scheme was relevant in the "Web 1.0" system architecture, however we have moved on, and I suggest that our project naming scheme should better reflect the modern paradigm.

The "Index"

In actually, "the index" is a data-structure that our software develops and maintains over its operation.

From there we have differing roles that provide services to this conceptual index:

Database Role

This role is responsible for maintaining the coherent data structure that we call "the index". - It is the closest thing to the actual index itself; has the greatest privilege of all the roles.

The database provides a low level api (in our case: SQL). This api should be quickly abstracted as it is inconvenient and dangerous to interact with.

The database role typically only interacts with a single service, (in more complex systems there can be many services that interact with the database layer, each having their own permissions and responsibilities).

Logic Role

This role provides the core logical foundation for the index: On one side it manages the low level interactions with the database layer. - And on the other it provides a safe, logical, and high-level data-structures that conceptually represent the interaction possibilities a index provides.

Typically the logic role connects with a single database provider, and with many service providers.

API Service Role

This role provides a standardised and secure portal to "the index"; this role translates and specialises the internal logic provider into a public facing interface.

The API service makes interfaces for the layer to interact with various applications: it is not intended for human consumption.

Some Examples include:
C-Programming Linking Interface.
Protobuffers / ØMQ.
Rest/HTTP API.
GraphQL.
RSS.

These standard interfaces allow for other applications to interact with the index with confidence. They should be designed in a way that they are logical and easy to comprehend for others who may not know the inner-workings of the index logic.

Application Role

The application role makes available "the index" to third parties. I.e, somebody who doesn't necessarily has any fundamental interest in the index, but uses it in the process of doing something else.

User Interfaces are a good example of an application. A User Interface would interact with an API provider.

For example; a search engine, May crawl a index using the RSS api service; the search engine is an application for the index.

Applications can be focused, i.e. our dedicatedly name "frontend". Or incidental, i.e the search engine indexing a RSS feed. - Or anywhere between.

---

I would it it seems like we have the first three roles: database; logic; and api; merged into a single repository: "torrust-index-backend".

Splitting these into separate repositories would be a significant effort.

However, since these roles cover the core of the index. I suggest we can simply drop the "backend" suffix.

(The current "torrust-index" repository can simply be deleted.)

Secondly I would like to make it clear that the frontend is simply an application. - And we could specify what sort of application it is.

So maybe: "torrent-index-ui-nuxt". Since in the future the hope is that the web index api service is standardised; and is no-longer torrust specific.

What do you think? We should not rename repositories regularly; so let's get it right!

@josecelano @cgbosse @MCM-Mike @WarmBeer

[josecelano]

Relates to: torrust/torrust-tracker#240

[josecelano]

Hi @da2ce7, I agree with reviewing the purpose of all repositories and how they interact with each other or the dependencies between them. Let's discuss this from different points of view. I see three different levels:

• User solution: a software that solves a user's problem.
• Deliverable: independently deployable pieces of that solution.
• Repositories: software modules with independent history. They could map one-to-one to deliverables (monolithic solutions).

Current solution: Index is a web application

I think right now, we have two products: the Tracker and the Index. The Tracker can be used independently, but the Index depends on the Tracker. One product (user solution) depends on the other.

Right now (at least how I see it), the Index is

• A product that helps users to find torrents.
• It's one solution that has three deliverables. It's a web application with the common three tiers: database, backend and frontend.
• It has two repositories. The Index Backend contains two tiers: the database and the backend.

The backend has different parts:

• Database
• API
• Other console commands, for example, cronjobs (or scheduled task) to import statistics from the Tracker.

Some considerations:

• In a common architecture (onion, clean, hexagonal), the API is the delivery layer (UI). We can consider the console as another UI, so the current index has at least these two interfaces with the user.
• We do not have them yet, but we will probably have some cronjobs for asynchronous tasks (job queues, etcetera). Both the API and Console command depend on the Application Services layer:

UI         ->Application Services->Domain Services->Domain Entities
API        ->Application Services->Domain Services->Domain Entities
Console App->Application Services->Domain Services->Domain Entities

• Sometimes it's convenient to have different repos for the common layers (Domain Services). For example, if you deploy using container, you may have one container for the API, one container for running background tasks, and another container for the DB.

• In the current solution, as It was thought like one solution, the Index API was designed to fulfil frontend needs. It's not a generic API build for unknown clients.

New solution: Index is a service

If I get it right, you propose to change the role of this backend. Instead fo having one solution (web application) the Index itself is going to become an independent solution.

This new Index would be like the Tracker. It's an online service that tracks metadata about torrents (indexed torrents). That data can be used by any client.

I think this has some implications. For example:

• We cannot build a custom endpoint for the frontend. We need to consider generic features that a service like this may have.

Do you have any other ideas about how this index could be used? The obvious one is implementing other web clients. I think, for example, someone might want to build a console app to interact with the Index (I like that idea :-), like, for example: https://github.com/mandreyel/cratetorrent). In such a case, I guess the console app should use the API.

Conclusion

I like the idea of making the "Index" an independent (service) solution and renaming it to just "Index", but making it a really independent project

Other topics

Regarding renaming the frontend to "torrent-index-ui-nuxt", in general, I do not like the idea of using the implementation detail in the solution name, unless there are different implementations for the same solution. I would call it: "torrent-web-index" or something like that. I would add the prefix to "torrent-web-index-nuxt" if we introduce the "torrent-web-index-svelte-kit" version.

We should also review how we can split the Index into different packages/repos. That could be done later, but there are some easy refactoring, like extracting the: schema/contract for the API and the client wrappers for some languages like Rust and TypeScript.

[josecelano]

There are other aspects like:

• The Index configuration file contains info related only to the website, for example, the website name. It does not make sense to have that info there, but then would that mean we need a new "backend" for the frontend?
• The Index would need anyway a web interface for configuration, user management, etcetera, or should we move those features to a different place?

[da2ce7]

CC: @mario-nt and @grmbyrn

[mario-nt]

Overall I agree with what you both said, still I will give my opinion on these topics:

Torrust Index

I think we should see the index as an independent app, and should contain different parts separated as you've mentioned (database, API, logic, etc).

Torrust Backend

Again, I think there should only be a Torrust Index, so I will rename this repo to Torrust Index as you said, and will in the future move the different parts (API, Database, etc) to different repos or keep them as modules inside the Torrust Index repo.

Torrust Frontend

The same with this, for me, the current "Frontend", is a Nuxt implementation of the UI, a web graphic interface written with Nuxt, that the final user/s use to interact with the Index

Summary

I think we should think about Torrust as a project that have two main parts, the tracker and the index, users have the chance to use any of them or both independently, and each project should be split into different modules that represent the different functionalities and implementations of those functionalities.

[cgbosse]

These are technical details where I trust your judgement better than mine, therefore I will make only one comment:

1. Whatever changes you make and the reasons behind these you should publish these on the repo readme, the website, and any other online sites that you may deem relevant.