Cached statistics and all ontologies for ontologies tab and cleaned u…#700
Cached statistics and all ontologies for ontologies tab and cleaned u…#700henrietteharmse wants to merge 2 commits intodevfrom
Conversation
|
Hi @henrietteharmse ! I like the idea of caching all ontologies endpoints as it doesn't change during our application lifecycle. However, if I understand it correctly, the current implementation of the endpoint doesn't technically cache the result unless I'm missing something. The new controller will still go to solr to retrieve the ontologies every time it's called. I suggest we use Spring Cache which is straightforward to set up and can be helpful in our use case. Have a look at https://www.baeldung.com/spring-cache-tutorial |
|
The old endpoint is not caching it. I did look at the different Spring Cache solutions. However, we do not need all the functionality these solutions include and thus it is an overkill. |
That is not true. It only calls solr once and never again. |
yup! i missed the variable bit here |
| "ontologies_all", | ||
| async (_, { rejectWithValue }) => { | ||
| const path = `api/v2/ontologies?size=1`; | ||
| const allOntologiesPath = `api/v2/cache/ontologies`; |
There was a problem hiding this comment.
Is there any reason we can't just make the cached endpoint the only endpoint instead of having a separate API route?
3 participants
…p logging on backend.