DEV Community: Phillip Ninan

Provision an RDS Instance using the AWS CDK and Secrets

Phillip Ninan — Wed, 11 Aug 2021 03:50:01 +0000

TLDR: Checkout the complete code on GitHub Repo.

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

Introduction

Today, I am going to show you how to provision an RDS instance using the AWS CDK. We will set up an AWS Secret and System Parameter that can be used to allow other resources to connect without using plaintext credentials. Never keep database credentials in plaintext!

Table Of Contents

Introduction

Check Out a Starter Project

Update Dependencies

Add a Database Secret

Create a System Parameter

Load Default Security Group

Optionally Open Access From Your IP

Configure RDS Instance

Output RDS Endpoint

Deploy

Conclusion

Check Out a Starter Project

We are going to start from my last post, here is the GitHub Repo. We want to start with a base stack. A base stack is where you should keep your stateful resources. Since a database cannot be easily re-constructed you should consider this stateful. We will be updating the base stack by adding an RDS database.

Update Dependencies

First, we need to update the dependencies in package.json. We are going to need some new dependencies for this tutorial. Note, you should try to keep all the CDK dependency versions the same.

  "dependencies": {
    ...
    "@aws-cdk/aws-rds": "1.95.1",
    "@aws-cdk/aws-secretsmanager": "1.95.1",
    "@aws-cdk/aws-ssm": "1.95.1"
  }

Add a Database Secret

Next, we will start to update the base stack! First, we need to set up a secret and a system parameter. You should never keep plaintext credentials in plaintext or in source control. The AWS Secrets Manager allows you to provide credentials to a number of other AWS resources in a secure way. Let's add the secret.

    // first, lets generate a secret to be used as credentials for our database
    const databaseCredentialsSecret = new secretsManager.Secret(this, `${props?.stage}-DBCredentialsSecret`, {
      secretName: `${props?.stage}-credentials`,
      generateSecretString: {
        secretStringTemplate: JSON.stringify({
          username: 'postgres',
        }),
        excludePunctuation: true,
        includeSpace: false,
        generateStringKey: 'password'
      }
    });    

    // lets output a few properties to help use find the credentials 
    new cdk.CfnOutput(this, 'Secret Name', { value: databaseCredentialsSecret.secretName }); 
    new cdk.CfnOutput(this, 'Secret ARN', { value: databaseCredentialsSecret.secretArn }); 
    new cdk.CfnOutput(this, 'Secret Full ARN', { value: databaseCredentialsSecret.secretFullArn || '' });

A couple of notes here:

This is going to generate a password for the username postgres
We are using a few CfnOutputs to print some of the secret resource values. This will allow you to either identify which secret we just created or be able to access it via the AWS CLI. Note, this will not actually output a password! These values will be output in the terminal when you deploy your infrastructure.

Create a System Parameter

Next, we can simply create a system parameter with the secret. You will use this service to provide other AWS services with credentials to connect to RDS.

    // next, create a new string parameter to be used
    new ssm.StringParameter(this, 'DBCredentialsArn', {
      parameterName: `${props?.stage}-credentials-arn`,
      stringValue: databaseCredentialsSecret.secretArn,
    });

Load Default Security Group

Our next step will be to get the VPC default security group. The database should be in a security group so that we can set up connectivity between other resources deployed in a VPC.

    // get the default security group
    let defaultSecurityGroup = SecurityGroup.fromSecurityGroupId(this, "SG", vpc.vpcDefaultSecurityGroup);

Optionally Open Access From Your IP

You can optionally add a rule to allow access to the database from your IP. NOTE THIS IS NOT SECURE! You should always put your database in a private subnet! This part is for educational purposes.

    if(props?.yourIpAddres){
      // your to access your RDS instance!
      defaultSecurityGroup.addIngressRule(ec2.Peer.ipv4(props.yourIpAddres), ec2.Port.tcp(5432), 'allow 5432 access from my IP');
    }

Configure RDS Instance

