If you've been working with FastAPI, you've likely encountered dependencies in action. Perhaps you saw Depends() in a tutorial or the docs and were confused for a minute. I certainly was. That confusion sparked weeks of experimenting with this system. The truth is, you can't avoid dependency injection when building backend services with FastAPI. It's baked into the framework's DNA, powering everything from authentication and database connections to request validation.

FastAPI's docs describe its dependency injection system as 'powerful but intuitive.' That’s accurate, once you understand how it works. This article breaks it down, covering function dependencies, class dependencies, dependency scopes, as well as practical examples.

Table of Contents

• Prerequisites

• Dependencies and Dependency Injection in FastAPI

• Getting Started: Environment Setup

• Types of Dependencies in FastAPI

  • How to Use Function Dependencies in FastAPI

  • How to Use Class Dependencies in FastAPI

• Dependency Scope

  • Path Operation Level

  • Router Level

  • Application Level

• Common Use Cases for Dependency Injection

• Conclusion

Prerequisites

To follow along with this article, you should have:

• Working knowledge of Python.

• Ability to create and activate virtual environments.

• Basic understanding of FastAPI.

• Familiarity with Object-Oriented Programming (OOP) concepts.

Dependencies and Dependency Injection in FastAPI

A dependency is a reusable piece of logic, like authentication, database connection, or validation, that your path operations require. Dependency injection (DI) is how FastAPI delivers these dependencies to specific parts of your application: you declare them using Depends() and FastAPI automatically executes them when the associated route receives a request.

Think of it as requesting the tools your application needs. You declare dependencies once and FastAPI provides them wherever needed, with no repetitive setup across routes.

This makes for modular, scalable applications. Without DI, you would have to repeat the same setup code on every endpoint, making updates tedious and bugs more likely.

Getting Started: Environment Setup

Let's set up your development environment to work through the examples in this guide.

Start by creating a project folder, then:

Create and activate a virtual environment:

python -m venv deps
source deps/bin/activate          #on Mac
deps\Scripts\activate             # On Windows

Install FastAPI with all dependencies:

pip install 'fastapi[all]'

Organize your project as follows:

fastapi-deps/
├── deps/                 # Virtual environment
├── function_deps.py
├── class_deps.py
├── router_deps.py
├── app.py
└── requirements.txt

Types of Dependencies in FastAPI

In FastAPI, a dependency is a callable object that retrieves or verifies information before a route executes. Dependencies can be implemented as either functions or classes.

Function dependencies are the most straightforward approach and work well for most use cases, including validation, authentication, and data retrieval. Class dependencies can handle the same tasks but are particularly useful when you need stateful logic, multiple instances with different configurations, or prefer object-oriented patterns.

How to Use Function Dependencies in FastAPI

A function dependency is a helper function (such as for authentication or data retrieval) that can be injected into path operations. To demonstrate, we'll create a simple user authentication dependency using an in-memory database—a list of dictionaries.

Recall the folder structure from earlier? We’ll write this code in fastapi-deps/function_deps.py.

Start by importing the required modules:

from fastapi import FastAPI, Depends, HTTPException
import uvicorn

You bring in FastAPI to create the app instance, Depends for dependency injection, and HTTPException to handle errors gracefully. uvicorn will be used to run the application later.

Next, instantiate the FastAPI application:

app = FastAPI()

app = FastAPI() creates your application instance: the object that will hold all your endpoints and dependencies.

Next, create an in-memory database. Define a list of dictionaries to act as your temporary database. Each dictionary represents a user entry containing a name and a password.

users = [
    {"name": "Ore", "password": "jkzvdgwya12"},
    {"name": "Uche", "password": "lga546"},
    {"name": "Seke", "password": "SK99!"},
    {"name": "Afi", "password": "Afi@144"},
    {"name": "Sam", "password": "goTiger72*"},
    {"name": "Ozi", "password": "xx%hI"},
    {"name": "Ella", "password": "Opecluv18"},
    {"name": "Claire", "password": "cBoss@14G"},
    {"name": "Sena", "password": "SenDaBoss5"},
    {"name": "Ify", "password": "184Norab"}  
]

Then, define a dependency function for user validation. The simple helper function below checks whether a username and password provided by the user match an existing user in the database.

#the dependency function
def user_dep(name: str, password: str):
    for u in users:
        if u["name"] == name and u["password"] == password:
            return {"name": name, "valid": True}

This function expects two string parameters, name and password, from the incoming request. If it finds a match in the users database, it returns a dictionary confirming the user’s validity. FastAPI automatically converts this dictionary into a JSON response.

Next, inject the dependency into a path function:

#the web endpoint
@app.get("/users/{user}")
def get_user(user = Depends(user_dep)) -> dict:
    if not user:
        raise HTTPException(status_code=401, detail="Invalid username or password")
    return user

The user_dep function is injected into the path operation using Depends(). When an HTTP request is made to this endpoint, FastAPI executes the dependency first, validates the input, and passes its return value to the user parameter.

The -> dict: annotation indicates that the function returns a dictionary, which FastAPI auto-converts to JSON. If no matching record is found, an HTTPException with a 401 status code is raised; otherwise, the verified user data is returned.

Now you’ll start the FastAPI server. To start the server, open your terminal in the project directory and run:

uvicorn function_deps:app --reload

• function_deps is the name of your Python file (without the .py extension).

• --reload automatically restarts the server whenever you save changes.

Once it starts, you’ll see an output similar to the image below:

Now you can test the endpoint. Open your browser or the Postman desktop app to validate the user “Seke”. Paste this URL into your browser: http://127.0.0.1:8000/users/{user}?name=Seke&password=SK99!

Alternatively, you can test the endpoint using FastAPI’s built-in docs at: http://127.0.0.1:8000/docs

In the Swagger UI:

• Click on the Get User endpoint

• Click Try it out

• Enter “Seke” in the name field and “SK99!” in the password field

• Click Execute

You should get a 200 status code, with the payload in this image:

You can also test the endpoint with usernames or passwords that don’t exist in the database. Each time, you should see a 401 error like this:

How to Use Class Dependencies in FastAPI

While functions are the most common way to define dependencies, FastAPI also supports class-based dependencies. Classes are useful when you need reusable instances with configurable state or prefer object-oriented patterns.

Class dependencies inject the same way: through the Depends function in your path operation.

Let's convert the user_dep function dependency to a class. It will authenticate users, grant access to valid credentials, and raise exceptions for unauthorized attempts. We'll apply it to a user dashboard endpoint to ensure only authenticated users access their resources.

#Dependency class for user authentication
class UserAuth():
    def __init__(self, name: str, password: str):
        self.name = name
        self.password = password

    def __call__(self):
        #check if name and password entered correspond to any row in the db
        for user in users:
            if user["name"] == self.name and user["password"] == self.password:
                pass
        #If no match found, raise an error
        raise HTTPException(status_code=401, detail="Invalid username or password")

The __init__ method receives the parameters from the request (name and password) and stores them as instance attributes. These can then be accessed in the __call__ method, which contains the dependency logic.

Note that __call__ doesn't return a value in this example. It simply raises an HTTPException if authentication fails. The __call__ method makes the class instance callable, allowing FastAPI to invoke it like a regular function.

Here’s how to inject UserAuth into a path function:

#Injecting the class dependency into a path operation
@app.get("/user/dashboard")
def get_dashboard(user: UserAuth = Depends(UserAuth)):
    return {"message": f"Access granted to {user.name}"}

What's happening here:

When a client requests the /user/dashboard endpoint, FastAPI executes the dependency first. Recognizing UserAuth as a class, FastAPI automatically creates an instance and populates it with values from the query parameters.

Here’s the execution flow to help you understand:

• Depends(UserAuth) tells FastAPI: “Before running this route, create a UserAuth instance.”

• FastAPI extracts name and password from the request URL (for example, /user/dashboard?name=Seke&password=SK99!).

• It then calls UserAuth(name=”Seke”, password=”SK99!”) to create the instance.

• The UserAuth instance, with its stored name and password attributes, is passed to the user parameter in get_dashboard.

• The route function can access user.name and user.password directly.

• If __call__ raises an exception, the route never executes.

Test the endpoint with valid credentials from the users list, and you should see output like this:

A closer look at FastAPI’s official documentation provides an alternative approach to classes as dependencies. However, using the __call__ method, in my opinion, is the most straightforward and self-contained approach. It keeps your authentication logic modular without adding extra code to the path operation.

The trade-off is that class dependencies are more verbose than helper functions, but cleaner for complex logic.

Dependency Scope

FastAPI offers two ways to inject dependencies into a path operation: as a function parameter or via the path decorator. When you include a dependency as a function parameter, the dependency's return value is available within the function. But when injected into the decorator, the dependency executes without passing a return value to the path function.

Beyond single endpoints, FastAPI lets you inject dependencies at the router or global level. Let’s examine these scopes in more detail.

Path Operation Level

While the first example injected dependencies into path function parameters, you can also inject them directly into the decorator using the dependencies parameter. This approach is useful for side-effects (for example, authentication guards, rate limiting or request logging) where the return data is not required in the path operation.

Replace the previous code in fastapi-deps/function_deps.py with this:

#dep function to pass in decorator
def user_dep(name: str, password: str):
    for u in users:
        if u["name"] == name and u["password"] == password:
            return
    raise HTTPException(status_code=401, detail="Invalid username or password")

#path function
@app.get("/users/{user}", dependencies=[Depends(user_dep)])
def get_user() -> dict:
    return {"message" : "Access granted!"}

This decorator-based dependency acts as a pre-check before the endpoint executes. It validates credentials without passing any values to the path function. On authentication failure, FastAPI raises an HTTPException and prevents the path operation from running.

If you test this using a valid name and password from the in-memory database, your output should look like this:

Router Level

Injecting dependencies at the router level allows multiple endpoints to share common logic without repeating the dependency in each route.

We'll use the same user_dep function but inject it at the router level. Add these imports to fastapi-deps/router_deps.py:

from fastapi import APIRouter, Depends

#import the dependency function
from function_deps import user_dep

Then, create an APIRouter instance, passing your dependency to the dependencies parameter. This makes the dependency run automatically for every route you define under this router.

In this example, user_dep executes before get_user() and any other endpoints you add to the router, eliminating the need to declare it on each route.

router = APIRouter(prefix="/users", dependencies=[Depends(user_dep)])

#define the routes with or without additional dependencies
@router.get("/{user}")
def get_user() -> dict:
    return {"message" : "Access granted!"}

In your main application file (app.py), import the router and register it with your FastAPI application using include_router(). This makes all routes defined in the router accessible through your application.

from fastapi import FastAPI
import uvicorn
from router_deps import router as user_router

app = FastAPI()
app.include_router(user_router)

if __name__ == "__main__":
    uvicorn.run("app:app", reload=True)

Start your server and test the route using a valid name–password pair from the users list, then try a mismatched one. You should get a 200 status for the correct credentials and 401 for invalid ones.

Application Level

Application-level dependencies (also called global dependencies) are defined when instantiating the FastAPI app and apply to every route in your application. Unlike router-level dependencies that target specific endpoint groups, app-level dependencies extend across the entire application. Any dependency injected into the FastAPI app object will automatically execute for all path functions.

Let's inject a simple logging dependency alongside the user authentication dependency we've used throughout this article.

Update fastapi-deps/app.py with this code:

from fastapi import FastAPI, Depends
import uvicorn
from function_deps import user_dep
from router_deps import router as user_router
from datetime import datetime

#Basic logging dependency
def log_request():
    print(f"[{datetime.now()}] Request received.")

app = FastAPI(dependencies=[Depends(log_request), Depends(user_dep)])
app.include_router(user_router)

@app.get("/home")
def get_main():
    return "Welcome back!!!"


if __name__ == "__main__":
    uvicorn.run("app:app", reload=True)

When you send a request to any endpoint within this application, log_request acknowledges it and outputs what time the request was made. Since we aren’t sending the logs to any database in particular, it will just print to the terminal (or console) like so:

Request the endpoint with valid credentials using your browser, cURL, Postman, or the Swagger UI. You should get this response:

Common Use Cases for Dependency Injection

Dependency injection solves several common challenges in API development. Here are the most frequent use cases where you'll apply this pattern.

1. Database Connections: Reusing connection logic across multiple endpoints prevents connection leaks, and ensures each request has an isolated session.

2. Authentication & Authorization: Dependencies help validate tokens and verify user roles across protected routes.

3. Logging & Monitoring: A logging dependency can automatically record each request to your monitoring system or database. It is beneficial for debugging and tracking API usage.

4. Rate Limiting: You can control request frequency and prevent API abuse by injecting rate-limiting logic in path functions.

5. Configuration & Settings: FastAPI’s dependency injection system simplifies configuration management by letting you inject settings such as API keys or environment variables wherever needed, keeping your code consistent.

6. Pagination & Filtering: Injecting common parameters like page_size and limit standardize data retrieval patterns across endpoints.

Conclusion

