Project proposal: light-4j microservices framework about toc

[maurerbot]

looks like you just glued a bunch of libraries and utilities together on top of undertow? What if I don't want all that stuff and compose something that works for my specific needs?

Can you go into depth on what added value light-4j provides beyond bootstrapping a bunch of other projects into a web framework?

[stevehu]

@adrianmaurer Yes. We basically built dozens of middleware handlers that address all cross-cutting concerns for most microservices running in a container. In addition, we provide handlers to support different style of APIs like Swagger 2.0, OpenAPI 3.0, GraphQL and RPC. If users want to build services with asynchronous events, we have Event Sourcing/CQRS, transactional messaging and saga frameworks to choose from.

All the handlers are glued together with service module so that you can add or remove with an externalized config file. Also, every handler has its own configuration file to manipulate behaviors. The light-codegen is used to scaffold a new project with default handlers wired in; however, users can add other provided handlers or their in-house built handlers based on the application requirement.

We also provide light-oauth2, light-portal, tokenization services to help manage life cycles of microservices at scale.

You can use Undertow to build your service but light platform provides an ecosystem for more development productivity. With the scaffolded project, developers can only focus on the business handlers and test cases for these handlers without worrying about all other cross-cutting concerns.

With all the cross-cutting concerns built-in, every service built on top of our frameworks has an embedded gateway so we don't need any API gateway or Service Mesh in the deployment.

[maurerbot]

It still sounds to me like light4j brings on a lot of assumptions and baggage. I think I understand what you're trying to do and that is to provide a reference architecture and some standard dev tools. But I'm not sure light4j achieves that. And here is why

1. Everything you've selected to be part of the ecosystem is more or less wrappers around common tools and patterns with opinions so that they integrate with light4j. But what if I don't need to apply those patterns or use those tools. For example, if I'm already using graphite, do I need to tear that down and migrate to prometheus now?

2. How light4j has selected tools make it very difficult for an application developer to evolve their app over time. There are many alternatives to the selected tools, and better ones may be released over time. I'd prefer to include the tool directly and build my abstractions around it myself. How to create an manage my infrastructure is also tightly coupled creating more dependences -- light4j assumes if this were to be used in a large organization (e.g. bank) developers would even have access to define their infrastructure.

3. Light4j presumes that I need a bunch of patterns in my application, like audit for example. What gives light4j the right to tell me how I apply specific patterns to my application?

Okay, maybe if I was trying to set up a standard for building applications at a large org I may want to build a reference implementation and select some standard dev tools around some best practices. But that should be a decision made by the organization, not a framework developer. And even then, a reference architecture is just that, a reference on how with some opinions vs. "thou shall". Especially as large organizations move towards more product oriented development where product teams have greater autonomy on how to build their applications -- the team chooses their best practices, patterns, tools and how to apply them.

There are a bunch of better ways teams already handle this. You can use tools like yeoman to do your initial scaffolding based on the latest reference architecture a team or org works against (which you may have or need many). One could also easily setup some scans and linting in a CI process using a variety of standard setups like Jenkins, SonarQube and Nexus to ensure specific governance around building applications -- these rules though should be decided by the team and org not.

If I were to sum it up, Java already has a vast ecosystem of libraries and tools to select from. Dependency management is already very mature. Why would I choose an opinionated abstraction on top of that ecosystem that keeps me tightly bound to it? Isn't that an anti-pattern? Especially for something open source?

In other words, as I mentioned in my first comment, light4j has just glued a bunch of current libraries together and a very opinionated manner. In 2-3 years from now, without a considerable renovation, using light4j will seem like buying a used home.

[stevehu]

We are not trying to provide a reference architecture but trying to provide a skeleton that allows users to create their own handlers to attach/inject to it. It is just like we build a Lego base and provide some blocks as references. Other players can use our blocks or build something totally different.

Although light-4j is built on top of Undertow, it has the same performance as you build the application manually. We call it a zero-cost abstraction. You can see the performance comparison at https://www.techempower.com/benchmarks/

For the metrics collection example, we have provided hander for InfluxDB and Prometheus as these are typical push and pull implementations. Other users can create their own handlers and replace the reference metrics handler depending on their environment and non-functional requirement.

