DEV Community: Steven Victor

Using GraphQL in Golang

Steven Victor — Tue, 01 Sep 2020 16:50:43 +0000

Introduction

From the official GraphQL documentation, GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need, and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

I will be demonstrating with a simple application of how you start using GraphQL with Golang using the awesome gqlgen package

There are other packages used in Golang for GraphQL implementations, but these are the few reasons we use gqlgen:

gqlgen is based on a Schema first approach — You get to Define your API using the GraphQL Schema Definition Language.
gqlgen prioritizes Type safety — You should never see map[string]interface{} here.
gqlgen enables Codegen — We generate the boring bits, so you can focus on building your app quickly. You can get a complete read here

The purpose of this article is to give you a hands-on introduction to using Graphql in Golang. As such, we won't focus on definitions of terms in great detail.

We will be building a multi-choice question and answer application.

Basic Setup

You can get the complete code for this article here

Create a folder of the project at any location on your computer(preferably where you have your Go projects), initialize go mod, then install the package gqlgen package.

mkdir multi-choice
cd multi-choice
go mod init multi-choice
go get github.com/99designs/gqlgen

Then create a Makefile to house all the commands that will be used.

touch Makefile

Content:

init:
    go run github.com/99designs/gqlgen init

Initialize using:

make init

After running the above command, the project structure will look like this(from the documentation):

The end product of the application we will be building has this structure:

We will now customize to fit our use case.
The gqlgen.yml is modified to be:

Schemas

A GraphQL schema is at the core of any GraphQL server implementation. It describes the functionality available to the client applications that connect to it. - Tutorialspoint

gqlgen ships with a default schema.graphql. We can create more schemas based on project requirements.

The look of the schemas directory:

I thought it neat to have the schema for a particular functionality to be in just one file(including the mutation and the query).
Rather than have a huge mutation/query that houses all mutation/query descriptions, we will have several, based on the number of concerns/features we are to implement.

In a nutshell:

Base:

type Mutation {
    #schema here
}

type Query {
    #schema here
}

Extended:

extend type Mutation {
    #schema here
} 

extend type Query {
    #schema here
}

The Question Schema:

The Question Option Schema:

Observe there is no mutation/query. Well, question options are created only when questions are created, so they are not created independently.
The QuestionOptionInput was used as an argument in the Question schema defined above.

The Answer Schema:

Note:

Graphql does not permit more one definition of mutation/query. So we had to use the extend keyword when defining other mutation/query for other functionalities.
I don't consider it neat to have all mutation/query in one file as I have often seen from projects.

Custom Types

We can always add custom types outside the built-in types(ID, String, Boolean, Float, Int) to do so, we use the scalar keyword.
A good example is Time(created_at, updated_at, etc)
That can be defined in the schema.graphql file:

We don't need to bother adding the marshaling behavior to Go types; gqlgen has taken care of that. This also applies to other custom scalar types such as Any, Upload, and Map. Read more here. To add your own custom type, you will need to wire up the marshaling behavior to Go types.

Models

Models' directory structure:

The graphql schema defined in the schemas directory is translated into Go code and saved in the models.go file.

For example,

type Question {
    id: ID!
    title: String!
    questionOption: [QuestionOption]
    createdAt: Time!
    updatedAt: Time!
}

Is translated to:

type Question struct {
    ID             string            `json:"id"`
    Title          string            `json:"title"`
    QuestionOption []*QuestionOption `json:"questionOption"`
    CreatedAt      time.Time         `json:"createdAt"`
    UpdatedAt      time.Time         `json:"updatedAt"`
}

Where QuestionOption is a type just like Question

For us to translate schema to an actual Go code, we need to run a generate command.
Update the Makefile:

init:
    go run github.com/99designs/gqlgen init

generate:
    go run github.com/99designs/gqlgen

Then run the generate command:

make generate

This will generate the following in the models.go file

Observe that the mutation and query translations are not here. That will be in the resolvers as we will see later.

To have a different model for each schema, you can inform the gqlgen.yml about them. Read more here I think is neat to have the models inside the models.go file for now.

Custom hooks

You can define hooks to alter your model's behavior. In my case, I want the id to be a randomly generated string(UUID). So, to do that, I have to use gorm's BeforeCreate hook:

Custom tags

We might need to add extra tags to our model structs. For instance, we might add a "db" tag, a "gorm" tag, a "bson" tag(when using MongoDB).

This is defined in the path: models/model_tags

We can update the generate command in the Makefile so that we always add the model tags each time we run the generate command.

generate:
    go run github.com/99designs/gqlgen && go run ./app/models/model_tags/model_tags.go

Running the generate command:

make generate

We will now have the models.go updated as:

Resolvers

Structure:

A resolver acts as a GraphQL query handler
Mutations and Queries are translated into Go code and placed in the resolvers when the generate command is run:

make generate

So, for a mutation like this:

type Mutation {
    CreateQuestion(question: QuestionInput!): QuestionResponse
}

The corresponding translation is:

func (r *mutationResolver) CreateQuestion(ctx context.Context, question models.QuestionInput) (*models.QuestionResponse, error) {
   panic(fmt.Errorf("not implemented"))
}

The article slightly adheres to DDD(Domain Driven Design) principles. So I thought it cool to have the resolver.go and all resolver related files to be placed in the interfaces directory.

The Question Resolver:

The Answer Resolver:

The above are simple crud operations. We use dependency injection to require external functionalities. The dependencies used are:

QuestionService
QuestionOptionService
AnsService

which are defined in the base resolver file:

This makes our resolver methods to be easily testable. We can easily replace those dependencies with fake ones, so we can achieve unit testing. Kindly check the test files.

Domain

We injected some dependencies into our resolver above. Let's define those. This will be done in the domain:

The Question Repository:

The Question Option Repository:

The Answer Repository:

Infrastructure

We will now implement the interfaces defined above in the infrastructure layer:

Implementing Question Methods:

Implementing Question Option Methods:

Implementing Answer Methods:

From the above implementations, gorm is used as the ORM to interacting with the PostgreSQL database.

Next, let's look at db.go file, which has functions that open the db and run migration.

Running the Application

We have pretty much everything wired.
Let's now connect to the database, pass down the db instance.
All environmental variables are stored in a .env file at the root directory:

In the root directory, create the main.go file. The content of the server.go that graphql initial setup ships with are added to the main.go file, and the file is deleted.

We can update the Makefile that have the run and the test commands:

Run the application:

make run

Trying Some Endpoints

Create a Question with multi-choice

Get one question with multi-choice

Answer the question:

Running the tests

Integration Tests
You will need to create a test database and update the .env file with the credentials to run the integration tests in the infrastructure layer.
Unit Tests
The dependencies from the infrastructure layer are swapped with fake implementation. This allowed us to unit test the resolvers in the interfaces layer.

Having updated the .env, run all test cases from the root directory:

make test

Conclusion

You have seen how simple it can be to start using graphql in golang. I hope you enjoyed the article.
Get the complete code for this article here
I will be expanding on the current idea in future articles to add:

File upload
Authentication

Stay tuned!

You can follow me on twitter for any future announcement.

Thank you.

Converting your Unit and End-To-End Test Suites from Mocha, Chai, and Sinon to Jest in Nodejs.

Steven Victor — Sun, 22 Mar 2020 21:44:59 +0000

I started on a project recently and Jest is a requirement for testing. Making the switch from what I am already used to(mocha, chai, and sinon) is not difficult though, I wish to explain in this article some of the differences I observed using code samples.

Mocha

Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting while mapping uncaught exceptions to the correct test cases. In other words, mocha is a javascript test framework.

Chai

Chai is a BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework.

Sinon

Sinon provides standalone test spies, stubs and mocks for JavaScript.

Jest

Jest is a delightful JavaScript Testing Framework with a focus on simplicity.

Mocha or Jest?

Both Mocha and Jest are both javascript test frameworks(test runners).
A vivid comparison between both mocha and jest is found here.

Jest comes with built-in mocking and assertion abilities. In addition, Jest runs your tests concurrently in parallel, providing a smoother, faster test run. There’s no upfront configuration that you have to do. You just install it through npm or yarn, write your test, and run jest. Get the full details here.

Mocha provides developers with a base test framework, allowing you to have options as to which assertion, mocking, and spy libraries you want to use.
This does require some additional setup and configuration, which is a downside. However, if having complete control of your testing framework is something you want, Mocha is by far the most configurable and best choice. Get the full details here.

What we could deduce from the above explanation is that when using Jest, you have most of the tools that are needed both for your unit and end to end tests, such as assertion and mocking abilities, while when using Mocha, you will need to require external libraries for assertion and mocking. So, Chai can be used for assertions while Sinon can be used for mocking.

I have no problem using Jest alone or using Mocha along with Chai and Sinon. My use case is wholely dependent on the project requirement.

The project

I built a Mock Premier League Fixture API so as to demonstrate how you can use either jest or mocha. You can check out the code on github.
Jest is used in the master branch, while Mocha/Chai/Sinon are used in the mocha-chai-sinon branch.

Get the full code:
Using Jest here.
Using mocha here.

Test Setup

An in-memory database is used for the unit tests while a real test database is used for the end-to-end tests. Mongodb is used as the database in this project.

Jest Setup

This is only for jest use case.
First, install jest and @shelf/jest-mongodb and supertest(used for end-to-end tests)

npm install --save-dev jest supertest @shelf/jest-mongodb

Then we create a jest.config.js file in the root directory and specify the preset.

module.exports = {
  preset: '@shelf/jest-mongodb',
};

Next we, create jest-mongodb-config.js file which is used to configure our in-memory db for unit tests:

