DEV Community: Mayuran

Fixing Memory Leaks in Node.js

Mayuran — Tue, 20 Feb 2024 20:00:14 +0000

Usually unless there is a spike in traffic the memory usage of a server should be regular, and stable. Memory usage of a server that continuously increases over time / per request could indicate a memory leak bug.

This post describes how to use "Chrome Dev Tools for Node" to profile memory of a NodeJs App, and identify the source of a memory leak.

Setup



git clone git@github.com:maybebored/codesamples.git
cd memory-leak-example

# Build
yarn build

# Run the app with --inspect so it can be profiled
node --inspect ./dist/index.js
# This will output the debugger port to connect ex:- Debugger listening on ws://127.0.0.1:9229/a2fc3802-d5d9-497b-b3f7-9fe439414e13

Use the dedicated DevTools for Node on Chrome Devices Page. Navigate to the Memory tab, and check that the Node process shown matches the debugger port of your app. If it doesn't show there, go to Connection page and add the connection as localhost:{Your debugger port}, example mine is localhost:9229.

Profiling

There are 3 different profiling types shown here. This post will utilise the Heap snapshot. Perhaps a future post will explore the other 2 types in more detail.

Heap Snapshot

A heap snapshot is what it sounds like, a snapshot of all the objects stored in the heap, how much memory they are using, what created them, and some more details.

I found that comparing snapshots overtime provided the most useful hints to find the source of the leak.

Click on the record button to take a snapshot before firing any requests. This serves as the baseline. Then fire requests and take a snapshot. Repeat this a few times until the analysis reveals something useful.



  
  
  fire n requests


ab -n 1000 http://localhost:4000/info

Snapshot 1

After taking the first snapshot, by default a Summary view is displayed, which shows some important data. The different columns are explained in detail in Chrome's developer docs

One thing to note here is the difference between the column Shallow Size, and Retained Size. Shallow size is memory held by the the Constructor alone, Shallow size is memory held by the Constructor indirectly because it holds a reference to another object. By default the Constructors are sorted by their retained size.

Snapshot 2

This snapshot was taken a few seconds after firing 6000 requests. It is important to remember each snapshot does garbage collection before the snapshot. This means, the memory usage shown in the snapshot is that which is currently in usage.

In this snapshot we notice the memory usage is 24.3 MB. We also notice that in 6th place is a class defined in the app's code: Logger, holding roughly 14 MB - over 50% of the heap memory. This already provides some useful clues about where the issue could be, yet it does not point exactly where the issue is.

Compare snapshot 2 to snapshot 1

Comparison view shows "Size Delta" in Constructors between Snapshot 2 and 1. This allows us to scope down into the problem. When sorting by "Size Delta" it is clear that almost 13 MB of strings were created.

Clicking on (strings), reveals all the strings that were created, and clicking on each opens a detailed view of its contents. At the bottom, in Retainers tab, a hierarchical view of the string's references are shown. Over here, it is noticeable a variable named buffer that belongs to our Logger class is referencing it.

Every other string also points to the same variable buffer. With this information, it is clear enough to debug the code to fix the memory leak.

Note that the hierarchy of references extends all the way until express.js handler functions, and then to NodeJs internal event loop functions. This is the reason why Summary view of a snapshot is not very useful as internal closures' retained memory also increases.

Summary

Chrome DevTools allows for 3 types of memory profiling NodeJs Apps
Heap snapshot types allows taking many snapshots and comparing them.
Summary view of a snapshot does not give an immediate clue as to where the problem is because library functions / internal classes can also appear there.
Comparison view shows objects created between 2 snapshots, allowing to scope down to the problem area.

7 things I learned in my first year of work

Mayuran — Sat, 20 Jun 2020 14:47:50 +0000

Fitting in at your first job can be challenging. Often, there'd be no one to guide you, tell you right from wrong, almost everything you learn is on your own. Growing and improving in your first job, is not obvious either, it takes time and effort. I joined a team, that guided me and provided me with an environment to learn, grow and have fun along the way. I learned many things in my year long journey, and I wish to share some of them, hoping that it helps the newcomers of tomorrow.

Lesson 1: Don't be afraid to interact.

