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.
Zak will 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.
- 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