Faisal Masood

Developer. Build platforms and help customer write better code.

Areas of Expertise

Programming, Containers, Cloud

Recent Posts

Using a Kotlin-based gRPC API with Envoy proxy for server-side load balancing

Using a Kotlin-based gRPC API with Envoy proxy for server-side load balancing

These days, microservices-based architectures are being implemented almost everywhere. One business function could be using a few microservices that generate lots of network traffic in the form of messages being passed around. If we can make the way we pass messages more efficient by having a smaller message size, we could  the same infrastructure to handle higher loads.

Protobuf (short for “protocol buffers”) provides language- and platform-neutral mechanisms for serializing structured data for use in communications protocols, data storage, and more. gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. Together, they provide an efficient message format that is automatically compressed and provides first-class support for complex data structures among other benefits (unlike JSON).

Microservices environments require lots of communication between services, and for this to happen, services need to agree on a few things. They need to agree on an API for exchanging data, for example, POST (or PUT) and GET to send and receive messages. And they need to agree on the format of the data (JSON). Clients calling the service also need to write lots of boilerplate code to make the remote calls (frameworks!). Protobuf and gRPC provide a way to define the schema of the message (JSON cannot) and generate skeleton code to consume a gRPC service (no frameworks required).

Continue reading “Using a Kotlin-based gRPC API with Envoy proxy for server-side load balancing”

Share
Writing better Spring applications using SpringFu

Writing better Spring applications using SpringFu

“Truth can only be found in one place: the code,” Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship.

The way we structure our code has a direct impact on how understandable is it. Code that is easy to follow with no or less hidden functionality is much easier to maintain. It also makes it easier for our fellow programmers to track down bugs in the code. This helps us to avoid Venkat’s Jesus Driven Development.

The way I write Spring applications comprises heavy use of Spring annotations. The problem with this approach is that partial flow of the application is controlled by annotations. The complete flow of my code is not in one place, that is, in my code. I need to look back to the documentation to understand the annotations’ behavior. By reading just the code, it is difficult to predict the flow of control.

Luckily, Spring has a new way to code to and it has been called Spring Functional or SpringFu. In this article, I will use Kotlin to showcase some of the benefits you get from SpringFu.

Continue reading “Writing better Spring applications using SpringFu”

Share
How Kotlin’s coroutines improve code readability

How Kotlin’s coroutines improve code readability

Programs must be written for people to read, and only incidentally for machines to execute. — Abelson and Sussman

Kotlin is a new practical language designed to solve real-world problems. It is based on JVM but there are many differences between Kotlin and Java. Kotlin is a null-safe and concise language with support for functional programming. You can try programming in Kotlin here.

Kotlin coroutines provide an easy way to write highly scalable code, using the traditional style of programming, while avoiding having a thread allocated to each task.

In this article, I focus on code readability and how, in my opinion, coroutines provide a cleaner approach to writing code compared to a reactive approach. I have used Project Reactor to showcase the reactive code; however, the example can be extended to any reactive library, for example, RxJava and CompleteableFuture. Note that coroutine-based code scales as well as code written using a reactive approach. To me, coroutines are a win-win situation for developers.

Continue reading “How Kotlin’s coroutines improve code readability”

Share
Asynchronous communication between microservices using AMQP and Vert.x

Asynchronous communication between microservices using AMQP and Vert.x

Microservices are the go-to architecture in most new, modern software solutions. They are (mostly) designed to do one thing, and they must talk to each other to accomplish a business use-case. All communication between the microservices is via network calls; this pattern avoids tight coupling between services and provides better separation between them.

There are basically two styles of communication: synchronous and asynchronous. These two styles applied properly are the foundation for request-reply and event-driven patterns. In the case of the request-reply pattern, a client initiates a request and typically waits synchronously for the reply. However, there are cases where the client could decide not to wait and register a callback with the other party, which is an example of the request-reply pattern in an asynchronous fashion.

In this article, I am showcasing the approach of asynchronous request-reply by having two services communicate with each other over Advanced Message Queuing Protocol (AMQP). AMQP is an open standard for passing business messages between applications or organizations. Although this article focuses on the request-reply pattern, the same code can be used to develop additional scenarios like event sourcing. Communicating using an asynchronous model can be very beneficial for implementing the aggregator pattern.

I will be using Apache QPid Proton (or Red Hat AMQ Interconnect) as the message router and the Vert.x AMQP bridge for communication between the two services.

Continue reading “Asynchronous communication between microservices using AMQP and Vert.x”

Share
Natively compile Java code for better startup time

Natively compile Java code for better startup time

Microservices and serverless architectures are being implemented, or are a part of the roadmap, in most modern solution stacks. Given that Java is still the dominant language for business applications, the need for reducing the startup time for Java is becoming more important. Serverless architectures are one such area that needs faster startup times, and applications hosted on container platforms such as Red Hat Openshift can benefit from both fast Java startup time and a smaller Docker image size.

Let’s see how GraalVM can be beneficial for Java-based programs in terms of speed and size improvements. Surely, these gains are not bound to containers or serverless architectures and can be applied to a variety of use cases.

Continue reading “Natively compile Java code for better startup time”

Share