FastAPI's dependency injection system helps you manage shared logic and resources efficiently while adhering to DRY principles. However, knowing when to inject a dependency versus when to skip it is a skill that comes with practice.

Dependency injection isn't needed for simple, standalone logic. But for resources requiring lifecycle management, shared logic, or modularity, FastAPI's dependency injection system simplifies checks and app operations—with or without return values.

This growing web of dependencies can quickly become a problem. When the relationships between components are unclear or tightly coupled, the codebase becomes harder to test, refactor, and maintain. Making changes or adding new features can introduce unexpected bugs, and isolating parts of the system for testing often requires pulling in far more than you intended.

Consider a team working on a backend service. At first, the codebase is manageable: a few handlers, a database connection, maybe a logger. But as the product matures, new requirements appear: authentication, caching, integrations with third-party APIs, background jobs, and more. Suddenly, a single handler might need access to several services, each with their own dependencies. The team finds themselves spending more time figuring out what needs what, and less time actually building features. Testing becomes a headache, and refactoring feels risky.

Why is this such a challenge? When dependencies are hidden inside components, it's hard to see how everything fits together. Tightly coupled code means that a change in one place can ripple unpredictably through the system. It's easy to end up with fragile code that's difficult to test, hard to extend, and risky to modify.

One way to address this challenge is dependency injection - often referred to as DI. The core idea is straightforward: instead of having each part of a program create its own dependencies, those dependencies are provided from the outside. This makes the relationships between components explicit, allowing for easier testing, swapping of implementations, and greater flexibility as the project evolves.

DI isn't about frameworks or enterprise patterns, it's a practical technique for structuring code so that complexity remains manageable. By making dependencies clear and configurable, DI helps keep code maintainable and adaptable, no matter how requirements change.

In this tutorial, we'll cover:

• What dependency injection is in Go.

• How to implement manual DI, the idiomatic way.

• When manual DI becomes unwieldy.

• Popular DI libraries in Go.

• Best practices for managing dependencies in real-world projects.

By the end of this guide, you'll have a clear understanding of DI in Go and know how to choose the right approach for your projects.

What We’ll Cover:

• Prerequisites

• What is Dependency Injection?

• Manual DI in Go

  • The Repository Layer

  • The Service Layer

  • The Handler Layer

  • Wiring It All Together in main.go

  • Why Manual DI Works Well in Go

  • Downsides of Manual DI

  • A Quick Testing Example

  • Takeaway

  • Exercise for the Reader

• When DI Gets Hard

  • Nested Dependencies

  • Testing at Scale

  • Configuration Complexity

  • Patterns to Mitigate Complexity

  • When Developers Consider DI Frameworks

  • Key Takeaways

• Go DI Libraries and Tools

  • Google Wire (Compile-Time DI)

  • Uber Dig (Runtime DI)

  • Uber Fx (DI + App Lifecycle)

  • Other Lightweight DI Helpers

• Choosing the Right Tool

  • Key Takeaways

  • Exercise for the Reader

• Best Practices and Takeaways

  • Prefer Explicit Dependencies

  • Start Simple (Manual DI)

  • Use Frameworks to Tame Complexity

  • Keep Wiring at the Edges

  • Favor Interfaces for Testability

  • Avoid Over-Engineering

  • Balance Verbosity and Magic

  • Adopt Incrementally

  • Document Your Wiring

  • Key Takeaways

• Conclusion

Prerequisites

This article assumes you understand the basics of Go. You don't need to be an expert, but you should be comfortable with:

• Functions and structs – understanding how to define types and their methods.

• Interfaces – knowing how to declare and implement them.

• Packages and imports – organizing code across files and packages.

• Basic Go web server – familiarity with net/http and simple handlers will help when we build examples.

If you've read the earlier freeCodeCamp guides on Go collections and standard library helpers, you're in good shape. If not, don't worry - all code examples here are self-contained and explained step by step.

You'll also need:

• Go installed (1.20 or later recommended)

• A text editor or IDE of your choice

• Be comfortable running go run from the terminal

That's it. No special libraries are required unless we explicitly install them in later sections (for example, when we explore wire, dig, or fx).

What is Dependency Injection?

Let's start with a simple example. Imagine a web handler that fetches a user from a database. Without DI, it might look like this:

type UserService struct{}

func (us *UserService) GetUser(id int) string {
    // Pretend we fetch a user from the database
    return "user"
}

type Handler struct {
    userService UserService
}

func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    user := h.userService.GetUser(1)
    fmt.Fprintln(w, user)
}

Here, Handler is tightly coupled to UserService. We can't easily swap out UserService for a mock in tests or replace it with a different implementation.

With dependency injection, we pass the dependency into the struct, usually via a constructor function:

type UserService interface {
    GetUser(id int) string
}

type Handler struct {
    userService UserService
}

func NewHandler(us UserService) *Handler {
    return &Handler{userService: us}
}

Now Handler doesn't care how the UserService is created. That decision is left to the calling code (main.go or a test). This is the essence of DI: you inject what a component needs rather than letting it create it internally.

This approach has several benefits:

• Testability: You can easily pass a mock or fake UserService when testing Handler.

• Flexibility: You can swap out implementations without changing Handler.

• Separation of Concerns: Each component focuses on its own logic without worrying about how its dependencies are created.

As you can see, the concept is quite simple, but it has powerful implications for how you structure your code. Explicitly managing dependencies has many benefits and barely any downsides. Maybe you have to write some extra boilerplate, but this is a small price to pay for the clarity and flexibility it brings.

The principle of dependency injection is not unique to Go, it's a general software design principle you can find in many programming languages. However, the way you implement it can vary by language, ecosystem, and your specific use case. It's a recurring theme in higher-level design patterns: they tell you what to achieve, but they are not bothered with the details of how to implement it.

So the key idea is to explicitly manage dependencies by passing them in, rather than letting components fetch or create them themselves. This can be done a couple of ways:

• Constructor Injection: As shown above, dependencies are provided via constructor functions. This is the most common and idiomatic way in Go.

• Field Injection: Dependencies are set directly on struct fields. This is less common in Go and not considered idiomatic, but can be useful in some scenarios.

• Method Injection: Dependencies are passed as parameters to methods. This is also less common in Go, but can be useful in certain situations.