If you're an ambivert like me, you may try to avoid unnecessary social interactions as much as possible. The ambivert (or introvert) in you will cause you to incorrectly think every non-work interaction is unnecessary. It's a bias, don't give in to it. Through some of the most awkward 'Hello's and 'Nice to meet you's I've met some of the brightest minds at my workplace.

When you start talking to people and find out their interests, ideas and stories, you make connections you'd be truly fond of. It will make your work life a bit less boring and more importantly make collaborating an exciting activity.

I made friends with an engineer who loves teaching, maintains an awesome tech blog and loves travelling. I learnt a lot about Java from him, and helped him with JavaScript where I could. We worked on complex tasks together. It was satisfying to collaborate with someone with so much experience, and I may never have had the opportunity if not for the awkward 'Hi how's it going?'.

Lesson 2: Stick to your work schedule.

I knew it's a bad idea to take your work home, but disappointingly, I would find myself working on tasks at home, every other day. It was just bad planning on my part that contributed to this failure.

Eventually I adopted a different model. I plan a schedule when I start my work day, evaluate how much I've completed at the end of the day, adjust my workload for the next day based on how much I can complete and repeat this process. This worked for a while until I started taking up ad hoc tasks, during the middle of the day, failing to complete my planned tasks for the day.

Enter priority based task handling. My planned tasks were my highest priority, I picked them and sorted them based on my capability to complete them and how impactful they were. Ad hoc tasks pop up a lot in an agile team, they are good, it's the mechanism to continuously steer clear of obstacles, and stay on the road towards the bigger goal. But they messed up my daily plan, so naturally I deprioritized tasks for my original list, to make space for the ad hoc task. This is working for me even a year later.

Assigning priorities is a mundane process, but it benefits me in the following ways:

I rarely take work home, so I have time at home to spend on myself.
I feel good about ticking off all my tasks for the day. I am able to see myself grow when I complete more complex tasks quicker.
It improved my productivity, and therefore the team productivity.
I got pretty good at judging priority, which is an essential skill in and outside work.

Lesson 3: Stick to your learning schedule.

If you read the previous lesson, you'd appreciate the value of a schedule. In the world of software, no one knows everything, and the rate at which new information pops up is overwhelming, so how do you keep up with all the new frameworks, languages and best practices.

You don't. You can try to adopt the T-shaped learning model. Simply put, it's when you learn to become an expert at one thing by researching and acquiring deep knowledge, while expanding your knowledge across various subjects.

I enjoy learning about the web, so I dived into front-end development with React, Angular and experimented with some other frameworks. The more I worked, the more I realised, how important understanding JavaScript (ECMA Script) was to becoming a good front-end developer and building client side application, because all good UI frameworks, do the same thing: build wrappers around JavaScript's core features to expose APIs that make the developer's life easier.

So I spent a lot of time reading and understanding the fundamentals of JavaScript, tinkering with experimental JS features, using advanced concepts at work, all in order to improve my mastery of the language. This helps me work with modern frameworks better, debug faster and justify my technical decisions. In addition, I continue to learn more about how the web works, how online payments work (My team is working on a payment gateway) and cloud technologies.

My T shaped knowledge on software might look like the above.

To do this effectively, I put in six hours each week for six months to read, code and discuss JavaScript with experts. 1 year later, I can work with advanced concepts like closures, promises and async functions with ease. I'm not an expert yet, but I'm progressing steadily.

Figure out what you'd like to learn by actually trying everything you might like to learn; you'll eventually find out what you are most interested in. After that work out a study plan, invest time, subscribe to resources online (paid or free) and work your way through it.

More on T shaped learning

Lesson 4: Challenge your peers.

As a junior working with people who have more experience and knowledge can be daunting. It's normal to feel like you should have less say, but it's wrong to follow through with that feeling.

You're depriving yourself of opportunities to learn if you never challenge your peers. Sticking to my learning schedule helped me understand JavaScript as a language really well, why it was made, how it was supposed to be used and what are some common pitfalls.

We use AWS Lambdas at work to offload asynchronous tasks, which was a neat idea. The code written (in JavaScript) to do it, not so much. I raised questions about efficiency, complained about code quality and eventually asked for a chance to work on it to make it better. It didn't go exactly as planned, (we still have Lambdas written with bad code, more on that later) but some good came out of it.