Now, let us configure and create our RDS instance.

    // finally, lets configure and create our database!
    const rdsConfig: rds.DatabaseInstanceProps = {
      engine: rds.DatabaseInstanceEngine.postgres({ version: rds.PostgresEngineVersion.VER_12_3 }),
      // optional, defaults to m5.large
      instanceType: ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.SMALL),
      vpc,
      // make the db publically accessible
      vpcSubnets: {
        subnetType: ec2.SubnetType.PUBLIC,
      },
      instanceIdentifier: `${props?.stage}`,
      maxAllocatedStorage: 200,
      securityGroups: [defaultSecurityGroup],
      credentials: rds.Credentials.fromSecret(databaseCredentialsSecret), // Get both username and password from existing secret
    }

    // create the instance
    this.rdsInstance = new rds.DatabaseInstance(this, `${props?.stage}-instance`, rdsConfig);

A couple of notes here:

We are putting this into a public subnet. THIS IS NOT SECURE. You should always put your database in a private subnet. We are doing this for educational purposes.
I am creating the smaller database possible to save on costs.

Output RDS Endpoint

Lastly, let's output the RDS endpoint so you can actually connect publically. Again, this is just for educational purposes. ALWAYS KEEP YOUR DATABASE IN A PRIVATE SUBNET.

    // output the endpoint so we can connect!
    new cdk.CfnOutput(this, 'RDS Endpoint', { value: this.rdsInstance.dbInstanceEndpointAddress });

Deploy

That's it! Synthesize and deploy your code and you will have a provisioned database! This may take some time to come up.

cdk synth
cdk deploy

Conclusion

To get the credentials to connect to your new database you can either use the CLI using the CfnOutput or you can manually find it in your AWS Secrets Manager console. In my subsequent posts, I will be using the RDS tutorial as a starting point for other resources to access it. Enjoy! 🍺

TLDR: Checkout the GitHub Repo with the complete code.

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

Interested in having a 1:1 chat with me over this story, or AWS in general? Head over to Hire The Author and let’s connect!

Building a SaaS Product - (1) Setting Up the Project (Angular, Express.js)

Phillip Ninan — Thu, 18 Mar 2021 04:42:01 +0000

For the past several months, I have been developing a SaaS product. This is my first post in a series to show you how to build your own product and deploy it to AWS. We will be creating an Angular frontend, Express.js backend, and using DynamoDb database. I will show you how to use Docker to containerize each component, and then deploying it on AWS. This post will show you how to set up a modular codebase and scaffold all the necessary components.

Buckle up!

TLDR - Here is a link to my Github with the given code.

Twelve-Factor App

We will be following the Twelve-Factor App methodology. This is a framework to help you build software-as-a-service (SaaS). In setting up this project, we will be demonstrating the first two principles, Codebase and Dependencies. Our codebase will be tracked in source control and each component will be able to be developed, built, and deployed independently.

Frontend - Angular

In my previous blog post, I wrote about how to containerize an Angular application. We will use that tutorial as a starter for this frontend.

# clone my git repo
git clone https://github.com/fourgates/blog-docker-angular-container-intro.git
# rename the folder to webapp
mv blog-docker-angular-container-intro webapp
cd webapp
# build the docker image
docker-compose build node
# remove my git repo
rm -fr .git

Backend - Express.js

In another separate previous blog post, I showed you how to containerize an Express.js application. We will use that tutorial as a starter for the backend.

# clone my git repo
git clone https://github.com/fourgates/blog-express-ts-docker.git
# rename the folder to api
mv blog-express-ts-docker api
cd api
# build the docker image
docker-compose build
# remove my git repo
rm -fr .git

Database - DynamoDb

I third previous blog post, I taught you how to containerize a DynamoDb database. We will use that tutorial as a starter for the development database. We will modify the Express API docker-compose.yml file.

version: '3.7'