The most universal approach in Go is constructor injection. Field and Method injection is less common, mainly because they can lead to less clear code and harder-to-track dependencies (it's always better to see what a component needs upfront in the constructor than to have it hidden in method calls or field assignments).

Manual DI in Go

The most common and idiomatic way to handle dependencies in Go is to wire them manually. That might sound boring, but it's actually one of Go's strengths: you always know where a dependency comes from, and nothing is hidden behind a framework. Especially if you inject dependencies via constructors, it's always clear what a component needs in order to work properly. This explicitness is a key part of Go's philosophy: you make the dependencies obvious and explicit, so that anyone reading the code can easily understand how components fit together.

Let's build a small web application with three layers to see how this works in practice:

• A repository that talks to the database.

• A service that contains business logic.

• A handler that exposes an HTTP endpoint.

We'll then wire these pieces together in main.go.

The Repository Layer

At the bottom of the stack, we'll define a UserRepository. In a real-world project, this would talk to a database, but for simplicity we’ll just return some dummy data.

type UserRepository struct {
    // Imagine this struct holds a database client
}

func NewUserRepository() *UserRepository {
    return &UserRepository{}
}

func (r *UserRepository) FindUser(id int) string {
    // In a real app, this would query the database
    return fmt.Sprintf("user-%d", id)
}

The key thing here is the constructor NewUserRepository(). This is a Go convention:

• Functions named NewXxx create and return new instances.

• They make wiring dependencies explicit.

(We call it a "constructor" because Go doesn't have constructors in the traditional OOP sense. Instead, we use functions that return initialized structs, which is closer to factory functions, but the term "constructor" is commonly used in Go parlance.)

The Service Layer

Above the repository, we'll add a service that uses it:

type UserService struct {
    repo *UserRepository
}

func NewUserService(r *UserRepository) *UserService {
    return &UserService{repo: r}
}

func (s *UserService) GetUser(id int) string {
    // Add some business logic here
    return s.repo.FindUser(id)
}

The UserService depends on the repository. Notice that the dependency is passed into the "constructor". This is dependency injection in action: instead of UserService creating its own repository, we give it one.

This also makes the service easy to test. In tests, we can pass a fake repository instead of the real one.

The Handler Layer

Finally, at the top, let's add a web handler. This is what responds to HTTP requests:

type Handler struct {
    service *UserService
}

func NewHandler(s *UserService) *Handler {
    return &Handler{service: s}
}

func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    user := h.service.GetUser(1)
    fmt.Fprintln(w, user)
}

The handler depends on the service. Again, we inject the dependency through the constructor.

Wiring It All Together in main.go

Now we need to put the pieces together. Going from the bottom up, we create the repository, then the service, and finally the handler. This is done in main.go:

func main() {
    repo := NewUserRepository()      // lowest layer
    service := NewUserService(repo)  // depends on repo
    handler := NewHandler(service)   // depends on service

    http.Handle("/user", handler)
    http.ListenAndServe(":8080", nil)
}

Here, main() is responsible for wiring everything together. This is a simple and clear way to manage dependencies:

• Each component declares what it needs via its constructor.

• main() creates and connects everything.

• The flow of dependencies is explicit and easy to follow.

• No hidden magic: everything is plain Go code, no frameworks or reflection.

If you run this program and visit http://localhost:8080/user, you'll see:

user-1

That's it. We've manually injected each dependency and wired everything together in main(). We have full control over how components are created and connected. We can easily swap out implementations, add new layers, or change the wiring as needed.

Why Manual DI Works Well in Go

This style of dependency management is the default in Go. It has several advantages:

• Explicit, clear dependencies: Every dependency is visible in the constructor. If UserService needs a repository, you see it right there in NewUserService(). Nothing is hidden.

• No magic: There are no reflection tricks, no hidden containers, no annotations. When you look at main.go, you see exactly how the application is assembled.

• Easy to test: Because dependencies are injected, you can pass mocks or stubs in tests. For example, you might create a FakeUserRepository and pass it to NewUserService() in a unit test. (And your fakeUserRepository would likely resemble the UserRepository above.)

• Great for small and medium apps: For most projects, this approach is all you need. Many production Go services at big companies use nothing more than manual DI.

Downsides of Manual DI

Of course, nothing is perfect. Manual DI has some drawbacks, especially as your application grows:

• Verbose main.go: As the number of services increases, main.go can become a wall of wiring code. You may have dozens of lines just creating and passing around dependencies. The same approach that works so well for small or medium apps can become unwieldy in very large projects.

• Nested dependencies: Imagine service A depends on service B, which depends on service C, which depends on a repository. By the time you wire everything in main.go, you might end up with long chains of constructor calls. Unlike our previous example, imagine hundreds of services and repositories. This can make the wiring code almost impossible to read and maintain.

• Scaling pain: In very large applications with many modules, it can be hard to keep track of which service depends on which other service. Once your application reaches a certain size, manual DI may no longer be sufficient. This is where various DI frameworks come in, as we'll see in a bit.

A Quick Testing Example

To see the benefit of manual DI, let's write a quick test. Suppose we want to test UserService without touching the real repository. We can define a fake repository:

type FakeUserRepository struct{}

func (f *FakeUserRepository) FindUser(id int) string {
    return "fake-user"
}

And then inject this into the service:

func TestUserService(t *testing.T) {
    fakeRepo := &FakeUserRepository{}
    service := NewUserService(fakeRepo)

    got := service.GetUser(1)
    want := "fake-user"

    if got != want {
        t.Errorf("got %s, want %s", got, want)
    }
}

This test is only possible because we injected the dependency. If UserService had created its own repository internally, we wouldn't be able to replace it.

Takeaway

Manual DI in Go is simple, explicit, and powerful. It's the idiomatic way to manage dependencies in Go applications. For many projects, it's all you'll ever need. In an ideal world, this article would end here and everybody could go on their merry way to build great software.

But as we'll see in the next section, when your project grows large and your wiring code gets out of hand, manual DI can start to feel painful. That's when developers often look for frameworks or tools to help.

Exercise for the Reader

We provided all the relevant code snippets in this section, but you can try building the full application yourself. Create a new Go module, add the repository, service, and handler layers as shown, and wire them together in main.go. Run the server and visit the endpoint to see it in action. Then, try writing a test for UserService using a fake repository. This hands-on practice will help solidify your understanding of manual DI in Go.

When DI Gets Hard

Manual dependency injection works beautifully in small to medium Go projects. It's explicit, testable, and easy to reason about. But as your application grows, wiring dependencies manually can become cumbersome. In this section, we'll explore the pain points that arise when manual DI scales, and why developers sometimes reach for DI frameworks or libraries.

Nested Dependencies

Consider a slightly larger project with multiple services:

• AuthService depends on UserService.

• UserService depends on UserRepository.

• EmailService depends on an SMTPClient.

• NotificationService depends on both EmailService and SMSService.

• Handler depends on AuthService and NotificationService.

If you try to wire all of this manually, your main.go starts to look like this:

func main() {
    userRepo := NewUserRepository()
    userService := NewUserService(userRepo)
    authService := NewAuthService(userService)

    smtpClient := NewSMTPClient("smtp.example.com")
    emailService := NewEmailService(smtpClient)
    smsService := NewSMSService()
    notificationService := NewNotificationService(emailService, smsService)

    handler := NewHandler(authService, notificationService)

    http.Handle("/signup", handler)
    http.ListenAndServe(":8080", nil)
}

This example is already verbose and hard to read, even though the application isn't very large. Imagine what happens when dozens of services and repositories are involved.

Problems you might notice:

• Long chains of dependencies: Services depend on other services, which depend on repositories, which might depend on database clients. The chain grows quickly and can be hard to manage.

• Wiring logic in main.go: main.go becomes full of constructor calls. While explicit, it can be difficult to see the overall structure of the application at a glance.

• Increased risk of mistakes: Passing the wrong dependency to a constructor or forgetting to wire a new service can cause runtime errors. Manual DI requires careful attention as projects scale.

Testing at Scale

Another challenge arises when testing large applications. Suppose you want to write integration tests for Handler with fake dependencies. You'll need to manually create fakes or mocks for every layer:

fakeRepo := &FakeUserRepository{}
fakeUserService := NewUserService(fakeRepo)
fakeAuthService := NewAuthService(fakeUserService)
fakeEmailService := &FakeEmailService{}
fakeSMSService := &FakeSMSService{}
fakeNotificationService := NewNotificationService(fakeEmailService, fakeSMSService)
handler := NewHandler(fakeAuthService, fakeNotificationService)

While this works, the test setup becomes verbose and repetitive, especially if multiple tests require different combinations of fake dependencies. This verbosity can make tests very hard to maintain.

Configuration Complexity

Some services require configuration or external clients, such as:

• Database connections

• HTTP clients

• API keys or credentials

• Logging frameworks

In manual DI, you often end up writing repetitive code to initialize and pass these dependencies around:

db := NewDatabase("postgres://user:pass@localhost:5432/db")
logger := NewLogger("INFO")
repo := NewUserRepository(db, logger)
service := NewUserService(repo, logger)
handler := NewHandler(service, logger)

As the number of dependencies grows, it's easy to forget a required parameter or misconfigure a service. This can result in runtime errors that are difficult to debug.

Patterns to Mitigate Complexity

Even without frameworks, there are some strategies to keep manual DI manageable:

1. Group related dependencies: If multiple services depend on the same configuration or clients, bundle them into a struct:

type AppDeps struct {
    DB     *Database
    Logger *Logger
}

func NewAppDeps() *AppDeps {
    db := NewDatabase("...")
    logger := NewLogger("INFO")
    return &AppDeps{DB: db, Logger: logger}
}

This reduces repetitive constructor parameters:

deps := NewAppDeps()
repo := NewUserRepository(deps.DB, deps.Logger)
service := NewUserService(repo, deps.Logger)

2. Layered constructors: Create higher-level constructors for feature modules:

func NewUserModule(deps *AppDeps) (*UserService, *UserHandler) {
    repo := NewUserRepository(deps.DB, deps.Logger)
    service := NewUserService(repo, deps.Logger)
    handler := NewHandler(service)
    return service, handler
}

This keeps main.go cleaner and encapsulates wiring for a specific module.

When Developers Consider DI Frameworks

Once your project grows beyond a handful of services, manual DI can become a maintenance burden:

• Long constructor chains

• Verbose test setup

• Repetitive wiring code

This is where Go DI libraries like Google Wire, Uber Dig, or Uber Fx can help. They automate some of the wiring while keeping dependencies explicit. Frameworks are not strictly necessary, but they can make large-scale projects more manageable. In the next section, we'll explore some popular DI libraries in Go, how they work, and when to consider using them.

Key Takeaways

• Manual DI is explicit, simple, and idiomatic. It works best in small to medium applications.

• As the number of dependencies grows, main.go can become long and repetitive.

• Testing complex services requires careful setup of fakes or mocks.

• Strategies like grouping dependencies or layered constructors can reduce boilerplate.

• For very large applications, DI frameworks can help manage wiring, but manual DI remains the foundation of idiomatic Go.

Go DI Libraries and Tools

Once your project grows beyond a handful of services, manually wiring all dependencies can become verbose and error-prone. That's where dependency injection libraries can help. Go doesn't force you to use them - manual DI is still idiomatic - but frameworks can simplify wiring in larger projects.

In this section, we'll explore some of the most popular Go DI tools:

• Google Wire (compile-time DI)

• Uber Dig (runtime DI)

• Uber Fx (DI with app lifecycle management)

• A brief look at other lightweight DI helpers

We'll show how each works, with examples, and discuss when to consider them.

Google Wire (Compile-Time DI)

Google Wire is a compile-time code generation tool. You define how dependencies relate to each other, and Wire generates the code to assemble them. There's no runtime magic, all the wiring is explicit in the generated code.

Example: Wire in Action

Suppose we have a simple service with a repository and handler:

type UserRepository struct{}
func NewUserRepository() *UserRepository { return &UserRepository{} }

type UserService struct { repo *UserRepository }
func NewUserService(r *UserRepository) *UserService { return &UserService{repo: r} }

type Handler struct { service *UserService }
func NewHandler(s *UserService) *Handler { return &Handler{service: s} }

With Wire, we define a provider set and an injector:

import "github.com/google/wire"

// Provider set
var Set = wire.NewSet(NewUserRepository, NewUserService, NewHandler)

// Injector function
func InitializeHandler() *Handler {
    wire.Build(Set) // generates code here to wire dependencies
    return nil
}

wire has a CLI tool that generates the code to wire up your dependencies. When you run wire in your project, it generates Go code for InitializeHandler(), assembling all dependencies. You can then use it in main.go:

func main() {
    handler := InitializeHandler()
    http.Handle("/user", handler)
    http.ListenAndServe(":8080", nil)
}

So basically, you define the dependencies in the provider set, then annotate the injector function with wire.Build(Set), and Wire generates the boilerplate for you in that function. The generated code is in a separate file.

Pros:

• No runtime overhead, wiring happens at compile-time.

• Generated code is readable and explicit.

• Safe: missing dependencies cause compile errors.

Cons:

• Requires an extra tool (wire CLI).

• Generated files add some noise to the codebase.

• Not as flexible for dynamic runtime configuration.

Uber Dig (Runtime DI)

Uber Dig is a runtime dependency injection container. Unlike Wire, Dig uses reflection to automatically resolve dependencies when you invoke them.

Example: Dig in Action

import "go.uber.org/dig"

func main() {
    c := dig.New() // create a new container

    // Provide constructors to the container
    c.Provide(NewUserRepository)
    c.Provide(NewUserService)
    c.Provide(NewHandler)

    // Invoke the function, letting Dig resolve dependencies
    err := c.Invoke(func(h *Handler) {
        http.Handle("/user", h)
    })
    if err != nil {
        log.Fatal(err)
    }

    http.ListenAndServe(":8080", nil)
}

Here, Dig inspects the constructors' parameters and automatically provides the required dependencies. You no longer have to manually pass each dependency in main(). It creates a container, then Provide() registers constructors with the container. Dig analyzes the parameters of each constructor to understand what dependencies are needed. Then c.Invoke(func(h *Handler) { ... }) asks Dig to call the provided function, automatically resolving and constructing all dependencies required for *Handler (using the registered constructors).

How Dig resolves dependencies:

• Dig looks at NewHandler and sees it needs a *UserService.

• It looks at NewUserService and sees it needs a *UserRepository.

• It calls the constructors in the correct order, passing the results as needed, and finally provides the fully constructed *Handler to your function.

Does it look like magic? A bit, but it's all based on reflection and the constructors you provide. You still have full control over how dependencies are created, but Dig handles the wiring for you.

Pros:

• Reduces manual wiring, especially in large projects.

• Flexible: easy to swap implementations at runtime.

• Works well with dynamic configurations.

Cons:

• Uses reflection, which can introduce runtime errors if dependencies are misconfigured.

• Less explicit: it's not always obvious how a dependency is resolved.

• Debugging runtime DI issues can be tricky.

• Reflection can have performance implications, though usually negligible.

Uber Fx (DI + App Lifecycle)

Uber Fx builds on Dig and adds application lifecycle management. It's ideal for large microservices with multiple modules and background processes.

Example: Fx in Action

import "go.uber.org/fx"

func registerRoutes(lc fx.Lifecycle, handler *Handler) {
    lc.Append(fx.Hook{
        OnStart: func(ctx context.Context) error {
            http.Handle("/user", handler)
            go http.ListenAndServe(":8080", nil)
            return nil
        },
        OnStop: func(ctx context.Context) error {
            log.Println("shutting down server")
            return nil
        },
    })
}

func main() {
    app := fx.New(
        fx.Provide(NewUserRepository, NewUserService, NewHandler),
        fx.Invoke(registerRoutes),
    )

    app.Run() // starts the app and manages lifecycle hooks
}

Fx uses Dig under the hood for DI, but adds lifecycle hooks to manage startup and shutdown logic. You can register functions to run when the app starts or stops, making it easy to manage resources like HTTP servers, database connections, and so on. This can be particularly useful in microservices that require background workers, database connections, or scheduled jobs.

Fx also provides a more opinionated structure for your application, encouraging best practices and making it easier to reason about your code. The downside is that it introduces more complexity and a steeper learning curve compared to manual DI or even Dig alone.

Pros:

• Simplifies complex applications with lifecycle management.

• Integrates DI with application startup and shutdown.

• Good for microservices and enterprise-scale projects.

Cons:

• Steeper learning curve than manual DI or Wire.

• Locks you into the Fx framework.

• Somewhat heavier than other solutions. May feel overkill for small apps.

Other Lightweight DI Helpers

Besides Wire, Dig, and Fx, there are smaller tools like:

• do: A minimalistic DI container that focuses on simplicity and ease of use. It provides basic functionality to register and resolve dependencies without much overhead.

• alice: A lightweight middleware chaining library that can help manage dependencies in HTTP handlers, though it's not a full DI framework.

These libraries are less commonly used but can be useful in specific scenarios. They typically offer a middle ground between manual DI and full-fledged frameworks.

Choosing the Right Tool

A few considerations when deciding whether to adopt a DI library:

Remember: manual DI is always valid. Libraries are optional tools to reduce boilerplate and improve maintainability in larger systems. They should not replace understanding the underlying pattern.

Key Takeaways

• DI frameworks can reduce wiring complexity, but manual DI is still idiomatic and often sufficient.

• Wire: compile-time safety, explicit generated code.

• Dig: runtime reflection, flexible wiring.

• Fx: DI + app lifecycle, best for large services.

• Other tools: lightweight helpers for specific use cases.

By understanding these tools, you can scale your Go applications cleanly while keeping dependencies manageable, testable, and explicit.

Exercise for the Reader

Try integrating one of these DI libraries into the example application we built earlier (or all of them). Start with Wire to see how compile-time DI works, then experiment with Dig or Fx for more complex scenarios. Observe how the wiring code changes and consider the trade-offs in terms of complexity, readability, and maintainability. Consult the documentation for each library to understand its features and limitations. This hands-on experience will help you decide when and how to use DI frameworks in your own projects.

Best Practices and Takeaways

We've now looked at dependency injection (DI) from multiple angles: the idiomatic manual approach, the challenges that arise at scale, and the libraries that can help. The next logical question is: how do you decide what's right for your project?

This section summarizes best practices that apply regardless of whether you stick with manual DI or adopt a framework. The goal is to help you make practical, informed choices.

Prefer Explicit Dependencies

The most important principle in Go is clarity. Whether you're writing a small service or wiring up a large application, make dependencies explicit.

• Pass dependencies through constructors, not hidden global variables.

• Use interfaces to abstract behavior when testing or swapping implementations.

• Avoid magic - readers should see how things are connected.

Example of explicit constructor-based DI:

func NewOrderService(repo OrderRepository, logger Logger) *OrderService {
    return &OrderService{repo: repo, logger: logger}
}

Anyone reading this constructor immediately knows that OrderService depends on a repository and a logger.

Start Simple (Manual DI)

For most Go projects, manual DI is enough. It keeps things simple, predictable, and easy to follow.

• In small to medium services, wiring by hand in main.go is rarely a bottleneck.

• Explicit wiring doubles as documentation: you can glance at main.go to see how the app is assembled.

• Adding a framework too early can add complexity without clear benefits.

A useful rule of thumb: If your wiring fits comfortably in one screen, manual DI is probably the best choice.

Use Frameworks to Tame Complexity

That said, frameworks exist for a reason. When your main.go turns into hundreds of lines of boilerplate, consider a DI tool.

• Wire: best if you want compile-time safety and explicit generated code.

• Dig: best if you want runtime flexibility with minimal setup.

• Fx: best if you want both DI and application lifecycle management.

Think of these frameworks as productivity helpers, not as replacements for understanding DI. You should always understand how dependencies flow through your code, even if a library is wiring them for you.

Keep Wiring at the Edges

A common best practice is to keep wiring separate from business logic.

• Business logic should not care about how dependencies are constructed.

• Wiring should happen at the application entry point (main.go or an initApp() function).

• This separation keeps your core code decoupled and testable.

Example structure:

/cmd/app/main.go    <-- all wiring here
/internal/service/  <-- business logic
/internal/repo/     <-- data access

This way, tests can bypass the wiring entirely and construct only what they need.

Favor Interfaces for Testability

Dependency injection shines when it comes to testing. To get the most out of it, depend on interfaces rather than concrete types.

For example:

type UserRepository interface {
    FindUser(id int) string
}

type UserService struct {
    repo UserRepository
}

In production, you can inject a real DBUserRepository. In tests, you can inject a FakeUserRepository. This makes testing fast, isolated, and easy.

Avoid Over-Engineering

While interfaces are powerful, overusing them can hurt readability. A good heuristic in Go is:

• If there's only one implementation, you probably don't need an interface.

• Add interfaces when you need to mock something or swap implementations.

This keeps your codebase clean without unnecessary abstractions.

Balance Verbosity and Magic

Every DI strategy sits on a spectrum:

• Manual DI: maximum explicitness, but verbose at scale.

• Dig/Fx: less verbose, but more hidden wiring.

• Wire: middle ground: generated code is explicit, but you don’t write it by hand.

There's no one-size-fits-all answer. The right choice depends on your team's size, project complexity, and tolerance for boilerplate.

Adopt Incrementally

You don't need to commit to a DI framework from day one. Many teams:

• Start with manual DI.

• As the project grows, refactor to Wire for compile-time safety.

• If the project evolves into a complex service with many modules, adopt Fx for lifecycle management.

This incremental approach ensures you never add more complexity than you need.

Document Your Wiring

Whether manual or framework-based, document how dependencies are wired.

• In manual DI, main.go often serves as self-documenting code.

• With frameworks, add comments or diagrams explaining the flow.

• New contributors should be able to understand the structure without guesswork.

Key Takeaways

• Be explicit: make dependencies visible and testable.

• Start simple: manual DI works well in most projects.

• Use frameworks only when needed: Wire, Dig, and Fx can only help manage complexity if there is complexity.

• Keep wiring at the edges: business logic should stay clean and decoupled.

• Follow Go's philosophy: prefer clarity and simplicity over cleverness.

By following these best practices, you'll be able to manage dependencies effectively in Go - whether you're writing a tiny CLI tool or a large-scale microservice.

Conclusion

Dependency injection in Go doesn't need to be mysterious or complicated. At its core, it's simply about passing dependencies into your code rather than creating them inside it. This small shift in design makes your applications easier to test, more modular, and more maintainable.

We've seen the three main approaches:

• Manual DI: the idiomatic baseline in Go. Explicit, clear, and great for most projects.

• Compile-time tools like Wire: reduce boilerplate while keeping wiring explicit.

• Runtime frameworks like Dig and Fx: powerful for large applications that need flexibility and lifecycle management.

There is no single "right" choice. The best approach depends on the size and complexity of your project, your team's preferences, and how much wiring you're willing to manage by hand.

If you take one thing away from this guide, let it be this: start simple with manual DI, and only reach for tools when the cost of wiring by hand outweighs the benefits of explicitness.

By understanding the trade-offs and following best practices, you'll be well equipped to structure Go applications that are clear, testable, and scalable, whether you're writing a tiny web service or a full-blown distributed system.

Configurable Dependency, also known as Dependency Injection, is a pattern that enables you to switch dependencies of your application. The term was coined by Alistair Cockburn.

Say your application has a GUI. But your administrator wants to use certain functions via the console. Or your production code calls an external service. But your tests shouldn’t call the service, since it doesn’t provide reliable results. Or the service isn’t always available.

Here’s where a Configurable Dependency is helpful. Depending on context, you use one dependency or the other.

A lot of articles attempt to explain the pattern. But they embed it in a broader context, like ports and adapters architecture. That makes understanding harder than necessary. I know, I’ve written such articles myself.

On top of that, many articles focus on greenfield applications. But most of us have to maintain applications that already exist.

Let’s start with a simple class that has a hard-wired dependency. Then we'll refactor it to a class that has a Configurable Dependency.

The example is trivial, but the refactoring steps are generally applicable to your own application if you’re in a similar situation.

I’ll refer to an example GitHub project in the article. It shows the steps to perform, in its commit history. At the end of the article, there are appendices for IntelliJ IDEA and Eclipse. They show how to do the refactoring steps in your IDE.

The Calculator Example

Say you have a class called Calculator. It’s the equivalent of “business logic”. At the end of each calculation, it prints the result to the screen. In a real world application, it might save something to a database instead.

Here’s the code:

package example;

public class Calculator {
    public Calculator(){
    }

    public long add(long one, long two) {
        long result = one + two;
        printResult(result);
        return result;
    }

    public long sub(long one, long two) {
        long result = one - two;
        printResult(result);
        return result;
    }

    private void printResult(long result) {
        System.out.println("The result is: " + result);
    }
}

Now if you want to test that class, your test code may look like this:

package example;

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.*;

class CalculatorTest {
    private Calculator calculator;

    @BeforeEach
    void setup() {
        calculator = new Calculator();
    }

    @Test
    void addsToNumbers() {
        long result = calculator.add(1, 2);
        assertEquals(3, result);
    }

    @Test
    void subtractsToNumbers() {
        long result = calculator.sub(5, 1);
        assertEquals(4, result);
    }
}

Every time you run your test, it prints the results to the screen. That’s unnecessary. It slows your tests down.

With dependency injection, you can still assert the result in the test. But you avoid printing the result to the screen (or saving the result to the database, the file system, or somewhere else).

Step 1: Move Dependency Creation to the Constructor

Find out where an instance of the dependent class is created. Move creation to the constructor by assigning the instance to a field. Use the field throughout the class, so that only the constructor creates the dependency.

The example code is a bit different. The dependency is a static one, System.out. But as described above, the refactored code assigns it to the printer field in the constructor.

So the Calculator class now looks like this:

package example;

import java.io.PrintStream;

public class Calculator {
    private final PrintStream printer;

    public Calculator(){
        printer = System.out;
    }

    public long add(long one, long two) {
        long result = one + two;
        printResult(result);
        return result;
    }

    public long sub(long one, long two) {
        long result = one - two;
        printResult(result);
        return result;
    }

    private void printResult(long result) {
        printer.println("The result is: " + result);
    }
}

Run the test. It still needs to pass.

Step 2: Pass the Dependency as a Constructor Argument

Pass the instance as a constructor argument, instead of creating it in the constructor. Here’s the refactored example code:

package example;

import java.io.PrintStream;

public class Calculator {
    private final PrintStream printer;

    public Calculator(PrintStream printer){
        this.printer = printer;
    }

    public long add(long one, long two) {
        long result = one + two;
        printResult(result);
        return result;
    }

    public long sub(long one, long two) {
        long result = one - two;
        printResult(result);
        return result;
    }

    private void printResult(long result) {
        printer.println("The result is: " + result);
    }
}

For this class to work, you need to adapt each line of code that creates a Calculator object to pass in the dependency. So the line to create the Calculator in CalculatorTest now looks like this:

calculator = new Calculator(System.out);

Run the test. It still needs to pass.

Step 3: Create an Interface and Implementation

Create an interface with the exact same name as the class name of the dependency. Place it in the same package. Put the method in it that the business logic calls.

package example;

public interface PrintStream {
    void println(String text);
}

In the Calculator class, remove the import statement of the dependency, java.io.PrintStream, to use the new interface instead.

Here’s one implementation of the interface. ConsolePrinter contains the original functionality that prints to a screen.

package example;

public class ConsolePrinter implements PrintStream{
    @Override
    public void println(String text) {
        System.out.println(text);
    }
}

In the test class, pass in the ConsolePrinter. Run the test. It still needs to pass, and print the results to the screen:

package example;

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.*;

class CalculatorTest {
    private Calculator calculator;

    @BeforeEach
    void setup() {
        calculator = new Calculator(new ConsolePrinter());
    }

    @Test
    void addsToNumbers() {
        long result = calculator.add(1, 2);
        assertEquals(3, result);
    }

    @Test
    void subtractsToNumbers() {
        long result = calculator.sub(5, 1);
        assertEquals(4, result);
    }
}

Step 4: Rename and Clean Up

This is an optional step. You can decide to rename the interface, to give it a more meaningful name. For example, rename PrintStream to Printer.

You can also decide to move the class to a different package and rename its method(s).

Run the test. It still needs to pass.

Step 5: Configure the Dependency

Create another implementation that ignores the text argument, for testing purposes:

package example;

public class IdlePrinter implements Printer{
    @Override
    public void println(String text) {
        // This is empty, because we don't want to print in tests.
    }
}

Now, you can change a single line of the CalculatorTest to turn off printing:

calculator = new Calculator(new IdlePrinter());

Since Java 8, you don’t even need IdlePrinter. Pass in a Lambda function instead:

calculator = new Calculator(text -> {});

Congratulations!

You have refactored to a Configurable Dependency.

Have a look at the GitHub project commit history to see the changes in code that I performed.

If you have any questions, leave a comment or contact me.

Twitter: https://twitter.com/BertilMuth

LinkedIn: https://www.linkedin.com/in/bertilmuth/

The following appendices explain the concrete refactoring steps in IntelliJ IDEA and Eclipse.

Appendix A — How to refactor in IntelliJ IDEA

IntelliJ Step 1: Move Dependency Creation to the Constructor

Open the Calculator class. Locate System.out. Right click, select Refactor > Introduce Field. Select initialize in: constructor. Name the field printer. Hit Return.

IntelliJ Step 2: Pass the Dependency as a Constructor Argument

Set the cursor into the constructor, Calculator(). Mark the access to the dependency, System.out. Right click, select Refactor > Introduce Parameter. Name the field printer. Hit Return.

IntelliJ Step 3: Create an interface and Implementation

Create the interface and implementation in the same package:

package example;

public interface PrintStream {
    void println(String text);
}

package example;

public class ConsolePrinter implements PrintStream{
    @Override
    public void println(String text) {
        System.out.println(text);
    }
}

Go to the business logic class Calculator and remove the import statement import java.io.PrintStream;. Save the file.

In the test class CalculatorTest, use the new implementation class.

Change this:

calculator = new Calculator(System.out);

to this:

calculator = new Calculator(new ConsolePrinter());

Save the file. Run the test and check if it still passes.

IntelliJ Step 4: Rename and Clean Up

Go to the interface PrintStream. Right click on PrintStream and select Refactor > Rename. Enter Printer and press Return. Run the test and check if it still passes.

IntelliJ Step 5: Configure the Dependency

Create another implementation that ignores the text argument, for testing purposes:

package example;

public class IdlePrinter implements Printer{
    @Override
    public void println(String text) {
        // This is empty, because we don't want to print in tests.
    }
}

Go to CalculatorTest and change this:

calculator = new Calculator(new ConsolePrinter());

to this:

calculator = new Calculator(new IdlePrinter());

Save the file. Run the test and check if it still passes.

The text output should now be off. Well done.

Appendix B — How to Refactor in Eclipse

Eclipse Step 1: Move Dependency Creation to the Constructor

Open the Calculator class. Locate System.out. Right click, select Refactor > Extract Local Variable. Click OK.

Mark the newly created local variable out. Right click, select Refactor > Convert Local Variable to Field. Name the variable printer. Choose Initialize in Class Constructors. Check Declare field as ‘final’. Hit OK.

Run the test and check if it still passes.

Eclipse Step 2: Pass the Dependency as a Constructor Argument

Set the cursor into the constructor, Calculator(). Mark the access to the dependency, System.out, and copy it to the clipboard (CTRL-C).

Right click, select Refactor > Change Method Signature. Click Add. Type PrintStream under Type, printer under Name, and paste System.out under Default value. Click OK and Continue.

Change the constructor to look like this:

public Calculator(PrintStream printer){
this.printer = printer;
}

Save the file. Run the test and check if it still passes.

Eclipse Step 3: Create an Interface and Implementation

Create the interface and implementation in the same package:

package example;

public interface PrintStream {
    void println(String text);
}

package example;

public class ConsolePrinter implements PrintStream{
    @Override
    public void println(String text) {
        System.out.println(text);
    }
}

Go to the business logic class Calculator and remove the import statement import java.io.PrintStream;. Save the file.

In the test class CalculatorTest, use the new implementation class.

Change this:

calculator = new Calculator(System.out);

to this:

calculator = new Calculator(new ConsolePrinter());

Save the file. Run the test and check if it still passes.

Eclipse Step 4: Rename and Clean Up

Go to the interface PrintStream. Right click on PrintStream and select Refactor > Rename. Enter Printer and press Return. Run the test and check if it still passes.

Eclipse Step 5: Configure the Dependency

Create another implementation that ignores the text argument, for testing purposes:

package example;

public class IdlePrinter implements Printer{
    @Override
    public void println(String text) {
        // This is empty, because we don't want to print in tests.
    }
}

Go to CalculatorTest and change this:

calculator = new Calculator(new ConsolePrinter());

to this:

calculator = new Calculator(new IdlePrinter());

Save the file. Run the test and check if it still passes.

The text output should now be off. Well done.

Motivation

Dependency Injection is often more simply referred to as DI. The paradigm exists throughout Angular. It keeps code flexible, testable, and mutable. Classes can inherit external logic without knowing how to create it. Any consumers of those classes also do not need to know anything.

DI saves classes and consumers alike from having to know more than necessary. Yet the code is as modular as it was before thanks to the mechanisms supporting DI in Angular.

Services are a key benefactor of DI. They rely on the paradigm for injection into various consumers. Those consumers can then take advantage of that service provides and/or forward it elsewhere.

Service are not alone. Directives, pipes, components, and so on: every schematic in Angular benefits from DI in some way or another.

Injectors

Injectors are data structures that store instructions detailing where and how services form. They act as intermediaries within the Angular DI system.

Module, directive, and component classes contain metadata specific to injectors. A new injector instance accompanies every one of these classes. In this way, the application tree mirrors its hierarchy of injectors.

The providers: [] metadata accepts services that then register with the class’ injector. This provider field adds the instructions necessary for an injector to function. A class (assuming it has dependencies) instantiates a service by taking on its class as its data type. The injector aligns this type a creates an instance of that service on the class’ behalf.

Of course, the class can only instantiate what the injector has instructions for. If the class’ own injector does not have the service registered, then it queries its parent. So on and so forth until either reaching an injector with the service or the application root.

Services can register at any injector within the application. Services go in the providers: [] metadata field of class modules, directives, or components. The class’ children can instantiate a service registered in the class’ injector. Child injectors fallback on parent injectors after all.

Dependency Injection

Take a look at the skeletons for each class: service, module, directive, and component.

// service

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: /* injector goes here */
})
export class TemplateService {
  constructor() { }
}

