# Initial Performance Observations (DAO Queries & UI Rendering)
**URL:** https://talk.openelis-global.org/t/initial-performance-observations-dao-queries-ui-rendering/2046
**Category:** Development
**Tags:** dev
**Created:** [March 3, 2026, 11:19am UTC](https://talk.openelis-global.org/t/initial-performance-observations-dao-queries-ui-rendering/2046 "2026-03-03T11:19:04Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@priyanshu56](https://talk.openelis-global.org/u/priyanshu56)
#### Post date: [March 3, 2026, 11:19am UTC](https://talk.openelis-global.org/t/initial-performance-observations-dao-queries-ui-rendering/2046/1 "2026-03-03T11:19:04Z")
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!
---
### Author:  [@priyanshu56](https://talk.openelis-global.org/u/priyanshu56)
#### Post date: [March 3, 2026, 11:20am UTC](https://talk.openelis-global.org/t/initial-performance-observations-dao-queries-ui-rendering/2046/2 "2026-03-03T11:20:38Z")
I may have missed existing patterns, so please guide me.