As I have explained above, we don't select tools for our users but only provide some reference implementations so that user can learn how to leverage their tools in the framework. At the core of the framework, we do have some dependencies and we are trying out best to select green libraries without too many dependencies. This can make the core of the framework very small and reduce the risk of dependency conflicts.

I don't think there is a fixed pattern or somehow the framework is forcing the user to choose one or the other. We have provided two built-in audit handlers: one to dump only the important info and the other dump everything in request/response into audit log file. One of the bank customers created an audit handler to save information into Oracle database.

I totally agree with you that each organization should have the flexibility to choose best practices, patterns and tools. I am actually collecting these best practices from my customers here.

We have our own generator light-codegen which is very similar to yeoman.

The dependency injection is opinionated because we want to have externalized config files and only want to support constructor injection to avoid confusion. Most injections are happening in the startup hooks anyway.

For Java EE developers, it is very hard to understand the modern async nature of the Undertow, we are just trying to provide an abstract layer to hide these cross-cutting concerns so that developers can only focus on the business logic.

[maurerbot]

We are not trying to provide a reference architecture but trying to provide a skeleton that allows users to create their own handlers to attach/inject to it. It is just like we build a Lego base and provide some blocks as references. Other players can use our blocks or build something totally different.

I think most people would prefer selecting what building blocks they want, for example https://start.spring.io/

Although light-4j is built on top of Undertow, it has the same performance as you build the application manually. We call it a zero-cost abstraction. You can see the performance comparison at https://www.techempower.com/benchmarks/

You ran this benchmark yourself on one endpoint for all comparisons. Not 100% sure this qualifies as a good benchmark. This is just straight up undertow .

public class Example implements HandlerProvider {
    private static final String MESSAGE = "Hello World!";

    public HttpHandler getHandler() {
        return Handlers.path()
        .addPrefixPath("/", new HttpHandler() {
                public void handleRequest(HttpServerExchange exchange) {
                    exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
                    exchange.getResponseSender().send(MESSAGE);
            	}
            }
        );
    }
}

For the metrics collection example, we have provided hander for InfluxDB and Prometheus as these are typical push and pull implementations. Other users can create their own handlers and replace the reference metrics handler depending on their environment and non-functional requirement.

There are plenty of SDK and other libraries that do this generically without needed specific light4j context.

As I have explained above, we don't select tools for our users but only provide some reference implementations so that user can learn how to leverage their tools in the framework. At the core of the framework, we do have some dependencies and we are trying out best to select green libraries without too many dependencies. This can make the core of the framework very small and reduce the risk of dependency conflicts.

I still believe in BYODependencies when needed

I don't think there is a fixed pattern or somehow the framework is forcing the user to choose one or the other. We have provided two built-in audit handlers: one to dump only the important info and the other dump everything in request/response into audit log file. One of the bank customers created an audit handler to save information into Oracle database.

There are plenty of logging libraries that can stream logs to wherever you like however you like. Your patterns is presumptuous. FluentD can also do this faster at the OS level. Also, this is by definition a reference implementation.

I totally agree with you that each organization should have the flexibility to choose best practices, patterns and tools. I am actually collecting these best practices from my customers [redacted].

Good that you agree. There are also many blog posts from various schools of thought on best practices that the community agrees on.

We have our own generator light-codegen which is very similar to yeoman.

This only works for light4j? Why not make a PR to yeoman to generate light4j stuff?

The dependency injection is opinionated because we want to have externalized config files and only want to support constructor injection to avoid confusion. Most injections are happening in the startup hooks anyway.

It's great that you are thinking of DI and how to manage it within the light4j context. But the pattern is been pretty well solved with spring.

For Java EE developers, it is very hard to understand the modern async nature of the Undertow, we are just trying to provide an abstract layer to hide these cross-cutting concerns so that developers can only focus on the business logic.

I don't think you would write code any differently using Undertow then with any other container? You can pretty much run spring boot on it with a simple change in the project pom.

Anyway, I think your intentions are well founded. And I believe having a variety of frameworks out there competing against each other is great for the community. But I'm not sure light4j is hitting the mark on what your trying to achieve -- at least for a cncf pov. With that said, I think it's a great case study on how to assemble a suite of tools and libraries to build an application.

[caniszczyk]

closing, no interest from @cncf/toc to present