The team appreciated my growth and my ability to point out mistakes.
I learned how to communicate my thoughts better, especially on tech. It's not easy to get your point across all the time, which is why it takes practice.
Asking 'Why are we doing this?' helped me understand the system better, allowing me to be a contributor the next time we were designing new features.

Start with a simple "why", at your next meeting. It goes a long way.

Lesson 5: Do Effort vs Impact analysis

As a software developer you put effort into solving problems that have various levels of impact. Sometimes you're changing the colour of a button, sometimes you're integrating a fraud detection mechanism into an online payment flow.

It's important to decide how much time you'll spend planning/working on your task, before you get started on it.

Changing the color of a button, has comparatively less impact on the user experience, than integrating fraud detection. It is also easily undoable, however undoing an integration from the user journey is not easy. Therefore, spend less time planning and discussing the color, instead push the change and wait for feedback from the customer experience team, to decide how you'll improve.

However, if you integrate fraud detection without proper planning, you may break existing user experience, face new bugs, and may not even achieve your goal of preventing fraud effectively. In this case, it is worthwhile to test the integration separately, discuss edge cases and spend time building experiments. These experiments maybe throwaway work, but it may save you from costly bugs and frustrated users.

When my team wanted to integrate a third party fraud detection API, I spent time writing SQL and Node scripts to test the software in an isolated environment. We may never use the code I wrote, but it helped uncover that we were missing some key pieces in our flow required for fraud detection. If we didn't realise this this integration would have been a costly mess.

When given a problem, before you plan a solution, think of the impact solving it will have on your users. Plan your effort with respect to this impact.

Lesson 6: Take up teaching

It's not only the best way to give back to the community, but also a great way to validate your skills. I've always loved teaching other, so I was fond of teaching others at work.

Through teaching, I improved how I communicate complex concepts, and when people ask me questions to which I don't have an answer, I'm presented with an opportunity to learn more. Through a cycle of learning and teaching, I improved my React skills rapidly.

In addition, you also build meaningful connections with your team members, when you play the role of a teacher. You build trust and gain opportunities to collaborate on exciting problems.

As a teacher you're not only absorbing knowledge but also disseminating knowledge, which helps your team to trust you and eventually gain opportunities to work on exciting and novel problems.

As a new member in the team, it might seem impossible to start teaching others, but your fresh perspective on the system and the free time you have helps you build knowledge that others might need desperately. Use this opportunity to try to teach something, however simple it is.

Lesson 7: Don't fall into imposter syndrome

The world of software is filled with popular, influential and talented people. I've felt insufficient after seeing developers who own GitHub repos with over 1k stars, write consistently, brag a huge following and rank high on Stack Overflow, while I hadn't answered a single question until recently. I sank into a feeling that everything I know is trivial and I could be easily replaced. I compared myself to people I didn't even know, and felt bad about it. This feeling is referred to as Imposter Syndrome. The right way to deal with these feelings is to have better perspective.

The high performing developers you see online, didn't get there in a day, they worked hard for it. What you need to do is not feel bad about your efforts, but work on improving yourself. You've done a good job so far and you have more to go.

On that note, remember to take care of your physical and mental health, more often than you take care of career.

These lessons definitely aren't all the answers to shaping your career, but it should get you started well. In conclusion, your first job (in software) will be filled with challenges and opportunities. Learn to pick and choose wisely, take it easy on yourself when you make mistakes and have fun along the way.

No one has the right answer to everything, so don't be afraid to try what you like, and create your own identity in the complex world of Software Development.

If you liked this follow me here and/or on Twitter for more of my thoughts on software.

Part 2: Stashing and Rebasing in Git

Mayuran — Fri, 20 Mar 2020 12:37:21 +0000

Note: This series assumes the reader is familiar with using the command line and has used basic git commands during development. The series aims to provide examples of using lesser known git commands that improve development experience and reduce friction during collaboration across the team.

Part 1 covered how to set up git for your project, so you can collaborate better. Part 2 is about git stash and git rebase - two commands I use regularly when collaborating on tasks.

git stash

While working in a team, there might be situations where you'd have to temporarily put away your current work, to work on something of higher priority, and git stash helps you stash your work away and clear your working directory.

It helps to understand about the three stages, that your changes are moved to and from in a git repository, before we dive into git stash.

When you checkout or make new changes they live on the working directory.
Changes you git add are moved to a staging area.
From there when git commit they are moved to the repository.

