Skip to end of metadata
Go to start of metadata

Discussion items

TimeItemNotesAction Items
<5 minsIntroductions


30 minsERM Sprint 60 Retrospective
  • Sprint cycle is practically curtailed, but creates opportunity for 'between sprint' time
  • Improvements to ERM (rather than FOLIO) onboarding


20 minsSprint 61 Engineering Design Notes

5+ minsAOB
  • None

Engineering Design Notes / Queries

Feature

Issue

Notes


ERM-79 - Getting issue details... STATUS

  • Some final integration tests to commit
  • Sort order to be implemented

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.


ERM-173 - Getting issue details... STATUS / ERM-174 - Getting issue details... STATUS

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.

ERM-162 - Getting issue details... STATUS / ERM-163 - Getting issue details... STATUS


5 Comments

  1. 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?)

  2. Ian Ibbotson

    cache strategy should be transparent

    Definitely.

    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.

    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?

    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.

    Agreed. For that reason and others.

    Can we have some more detail of what these extra fetches will be (Beyond what we do now?)

    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.

  3. 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?

    1. 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. 

  4. 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.