Proposal to Develop API Support for ConvertX

[AdrienGras]

Hi @C4illin,

First of all, thank you so much for creating ConvertX—it’s an amazing project!

I discovered your software after an hour of searching for a fast, flexible, containerized multi-file converter. ConvertX immediately stood out to me, and I was thrilled with how well it works. However, the only limitation I’ve encountered is that it currently operates as a web application. For my use case, I need an API to integrate it seamlessly into software pipelines I’m developing to process and convert images.

To address this, I’d like to propose a pull request (PR) that would include the following major changes:

• Refactor: Introduce a meta-controller system, similar to the one demonstrated by @OthmanAmoudi: Elysiajs-api-controllers. This meta-controller approach aligns with Elysia's best practices since the annotations are compiled into handlers function at compile time.
• Refactor: Restructure the business logic into services to improve separation of concerns and make them independent of HTTP requests.
• Refactor: Redistribute domain-specific logic and data access into repositories.
• Refactor: Organize utility code into dedicated helpers (e.g., for database interactions, error handling, etc.).
• Refactor: Implement a "responder" system to provide more flexibility in responding to requests (e.g., JSX, JSON, etc.).
• Feature: Add an API layer to enable interaction with the project via both web and API modes.
• Feature: Secure the API using a JWT-based system, leveraging the existing cookie authentication system.
• Feature (breaking): Revamp the routes to conform to RESTful standards. To minimize disruption for existing users, the current routes could coexist with the API routes under a prefix (e.g., /api).
• Performance: Optimize converter code to enhance data processing speed.

Given the significant scope of these changes, I wanted to reach out first to seek your permission to undertake this work. I respect the fact that this represents a major evolution of the project, and I want to ensure that these changes align with your vision for ConvertX.

I believe I can dedicate time during the upcoming holiday season to develop these features and submit the PR. Please let me know if you’d be open to this, or if you have any feedback or concerns about the proposal.

Thank you again for creating such a great tool, and I look forward to hearing your thoughts!

[C4illin]

Hello I am glad that you like the project and are excited to contribute, but I don't think an api is the right thing to add. If you have the time to figure out how to use an api, isn't it better to just call the converter directly?

But some of your ideas not connected to the API are good and I would gladly accept a pull request (PR).

Refactor: Introduce a meta-controller system, similar to the one demonstrated by @OthmanAmoudi: Elysiajs-api-controllers. This meta-controller approach aligns with Elysia's best practices since the annotations are compiled into handlers function at compile time.

Sounds like a good idea

Refactor: Restructure the business logic into services to improve separation of concerns and make them independent of HTTP requests.

What do you mean?

Refactor: Redistribute domain-specific logic and data access into repositories.

What? Sounds good to refactor the code but it definitely doesn't need to be split between repositories.

Refactor: Organize utility code into dedicated helpers (e.g., for database interactions, error handling, etc.).

Sounds good

Refactor: Implement a "responder" system to provide more flexibility in responding to requests (e.g., JSX, JSON, etc.).

not really useful imo

Feature: Add an API layer to enable interaction with the project via both web and API modes.

Seems overkill

Feature: Secure the API using a JWT-based system, leveraging the existing cookie authentication system.

Yes that would be nice

Feature (breaking): Revamp the routes to conform to RESTful standards. To minimize disruption for existing users, the current routes could coexist with the API routes under a prefix (e.g., /api).

I think it wouldn't break anything for current users

Performance: Optimize converter code to enhance data processing speed.

What is the bottleneck? There is very little overhead