Ideally we should be able to run pg_graphql queries inside our modules however there are some limitations such as nested filters which is why we had to use raw queries inside the messaging module. When we want to load relations, this is not practical because we have to introduce JOIN inside the raw queries and our custom repositories become more and more complex. On the other hand, without loading relations we have to rely on multiple queries which might impact messaging performances (and other modules that would adopt this pattern in the future).
Those raw queries could be improved to fully use type-orm repositories/entities eager loading to avoid n+1 and other issues and would also improve readability.
The challenge here will be to convert our standard object metadata to typeorm entities so that the engine knows how to query the DB, considering the fact that they live in different schemas based on the current workspace and we need to make sure it uses the correct schema.
Scope & Context
Ideally we should be able to run pg_graphql queries inside our modules however there are some limitations such as nested filters which is why we had to use raw queries inside the messaging module. When we want to load relations, this is not practical because we have to introduce JOIN inside the raw queries and our custom repositories become more and more complex. On the other hand, without loading relations we have to rely on multiple queries which might impact messaging performances (and other modules that would adopt this pattern in the future).
Those raw queries could be improved to fully use type-orm repositories/entities eager loading to avoid n+1 and other issues and would also improve readability. The challenge here will be to convert our standard object metadata to typeorm entities so that the engine knows how to query the DB, considering the fact that they live in different schemas based on the current workspace and we need to make sure it uses the correct schema.