Spring way

In FOLIO

Agenda

• Pain points
• mod-users@Spring experience
• Benefits
• mod-password-validator

RMB - Custom enterprise framework

Community has been endeavoring to build a custom enterprise-grade framework

​

​

How many contributors do we have?

• Spring framework - 500+ active contributors�a lot more for other spring landscape projects
• Quarkus core - 379 contributors
• Micronaut core - 268 contributors
• Vert.x core - 188 contributors
• RMB ~ 5 contributors

​

​

How mature the frameworks are?

• Spring framework - more than 18 years
• Quarkus - 1,5 year
• Micronaut - 2,5 years
• Vert.x core - 7 years
• RMB ~ 3 years

​

​

RMB - Custom enterprise framework

Created vs Resolved tickets in JIRA for RMB project.

Pain points

• Vert.x & RMB major versions' bump up is difficult
• Requires continuous additional effort for every team
• Performance
• In RMB Vert.x is not used as it is recommended by its creators
• RMB creates a single Verticle within a module instance all the work is done in scope of that Verticle
• It is recommended to separate functionality between many Verticles�Vert.x comes with a simple, scalable, actor-like deployment and concurrency model out of the box… An application would typically be composed of many verticle instances running in the same Vert.x instance at the same time. The different verticle instances communicate with each other by sending messages on the event bus. - https://vertx.io/docs/vertx-core/java/
• Developers forced to use “Reactive programming paradigm” only
• A lot of cases in FOLIO could be simply solved by the “Imperative approach” - the solution would be simpler
• Very rare cases that require the full power of the asynchronous reactive approach

Pain points

• CQL and JSON limitation

https://docs.google.com/presentation/d/12gnfQHXZP9rAthJYhDkIYzsyZlTfTG9mgWQj9WmcS-U/edit?usp=sharing

​

Pain points

• Lack of functionality available out of the box in other tool-kits or frameworks
• Support for Model and Representation/View segregation
• JPA/ORM
• Declarative Transactions
• Declarative or Embedded Caching
• CDI
• Conversion/mapping support
• Validation API
• Configuration capabilities / Profiles support (Dev, Testing, Prod, etc.)
• “Call back hell”

Requirements Limitation and Constraints

1. “API First” declarative approach MUST be used
2. Pagination, Filtering, and Sorting options out of the box
3. Full support & compatibility for RMB Management/Administration/Tenant... API required by OKAPI
4. Transparent propagation for “X-okapi” HTTP headers
5. Full support for DB Schema per tenant approach (tenant identifier passed through HTTP headers)

Spring solution

https://www.jetbrains.com/lp/devecosystem-2020/java/

https://www.jrebel.com/blog/2020-java-technology-report#framework-technology

Spring solution

Spring solution

​

Spring core repository

Spring solution

Spring Framework : Vulnerability Statistics�https://www.cvedetails.com/product/31286/Pivotal-Software-Spring-Framework.html?vendor_id=15183

Spring solution

Spring Framework : Vulnerability Statistics�https://snyk.io/vuln/search?q=springframework&type=maven

In total over the decades that the Spring framework has been around, only 96 vulnerabilities have been found.

The distribution of vulnerabilities as they were identified spread across the various framework versions as demonstrated in the following graph.

Spring solution: mod-users@Spring

mod-users -> mod-users@Spring

Made by guys in their free time.�Contributors:

• Illia Borysenko
• Mikhail Fokanov
• Oleksandr Dekin

Goals

• Assess the cost for Spring development in FOLIO
• Find hidden rocks and pitfalls
• Follow OKAPI and RMB restrictions

Spring solution: mod-users@Spring

Results

• A completed spring based module that can be packaged into the Docker container and deployed into FOLIO platform using existing OKAPI API, scripts, and tools
• Users APIs are implemented
• ModuleDescriptor.json - register a module within OKAPI
• Dockerfile & docker-DeploymentDescriptor.json - deploy into FOLIO (VagrantBox or other staging environments)
• mod-users could be substituted by this module in FOLIO platform

Spring solution: mod-users@Spring

Results

API First approach: OpenAPI v2.0 instead of RAML

