Skip to end of banner
Go to start of banner

0010-eureka

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Start Date

End Date

TBD

Contributors

Craig McNally VBar

Status

RFC Preparation

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

It became increasingly clear that requirements imposed by some high-profile libraries adopting Folio were going to be very difficult, if not impossible to meet on the current platform.

Scope

This RFC is intended to cover all aspects of Eureka at a high level. This includes:

Detailed Explanation/Design

 TBD

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.

Deprecations

The following could be deprecated/archived once Eureka has been fully adopted and these components are no longer within the support period:

  • Okapi - Functionality has been delegated to various single-purpose components

    • folio-kong - API Gateway, CORS

    • folio-keycloak - Authorization

    • folio-module-sidecar - Authorization, module-to-module request routing

    • mgr-tenants - Tenant management

    • mgr-applications - Application (and constituent module) registration, Discovery information

    • mgr-tenant-entitlements - Application/Tenant entitlements

    • mod-scheduler - Timers

    • mod-okapi-facade - Partial implementation of the okapi interface, primarily to support modules which call okapi APIs to get a list of entitlements, tenants, etc.

  • mod-authtoken - Replaced by Keycloak/Sidecars

  • mod-login-saml - Replaced by Keycloak

  • mod-consortia - Replaced by mod-consortia-keycloak

  • mod-login - Replaced by mod-login-keycloak

  • mod-permission - Replaced by mod-roles-keycloak

    • Slightly different from the components above in that it’s included in app-platform-minimal. Mod-permissions is needed for migration APIs used when moving to the Eureka platform. After that, it’s no longer needed. So, we need to be sure everyone has fully adopted Eureka before removing it from app-platform-minimal along with the migration APIs.

Benefits

  • Maintainability

    • By adopting trusted open source software like Kong and Keycloak, Folio can focus their development effort on library business logic, leaving the API gateway and Security code to the experts.

  • Security

    • Improved SSO integrations

      • Support for multiple identity providers

      • Single logout

      • Federation support

      • etc.

    • Use of standard protocols (OIDC, OAuth2, etc.)

    • RBAC support

      • Policies allow for greater control of who can do what, when, from where, etc.

    • Additional features like MFA, LDAP/AD integration, etc.

  • Enabler for independent application lifecycles

    • Application-level packaging (application formalization)

  • A step toward the envisioned app stores / application marketplaces

  • Improved system user management

    • Modules no longer need to create/manager/user system users. The platform handles this instead.

  • Configurable structured transaction logging (https://github.com/folio-org/folio-module-sidecar?tab=readme-ov-file#logging-configuration )

  • …

Risks and Drawbacks

 TBD

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

 TBD

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

We would like to get the Eureka platform formally approved and adopted by the Folio community for the Sunflower release.

Unresolved Questions

 TBD

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

 TBD

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

  • No labels