DEV Community: Jorge Cifuentes

A straightforward introduction to Dependency Injection

Jorge Cifuentes — Mon, 07 Dec 2020 01:07:28 +0000

This content was published here before.

This post presents a concise and short introduction to the technique called Dependency Injection (DI).

The task

Let's say you have a database with user-related data and that you want to query some of this data to process it. You might start with a class looking like this, using a SqlReader class:

public class Foo {

    SqlReader dataReader;

    constructor() {
        this.dataReader = new SqlReader();
    }

    public double Process(int userId) {
        var data = this.dataReader.QueryById(userId);
        // process the data
        // ...
    }        
}

The problem

Imagine that your software expands and, when running in a new mode, it should not get the data from a database but from some CSV files.

The main obstacle here is that our Foo class is coupled with the SqlReader: you can see it in the fact that a new instance is created in the constructor. In short words, it depends on an implementation: SqlReader is a dependency of Foo.

One could add this CSV functionality to the SqlReader class (ugly) or make CsvReader expand SqlReader (would get messy when adding even new more readers). This is a perfect use case for inversion of control.

The inversion of control

Theory

Here is where the concept Dependency Inversion gets to shine. Simply speaking, it means that the control of any class dependencies should be inverted: the Foo class shouldn't be the one instantiating a SqlReader.

This can be accomplished with the technique called Dependency Injection: it applies the principle that ensures classes are never responsible of supplying their own dependencies (they get injected).

And why is it important? It helps you decouple your application: you have the implemented code in one side, and the code that uses it in the other, both depending on a common interface. You can change them separately as long as it fits the interface, thanks to the concerns being separated.

The code

Usually, you would start by creating an interface IReader:

public class IReader {
    public List<Data> QueryById(int id);
}

and implement it for every reader you wanted:

public class SqlReader : IReader {
    public List<Data> QueryById(int id) {
        // ...
    }
}

public class CsvReader : IReader {
    public List<Data> QueryById(int id) {
        // ...
    }
}

Interfaces? Nothing new

You probably already knew about interfaces and, at the end of the day, an object based on one has to be instantiated with a concrete implementation. So how is it better if you're going to end up doing this?:

public class Foo {

    IReader dataReader;

    constructor() {
        this.dataReader = new SqlReader(); // <--- coupling
    }

    public double Process(int userId) {
        var data = this.dataReader.QueryById(userId);
        // process the data
        // ...
    }       
}

This is where the dependency inversion container plays its part: somewhere in your code, you still need to instantiate the implementation of the interface. The container is the one actually instantiating your objects and supplying them, so your code will look like this:

public class Foo {

    IReader dataReader;

    constructor(IReader r) { // <--- this is called by the container
        this.dataReader = r; // <--- injection
    }

    public double Process(int userId) {
        var data = this.dataReader.QueryById(userId);
        // process the data
        // ...
    }       
}

The container is a fairly complicated software that tracks and manages how interfaces are implemented. You could simplify them in your mind as a dictionary of interfaces mapped to implementing classes. Some examples of these containers are Autofac or Ninject.

With Autofac you can do something in the lines of this to have multiple implementations depending on some runtime variable:

if (someCondition)
    builder.RegisterType<SqlReader>().As<IReader>();
else
    builder.RegisterType<CsvReader >().AsIReader>();

The magic thing about containers, as opposed to wiring the dependencies yourself, is that you don't have to worry about calling the constructor with new SqlReader(). This is very useful with a lot of interfaces where the dependency chain is deeply nested. You just tell the container what implementation you want to use and let it inject it using the constructor in whatever number of classes you might have.

After these changes, total decoupling is achieved. Foo doesn't have to know any details of IReader or even how its instantiated: it just gets injected.

Note that containers usually can inject dependencies via the constructor, or a property or field.

So what is it useful for?

Extensibility and reusability

The first thing to note is that given your code is based on abstracts, extending it's as easy as implementing new classes and telling the container under which circumstances they should be used. The same code using IReader can work with a SqlReader, CsvReader, JsonReader or any other implementation. You can change and switch these classes without having to change the code that uses them.

Unit testing

If you wanted to test the Foo.Process method, hitting your database when running tests would be, most of the time, an anti-pattern and slow.

But, since Foo depends on the interface IReader, you can resolve this interface to SqlReader in normal execution and FakeDataReader while running tests. The FakeDataReader would just fake the database using in-memory variables. That would mean faster tests and in a more controlled and reproducible environment.

Safer parallel programming

Two developers can work with classes that use each other only based on the interface, without having to modify the other developer files. Less git conflicts 😃.

The cons

Obviously, the main adverse effect is the added layer of indirection. This makes the software a bit harder to understand - your implemented classes won't be directly referenced where they will be used. You won't be able to find references or easily trace them, and you won't know which implementation is injected until you debug it.

Wrap-up

To summarise, dependency injection is a technique used to satisfy the dependency inversion principle, introducing interfaces between a high-level class and its dependencies and making their relation loosely coupled assuring that the only central point where an interface is related to its actual implementation is in the container code.

Get your high-level class dependencies injected via the constructor (dependency injection).
Make this dependencies implement a common interface (decoupling).
Leave the hassle of calling all the injecting constructors to a dependency inversion container.

