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. Essentially any app that any service API was required to subscribe to this object. Work was needed to break the object down into more discrete objects; 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 has been leading will lead the investigation at 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 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.