So in between all these stages, git stash pushes all the changes in the working directory to a special directory called stash.

`git stash push [-m <message>]`

Imagine a scenario, where you started working on a feature, but you're not nearly ready to commit these changes, and your teammate asks you to work on a different feature branch, because it is of higher priority.

To start off you'd need to clean your working directory, and save your existing changes somewhere safe.

git stash push -m "Upgrading version" does just that.

Notice how after running git stash, the working directory becomes clean, that's because all the changes have been pushed elsewhere. Let's take a look at it.

`git stash list`

It's what it sounds like, this commands lists down all the changes you stashed. We've stashed one such change. Let's look at where they've been saved.

git stash show summarises the stashed changes. git stash show -p [<stash>] shows the exact diff that is stashed.

`git stash pop [<stash>]`

Let's find out how we can retrieve changes from a stash to the working directory. There are two ways to do this: git stash pop and git stash apply. pop removes the stash before applying it, apply does the same but doesn't remove the change set from the stash.

Notice how the stash is empty after popping.

`git stash apply [<stash>]`

The stash remains the same after using apply.

`git stash drop [<stash>]`

Use this command when you want to delete an outdated stash from you list.

When you want to clear the entire list, use git stash clear.

pro tips

Use git stash to temporarily put away your changes when checking out a new branch.
Ensure your working directory is clean before applying changes from stash.
pop, apply and drop take an optional <stash> parameter. If not provided, it defaults to 0, which is the latest stash.

git rebase

git rebase applies your commits on top of another branch's tip. A diagram would explain this better.

This command allows you to be able to move your commits, making this a very powerful command, used for different purposes. Let's look at a few scenarios.

Conflict free merges

As we saw in Part 1 of this series, teams that follow git, feature branches are merged onto the Development branch. To avoid conflicts during merge, we try to ensure that the HEAD of your feature branch is on top of the latest commit in the Development branch.

Branch feature and branch Development have one commit each and therefore in git terms, have diverged. By rebasing feature on Development, all the commits of the feature branch will be replayed on top of the latest commit in the Development branch.

Notice how after rebasing the commit hash changes, this is because git creates new commits behind the screen, and stops pointing to the old commits.

Merging feature_branch to Development would now result in a fast-forward merge, which means there will be no conflicts to resolve during the merge. A bit more about Git Merge.

Rewriting history

Git Rebase essentially allows for moving commits around. Since git commits are record of history, by moving them around we can indeed rewrite history.

Here's a quick overview of ways you can change history:

- Pick or drop commits.

You might have accidentally committed some changes. To undo that you can drop it from the history.

- Squash commits together.

Consider a series of commits in which you fixed typos. Consider squashing all of them together to make your history look cleaner.

- Edit or reword commits.

Everyone loves meaningful and clean commit messages. Reword commits if you think it wouldn't make sense to your reviewer.

pro tips

Use git rebase to sync your feature branch with the branch it will be merged into.
Interactive rebase (git rebase -i) requires basic vim usage. Check out this awesome cheatsheet to get started.

In this post, we checked out git stash and git rebase and where to use them. Check out the official documentation for advanced usage and in some depth information.

Let me know if you'd like me to continue updating this series, with more commands I run into.

Part 1: Setting Up Git

Mayuran — Fri, 14 Feb 2020 12:08:16 +0000

Note: This series assumes the reader is familiar with using the command line and has used basic git commands during development. The series aims to provide examples of using lesser known git commands that improve development experience and reduce friction during collaboration across the team.

Before we dive in, it helps to imagine a scenario in which git is used in a modern development team. A project's original source code is usually stored in a remote server provided by a 3rd party git service such as GitHub. Each team member then forks this repo, clones the fork, to work on their changes and then eventually merge it back to the original source code via a Pull Request. This is one of the many approaches to using git, called Forking Workflow

If that didn't make much sense, don't worry. We will look at each step in detail, using a demo repository and cover some useful commands that will help you collaborate better.

Step 1: Fork the original remote repository

Remote repository refers to repository hosted by GitHub on their server. Note that forking isn't a special git command. All it does is make a copy of the remote repository in your own remote server. Here's an example repository, (wittily named "Spoon-Knife") you can fork to see for yourself.

Step 2: Clone the forked repository