As a sidenote, using interfaces isn't inherent to dependency injection: you can have dependencies marked as a normal class and have them injected, but DI works better with interfaces.

At the end of the day, using this technique is a development decision up the creator. Any questions?

Integrating Google authentication with your Angular app

Jorge Cifuentes — Sat, 18 Apr 2020 17:15:28 +0000

This content was published here before.

From the user point of view, the option to log in to a website with a Google account is convenient and standardized. The Google OAuth API is the way to implement it and, while the library is developed in plain JavaScript, it can easily be integrated into your Angular application.

The OAuth flow is a simple yet powerful one: the user clicks on a "Sign in with Google" button present at your page and is prompted with a form to log into his Google account. When the log-in is done, the form window closes and gives you back the user data and a signed token. And that's all! You can use it to identify your users.

Grab your keys

First things first, you have to create a project through the Google API Console to which all log-ins will be associated. Refer to Google for the creation steps. Once created, under the Credentials options, you need to set up an "OAuth 2.0 Client". This will create a Client ID (our key) for you.

An explicit authorization has to be added for every URL under which the app is going to be stored. For testing purposes, whitelisting your local development site should be sufficient.

With this credentials, now your app is allowed to communicate to Google.

Get your app ready

The SDK is developed in plain JavaScript, so in order to make our compiler happy, we have to install the Typescript types provided by the DefinitelyTyped project. Open up a terminal and install them via npm:

npm install --save @types/gapi.auth2

By default, you should have the types loaded, since your TS compiler usually looks for them under the node_modules/@types folder, where this particular package is installed. If it's not the case, you can assert it filling the types array:

"compilerOptions": {"types": ["gapi.auth2"]}

tsconfig.json

And a script tag should be placed at your index. This will load the external code.

<script async defer src="https://apis.google.com/js/api.js"></script>

index.html

Place a button

I'm going to use a simple button for the user to log-in. When this button is clicked, a prompt will ask the user to grant permission to your application. Whether they complete the form or abandon it, we'll catch the result.

Create a component:

ng generate component auth-button

And give it a click handler:

<button (click)="authenticate()">Authenticate</button>

auth-button.component.html

Now, you're ready to add the logic behind it.

Make some promises

Talking to a server is an inherently asynchronous operation.

The gapi relies heavily in callbacks in a way I don't feel really comfortable with, so my personal approach here is wrapping the functions in Promises so they can be called in a more functional way.

For the set up, you will have to load the auth2 library and initialize it with your app key. I wrote this function to be called in a "lazy" way, that means, it's not to be called until authentication happens for the first time.

  async initGoogleAuth(): Promise<void> {
    //  Create a new Promise where the resolve 
    // function is the callback passed to gapi.load
    const pload = new Promise((resolve) => {
      gapi.load('auth2', resolve);
    });

    // When the first promise resolves, it means we have gapi
    // loaded and that we can call gapi.init
    return pload.then(async () => {
      await gapi.auth2
        .init({ client_id: 'YOUR_GOOGLE_KEY' })
        .then(auth => {
          this.gapiSetup = true;
          this.authInstance = auth;
        });
    });
  }

auth-button.component.ts

The second one is the actual authentication method we previously set as the click handler. We await for the prompt result and catch the result with the data or the error.

  async authenticate(): Promise<gapi.auth2.GoogleUser> {
    // Initialize gapi if not done yet
    if (!this.gapiSetup) {
      await this.initGoogleAuth();
    }

    // Resolve or reject signin Promise
    return new Promise(async () => {
      await this.authInstance.signIn().then(
        user => this.user = user,
        error => this.error = error);
    });
  }

auth-button.component.ts

This would work already, but if you want to keep your user logged in when they come back, you can check if there's one currently stored on your ngOnInit and use it:

  async checkIfUserAuthenticated(): Promise<boolean> {
    // Initialize gapi if not done yet
    if (!this.gapiSetup) {
      await this.initGoogleAuth();
    }

    return this.authInstance.isSignedIn.get();
  }

auth-button.component.ts

  async ngOnInit() {
    if (await this.checkIfUserAuthenticated()) {
      this.user = this.authInstance.currentUser.get();
    }
  }

auth-button.component.ts

After that, the local variable user is filled with the user data, including a unique ID, and can be sent to your server to be stored.

Talk to the server

Now that you have a way to identify each one of your users uniquely and unequivocally, the logical step forward is to send this info to your backend. Usually, you'd want to store the unique ID in your database system of choice.

It's not a secret that sending this ID plainly to your backend would raise a huge security issue: you have to consider everything that comes from your client insecure by default.

When the user logs in to your site through Google OAuth, the api gives you not only the personal data for the user but a token as well. Simply speaking, this token is generated and signed at Google's side and it states for whom user is valid and to which app, until when is valid amongst some other data. This token is what you will send to your server, and its validation is the way to make sure your application does not get compromised. Google provides the steps needed to validate one of its tokens.

Furthermore, they have already built-in libraries to do the dirty work in some languages. For example, for .NET a GoogleJsonWebSignature.ValidateAsync method is provided. If you inspect the code, you will see how every step is implemented.

Final thoughts

I hope you found this little covering interesting. You can check the working example in my GitHub.