Light Mesh

Several sidecars in the light-mesh project can be used as a sidecar container in a Kubernetes pod along with your API built with any frameworks or languages to address cross-cutting concerns. With most of the cross-cutting concerns addressed, your developers can focus on the business logic only in the backend API.

The light-proxy can be used as a sidecar to address cross-cutting concerns for APIs built with any framework and language.

Kafka sidecar contains both producer and consumers (consumer group, stream processor and ksqldb subscriber) to interact with a Kafka cluster without the developer knowing Kafka client. All the interactions to Kafka are through the sidecar with REST APIs. Like using the light-proxy as a sidecar, we can leverage light-4j middleware handlers to address cross-cutting concerns at the sidecar level and propagate tracer to the ProducerRecord headers.

HTTP Sidecar

There are two ways to implement a complete distributed microservices application with Light in a Kubernetes cluster: Embedded and Sidecar. If you use Java 8 or Java 11 to implement your service, you can leverage one of the Light frameworks with cross-cutting concerns embedded in the request/response chain. The other option is to use the HTTP Sidecar container in the same pod to address the cross-cutting concerns at the network level. Read More »

Kafka Sidecar

The Kafka sidecar is designed to address the following concerns for distributed microservices to leverage asynchronous event-based communications instead of synchronous request/response over HTTP. Hide the complicity of Kafka client Unlike traditional server-heavy messaging systems, Kafka’s server is just a set of appended logs; however, the Kafka client is much more complicated. It is not an easy task to build a producer or consumer in microservices within a multi-threaded context. Read More »