DEV Community: Asaju Enitan

I want a divorce

Asaju Enitan — Thu, 28 Sep 2023 07:04:37 +0000

that's it... I want a divorce.

Configuring Github on your Dev Environment Part One

Asaju Enitan — Wed, 01 Sep 2021 09:58:26 +0000

Configuring Github on your Dev Environment Part One

$ means running the command as a normal user but make sure to remove it from your command as it already exists on your terminal

Setup

The first step in setting up git on your dev environment is installing the git to your environment. Although you can use Git with the web version with https://github.com, most of the time you will be interacting with Github from within your dev environment using either Terminal and/or applications.
First go to https://git-scm.com/ and install for your OS.
For Windows user, using the installer will also install the git bash application which you can use to run git commands.

Linux users will have to download for their distribution https://git-scm.com/download/linux

While MacOS users can use Homebrew to install by running brew install git. Make sure to install Homebrew if you don't have it already.

If you like living on the edge, you can build from source with the tarballs from kernel.org.

Basic Configuration

After going through the installation process for your OS, you will need to make configurations. But before that, you should make sure that git installed successfully on your environment. For Windows users, during installation, you will be asked if you want to install to path, if you didn't check the box, you will need to add it to your environment variables.

Git comes with a tool called git config that lets add and read configuration variables that control how you use Git. These variables can be saved in three different places;

/etc/gitconfig file: The variables saved in this location applies to every user on your system and all the repositories. To save configuration variables to this file you must pass --system flag to the git config command. You will need administrative or superuser privilege to use this command because it writes to a system file.
$HOME/.gitconfig or $HOME/.config/git/config file: The configuration variables saved to this file apply only to a single user, You. You can save configuration variables to this file by passing --global flag to the git config command. The variables in this file affects only the repositories that you manage.
config file in the Git directory i.e .git/ in your project directory. To know if you have this directory in your project folder, you can run ls -al which displays all the hidden files/folders in your project, you can also access see this by checking Show hidden files in your OS's file explorer. Now that you know where to store files. Let's add some configuration variables. You will be going with the second option because you will want to apply to yourself and all the repositories you own.

Setting Your Identity

The first thing you should do when you install Git is to set your user name and email address. Git uses this to bind every commit towards you. This is important so that you will be able to keep track of every commit you make.
Open your preferred terminal and type the following;
$ git config --global user.name "John Happer" This command sets the user name. Replace the John Happer with your full name.

$ git config --global user.email "johnhapper@example.com" This commands sets the email address. Make sure you replace johnhapper@example.com with the email you registered your github account with. Using the --global flag makes sure to set these variables to only you but affects all the repositories.

Editor

You have set up your identity, you can configure the default text editor that will be used when you need to type messages or make amends to commits. It is not a must though as Git will make use of your system's default editor.

But if you want to use a different editor, for example VSCode, you can run the command like this
$ git config --global core.editor code. This will use the VSCode executable code. For windows users, you will need to specify the full path to the editor you want to use. For example, if you want to use VSCode on windows, you will need to type something like this;

$ git config --global core.editor "C:/Program Files/Visual Studio Code/code.exe"

Make sure you get the correct path as this can cause issues when Git attempts to open the executable.

Default Branch

By default, when you run git init to initialize a new repository for your project, Git will create a branch called master. But you can set a different name for the initial branch. For example to set main as the default branch name, type
$ git config --global init.defaultBranch main and it will set main as your default initial branch every time you run git init.

Phew!, you have done a lot. To check the current variables you have set, you can use the git config --list to show the list of everything Git has set. This command reads from all the Git config files.

$ git config --list
user.name=John Happer
user.email=johnhapper@example.com
core.editor=vim
color.status=auto
color.branch=auto
...

... The rest of the variables have been truncated.
At any point if you forgot a command, you can run $ git help <verb> to get a comprehensive manual for that command. For example you can get the documentation for git commit by running $ git help config. For short and concise help options, you can use the $ git <verb> -h for example $ git add -h to get help for the github add command.

