Backend Layer Separation & Scalability Considerations

[Riddhi8077]

Hi everyone,

While working on a recent backend contribution related to the image favourite toggle functionality, I spent some time exploring how the API routes, database utilities, and processing logic interact across the backend.

During this exploration I noticed some interesting patterns in how the current layers communicate, and I wanted to ask maintainers about the long-term architectural direction for backend scalability and maintainability.

From reviewing several backend routes, it appears that API endpoints often directly interact with database functions and occasionally perform additional processing within the same route handler.

In simplified form, the flow often looks like:

Route → Database Layer → Utility Processing

For example, while working on optimizing the /toggle-favourite endpoint, the route interacts directly with database functions to update the favourite status and then retrieve the updated image state.

This works well for the current functionality, but it made me curious about how the backend structure might evolve as more features and processing steps are introduced.

As the project grows (image metadata processing, tagging, detection pipelines, etc.), I was wondering whether introducing an intermediate abstraction layer could help maintain clear separation between API logic and application logic.

Conceptually something like:

Route Layer → Service Layer → Database Layer

A service layer could potentially help with:

• centralizing business logic
• keeping route handlers lightweight
• simplifying testing of core logic
• improving maintainability as new features are added

Another related thought was whether heavier operations (for example metadata processing or image analysis tasks) might eventually benefit from background execution instead of being handled directly within request handlers.

FastAPI provides tools like BackgroundTasks that could potentially help keep API responses fast while delegating longer operations.

I wanted to ask the maintainers:

Would introducing an additional service layer or background task separation align with the long-term architecture goals for the backend?

Or is the current approach intentionally designed this way for simplicity and development speed at this stage of the project?

I’m still exploring the codebase and would really appreciate hearing how the maintainers think about backend structure as the project evolves.

Thanks for all the work on this project - it has been a great learning experience contributing so far!

Context: Related to my recent contribution on optimizing the /toggle-favourite endpoint.