Skip FOLIO Project Navigation

The design of FOLIO architecture (microservices and REST) enables any module to be written in a programming language that the developer is comfortable with. So various programming languages and build environments could be utilized.

However, FOLIO has implemented a Technical Designs and Decisions process (presentation) to provide consistency in FOLIO and to minimize the use of alternative tech stacks.

Server-side

The back-end modules can utilize any language.

Frameworks abstract much functionality and enable the developer to focus on implementing business functions. Define the APIs and objects in RAML or OpenAPI files and schema files, then the framework generates code and provides tools to help implement the module. Frameworks currently in use:

Key requirements for server-side modules:

  • Be able to handle the REST interactions according to the API and implement the lifecycle endpoints.
  • As explained in the Okapi Guide, Okapi uses HTTP 1.1 with chunked encoding to make the connections to the modules.

Client-side

The front-end user interface code can be written using any toolkit and programming language, since Okapi represents all of the FOLIO functionality as well-behaved web services. FOLIO provides the Stripes UI toolkit (JavaScript), optimized for accessing Okapi-based services and wrapping UI functionality into convenient modules.

  • Be able to handle the REST interactions according to the API.
  • Be able to manage state and send special headers such as X-Okapi-Tenant.

Current situation

So far we have concentrated on server-side modules in Java using Vert.x or Spring, and client-side in Node.js and React. Because we use them internally, those technologies will have a prominent place in the FOLIO ecosystem and, initially, it may be easiest to get started using them. We provide libraries and utilities that help with development (especially with writing standard boiler-plate code and scaffolding).