usage: git add [<options>] [--] <pathspec>...

    -n, --dry-run         dry run
    -v, --verbose         be verbose

    -i, --interactive     interactive picking
    -p, --patch           select hunks interactively
    -e, --edit            edit current diff and apply
    -f, --force           allow adding otherwise ignored files
    -u, --update          update tracked files
    --renormalize         renormalize EOL of tracked files (implies -u)
    -N, --intent-to-add   record only the fact that the path will be added later
    -A, --all             add changes from all tracked and untracked files
    --ignore-removal      ignore paths removed in the working tree (same as --no-all)
    --refresh             don't add, only refresh the index
    --ignore-errors       just skip files which cannot be added because of errors
    --ignore-missing      check if - even missing - files are ignored in dry run
    --chmod (+|-)x        override the executable bit of the listed files
    --pathspec-from-file <file>
                          read pathspec from file
    --pathspec-file-nul   with --pathspec-from-file, pathspec elements are separated with NUL character

And that's all about basic setup for your github. Next up, we will look at setting up your git commit messages.

Adding Files

You have made changes to your code, and now you need to push to the remote repository. To do that, you will use the git add command. You can add files in several ways. Running git add . will add all modified and new files and stage them for commit and push. But you can also specify which file you want to add by running git add path/to/file/in/the/repositiry i.e git add app/controllers/user.js will add only the user.js file and stage it.

Removing Files

You can also remove files i.e unstage them from commits by running git rm path/to/file/in/the/repository. The git rm . also unstages all files and folders. Not to be confused with git stash, this command clears the current commit and reverts to the last push commit in the log which can be accessed using the git log command.

Commit Messages

Commit messages are a way to keep note tracks of your project updates. It is very important because it helps when you revisit the codebase or share the repository with someone else. It is very important to make sure your commit messages as descriptive as possible. Avoid short messages such as updated app.js, the change here is now working, these kind of messages leave little space for understanding your code and can waste productive time.

That being said, how should you write a good commit message. A good commit message needs to follow a good idea of what the update is about, a summary or it and full text explaining to an extent what the update to the commit is.

An example of this is <scope> <summary> <full text>.

Scope

Where <scope> is the feature/function of the commit, i.e is it a feature, a test, a breaking change or a fix.
A way you can do this is using keywords, these keywords has to be descriptive enough, listed below are some examples;

feat
fix
breaking changes
new
improve
refactor, etc...

Summary

Where <summary> shows the TL;DR version of the commit. For example, what function was refactored or what issue was resolved. It is advisable to keep this at 20 words max as you will still give a detailed explanation in the <full text>. Example might be, Added validator to the create user endpoint.

Full Text

The <full text contains the full detailed explanation of the explanation, will it affect any other commit?, is there a command that must be run for it work?. You can type as much as you want here since it will help you or anyone checking the code to grasp a full explanation of the commit.

So a full commit message will be something like $ git commit -m "UPDATE(Added validator to the create user endpoint): To avoid a security issue, user registration now requires the email to be of the email format, username must be more than 3 characters and password must be at least 8 characters. This is going to affect the registration endpoint which might generate error."

Alias

That being said, typing all these for every commit can be sometimes very tiring 😫. That being said, Git has a tool to exactly help with that and that is the git config --global alias🙂. With this command, you can set at much as aliases as you want. Let\'s set an alias to make an set a commit message for the initial commit.

git config --global alias.int '!f() { git commit -m "🎊 INITIAL COMMIT($1): $2; }; f' Running this command will add the alias command to your config file. Then when you run git int "Project Setup" "Setting up the base files, we will be using this technology etc..." it will translate to $ git commit -m "🎊 INITIAL COMMIT(Project Setup): Setting up the base files, we will be using this technology etc..." which looks cool and you get to type less.

You can add more of these alias and more with the git config --global alias.<keyword> command. I will share my config file so you can see how I did mine and edit according to your preference.

With this all set up, you are well on your way of becoming adept at using git. This is the first in the series and I will be updating as soon as I can.

Link to my config.

See you next time 😉❤️

Migrating existing REST API Server to Serverless with AWS Lambda, MongoDB and Serverless Framework

Asaju Enitan — Sat, 24 Jul 2021 23:57:54 +0000

With the increased interest in serverless backend development, companies, startups have began to look towards migrating their exiting projects from using a server to essentially a serverless server*.

Serverless has different meanings depending on the context. It could be a third party managed services like Firebase or an event driven service.

In this tutorial, you will learn how to migrate your existing project to a serverless approach using AWS Lambda, MongoDB, and Serverless Framework.

Table of Contents
- Application: A Movie App
- Prerequisites
- Terms
- Yosh! Show me dah Code!
- Step 1:
- Step 2:
- Step 4:
- Step 5:
- Step 6:
- Step 7:

Application: A Movie App

The movie app is a simple CRUD based application that stores, retrieves, updates and deletes movies from a MongoDB database. The application is written in Fastify but the process is the same for every other NodeJS Framework e.g, Express, Hapi, Koa.

