Including the code from the torrust-index-types-lib & torrust-index-api-lib in the Torrust Frontend repo.

[mario-nt]

After giving it some thought, I think it could be a good idea to take the code that is inside the torrust-index-types-lib and torrust-index-api-lib and put it inside the torrust-index-frontend.

Having the code for the types and the api in external packages is a good solution, but I think It's better suited when the project (the types and the API) is more defined and mature.

After making some changes to these packages, I've noticed semver does not really support the versioning in a useful way, and making some other changes in the future (something that is very likely as we will probably add or modify new types for the API calls) will lead into a high major version number, which translates into a bad design.

My take on this would be to put the content of the packages inside two folders in the frontend, named for example, wrapper for the api package and types for the types package, and further down the road, once a contract for the API is made and is in a mature state, go back and maybe consider to split them into packages and make them dependencies from the main project. This may be really useful if the user wants to implement their version of the frontend, as it provides a level of abstraction from the framework.

This change can take a bit of time, but I think is worth considering the time needed to think about how to version the next releases of the packages plus the time spent managing the NPMs packages.

Also, usually, the less dependencies a project have, the easier it is to avoid the so called "dependency hell".

cc: @josecelano @da2ce7 @grmbyrn

[josecelano]

Hey @mario-nt I think It's a good idea for some reasons:

1. As you said, We likely will need to make more changes and there are no other people using them yet.
2. The torrust-index-types-lib package only includes the response types and not the request types. I think I should include both.
3. The torrust-index-types-lib should depend on other parent package where we define the API contract. I think we could have that parent contract repo with several child repos which are the types or/and the API wrapper for different languages: Rust, TypeScript, ...

.
├── torrust-index-api-schema              <- JSON schema?
├── torrust-index-api-rust-client         <- Rust wrapper/client for the API
├── torrust-index-api-rust-types          <- Rust struts for request/responses
├── torrust-index-api-typescript-client   <- TypeScript wrapper/client for the API
└── torrust-index-api-typescript-types    <- TypeScript types for request/responses

[da2ce7]

Hello @mario-nt and @josecelano

Thanks for brining up this topic. It is related to my new discussion about the future repo-naming and structure: https://github.com/orgs/torrust/discussions/13

Overall I think that it is pre-mature to think about merging these repos into either the backend or frontend repositories. The API that the frontend and the backend use to talk together is no specific to either.

Additionally, I do not think that having a high semantic version number is necessarily a bad thing. — it could be indicative of bad design, but it could just be the nature that we have many backwards incomparable changes in our development process: it is not like that we have to coordinate with external parties who actively make use of our API.

I invite @mario-nt to additionally consider the Repository Naming discussion in the context of our API definitions.

[da2ce7]

Hmmm, it should be merged into the torrust-index-backend, as this is the API provider.

[josecelano]

Hi @da2ce7,

The API that the frontend and the backend use to talk together is no specific to either.

Do you mean that none of them is the ultimate responsible for how the API evolves?

If we keep them, at least I would move the requests types from the frontend repo to the types repo. At least we have all the types defined in the same repo.

[da2ce7]

@josecelano

Do you mean that none of them is the ultimate responsible for how the API evolves?

Hmmm... For the moment the frontend is simply a consumer of the backend's API... Whatever the backend decides with the API, the frontend needs to follow. So it could be argued that the definitions should be placed in the backend repo. The frontend should extract the API from the backend repo directly, or later from some form of self-discovery API.

However I wish this to be a temporary arrangement. In the (maybe distant) future, the Torrent Index Rest API should be defined by a public schema that developed in some open-standardisation process; where the backend and frontend both implement this standard.

[josecelano]

Yes, I agree. But I think we are discussing what we do for the time being. I think the most convenient state is a "Symmetric state". Both the backend and frontend have an internal implementation of the API (types and wrapper), and there is no explicit contract between them, just the implementation. If we want to change something on the backend or frontend we need to change both at the same time (first backend and then frontend).

I think the only advantage of having independent packages is if we also like to support the frontend with multiple API versions at the same time (and allow other people to use them, which I would not recommend right now). For now, I think it's simpler to use the latest backend API with the latest frontend.

[mario-nt]

I agree with some things you both mentioned, but I have a different opinion on others:

I believe the two packages belong to the frontend, the backend does not understand Typescript, and the types is a representation of the responses data sent by the backend when the frontend makes those API calls to fetch any data needed.

And the API package for me, is some sort of service, and is a pattern used in the frontend to separate the API calls from the rest of the logic, but again, is a functionality that the frontend uses to get the data it needs from the backend.

Think about it as a example of what Jose described in the first comment, both packages are implementations for a frontend written using Typescript, and as for now we only have that one implementation, I will keep it in the frontend, and maybe in the future, I would follow Jose's schema, having it in a package that the frontend downloads as a dependency.