services:
  express:
    build:
      context: .
      dockerfile: Dockerfile  
    image: express/builder:0.0.1
    container_name: express-container
    ports:
      - '8080:8080'
    volumes:
      - ./src:/usr/src/app/src 
    command: npm run start
  ddb:
    container_name: dynamodb-container
    image: amazon/dynamodb-local
    ports:
      - "8000:8000"
    volumes:
      - dynamodata:/home/dynamodblocal
    command: "-jar DynamoDBLocal.jar -sharedDb -dbPath ."
volumes:
  dynamodata: {}

A couple of notes on this structure:

webapp - this is where the Angular frontend code is
api - this will be for the Express.js backend

Start Your App!

Once you have all of your docker images created you should be ready to start each component! You can open three terminals and run docker-compose up dev in each components folder (webapp, api). Or you can use the -d (disconnect) flag to use a single terminal to run all three commands

Pro Tip - I love VS Code! I usually open a VS Code instance / window for the frontend and backend (2 total). You can then use the terminal in VS Code to start your container while you develop! This way your code and terminal are all in one place. I also use the VS Code peacock plugin to give a different color to each window.

Git Init

Optionally but highly recommended, navigate to the root directory and initialized a new git repo. Run the following commands in the root directory (the parent folder of api, db, and webapp). You will first need to create a new git repo. Github is a great place to get started!

echo "# My SaaS Product" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin YOUR_GIT_REPO
git push -u origin main

Twelve-Factor App - Codebase

We have successfully implemented the first principle of the Twelve-Factor App, Codebase. This principle states that you should have one codebase tracked in source control. If you have more than one codebase this is typically no longer considered a single app, but a distributed system. There is nothing wrong with a distributed system but when you are first building a SaaS product you want to keep things simple and allow a developer to check out one codebase and get started ASAP. As your product grows you may find a use case for additional codebases.

Twelve-Factor App - Dependencies

The second principle of the Twelve-Factor App is Dependencies. This principle says that an app should never rely on the implied existence of system-wide packages. If the frontend and backend are deployed in two different environments this may break your system. You should be able to check out the codebase, utilize a dependency manager, and get started! We are using a mix of Node Package Manager (npm) and Docker. Both of these tools explicitly document the dependencies for each component of our SaaS product. NPM uses package.json to document the dependencies for our node components. Our Dockerfile describes how our Docker images should be built. Each component can be developed, built, and deployed independently.

Conclusion!

That's it! If you run docker-compose up in each folder you will have successfully set up three components in our stack! Congrats!

Code

Here is a link to my Github with the given code.

Getting Started with Express.js in 5 minutes

Phillip Ninan — Fri, 12 Mar 2021 04:58:15 +0000

Welcome to my first post in my Express.js series. Today, I am going to show you how to spin up a new express server in a matter of minutes.

Express.js is one of my favorite node frameworks. It is quick and simple while being very flexible. There is a ton of community support and many popular frameworks were built on top of it. You can find plenty of examples of middleware to help with common use cases such as decoration, authentication, error handling, etc. It's a great framework to help build apps quickly and securely. I have built several APIs using express. Let's get started!

TLDR: Here is a working example in my GitHub.

Prereq -- make sure node is installed. If not, you will need to download and install it.

node --version

First, create a folder for the demo.

mkdir express-demo

Next, initialize the new node app.

npm init -y

Then, install express.

npm install express

We will now create the entry point to get an express server started. Either open up your favorite text editor or continue using your terminal (my recommendation). We are going to make a src folder with a file named index.js inside of it.

mkdir src
cd src
nano index.js

Copy in the following text into index.js.

const express = require( "express" );
const app = express();
const port = 8080; // default port to listen

// define a route handler for the default home page
app.get( "/", ( req, res ) => {
    res.send( "Hello world!" );
} );

// start the Express server
app.listen( port, () => {
    console.log( `server started at http://localhost:${ port }` );
} );

(If you are using nano, CTRL + X to exit edit mode. Next, enter Y to "save modified buffer". Finally, hit enter to save with the current file name.)

Lastly, we need to update package.json to instruct npm on how to run your application. We will change main to point to the newly created src/index.js and add a start script.

cd .. 
nano package.json