Prerequisites

AWS Account
Node.js
Configured AWS CLI (for deployment)
Serverless CLI (we will be running it locally)

Terms

Serverless Framework: The Serverless Framework is a framework that allows you to build Serverless applications. It is provider-agnostic meaning it you can use it to build quite a number of serverless providers. Read more on their.

AWS Lambda: AWS Lambda is and event-driven serverless computing platform, meaning, it executes your code in response to event. It is the third compute service from Amazon. The others being EC2 (Elastic Compute Cloud) and ECS (Elastic Container Service).

Enough talk. Let's get into the code

Yosh! Show me dah Code!

Alright alright, even I am getting tired of talk. Let's code

This is might be a given, but be sure to clone your code and not edit the original one,

It may not affect but it's makes for freedom to edit to satisfaction

Step 1:

NOTE: As of this writing serverless is only supported up to node v15.4.0 details.

You can use your node version manager to install the specific node version. I use nvm

Install Serverless CLI

(Recommended to install system wide, makes for easy cli usage outside your current project)

$ npm install -g serverless

(if you are not interested in installing system wide)

$ cd your-project-directory
$ npm install --save serverless

This command will install serverless and makes available 2 commands serverless & sls. sls is an alias to serverless

Step 2:

Add Serverless to your current project

$ sls create --template aws-nodejs --name <custom-unique-name>

This will create three files

.
├── .npmignore
├── handler.js
└── serverless.yml

Explanation time (bear with me)

.npmignore: This file tells npm which files should be kept outside of the package
handler.js: Contains the boilerplate code.

'use strict';

module.exports.hello = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        message: 'Go Serverless v1.0! Your function executed successfully!',
        input: event,
      },
      null,
      2
    ),
  };

  // Use this code if you don't use the http event with the LAMBDA-PROXY integration
  // return { message: 'Go Serverless v1.0! Your function executed successfully!', event };
};

serverless.yml: The entry point file. Without it, Serverless won't run. It has three sections - provider, functions, resources, plugins, etc.

provider: This section declares configuration specific to a cloud provider. (in this case AWS). It can also be used to specify region, stage, runtime etc.

provider:
  name: aws
  runtime: nodejs12.x
  lambdaHashingVersion: 20201221
  stage: dev
  region: us-west-1
  ...

functions: This section is used to specify all the functions that are available for your service (the --name flag we specified when adding adding serverless)

functions:
hello:
  handler: handler.hello
  ...

resources: This section specifies all the resouces that your functions can use. They can be declared using AWS CloudFormation.

resources:
Resources:
  NewResource:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-new-bucket
Outputs:
   NewOutput:
     Description: "Description for the output"
     Value: "Some output value"

Step 4:

Update serverless.yml file
We will configure the serverless.yml file to reference your existing API endpoints and other configurations

I won't bore you with the details, you can update it as shown below. It should work for your application too

service: <autogenerated> # Service name (must be unique for your account, no two services can share the same name)

frameworkVersion: "2" # Recommended to pin it to a working version so updates won't break your application

provider:
  name: aws # Name of the cloud provider
  runtime: nodejs14.x # node runtime that the deploy will work on, this is different from the nodejs version required for sls to run
  lambdaHashingVersion: 20201221 # Recommended (honestly, no idea why. Lemme know in the comments what it means)
  memorySize: 130 # Memory size required for lambda functions to run
  timeout: 10 # 10s timeout for a request to be cancelled
  stage: {opt:stage, 'dev'} # Stage to run the functions, it is used for development process to specify which ENV to run
  region: eu-west-1 # Optional override, it will be automatically set from AWS

functions:
  api: # can be any name, this will be mapped to the functions on lambda. It has to be unique
    handler: handler.api # The file.exportedFunction that the functions will be use when the event is created
    events:
      - http: ANY / # RegExps all the HTTP Routes GET|POST|PUT|PATCH|DELETE|OPTIONS, etc.
      - http: ANY /{proxy+} # If your routes use queries and parameters

Oh look, I ended up adding the details. Make sure to remove the comments.

Step 5:

Install the aws-lambda-fastify

npm install aws-lambda-fastify

Open handler.js using your editor and update it as follows

const awsLambdaFastify = require('aws-lambda-fastify');
const app = require('./app');

const proxy = awsLambdaFastify(app);

exports.api = (event, context) => proxy(event, context);

Step 6:

Open app.js and update it

