Summary
The Folio Eureka Platform (henceforth referred to as Eureka for brevity) represents the next generation of Folio’s architecture which allows the project to operate at enterprise scale and expand its solution space. It seeks to replace custom-developed core components found in the original Folio architecture, with feature-rich, best-of-class, specialized open-source components. The need for this has become critical as Folio has become widely adopted, and particularly in ever increasing numbers in complex configurations such as consortia and national libraries.
Motivation
Why are we doing this? What use cases does it support? What is the expected outcome? What is the strategic value?
Scope
This RFC is intended to cover all aspects of Eureka at a high level. This includes:
Authentication
Authorization
Sidecars
API Gateway/Routing
Dynamic Scheduling
Role Based Access Controls
Application Formalization
Covered in more detail here: https://folio-org.atlassian.net/wiki/spaces/TC/pages/349765637/0005-application-formalization?atl_f=content-tree
Detailed Explanation/Design
This is the bulk of the RFC.
Explain the proposal as though it were already implemented and you were teaching it to someone already familiar with Folio - foregoing unnecessary introductory material.
Get into the specifics including corner cases and plenty of examples.
Define any new terminology and named concepts
Fully explain the scope of the proposal: backend; frontend; full-stack.
Provide clear guidance as to how the proposal might be implemented.
Include any reference to any existing Folio Jira issues.
If appropriate, the use of diagrams and illustrations is encouraged.
Provide any assessment of the dependency impact of the proposed change; its interaction with other features is clear.
If possible describe how disruptive the change might be to the existing Folio development community.
Discuss how any breaking changes can be rolled out (migration guidance).
If applicable, provide sample code or pseudo-code, error messages, or deprecation warnings
Describe the impact on existing Folio documentation, guides and other reference materials.
Risks and Drawbacks
Why should we not do this?
A genuine and thoughtful consideration to risks and drawbacks is essential for a well-rounded proposal.
Rationale and Alternatives
Why is this design the best in the space of possible designs? How does this design integrate (or not) into the existing architecture and practices in Folio?
What other designs have been considered and what is the rationale for not choosing them?
This section could also include prior art, that is, how other the same problem may have already been solved elsewhere.
Timing
By what date / flower release does the proposal intend that new work be compliant?
Does this RFC impact existing work? If so, by what date / flower release does the proposal intend that existing work be updated to be compliant?
Unresolved Questions
Optional, but suggested for first drafts. What parts of the design are still TBD?
What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
Keywords
Optional, but recommended, especially in cases where the RFC links to other documents. This should take the form of a simple comma-separated list of keywords/phrases