Now that you forked to create your own remote copy of the original repo, you can copy it to your local machine to begin work.

It's really easy to make a copy of a repository. git clone <repository>. <repository> here refers to the location of the repository to copy from. Could be a local file path, or a remote url. In this case you'd be using a remote url like such example. Try cloning the fork you made in Step 1.

Step 3: Do a status check.

Okay you've forked octocat/Spoon-Knife to your own remote repository, and you've cloned a copy of your remote git repository to your local machine. That's three repositories that must be kept in sync so that individual contributions from the rest of the team doesn't cause issues:

The original remote repo: octocat/Spoon-Knife (Upstream)
Your remote repo: /Spoon-Knife (Origin)
Your local repo /Home/Projects/Spoon-Knife (Local)

Changes are pushed from Local to Origin and merged from Origin to Upstream. It is possible, that while you are working on your changes, other developers have merged code to Upstream. So it is important you regularly check if Upstream has changes, that you need to synchronise. Sounds complicated, but git makes it really easy to do this.

Step 3.1 Track remote repositories

    git remote -v 
    # origin https://github.com/maybebored/Spoon-Knife.git (fetch)
    # origin https://github.com/maybebored/Spoon-Knife.git (push)

    git remote add upstream https://github.com/octacat/Spoon-Knife.git 
    # Set `upstream` to track the original remote repository.

    git remote -v
    # origin https://github.com/maybebored/Spoon-Knife.git (fetch)
    # origin https://github.com/maybebored/Spoon-Knife.git (push)
    # upstream https://github.com/octocat/Spoon-Knife.git (fetch)
    # upstream https://github.com/octocat/Spoon-Knife.git (push)

git remote -v lists all the remote repositories that are being currently tracked. By default it will track, the remote repository from which we cloned, and calls it origin. This is your server side copy of the original project.

We add another remote reference to "upstream" with git remote add upstream <upstream>

Step 3.2 Fetch the development/master branch from upstream

Now that we told git the two remote repositories to track, let's fetch a branch from the remote repository and begin work.

git repositories contain branches to maintain different versions of the project, where one branch will be the master branch or the original version of the code. Other versions branch off, from the master branch. It is common practice to also maintain a development branch for the version of the code with new changes, so that it can be tested in a test environment, before it is merged to the master branch, to be deployed to a production environment.

"Spoon-Knife" doesn't have a "development" branch, so we will fetch the master branch. Before that run git status to check the current status of your local repository.

On branch master suggests that we are already on the master branch. The local master branch was set to track the remote branch at my server side copy: origin/master when the repository was cloned and is currently up to date with it. We also see that the working tree is clean (We will explore what this means soon).

Other developers will eventually merge their code to the original repository at upstream/master, never to my server side copy of the repository. Therefore, I do not want my local master branch to track my server side copy at origin/master, instead I want it to track the original server side repository upstream/master.

    git fetch upstream master 
    # From https://github.com/octocat/Spoon-Knife
    # * branch            master     -> FETCH_HEAD
    # * [new branch]      master     -> upstream/master

    git branch --set-upstream-to upstream/master
    # Branch 'master' set up to track remote branch 'master' from 'upstream'

First we need to fetch the master branch from upstream using git fetch upstream master then we need to set our local master branch to track it. git branch --set-upstream-to upstream/master Now we can fetch changes from upstream to ensure the local branch is synchronised with the upstream branch.

Running git status now shows that local master branch is tracking the original master branch at upstream/master.

Good! We have successfully set up everything we need to begin working on our feature. Before that, let's recap what we have done so far.

We forked octocat/Spoon-Knife to make our own server side copy
We cloned our server side copy, to make a copy in our local machine.
We fetched master branch and set its upstream to master branch in the original remote repository.

In the next post, we will explore two more commands (git stash, git rebase) that will make fast-paced development a bit less painful.

How To Use React Error Boundary

Mayuran — Mon, 09 Sep 2019 16:01:25 +0000

Recap

In a previous post, I explained how I came to find out about Error Boundary. In this post let us dive into it a bit more, and understand how React provides a declarative way to catch and handle errors that occur during rendering. Finally, I will show how I used it.

Declarative Error Handling

In a typical JavaScript code, errors can be caught and handled using a try - catch block.