const fastify = require('fastify');
const cors = require('fastify-cors');

const mongoose = require('mongoose');
require('dotenv').config();

const controllers = require('./controllers');

const MONGO_URI = process.env.MONGO_URI || 'mongodb://localhost:27017/movie';
const PORT = process.env.PORT || 3000;

// Connect to the db
mongoose
  .connect(MONGO_URI, {
    useCreateIndex: true,
    useFindAndModify: false,
    useNewUrlParser: true,
    useUnifiedTopology: true,
  })
  .then((connection) => {
    console.log(`Database connected ::: ${connection.connection.host}`);
  })
  .catch((err) => {
    console.error(`Error ::: ${err.message}`);
    process.exit();
  });

// Initialize app
const app = fastify();

// CORS
app.register(cors, {
  origin: '*',
});

// Routes
app.get('/', controllers.getAll);
app.post('/create', controllers.create);
app.get('/:id', controllers.getOne);
app.put('/:id/update', controllers.updateOne);
app.delete('/:id/delete', controllers.deleteOne);

// Run as backend server if the file is called directly
if (require.main === module) {
  app.listen(PORT, (err) => {
    if (err) console.error(err);
    console.log(`server running on ${PORT}`);
  });
} else {
  // Execute as aws lambda function when required as a module
  module.exports = app;
}

As noticed here, there's not much change except

// Run as backend server if the file is called directly
if (require.main === module) {
  app.listen(PORT, (err) => {
    if (err) console.error(err);
    console.log(`server running on ${PORT}`);
  });
} else {
  // Execute as aws lambda function when required as a module
  module.exports = app;
}

Which runs the file as normal server if called directly node app.js and runs it as a function when imported from our handler.js file

Another change is in the controllers.js file
we will replace req,res with event since our requests are now events but it works the same. Fastify Power!

// const create = async (req,res) {
const create = async (event) => {
  try {
    const newMovie = await Movie.create(event.body); // Events are sent in JSON format
    return {
      statuCode: 201,
      body: JSON.stringify(
        {
          message: 'new movie created',
          newMovie,
        },
        null,
        2
      ),
    };
  } catch (err) {
    return {
      statuCode: err.code || 500,
      message: JSON.stringify(err),
    };
  }
};
...

Next is the way we return responses, we will have to stringify (JSON.stringify(data)) the responses (AWS Lambda Recommended) and structure it as above.

Phew! that was a stretch, I need a cup of coffee ....Alright, let's continue

Step 7:

Now we can deploy our app to AWS!

Hehe, not yet young padwan.

Testing our application locally (dev) is really important so we don't end up causing cataclysmic situation. That's where serverless-offline comes in

Explanation Time!: Serverless Offline is a Serverless plugin that emulates AWS and API Gateway on your local machine to speed up your development cycles. - Serverless

How do we integrate it to our application? Glad you asked. It takes two easy steps
Install the npm package as devDependecy

npm install --save-dev serverless-offline

Next we will plug-in 👓 it to our serverless.yml file

...
plugins:
  - serverless-offline

Yosh! let's now run it locally

sls offline start

running this command will show this output

When we visit Postman (or any REST Client you use) and perform the CRUD Operations

Create movie

Get all movies
Get one movie

Update one movie

Delete movie

Now that we are done testing our app locally, time to deploy it. Ah finally!

First we have to configure AWS CLI. Follow the steps here

Done? Good, let's continue.

run

sls deploy

to deploy your application

PS: I couldn't deploy mine, for some reason, I can't access my AWS account, story for later.

It will display the url to your application should the deploy succeed, test the endpoints and you should be good to go

And that's it. You have successfully migrated your existing app to AWS Lambda using Serverless Framework.

The link to the Repository

Was the guide straightforward enough to follow?, did you get lost somewhere?, let me know in the comments.

Follow me for more 'straightforward' tutorials such as this.

KodeRant](https://koderant.hashnode.dev/)

DEV Community: Asaju Enitan

I want a divorce

Configuring Github on your Dev Environment Part One

Configuring Github on your Dev Environment Part One

Setup

Basic Configuration

Setting Your Identity

Editor

Default Branch

Adding Files

Removing Files

Commit Messages

Scope

Summary

Full Text

Alias

Migrating existing REST API Server to Serverless with AWS Lambda, MongoDB and Serverless Framework

Table of Contents

Application: A Movie App

Prerequisites

Terms

Yosh! Show me dah Code!

Step 1:

Step 2:

Step 4:

Step 5:

Step 6:

Step 7: