Skip to end of metadata
Go to start of metadata



Discussion items

5 minCodex DocMDG

Vince has published his longer doc on Codex. TC to review and comment as well as share with community to get their input. Feedback due in 2 weeks. Schedule special meeting to discuss feedback, include non-TC members in this meeting.

10 minOTS Report Summary MDG  We met with OTS to review our writeup on their report. I am set to present to the PC tomorrow.
20 minStripes Architectural Review

Zak presented the Stripes Architecture group's review, prioritization and plan based on what was in the Frontside proposal:

There are 3 key areas that the recommendations addressed:

  • Routing. Routing is the process of mapping a URL to desired functionality in a Web App; based on the URL what pages/data should be rendered. As had been highlighted in the previous presentation on this issue, FOLIO currently handles routing inconsistently (modules determine their own routing) and/or sub-optimally (can't necessarily determine which view or what data should be fetched based on the URL). The recommendation to introduce a better and standard routing has been taken on within the Stripes Force team and good progress has been made. See STRIPES-589 and FOLIO-1694 for discussion, and related work in UIORG-120. Specifically:
    • Progress has been made in Q1 on a new routing architecture.
    • The team will be prototyping the approach in a few small apps (perhaps Checkin and Checkout) and then move to something bigger like UI-Users.
    • It's felt that the new routing architecture could be in place by end of Q2.
  • Stripes "GOD" Object. This was a problem of organization and entanglement; components that should have been independent were instead tightly coupled. The React context API used by the stripes object is now deprecated, in part due to performance problems. Distinct contexts (internationalization, permissions, current-user, access to the data layer) are now provided independently and code that does not require any context (i.e. everything in stripes-components) is separate from code that does.
    • This work was done last quarter
  • Managing the Data Layer. Stripes Connect was created at an early point in the project because there didn't seem to be a good alternative in the technological landscape. GraphQL was early on in its life. Currently Stripes Connect doesn't provide capabilities that are required/beneficial - like caching and robust error handling. Jason Skomorowski will lead the investigation of the problem and he/the Stripes Architecture group plan to make a recommendation to the TC on which direction to take: Adopt GraphQL, invest in Stripes Connect, or other. Current early gut-feel is the GraphQL path makes the most sense. Details:
    • The recommendation will outline an estimated timeframe required to migrate to GraphQL
    • Expect this recommendation in the next 4-6 weeks
    • The work to migrate the data layer should (hopefully) be semi-transparent to most aspects of FOLIO; we won't have to do a lot of rewriting because Stripes Connect is already separated
    • The work on this would likely follow the Routing work outlined above - perhaps addressed in Q3/Q4.
15 minIntro to the UUID discussionMDG

The extensive debate in 

T Key Summary Assignee Reporter P Status Resolution Created Updated Due

 - to avoid having the UUIDs and HRIDs exist in a kind of limbo with an undefined relationship and individual users and developers using the willy-nilly, it would be good for the TC to clearly articulate best practices in the use and consumption of these IDs. Resolving the question of whether a HRID can be modified after the creation of an object is also important. At stake here is FOLIO’s ‘feel’ as a system with some consistency of behaviors and expectations across modules

10 minNew Business?TCAny other items to discuss this week?