When I began my first React application, I struggled to decide how I wanted to organize my code. I knew that I was free to structure it in any way I wanted, but was unsure of what best practice was. After doing much research, I was forced to conclude that there was no accepted best practice. You can find many opinions out there, and today I am adding my own. With my first application, I came to a solution that I thought was pretty solid at the time, but I have since developed many more applications and have honed my approach with time. I am confident that I have landed on a structure that will be flexible and manageable as a project grows.

Introduction

Here we are; part 2 of the Serverless React App series. As a DevOps Engineer, I appreciate this part of the project. Don't get me wrong; I enjoy the entire stack, but automating building, linting, and testing is so refreshing. Knowing that newly introduced code is formatted correctly, and tests don't fail before merging into develop makes development much more enjoyable for me. Because everybody reading this is probably creating merge requests and having their code reviewed, it most likely will for you too.

Table of Contents

• Introduction: Serverless Re...

In my previous post, I introduced the Serverless React App series. I went over the outline for where the series is heading and what things will be covered. This is Part 1 of the series. Today I will quickly go through the creation of our react app. I want the main focus of this series to be around serverless architecture and what it takes to get an application deployed. Let's get started.

Serverless is not a new concept, but not everyone knows how to implement it or get integrated using GitLab's CI/CD pipelines. In this series we are going to cover how to build a full stack from the creation of the React App to deploying.

Archero is such a simple yet very addicting game. Make sure to watch for new codes and use them before they expire.