API

Backend-for-Frontend: The Demo

Let’s use a very simple e-commerce use-case to demo how to implement the Backend-for-Frontend with and without the help of Apache APISIX.

Write Your Own Service Discovery Client for Apache APISIX

Most modern infrastructures are dynamic – servers are cattle, not pets. In this article, I describe how to implement a dynamic node registry based on a YAML file.

Discussing Backend For Front-end

The idea behind BFF is to move logic from each microservice to a dedicated deployable endpoint.

Avoiding Stringly-typed in Kotlin

It is more beneficial to use sealed and value class instead of enumerations in Kotlin; let’s find out why.

System Logger

Almost all Java developers are familiar with logging frameworks like Log4j and the facade SLF4J, but not the System.Logger that has been available since java 9. Let’s learn about the standard.

Beautify Third-Party APIs with Kotlin

Learn how to improve the API provided by third-party libraries by combining Kotlin extension functions and delegation.

Why a Serverless Data API Might be Your Next Database

Serverless data offers benefits, but market offerings are limited. What serverless data can, should, or could do isn’t always understood.

Extending Third-Party APIs in Different Languages

I’d like to describe how to add new behavior to an existing object/type. I won’t use any reactive type to make it more general.

Hacking Third-Party APIs on the JVM

The JVM ecosystem is mature and offers plenty of libraries, so you don’t need to reinvent the wheel. Basic – and not so basic – functionalities are just a dependency away. Sometimes, however, the dependency and your use-case are slightly misaligned.

The correct way to fix this would be to create a Pull Request. But your deadline is tomorrow: you need to make it work now! It’s time to hack the provided API.

In this article, we are going through some alternatives that allow you to make third-party APIs behave in a way that their designers didn’t intend to.

Teeing: Hidden Gem in the Java API

Last week, I described a use-case for a custom Stream Collector. I received a intriguing comment on Twitter.

So I decided to investigate what is the teeing() method about, which returns a Collector that is a composite of two downstream collectors.

Every element passed to the resulting collector is processed by both downstream collectors, then their results are merged using the specified merge function into the final result.

A Real-World Example of a Stream Collector

You can solve most use cases with one of the out-of-the-box collectors provided in the Collectors class.

However, some require to implement a custom Collector, e.g., when you need to collect more than a single collection or a single scalar.

While it may seem complicated if you never developed one before, it’s not. You only need a bit of practice.

I hope this article might help you with it!

Optional.stream()

This week, I learned about a nifty “new” feature of Optional that I want to share in this post. It’s available since Java 9, so its novelty is relative.

We start with a sequence to compute the total price of an order, for which it is nowadays more adequate to use streams instead of iterations.

Optional makes the code less readable! I believe that readability should trump code style every single time.

Fortunately, Optional offers a stream() method (since Java 9). It allows to simplify the functional pipeline. Functional code doesn’t necessarily mean readable code. With the last changes, I believe it’s both.