This article is part of the series  GoLang: Building a Web Server

In the  previous article, we explored how we can convert a manually wired HTTP web server into a DI based web server using the  Fx library. Now once we have that in place, our next step is to add functionalities to our server .i.e business logic. But before we jump into that, we need to first understand how to write modules for our Fx Server. These modules will act as building blocks for our application.

What is a module?

Generically speaking, a module is a piece of program that is independent and interchangeable, such that each module contains everything necessary to execute only one aspect of the desired functionality. (Source:  Wikipedia).

When we write a line of code, we achieve a mini-goal with that. This might be our business logic, trimming trailing spaces from a string, or maybe getting the current system time, etc. Each of these cases is unique and can exist independently and has a meaning to it, so shall we go ahead and create a module out of it? Well, I don’t think so.

We should be thoughtful while defining modules. An ideal scenario to create a module would be when you want to encapsulate some behavior such that it is reusable across the application and at times outside the application as well. Generally, this behavior is exposed outside the module using an interface. For example, a few good use cases to create a module would be logging module, metric module, authorization module, etc.

What is an Fx Module?

As we saw in the  last article, that all Fx does is that it injects an object into another object. And in order to inject object A into object B, it needs to have object A inplace beforehand. So where does it gets object A in the first place from?

Confusing…right?

Let’s try to simplify it, when Fx creates a new object (we call it OBJ1, hereafter) it looks up for the dependencies that OBJ1 needs.

Case1: No dependencies required, OBJ1 is created in the application context.

Case 2: Fx finds the needed dependencies in the application context, injects them and OBJ1 is created.

Where did all of this happen? It happened inside a fx.provide call, which in turn is part of a module whose responsibility is to create OBJ1 and provide it to the application context when the New method is called in the Fx lifecycle. ( Fx Documentation)

Fx is designed on the concepts of  Modular programming. Whenever you write a line of code in an application that is achieving DI using Fx, it is always a part of some module(unless manually wired). You already wrote code inside a module when you converted your application into an Fx application.

#golang #modular-programming #logging