This is what the changes should look like.

  "main": "src/index.js",
  "scripts": {
    "start": "node .",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

That's it! Express.js is now ready! All you need do to is start it up.

npm run start

You should see the following text.

server started at http://localhost:8080

In a new terminal, you should be able to curl and see "Hello world".

curl localhost:8080

Alternatively, if you navigate to http:localhost:8080 in your favorite web browser you should see "Hello world"!

Here is a working example in my GitHub. I hope you enjoyed this tutorial! You didn't even have to leave your terminal. My next post in this series will teach you how to convert this project to TypeScript. Also, I will be writing about some useful middleware I have written.

Cheers!

Land a Software Job in 6 Months!

Phillip Ninan — Thu, 11 Mar 2021 04:32:12 +0000

I have JS, PHP, HTML & CSS, but where would you suggest I go next? There’s so much to learn and it’s very confusing. I’m really scared of getting things wrong. Or asking for a road map if you like.

This is a hard question to answer. You need to ask yourself, "What are my goals"?

Do you want to be able to build apps? Web apps?
Do you want to design very pretty-looking websites?
Do you want to want to make cool websites and get them to be on the first page of Google (SEO)?
Are you interested in AI or ML? Do you like databases?

Once you figure out your goal(s), you can put a plan in place. I can help you figure out what steps you should take forward! All you need are some stepping stones. We can create a road map on how to accomplish your goal. Here is a simple roadmap for becoming a web application developer.

🐦 Follow me on Twitter to see even more content! 🐦

!IMPORTANT!

This is a high-level roadmap. This is not intended to turn you into an expert. This is ONE of MANY ways to HELP you land an entry-level web developer job. I have close to a decade of experience writing code. I regularly interview entry-level developers. If you were to complete each of these steps, absorb the material, and be able to speak intelligently about these topics I would be impressed. Take this advice with a grain of salt.

1. Learn HTML and CSS

FreeCodeCamp is a great resource for this. HTML and CSS is the foundation for any web application. Allocate 2-3 weeks for this.

2. Recreate 3 Popular Websites

Develop a landing page(s) using only HTML and CSS. Apple, GitHub, and Netflix are great choices! Understanding how popular websites are built will allow you to follow great patterns when you develop your own. Allocate 1-2 weeks to accomplish this.

3. Learn JavaScript and NPM

FreeCodeCamp and MDN are great resources for this. All modern websites utilize some sort of JavaScript framework. Node and NPM are tools used to work with these frameworks. They allow you to use libraries and tools that someone else has already written! Allocate 2-3 weeks.

4. Recreate 2 Popular Websites with JavaScript

Pick 2 complex projects and recreate their basic functionality using JavaScript, HTML, and CSS. Soundcloud and Twitter are great examples. Allocate 2-3 weeks.

5. Learn How Computers and the Internet Works

Search YouTube and Wikipedia and focus on the Application layer, HTTP, and how modern web apps work. You need to understand the basics of how web applications communicate. Allocate 1-2 weeks.

6. Learn Git and Deploying

All software projects should use source control. Atlassian has great git tutorials. Deploy your projects to Netlify or Vercel. Allocate 1-2 weeks.

7. Learn NodeJs and Express

Use official tutorials, then YouTube and StackOverflow if you don't understand something. I have a getting started tutorial here. Express and Node are great frameworks for build web applications QUICKLY. Allocate 2 weeks.

8. Learn ReactJS and Redux.

I am a big advocate for Angular. But I think ReactJS is in the biggest demand right now. Kent C. Dodds has a great course. Udemy also has some great courses. Allocate 3 weeks.

9. Learn GraphQL

Use official tutorials and YouTube (Udemy if needed). Then transfer your created apps to GraphQL. It should be relatively easy to migrate a small project to GraphQL, especially if you've gotten this far! Allocate 1 week.

10. Learn TypeScript

Learn it using official docs, YouTube & Udemy if needed. After, transfer all created apps to the TypeScript. I have written a great article describing how to convert ExpressJS to TypeScript. Allocate 1 week.

11. Build 2 Complex Applications

Pick a popular service and recreate the core functionality using learned stack: ReactJS, React Ecosystem, GraphQL, TypeScript, and ExpressJS. Then you will deploy it and put it on your resume. Allocate 2-4 weeks.

12. Create a resume, LinkedIn profile and apply for jobs

It should take you 1-4 weeks to land a job.

Conclusion

This should take you roughly ~6 months. This roadmap is not meant to make you an expert. But it should make you competent enough to land an entry-level software developer job. If you complete this roadmap I am very confident that you will be a very marketable developer! Good Luck! Reach out to me for ANY help!

🐦 Follow me on Twitter to see even more content! 🐦

This roadmap was inspired by Nick Bull!

How to Write Great Tests!

Phillip Ninan — Thu, 04 Feb 2021 23:59:01 +0000

In my previous post, I discussed a nifty sorting test. Today, I am going to teach you how to write great tests! When I write a new JUnit test I follow the same formula. This allows my tests to be written and read in a consistent manner. It also helps me write tests faster. I would like to share my format with you today!

The File

The first thing I do is create a new test file/class in my project's test package and create the test method. All my tests end with Test so it is easy to find corresponding classes. A class named SomeService should have a counterpart named SomeServiceTest.

Next, I make sure I give my test a good name. I personally prefer to omit the word test it since its redundant in a test class. The name of the test should describe what is being tested. Make you can easily differentiate similar tests.

public SomeServiceTest{
    @Test
    public void sortByPopularVoteDesc() {

    }
    @Test
    public void sortByPopularVoteAsc() {

    }
}

Outline

Next, I put some boilerplate inside of my method. This is the same format I use for all my tests. I set up my test, I call a function, finally, I use some sort of assertion or verify to ensure the expected results.

public TestClass{
    @Test
    public void sortByPopularVote() {
      // setup
      // test
      // assert/validate
    }
}

Let's discuss some of these components.

setup - This is where you should prepare your code to be tested.
test - This is where you should call the function being tested. This can be good to point out if you call multiple functions in your test.
assert/validate - This is where you actually use an assert or validate function to ensure the actual output matches what you expect.

Setup The Test

Finally, I simply fill in the blanks. If my setup is similar to all other tests I abstract this logic to a @Before function. This function gets invoked before each test. If you have a common setup between several tests, but not all of them, it is also a common practice to write a private function to encapsulate specific setup instructions. Either option makes the setup for common tests more reusable. If you have to make a change in setting up your tests you only have to make it in one place. This is very useful when a refactor breaks a certain set of tests.

public TestClass{
  private List<SortableObj> expected;
  private final SortableObj first = new SortableObj();
  private final SortableObj second = new SortableObj();
  private final SortableObj third = new SortableObj();
  private final SortableObj fourth = new SortableObj();

   @Before
   public void before{
     // some decoration on objects
     // ...
     expected = Arrays.asList(first, second, third, fourth);
   }

    @Test
    public void sortByPopularVote() {
      // setup
      List<SortableObj> actual = Arrays.asList(fourth, third, first, second);
      // test
      Collections.sort(actual);
      // assert/validate
      assertThat(actual).isEqualTo(expected);
    }
}

Testing Nomenclature

Please note the use of the variable names expected and actual. These are keywords commonly associated with writing tests and make them more easily readable. You want the actual object returned from a function to match the expected value.

expected - This is the name of the variable for what you want your output to look like. In this example, we want a list to be in a certain order.
actual - This is the name of the variable to use for the output of the function under test. It is the "actual" output to the function.

Nomenclature - The devising or choosing of names for things, especially in a science or other discipline. In the context of software, this deals with the consistent naming of API endpoints, responses, variables, functions, and documentation.

Conclusion

Using this format you should be able to write more consistent tests in an efficient manner. This allows you to implement more maintainable code. I hope you enjoyed this post! Check out my series on JUnit tests!

Follow me on Twitter if you would like to keep up to date with my latest software content!