// module

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';

@NgModule({
  imports: [
    CommonModule
  ],
  declarations: [],
  providers: [ /* services go here */ ]
})
export class TemplateModule { }

// directive

import { Directive } from '@angular/core';

@Directive({
  selector: '[appTemplate]',
  providers: [ /* services go here */ ]
})
export class TemplateDirective {
  constructor() { }
}

//component

import { Component } from '@angular/core';

@Component({
  selector: 'app-template',
  templateUrl: './template.component.html',
  styleUrls: ['./template.component.css'],
  providers: [ /* services go here */ ]
})
export class TemplateComponent {
  // class logic ...
}

Each skeleton can register services to an injector. In fact, TemplateService is a service. As of Angular 6, services can now register with injectors using @Injectable metadata.

In Any Case

Notice the providedIn: string (@Injectable) and providers: [] (@Directive, @Componet and @Module) metadata. They tell injectors where and how to create a service. Otherwise, injectors would not know how to instantiate.

What if a service has dependencies? Where would the results go? Providers answers those question so that injectors can instantiate properly.

Injectors form the backbone of the DI framework. They store instructions to instantiate services so consumers do not have to. They receive service instances without needing to know anything about the source dependency!

I should also note that other schematics without injectors can still utilize dependency injection. They cannot register additional services but they can still instantiate from injectors.

Service

The providedIn: string metadata of @Injectable specifies which injector to register with. Using this method, and depending on if the service gets used, the service may or may not register with the injector. Angular calls this tree-shaking.

By default the value is set to ‘root’. This translates to the root injector of the application. Basically, setting the field to ‘root’ makes the service available anywhere.

Quick Note

As previously mentioned, child injectors fallback on their parents. This fallback strategy ensures parents do not have to re-register for every injector. Refer to this article on Services and Injectors for an illustration of this concept.

Registered services are singletons. Meaning, the instructions to instantiate the service exists on only one injector. This assumes it has not been explicitly registered elsewhere.

Module, Directive, and Component

Modules and components each have their own injector instance. This is evident given the providers: [] metadata field. This field takes an array of services and registers them with the injector of the module or component class. This approach happens in the @NgModule, @Directive, or @Component decorators.

This strategy omits tree-shaking, or the optional removal of unused services from injectors. Service instances live on their injectors for the life of the module or component.

Instantiating References

References to the DOM can instantiate from any class. Keep in mind that references are still services. They differ from traditional services in representing the state of something else. These services include functions to interact with their reference.

Directives are in constant need of DOM references. Directives perform mutations on their host elements through these references. See the following example. The directive’s injector instantiates a reference of the host element into the class’ constructor.

// directives/highlight.directive.ts

import { Directive, ElementRef, Renderer2, Input } from '@angular/core';

@Directive({
  selector: '[appHighlight]'
})
export class HighlightDirective {
  constructor(
    private renderer: Renderer2,
    private host: ElementRef
  ) { }

  @Input() set appHighlight (color: string) {
    this.renderer.setStyle(this.host.nativeElement, 'background-color', color);
  }
}

// app.component.html

<p [appHighlight]="'yellow'">Highlighted Text!</p>

Renderer2 also gets instantiated. Which injector do these services come from? Well, each service’s source code comes from @angular/core. These services must then register with the application’s root injector.

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { AppComponent } from './app.component';
import { HighlightDirective } from './directives/highlight.directive';

@NgModule({
  declarations: [
    AppComponent,
    HighlightDirective
  ],
  imports: [
    BrowserModule
  ],
  providers: [],
  bootstrap: [
    AppComponent
  ]
})
export class AppModule { }

An empty providers array!? Not to fear. Angular registers many services with the root injector automatically. This includes ElementRef and Renderer2. In this example, we are managing the host element through its interface stemming from the instantiation of ElementRef. Renderer2 lets us update the DOM through Angular’s view model.

You can read more about views from this article. They are the preferred method for DOM/view updates in Angular applications.

It is important recognize the role that injectors play in the above example. By declaring variable types in the constructor, the class obtains valuable services. Each parameter’s data type maps to a set of instructions within the injector. If the injector has that type, it returns an instance of said type.

Instantiating Services

The Services and Injectors article explains this section to an extent. Though, this section rehashes the previous section or the most part. Services will often provide references to something else. They may just as well provide an interface extending a class’ capabilities.

The next example will define a logging service that gets added to a component’s injector via its providers: [] metadata.

// services/logger.service.ts

import { Injectable } from '@angular/core';

@Injectable()
export class LoggerService {
  callStack: string[] = [];

  addLog(message: string): void {
    this.callStack = [message].concat(this.callStack);
    this.printHead();
  }

  clear(): void {
    this.printLog();
    this.callStack = [];
    console.log(“DELETED LOG”);
  }

  private printHead(): void {
    console.log(this.callStack[0] || null);
  }

  private printLog(): void {
    this.callStack.reverse().forEach((log) => console.log(message));
  }
}

// app.component.ts

import { Component } from '@angular/core';
import { LoggerService } from './services/logger.service';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  providers: [LoggerService]
})
export class AppComponent {
  constructor(private logger: LoggerService) { }

  logMessage(event: any, message: string): void {
    event.preventDefault();
    this.logger.addLog(`Message: ${message}`);
  }

  clearLog(): void {
    this.logger.clear();
  }
}

// app.component.html

<h1>Log Example</h1>
<form (submit)="logMessage($event, userInput.value)">
  <input #userInput placeholder="Type a message...">
  <button type="submit">SUBMIT</button>
</form>

<h3>Delete Logged Messages</h3>
<button type="button" (click)="clearLog()">CLEAR</button>

Focus on the AppComponent constructor and metadata. The component injector receives instructions from the provider’s metadata field containing LoggerService. The injector then knows what to instantiate LoggerService from requested in the constructor.

The constructor parameter loggerService has the type LoggerService which the injector recognizes. The injector follows through with the instantiation as mentioned.

Conclusion

Dependency injection (DI) is a paradigm. The way it works in Angular is through a hierarchy of injectors. A class receives its resources without having to create or know about them. Injectors receive instruction and instantiate a service depending on which one was requested.

DI shows up a lot in Angular. The official Angular documentation explains why the paradigm is so prevalent. They also go on to describe the numerous use-cases for DI in Angular way beyond what was discussed in this article. Check it out by clicking below!

More on dependency injection:

• Intro to Angular dependency injection
• Quick intro to dependency injection

Components are responsible for the data that renders into the template. Having external services to draw upon can simplify this responsibility. Plus, encapsulating extraneous is much easier to maintain.

Delegating too many responsibilities onto a single component can complicate the component class. And what if these responsibilities applied to several components? Copying and pasting such logic is extremely poor practice. Any future changes to the logic would be harder to implement and test.

Angular meant to curb this issue with services and dependency injection. Both concepts work together to provide modular functionality.

Components do not need to provide any extraneous information either. A services imports what it needs to function on behalf of the components it services. The components only need to instantiate the service. From there they service their own needs with the instantiated service instance.

As for testing and future modification, all the logic is in one place. The service instantiates from its source. Tests and modifications to the source apply anywhere the service is injected.

Introduction to Services

A service is a type of schematic available in Angular. It is generatable by the command-line interface (CLI): ng generate service [name-of-service]. Replace [name-of-service] with a preferable name. The CLI command yields the following.

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class LoggerService {
  constructor() { }
}

The logic of a service is distinct within its class. Angular interprets a class as an injectable service based off the @Injectable decorator. Injectable services must register with an injector.

The component instantiates a service while the injector provides that instance. Keep reading into the next section for more on injectors.

The @Injectable metadata field providedIn: ‘root’ targets the root module of the current application (app.module.ts). It registers the service with the module’s injector so that it can inject that service into any of its children.

Injectors are the building blocks of Angular’s dependency injection system. Injectors are a good place to focus your attention before continuing with services.

Injectors

An application, beginning with app.module.ts, contains a hierarchy of injectors. They exist alongside each module and component in the application tree.

The green circles indicate injectors. They provide service instances to instantiating components. Depending on which injector a service is registered with, it may or may not be available to a component.

Services registered at the root of the app (app.module.ts) are available to all components. An injector for a component may not have a certain service registered. If that is the case and the component requests its instantiation, the injector will defer to its parent. This trend continues until either reaching the root injector or the service is found.

Looking at the diagram, say that a service registers at point B’s injector. All components at point C and down will not be able to access the service registered at B’s injector. Injectors will never defer to their children for a service instance.

Dependency Injection

There are multiple ways to register a service with an application’s injectors.

The providedIn: ‘root’ metadata field of @Injectable provides the most recommended approach. This metadata field released with Angular 6.

As mentioned before, providedIn: ‘root’ registers a service with the root module injector. It is instantiable across the entire application as a result.

The novelty of providedIn: ‘root’ is tree-shaking. If the service is unused despite its registration, it gets shaken from the application at run-time. That way it does not consume any resources.

The other two ways are more direct and traditional. Granted, they do not offer tree-shaking.

A service can register with any injector along the component tree. You insert the service as a provider in the @Component metadata field: providers: []. The service is available to the component and its children

In the third registration strategy, the providers: [] metadata exists as its own field in the @NgModule decorator. The service is instantiable from the module to the underlying component tree.

Remember that unlike with providedIn: ‘root’, @NgModule registration does not offer tree-shaking. Both strategies are otherwise identical. Once a service registers with @NgModule, it consumes resources even if left unused by the application.

Services Continued

Writing an actual service comes next. To recap, services handle certain functions on behalf of an application’s components.

Services excel at handling common operations. They spare components the responsibility by doing so. It saves time not having to re-write common operations across multiple components. It is also more testable because the code is in one place. Changes only need to happen in one place without having to search elsewhere.

Use Cases

A couple examples goes a long way towards a complete understanding of services.

• console logs
• API requests

Both are common across most applications. Having services to handle these operations will reduce component complexity.

Console Logs

This example builds up from the base @Injectable skeleton. The skeleton is available through executing the CLI (ng generate service [name-of-service]]).

// services/logger.service.ts

import { Injectable } from '@angular/core';

interface LogMessage {
  message:string;
  timestamp:Date;
}

@Injectable({
  providedIn: 'root'
})
export class LoggerService {
  callStack:LogMessage[] = [];

  constructor() { }

  addLog(message:string):void {
      // prepend new log to bottom of stack
      this.callStack = [{ message, timestamp: new Date() }].concat(this.callStack);
  }

  clear():void {
      // clear stack
      this.callStack = [];
  }

  printHead():void {
      // print bottom of stack
      console.log(this.callStack[0] || null);
  }

  printLog():void {
      // print bottom to top of stack on screen
      this.callStack.reverse().forEach((logMessage) => console.log(logMessage));
  }

  getLog():LogMessage[] {
      // return the entire log as an array
      return this.callStack.reverse();
  }
}

LoggerService registers with the root module through the @Injectable metadata. Thus it can instantiate in the app.component.html.

// app.component.ts