try {
   throw new Error('A new error');
catch (error) {
   console.log('Caught this error', error);
}

This is imperative code where we tell the program how to do something, usually in a series of steps. This is not the case when using React, where we tell the program what to do.

Let's take a look at code examples, I found elsewhere of both approaches, for doing the same task of changing a button element's colour

Imperative example, where we provide step-by-step instructions to change the change the button colour.

const container = document.getElementById('container');
const btn = document.createElement('button');
btn.className = 'btn red';
btn.onclick = function(event) {
 if (this.classList.contains('red')) {
   this.classList.remove('red');
   this.classList.add('blue');
 } else {
   this.classList.remove('blue');
   this.classList.add('red');
 }
};
container.appendChild(btn);

React example, where we handle state and return the button element.

class Button extends React.Component{
  this.state = { 
     color: 'red' 
  }
  handleChange = () => {
    const color = this.state.color === 'red' ? 'blue' : 'red';
    this.setState({ color });
  }
  render() {
    return (
       <div>
         <button 
            className=`btn ${this.state.color}`
            onClick={this.handleChange}>
         </button>
       </div>
    );
  }
}

We are only telling React what to return (display) given the current state of the program. Therefore using a try-catch block while trying to render a component will not catch errors in the component. React Error Boundary is a declarative approach to error handling.

How I used React Error Boundary

Using Error Boundary helps render a fallback UI, which is better UX than a blank screen, but we can do better. We can reset the state so users can go back to what they saw before the error occurred, without having to reload the page.

The fallback UI can contain a button, which when clicked, sets the component's state to its initial state, that is {hasError: false}. But before it does this we must reset the state of the child component that is rendered within the Error Boundary, so that when the app re renders we are not in an erroneous state. See for yourself below.

Conclusion

With that I conclude my two part series on React Error Boundary. The last bit about resetting state is just something I experimented with, I didn't find anything online that endorses that, so I appreciate any feedback on that.

React Error Boundary - An Intro

Mayuran — Mon, 09 Sep 2019 16:01:11 +0000

Preface

My team and I are currently working on an analytics dashboard for a payment gateway at work. We are using ElasticSearch to comb through large amounts of raw data, aggregate that, then provide useful insights, displayed on a beautiful UI built using ReactJS. The application's backend is supported by NodeJS + Express and MongoDB for some data persistence.

After working on it for ~4 months, I finally got to demo it, to other team mates. It wasn't perfect, but I wanted to show what we have achieved so far. I showed our really fast search feature. I hit enter after typing the search term, expected it to load the results in blazing fast speed, but instead I got a white screen. The entire app had crashed, with no information about what went wrong. This was embarrassing, and I just found out that we hadn't thought of error messages.

Context

We have unit tests, code reviews and manual QA testing to prevent the bad stuff like this from happening. BUT, it did. I figured out the root cause using Chrome Dev Tools, and quickly resolved it, but this wasn't enough. What if this happens at a real demo. I needed to do something better.

Why did the app crash?

In one of the component's render code I was trying to access a property on an undefined object. That throws an exception: TypeError. And if you don't handle this exception, then you get the infamous Uncaught TypeError in the browser console.

But, why the did the app crash ?

To answer this, let's dig into the code a bit more. In the below pen, as you click the button the status updates, but the third time you click it you will see a blank screen, because the app crashes. Open the pen in full view and inspect your browser console, and you'll see the error occurred in the BadgeComponent.

Why would an error that occurred in one child component crash the entire application? The React Team has an answer to that - but in short and quite obviously, leaving a broken UI is bad UX, so it is better to just remove the entire UI.

Enter Error Boundary

A blank UI with nothing to see is also bad UX, and to answer that React 16 introduces Error Boundary. It is essentially a component that is able to handle an error that occurs in a child component, and display/render a fallback UI. There are plenty of great posts online explaining how to use one, but here's a quick pen I made that gracefully handles the error we see in the above pen.

In my next post in this series, I'll talk about how Error Boundary works, and show you what to do after an error has been caught by the Error Boundary Component.

How to set up a custom domain for your EC2 instance without using Route53

Mayuran — Thu, 21 Mar 2019 03:11:13 +0000

In my previous post I explained how to deploy a simple WordPress site using AWS. This post shows how to set up a custom domain to access your site. The default way to access EC2 instances is by typing its IP address (192.168.0.1) in a browser. This is great for testing, but when going public with your blog or portfolio website, it makes more sense to have a domain name such as "example.com" instead. You can learn more about DNS and IP addresses outside this post.

AWS Route53 is a web-based domain resolution service, packed with additional features for reliability and scalability. It's easy to use, flexible and great for beginners. However, this post is intended for those (like me) who do not wish to use Route53.

Step 1 - Set up Elastic IP

Navigate to EC2 > Network and Security > Elastic IPs on the AWS Management Console and click on allocate new address.

Click "Allocate" on the next screen. You'll see your newly created Elastic IP after confirming. Select this IP > Actions > Associate Address.

Select your instance from the dropdown and click Associate. You now have an elastic IP address for your EC2 instance. This means you have a static IP that doesn't change even after restarting the instance. This is important to complete our next step.

Verify that you can see your website by navigating to this elastic IP address.

Step 2 - Update your domain's DNS records to point to your elastic IP

Create type A DNS record for your domain, which points to your elastic IP. Without an elastic IP, we'd have to keep updating this record ever time you restart your AWS instance.

After you create a new DNS record it can take anywhere between 5 minutes to 1 hour, to update. ⏳

Step 3 - Update EC2 instance's domain settings

Login to your EC2 instance via SSH, then specify your domain name in apps/wordpress/htdocs/wp-config.php file like shown below.

Replace```define('WP_SITEURL',

'http://' . $_SERVER['HTTP_HOST'] . '/');
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/');

with```define('WP_SITEURL',

 'http://DOMAIN/');
define('WP_HOME', 'http://DOMAIN/');

And that's about it. You should be able to access your WordPress site at your domain address. 🎉

Let me know what you thought about this article in the comments. I want to improve my writing and help others learn to love tech, the way I did.

Deploy A Wordpress Website using AWS EC2 (The absolute beginner's guide)

Mayuran — Fri, 15 Mar 2019 12:19:53 +0000

WordPress themes are a great because you can set up an elegant website, within minutes, almost effortlessly. Because it abstracts away most of the styling and all of the backend work, WordPress is the go-to solution to put up a website. If you are just getting started in the web development world, this guide is for you.

Step 1 - Set up your AWS account

AWS offers a free tier to get free hands-on experience with its services, for new sign-ups. The free tier is sufficient for this guide.

Step 2 - Follow this AWS Tutorial to set up a WordPress website.

This tutorial is well written to guide newcomers. Yet, if it is still confusing (which is okay), leave a comment to get some help. The above guide is only meant for those who want to deploy a mostly static, simple, experimental blog. It is not meant for production level solutions.

AWS EC2 is a virtual server in the cloud, and an Amazon Machine Image (AMI) provides the configuration information to this server so it can host your Wordpress website. When you select "Wordpress powered by Bitnami" and click next you get that done in ONE click. Ability to launch one-click solutions is one of the many benefits of modern cloud computing.

Step 3 (Optional) - Configure your EC2 instance's security configurations

If you can access your EC2 instance's public IP on your browser, you can ignore this step.

Security configurations are usually created automatically when you set up your EC2 instance, to protect your virtual server from external attacks. Check your security configurations by selecting your instance and then viewing its associated security group, under the "Description" tab. You should see something like the image below. Then go to your instance's security group, by clicking on it.

If you successfully created your instance but can't access it using your browser, then maybe you haven't allowed any incoming connections to your instance. Edit your security group's inbound rules to allow incoming traffic. These rules describe the type and source of incoming web traffic that is allowed by your instance. The image below shows my rules.

I allow HTTP and HTTPS traffic from all IP addresses because I'm hosting a website, but I only allow SSH traffic (SSH is used to remotely connect to my server) from my IP. Configuring security rules, is easy and intuitive on AWS Console.

If you do not have inbound rules that allow HTTP or HTTPS traffic then you cannot view your site using a browser (nor can anyone else). So go ahead and add a rule, choose HTTP/HTTPS for type, and for source, add either your ip address or leave it blank to allow all incoming connections. If you're interested in learning more about security groups in AWS, the official documentation is a good place to start.

Now go check if you can visit your instance's public IP using a browser. There you go, you just used AWS to deploy a Wordpress Website.

Let me know what you thought about this article in the comments. I want to improve my writing and help others learn to love tech, the way I did.