light-4j: a Java microservices framework organised as a pile of pluggable modules
A fast, lightweight and more productive microservices framework
At a glance
- What is it?
- light-4j is built on Undertow rather than Tomcat and splits every cross-cutting concern into its own Maven module with an externalised config module beside it. Whether that trade is worth the vendor-shaped commitment is the real question.
- Who is it for?
- light-4j is worth a look when you have measured that a conventional Spring Boot service is too heavy for the environment you deploy into, because the README's central argument is a resource argument and the module layout is consistent with it.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 17 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Built on Undertow, and organised as a pile of modules
The project's origin story is a performance complaint. The author describes working on Java EE platforms from early 2000, hitting performance and productivity problems, and concluding in 2014 that the industry was moving from monoliths to microservices and from on-premise data centres to public clouds. Java EE and Spring and Spring Boot are named as too heavy, and other lightweight Java platforms are criticised for separating business logic from cross-cutting concerns badly, and for not being cloud-native.
What he built instead sits on top of the Undertow HTTP core, and the tree shows the result clearly. There is no `starter` or `autoconfigure` module in the listing, no fat shaded jar, and instead a long list of small Maven modules named after single responsibilities: `access-config/`, `api-key/`, `apikey-config/`, `audit-config/`, `audit/`, `balance/`, `basic-auth/`, `basic-config/`, `body-config/`, `body/`, `cache-explorer/`, `cache-manager/`, `caffeine-cache/`, `client/`, `cluster/`, `common/`, `config/`, `consul/`, `content/`, `correlation/`, `cors/`, `data-source/`, `db-provider/`, `decryptor/`, `deref-token/`, `dump/`, `egress-router/`, `email-sender/`, `encode-decode/`, `exception/`, `expect100continue/`, `handler/`, `header/`, `health/`, `hmac/`, `hmac-redis/` and more.
The pattern to notice is that most modules come in pairs. `audit-config/` sits beside `audit/`, `basic-config/` beside `basic-auth/`, `body-config/` beside `body/`, `cors-config/` beside `cors/`, `correlation-config/` beside `correlation/`. Each concern is a handler, and its configuration lives in a separate module you can read, override and replace at deploy time. That is the architectural identity of the project: not an annotation to add, but a module to depend on and a YAML file to supply.
Every cross-cutting concern arrives as a handler
The README describes an embedded gateway addressing cross-cutting concerns, and the enumeration is effectively the feature list. The plugin architecture covers startup and shutdown hooks plus middleware components. Distributed OAuth2 JWT verification is part of the framework rather than an add-on. Requests and responses are validated against an OpenAPI specification at runtime, which is the piece that makes the specification more than documentation.
Around that sit operational concerns handled the same way: metrics collected in InfluxDB or Prometheus and viewed from a Grafana dashboard for both services and clients, global exception handling for runtime, API and other checked exceptions, masking of sensitive data such as credit card and social insurance numbers before logging, sanitisation of cross-site scripting in query parameters, headers and body, audit logging that can dump the important information or the entire request and response, and a body parser that supports different content types.
Then the operational plumbing: standardised response codes and messages from the configuration file, externalised configuration for all modules so the same artifact runs in a containerised environment, a CORS pre-flight handler for SPAs such as Angular or React served from another domain, rate limiting for services exposed to the internet, service registry and discovery support for direct, Consul and Zookeeper, and client-side discovery and load balancing intended to eliminate proxies.
Any one of these could be a library. The claim here is that all of them are handlers in one chain, configured the same way, with an explicit startup and shutdown lifecycle. Whether you prefer that to Spring's annotated approach is a matter of taste you will form quickly.
The performance claim is the argument, and it is unverified in the README
The README states that the framework is 44 times faster than Spring Boot with embedded Tomcat and uses one fifth of the memory. It links to a benchmark repository in the same organisation and to a TechEmpower comparison.
That claim deserves careful handling, and the reason is structural rather than adversarial. This README contains no benchmark table, no methodology, no hardware description and no result set of its own. It points outward, twice, and the linked material is not part of what the repository documents. The repository also has no benchmark module in its tree, so nothing here would let you check the number yourself.
The right response is not to dismiss it, since a framework on Undertow with a plugin chain plausibly does start faster and hold a smaller footprint than a Spring Boot service carrying the same middleware. The right response is to treat the 44x figure as a claim from the project, and to measure your own application with your own payload and your own JVM flags if footprint is the deciding criterion. The `cache-manager/`, `caffeine-cache/` and `cluster/` modules in the tree hint that caching and clustering are part of the intended workload profile.
It is also worth noting what the release history adds here. The three most recent tags, 2.3.5, 2.3.6 and 2.3.7, were published in July and August 2026, and each release body consists of a heading and an empty merged pull requests section. So the project ships on a frequent cadence and tells you almost nothing about what changed between versions, which means the CHANGELOG.md in the tree is the file to consult, not the releases page.
One repository, four service frameworks, one ecosystem story
light-4j is not only a REST framework, and the README separates out a family built on the same core. `light-rest-4j` is the RESTful framework with OpenAPI specification for code generation and runtime security and validation. `light-graphql-4j` is the GraphQL variant, supporting schema generation from IDL plus the same plugin approach. `light-hybrid-4j` is described as taking advantages of both monolithic and microservice architectures. `light-eventuate` is the messaging framework, built on Kafka, event sourcing and CQRS.
Alongside those sit light-oauth2 as the OAuth2 server and light-portal for production monitoring and management, which the README also frames as a marketplace linking clients and services.
The honest reading of this section is that it describes both the strength and the risk. The same ideas travel between four service types, which is a real advantage if you run more than one. But every component is a repository from one maintainer's organisation, and the same README section on language support says plainly that all open source frameworks are built in Java, that a Node.js framework is being worked on internally, and that a Golang framework might come later. Broad platform commitment in a microservice framework is usually a sign of a small bus factor rather than a broad one.
Two smaller signals from the tree point the same way. There is a `SECURITY.md` and a `NOTICE` alongside an Apache-2.0 `LICENSE`, which is the correct shape for a project that expects to be embedded in enterprise builds, and a `.pre-commit-config.yaml` rather than only the Travis configuration the build badge still points at.
Generating a project is the recommended first step
The README gives two ways to start a project, and the first is a code generator rather than an example to copy.
`light-codegen` supports light-rest-4j, light-graphql-4j, light-hybrid-server-4j and light-hybrid-service-4j, with the light-eventuate generator described as coming. Its README documents four ways to run it: clone and build light-codegen and use the `codegen-cli` command line utility, use the `networknt/light-codegen` Docker image to run the same utility, use `generate.sh` from the model-config repository to generate projects based on conventions, or generate from a website through the codegen-web API.
That last option comes with a caveat printed in the README itself: the API is ready but the UI needs to be built. It is a small detail, and it is the kind of detail that tells you the project is candid about the gap between what is shipped and what is planned. The same candour appears in the codegen-web note and again in the language support paragraph, which is worth weighing against a framework that lists only finished work.
The second route, starting from an example project, is where the README stops. The page cuts off mid-sentence at "The othe", so the example project's identity and its instructions are not something this page resolves. Following that thread means reading the documentation site linked at the top of the README, and that site is where the principles page lives too, which is linked from the story of why Undertow.
The version floor to note when you get there is Java. The repository topics still list both `java8` and `java11`.
Editorial conclusion
light-4j is worth a look when you have measured that a conventional Spring Boot service is too heavy for the environment you deploy into, because the README's central argument is a resource argument and the module layout is consistent with it. It is a poor choice when your team needs broad hiring pool, extensive third-party integration, or the reassurance of a large foundation behind it, since the ecosystem is one maintainer's and several of the promised pieces are still described as upcoming. Start from `light-codegen` rather than from this repository, since the README names it as the primary entry point and lists the second option as starting from an example project whose details the repository page cuts off mid-sentence.
Frequently asked questions
What are some frameworks for microservices?
The light-4j family is four frameworks over one core: light-rest-4j for REST with OpenAPI, light-graphql-4j for GraphQL, light-hybrid-4j for a mix of monolithic and microservice styles, and light-eventuate for Kafka, event sourcing and CQRS. Outside that family, the ecosystem the README compares itself against is Spring Boot with embedded Tomcat.
How do I start a light-4j project?
The README names two routes. The primary one is the light-codegen generator, which supports light-rest-4j, light-graphql-4j, light-hybrid-server-4j and light-hybrid-service-4j and can run from a cloned build, the `networknt/light-codegen` Docker image, a `generate.sh` script in the model-config repository, or a codegen-web API. The second route is starting from an example project.
Is light-4j faster and lighter than Spring Boot?
The README claims 44 times the throughput of Spring Boot with embedded Tomcat at one fifth of the memory, and links to a benchmark repository in the same organisation and a TechEmpower comparison for support. The README itself contains no benchmark table or methodology, so the figure is a project claim rather than a reproducible result published on the page.