Meeting Details
| Date | |
|---|---|
| Time | 09:30am ET, 2:30pm UK, 3:30pm Germany |
| Location | Video Call in FOLIO Slack: #erm-developers |
Discussion items
| Time | Item | Notes | Action Items |
|---|---|---|---|
| <5 mins | Introductions |
| |
| 30 mins | ERM Sprint 60 Retrospective |
| |
| 20 mins | Sprint 61 Engineering Design Notes | ||
| 5+ mins | AOB |
|
Engineering Design Notes / Queries
Feature | Issue | Notes |
|---|---|---|
ERM-79 - Getting issue details... STATUS |
| |
ERM-49 - Getting issue details... STATUS | Progressing dialogue with Wayne to determine implementation options. | |
ERM-92 - Getting issue details... STATUS | Questions around approach to creating domain objects outside of web app context for integration testing, which Kurt will raise on the ticket. | |
ERM-139 - Getting issue details... STATUS | TBD whether to share data or fetch each time. FOLIO preference is emerging to be fetch each time (as eHoldings does). This should be resolved in the UX call on Thursday This approach will result in more fetches, but this should be mitigated through caching. No caching has yet been implemented, but this is something we need to plan for and schedule into upcoming sprint work.
Note: deferring the refactor until the routing question is resolved need not delay work on Amendments, but if that is progressed using SearchAndSort (rather than SearchAndSortQuery), it will need re-work later. Decision is to expedite the routing best practice question through UX team, complete the refactor and use the next couple of weeks to get a sense of the impact of additional fetches that caching needs to mitigate. | |
smart-components has been amended to make Tags handling more flexible, which allows for the option to create a new withTags component in stripes-erm-components. | ||
5 Comments
Ian Ibbotson
In terms of strategy, The cache strategy should be transparent - enabling caching should not change the API or what calls are made. It's not entirely clear that the individual module is the right place to cache results, and it would be interesting to understand if this has been considered as an okapi feature rather than a functional requirement on modules. I don't think eHoldings is a good representative of the general FOLIO use case BTW, as it's based on different underlying service principles to most FOLIO modules. Can we have some more detail of what these extra fetches will be (Beyond what we do now?)
Mark Deutsch
Ian Ibbotson
Definitely.
Yeah no clue. Definitely more of a backend topic so I don't really have visibility into what the plan going forward for Folio is here. I bet Marc might have heard something at some point?
Agreed. For that reason and others.
For an example, consider that we fetch refdata values for license status and type. We use these values when rendering what filters to display (the /licenses route) and also what values a user can change a License's status/type to (the /licenses/create and /licenses/:id/edit routes).
Currently, we endeavor to fetch those refdata endpoints once: when the user navigates to the Licenses app. With the refactor, we would fetch them when the user navigates to /licenses, when they navigate to /licenses/create, when they navigate to /licenses/:id/edit, etc, because each of those routes would be responsible for fetching whatever data they need.
So if a user went from /licenses → /licenses/create → /licenses → /licenses/:id → licenses/:id/edit (a view, create, edit workflow), we'd make five fetches for the type/status endpoints (each step except the /licenses/:id route) since those routes require those refdata values and would make fetches for it. They'd all be identical fetches, so very easily cacheable, but yeah, we'd need to be caching them.
We maaay be able to cut out the intermediate fetch the second time we're at /licenses, but we'd always be making the extra fetches on the create and edit routes.
Ian Ibbotson
Well - to quote Knuth - "Premature optimization is the root of all evil" - I say fetch every time for now, and if it becomes a problem we can look at cache/optimisation strategies? from what you're describing tho, this initially sounds more like local storage inside the client page will have by far the biggest impact. I'd mark this as considered - no action needed for now, review if performance / usability testing starts throwing up concerns over latency?
Jag Goraya
That's broadly where we got to in the team call - no desire for premature optimization, you'll be pleased to hear.
So, we see what the fallout is and assess what - if any - caching mitigations might be needed.
Jag Goraya
Sounds like there's a separate architecture concern of whether to apply mitigations at okapi v module level.
I guess, that's the nub of the 'what's our caching strategy' question, and making sure we are aligned or excepted as appropriate with FOLIO convention.
And I suppose that's more appropriately determined when we know what impacts might need mitigating. Guess we can revisit as needed then - I'll mark this action as resolved for now. Thanks Ian Ibbotson.