Skip to end of banner
Go to start of banner

Folio module types

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 10 Next »

Introduction

FOLIO is a micro-service system. FOLIO services are called "modules"

Each module is a separate application serving a specific role. There are several roles in project:

↑ Back to top

Frontend modules

FOLIO frontend is built as an SPA application based on React.js.

There are component frameworks located at: https://github.com/folio-org/stripes and https://github.com/folio-org/stripes-core

Each UI module implements its own functionality. At build/package time all modules are packed to packages and a single frontend budle is created.

↑ Back to top

Backend module types

OKAPI

OKAPI is a central gateway in FOLIO project. It also encapsulates following services

  • API gateway
    • UI accesses OKAPI API which is exposed as a public API
    • all internal modules communicate via OKAPI API (no direct communication via HTTP(s) between modules)
  • service registry / discovery - all modules, excluding UI, publish their descriptors using OKAPI API to be available within the system)
  • security / access control - all requests passing through OKAPI has a security token assigned and checked to have corresponding permissions
  • tenant management - OKAPI controls when a database of a particular module (including a per-tenant databases) have to be upgraded for next version
  • dependency management - each module descriptor published has a set of dependencies included. OKAPI checks all those dependencies and also checks for existing circular dependencies in tree.

Business logic modules

Business logic modules are usually a Java applications, encapsulating data transformation, enriching, calculation - everything required to implement a business process.

Business logic modules are not commonly using their own database connection, but using "Storage modules" to persist information.

Storage modules

These modules are dedicated to provide an API for persistence layer of FOLIO. They usually expose CQL-type API to access database objects. Modules are mostly implemented using RAML descriptors.

Storage modules are not meant to have any type of business logic and must serve exclusively for storage purposes.

Edge modules

Edge modules are services to provide API for integration of third-party systems with FOLIO platform. Those modules are set up to be accessed from 'external' networks and not using OKAPI as a gateway in front of them.

For access control purposes they use their own mechanisms.

Modules used to interact with third-party systems (where FOLIO is an initiator) can be considered either BL or EDGE modules (example: https://github.com/folio-org/edge-dematic)

↑ Back to top

Sample interaction diagram

Source

↑ Back to top


  • No labels