We’ve already briefly touched on the e-commerce application in Chapter 1: Evolution to Microservices, and we’ll continue in that vein throughout the rest of the book. The e-commerce domain is one that many people are very familiar with, and although we may not understand all the moving pieces, it is simple enough to grasp.

The first microservice in the vast array of services that make up an e-commerce application that we’ll look at is the Basket microservice:

Before we dive straight into our IDE, let’s scope out what functionality makes up a basket.

Components of a Basket Microservice

On the face of it, the basket microservice may seem simple, but there are more moving pieces than initially thought.

First and foremost, we need some way to interact with our basket. In microservices, we can achieve this in a couple of ways. First, we have HTTP endpoints. These are the simplest (usually) to implement and provide us with a strong contract to adhere to (REST).

Next, is gRPC. Although it is much faster than HTTP, it requires more specialized tooling and setup and is less ubiquitous than HTTP. Finally, we have a message or queue-based communication. This is the most resilient of the options, as we can publish messages to a message broker and not have to communicate directly with our Basket microservice. But, this is usually the slowest communication method, so it may not suit our particular use case.

Given the options we have listed above, HTTP seems the most sensible for our Basket microservice, so we’ll implement an HTTP API for other services to communicate with. In terms of the actions we want to carry out against a basket, the most obvious is the ability to add products to it. Also, we want the ability to retrieve a basket for a given user so we can display it to them in the frontend.

Finally, users will want to remove products from their basket. So, that sounds like three straightforward endpoints to get us started!