module.exports = {
  mongodbMemoryServerOptions: {
    instance: {
      dbName: 'jest'
    },
    binary: {
      version: '4.0.2', // Version of MongoDB
      skipMD5: true
    },
    autoStart: false
  }
};

We then need to setup database and seed data. Create the test-setup directory and the db-config.js and seed.js files

The db-config.js file looks like this:


import mongoose from 'mongoose'


//in-memory db used only in unit testing
export const connect = async () => {
  const mongooseOpts = {
    useNewUrlParser: true,
    autoReconnect: true,
    reconnectTries: Number.MAX_VALUE,
    reconnectInterval: 1000
  };
  await mongoose.connect(global.__MONGO_URI__, mongooseOpts)
};

//Drop database, close the connection. 
//Used by both unit and e2e tests
export const closeDatabase = async () => {
    await mongoose.connection.dropDatabase();
    await mongoose.connection.close();
};


//Remove all the data for all db collections. 
//Used by both unit and e2e tests
export const clearDatabase = async () => {
  const collections = mongoose.connection.collections;
  for (const key in collections) {
      const collection = collections[key];
      await collection.deleteMany();
  }
};

The file above is self-explanatory. You can checkout out the seed.js file in the repo

The last setup using jest is to specify the script to run in the package.json file:

    "test": "cross-env NODE_ENV=test jest --runInBand  --testTimeout=20000"

cross-env enable us run scripts that set and use environment variables across platforms. As seen above, it enabled us set our environment to test. Install using:

npm install cross-env

To disable concurrency (parallel execution) in Jest, we specify the runInBand flag so as to make Jest run tests sequentially.
We then specified a timeout of 20 seconds (20000ms).

Specify a key in the package.json file to tell jest about the test environment, files to ignore while testing and that test output should be in verbose.

"jest": {
    "testEnvironment": "node",
    "coveragePathIgnorePatterns": [
      "/node_modules/",
      "/dist/"
    ],
    "verbose": true
  },

Mocha, Chai and Sinon Setup

This is for Mocha, Chai, and Sinon users.
First, install mocha, chai and sinon, and their extensions that will be used in the unit and end-to-end tests

npm install --save-dev mocha chai chai-as-promised chai-http sinon @sinonjs/referee-sinon sinon-chai

For unit testing, we will need to install a mongodb memory server:

npm install mongodb-memory-server --save-dev

We then install nyc which is the Istanbul command-line interface for code coverage:

npm install nyc --save-dev

We next setup database and seed data. Create the test-setup directory and the db-config.js
The content of the db-config.js file:


import mongoose from 'mongoose'
import { MongoMemoryServer } from 'mongodb-memory-server'

const mongod = new MongoMemoryServer();

//in-memory db for unit test
export const connect = async () => {
  const uri = await mongod.getConnectionString();
    const mongooseOpts = {
      useNewUrlParser: true,
      autoReconnect: true,
      reconnectTries: Number.MAX_VALUE,
      reconnectInterval: 1000
    };

  await mongoose.connect(uri, mongooseOpts);

};

//works perfectly for unit test in-memory db
export const closeDatabase = async () => {
    await mongoose.connection.dropDatabase(); 
    await mongoose.connection.close();
};


//Remove all the data for all db collections. 
export const clearDatabase = async () => {
  const collections = mongoose.connection.collections;
  for (const key in collections) {
      const collection = collections[key];
      await collection.deleteMany();
  }
};

We use the mongodb-memory-server library to setup in-memory db for unit tests. This can also be used for jest but we followed a different approach, as seen in the jest setup.

Next, create the mocha.env.js file which is used to tell our test the environment to run on. We used cross-env to take care of this in the jest configuration above. I tried using that with mocha, but I didn't give the desired result.
So the mocha.env.js file:

process.env.NODE_ENV = 'test';

Then, the script file in package.json, where we will require the above file, use babel to convert ES6 to ES5, specify the directories mocha will look for when running our tests and set a timeout of 20seconds.

"test": "nyc --require @babel/register --require ./mocha.env.js  mocha ./api/**/*.test.js --timeout 20000 --exit"

An Example

Remember to stick to using one test framework(jest or mocha) per project.

Let's consider the signup/create user flow.
We have the user.controller.js file:

import User from '../models/user'
import validate from '../utils/validate'

class UserController {
  constructor(userService){
    this.userService = userService
  }
  async createUser(req, res) {
    const errors = validate.registerValidate(req)
    if (errors.length > 0) {
      return res.status(400).json({
        status: 400,
        errors: errors
      })
    }
    const { name, email, password } =  req.body

    let user = new User({
      name: name.trim(),
      email: email.trim(),
      password: password.trim(),
    })
    try {
      const createUser = await this.userService.createUser(user)
      return res.status(201).json({
        status: 201,
        data: createUser
      })
    } catch(error) {
      return res.status(500).json({
        status: 500,
        error: error.message
      })
    }
  }
}

export default UserController

We took the user's input from the request, called the registerValidate function from the validate.js file located in the utils directory in the repo, we then called the createUser method passing in the user to create. createUser is a method defined in the user.service.js file, which is passed into our controller using dependency injection.

The user.service.js file looks like this:

import User from '../models/user'
import password from '../utils/password';

class UserService {
  constructor() {
    this.user = User
  }
  async createUser(user) {
    try {
      //check if the user already exists
      const record = await this.user.findOne({ email: user.email })
      if (record) {
        throw new Error('record already exists');
      }
      user.password = password.hashPassword(user.password)
      //assign role:
      user.role = "user"
      //create the user
      const createdUser = await this.user.create(user);
      const { _id, name, role } = createdUser;
      //return user details except email and password:
      const publicUser = { 
        _id,
        name,
        role
      }
      return publicUser
    } catch(error) {
      throw error;
    }
  }
}

export default UserService

Unit Tests

Let's now wire our test cases for the files above.
To achieve unit test, we will need to mock external function/method calls.
From the user.controller.js file above, the createUser controller method we will mock the calls to registerValidate function, createUser service method, the response and the status that is sent back to the client.

Looking at the user.service.js file, the createUser service method called an external function, hashPassword to help us hash the password. To achieve unit testing, we will mock that.

Using Jest

a. Controller createUser method.
To mock the response and the status, we will use jest.fn(), which is used to create a jest mock object.
We use jest.spyOn to mock the registerValidate and createUser methods. It is used to mock just a function/method in a given object or class.

The user.controller.test.js file:

import faker from 'faker'
import validate from '../utils/validate'
import UserController from './user.controller'
import UserService from '../services/user.service'

const mockResponse = () => {
  const res = {};
  res.status = jest.fn().mockReturnValue(res);
  res.json = jest.fn().mockReturnValue(res);
  return res;
};

describe('UserController', () => {
  describe('createUser', () => {
    let userController, userService, res;

    beforeEach(() => {
      res = mockResponse()
      userService = new UserService();
    });
    afterEach(() => {    
      jest.clearAllMocks();
    });

    it('should create a user successfully', async () => {
      const req = {
        body: { name: faker.name.findName(), email: faker.internet.email(), password: faker.internet.password() }
      };
      //since validate is foreign, we have to mock it to achieve unit test. We are only mocking the 'registerValidate' function
      const errorStub = jest.spyOn(validate, 'registerValidate').mockReturnValue([]); //no input error
      const stubValue = {
        name: faker.name.findName(),
      };
      //We also mock the 'createUser' service method
      const stub = jest.spyOn(userService, 'createUser').mockReturnValue(stubValue);

      userController = new UserController(userService);

      await userController.createUser(req, res);

      expect(errorStub).toHaveBeenCalledTimes(1)
      expect(stub).toHaveBeenCalledTimes(1)
      expect(res.status).toHaveBeenCalledTimes(1);
      expect(res.json).toHaveBeenCalledTimes(1);
      expect(res.status).toHaveBeenCalledWith(201);
      expect(res.json).toHaveBeenCalledWith({'status': 201, 'data': stubValue});
    });
  });
});

You can check out the repo for unsuccessful user creation tests.
So, we tested only the createUser controller method and mocked all other methods that it depended on, with the help of jest mock and spies libraries. So we can say that the createUser controller method is unit tested🔥.

b. Service createUser method.
Instead of hitting a real database, we will use the in-memory database we had earlier set up in order to achieve unit tests in the services.

The user.service.test.js file:

import UserService from './user.service'
import  password from '../utils/password';
import { seedUser } from '../test-setup/seed'
import  { connect, clearDatabase, closeDatabase  }  from '../test-setup/db-config'


let seededUser

//Connect to in-memory db before test
beforeAll(async () => {
  await connect();
});
beforeEach(async () => {
  seededUser = await seedUser()
});
// Clear all test data after every test.
afterEach(async () => {
  await clearDatabase();
});
// Remove and close the db and server.
afterAll(async () => {
  await closeDatabase();
});