import { Component, OnInit } from '@angular/core';
import { LoggerService } from './services/logger.service';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html'
})
export class AppComponent implements OnInit {
  logs:object[] = [];

  constructor(private logger:LoggerService) { }

  updateLog():void {
      this.logger.printHead();
      this.logs = this.logger.getLog();
  }

  logMessage(event:any, message:string):void {
      event.preventDefault();

      this.logger.addLog(`Message: ${message}`);
      this.updateLog();
  }

  clearLog():void {
      this.logger.clear();
      this.logs = [];
  }

  ngOnInit():void {
      this.logger.addLog(“View Initialized”);
      this.updateLog();
  }
}

The template HTML provides further insight into the component’s use of LoggerService.

<!-- app.component.html -->

<h1>Log Example</h1>

<form (submit)="logMessage($event, userInput.value)">
  <input #userInput placeholder="Type a message...">
  <button type="submit">SUBMIT</button>
</form>

<h3>Complete Log</h3>
<button type="button" (click)="clearLog()">CLEAR</button>
<ul>
  <li *ngFor="let log of logs; let i=index">{{ logs.length - i }} > {{ log.message }} @ {{ log.timestamp }}</li>
</ul>

This has the feel of a ToDo application. You can log messages and clear the log of messages. Imagine if all the logic from the service was shoved into AppComponent! It would have complicated the code. LoggerService keeps the log-related code encapsulated from the core AppComponent class.

Fetch Requests

Here is one more example worth playing around with. This example is possible thanks to typicode’s JSONPlaceholder¹. The API is public and free to use.

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

// https://jsonplaceholder.typicode.com
// public API created by typicode @ https://github.com/typicode

interface Post {
  userId:number;
  id:number;
  title:string;
  body:string;
}

@Injectable({
  providedIn: 'root'
})
export class PlaceholderService {
  constructor(private http:HttpClient) { }

  getPosts():Observable<Post[]> {
      return this.http.get('https://jsonplaceholder.typicode.com/posts');
  }

  getPost(id:number):Observable<Post> {
      return this.http.get(`https://jsonplaceholder.typicode.com/posts/${id}`);
  }
}

This is more of a stand-alone piece than a fully fleshed out example. Fetch requests tend to work better as an injectable service. The alternative is an over-complicated component. The injected class subscribes to what the PlaceholderService pre-configures.

Conclusion

Services and dependency injection are very useful together. They allow developers to encapsulate common logic and inject across multiple different components. This alone is a massive convenience for any future maintenance.

Injectors work as intermediaries. They mediate between instantiating components and a reservoir of registered services. Injectors offer these instantiable services to their branch children.

See the next few links for more information on services and dependency injection.

Resources for Angular

• Angular Documentation
• In introduction to Angular dependency injection
• What is dependency injection and when to use it
• Best Angular code examples
• Angular GitHub Repository
• Dependency Injection
• Intro to Services and DI

Introduction

Nodejs gives you the power to write server side code using JavaScript. In fact, it is very easy and fast to create a web server using Nodejs. There are several frameworks available on Node package manager which makes the development even easier and faster.

But there are a few challenges in Nodejs development:

• Nodejs is all about callbacks, and with more and more callbacks you end up with a situation called callback hell.
• Writing readable code.
• Writing maintainable code.
• You don't get much intellisense support which makes development slow.

If you are quite experienced and have a good knowledge of Nodejs, you can use different techniques and try to minimize these challenges.

The best way to solve these problems is by using modern JavaScript ES6, ES7 or TypeScript, whatever you feel comfortable with. I recommend TypeScript, because it provides intillisense support for every word of code which makes your development faster.

So I created a framework called FortJs which is very easy to learn and use. FortJs enables you to write server-side code using ES6 or TypeScript which is modular, secure, and pretty much just beautiful and readable.

Features

Some of the important features of FortJs are:

• Based on Fort architecture.
• MVC Framework and follows OOPS approach so everything is class and object.
• Provides components - Wall, Shield and Guard. Components help modularize the application.
• Uses ES6 async/await or promise for executing asychronous code.
• Everything is configurable - you can configure your session store, view engine, websocket etc.
• Dependency Injection.
• Everything can be unit tested, so you can use a TDD approach.

Let's Code

In this article I am going to create a REST API using FortJs and ES6. But you can use the same code and steps to implement using TypeScript too.

Project Setup

FortJs provides a CLI - fort-creator. This helps you set up the project and develop faster. Let's use the CLI to develop.

Perform the below steps sequentially:

• Open your terminal or command prompt.
• Install fort-creator globally - run the command "npm i fort-creator -g". Note: Make sure you have Nodejs installed in your system.
• Create a new project - run the command "fort-creator new my-app". Here “my-app” is the name of the app, so you can choose any name. The CLI will prompt you to choose the language with two options: TypeScript and JavaScript. Choose your language by using the arrow keys and press enter - i have chosen JavaScript. It will take some time to create the project, so please wait until you see "new project my-app created".
• Enter into the project directory - "cd my-app".
  Start the development server with live reloading - run the command "fort-creator start".
• Open the browser and type the URL - http://localhost:4000/.

You should see something like this in the browser.

FortJs starter page

Let's understand how this page is rendered:

• Open the project folder in your favourite code editor. I am going to use VS Code. You will see many folders inside project root such as controllers, views, etc. Every folder is grouped by their use - for example, the controllers folder contains all controllers and the views folder contains all views.
• Open the controllers folder -> Inside the controllers, you will see a file name - default_controller. Let's open it and observe the code. The file contains a class DefaultController - this is a controller class and it contains methods which return some http response.
• Inside the class DefaultController, you will see a method 'index' - this is the one which is rendering current output to the browser. The method is known as worker in FortJs because they do some kind of work and return the result as an http response. Let's observe the index method code:

const data = {  
    title: title  
}  
const result = await viewResult('default/index.html', data);  
return result;

It creates a data object and passes that object into the viewResult method. The viewResult method takes two parameters - the view location and view data. The work of viewResult is to render the view and return a response, which we are seeing in the browser.

• Let's find the view code and understand it. Open the views folder - > open default folder - > open index.html. This is our view code. It is simple HTML code along with some mustache syntax. The default view engine for Fortjs is mustache.

I hope you have understood the project architecture. If you are having any difficulties or doubts, please feel free to ask in the comments section.

Now we will move to next part of this article where we will learn how to create a simple rest API.

REST

We are going to create a REST endpoint for entity user - which will perform CRUD operations for the user such as adding a user, deleting a user, getting a user, and updating a user.

According to REST:

1. Adding user - should be done using the http method "POST"
2. Deleting user - should be done using the http method "REMOVE"
3. Getting user - should be done using the http method "GET"
4. Updating user - should be done using the http method "PUT"

For creating an endpoint, we need to create a Controller similar to the default controller explained earlier.

Execute the command "fort-creator add". It will ask you to "Choose the component to add ?" Choose Controller & press enter. Enter the controller name "User" and press enter.

Now that we have created the user controller we need to inform FortJs by adding it to routes. The route is used to map our controller to a path.

Since our entity is user, "/user" will be a good route. Let's add it. Open routes.js inside the root directory of the project and add UserController to routes.

After adding UserController, routes.js will look like this:

import { DefaultController } from "./controllers/default_controller";
import { UserController } from "./controllers/user_controller";

export const routes = [{
    path: "/*",
    controller: DefaultController
},
{
    path: "/user",
    controller: UserController
}]

So when an http request has the path "/user" then UserController will be called.

Let's open the url - http://localhost:4000/user.

Note: If you have stopped FortJs while adding the controller, please start it again by running the cmd - fort-creator start

And you see a white page right?

This is because we are not returning anything from the index method and thus we get a blank response. Let's return a text "Hello World" from the index method. Add the below code inside the index method and save:

return textResult('Hello World');

Refresh the url - http://localhost:4000/user

And you see "Hello World" right?

Now, let's convert "UserController" to a REST API. But before writing code for the REST API, let's create a dummy service which will do CRUD operations for users.

Service

Create a folder called “services” and then a file “user_service.js” inside the folder. Paste the below code inside the file:

const store = {
    users: [{
        id: 1,
        name: "ujjwal",
        address: "Bangalore India",
        emailId: "ujjwal@mg.com",
        gender: "male",
        password: "admin"
    }]
}

export class UserService {
    getUsers() {
        return store.users;
    }

    addUser(user) {
        const lastUser = store.users[store.users.length - 1];
        user.id = lastUser == null ? 1 : lastUser.id + 1;
        store.users.push(user);
        return user;
    }

    updateUser(user) {
        const existingUser = store.users.find(qry => qry.id === user.id);
        if (existingUser != null) {
            existingUser.name = user.name;
            existingUser.address = user.address;
            existingUser.gender = user.gender;
            existingUser.emailId = user.emailId;
            return true;
        }
        return false;
    }

    getUser(id) {
        return store.users.find(user => user.id === id);
    }

    removeUser(id) {
        const index = store.users.findIndex(user => user.id === id);
        store.users.splice(index, 1);
    }
}

The above code contains a variable store which contains a collection of users. The method inside the service does operations like add, update, delete, and get on that store.

We will use this service in REST API implementation.

GET

For the route "/user" with the http method "GET", the API should return a list of all users.

In order to implement this, let's rename the "index" method inside user_controller.js to "getUsers" making it semantically correct. Then paste the below code inside the method:

const service = new UserService();
return jsonResult(service.getUsers());

Now user_controller.js looks like this:

import { Controller, DefaultWorker, Worker, textResult, jsonResult } from "fortjs";
import { UserService } from "../services/user_service";

export class UserController extends Controller {

    @DefaultWorker()
    async getUsers() {
        const service = new UserService();
        return jsonResult(service.getUsers());
    }
}

Here, we are using the decorator DefaultWorker. The DefaultWorker does two things: it adds the route "/" & the http method "GET". It's a shortcut for this scenario. In the next part, we will use other decorators to customize the route.

Let's test this by calling the url http://localhost:4000/user. You can open this in the browser or use any http client tools like postman or curl.

Ok, so we have successfully created an end point :) .

Let's look again at our code and see if we can make it better:

1. The service "UserService" is tightly coupled with Controller "UserController" which becomes a problem for unit testing "UserController". So we will use dependency injection by FortJs to inject UserService.
2. We are creating an instance of "UserService" every time the method getUsers is called. But what we need from "UserService" is a single object and then call the "UserService" method from the object.

So if we can somehow store an object of "UserService" then we can make our code faster (because calling new does some work under the hood). For this we will use the singleton feature of FortJs.

Let's change the user_controller.js code by the below code:

import { Controller, DefaultWorker, Worker, textResult, jsonResult, Singleton } from "fortjs";
import { UserService } from "../services/user_service";

export class UserController extends Controller {

    @DefaultWorker()
    async getUsers(@Singleton(UserService) service) {
        return jsonResult(service.getUsers());
    }
}

As you can see, the only change is that we are using the "Singleton" decorator in the method getUsers. This will create a singleton and inject that singleton when getUsers is called. This singleton will be available throughout the application.

Since service is now a parameter, we can manually pass the parameter while calling. This makes getUsers unit testable.

For doing unit testing or E2E testing, please read this test doc - http://fortjs.info/tutorial/test/

POST

Let's add a method "addUser" which will extract data from the request body and call service to add a user.

async addUser(@Singleton(UserService) service) {
        const user = {
            name: this.body.name,
            gender: this.body.gender,
            address: this.body.address,
            emailId: this.body.emailId,
            password: this.body.password
        };
        const newUser = service.addUser(user);
        return jsonResult(newUser, HTTP_STATUS_CODE.Created);
}

In the above code we are creating the Singleton of the UserService again. So the question is will it create another object?

No it will be same object that was in getUser. FortJs supplies the object as a parameter when it calls the method.

The methods created are by default not visible for an http request. So in order to make this method visible for the http request, we need to mark this as a worker.

A method is marked as a worker by adding the decorator "Worker". The Worker decorator takes a list of http methods and makes that method available for only those http methods. So let's add the decorator:

@Worker([HTTP_METHOD.Post])
async addUser(@Singleton(UserService) service) {
    const user = {
        name: this.body.name,
        gender: this.body.gender,
        address: this.body.address,
        emailId: this.body.emailId,
        password: this.body.password
    };
    const newUser = service.addUser(user);
    return jsonResult(newUser, HTTP_STATUS_CODE.Created);
}

Now the route of this method is the same as the name of the method that is "addUser". You can check this by sending a post request to http://localhost:4000/user/addUser with user data in the body.

But we want the route to be "/", so that it will be a rest API. The route of the worker is configured by using the decorator "Route". Let's change the route now.

@Worker([HTTP_METHOD.Post])
@Route("/")
async addUser(@Singleton(UserService) service) {
    const user = {
        name: this.body.name,
        gender: this.body.gender,
        address: this.body.address,
        emailId: this.body.emailId,
        password: this.body.password
    };
    const newUser = service.addUser(user);
    return jsonResult(newUser, HTTP_STATUS_CODE.Created);
}