• Completely repeated the entire API defined in RAML without any problems
• JSON schemas were reused without changes
• RAML to OpenAPI can be converted semi-automatically
• The biggest community compared to other competitors in the field
• Production-grade API Design tools
• Swagger Editor to to design, describe, and document API
• OpenAPI Codegen generating server stubs and client SDKs for any API, defined with the OpenAPI specification, perfect support for Spring
• openapi-codegen-maven-plugin
• https://github.com/mulesoft-labs/raml-for-jax-rs https://github.com/hubrick/raml-maven-plugin https://github.com/phoenixnap/springmvc-raml-plugin - are obsolete and no longer supported.

​

Spring solution: mod-users@Spring

Results

Follow best practices

• Spring Web MVC as a Main pattern
• Layered style
• Rest Controllers
• Services
• Repositories (persistence layer)
• Model and Representation/View segregation

Spring solution: mod-users@Spring

Results

Persistence - Only production-grade tools and solutions

• Liquibase for tracking, managing and applying database schema changes
• PostgreSQL - use relational tables with plain fields. JSONB where it makes sense
• HikariCP - fast, simple, reliable JDBC connection pool
• Spring Data
• Spring Data JPA - this option was selected in this case
• Spring Data JDBC
• class DataSourceFolioWrapper - FOLIO DB schema per tenant support
• Domain model classes are created using Jakarta EE Persistence Specification

Spring solution: mod-users@Spring

Results

Service layer - Only production-grade tools and solutions

• CQL support
• CriteriaBuilder & CriteriaQuery as means to run queries with filtering, predicates, ordering, etc. (Jakarta EE Persistence Specification - https://jakarta.ee/specifications/persistence)
• MapStruct for generated mapping between persistent models and DTOs
• Rest Clients generated from OpenAPI or Spring Cloud OpenFeign - Declarative REST Client to call other modules and services
• Automatic propagation for x-okapi HTTP headers

Spring solution: mod-users@Spring

Results

Rest controller layer

• All DTOs are generated by the openapi-codegen-maven-plugin
• equals, hashcode, toString are correctly implemented
• All Controller interfaces are generated by the openapi-codegen-maven-plugin
• All Controller implementations are simple and straightforward

Spring solution: mod-users@Spring

Benefits

• Completely compatible with existing OKAPI and RMB API
• Stick with Api first declarative approach
• Support for current FOLIO permission model
• Only production-grade and proven tools are used
• All EPAM developers have hands-on experience with spring framework and tools used in this project

Spring solution: mod-users@Spring

Benefits

• OKAPI support is a separate library

Spring solution: mod-users@Spring

Benefits

• Spring Web allows both reactive and imperative programming models
• A lot of mature and proven libraries could be easy used
• Spring Cloud Contract (API Contract Level Testing)
• Spring Security
• Support for monitoring, logging, metrics collection, etc.
• Client side balancing, Circuit-breaker, Retry, etc.
• Integration of applications running inside Kubernetes (Spring Cloud Kubernetes)
• …
• Reduction of development time
• Source code is more compact, simple, and human-readable

Spring solution: mod-users@Spring

Dependencies

• spring-boot-starter-data-jpa - released under the Apache 2.0 license
• jakarta.persistence-api - released under the Eclipse Public License 2.0
• jakarta.transaction-api - released under the Eclipse Public License 2.0
• hibernate-core - released under the LGPL 2.1
• spring-boot-starter-web - released under the Apache 2.0 license
• spring-cloud-starter-openfeign - released under the Apache 2.0 license
• org.apache.commons - released under the Apache 2.0 license
• liquibase-core - released under the Apache 2.0 license
• lombok - released under the MIT license.
• spring-boot-starter-test - released under the Apache 2.0 license
• spring-security-test - released under the Apache 2.0 license
• swagger-annotations - released under the Apache 2.0 license
• springfox-swagger2 - released under the Apache 2.0 license
• javax.ws.rs-api - released under the CDDL Version 1.1
• PostgreSQL (jdbc driver) - released under the PostgreSQL Licence
• mapstruct-processor - released under the Apache 2.0 license

Spring solution: mod-password-validator@Spring

Results

• Reworked and improved library for OKAPI support
• Support for Liquibase
• TenantAPI default implementation
• FOLIO DB schema per tenant support for Liquibase and Repositories
• FOLIO_EXECUTION scope - unified access to Tenant Id, username, JWT token, OKAPI url, x-okapi-* headers, and others
• Request validation
• OpenAPI v3.0
• Improved packaging approach for Docker image to reduce application startup time
• The codebase for the module is extremely simple

https://github.com/folio-org/mod-password-validator/tree/mpv-with-spring

Q/A