describe('UserService', () => {
  describe('createUser', () => {
    it('should not create a new user if record already exists', async () => {
      let user = {
        name: 'frank',
        email: seededUser.email,
        password: 'password',
      }
      const userService = new UserService();

      await expect(userService.createUser(user)).rejects.toThrow('record already exists'); 
    });

    it('should create a new user', async () => {
      let userNew = {
        name: 'kate',
        email: 'kate@example.com',
        password: 'password',
      }

      //'hashPassword' is a  dependency, so we mock it, and return any value we want
      const hashPass = jest.spyOn(password, 'hashPassword').mockReturnValue('ksjndfklsndflksdmlfksdf')

      const userService = new UserService();
      const user = await userService.createUser(userNew);

      expect(hashPass).toHaveBeenCalled();
      expect(user._id).toBeDefined();
      expect(user.name).toBe(userNew.name);
      expect(user.role).toBe(userNew.role);
    });
  });

We have both a failure and a successful test case. For the failure test, we first seeded our in-memory db with a user, then tried to insert a record that has the same email as the seeded user. We expected that test to throw an error, which it did:

   await expect(userService.createUser(user)).rejects.toThrow('record already exists');

We also tested for a successful insertion.

Using Mocha/Chai/Sinon

We will mock external methods and functions using sinon's stub.

a. Controller createUser method.
The user.controller.test.js file will look like this:

import chai from 'chai'
import sinon from 'sinon'
import sinonChai from 'sinon-chai'
import faker from 'faker'
import validate from '../utils/validate'
import UserController from './user.controller'
import UserService from '../services/user.service'

chai.use(require('chai-as-promised'))
chai.use(sinonChai)
const { expect } = chai

const mockResponse = () => {
  const res = {};
  res.status = sinon.stub()
  res.json = sinon.stub()
  res.status.returns(res);
  return res;
};

describe('UserController', () => {
  let userController, userService, res, sandbox = null;
  beforeEach(() => {
    sandbox = sinon.createSandbox()
    res = mockResponse()
    userService = new UserService();
  });
  afterEach(() => {
    sandbox.restore()
  })

  describe('createUser', () => {
    it('should create a user successfully', async () => {
      const req = {
        body: { name: faker.name.findName(), email: faker.internet.email(), password: faker.internet.password() }
      };
      //since validate is foreign, we have to mock it to achieve unit test. We are only mocking the 'registerValidate' function
      const errorStub = sandbox.stub(validate, 'registerValidate').returns([]); //no input error

      const stubValue = {
        name: faker.name.findName(),
      };
      const stub = sandbox.stub(userService, 'createUser').returns(stubValue);

      userController = new UserController(userService);
      await userController.createUser(req, res);

      expect(errorStub.calledOnce).to.be.true;
      expect(stub.calledOnce).to.be.true;
      expect(res.status.calledOnce).to.be.true;;
      expect(res.json.calledOnce).to.be.true;;
      expect(res.status).to.have.been.calledWith(201);
      expect(res.json).to.have.been.calledWith({'status': 201, 'data': stubValue});

    });
  });
});

As seen above, the beforeEach() hook, we created a sinon sandbox. Sandboxes remove the need to keep track of every fake created, which greatly simplifies cleanup. It becomes useful when other tests are added, as shown in the repository.

b. Service createUser method
The user.service.test.js file will look like this:


import chai from 'chai'
import sinon from 'sinon'
import UserService from './user.service'
import  password from '../utils/password';
import { seedUser } from '../test-setup/seed'
import  { connect, clearDatabase, closeDatabase  }  from '../test-setup/db-config'

chai.use(require('chai-as-promised'))
const { expect } = chai

describe('UserService', () => {

  let seededUser, sandbox = null

  //Connect to in-memory db 
  before(async () => {
    await connect();
  });
  beforeEach(async () => {
    seededUser = await seedUser()
    sandbox = sinon.createSandbox()
  });
  //Clear all test data after every test.
  afterEach(async () => {
    await clearDatabase();
    sandbox.restore()
  });
  //Remove and close the db and server.
  after(async () => {
    await closeDatabase();
  });

  describe('createUser', () => {
    it('should not create a new user if record already exists', async () => {

      let user = {
        name: 'frank',
        email: seededUser.email,
        password: 'password',
      }
      const userService = new UserService();
      await expect(userService.createUser(user)).to.be.rejectedWith(Error, 'record already exists')
    });

    it('should create a new user', async () => {

      let userNew = {
        name: 'kate',
        email: 'kate@example.com',
        password: 'password',
      }

      //'hashPassword' is a  dependency, so we mock it
      const hashPass = sandbox.stub(password, 'hashPassword').returns('ksjndfklsndflksdmlfksdf')

      const userService = new UserService();
      const user = await userService.createUser(userNew);

      expect(hashPass.calledOnce).to.be.true;
      expect(user._id).to.not.be.undefined
      expect(user.name).to.equal(userNew.name);
      expect(user.role).to.equal(userNew.role);
    });
  });
});

You can see that we have two tests in the above suite. One failure and one success. For the failure test, we seeded our in-memory db and tried to add a record with the same email like the one in the db. You might need to pay attention to this line:

await expect(userService.createUser(user)).to.be.rejectedWith(Error, 'record already exists')

We expected the promise to be rejected with an error. This was made possible using:

chai.use(require('chai-as-promised'))

We have used the create user functionality to see how we can write unit tests in our controllers and services, using either jest or mocha test framework. Do well to check the repo for the entire test suites.

End To End Tests(e2e)

For our e2e tests, we won't be mocking any dependency. We want to really test an entire functionality that cuts across different layers at a goal. This is essential as help gives us confidence that all layers in our api as working as expected. We will only see an example when jest is used. You can check the mocha-chai-sinon branch for e2e tests using mocha.

The entire e2e tests inside the e2e_tests directory:

A couple of things to note, we will use the supertest installed earlier in our e2e tests. We also use a real test database. You can check the db configuration in the database directory from the repository.

User e2e test

import supertest from 'supertest'
import app from '../app/app'
import http from 'http'
import User from '../models/user'
import { seedUser } from '../test-setup/seed'
import  { clearDatabase, closeDatabase  }  from '../test-setup/db-config'


let server, request, seededUser

beforeAll(async () => {
  server = http.createServer(app);
  await server.listen();
  request = supertest(server);
});
beforeEach(async () => {
    seededUser = await seedUser()
});
//Clear all test data after every test.
afterEach(async () => {
  await clearDatabase();
});
//Remove and close the test db and server.
afterAll(async () => {
  await server.close();
  await closeDatabase();
});


describe('User E2E', () => {
  describe('POST /user', () => {
    it('should create a user', async () => {
      let user = {
        name: 'victor',
        email: 'victor@example.com',
        password: 'password'
      }
      const res = await request
                        .post('/api/v1/users')
                        .send(user)

      const { _id, name, role } = res.body.data

      //we didnt return email and password, so we wont assert for them
      expect(res.status).toEqual(201);
      expect(_id).toBeDefined();
      expect(name).toEqual(user.name);
      expect(role).toEqual('user');

      //we can query the db to confirm the record
      const createdUser = await User.findOne({email: user.email })
      expect(createdUser).toBeDefined()
      expect(createdUser.email).toEqual(user.email);
      //since our password is hashed:
      expect(createdUser.password).not.toEqual(user.password);
    });

    it('should not create a user if the record already exist.', async () => {
      let user = {
        name: 'chikodi',
        email: seededUser.email, //a record that already exist
        password: 'password'
      }
      const res = await request
                        .post('/api/v1/users')
                        .send(user)

      expect(res.status).toEqual(500);
      expect(res.body.error).toEqual('record already exists');
    });


    it('should not create a user if validation fails', async () => {
      let user = {
        name: '', //the name is required
        email: 'victorexample.com', //invalid email
        password: 'pass' //the password should be atleast 6 characters
      }
      const res = await request
                        .post('/api/v1/users')
                        .send(user)

      const errors =  [ 
        { name: 'a valid name is required' },
        {email: 'a valid email is required'},
        { password: 'a valid password with atleast 6 characters is required' } 
      ]                  
      expect(res.status).toEqual(400);
      expect(res.body.errors).toEqual(errors);
    });
  });
});

From the above, we have two failure tests and one successful test case.
We created a fake server so that we don't listen to the real server and mess it up. After the test, we close the fake server.
You can check how this test is done using mocha, chai, and chai-http from the mocha-chai-sinon branch.

A sample output of the project entire test suites:

Conclusion

With a few examples, we have explored use cases when using jest and mocha. These are some of my findings:
a. Declaring test hooks can be defined both inside and outside the describe block when using jest. This is not the case when using mocha, as test hooks are defined inside a describe block.
b. Jest has instabul built it for test coverage by using the --coverage flag when running tests. This is not the case with mocha which requires an external package nyc(which is Istanbul command line interface) for test coverage.
c. Jest has most of the test tools built-in, hence you can hit the ground running immediately. Mocha provides you a base test framework and allows you to use libraries of your choice for assertions, spies, and mocks.

Get the full code:
Using Jest here.
Using mocha here.

Happy Testing.

You can follow on twitter for new notifications.

Using Domain-Driven Design(DDD)in Golang

Steven Victor — Sat, 22 Feb 2020 17:49:07 +0000

Domain-Driven Design pattern is the talk of the town today.
Domain-Driven Design(DDD) is an approach to software development that simplifies the complexity developers face by connecting the implementation to an evolving model.

Note

This is not an article that explains the "ideal" way to implement DDD in Golang because the author is no way an expert on it. This article is rather the author's understanding of DDD based on his research. The author
will be very grateful to contributions on how to improve this article.
Check the github repo for the updated code:
https://github.com/victorsteven/food-app-server

Why DDD?
The following are the reasons to consider using DDD:

Provide principles & patterns to solve difficult problems
Base complex designs on a model of the domain
Initiate a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses domain problems.

The idea of Domain-Driven Design was inverted by Eric Evans. He wrote about it in a book which you can find some of the highlights here

DDD comprises of 4 Layers:

Domain: This is where the domain and business logic of the application is defined.
Infrastructure: This layer consists of everything that exists independently of our application: external libraries, database engines, and so on.
Application: This layer serves as a passage between the domain and the interface layer. The sends the requests from the interface layer to the domain layer, which processes it and returns a response.
Interface: This layer holds everything that interacts with other systems, such as web services, RMI interfaces or web applications, and batch processing frontends.

To have a thorough definition of terms of each layer, please refer to this

Let's get started.

We are going to build a food recommendation API.

You can get the code if you don't have all the time to read.
Get the API code here.
Get the Frontend code here.

The very first thing to do is to initialize the dependency management. We will be using go.mod. From the root directory(path: food-app/), initialize go.mod:


 mod init food-app

This is how the project is going to be organized:

In this application, we will use postgres and redis databases to persist data. We will define a .env file that has connection information.
The .env file looks like this:

This file should be located in the root directory(path: food-app/)

Domain Layer

We will consider the domain first.
The domain has several patterns. Some of which are:
Entity, Value, Repository, Service, and so on.

Since the application we are building here is a simple one, we consider just two domain patterns: entity and repository.

Entity

This is where we define the "Schema" of things.
For example, we can define a user's struct. See the entity as the blueprint to the domain.

From the above file, the user's struct is defined that contains the user information, we also added helper functions that will validate and sanitize inputs. A Hash method is called that helps hash password. That is defined in the infrastructure layer.
Gorm is used as the ORM of choice.

The same approach is taken when defining the food entity. You can look up the repo.

Repository

The repository defines a collection of methods that the infrastructure implements. This gives a vivid picture of the number of methods that interact with a given database or a third-party API.

The user's repository will look like this:

The methods are defined in an interface. These methods will later be implemented in the infrastructure layer.

Almost the same applies to the food repository here.

Infrastructure Layer

This layer implements the methods defined in the repository. The methods interact with the database or a third-party API. This article will only consider database interaction.

We can see how the user's repository implementation looks like:

Well, you can see that we implemented the methods that were defined in the repository. This was made possible using the UserRepo struct which implements the UserRepository interface, as seen in this line:



//UserRepo implements the repository.UserRepository interface
var _ repository.UserRepository = &UserRepo{}

You can check the repository on how the food repository was implemented here.

So, let's configure our database by creating the db.go file with the content:

From the above file, we defined the Repositories struct which holds all the repositories in the application. We have the user and the food repositories. The Repositories also have a db instance, which is passed to the "constructors" of user and food(that is, NewUserRepository and NewFoodRepository).

Application Layer

We have successfully defined the API business logic in our domain. The application connects the domain and the interfaces layers.

We will only consider the user's application. You can check out that of the food in the repo.

This is the user's application:

The above have methods to save and retrieve user data. The UserApp struct has the UserRepository interface, which made it possible to call the user repository methods.

Interfaces Layer

The interfaces is the layer that handles HTTP requests and responses. This is where we get incoming requests for authentication, user-related stuff, and food-related stuff.

User Handler

We define methods for saving a user, getting all users and getting a particular user. These are found in the user_handler.go file.

I want you to observe that when returning the user, we only return a public user(which is defined in the entity). The public user does not have sensitive user details such as email and password.

Authentication Handler

The login_handler takes care of login, logout and refresh token methods. Some methods defined in their respective files are called in this file. Do well to check them out in the repository following their file path.

Food Handler

In the food_handler.go file, we have methods for basic food crud: creating, reading, updating, and deleting food. The file has explanations of how the code works.

Please note, when testing creating or updating food methods via the API using postman, use form-data not JSON. This is because the request type is multipart/form-data.

Running the Application

So, let's test what we've got. We will wire up the routes, connect to the database and start the application.

These will be done in the main.go file defined in the directory root.

The router(r) is of type Engine from the gin package we are using.

Middleware

As seen from the above file, Some routes have restrictions. The AuthMiddleware restricts access to an unauthenticated user. The CORSMiddleware enables data transfer from different domains. This is useful because VueJS is used for the frontend of this application and it points to a different domain.
The MaxSizeAllowed middleware stops any file with size above the one the middleware specifies. Since the food implementation requires file upload, the middleware stops files greater than the specified to be read into memory. This helps to prevent hackers from uploading an unreasonable huge file and slowing down the application. The middleware package is defined in the interfaces layer.

We can now run the application using:



go run main.go

Bonus

Vue and VueX are used to consume the API. Get the repository here, You can also visit the url and play with it.
Test cases are written for most of the functionality. If you have time, you can add to it. To achieve unit testing for each of the methods in our handler, we created a mock package(in the utils directory) that mocks all the dependencies that are used in the handler methods.
Circle CI is used for Continuous Integration.
Heroku is used to deploy the API
Netlify is used to deploy the Frontend.

Conclusion

I hope you didn't have a hard time following this guideline on how to use DDD in when building a golang application. If you have questions or any observations, please don't hesitate to use the comment section. As said early, the author is not an expert on this. He simply wrote this article based on his use case.
Get the API code here.
Get the Frontend code here.
You can also visit the application url and play with it.

Check out other articles on medium here.

You can as well follow on twitter

Happy DDDing.

A Working Solution to JWT Creation and Invalidation in Golang

Steven Victor — Sat, 25 Jan 2020 22:31:41 +0000

Before you proceed

This is part 1 of the two-part series.
This part solely focused on creating a JWT that has no expiration date. While this seems cool, it can have security issues. For example, in the event that the JWT is hijacked. If this happens the only remedy in this article is, when the authenticated user logs out, the token will be revoked and can't be used any further(by either the hijacker or the user). So the user can obtain a new one when he login again.

In part 2 of this series, Two tokens will be used:

Short Term Token: also known as access token(usually 15 mins)
Long Term Token: also known as refresh token(usually 1 week) This approach is more secure compared to the above. Once the article is ready, the link will be provided here.

Introduction

Whenever JWT is mentioned to be used for authentication, there is this question that is always asked by developers that have experience using it:
when a user logout, what happens to the JWT?
That question is a nightmare.

What this article solved: Once that user logs out, the JWT used is invalidated that very second! Without waiting for any expiration time if any was set when the token was created.

Using my Github account as a case study. I don't get logged out except I explicitly trigger the logout button.
When using JWT, many have advocated that the token should have a short time span(15min, 20min, etc), the token should be revoked often time than not, blah, blah, blah.
Think about it, if a token lifespan is short, say 10mins, it means, after that period, you will be logged out and need to log in again😡. Except for applications that require that(payment applications, etc), I see no reason why I should go through this pain.

Solutions to the JWT discussion before now from this reading, include:

Set a reasonable expiration time on tokens
Delete the stored token from client-side upon log out
Have DB of no longer active tokens that still have some time to live
Query provided token against The Blacklist on every authorized request.

Issues from the above-mentioned solutions:

What if you set the expiration of 1 hour for a JWT, then the user login, then logout after like 1 minute or so? What it means is, that JWT will be valid for an additional 59 minutes; ample time for a hacker to do his thing💀, in the event that the user JWT was hijacked.
About Blacklist stuff. This is what that means: Once a user logs out, add the token he used to a blacklist table in your database(Redis preferably). So once the user wants to perform a request that requires authentication and provides that token, then blacklist table will be queried to check if a token has been created before by that user and have not expired, if found, don't allow the user to get away with his mischievous act, hold him right there✊.
While this approach seems cool, it has obvious downsides:
When creating the token(during signup or login), I must specify a time when the token expires in my code. When that time elapses, the user will be forced to login again. I definitely don't want this.
You might argue that you can create a token that does not expire right? Well, what it means is that your blacklist table will soon have "zillions" of rows of JWT tokens not used by anyone, and you cannot afford to delete any because a user might wait patiently and reuse a token he has been saving for like a year now, just to test the integrity of your application🧐.

This is what this article is all about:

We want a type of application in which the user does not try to access his account after a few minutes or hours and discover that he is logged out because we are trying to protect them from hackers💀. Don't get me wrong, it all depends on the time of application. For instance, my banking application logs me out after say 5min of inactivity, which is a good use case.
We want an application in which, when the user chooses to logout, he does so, and can't try to use that same JWT he used before logging out for any authenticated request. He should not be allowed.
We don't an application that has "zillions" of rows of blacklisted JWTs. Total no! I mean, why waste resources?

So this is what we want:
An application that can keep the user logged in forever except the user chooses to explicitly logout. I don't know about you, but this is how I
use my Twitter, Github, and so on.
To achieve this in your application, this piece is for you. Especially when you want to use JWT.

This is the trick I used:
I created a database table called auths, the table has three columns: id, user_id and auth_uuid. Pay attention to the auth_uuid. It is created from uuid. UUID stands for a universally unique identifier. When a user login, a JWT is created. The user_id and auth_uuid are used as claims for that JWT. The **user_id is the id of the user who attempts to login, while the auth_uuid is created using a helper package called: twinj. When a user logs out, the created row(of the user_id and the auth_uuid is deleted from the auths table). What it now means is, though the JWT has not expired, it cannot be used to make any further requests on behalf of that user.
Reason: because part of its claims are deleted. For that user to make any authenticated request again, he needs to login, which will create a new JWT for him then also a new row is added to the auths table, with the user_id and a brand new auth_uuid. Take note that a new uuid is created for each JWT according to the code implementation you will below.
If what was explained above is not clear, please look at the example below where it was demonstrated.

Building

Consider a simple Todo Restful API with Authentication.

Basic StepUp

a. From any location, you prefer in your computer, create a directory called manage-jwt


 mkdir manage-jwt

b. Change to that directory


 manage-jwt

Then initialize go modules:


 mod init manage-jwt

c. Environmental variables.
We will store all our environmental variables in .env file.
From the root directory, create the .env file:


 .env

Creating JWT

From your project root directory(path: manage-jwt/), create the auth package(directory), then the auth.go file


 auth


 auth && touch auth.go

From the file above, we created the JWT with the UserId and a AuthUuid, as seen in the AuthDetails struct. We also have functions that verify the token and extract the UserId and the AuthUuid.

Wiring the Models

From the root directory, create the model directory. This is where we will have our database initialization and all database related stuff.


 model

a. Let's create the base_model.go file.


 model && touch base_model.go

From the above file, we have the Initialize method and an interface that is a collection of our model methods we will define soon.

b. Create the user model


 touch user.go

We have methods that validate the email, create a user and get a user by email.
Since the sole aim of this article is about jwt, we left implementation as basic as possible.

c. Create the todo model


 todo.go

As seen in the above file, we just have the CreateTodo model, since we are focused on JWT.

d. Create the auth_uuid model


 auth_uuid.go

We functionalities to create, get and delete the uuid and the user id associated with the jwt. For instance, the CreateAuth method is used in the Login controller function(this will be defined later), the auth created have the AuthUuid and the UserId. These are then used as claims when creating the JWT.
Whenever a request is made that requires authentication, the FetchAuth method is called, which lookup the auths table and check for the auth_uuid and the user_id. If they exist, the next line of action is taken(such as Creating a Todo, Logging out the user, etc).
The DeleteAuth method is used to delete the auth_uuid and user id from the auths table. This happens during logout, thus, rendering that JWT useless😪 because it cannot be used for any other request. Ever!.

Take note that the JWT is not deleted. It still exists, but it is invalid because the claims used to form it are no more. What actually made this possible is the uuid. Since the uuid is unique at its creation, there is little or no chance of having the same uuid in auths table. Even if that eventually happens, the user id is ever unique. We can't two or more same user id in the auths table.
This is how the uuid table looks like:

id	user_id	auth_uuid
1	1	83b09612-9dfc-4c1d-8f7d-a589acec7081
-----	----------	---------------------------------------
2	2	14033612-df45-sdf3-137d-dfsdfd32243d

So, when the DeleteAuth method is called, the row that matches the parameters provided is deleted. Then no further request can be carried out with that JWT again because the auths table will always be checked👨‍✈️.

Wire up the Signin Service

Before any authenticated request is made, the user needs to the signed in. This is where the CreateToken function from the auth package is called.

From the root directory, create the service directory:


 service

Then, create the signin_service.go file:


 service && touch signin_service.go

This would simply have been done without an interface. The purpose of defining the method in an interface is to enable us to mock it when writing test cases.
Observe that we passed as parameter the AuthDetails struct which defines the auth_uuid and the user id; which are used as claims when creating JWT.

Wire up the Controllers

From the project root(path: /manage-jwt), create the controller directory(package).

a. The User Controller
Create the user_controller.go file


 controller && touch user_controller.go

Keeping things super simple, so as not to distract the main purpose of the article.

b. The Login Controller
A user can login after he has signed up(been created).
Create the login_controller.go file


 touch login_controller.go

As seen in the file above, we have both the Login and the LogOut functions.
Observe in the Login function that we created a new row in the auths table when we called CreateAuth method, we then passed its return value to the SignIn method, which calls the CreateToken function.
So now, we have a JWT and a row in the auths table that has the auths and the user id used as claims when creating the token.

From the LogOut function, called the DeleteAuth method that deleted that row created in the auths table, thus rendering the JWT useless.

Note: Remember that before you logout, you must be authenticated, so you must add to the header of your request a valid JWT.

c. The Todo Controller
Create the todo_controller.go file.


 touch todo_controller.go

Creating a todo requires a user to be authenticated. From the CreateTodo function, we extracted the JWT claims(particularly AuthUuid and the UserId). We then checked the validity of those by calling FetchAuth method. If everything goes well, we then proceed to create the todo.

Routing and Starting the Application

Let's connect everything together and fire up the application.
From the root directory, create the app directory:

app

a. Routing
Then create the router.go file:


 app && touch router.go

Observe that we called a middleware we have not created yet and we used a router. We will create these shortly.

b. The StartApp function
Still, in the app directory, create the app.go file:


 touch app.go

The above file defined the router variable referenced in the router.go file. It also called the Initialize method(defined in the model), for the database connection. We called the route() function and also started the application.

c. The Middleware
From the root directory(path: manage-jwt/), create the middlewares directory, then the middlewares.go file


 middlewares


 middlewares && middlewares.go

The TokenAuthMiddleware function help to protect routes that require authentication.

d. The main.go file
It is time to finally test our hard work💪. From the root directory, create the main.go file and call the StartApp function defined above:


 main.go

Then run:



go run main.go

Your app should be on fire🔥 if you followed the instructions above.

Testing with Postman

Let's try our hands on some endpoints

a. /user endpoint: for creating a user(signup). Provide an email address to be signed up.

b. /login endpoint

c. /todo endpoint: Let's create a todo with the token generated above.
This token will be added in the Authorization: Bearer Token

d. /logout endpoint
To logout, you must be authenticated, so add the above token in the Authorization: Bearer Token

Bonus

a. The API is deployed is to heroku. You can test using:
https://manage-jwt.herokuapp.com.

b. Test Cases are added for the above functionalities, get the Github repository here and run tests from the root directory using:



go test ./...

c. Circle CI is used for Continuous Integration.

d. The application is already dockerized. You can run it on docker if you wish. Setup is found in the repo.

Conclusion

So, there you have it. The JWT monster has been trampled on our feet, as we can invalidate it at any time if we wish.

Get the repository here, which you can star to track any new update.

Test the API in production using the url: https://manage-jwt.herokuapp.com.

Happy Forcing JWT to be useless at will🤣.

Follow me on Twitter to get notified of current releases.

Also, follow here on dev.to

Thank you.

Using Golang Concurrency in Production

Steven Victor — Sun, 19 Jan 2020 23:43:04 +0000

In this article, we will see how Asynchronous Programming is achieved in Golang using a real-world application.

Asynchronous
Our daily chores are filled with concurrent(asynchronous) activities.
For instance, When making a coffee, you boil water, put the coffee in your mug, add other ingredients you need, then finally add the boiled water into the mug. Your coffee is ready.

Synchronous
From the instance above, doing this synchronously will mean you waiting for a task to be done first before undertaking another. That is, Place the water on the heater, do nothing else until that water boils. Of course, we consider this approach a total waste of our time and somewhat inefficient.
Hence, it is inefficient to implement a feature that is asynchronous in nature synchronously.

I wrote a real-world program: Username Lookup Application, which demonstrates how asynchronous programming is utilized in making HTTP calls to different endpoints at the same time and retrieving data. This is how it works, you provide a username to look up, then that username is checked across the accounts you specify(such as Twitter, Instagram, Github, and so on). Visit the application here
You can also get the code on Github

The Application Overview.

Golang is used on the backend
VueJS is used on the frontend
Docker is used to deploying on Heroku
Travis is used for Continous Integration

Steps Taken

Step 1: Basic Setup

Create the root folder for the project titled: username_across_platforms

mkdir username_across_platforms

Initialize go modules with the name of the folder created above:

go mod init username_across_platforms

Step 2: Client Implementation(for HTTP calls)

Create the server package:

mkdir server

Since we will be making HTTP requests to the different urls, we will need a client. Note, the client here is not the frontend. It is used for HTTP calls on the server-side.
Inside the server package(folder), create the client package(directory):

cd server && mkdir client

Then create client.go inside the client package:

cd client && touch client.go

From the above file, you might be wondering why we used an interface and stuff, this will make sense to you when you see the test files. We will need to mock the GetValue method. We can't do this except the method is defined in an interface.
Something else I want you to observe is how we implemented the interface.
We defined a clientCall struct which the GetValue method 'belongs to'. Then the struct now implements the interface in this line:

ClientCall HTTPClient = &clientCall{}

The struct also has the http.Client. This will help us replace the actual **http.Client with a fake one, so we don't make a real http call while writing test cases.
Still, in the same package, create the test file:

touch client_test.go

From the above file, we fake the real http call with the help of the RoundTripFunc, another option you might consider is using httptest.Server.
You could see how the Transport of the http.Client is swapped with our RoundTripFunc in the NewFakeClient function.

Step 3: Provider Implementation

Since our client is in place with enough unit tests to back it, let us create the provider that calls the GetValue method of the client and pass the response it obtained to a channel.
From the server package(directory), create the provider package then the provider.go file:

mkdir provider

cd provider && touch provider.go

As seen in the file, the CheckUrl method is defined in an interface(because we need to mock it in the future while writing unit tests). In the method implementation, we passed the url to look up and the channel to send the response or the error if not available. The main reason we used the channel here is, the checkUrl method will be called in a different goroutines when will implement the service.
In a nutshell, the checkUrl method checks a url, for example https://twitter.com/stevensunflash, if the url does not exist, cant_access_resource is sent to the channel. If the url exists but the username stevensunflash is not found, no_match is sent to the channel, if the desired username is found, we send the url to the channel.

Now let's test the implementation.
Create the provider_test.go file:

touch provider_test.go

Observe closely that we mocked the client's GetValue method here, this is one of the uses of defining that method in an interface from the client package. You could see how we returned the response we want from the client without hitting a real endpoint. This has also helped us achieve unit testing on the provider without calling the real GetValue method from the client package. How Sweet!😴

Step 4: Service Implementation(Launching Some Goroutines🚀)

Now let's fire up some goroutines to get multiple urls responses at the same time.
From the server package(directory), create the service package(directory), then the service.go file:

mkdir service

cd service && touch service.go

The UsernameCheck method receive a slice of urls to process, we already have the checkUrl method we can use to check a url, defined in the provider's package. Now, we loop through the given urls and launch a goroutine for each url. Remember, any response or error obtained is sent to the channel. We then get the value for each url from the channel and put it inside the links slice.
The result set can have three cases:

cant_access_resource
no_match
valid result(url) We further filtered the links slice to get only valid urls.

Now, let's write some tests to prove that our code is working.
Create the service_test.go file:

touch service_test.go

Observe from the test that we also mocked the client so that we don't hit the actual endpoint.

Step 5: Controller Implementation(Returning the response to the caller)

Now, let's send back an HTTP response to the caller.
From the server package(directory), create the controller package(directory) and then the controller.go file

mkdir controller

cd controller && controller.go

Nothing fancy, the controller receives the request from the caller pass it down to the service(which concurrently uses the provider's checkUrls method), the service passes back to the controller the urls it could process, then the controller sends the urls to the caller.

Let's also test the controller, create the controller_test.go file

touch controller_test.go

As seen above to achieve unit test, we must mock the service's UsernameCheck method, and return anything we like. We could mock the service easily with the help of the usernameService interface.

Another thing to observe from the tests is, the json passed from the caller is of this format:

`["url1","url2","url3"]`

Anything outside a format like this won't work. We have the tests above to prove that.

Step 6: Wiring up the application

Though we have unit tests to prove that our application is working, lets still test it on the browser.
From the server package(directory), create the app package(directory),

mkdir app

then create two files:
-app.go
-route.go

a. app.go

cd app && touch app.go

Since we will later deploy this to heroku, we checked for the Heroku port.

b. route.go

touch route.go

Observe from the route that we called a middleware we have not defined yet. This middleware will enable us to make API calls between the server and the client(frontend), which we will define shortly.

The Middleware

From the server package, create the middleware package(directory), then the cors.go file:

mkdir middleware && touch cors.go

Running the app

We now need to create the main.go file in the server directory:

touch main.go

We called the StartApp function we defined in the app package.

Run the application, from the path: username_across_platforms/server

go run main.go

So, run the application and use Postman to test, or simply skip to the next step, where will use a vuejs as our frontend.
Remember, if you want to use Postman or your favorite testing tool,
pass the JSON like this:

Step 7: The Client(Frontend)
All we have done thus far is server stuff. Let's now see a beautiful representation of our hard work💪.
We will be using vuejs, you can also use reactjs if you wish. After all, this is just a SPA(Single Page App)

The first thing to do is install the https://cli.vuejs.org/, if you have installed that before.

From the root directory of the project(path: "username_across_platforms/"), create a new Vue project called client.

vue create client

It will prompt you for some stuff, choose all default.
When completed, enter the client(frontend) directory:

cd client

💥Very Important💥
The application just installed already have git initialized, remove the .git file. From the terminal, in the path: username_across_platforms/client, execute:

rm -rf .git

Next step, install vuetify we will use for the UI

vue add vuetify

Since we will be making an api call, lets install axios

yarn add axios --save

Great!

Next, locate the App.vue file inside the src directory and replace the content with:

Observe above that we imported a file we have not defined(env.js). To enable us to test both on local and production, we need to inform our application at any point in time the url to use.
In the same directory path as App.vue, create the env.js file:

Now, let's start the Frontend app:
From the path: username_across_platforms/client
Run:

npm run serve

Now fire up your browser and visit: http://localhost:8080

Aww😍. You're welcome!

Step 8: Hosting

We will deploy this awesome app to heroku for free. We can achieve easily using Docker.
From the project root (path: username_across_platforms/), create the Dockerfile

Since heroku is used for deployment, create the heroku.yml file, this file tells Heroku that we are dockerizing the app:
From the root directory:

touch heroku.yml

If you have following along, push your code to github, remember to initialize git from the root directory(path: username_across_platforms/).

Pushing to Heroku.

From the root directory

Install the heroku-cli
Login to heroku:

heroku login

Create the heroku application:

heroku create

Tell heroku that we are deploying a container to this stack:

heroku stack:set container

Push to heroku:

git add .

git commit -m "Heroku deployment"

git push heroku master

Now visit the application when deployment is done using:

heroku open

Behold the application🔥

Bonus

I added integration tests for the server implementation
I also used Travis CI for Continuous Integration

Get all these from the repository:
https://github.com/victorsteven/Username-Across-Platforms

Conclusion

So there you have it! A full-fledged application that uses Golang awesome concurrency feature.
You can also visit other articles here or in my medium account.
Don't forget to follow for future articles.

Get the complete code on Github

Happy Coding.

Forum App with Golang/Gin and React/Hooks

Steven Victor — Fri, 01 Nov 2019 10:22:24 +0000

Have you been looking forward to a production application built with Golang and React? This is one.

This application has an API Backend and a Frontend that consumes the API.
The application has two repositories:

https://github.com/victorsteven/Forum-App-Go-Backend (Backend)
https://github.com/victorsteven/Forum-App-React-Frontend (Frontend)

This is live version of the App. You can interact with it.

https://seamflow.com

Technologies

Backend Technologies:

Golang
Gin Framework
GORM
PostgreSQL/MySQL

Frontend Technologies:

React
React Hooks
Redux

Devops Technologies

Linux
Nginx
Docker

While the above may seem overwhelming, you will see how they all work in sync.

You might also like to check out my other articles about go, docker, kubernetes here

SECTION 1: Buiding the Backend

This is backend session wired up with Golang

Here, I will give a step by step approach to what was done.

Step 1: Basic Setup

a. The base directory
Create the forum directory on any path of your choice in your computer and switch to that directory:

        ```mkdir forum && cd forum```

b. Go Modules
Initialize go module. This takes care of our dependency management. In the root directory run:

go mod init github.com/victorsteven/forum

As seen, I used github url, my username, and the app root directory name. You can use any convention you want.

c. Basic Installations

We will be using third party packages in this application. If you have never installed them before, you can run the following commands:

go get github.com/badoux/checkmail
go get github.com/jinzhu/gorm
go get golang.org/x/crypto/bcrypt
go get github.com/dgrijalva/jwt-go
go get github.com/jinzhu/gorm/dialects/postgres
go get github.com/joho/godotenv
go get gopkg.in/go-playground/assert.v1
go get github.com/gin-contrib/cors 
go get github.com/gin-gonic/contrib
go get github.com/gin-gonic/gin
go get github.com/aws/aws-sdk-go 
go get github.com/sendgrid/sendgrid-go
go get github.com/stretchr/testify
go get github.com/twinj/uuid
github.com/matcornic/hermes/v2

d. .env file
Create and set up a .env file in the root directory.

touch .env

The .env file contains the database configuration details and other details that you want to key secret. You can use the .env.example file(from the repo) as a guide.

This is a sample .env file:

e. api and tests directories
Create an api and tests directories in the root directory.

mkdir api && mkdir tests

Thus far, our folder structure looks like this:

forum
├── api
├── tests
├── .env
└── go.mod

Step 2: Wiring up the Models

We will be needing about five models in this forum app:
a. User
b. Post
c. Like
d. Comment
e. ResetPassword

a. User Model
Inside the API directory, create the models directory:

cd api && mkdir models

Inside the models directory, create the User.go file:

cd models && touch User.go

A user can:
i. Signup
ii. Login
iii. Update his details
iv. Shutdown his account

b. Post Model
A post can be:
i. Created
ii. Updated
iii. Deleted
In the models directory, create a Post.go file:

touch Post.go

c. Like Model
Posts can be liked or unliked.
A like can be:
i. Created
ii. Deleted
Create the Like.go file:

touch Like.go

d. Comment Model
A post can have comments.
Comment can be:
i. Created
ii. Updated
iii. Deleted
Create the Comment.go file

touch Comment.go

e. ResetPassword Model
A user might forget his/her password. When this happens, they can request to change to a new one. A notification will be sent to their email address with instructions to create a new password.
In the models directory, create the ResetPassword.go file:

touch ResetPassword.go

Step 3: Security

a. Password Security
Observe in the User.go file, that before a password is saved in our database, it must first be hashed. We called a function to help us do that. Let's wire it up.
In the api directory(the path: /forum-backend/api/), create the security directory:

mkdir security

Inside the security directory, create the password.go file:

cd security && touch password.go

b. Token Creation for ResetPassword
This is the scenario: when a user requests to change his password, a token is sent to that user's email. A function is written to hash the token. This function will be used when we wire up the ResetPassword controller file.
Inside the security directory, create the tokenhash.go file:

touch tokenhash.go

Step 4: Seeder

I think is a good idea to have data to experiment with. We will be seeding the users and posts table when we eventually wire the database.
In the api directory (in the path: /forum/api/), create a seed directory:

mkdir seed

Inside the seed directory, create the seeder file seeder.go

touch seeder.go

Step 5: Using JWT for Authentication

This app will require authentication for several things such as creating a post, liking a post, updating a profile, commenting on a post, and so on. We need to put in place an authentication system.
Inside the api directory, create the auth directory:

mkdir auth

Inside the auth directory, create the token.go file:

cd auth && touch token.go

Step 6: Protect App with Middlewares

We created authentication in step 5. Middlewares are like the Police. They will ensure that the auth rules are not broken.
The CORS middleware will allow us to interact with the React Client that we will be wiring up in section 2.

In the api directory, create the middlewares directory

mkdir middlewares

Then create the middlewares.go file inside the middlewares directory.

cd middlewares && touch middlewares.go

Step 7: Utilities

a. Error Formatting
We will like to handle errors nicely when they occur.
The ORM(Object-Relational Mapping) that is used in the app is GORM. There are some error messages that are not displayed nicely, especially those that occurred when the database is hit.
For instance, when a user inputs someone else email that is already in our database, in an attempt to sign up, we need to prevent such action and politely tell the user that he can't use that email.

In the api directory, create a the utils directory

mkdir utils

Inside the utils directory, create a formaterror directory:

cd utils && mkdir formaterror

Then create the formaterror.go file:

cd formaterror && touch formaterror.go

b. File Formatting
A user will need to update his profile(including adding an image) when he does, we will need to make sure that we image added has a unique name.

In the utils directory(path: /forum-backend/api/utils), create the fileformat directory.

mkdir fileformat

Then create the fileformat.go file inside the fileformat directory:

cd fileformat && touch fileformat.go

Step 8: Emails

Remember when we were wiring up the models, we had the ResetPassword model. Well, when a user wishes to change his password, an email is sent to him with instructions to do so. Let set up that email file.
The emails are handled using Sendgrid service.

In the api directory, create a mailer directory

mkdir mailer

Inside the mailer directory create the forgot_password_mail.go file.

cd mailer && touch forgot_password_mail.go

Step 9: Wiring Up Controllers and Routes

I perceive you might be have been thinking how all these things connect right? Well, perish the thought, because we are finally there.
This step was purposely skipped until now because it calls most of the functions and methods we defined above.

In the api directory(path: /forum-backend/api/), create the controllers directory.

mkdir controllers

You might need to pay close attention to this directory.

a. The base file
This file will have our database connection information, call our routes, and start our server:
Inside the controllers directory, create the base.go file:

cd controllers && touch base.go

b. Users Controller
Inside the controllers directory, create the users_controller.go file

touch users_controller.go

From the above file, you can observe that we sent a photo upload to either DigitalOceanSpaces or AWS S3 Bucket
If you wish to practice along, You will need to create an Amazon S3 bucket or DigitalOcean Spaces object to store the images.
Also, update your .env file:

DO_SPACES_KEY=your_do_key
DO_SPACES_SECRET=your_do_secret
DO_SPACES_TOKEN=your_do_token
DO_SPACES_ENDPOINT=your_do_endpoint
DO_SPACES_REGION=your_do_region
DO_SPACES_URL=your_do_url

# OR USING S3:

AWS_KEY=your_aws_key
AWS_SECRET=your_aws_secret
AWS_TOKEN=

c. Posts Controller
Inside the controllers directory, create the posts_controller.go file:

touch posts_controller.go

c. Login Controller
Request that update a user, create a post, delete a post, and so on, need authentication.

Inside the controllers directory, create the login_controller.go file:

touch login_controller.go

c. Likes Controller
An authenticated user can like a post or unliked already liked post.
Inside the controllers directory, create likes_controller.go file

touch likes_controller.go

d. Comments Controller
The authenticated user can create/update/delete a comment for a particular post.

touch comments_controller.go

e. ResetPassword Controller
A user can request to reset their password peradventure the password is forgotten:

touch resetpassword_controller.go

f. Routes
All controller methods are used here.
Still, in the controllers directory, create the routes.go file:

touch routes.go

Step 10: Create the Server File

In the server.go file, we open a connection to the database, provide a port the app listens to from the .env file.
Inside the api directory(in the path: forum-backend/api/) create the server.go file

touch server.go

Step 11: Run the App

Let's now see some output from our labor thus far.
Create the main.go file in the root directory of the app, and call the Run method defined in server.go file above.
In the path /forum-backend/,

touch main.go

Confirm that your directory structure looks like this:

Running Without Docker

If you just want to run this API without docker, make sure you have this in your .env file:

DB_HOST=127.0.0.1

Also that your database is created, the username, password, and every other thing are in place.

Open the Terminal, in the root directory, run:

go run main.go

Your terminal output should look like this:

Running With Docker

a. Edit your .env file like this:

DB_HOST=forum-postgres

b. Create the Dockerfile for development:
In the project root (path: /forum-backend/), create the Dockerfile

touch Dockerfile

You can rename the example-Dockerfile.dev(from the repo) to Dockerfile

c. Create the docker-compose.yml file for development
In the project root (path: /forum/), create the docker-compose.yml

touch docker-compose.yml

You can also rename the example-docker-compose.dev.yml to docker-compose.yml

d. Run the app:
Open the terminal and run:

docker-compose up --build

e. You can use pgadmin to view your database.
Look up this article I wrote for a guide here

Step 13: Writing Unit and Integration Tests

The API is 99.9% tested.

Golang has a beautiful term called Table Testing.
That term might not sound familiar if you are coming from the NodeJS/PHP/Python/Ruby world.
Table testing in Go, give the Developer the privilege of testing all edge cases of a particular functionality just with one test function.
This is what I mean, Imagine a user signing up. What could possibly go wrong?

The user might input an invalid email
The user might input a password that does not meet the requirement
The user might input an email that belongs to someone else in our database.
- and so on.

With the power of Table Tests, you can test all the cases with one test function, instead of writing multiple functions with more lines of code to worry about.

Tests Set up

Remember, we created a tests directory at the start of the project.
Inside the tests directory, create the setup_test.go

touch setup_test.go

Since you will be running this tests in your local, let your TestMain and Database functions look like this:

func TestMain(m *testing.M) {
    var err error
    err = godotenv.Load(os.ExpandEnv("./../.env"))
    if err != nil {
        log.Fatalf("Error getting env %v\n", err)
    }

    Database()

    os.Exit(m.Run())

}

func Database() {

    var err error

    TestDbDriver := os.Getenv("TEST_DB_DRIVER")
    if TestDbDriver == "mysql" {
        DBURL := fmt.Sprintf("%s:%s@tcp(%s:%s)/%s?charset=utf8&parseTime=True&loc=Local", os.Getenv("TEST_DB_USER"), os.Getenv("TEST_DB_PASSWORD"), os.Getenv("TEST_DB_HOST"), os.Getenv("TEST_DB_PORT"), os.Getenv("TEST_DB_NAME"))
        server.DB, err = gorm.Open(TestDbDriver, DBURL)
        if err != nil {
            fmt.Printf("Cannot connect to %s database\n", TestDbDriver)
            log.Fatal("This is the error:", err)
        } else {
            fmt.Printf("We are connected to the %s database\n", TestDbDriver)
        }
    }
    if TestDbDriver == "postgres" {
        DBURL := fmt.Sprintf("host=%s port=%s user=%s dbname=%s sslmode=disable password=%s", os.Getenv("TEST_DB_HOST"), os.Getenv("TEST_DB_PORT"), os.Getenv("TEST_DB_USER"), os.Getenv("TEST_DB_NAME"), os.Getenv("TEST_DB_PASSWORD"))
        server.DB, err = gorm.Open(TestDbDriver, DBURL)
        if err != nil {
            fmt.Printf("Cannot connect to %s database\n", TestDbDriver)
            log.Fatal("This is the error:", err)
        } else {
            fmt.Printf("We are connected to the %s database\n", TestDbDriver)
        }
    }
}

...

I had to modify the repository because Circle CI could not detect the .env file that has the test database details. Please take note of this. The rest of the functions in the setup_test.go remain unchanged.

The setup_test.go file has functionalities that:

Initializes our testing database
Refresh the database before each test
Seed the database with relevant data before each test. This file is very handy because it will be used throughout the tests. Do well to study it.

Model Tests.

a. User Model Tests
In the tests directory, create the model_users_test.go file

touch model_users_test.go

After ensuring that your test database is created, the right user and password set and all files saved, You can go ahead and run this test. Launch your terminal in the path: /forum-backend/tests and run:

go test -v

The v flag is for verbose output.
To run individual tests in the model_users_test.go file, Say for instance I want to run the TestSaveUser, run:

go test -v --run TestSaveUser

b. Post Model Tests
In the tests directory, create the model_posts_test.go file

touch model_posts_test.go

c. Like Model Tests
In the tests directory, create the model_likes_test.go file

touch model_likes_test.go

d. Comment Model Tests
In the tests directory, create the model_comments_test.go file

touch model_comments_test.go

Controller Tests.

a. Login Controller Test
Observe in the login_controller.go file that, the Login method depends on the SignIn method.
In the tests directory, create the controller_login_test.go file.

touch controller_login_test.go

b. Users Controller Test
Each method in the users' controller call at least one method from somewhere else. The methods that each Users Controller Method called are tested in the Unit Tests session.

In the tests directory, create the controller_users_test.go file.

touch controller_users_test.go

c. Posts Controller Test
In the tests directory, create the controller_posts_test.go file.

touch controller_posts_test.go

d. Likes Controller Test
In the tests directory, create the controller_likes_test.go file.

touch controller_likes_test.go

e. Comments Controller Test
In the tests directory, create the controller_comments_test.go file.

touch controller_comments_test.go

f. ResetPassword Controller Test
In the tests directory, create the controller_reset_password_test.go file.

touch controller_reset_password_test.go

As mentioned earlier, You can run any test in the tests directory. No test function depends on another to pass. All test functions run independently.

To run the entire test suite use:

go test -v

You can also run tests from the main directory of the app that is, outside the tests directory(path: /forum-backend/) using:

go test -v ./...

Running Tests with Docker

If you wish to run the tests with docker, do the following:

a. Dockerfile.test file
In the root directory, create a Dockerfile.test

touch Dockerfile.test

You can rename the example.Dockerfile.test(from the repo) to Dockerfile.test

b. docker-compose.test.yml file
In the root directory, create a docker-compose.test.yml

touch docker-compose.test.yml

You can rename the example.docker-compose.test.yml(from the repo) to docker-compose.test.yml

c. Run the tests suite:
Ensure that the test database details are provided in the .env file and the Test_Host_DB is set as such:

TEST_DB_HOST=forum-postgres-test

From the project root directory, run:

docker-compose -f docker-compose.test.yml up --build

Step 14: Continuous Integration Tools

Circle CI is used as the CI tool in this API. Another option you might consider is Travis CI.

Steps to Integrate CircleCI:
a. config.yml
In the root directory(path: /forum-backend/), create the .circleci

mkdir .circleci

Create the config.yml file inside the .circleci directory

cd .circleci && touch config.yml

b. Connect the repository
Since you have following this tutorial on your local, you can now create a github/bitbucket repository and push the code.

Login to Circle CI and choose the repo to build.
Click on start building.
After the build process, you will be notified if it succeeds or fails. For failure, check the logs in the CI environment to know why.
Go to the settings, copy the badge and add it to the README.md of your repo
For a successful build, your badge should look like mine:

Step 15: Deployment

I deployed a dockerized version of the app to digitalocean. The job can also be done with Amazon AWS.
This deployment process is worth a full-blown article. If you be interested in the step by step process, do well to comment, I will spin up a different article for that.

Get the Repository for the backend here

Section 2: Buiding the Frontend

You might have been waiting for the session.
This is a where you will appreciate the backend work done in Section 1

We will be using React. I would have as well decided to use Vue(which is also cool).
This frontend has zero class definition. React Hooks are used 100%.
Redux is used for state management.

The repository for the frontend is this:
https://github.com/victorsteven/Forum-App-React-Frontend

Step 1: Basic Step Up

a. Installation

To follow along from scratch, create a new React Project. Note that this project should be created outside the backend. You can create it in your Desktop, Documents, or your dedicated frontend directory.

npx create-react-app forum-frontend

Follow the instructions in the terminal after the project is created.

Change to the forum-frontend directory:

cd forum-frontend

And start the app:

npm start

Visit on the browser:

  http://localhost:3000

Please note that I will be as concise as possible.

b. Install External Packages.
We installed packages like axios, moment, and so on.
To be brief, use the content in the project package.json file:

Then run:

npm update

c. API Url
The Backend is totally standalone from the Frontend
So a means of communication is needed.
Inside the src directory, create the apiRoute.js file:

cd src && touch apiRoute.js

Not, from the above file, the production URL for the forum app is used, you can as well change it to yours if you have hosted a backend somewhere.

d. Authorization
Authenticated will be needed for some requests in the app.
Take, for instance, a user needs to be authenticated to create a post.
Since axios is used for api calls(sending requests to the backend), we need to send the authenticated user's authorization token to each request they make. Instead of adding the authorization token manually, let's do it automatically.
Inside the src directory, create the authorization directory:

mkdir authorization

Create the authorization.js file inside the authorization directory

cd authorization && touch authorization.js

e. History
We may need to call redirection from our redux action.
This is what I mean: When a user creates a post, redirect him to the list of posts available.
To achieve this, we will use the createBrowserHistory function from the history package.

Inside the src directory, create the history.js file:

touch history.js

f. Assets
For each newly registered user, a default avatar is used as their display image.
Inside the src directory, create the assets directory:

mkdir assets

Add the avatar below in the assets directory. You can rename it to Default.png

Step 2: Wiring up our Store

As said earlier, we will be using redux for state management. And I think it is best the store is fired up before we start calling components that we will create later.
Inside the src directory, create the store directory:

cd src && mkdir store

Inside the store directory, create the modules directory:

cd store && mkdir modules

a. The Authentication Store

Inside the modules directory, create the auth directory:

cd modules && mkdir auth

Inside the auth directory, create these directories and files as shown in the image below:

i. auth/actions/authActions.js

ii. auth/authTypes/index.js

iii. auth/reducer/authReducer.js

b. The Posts Store

Inside the modules directory, create the posts directory:

mkdir posts

Inside the posts directory, create these directories and files as shown in the image below:

i. posts/actions/postsActions.js

ii. posts/postsTypes/index.js

iii. posts/reducer/postsReducer.js

c. The Likes Store

Inside the modules directory, create the likes directory:

mkdir likes

Inside the likes directory, create these directories and files as shown in the image below:

i. likes/actions/likesActions.js

ii. likes/likeTypes/index.js

iii. likes/reducer/likesReducer.js

d. The comments Store

Inside the modules directory, create the comments directory:

mkdir comments

Inside the comments directory, create these directories and files as shown in the image below:

i. comments/actions/commentsActions.js

ii. comments/commentTypes/index.js

iii. comments/reducer/commentsReducer.js

e. The Combined Reducer

We will need to combine the reducers from each of the stores defined above.
Inside the modules directory(path: /src/store/modules/), create the index.js file.

touch index.js

f. The Store File

This is the file that a kind of wraps up the store.

The combined reducer is called
We applied the thunk middleware
Enabled Redux DevTools

In the store directory(path: /src/store/), create the index.js file.

touch index.js

Step 3: Wiring Up The Components

Inside the src directory, create the components directory

cd src && mkdir components

Navigation Component

This component takes us wherever we want in the app.

a. Navigation
Inside the components directory, create the Navigation component

cd components && touch Navigation.js

b. Navigation.css
Inside the components directory, create the Navigation.css file

Utils Component

Inside the components directory, create the utils directory

mkdir utils

a. Message: This is the notification component.
Create a Message.js file inside the utils directory:

cd utils && touch Message.js

Auth Component

This is the component that will house our authentication.
Inside the components directory, create the auth directory

mkdir auth

a. Signup: A user can register on the app.
Create a Register.js file inside the auth directory:

cd auth && touch Register.js

b. Login: A user can log in.
Create a Login.js file inside the auth directory:

touch Login.js

c. Auth.css Add styling to auth files.
Create a Auth.css file inside the auth directory:

touch Auth.css

Users Component

The user can update his profile picture, change his email address, request to change his password, and so on.
Inside the components directory, create the users directory

mkdir users

a. Profile: A user can update his profile.
Inside the users directory, create the Profile.js component:

cd users && touch Profile.js

b. Profile.css. Add the profile css file.
Inside the users directory, create the Profile.css file:

touch Profile.css

c. ForgotPassword: A user can request to change their forgotten password.
Inside the users directory, create the ForgotPassword.js component:

touch ForgotPassword.js

d. ResetPassword: A user can reset their password.
Inside the users directory, create the ResetPassword.js component:

touch ResetPassword.js

Posts Component

An authenticated user can create/edit/delete posts they created.
Inside the components directory, create the posts directory

mkdir posts

a. Posts: A user can view all posts.
Inside the posts directory, create the Posts.js component:

cd posts && touch Posts.js

b. Post: This a single component inside the Posts component
Inside the posts directory, create the Post.js component:

touch Post.js

c. PostDetails: A user can visit a particular post.
Inside the posts directory, create the PostDetails.js component:

touch PostDetails.js

d. CreatePost: An authenticated user can create a post.
Inside the posts directory, create the CreatePost.js component:

touch CreatePost.js

e. EditPost: An authenticated user can edit their post.
Inside the posts directory, create the EditPost.js component:

touch EditPost.js

f. DeletePost: An authenticated user can delete the post they created.
Inside the posts directory, create the DeletePost.js component:

touch DeletePost.js

g. AuthPosts: An authenticated user view all the posts they created.
Inside the posts directory, create the AuthPosts.js component:

touch AuthPosts.js

h. AuthPost: This is a single component inside the AuthPosts component.
Inside the posts directory, create the AuthPost.js component:

touch AuthPost.js

i. Posts.css: This is CSS file for the above components.

Likes Component

Inside the components directory, create the likes directory

mkdir likes

a. Likes: An authenticated user can like a post or unlike already liked post.
Inside the likes directory, create the Likes.js component:

cd likes && touch Likes.js

Comments Component

An authenticated user can create/edit/delete comments they created.
Inside the components directory, create the comments directory

mkdir comments

a. Comments: A user can view all comments for a post.
Inside the comments directory, create the Comments.js component:

cd comments && touch Comments.js

b. Comment: This a single component inside the Comments component.
Inside the comments directory, create the Comment.js component:

touch Comment.js

c. CreateComment: An authenticated user can create a comment.
Inside the comments directory, create the CreateComment.js component:

touch CreateComment.js

d. EditComment: An authenticated user can edit their comment.
Inside the comments directory, create the EditComment.js component:

touch EditComment.js

e. DeleteComment: An authenticated user can delete their comment.
Inside the comments directory, create the DeleteComment.js component:

touch DeleteComment.js

Dashboard Component

This is the entry component of the application.
Inside the components directory, create the Dashboard.js component

touch Dashboard

Step 4: Wiring Up The Route

If routing is not in place, we cannot navigate to the different components we have.
In the src directory, create the Route.js file

touch Route.js

Step 4: Wiring Up The App Main Entry

All that is done above, from the store* to the routing need to connect at some point.
This is done in the index.js file in the src directory.

Edit the index.js file in the src directory

Also, edit the index.css file in the src directory. This file has just once CSS class color-red. This is used in all components that error is displayed

Fire up your terminal and run http://localhost:3000

Welcome to the App.

Step 4: Deployment

The frontend is deployed using Netlify
before you deploy, in the public directory(path: forum-frontend/public), create the _redirects file

touch _redirects

File content:

/*    /index.html   200

Steps to deploy:

Create a new github repo(different from the backend)
Push the frontend code to the repo
Login to your Netlify account and connect the frontend repo.
Give it sometime to deploy.

Note the following:

For the backend to work with the deployed frontend, it needs to be deployed also to a live server(digitalocean, aws, heroku, etc).
Make sure that url for the backend is not just the ip address. you can get a domain name and make sure https is enabled
You can update the apiRoute file and add your backend url

Conclusion

I tried as concise as possible to avoid a 2 hours or so read.

This is the visit the production application
https://seamflow.com
You can visit and try all that you learned in this article.

Also, get the github repositories

https://github.com/victorsteven/Forum-App-Go-Backend (Backend)
https://github.com/victorsteven/Forum-App-React-Frontend (Frontend)

Don't forget to drop a star.

You can ask me personal questions on questions on twitter

You might also like to check out my other articles about go, docker, kubernetes here

Thanks.