Hybrid Serverless Modularized Monolithic

For most organizations, switching from a monolithic architecture to microservices is really hard as the initial infrastructure investment is very high, and almost all the design patterns in Java EE are anti-patterns in microservices. It might be easier to start with modularized monolithic and then split each module to separate instances as microservices once volume picks up. The light-hybrid-4j is designed for it. It takes advantage of both monolithic and microservices with a simple RPC style of interaction between services.

The light-hybrid-4j is a framework built on top of the light-4j for modularized monolithic and serverless architecture. The idea is that you first create a server with all the third-party dependencies included in the instance. Then you can build multiple services with the same dependencies or a subset of dependencies for development, unit tests, and integration tests. Once your services are completed, they will be built into small jar files without any dependency but only the business handlers. You drop these jars into a service folder on the host the server is running, start the server and all services in the folder will be loaded, and the traffic will be routed to the right handler in the right service for the request.

Similar to the light-graphql-4j, the JSON based light-hybrid-4j is a particular case of RESTful API with all the information defined in the body of the request instead of scattered in the path parameters and query parameters. It gives us a uniformed request body structure so that we can quickly and efficiently identify the handler for a particular request. As JSON is typed, we don’t need a very complicated Swagger specification to describe the variable conversion between service and consumer.

For each service, you need to define a specification file that contains JSON schema for the light-hybrid-4j to validate the incoming request. This schema can also be used by the react-schema-form to generate the application in a React SPA.

Light-hybrid-4j is the framework we used most for our internal services. It gives us the flexibility for deployment and saves us the production cost. For example, the light-portal contains numeric services, but we only split them into a command server and a query server for now. It saves us a lot compare with light-rest-4j as we have to deploy dozens of containers instead of only four(two instances of command service and two instances of query service) in the beginning. In the long run, we have the option to scale the query server to more instances or split it to multiple servers if some services are hit with high volumes.

Light-hybrid-4j contains the following components.

rpc-router

rpc-router is a middleware handler that implements light-4j handler interface and will be injected into the request/response chain. It is responsible for parsing the incoming request body and then routing the request to the right handler to handle it. The handler will be implemented in one of the service jar files included in the server instance.

rpc-security

rpc-security is responsible for JWT token verification from Authorization header.

Rpc Security

This handler is part of the light-hybrid-4j which is built on top of light-4j but focused only on the hybrid style of API. It supports OAuth2 with JWT token distributed verification and can be extended to other authentication and authorization approaches. JwtVerifyHandler This is the handler that is injected during server startup if security.yml enableVerifyJwt is true. It does further scope verification if enableVerifyScope is true against hybrid schema specification. Read More »

Rpc Router

The rpc-router is a middleware handler that implements light-4j handler interface and will be injected into the request/response chain. It is responsible for parsing the incoming request body and then routing the request to the right handler to handle it. Several handlers will be packaged into one of the service jar files included into a server instance as a multi-tenancy container. Read More »

Test Service

Read More »

Start Server

Read More »

Json Schema

Read More »

JSON RPC

You can use JSON to define the schema for each service and the server will use it to validate the request body. There are two different parts in the request body: metadata and data. The schema only applies to the data portion. Here is an example of schema. { "host": "lightapi.net", "service": "certification", "action": [ { "name": "certifyEndpoint", "version": "0.1.0", "handler": "Endpoint", "scope" : "cert.endpoint.r", "schema": { "title": "Endpoint Certification", "type": "object", "properties": { "host": { "type": "string" }, "path": { "type": "string" }, "token": { "type": "string" }, "environment": { "type": "string", "enum": ["test", "prod"] } }, "required": ["host", "path"] } }, { "name": "certifyRegistry", "version": "0. Read More »