Decoupling access to the data stores

One fundamental issue with the monolithic implementation from the previous chapter is that our application was talking directly to the Elasticsearch and CockroachDB clusters. We have effectively introduced a tight coupling between the application and the data store implementations.

Now that it's time to create the microservice-based version of Links 'R' Us, we need to take a few steps to rectify this problem. To this end, the first two services that we will be creating as part of our refactoring work will serve as a kind of proxy for facilitating access to the underlying data stores. The text-indexer and link-graph services will be deployed in the linksrus-data namespace and allow other services to interact with the data stores through the gRPC-based APIs that we defined in Chapter 9Communicating with the Outside World.

An important benefit of introducing an indirection layer between the services and the data stores is that we gain the ability to change the data store implementation at any moment without having to change, update, or otherwise reconfigure any of the other Links 'R' Us services.

In terms of service implementation, things are surprisingly simple. Each service binary receives the URI of the data store to connect to as an argument. Then, it creates a gRPC server on port 8080 and exposes the pprof debug endpoints on port 6060. All the boilerplate code fits nicely into a single main file, which you can find in the Chapter11/linksrus/linkgraph and Chapter11/linksrus/textindexer folders of this book's GitHub repository.