light-4j Documentation

The client-config module is a shared component used by both the light-4j client module and light-aws-lambda. It provides configuration support for two types of HTTP clients:

1. Undertow-based client
2. JDK 11 http-client

This module enables configuration reloading and is designed to be backward-compatible by following the Undertow client syntax in cases of discrepancy.

Light-4j provides multiple specialized frameworks for different microservice architectures:

• light-rest-4j: A RESTful microservice framework using OpenAPI specifications for code generation, runtime security, and validation.
• light-graphql-4j: A GraphQL microservice framework supporting schema generation from IDL and plugins.
• light-hybrid-4j: A hybrid framework combining monolithic and microservice architectures.
• light-eventuate-4j: A messaging-based framework built on Kafka, supporting event sourcing and CQRS.

The ingress-proxy module provides handlers and utility classes for managing ingress traffic. It acts as a proxy that delegates to the light API server features to handle server-side cross-cutting concerns, such as:

• Schema validation
• JWT verification

The egress-router module provides handlers and utility classes for managing egress traffic (routing). It is designed to offload complex client-side responsibilities from legacy systems or applications developed in different technologies (such as Node.js or .NET) when they need to call light-api services.

By using router handlers, you can delegate the following client-side features to the router:

• Service discovery
• JWT token management
• Loading TLS certificates

Consumers can discover services using the Discovery Channel. This channel supports one-shot lookups, live subscriptions, and receiving change notifications.

Endpoint: wss://<controller-host>:<port>/ws/discovery

Authentication: Authentication occurs during the WebSocket upgrade request via the Authorization header: Authorization: Bearer <token>

portal-registry uses controllerDiscoveryToken if configured, otherwise it defaults to portalToken.

The egress-router module relies on light-router for its core functionality. To implement routing, service discovery, or proxying, refer to the following resources:

• GitHub Repository: Light-router
• Core Concepts: Getting Started Guide
• RESTful Proxy Implementation: Step-by-step Tutorial
• Configuration Options: Configuration Guide

The Token Limit handler is used to rate limit the OAuth 2.0 token endpoint. Its purpose is to ensure clients are caching tokens and to identify 'bad citizens' that request a new token for every request.

This handler can be deployed on:

• The oauth-kafka server
• A dedicated light-gateway for OAuth token and key services.

Environment-specific behavior:

• Lower environments: The handler can be configured to return an error message if a token is not cached by the client.
• Production environments: The handler can be configured to allow the request to complete while emitting a warning in the logs.

Depending on your environment, you can start the server using one of the following methods:

• In IDE: Run the com.networknt.server.Server main class.
• From Maven: Use the exec:exec goal.
• Command Line: Run the generated JAR file.

### From Maven
mvn exec:exec

### Command Line
java -jar target/demo-0.1.0.jar

You can start a new project using one of two methods:

1. Light-codegen generator: Use the light-codegen tool to generate a working project. It currently supports light-rest-4j, light-graphql-4j, light-hybrid-server-4j, and light-hybrid-service-4j. You can use it via:
   • The codegen-cli command line utility after building the project.
   • The networknt/light-codegen Docker image.
   • The generate.sh script from the model-config repository.
   • The codegen-web API (UI pending).
2. Example projects: Copy and adapt an existing project from light-example-4j. Detailed descriptions of examples and tutorials are available on the official website.

While Ctrl+C can be used to kill the server, for production environments you should use the TERM signal to allow the server's shutdown hook to execute. This ensures the server can:

• Complete in-flight requests.
• Close database connections.
• Notify service registries (if using discovery) and wait for clients to refresh their local cache (up to 30 seconds) before shutting down.

kill -s TERM <pid>

To implement or use the proxy functionality, refer to the following resources:

• Source Code: Visit the light-proxy GitHub repository.
• Core Concepts: Read the Getting Started guide.
• RESTful Proxy Implementation: Follow the Tutorial for a step-by-step guide.
• Configuration: Consult the Configuration documentation to adapt the proxy to your specific requirements.
• Deployment: Use the Artifact guide to select the correct artifact for your deployment environment.