Performance with several clients or projects

[josevavia]

Description

I have 500 clients and around 2,500 projects, and the project and client sections perform very poorly—likely because all the content is being loaded on the client side.

Something similar happens with the time tracker widget, where it is impossible to locate a project because the browser cannot render the list or respond to search queries.

Are there any plans to improve this area?

Steps To Reproduce

1. Create a lot of clients or projects (+500)
2. Navigate to Manage>Projects, Manage>Clients or try to create new entries in Time Tracker and filter by client, project or task
3. Very poor performance

Self-hosted or Cloud?

Self-hosted

Version of solidtime: (for self-hosted)

0.15.1

solidtime self-hosting guide: (for self-hosted)

Yes, https://github.com/solidtime-io/self-hosting-examples/tree/main/1-docker-with-database

[Onatcer]

@josevavia I pushed virtualisation for the Project/Task Selector and pagination for the project / client pages into a feature branch. Feel free to test it with this tag

via .env (for the self-hosting-example)
SOLIDTIME_IMAGE_TAG=feature-frontend_optimization

or solidtime/solidtime:feature-frontend_optimization if you use the image directly

and let me know if you experience any issues.

[josevavia]

Thank you @Onatcer!! I made some testing and performance is very good now. Pagination in project / client pages is awesome and de Project/Task selector is currenlty loading really fast.

You think that this changes could be merged in main branch? Can I help you in some way?

[josevavia]

Hi @Onatcer

While testing the feature/frontend_optimization on a large self-hosted dataset I encountered a problem due to the change in fetchAllPages, and I have a fix.

Problem

The project counts shown per client are wrong and non-deterministic — they change between page reloads, and differ between two instances that have the same database.

fetchAllPages (added in 556bbed, "add dynamic loading of paginated endpoints above page_limit") downloads every page in separate HTTP requests and concatenates them.

The paginated Api/V1 index endpoints order only by a non-unique column (created_at desc, or start desc for time entries). As I have a bulk import that creates thousands of rows sharing the exact same created_at , the API responses are inconsistent across pages.

Fix

Add a stable field (the UUID primary key) so pagination is deterministic across requests. For time entries, order by the real time_entries.start column (not the rounded start alias) plus time_entries.id.

Patch exampe attached — it touches Project, Client, Task, Tag, Member, ProjectMember, Invitation, Report and TimeEntry controllers.

# app/Http/Controllers/Api/V1/ProjectController.php  (representative — same pattern in the others)
         $projects = $projectsQuery
             ->orderBy('created_at', 'desc')
+            ->orderBy('id')
             ->paginate(config('app.pagination_per_page_default'));

# app/Http/Controllers/Api/V1/TimeEntryController.php
         $timeEntriesQuery = TimeEntry::query()
             ->whereBelongsTo($organization, 'organization')
             ->select($select)
-            ->orderBy('start', 'desc');
+            ->orderBy('time_entries.start', 'desc')
+            ->orderBy('time_entries.id');

Happy to open a PR if you prefer.