Hi everyone,
I’ve been exploring the OpenELIS Global 2 codebase to better understand the architecture before contributing.
While reviewing the backend (DAO / service layers) and parts of the React UI, I noticed a few areas that might be performance-sensitive in large deployments. I’d like to validate these observations with the community before proposing improvements.
1. DAO Layer – Potential Unbounded Queries
In several modules, I observed DAO methods that return full collections (e.g., list/findAll-style methods).
In large-scale lab environments with high record counts (patients, results, orders), unbounded queries could:
- Increase memory usage
- Slow down table rendering
- Introduce latency in reports
Would it make sense to gradually standardize:
- Pagination for list endpoints
- Filtered queries by default
- More explicit JOIN FETCH usage where appropriate to avoid N+1 issues?
2. Controller / Service Data Assembly
In some flows, entity graphs are traversed deeply before being returned to the frontend.
In high-volume datasets, this could potentially:
- Trigger additional lazy-load queries
- Increase serialization cost
- Affect response time
Would the project prefer:
- More DTO-based responses?
- Explicit fetch strategies at DAO level?
3. React UI – Large Data Rendering
In the React UI, certain pages render data tables that may grow significantly depending on lab size.
Would it be aligned with project direction to:
- Enforce server-side pagination for large datasets?
- Avoid rendering large unpaginated lists?
- Introduce memoization where heavy data transforms occur?
I would be happy to:
- Perform a more structured performance review on a specific module
- Submit small incremental PRs (pagination, query optimization, DTO refactors)
- Or follow any existing performance roadmap if one exists
Looking forward to your guidance on how the project would like to approach performance optimization.
Thanks!