Now our end point is configured for a post request. Let's test this by sending a post request to http://localhost:4000/user/ with user data in the body.

It returns the user created with id which is our logic. So we have created the end point for the post request, but one important thing to do is to validate the data. Validation is an essential part of any app and is very important for a backend application.

So far, our code is clean and readable. But if we add validation code it will become a little dirty.

Worry not, FortJs provides the component Guard for this kind of work. A/c to the FortJs docs:

Guard is security layer on top of Worker. It controls whether a request should be allowed to call the Worker.

So we are going to use guard for validation of the data. Let's create the guard using fort-creator. Execute the command fort-creator add and choose Guard. Enter the file name "UserValidator". There will be a file "user_validator_guard.js" created inside the guards folder. Open that file.

A guard has access to the body, so you can validate the data inside that. Returning null inside the method check means that we're allowing to call the worker. Returning anything else means block the call.

Let's make it clearer by writing code for the validation. Paste the below code inside the file "user_validator_guard.js":

import { Guard, textResult, HTTP_STATUS_CODE } from "fortjs";

export class UserValidatorGuard extends Guard {

    async check() {
        const user = {
            name: this.body.name,
            gender: this.body.gender,
            address: this.body.address,
            emailId: this.body.emailId,
            password: this.body.password
        };
        const errMsg = this.validate(user);
        if (errMsg == null) {
            // pass user to worker method, so that they dont need to parse again  
            this.data.user = user;
            // returning null means - guard allows request to pass  
            return null;
        } else {
            return textResult(errMsg, HTTP_STATUS_CODE.BadRequest);
        }
    }

    validate(user) {
        let errMessage;
        if (user.name == null || user.name.length < 5) {
            errMessage = "name should be minimum 5 characters"
        } else if (user.password == null || user.password.length < 5) {
            errMessage = "password should be minimum 5 characters";
        } else if (user.gender == null || ["male", "female"].indexOf(user.gender) < 0) {
            errMessage = "gender should be either male or female";
        } else if (user.emailId == null || !this.isValidEmail(user.emailId)) {
            errMessage = "email not valid";
        } else if (user.address == null || user.address.length < 10) {
            errMessage = "address length should be greater than 10";
        }
        return errMessage;
    }

    isValidEmail(email) {
        var re = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
        return re.test(String(email).toLowerCase());
    }


}

In the above code:

• We have created a method validate which takes the parameter user. It validates the user & returns the error message if there is a validation error, otherwise null.
• We are validating data inside the check method, which is part of guard lifecycle. We are validating the user inside it by calling the method validate.
  If the user is valid, then we are passing the user value by using the "data" property and returning null. Returning null means guard has allowed this request and the worker should be called.
• If a user is not valid, we are returning an error message as a text response with the HTTP code "Bad Request". In this case, execution will stop here and the worker won't be called.

In order to activate this guard for the method addUser, we need to add this on top of addUser. The guard is added by using the decorator "Guards". So let's add the guard:

@Worker([HTTP_METHOD.Post])
@Route("/")
@Guards([UserValidatorGuard])
async addUser(@Singleton(UserService) service) {
    const newUser = service.addUser(this.data.user);
    return jsonResult(newUser, HTTP_STATUS_CODE.Created);
}

In the above code:

• I have added the guard, “UserValidatorGuard” using the decorator Guards.
• With the guard in the process, we don't need to parse the data from the body anymore inside the worker. Rather, we are reading it from this.data which we are passing from "UserValidatorGuard".
• The method “addUser” will only be called when Guard allows, which means all data is valid.

One thing to note is that the method "addUser" looks very light after using a component, and it's doing validation too. You can add multiple guards to a worker which gives you the ability to modularize your code into multiple guards and use that guard at multiple places.

Isn't this cool :D?

Let's try adding a user with some invalid data:

As you can see in the screenshot, I have tried sending a request without a password. The result is - "password should be minimum 5 characters". So it means that guard is activated and working perfectly.

PUT

Let’s add another method - “updateUser” with route “/” , guard “UserValidatorGuard” (for validation of user) and most important - worker with http method “PUT”.

@Worker([HTTP_METHOD.Put])
@Guards([UserValidatorGuard])
@Route("/")
async updateUser(@Singleton(UserService) service) {
    const user = this.data.user;
    const userUpdated = service.updateUser(user);
    if (userUpdated === true) {
        return textResult("user updated");
    } else {
        return textResult("invalid user");
    }
}

The updated code is similar to the addUser code except functionality wise it is updating the data. Here, we have reutilized UserValidatorGuard to validate data.

DELETE

In order to delete data, user needs to pass the id of the user. This can be passed by:

• Sending data in body just like we did for add & update - {id:1}
• Sending data in query string - ?id=1
• Sending data in route - for this, we need to customize our route - "/user/1"

We have already implemented getting data from body. So let's see other two ways:

Sending Data in Query String

Let's create a method "removeByQueryString" and paste the below code:

@Worker([HTTP_METHOD.Delete])
@Route("/")
async removeByQueryString(@Singleton(UserService) service) {
    // taking id from query string
    const userId = Number(this.query.id);
    const user = service.getUser(userId);
    if (user != null) {
        service.removeUser(userId);
        return textResult("user deleted");
    } else {
        return textResult("invalid user", 404);
    }
}

Sending Data in Route

You can parameterise the route by using "{var}" in a route. Let's see how.

Let's create another method "removeByRoute" and paste the below code:

@Worker([HTTP_METHOD.Delete])
@Route("/{id}")
async removeByRoute(@Singleton(UserService) service) {

    // taking id from route
    const userId = Number(this.param.id);

    const user = service.getUser(userId);
    if (user != null) {
        service.removeUser(userId);
        return textResult("user deleted");
    } else {
        return textResult("invalid user");
    }
}

The above code is exactly the same as removeByQueryString except that it is extracting the id from the route and using parameter in route i.e., "/{id}" where id is parameter.

Let's test this:

So we have finally created a REST API for all the funtionalities except GETting a particular user by id. I will leave that to you for practice.

POINTS OF INTEREST

Q: How do we add authentication to "UserController", so that any unauthenticated request can't call the "/user" end point.

A: There are multiple approaches for this:

• We can check in every worker for authentication. (BAD - so much extra work and code repetition)
• Create a Guard component and assign to every worker . (GOOD)
• Create a Shield component and assign to controller. Shield is a security layer similar to guard but works on top of controller, so if shield rejects then controller is not initiated. (BEST)

Take a look at the FortJs authentication docs - http://fortjs.info/tutorial/authentication/

REFERENCES

• http://fortjs.info/
• https://medium.com/fortjs

In this article, we will see how the dependency injection of Angular works internally. Suppose we have a component named appcomponent which has a basic and simple structure as follows:

import { Component, OnInit } from "@angular/core";@Component({  selector: "my-root",  templateUrl: "app.component.html",  styleUrls: ["app.component.css"]})export class AppComponent implements OnInit {  ngOnInit(): void {      }}

And we have a service class named GreetingService with a function in it sayHello which has a name as a parameter and returns the name with “Hello” in front of it.

export class GreetingService{  sayHello(name){    return `Hello ${name}` ;  }}

There are two ways to use the service class in the component: first, we can manually create an instance of the service in the component (this is the wrong way and is never recommended).

And the other way is to let Angular create the instance of our service and pass that instance to our component internally. This is the common and recommended way to do it.

Injecting our service in the Angular dependency injection system

Import {Component} from '@angular/core';Import {GreetingService} from '. /greetingService';

@Component({  selector: 'my-app',  templateUrl: './app.component.html',  styleUrls: [ './app.component.css' ]})export class AppComponent  {

constructor(private greetingService : GreetingService){   console.log(this.greetingService.sayHello());  }}

Now if you run this project, you will get the error “No provider for GreetingService!”

So, basically Angular is complaining that it did not find any provider for creating an instance of the greeting service or it does not know how to create an instance. In order to let the framework know how the instance should be created, we have to pass a provider object to the providers property in the component decorator shown below:

import { Component } from '@angular/core';import {GreetingService} from './greetingService';

@Component({  selector: 'my-app',  templateUrl: './app.component.html',  styleUrls: [ './app.component.css' ],  providers:[{      }]})export class AppComponent  {

constructor(private greetingService : GreetingService){   console.log(this.greetingService.sayHello());  }  }

In this provider object, we have many properties so let us understand them one by one.

Custom Factory

use factory: this will tell the framework which factory will be used while creating the object of the service. In our case, we don’t have any factory so let’s create one.

The factory will be a function which will be responsible for creating and returning the object of the service.

export function greetingFactory(){   return  new GreetingService()};

Or more short way

export const greetingFactory= () =>  new GreetingService ();

Custom Injection Token

The next thing is to create a property whose value will be an Injection Token instance. Using this property, the framework will uniquely identify our service and will inject the right instance of the service.

var greetingTokken = new InjectionToken<GreetingService>("GREET_TOKEN");

So in the above snippet, we are creating an instance of the InjectionToken class and it is generic. In our case, the GreetingService instance will be injected when someone asks for the injection with name greetingToken.

So far now our code will look like this:

import { Component ,InjectionToken} from '@angular/core';import {GreetingService} from './greetingService';

export const greetingTokken = new InjectionToken<GreetingService>("GREET_TOKEN");export const greetingFactory=()=>  new GreetingService();@Component({  selector: 'my-app',  templateUrl: './app.component.html',  styleUrls: [ './app.component.css' ],  providers:[{    provide  : greetingTokken,    useFactory : greetingFactory,     }]})export class AppComponent  {

constructor(private greetingService : GreetingService){   console.log(this.greetingService.sayHello());  }  name = 'Angular';}

But then also we will have the same error:

This is because in the constructor, where we are asking for the instance of our service, we have to tell it the unique string of our injection token that is greetingToken.

So let’s update our code:

export class AppComponent  {

constructor(@Inject(greetingTokken) private greetingService : GreetingService){   console.log(this.greetingService.sayHello('Neeraj'));  }  name = 'Angular';}

and now we will have the result that allows us to successfully pass a service from Angular dependency injection.

Now let us assume you have some nested dependencies like this:

import{DomSanitizer} from '@angular/platform-browser';

export class GreetingService{  constructor (private domSanitizer:DomSanitizer){      }  sayHello(name){    return `Hello ${name}`  }}

So, in this case, we have to pass one more property to the provider’s object (that is deps) which is the array of all the dependencies:

@Component({  selector: 'my-app',  templateUrl: './app.component.html',  styleUrls: [ './app.component.css' ],  providers:[{    provide  : greetingTokken,    useFactory : greetingFactory,    deps:[DomSanitizer]     }]})export class AppComponent  {

constructor(@Inject(greetingTokken) private greetingService : GreetingService  ){   console.log(this.greetingService.sayHello('Neeraj'));  }  name = 'Angular';}

Up until now, whatever we have done has only been for learning purposes. It is not recommended to create manual providers until there is a need.

So this is all the hard work done by Angular behind the scenes for us. We don’t have to do all this for registering our service. We can actually reduce the code, and instead of passing the factory and token manually, we can ask the framework to do this for us in that case.

The provide property, which is the injection token, will be the name of the service and Angular will internally create an injection token and factory for us.

We have to pass one more property (use-class) which tells the framework which class we need to use:

import { Component ,InjectionToken,Inject} from '@angular/core';

import {GreetingService} from './greetingService';

@Component({  selector: 'my-app',  templateUrl: './app.component.html',  styleUrls: [ './app.component.css' ],  providers:[{    provide  : GreetingService,    useClass :GreetingService     }]})export class AppComponent  {

constructor( private greetingService : GreetingService  ){   console.log(this.greetingService.sayHello('Neeraj'));  }  name = 'Angular';}

So now our code looks much cleaner and we can further reduce it by just passing the name of the service. Then Angular under the hood will create the provide object, the factory, and the injection token for us and make the instance available to us when needed.

import { Component } from '@angular/core';

import {GreetingService} from './greetingService';

@Component({  selector: 'my-app',  templateUrl: './app.component.html',  styleUrls: [ './app.component.css' ],  providers:[GreetingService]})export class AppComponent  {

constructor( private greetingService : GreetingService  ){   console.log(this.greetingService.sayHello('Neeraj'));  }  name = 'Angular';}

So in the end, our code looks very familiar. Now in the future, whenever you create a service, you know exactly what steps are involved to get that instance available.

If you like this article follow me to get more of this kind of stuff.

Visit Smartcodehub

A few months ago, I wrote an article explaining dependency injection. I had mentioned of a follow-up article with a hands-on session of Google Guice. While I am disappointed in being so late in writing this, part of me is happy that I was able to write a second article.

This article assumes that you are familiar with what dependency injection is. I would recommend you to glance through my previous article as we will be building upon the examples we used there. If you are hearing the term for the first time, it will be worth it. If you are familiar with it, reading it won’t take much time :)

If you haven’t worked much with Guice, please check it out on GitHub here.

We will need to set up a few things before we start

1. JDK: We will be using Java for this task. So you will need to have a working JDK to be able to run Java code in your computer. To check if it’s already installed, run ‘java -version’ on the command line. If the version is 1.6 or greater, we are good. Just a note: I don’t think it would make much sense to attempt this if you don’t have experience with Java.
2. Maven: We will be using maven as a build tool. To install maven, follow the instructions here https://maven.apache.org/install.html (Quite easy). To check if you already have maven, run ‘mvn -v’ on the command line.
3. git (optional): https://www.linode.com/docs/development/version-control/how-to-install-git-on-linux-mac-and-windows/
4. clone the hands on repository (FreshGuice): Run commands mentioned below

cd folder/to/clone-into/ git clone https://github.com/sankalpbhatia/FreshGuice.git

Bindings and Binding Annotations

We are ready now. Let me start by introducing two crucial terms in the Guice framework: Bindings and Binding Annotations.

Bindings: being the core concept of Guice, in literal terms, means an agreement or promise involving an obligation that cannot be broken. Now let’s map it in the context of Dependency Injection. When we make Guice bind an instance with a class, we make an agreement with Guice that “When I ask for an instance of X.java, give me this instance”. And this agreement can’t be broken.

Binding Annotations: Occasionally you’ll want multiple bindings for the same type. The annotation and (class) type together uniquely identify a binding. For example, in some cases, you might need two separate instances of the same class/ implementation of the same interface. To identify those, we use binding annotations. We will see some examples when we explain bindings.

How to create bindings

The user guide section of Guice explains it perfectly. So I will just be copying it here:

To create bindings, extend AbstractModule and override its configure method. In the method body, call bind() to specify each binding. These methods are type checked so the compiler can report errors if you use the wrong types. Once you've created your modules, pass them as arguments to Guice.createInjector() to build an injector.

There are a number of types of bindings: Linked, Instance, @Provides annotation, Provider bindings, Constructor bindings, and Un-targeted bindings.

For this article, I will only be covering Linked Bindings, Instance Bindings, @Provides annotation, and a special annotation @Inject. I very rarely use any other means to bind, but more information can be found at https://github.com/google/guice/wiki/Bindings.

1. Linked Binding: a Linked binding maps a type/interface to its implementation. This example maps the interface MessageService to its implementation EmailService.

In plain terms: When I ask Guice to give me an instance of MessageService, it will give me an instance of EmailService.

But, how will it know to create an instance of EmailService? We’ll see that later.

public class MessagingModule extends AbstractModule {  @Override   protected void configure() {    bind(MessageService.class).to(EmailService.class);  }}

Maybe we want more than one instance of MessageService in our project. At some places, we would want a SMSService to be associated with a MessageService, rather than an EmailService. In such cases, we use a binding annotation. To create a binding annotation, you will have to create two annotations like so:

@BindingAnnotation @Target({ FIELD, PARAMETER, METHOD }) @Retention(RUNTIME)public @interface Email {}

@BindingAnnotation @Target({ FIELD, PARAMETER, METHOD }) @Retention(RUNTIME)public @interface SMS {}

You need not know about the metadata annotations (@Target, @ Retention). If interested, please read this: https://github.com/google/guice/wiki/BindingAnnotations

Once we have the annotations with us, we can create two separate bindings which instruct Guice to create different instances of MessageService based on the BindingAnnotation (I think of it as a qualifier).

public class MessagingModule extends AbstractModule {  @Override   protected void configure() {   bind(MessageService.class).annotatedWith(Email.class)                             .to(EmailService.class);

   bind(MessageService.class).annotatedWith(SMS.class)                             .to(SMSService.class);  }}

2. Instance Binding: Binds a type to a specific instance

 bind(Integer.class) .annotatedWith(Names.named(“login timeout seconds”)) .toInstance(10);

One should avoid using .toInstance with objects that are complicated to create, since it can slow down application startup. You can use an @Provides method instead. In fact, you can even forget that we mentioned anything about Instance binding right now.

3. @ Provides annotation:

This is straight from Guice’s wiki, as it is fairly simple:

When you need code to create an object, use an @Provides method. The method must be defined within a module, and it must have an @Provides annotation. The method's return type is the bound type. Whenever the injector needs an instance of that type, it will invoke the method.

bind(MessageService.class)

.annotatedWith(Email.class)

.to(EmailService.class);

is same as

@Provides@Emailpublic MessageService provideMessageService() {  return new EmailService();}

where Email.java is a Binding annotation.

Dependencies can be passed to a method with this annotation which makes it extremely useful in real life projects. For example, for the code mentioned below, the injector will exercise the binding for the string parameter apiKey before invoking the method.

@Provides @PayPalCreditCardProcessor providePayPalCreditCardProcessor(      @Named("PayPal API key") String apiKey) {  PayPalCCProcessor processor = new PaypalCCProcessor();  processor.setApiKey(apiKey);  return processor;  }

4. @ Inject annotation (Just in Time binding): Whatever we covered up until now are called explicit bindings. If Guice, when trying to create an instance, does not find an explicit binding, it tries to create one using a Just-in-time binding.

Guice can create these bindings by using the class’s injectable constructor. This is either a non-private, no-arguments constructor or a constructor with the @Injectannotation.

Task

Now let’s move to the project we cloned from Github.

Like the examples in the previous article, this maven project implements a BillingService which charges a PizzaOrder using a credit card and generates a Receipt.

The project structure is as follows:

Interfaces

• BillingService — charges an order using a credit card
• CreditCardProcessor — debits some amount from a credit card
• TransactionLog — logs results

Classes

src

• CreditCard — entity representing a Credit Card
• PizzaOrder — entity representing a Pizza order
• Receipt — entity representing a receipt
• RealBillingService implements BillingService
• PaypalCreditCardProcessor implements CreditCardProcessor
• BankCreditCardProcessor implements CreditCardProcessor
• InMemoryTransactionLog implements TransactionLog
• GuiceTest — Main class which uses BillingService
• BillingModule — All Guice bindings go here
• GuiceInjectionTest : Unit tests to check binding constraints

The task here is to create Guice Bindings in the BillingModule such that the following constraints are satisfied:

1. All implementations of BillingService should be bound to RealBillingService.
2. CreditCardProcessor interface annotated with @Paypal should be bound to PaypalCreditCardProcessor class.
3. CreditCardProcessor interface named with string “Bank” should be bound to BankCreditCardProcessor class.
4. BillingService instances returned by injector should have an instance of BankCreditCardProcessor as their dependency.
5. All implementations of TransactionLog should be bound to InMemoryTransactionLog.

All five unit tests in GuiceInjectionTests should pass if the above conditions are satisfied. You should also be able to run the main method in GuiceTest.

To test correctness:

1. run unit tests

mvn test

This should run the test file GuiceInjectionTests.java.

2. run the main file

mvn exec:java -Dexec.mainClass="GuiceTest"

This should execute the main class of the project, which does the end to end work of creating an order, processes payment using a credit card and generates a receipt.

You can comment if you have any questions and I will try answering them. Please note that there is no single correct answer for this exercise. DM me your solutions and I will add the answers to the repository. Or better still, send me a pull request :)

Dependency Injection (DI) is a topic which I found a little difficult to grasp during my initial days as a software developer. I just could not find a good definition of the term.

In this article, I’ve tried to put my understandings of it in fairly simple language. It is intended for people starting out with DI, or those who just want to get a little more insight.

What is Dependency Injection?

First things first: what is it? Dependency Injection, like so much other software development jargon, is a fancy term for a rather simple concept.

The definition which I found most useful is:

Dependency injection means giving an object its instance variables.

That’s it. Providing (injecting) dependencies for a class. Simple right? Indeed.

Now, there are three ways of providing a class its dependencies in Java. All of them achieve…(coughs) Dependency Injection.

They are:

• Constructors
• Setters
• Directly setting public fields

Let’s see Dependency Injection in action

I have an application class named MyMessagePublisher which has a dependency on a certain EmailService class.

Dependency Injection using Constructor:

public class MyMessagePublisher {    private EmailService emailService = null;        public MyMessagePublisher(EmailService emailService){        this.emailService = emailService;    }}

See what the constructor is doing there? It is telling MyMessagePublisher to use the EmailService provided by it. The class instantiating MyMessagePublisher should provide (inject) an EmailService instance (using the constructor) to be used by MyMessagePublisher. Something like this:

EmailService emailService = new EmailService();MyMessagePublisher myMessagePublisher =                            new MyMessagePublisher(emailService);

Good job, Constructor!

Dependency Injection using Setter:

public class MyMessagePublisher {    private EmailService emailService = null;    public MyMessagePublisher() {    }    public setEmailService(EmailService emailService) {        this.emailService = emailService;    }}

What’s going on here? The class using MyMessagePublisher can now set the EmailService which they want to use. Something like this:

MyMessagePublisher myMessagePublisher = new MyMessagePublisher();myMessagePublisher.setEmailService(new EmailService());

Good job, Setter!

Dependency Injection by directly setting public fields

Never do this!! If you have reached this far reading this article, I believe you know that this approach is evil.

Benefits of Dependency Injection

I’ll start this section by explaining what we miss out on if we do not use DI.

Consider this code. I have defined the EmailService and MyMessagePublisher classes. MyMessagePublisher itself instantiates an EmailService object instead of using the DI techniques mentioned above.

public class EmailService {        public void sendEmail(String message, String receiver){        System.out.println("Email sent to " + receiver);    }}

public class MyMessagePublisher {    private EmailService emailService = new EmailService();    public void processMessages(String message, String receiver){        this.emailService.sendEmail(message, receiver);    }}

The above code has some limitations:

1. If EmailService initialization logic changes (it takes a constructor parameter to initialize), we would need to make changes to MyMessagePublisher class along with everywhere else in the codebase where we are using EmailService without DI.
2. It has tight coupling. Let’s say we want to move away from sending emails and instead start sending SMSs. We will then have to write a new publisher class.
3. This code is not testable. We will be sending emails to everyone while unit testing MyMessagePublisher class.

This is the solution I propose:

public class EmailService implements MessageService {    @Override    public void sendMessage(String message, String receiver) {        //logic to send email    }}

public class SMSService implements MessageService {    @Override    public void sendMessage(String message, String receiver) {        //logic to send SMS    }

public interface MessageService {    void sendMessage(String message, String receiver);}

public class MyMessagePublisher {    private MessageService messageService;        public MyMessagePublisher(MessageService messageService){        this.messageService = messageService;    }        @Override    public void processMessages(String msg, String rec){        this.service.sendMessage(msg, rec);    }}

This implementation overcomes all three limitations mentioned above.

• EmailService (or MessageService) initialization logic moves to the module initializing MyMessagePublisher
• We can move to a different implementation of MessageService which sends SMS without changing code in MyMessagePublisher
• The code is testable. We can use a dummy implementation of MessageService while unit testing MyMessagePublisher

Sweet. We have achieved DI using Constructors of our classes. Easy right? But there are some shortcomings here as well.

Issues with Vanilla Dependency Injection

When does this become a problem? When the code grows.

So what are the alternatives? Dependency Injection Containers (Spring, Guice, Dagger, and so on).

Let’s try to answer the questions above in more detail.

Consider the code below. We are designing an AllInOneApp which offers multiple services like booking movie tickets, recharging prepaid connections, transferring money, and online shopping.

public class BookingService {    private SlotsManager slotsManager;    private MyMessagePublisher myMessagePublisher; //Looks familiar?}

public class AllInOneApp  {    BookingService bookingService; // Class above    RechargeService rechargeService;    MoneyTransferService moneyTransferService;    ShoppingService shoppingService;}

AllInOneApp needs four dependencies to be initialized. Let’s use vanilla Dependency Injection using Constructor here and instantiate the AllInOneApp class.

public static void main(String[] args) {

AllInOneApp allInOneApp = new AllInOneApp(                new BookingService(new SlotsManager(),                                   new MyMessagePublisher(                                              new EmailService())),                 new RechargeService(...),                 new MoneyTransferService(..),                new ShoppingService(...));

}

This looks messy. Can we identify the problems here? A couple of them are:

• The class initializing AllInOneApp needs to know the logic to construct all the dependency classes as well. This is cumbersome when writing code in any decent sized project. Managing all these instances by ourselves is not what we want to do while writing business specific code.
• Although I have seen people prefer this kind of DI, I personally believe this code is less readable as compared to this:

AllInOneApp myApp = SomeDIContainer.getInstance(AllInOneApp.class);

If all the components use DI, somewhere in the system some class or factory must know what to inject into all these components (AllInOneApp, BookingService, MessageService etc).

This is where Dependency Injection containers come into picture. It is called a container and not a factory because the container often takes on more responsibility than just instantiating objects and injecting dependencies.

DI containers let us define what components are to be initiated and what dependencies to be injected in those components. We can also configure other instantiation features, like the object being a singleton or getting created every time it is requested.

I will be writing another article explaining the usage of one of the popularly used DI Containers, Google Guice, which will have a hands on practice section as well. I will update this story with it’s link soon. I will now leave you with this user guide which is a good place to start.

Thank you for reading :)