DEV Community: Samuel Umoren

How I Stopped Chasing Clients and Started Building Assets: A Technical Writer's Guide to Multiple Income Streams

Samuel Umoren — Tue, 08 Jul 2025 14:12:59 +0000

In 2020, I was in my final year at university, working as a frontend engineer at a fintech startup for 30k naira per month. My friend and I needed extra income and were literally hungry. Then we found this Indian blogger running Codesource who paid $10 per frontend tutorial. That $10 was significant money for us.

But here's what changed things for me: I didn't jump into freelancing cold. I'd been building what we call "career capital" by writing my own content on Medium, Dev.to, and Hashnode. Free content that showed I could write technical tutorials.

That mindset shift from "I need money now" to "I need to build assets first" really helped my trajectory. Fast forward to today, I'm working as an AI developer, still earning from technical writing, and speaking about this journey. Not because I figured it all out, but because I know how much these strategies can help when you're starting from survival mode.

Here's what I've learned about building multiple income streams as a technical writer. Some of it worked, some of it didn't, but all of it taught me something.

Why I Had to Think Beyond the 9-to-5

The biggest shift that helped me was realizing you have to build the asset before you monetize it. Most people want to get paid immediately, but I learned you need to prove you can deliver value first, then people will pay you for it.

This same principle applied when I moved into AI development. I built a bunch of projects first, documented everything, then used that as my transition path. The documentation work I'd been doing suddenly became more valuable because I understood the technology I was writing about.

Career capital isn't just about portfolio pieces. It's about developing the skills and reputation that make opportunities come to you instead of you chasing them constantly.

The Technical Writing Areas That Actually Pay Well

Three areas are really hot right now:

Developer documentation is finally getting the respect it deserves. Companies understand that bad docs kill adoption. This is why programs like WriteTech Hub exist. When I started in 2020, we were just writing blogs. Now there's serious demand for API docs, SDK guides, and integration tutorials.

AI tools and workflows are everywhere. For the last few months, every client article I've written has been AI-focused. Agents, MCP (Model Context Protocol), RAG implementations. You need to stay with the trends because that's literally part of the job.

Cloud-native tools keep evolving. Cloud management, containerization, DevOps tooling. This demand stays consistent because the ecosystem keeps changing.

What I've learned about showing your skills in these areas:

Build public examples. Don't just say you can write API docs, actually document an API. Pick a trending AI tool and write a tutorial about it. Contribute to open source documentation.

The rates I've seen: Content writing ranges from $100-600 per article depending on complexity. Core documentation work varies by company, but it's significantly higher than blog rates.

Companies paying top rates want writers who understand the technology they're documenting. That's why my AI transition made my writing more valuable. I can explain what I've actually built.

Where to Find Real Freelance Opportunities

I'll be straight with you. I haven't had success with Fiverr or Upwork. But here are the four channels that built my career:

CommunityWriterPrograms repo was my 2021 breakthrough. I found companies like Sanity, Strapi, ContentLabs, LogRocket. Currently working with Draft.dev as my stable client. This repo really helped change my financial situation. Another resource is who pays technical writers.

Cold outreach to startups requires mastering the art of cold DMs. Right now is the perfect timing because AI startups are launching daily. Find something genuinely interesting about their product, then pitch. Don't spam, be specific.

Your network, including ghost writing, is more powerful than you think. Here's the reality: 60% of my work isn't in my name. From 2020-2023, it was 90% ghostwritten. Rates were $150-300 per piece. This has pros and cons. You get paid, but don't build a public portfolio. Weigh it based on your current needs.

Dev advocate connections often need content support and pay well. Build relationships with people in these roles.

The CommunityWriterPrograms repo update I'm working on is me giving back to the resource that really helped fund my career transition.

Creating Content That Opens Doors

First, cultivate a growth mindset. Be ready to try things, experiment, fail, and iterate.

Show up consistently and solve real problems. Thanks to AI tools like Claude and ChatGPT, anyone can build anything now. But you need to build with product expertise and create buzz around solutions people need.

Let me give you a concrete example: The biggest issue in coding with LLMs today? Leaked secrets. Everyone's bashing new coders for exposing API keys, but nobody's helping them. So I built npx secure-commit scan and shared about it. That's the kind of thing that opens opportunities.

Be part of the conversation. Join community discussions on Discord, Reddit, and X. Make open source contributions by writing articles for tools that don't have any and tag the maintainers. Participate in discussions around topics you care about. Don't just consume, create.

Apply to speak at events, and volunteer to help. Being a helper is underrated. You never know who's watching.

Stay curious and locked in. The 100 Nigerian Dev Articles project I'm running is an example of how I stay curious about our ecosystem and document what I find.

The pattern that's worked for me:

Find problems → Build solutions → Document the journey → Share with community → Opportunities follow.

Unconventional Ways to Monetize Your Skills

"Interning" for established technical writers or dev advocates might not be for everyone, but it's one of the best learning experiences. You don't just learn how to write; you learn client management, project scoping, and communication patterns.

What I learned from this experience is important: don't get exploited, but working under someone who can afford to delegate teaches you the business side. I learned more about client relationships from ghost writing than I ever would have figured out alone.

Create text-based educational content with micro-monetization. Build something like a practical course or guide, add a Buy Me a Coffee button, or request GitHub sponsorship. If it delivers real value, people will support you.

Document your learning journey with a specific technology. People pay for organized, tested knowledge that saves them time.

Don't give up if it doesn't work right away. Take it as experience because you're growing either way. Each "failed" project teaches you about audience, packaging, and delivery.

You're building multiple income streams while developing business skills that most freelancers never learn.

The Hard Truths About Freelance Challenges

Inconsistent income is the biggest challenge. Writing programs don't last forever. They can suspend anytime. Agencies are more predictable but tougher to break into.

Solution: Apply to as many writing programs as possible. Programs, agencies, cold DMs. But when you get them, treat each like a full-time job and give your best work.

Time management and communication is where I've failed a lot. Managing time and communicating ETAs properly. I've only been saved by the quality of my work, but don't rely on that. Be professional and reliable as much as possible.

Payment bottlenecks still hurt me. Inconsistent payment schedules, gateway issues. Try Mainstack if you're a Nigerian freelancer dealing with international payments. It's been a great solution I found recently.

Isolation kills productivity. Don't be a lone wolf. Have a healthy community of friends who understand what you're doing and can help you navigate challenges.

What's worked for me is treating inconsistency as the norm, not the exception. Build multiple streams, communicate like a professional, solve your payment infrastructure early, and lean on community when things get tough.

Building Products from Your Knowledge

Start with what you already know deeply. My AI transition journey could be a course called "From Technical Writer to AI Developer." Don't create in a vacuum.

The first thing I recommend is asking your audience what they're struggling with. The 100 Nigerian articles project is part of market research. I'm seeing what resonates. For example, when I highlighted Linda Ikechukwu's article on creating a technical writer resume, it got the most engagement of any article I shared in the collection. That tells me people are more interested in career-growth related stories.

Validate before you build. Share your course outline, see what gets engagement. Build the landing page before the course.

How Technical Writing is Evolving

AI is changing everything. I lived this. I went from documenting other people's code to building AI systems myself.

The future belongs to hybrid roles: Writer + Developer, Writer + AI specialist. Companies want people who understand what they're documenting.

The skills I think are most important now are learning the technologies you write about, AI tool integration (obvious but true), developer experience thinking, and product sense, not just writing sense.

My career is proof: the writers who evolve beyond just writing will have the most opportunities.

Building Assets That Work for You

The thing that connects everything in my journey is this: build assets, serve community, stay curious. That's what's helped me future-proof my career, even when I didn't know what I was doing.

Whether it's the CommunityWriterPrograms repo that funded my transition, the AI projects that got me hired, or the 100 Nigerian articles project building my speaking credibility, each asset has compounded over time.

I learned to focus less on chasing individual clients and more on building things that bring opportunities to me. It takes longer upfront, but the payoff is more sustainable than constantly hustling for the next gig.

The technical writing industry needs people who understand technology, not just grammar. I'm still figuring this out, but positioning yourself as someone who can bridge that gap seems to be working.

Optimize Your Node.js API with Clustering, Load Testing, and Advanced Caching

Samuel Umoren — Thu, 19 Oct 2023 15:18:20 +0000

Imagine your Node.js application struggling to keep up as user requests pile up, creating a performance bottleneck that no developer wants to face. This is a common challenge in single-threaded Node.js applications. But fear not; robust solutions exist to break free from these limitations. In this article, we'll delve into three powerful strategies to supercharge your Node.js API: Node.js clustering to leverage multiple CPU cores, load testing with Autocannon to measure performance, and advanced optimizations like Least Recently Used (LRU) caching and logging.

Prerequisites

To follow along with this article, you’ll need to have the following:

Node.js and npm installed
Basic understanding of TypeScript and Express.js
Clone the starter repository and switch to the starter branch: GitHub Repo

Understanding Node.js Clustering

Think of Node.js clustering as a team of workers in a factory assembly line. In a single-threaded environment, just one worker (or CPU core) does all the tasks. This lone worker can get overwhelmed, leading to performance bottlenecks. Imagine multiplying that worker to fully utilize all the available assembly lines (or CPU cores). That's what Node.js clustering does—it distributes incoming network requests across multiple CPU cores, making your application more scalable and efficient.

The importance of Node.js clustering can't be overstated. It's like upgrading from a one-man shop to a full-fledged factory. Distributing tasks speeds up the production line and makes it more resilient. If one worker fails, others can pick up the slack, ensuring your API remains responsive even under heavy load.

Let's examine how clustering is implemented in your cloned starter branch app.ts. The relevant part is as follows:



import cluster from 'cluster';
import os from 'os';

const numCPUs = os.cpus().length;

if (cluster.isMaster) {
    logger.info(`Master ${process.pid} is running`);

    // Fork workers
    for (let i = 0; i < numCPUs; i++) {
        cluster.fork();
    }

    cluster.on('exit', (worker) => {
        logger.error(`Worker ${worker.process.pid} died`);
    });
}

In this snippet, we first import the cluster and os modules. We then determine the number of CPU cores available on the machine using os.cpus().length. If the code runs on the master process, it forks a worker for each CPU core. This way, we can fully utilize the multi-core capabilities of modern CPUs to improve the performance of our Node.js application.

When you run the project with npm run dev, you should see this:

These logs confirm that your application is running in a clustered mode, utilizing all available CPU cores. Each worker is equipped with an instance of the TensorFlow model, ready to handle incoming requests. Let’s break it down:

Master is Running: The [INFO] Master 23249 is running message signifies that the master process has successfully started. The number 23249 is the process ID of the master.
Workers are Running: Messages like [INFO] Worker 23254 running on http://localhost:3000 indicate that worker processes have been forked and are running. Each worker listens on the same port (3000 in this case). The numbers 23254, 23255, etc., are the process IDs of the workers.
Model Loaded: The [INFO] Model loaded messages confirm that the TensorFlow model has been successfully loaded into each worker. This is crucial because each worker will handle incoming requests independently.

Load Testing with Autocannon

Imagine your API as a busy highway. You've added more lanes (workers) to handle traffic, but how do you know it's enough? Well, that’s where you need to load-test your API. To do that, we’ll use Autocannon. Autocannon is a fast HTTP/1.1 benchmarking tool powered by Node.js. It's like a traffic simulator for your API, allowing you to understand how your application performs under different load levels.

Setting Up Autocannon

First, you'll need to install Autocannon. You can do this by running npm install autocannon in your terminal. Once installed, you can create an autocannon-test.js** and add these lines of code:



const autocannon = require('autocannon');
const fs = require('fs');

const boundary = '----WebKitFormBoundary7MA4YWxkTrZu0gW';
const filePath = '/Users/mac/Desktop/sammy23/image-recognition-api/image1.png';
const fileContent = fs.readFileSync(filePath);

const body = Buffer.concat([
    Buffer.from(
        `--${boundary}\r\n` +
        'Content-Disposition: form-data; name="image"; filename="image1.png"\r\n' +
        'Content-Type: image/png\r\n' +
        '\r\n'
    ),
    fileContent,
    Buffer.from(`\r\n--${boundary}--\r\n`)
]);

const instance = autocannon({
    url: 'http://localhost:3000/upload',
    method: 'POST',
    connections: 10,
    duration: 60,
    headers: {
        'Content-Type': `multipart/form-data; boundary=${boundary}`
    },
    body: body
}, (err, result) => {
    if (err) {
        console.error('Error running autocannon:', err);
    } else {
        console.log('Test completed:', result);
    }
});

autocannon.track(instance, { renderProgressBar: true });   ****

In the autocannon-test.js file, you'll see several key components:

File and Boundary Setup: The boundary and filePath variables define the multipart form boundary and the path to the image file you'll upload. The fileContent reads the image file into a buffer.
HTTP Request Configuration: The instance object specifies the test parameters. The url is where the API is running, method is POST, and connections and duration define the load you want to simulate.
Headers and Body: The headers and body fields in the instance object specify the HTTP headers and the request's body. The body is a buffer that includes the image file and the multipart form boundary.
Running and Tracking: The autocannon() function runs the test and autocannon.track(instance, { renderProgressBar: true }) tracks the progress.

After running node autocannon-test.js, you'll see a comprehensive output showing your API's performance.

The average latency is 1526.9 ms, and the API can manage an average of 6.44 requests per second. The "2xx" count of 386 confirms that most requests were successful, indicating a stable API under load.

The latency and throughput metrics offer a nuanced view of your API's behavior. For instance, 50% of the requests have a latency less than or equal to 1450 ms, and 99% are under 3765 ms. These figures help you identify bottlenecks and make informed decisions for further optimizations, ensuring that your API can handle real-world usage patterns effectively.

Advanced Caching with LRU Cache

To further improve the performance of the Image Recognition API, we’ll add some advanced optimization techniques. One of those techniques is the Least Recently Used (LRU) Caching. LRU caching keeps recently used data closer (in memory), so when the same data is requested again, the system doesn't have to go through the lengthy process of fetching it from the source.

For this sample codebase, we’ll use a basic implementation of LRU caching:



const options = {
    max: 500, // The maximum number of items to store in the cache
    maxAge: 1000 * 60 * 30 // Items expire after 30 minutes
};
const classificationCache = new LRUCache(options);

// ... (other parts of the code)

const imageId = req.file.filename;
const cachedResult = classificationCache.get(imageId);
if (cachedResult) {
    return res.json({ predictions: cachedResult });
}

// ... (other parts of the code)

classificationCache.set(imageId, predictions);

In the code above, we initialize an LRU cache with a maximum of 500 items and a 30-minute expiration time for each item. When an image is uploaded for classification, the API first checks if the result is already in the cache (classificationCache.get(imageId)). If it is, the cached result is returned, saving computational time. If not, the image is processed, and the result is stored in the cache (classificationCache.set(imageId, predictions)).

The LRU cache is a performance booster for this image recognition API, particularly useful when dealing with repetitive image classifications. Imagine a scenario where the same images are uploaded and classified multiple times. Without caching, the API would redundantly perform the same computationally expensive TensorFlow operations for each request, leading to higher latency and increased CPU load.

By implementing LRU caching, we store the classification results of recently processed images. When the API receives a request to classify an image it has seen recently, it can simply retrieve the result from the cache instead of re-running the classification. This significantly reduces the API's response time and lightens the load on the CPU, making the system more efficient and scalable.

Conclusion

In large Node.js applications, clustering is an indispensable tool for harnessing the full power of your machine's CPU cores. It's not just about making your application faster; it's about making it resilient and capable of handling an increasing number of requests without choking. By distributing the load across multiple worker processes, you can ensure your application remains responsive even under heavy stress.

This article explored the essential techniques for optimizing a Node.js API. We delved into clustering to improve performance, used Autocannon for load testing, and implemented LRU caching to reduce redundant operations.

Resources

For those eager to dive deeper into the topics covered, here are some additional resources that can further your understanding and skills:

Node.js Clustering:
- Node.js Documentation on Cluster Module
- Scaling Node.js Applications
Load Testing with Autocannon:
- Autocannon GitHub Repository
- Understanding Load Testing Metrics
LRU Caching:
- LRU Cache Explained
- LRU Cache Implementation in JavaScript
Logging and Monitoring:
- Winston: A Logging Library for Node.js
- Monitoring Node.js Applications
TensorFlow.js and MobileNet:
- TensorFlow.js Documentation
- MobileNet: Efficient On-Device Vision Applications

Automating Code Review in Node.js with DeepSource

Samuel Umoren — Sun, 08 Oct 2023 11:55:40 +0000

In the fast-paced world of Node.js REST API development, maintaining high code quality often becomes a challenging task. Manual code reviews, although essential, can be time-consuming and might not catch every issue. This is where automated code review tools like DeepSource come into play.

DeepSource not only automates the code review process but also integrates seamlessly with your development workflow. In this article, we'll walk you through setting up DeepSource for a Node.js REST API project, specifically focusing on a fintech API. We'll cover everything from connecting your project to a version control system to configuring DeepSource to run automated code reviews and setting up alerts for new issues.

By the end of this guide, you'll have a streamlined code review process that elevates the quality of your codebase, making it more maintainable, robust, and secure.

Prerequisites

Before diving into the step-by-step guide, make sure you have the following prerequisites in place:

Node.js and npm: Ensure you've installed Node.js and npm on your system. You can download them from here.
DeepSource Account: Sign up for a DeepSource account here. You'll use this to run automated code reviews.

Getting Started

To get started, clone the repo of the Fintech API project from GitHub, install the dependencies, and switch to the starter branch:

git clone -b starter https://github.com/Umoren/fintech-api.git
cd fintech-api
npm install
git checkout starter

Run the project:

npm run dev

When this runs, your API will be running on http://localhost:5000/api. You can explore the API endpoints from the documentation at http://localhost:5000/api/docs.

DeepSource Integration

Head over to DeepSource and sign in with your GitHub account.
Activate DeepSource for your cloned repository.

Create a deepsource.toml file in your project and add these lines of code to set the JavaScript analyzer:

version = 1

[[analyzers]]
name = "javascript"

  [analyzers.meta]
  environment = ["nodejs"]

When this is done, commit and push the code.

DeepSource will automatically analyze your code on every push, helping you maintain high code quality.

With these steps, you've set up a Node.js REST API project and integrated it with DeepSource for automated code reviews. Next, we'll delve into how to make the most out of DeepSource's features to streamline your development workflow.

Prioritizing and Reviewing Issues with DeepSource

After integrating DeepSource, the tool scans your entire codebase and flags various issues that could range from code smells and anti-patterns to outright security vulnerabilities. One of the first things you'll notice is how DeepSource categorizes these issues based on their severity. This allows you to focus on the most critical issues first, ensuring that your codebase remains robust and secure.

DeepSource also offers the functionality to group similar issues. This feature is particularly useful when dealing with large codebases where similar issues might be scattered across different files. It streamlines the process of tackling these issues in batches rather than one at a time.

In a team setting, DeepSource allows for the assignment of issues to specific team members. This not only ensures accountability but also speeds up the review process, making it efficient and effective.

Automating Issue Creation for Immediate Action

One of the standout features of DeepSource is its ability to automate the issue creation process. This is particularly useful for teams that want to immediately act upon the issues flagged during the code review. By automating this process, you ensure that each issue receives the attention it deserves without manual intervention.

Understanding Severity Categories in DeepSource

DeepSource categorizes issues into four main severity levels: Critical, High, Medium, and Low. These categories help teams prioritize which issues need immediate attention and which can be scheduled for later.

Critical Severity: These are issues that pose a direct threat to the application's security or functionality. They require immediate attention and should be resolved as soon as possible to prevent potential breaches or system failures.
High Severity: While not immediately dangerous, high-severity issues can have a significant impact on code quality and performance. These should be addressed promptly to maintain a robust codebase.
Medium Severity: These issues are less urgent but still important for long-term code quality and maintainability. They often include things like code smells or minor performance bottlenecks.
Low Severity: These are mostly cosmetic issues that don't impact the functionality or security of the application. However, resolving them can improve code readability and maintainability.

Let’s illustrate the automating issue creation process by working on the “Detected usage of any type” issue. When you click on that issue, you’ll see this screen:

This is a critical issue. Click on the Create this issue on GitHub button.

Automating issue creation is an excellent way for you to ensure that critical issues are promptly addressed, thereby maintaining the codebase's integrity and quality.

Integrating DeepSource into Your Node.js REST API Development Workflow

DeepSource offers a Test Coverage analyzer that can be easily integrated into your Node.js REST API project. To set this up, you'll need to update the deepsource.toml configuration file to look like this:

  version = 1

  [[analyzers]]
  name = "javascript"

    [analyzers.meta]
    environment = ["nodejs"]

  [[analyzers]]
  name = "test-coverage"
  enabled = true

Setting Up Code Coverage with DeepSource

DeepSource only supports cobertura for code coverage reporting. To set this up in our project, update the scripts field of your package.json with this:

"coverage": "nyc --reporter=cobertura npm test"

Run code coverage:

npm run coverage

This will create a coverage/cobertura-coverage.xml file at the root of your project.

Navigate to your Deepsource dashboard, head to Settings and copy your repo DSN

Set the DEEPSOURCE_DSN env variable as a system variable

export DEEPSOURCE_DSN=<DSN URL>

Next, install the DeepSource CLI using this command:

curl https://deepsource.io/cli | sh

Run the report coverage command:

./bin/deepsource report --analyzer test-coverage --key javascript --value-file ./coverage/cobertura-coverage.xml

If it runs successfully, you should see this on your terminal:

➜  fintech-api git:(master) ✗ ./bin/deepsource report --analyzer test-coverage --key javascript --value-file ./coverage/cobertura-coverage.xml
DeepSource | Artifact published successfully

Analyzer  test-coverage
Key       javascript
Message   Artifact successfully uploaded for repository fintech-api on commit 330b1f913a8ec2ff0a81594d1eacacdf01d4b3e1.

Navigate to the Metrics tab on your DeepSource dashboard and you should see coverage report graphs generated like this:

Condition Coverage: This metric is particularly useful for understanding how well your code handles different conditional logic paths.

Composite Coverage: This provides a more holistic view of how well your code is tested.

Branch Coverage: This measures the code coverage, including the various branches in your code like if, else, and switch statements.

Line Coverage: This is the code coverage excluding the branches. It simply tells you what percentage of your lines of code are executed during tests.

Documentation Coverage: This unique metric tracks the extent to which your application code is documented. It's a good indicator of code maintainability.

External Dependencies: This shows the total number of 3rd-party dependencies used in your repository. It is a useful metric for understanding the complexity and potential security risks in your project.

Configuring CI/CD Pipeline with GitHub Actions

Let’s set up a CI/CD pipeline with GitHub Actions so that whenever you make a push action, a coverage report will be generated. Create a .github/workflows/deepsource-analysis.yml file and add these lines of code:

name: DeepSource and Test Coverage
on:
  push:
    branches:
      - master
  pull_request:

jobs:
  deepsource:
    runs-on: ubuntu-latest
    env:
        DEEPSOURCE_DSN: ${{ secrets.DEEPSOURCE_DSN }}
    steps:
    - name: Checkout Code
      uses: actions/checkout@v2

    - name: Setup Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '16'

    - name: Install Dependencies
      run: npm install

    # Run your tests and generate coverage file here
    - name: Run Tests and Generate Coverage
      run: npm run coverage

    # Report test-coverage to DeepSource using CLI
    - name: Report test-coverage to DeepSource
      run: |
        # Install the CLI
        curl https://deepsource.io/cli | sh

        # Send the report to DeepSource
        ./bin/deepsource report --analyzer test-coverage --key javascript --value-file ./coverage/cobertura-coverage.xml

Ensure you add your DSN to the GitHub Repository secrets.

This workflow will run DeepSource analysis and report back the results. If any issues are found, they can be automatically converted into GitHub issues using the methods described in the previous section.

Github Action for test coverage

Conclusion

Automating code reviews and integrating quality checks into your development workflow are not just best practices; they're necessities for scaling software projects efficiently. DeepSource serves as an invaluable tool for this, offering a comprehensive suite of metrics that go beyond simple lint checks. From identifying anti-patterns to calculating various code coverage metrics, DeepSource provides a 360-degree view of your code quality.

In this article, we've walked through the process of setting up DeepSource for a Node.js REST API project in the fintech space. We've demonstrated how to automate the creation of GitHub issues based on code analysis, and how to integrate DeepSource into your CI/CD pipeline using GitHub Actions. The aim is to make the code review process as frictionless as possible, allowing you to focus more on feature development and less on code maintenance.

By adopting tools like DeepSource and incorporating them into your development workflow, you're not just writing better code; you're creating a more sustainable, manageable, and scalable software architecture. And that's a win for everyone involved—developers, managers, and stakeholders alike.

Improve Data Fetching in Next.js Applications through SWR

Samuel Umoren — Fri, 19 May 2023 19:50:04 +0000

This article was originally published here

Fetching and rendering data from APIs is one of the core essentials of front-end development. The basic way of fetching data in JavaScript is to use local fetch or a third-party library like axios, input the right HTTP method for the request, including headers, parse the result in JSON, and render it to the DOM. This wouldn’t work well with modern web applications because of their architectures' complexity. Users will only use a web app that’s fast, reliable, and responsive; that means if they request a resource, they want it delivered in <3s. As a result, developers need to use tools or libraries that improve the data-fetching experience in their applications.

In React, data fetching is a side effect, and it provides the useEffect Hook for performing this side effect. Data fetching in React typically would look like this:



function Example() {
  const [data, setData] = useState(null);

  useEffect(() => {
    async function fetchData() {
      const response = await fetch('https://api.example.com/data');
      const result = await response.json();
      setData(result);
    }

    fetchData();
  }, []); // The empty array `[]` ensures the effect only runs once on mount and unmount.

  return (
    <div>
      {data ? (
        <div>{JSON.stringify(data)}</div>
      ) : (
        <div>Loading...</div>
      )}
    </div>
  );
}

However, when building server-rendered applications, Nextjs is preferred. Data fetching in Next.js can be done using different methods, depending on the desired rendering strategy, that is:

When you want to fetch data at build time and generate static HTML pages, Nextjs provides getStaticProps for that.
When you have dynamic routes and want to generate static HTML pages for each route, use getStaticPaths.
When you need to fetch data on each request, providing a server-rendered experience, use getServerSideProps
You can still use client-side data fetching when you don't need to pre-render the data or when you want to fetch data that depends on user interactions.

It is common to see Next.js applications that make use of client-side data fetching. The challenge with this technique of data fetching is that you have to render data based on user interaction, which can lead to several issues if not handled properly.

This is why Vercel created SWR (stale-while-revalidate). Without a solution like SWR, you’re likely to face difficulties managing caching, ensuring data synchronization, handling errors, and providing real-time updates. Additionally, handling loading states can become cumbersome, and you might end up with a lot of boilerplate code just for fetching, caching, and managing the data as the codebase grows. SWR addresses these challenges by providing built-in caching, automatic cache revalidation, error retries, support for real-time updates, and a Hooks-based API that simplifies data management.

In this article, I’ll introduce you to how SWR works, its key concepts, and how to use it for efficient data fetching in client-side Next.js applications.

How SWR works

To understand how SWR works, you need to be conversant with these key concepts.

Caching: Caching is like storing food in the fridge. It's a way to save data so it can be quickly accessed later without needing to fetch it from the source (server) every time. This speeds up the process of retrieving data and reduces the load on the server.
Revalidation: Revalidation is like checking if the food in the fridge is still good or needs replacing with a fresh meal. In the context of data fetching, revalidation means checking if the cached data is still valid or if it needs to be updated with new data from the server. With SWR, this process happens automatically in the background, ensuring your data is always up-to-date.
Stale-While-Revalidate: Imagine you have a fridge with food inside. When you're hungry, you grab something from the fridge (cached data). At the same time, a friend starts cooking a fresh meal (fetching new data). You eat the food from the fridge while waiting for the fresh meal to be ready. Once done, the fridge is restocked with fresh food (cache revalidation).

SWR is a data fetching library that implements the Stale-While-Revalidate (SWR) strategy. It fetches, caches, and revalidates data in the background to provide an efficient and seamless user experience.

What we’ll be building

To appreciate SWR, you need to build something with it. In this tutorial, we’ll build a product store with Nextjs. While building this demo app, you’ll get to learn the following:

Fetching data using the useSWR hook
Handling Errors and Loading States
Implementing optimistic UI updates with SWR
Implementing infinite scrolling in Next.js with SWR

Pre-requisites

You’ll need the following:

Nodejs ≥v16
Code editor (preferably VS code)
Code terminal
Package manager (yarn preferably)
Knowledge of JavaScript and Reactjs

The complete code is on Github, and the demo app is here.

Getting Started

Run this command on your terminal to create a nextjs project.



npx create-next-app product-store; cd product-store; code .

The product store will have a /product parent route with these sub-routes: /product/listing and /product/detail. Run this command from the root directory on your terminal to create these page routes.



cd pages; mkdir product; cd product; touch [id].js upload.js

Go back to the root directory and create these UI components



mkdir components; cd components; touch ProductList.jsx ProductCard.jsx ErrorMessage.jsx LoadingIndicator.jsx ProductUploadForm.jsx

Navigate back to the root director and install these packages:



yarn add swr tailwindcss postcss autoprefixer react-infinite-scroll-component;

See how to configure tailwindcss here.

Fetching, Displaying, and Updating Data with SWR

Firstly, let’s create a custom React hook that’ll fetch data from the Products fakeapi endpoint using SWR. Add these lines of code to hooks/useFetch.js



import useSWR from 'swr';

const fetcher = async (url) => {
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error('An error occurred while fetching the data.');
  }
  return response.json();
};

const useFetch = (path) => {
  const { data, error } = useSWR(`https://fakestoreapi.com/${path}`, fetcher);

  const isLoading = !data && !error;

  return { data, error, isLoading };
};

export default useFetch;

Here, we define a custom React hook, useFetch, which leverages the useSWR hook for data fetching. It takes a path as input and constructs a full URL to fetch data from the Fake Store API. The fetcher function handles making the request and error checking. useFetch returns an object with the fetched data, potential errors, and a loading state.

Now let’s display the product list.

Navigate to components/ProductCard and add these lines of code.



import Link from 'next/link';
import Image from 'next/image';

const ProductCard = ({ product }) => {
    return (
        <div className="bg-white rounded-lg shadow-md p-4">
            <Image
                src={product.image}
                alt={product.title}
                width={640}
                height={640}
                layout="responsive"
            />
            <h3 className="text-lg font-semibold mb-2">{product.title}</h3>
            <p className="text-gray-600 mb-2">{product.category}</p>
            <div className="flex justify-between items-center">
                <span className="text-lg font-bold">${product.price}</span>
                <Link
                    href={`/product/${product.id}`}
                    className="text-blue-600 hover:text-blue-800"
                >
                    View Details
                </Link>
            </div>
        </div>
    );
};

export default ProductCard;

This ProductCard component renders a single product card. The card includes an image, product title, category, price, and a link to the product details page. The image is set using Next.js' Image component, which automatically optimizes the image for performance. The link to the product details page is wrapped in Next.js' Link component for client-side navigation.

Navigate to component/ProductList.jsx and add these lines of code.



import useFetch from './hooks/useFetch';
import ProductCard from './ProductCard';

const ProductList = () => {
  const { data: products, error, isLoading } = useFetch('products');

  if (isLoading) {
    return <div>Loading...</div>;
  }

  if (error) {
    return <div>Error: {error.message}</div>;
  }

  return (
    <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-4">
      {products.map((product) => (
        <ProductCard key={product.id} product={product} />
      ))}
    </div>
  );
};

export default ProductList;

Here, we define the ProductList component, which fetches and displays a list of products. It uses the useFetch custom hook to fetch product data and ProductCard to render each product. The component handles loading and error states and displays the products in a grid format.

Update pages/index.js with these lines of code.



import ProductList from "../components/ProductList"

export default function Home() {
  return (
    <div className='max-w-screen-xl m-auto'>
      <ProductList />
    </div>
  )
}

Run the dev server with this command yarn dev, it should start the server at [http://localhost:3000](http://localhost:3000), and you should see something like this on your browser.

Great! We’ve been able to display the products. Let’s now implement the view for a single product. Update pages/product/[id].js with these lines of code. Here we’ll use useSWR directly.



import useSWR from "swr";
import Image from "next/image";

const fetcher = async (url) => {
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error("An error occurred while fetching the data.");
  }
  return response.json();
};

const ProductDetails = ({ id }) => {
  const {
    data: product,
    error,
    isLoading,
  } = useSWR(`https://fakestoreapi.com/products/${id}`, fetcher);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  if (error) {
    return <div>Error: {error.message}</div>;
  }

  return (
    <div className="max-w-2xl mx-auto min-h-screen py-16">
      <h1 className="text-2xl font-semibold mb-4">{product.title}</h1>
      <div className="md:flex space-x-8">
        <div>
          <Image
            src={product.image}
            alt={product.title}
            width={640}
            height={640}
            layout="responsive"
          />
        </div>
        <div>
          <p className="text-gray-100 mb-2">{product.category}</p>
          <p className="text-xl font-bold mb-4">${product.price}</p>
          <p>{product.description}</p>
        </div>
      </div>
    </div>
  );
};

export async function getServerSideProps(context) {
  const { id } = context.query;
  return {
    props: {
      id,
    },
  };
}
export default ProductDetails;

This component handles loading and error states and renders product information. The getServerSideProps function retrieves the product ID from the query params, which is passed as a prop to the component for server-side rendering. A single product detail look like this:

Handling Errors and Loading States

SWR provides an ErrorBoundary component that can be used to catch errors that occur within its child components. This component can be used to display a fallback UI when an error occurs, such as an error message or a reload button. The Error boundary provides a way to separate an application's data-fetching and data-rendering concerns. When an error occurs during data fetching, SWR Error Boundary can intercept and handle it gracefully. This way, error messages can be displayed to the user without breaking the entire application.



import useSWR from 'swr';
import { SWRConfig } from 'swr';
import { ErrorBoundary } from 'react-error-boundary';

function App() {
  const { data, error } = useSWR('/api/data');

  if (error) {
    throw new Error('Failed to load data');
  }

  return <div>{data}</div>;
}

function AppWrapper() {
  return (
    <ErrorBoundary fallback={<div>Failed to load data</div>}>
      <SWRConfig value={{}}>
        <App />
      </SWRConfig>
    </ErrorBoundary>
  );
}

In this code snippet, if an error occurs during the fetching process, it throws an error, which is caught by the ErrorBoundary component. The fallback prop of the ErrorBoundary component is a UI to be displayed when an error occurs. In this case, it displays a simple error message.

Implementing loading indicators for a better user experience

Let’s go back to building our app. Go to component/LoadingIndicator.jsx and add these lines of code.



const LoadingIndicator = () => {
  return (
    <div className="flex justify-center items-center">
      <div className="animate-spin rounded-full h-10 w-10 border-b-2 border-blue-500"></div>
    </div>
  );
};

export default LoadingIndicator;

This LoadingIndicator component will be used to represent the loading states while fetching data. Head to components/ProductList.jsx and modify the code to this:



if (isLoading) {
    return <LoadingIndicator />;
  }

Let’s also create an ErrorMessage component that renders an error message when there are data fetching issues. Head to components/ErrorMessage.jsx:



const ErrorMessage = ({ message }) => {
  return (
    <div
      className="bg-red-100 border border-red-400 text-red-700 px-4 py-3 rounded relative"
      role="alert"
    >
      <strong className="font-bold">Error: </strong>
      <span className="block sm:inline">{message}</span>
    </div>
  );
};

export default ErrorMessage;

Update component/ProductList.jsx like this:



if (error) {
    return <ErrorMessage message={error.message} />;
  }

Optimistic UI updates

When you POST a message in messaging apps, it is immediately displayed in the chat even if there’s no network connection. That’s the idea of optimistic UI updates, and this can be implemented with SWR. With SWR, you can update the local cache of the data in response to user actions while at the same time sending the update request to the server. If the server responds with an error, the local cache can be reverted back to its previous state. This way, the user gets an immediate response while still having the assurance that the data is being updated on the server.

To implement optimistic UI updates with SWR, you need to use the mutate function provided by the hook. The mutate function allows you to update the cache of the data without making a request to the server. You can pass an updater function to the mutate function, which receives the current data as an argument, and returns the updated data. The mutate function updates the local cache with the new data, and triggers a re-render of the component.

Once the update request is sent to the server, you can use the mutate function again to update the cache with the response from the server. If the server responds with an error, you can use the mutate function with the previous data to revert the cache to its previous state.

This is how to implement optimistic UI updates in our app while uploading a new product.

pages/product/upload.js



import ProductUploadForm from "../../components/ProductUploadForm";
import { mutate } from "swr";
import axios from "axios";
import ErrorMessage from "../../components/ErrorMessage";

const upload = () => {
  const onUpload = async (newProduct) => {
    // Optimistically update the local data
    mutate(
      "/products",
      (products) => {
        if (Array.isArray(products)) {
          return [newProduct, ...products];
        }
        return [newProduct];
      },
      false
    );

    // Make the API call to create the product
    try {
      await axios.post("https://fakestoreapi.com/products", newProduct);

      // Revalidate the data after successful upload
      mutate("/products");
    } catch (error) {
      // Handle any errors
      <ErrorMessage message={error} />;
    }
  };

  return (
    <div>
      <h1 className="mb-4 text-2xl  p-3 font-extrabold text-gray-900 dark:text-white md:text-3xl lg:text-4xl">
        {" "}
        Upload Product
      </h1>
      <ProductUploadForm onUpload={onUpload} />
    </div>
  );
};

export default upload;

Check out the ProductUploadForm.jsx here.

Using SWR for paginated data fetching

Paginated data fetching is one of the use cases of SWR. If we're fetching a large amount of data, breaking it down into smaller chunks called pages improves performance and reduces the amount of data transferred over the network.

The useSWRInfinite hook implements pagination with SWR. It takes two arguments: getKey and fetcher.

The getKey function returns a unique key for each page based on the page index and previous page data. Returning null for an empty page prevents unnecessary requests.

The fetcher function fetches data for a given key using an HTTP client, like axios or fetch.

Once we set up the useSWRInfinite hook, we can use the data and error properties to render the data and handle errors, respectively. We can also use the isLoading property to show a loading indicator while data is being fetched.

To implement pagination, we use the size and setSize properties to control the number of pages to fetch. Incrementing the size value in a loadMore function that's called when the user reaches the end of the current page enables pagination. We also use the hasNextPage property to determine if more data can be fetched.

Implementing infinite scrolling in Next.js with SWR

Update the useFetch hook with these lines of code:



import useSWRInfinite from "swr/infinite";

const fetcher = async (url) => {
    const response = await fetch(url);
    if (!response.ok) {
        throw new Error('An error occurred while fetching the data.');
    }
    return await response.json();
};

const useFetch = (path, limit) => {
    const getKey = (pageIndex, previousPageData) => {
        if (previousPageData && !previousPageData.length) return null;
        const pageNumber = pageIndex + 1;
        return `https://fakestoreapi.com/${path}?_page=${pageNumber}&_limit=${limit}`;
    };

    const { data, error, size, setSize } = useSWRInfinite(getKey, fetcher);

    const loadMore = () => setSize(size + 1);

    return {
        data: data ? data.flat() : [],
        isLoading: !error && !data,
        isError: error,
        loadMore,
        hasNextPage: data && data[data.length - 1]?.length === limit,
    };
};

export default useFetch;

In this code snippet is a custom hook that uses the SWR library to fetch paginated data. It takes two arguments, the path, and limit . The getKey function returns a unique key for each page based on the page index and previous page data. The hook uses the useSWRInfinite function to fetch data for a given key using an HTTP client. It returns an object with data, isLoading, isError , loadMore , and hasNextPage properties. The data property is an array of fetched data, while isLoading is a boolean value that indicates if the data is being fetched. isError is a boolean value that indicates if an error occurred while fetching data. loadMore is a function that increments the number of pages to fetch, and hasNextPage is a boolean value that indicates if there's more data to be fetched. The fetcher function is called to fetch data from a given URL, and it throws an error if the response is not successful.

The app should work properly with infinite scrolling now:

Wrapping up…

SWR is a powerful tool for efficient data fetching in client-side Next.js applications. Its built-in caching, automatic cache revalidation, error retries, support for real-time updates, and Hooks-based API make data management simpler and more streamlined. By using SWR, developers can improve the data-fetching experience for their users and ensure their applications are fast, reliable, and responsive. With Next.js, there are different methods of data fetching, depending on the desired rendering strategy. While client-side data fetching is a popular option, it can lead to several issues if not handled properly. SWR addresses these challenges and provides a more efficient way of managing data.

Overall, SWR is a great tool for building high-performance, scalable, and reliable web applications with React and Next.js.

Resources

SWR Official Documentation: https://swr.vercel.app/docs/getting-started
Next.js Documentation on Data Fetching:

* Official guide on fetching data with Next.js: [**https://nextjs.org/docs/basic-features/data-fetching**](https://nextjs.org/docs/basic-features/data-fetching)

An Introduction To SWR: React Hooks For Remote Data Fetching:

* [**https://www.smashingmagazine.com/2020/06/introduction-swr-react-hooks-remote-data-fetching/**](https://www.smashingmagazine.com/2020/06/introduction-swr-react-hooks-remote-data-fetching/)

Data fetching in React with SWR

https://dev.to/ibrahimraimi/data-fetching-in-react-with-swr-5gb0
GitHub Discussions and Conversations: https://github.com/vercel/swr/discussions](https://github.com/vercel/swr/discussions)

Backstage.io: The Ultimate Developer Portal for Enhancing Team Efficiency and User Satisfaction.

Samuel Umoren — Mon, 15 May 2023 16:32:15 +0000

Developers are often the ultimate multitaskers. Picture a platform engineer's typical busy day: they might switch from writing UI code to modifying an API's authentication process, creating an Infrastructure as Code template, implementing continuous integration on a new project, working on a data pipeline, and updating documentation. Each task has its unique requirements, UIs, technologies, languages, or processes.

This might sound thrilling for a sprinting stallion (yes, that's a nod to our friends at Pied Piper), but it's also a recipe for errors and potential chaos within an organization. Imagine being a chef trying to whip up several meal courses simultaneously. Pots are boiling, ingredients are strewn about, and multiple recipes are in progress. It's a high-energy environment, but it's also a chaotic one. The journey from a brilliant idea to polished software can feel the same. So, wouldn't it be great if there was a sous chef to bring some order to this chaos? That’s where Backstage comes in.

Backstage.io is an open platform designed for building developer portals developed by Spotify Engineering.

Understanding Backstage.io: A Powerful Developer Tool

A developer portal acts like a Swiss army knife for developers. It streamlines the development process and fosters a community of developers. Spotify Engineering has leveraged this concept and introduced Backstage, an open platform designed for building developer portals.

Consider the developer portal as a centralized hub for all services, software components, data, tools, and documentation within an organization. It simplifies navigation through the tech landscape and makes workflows more efficient.

In essence, Backstage puts everything in one place. It simplifies tool management, streamlines workflows, and saves precious time. The goal? To make software development more efficient, so developers can focus on what they do best: crafting great software.

This blog post will delve into how this handy tool can turbocharge your team's efficiency and make your users as thrilled as a kid in a candy store.

How Backstage.io Boosts Software Development Efficiency Through Centralization, Automation, and Extensibility

Backstage.io operates on a unique principle of centralizing all services, making them easily navigable and manageable for developers. The platform achieves this through its Software Catalog, a comprehensive list of all software components, resources, and tools available within an organization. You can think of the Catalog as an inventory of your organization's software.

In more traditional setups, you most likely have to switch between multiple platforms and interfaces to access and manage different services. Backstage.io eliminates this by providing a unified interface that consolidates all these services.

The Service Catalog in Backstage.io, offering a comprehensive overview of all services within an organization.

With Backstage.io, developers in your team can effortlessly locate and access any service they need within the Service Catalog. This catalog provides key information about each service, such as its owner, lifecycle status, and recent updates, offering an overview of all the services at a glance.

One aspect of centralization in Backstage.io is the TechDocs feature. TechDocs allows developers to create, maintain, find, and view documentation all within Backstage.io itself. This means that alongside services, the corresponding documentation is also available in the same place, saving developers from searching in different locations.

You can run your TechDocs separately from the organization dashboard.

Backstage.io's TechDocs feature, centralizing the creation and viewing of documentation.

Developers can view API documentation using this catalog plugin: @backstage/plugin-api-docs like this:

Backstage.io's API documentation, offering detailed information about each API's structure and capabilities.

Backstage.io also brings impressive automation capabilities to the table. It integrates with your existing CI/CD pipelines and providers (like Circle CI, GitHub Actions, and Jenkins), automatically updating each component's status in real-time. Moreover, it can automate routine tasks that developers often find themselves repeating. For instance, it can automatically set up new microservices or initiate test runs, freeing developers to focus on more critical tasks.

Lastly, the plugin architecture of Backstage.io allows for easy extensibility and customization. Need to add new functionality? Simply write a plugin and add it to your Backstage instance. Each plugin gets its page in Backstage, making it easy for developers to find and use the necessary tools without setting up new infrastructure.

Enhancing User Satisfaction with Backstage.io: Streamlining Workflows for Rapid Software Deployments

User satisfaction extends beyond the end product; it encompasses the entire user journey. The efficiency and effectiveness of the development process shape a significant part of this journey. This is precisely where Backstage.io makes its mark.

A Streamlined Developer Experience

Backstage.io offers a unified and streamlined developer experience where all services, libraries, APIs, and data pipelines are accessed from a single platform. This centralization eliminates the chaos of managing multiple tools, reduces the risk of miscommunication, and allows for a more cohesive approach to software development.

Rapid Iterations and Deployments

With the accelerated development process Backstage.io enables, your team can roll out new features, enhancements, or fixes more quickly. This rapid iteration capability is particularly valuable in today's fast-paced digital world, where users expect continuous improvement and timely responses to their feedback.

Enhanced Communication and Collaboration

Backstage.io brings tools and services together and fosters better communication and collaboration among developers. Developers can easily share, reuse, and collaborate on different project components with features like the Service Catalog and the Software Templates. This, in turn, contributes to more robust and reliable software, enhancing user satisfaction.

The interface for creating new services in Backstage.io, simplifying the process for developers.

Reliable and Error-Free Software

The unified view of Backstage.io allows for better tracking and monitoring of the entire software development lifecycle. It's easier to identify potential bottlenecks, catch bugs earlier, and ensure that the software being delivered is reliable and error-free. This results in a smoother user experience and increased user satisfaction. Backstage.io helps in identifying potential bottlenecks, catching bugs earlier, and ensuring the delivery of reliable and error-free software through several features:

Service Catalog: Such a comprehensive overview makes it easier to spot services that are facing issues or not performing as expected.
Tech Insights: Backstage.io includes features like Tech Radar, which help visualize, understand, and improve how software is built in the organization. It can be used to track metrics and set up checks or balances to ensure that certain standards or practices are being followed. This helps catch any potential issues early in the software development lifecycle.

Backstage.io's Tech Radar, visualizing and tracking how software is developed within the organization.
Plugins: Backstage.io supports various plugins that integrate with various tools for monitoring, logging, error tracking, continuous integration, and more. ********Some of these plugins include:
- CI/CD Plugins: Backstage provides plugins for popular CI/CD tools like Jenkins, CircleCI, GitHub Actions, and Travis CI, among others.
- Monitoring and Observability Plugins: Plugins like Grafana, Prometheus, and DataDog allow you to integrate your monitoring and observability tools with Backstage.
- Error Tracking Plugins: Backstage supports plugins for error tracking and monitoring tools like Sentry, Rollbar, and Honeycomb.
- Code Quality and Security Plugins: Plugins like SonarQube, Snyk, and Lighthouse provide insights into code quality, security vulnerabilities, and performance issues.
- GitHub Insights Plugin: This plugin provides insights into your GitHub repositories, including statistics on pull requests, issues, and contributors.

In essence, Backstage.io does more than simplify the developer's workflow—it also significantly impacts user satisfaction. By enabling a more streamlined, rapid, and reliable development process, it ensures that your users receive the best experience possible.

Conclusion

From my exploratory journey into the world of Backstage, it's clear that this platform has a lot to offer, even though I have yet to use it in a team setting. It has been designed thoughtfully to address the pain points that developers often encounter, particularly those working in large teams or on complex projects.

Backstage streamlines workflows, centralize disparate tools and allows for easy extensibility - aspects that are crucial for efficiency in software development. These benefits simplify the developers' tasks and improve the overall user experience by enabling rapid iterations, reliable software, and efficient collaboration among teams.

Let's consider how some notable companies have put Backstage into practice:

Netflix uses Backstage as the front door to a unified experience, connecting their internal platform products across important workflows with integrated knowledge and support.
For American Airlines, Backstage is a central hub where developers develop and maintain applications.
Voi has implemented Backstage as a Developer portal, the primary gateway to their infrastructure, documentation, and internal tooling.
Fiverr has leveraged Backstage to unify separate tools developers use, like monitoring and dead letter queues management, into a single platform.
HelloFresh has deployed Backstage as their Developer portal, used by over 500+ developers worldwide.
SoundCloud uses the Developer portal to manage a catalog of people, services, documentation, feature toggles, escalation policies, and more.
Next has utilized Backstage to improve the developer's experience by centralizing their services catalog and identifying microservices' ownership.

Disclaimer: The list of Backstage adopters and their use cases has been sourced from the official Backstage adopters list. I have no personal affiliations with these organizations; these examples were selected purely based on their relevance and potential interest to readers.

In conclusion, Backstage is a powerful tool that brings order to the often chaotic software development process. By centralizing services, automating workflows, and offering easy extensibility, Backstage paves the way for a smooth, efficient, and more manageable journey - akin to turning a rugged trail into a superhighway.

Resources

If you want to delve deeper into Backstage.io, here are some useful resources:

Backstage.io Documentation: This is the official documentation of Backstage.io. It provides a comprehensive guide on how to get started, as well as details on various features and plugins. Link
Building developer portals with Backstage: This is an excellent tutorial video. It explains the basic concepts and guides you through setting up a Backstage.io instance. Link
Backstage.io GitHub Repository: This repository contains the source code of Backstage.io. It is a useful resource if you want to contribute or understand how the platform works under the hood. Link
Building a Plugin in Backstage.io: This tutorial offers an in-depth guide on how to build a custom plugin in Backstage.io. Link

Step-by-Step Guide to Hosting and Deploying a React Static Website on AWS

Samuel Umoren — Sat, 29 Apr 2023 22:32:43 +0000

Throughout my years as a software developer specializing in frontend technologies, I've admired the simplicity of deploying static HTML, CSS, and JavaScript files to cloud hosting providers like Netlify, Vercel, or GitHub Pages. These platforms serve as Content Delivery Networks (CDNs) and automatically generate live URLs for hosted websites. Previously, I would use shared hosting or rent a Virtual Private Server (VPS) from providers like GoDaddy. Then, I would upload static files to the hosting server using an FTP client like Filezilla. Additionally, I needed to register a domain, or my website URL would default to the hosting server's IP address.

Some organizations utilize cloud services like Amazon S3 or Azure Blob storage to store and serve files. However, this approach requires additional configuration, such as proper access permissions, MIME types, and cache headers.

In a previous article on AWS CloudFormation, I suggested creating a static website hosted on Amazon S3 and distributed using Amazon CloudFront, using CloudFormation to provision and configure the S3 bucket and CloudFront distribution as a practice exercise.

Building on that idea, I've developed this tutorial to guide you through hosting and deploying a React static website on AWS using services like S3, CloudFront, and CloudFormation. If you're unfamiliar with Amazon CloudFront, it's a content delivery network (CDN) service designed to enhance web applications' performance, availability, and security by distributing content to users from geographically closer edge locations.

How would we build this?

This tutorial will use Amazon S3, Amazon CloudFront, and AWS CloudFormation to deploy a React-based static website.

S3 will be used to store the compiled static website files generated from the React project.

To enhance the performance and global reach of the website, we will use CloudFront CDN service to cache and serve content to users from edge locations closer to them.

AWS CloudFormation will be the backbone of this setup, as it allows us to define the infrastructure for our static website as code. Creating a CloudFormation template will automate the provisioning and configuration of the S3 bucket and CloudFront distribution.

What’s the purpose?

Using this combination of services, we are taking advantage of the scalability, security, and reliability offered by the AWS ecosystem. With the static website hosted on S3 and distributed through CloudFront, users will experience faster load times and better performance. At the same time, managing the infrastructure with CloudFormation ensures that the entire setup can be version-controlled, easily updated, and maintained systematically.

In other words, we are building a mini Vercel or Netlify for deploying static React apps.

Pre-requisites

It would be best if you had the following:

AWS Account: Sign up for an AWS account if you don't have one already.
AWS CLI: Install and configure the AWS CLI on your local machine. For instructions, follow this guide: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
Code editor (preferably VS Code)
Basic Knowledge of AWS CloudFormation
Enable AmazonS3FullAccess and AWSCloudFormationFullAccess Permission for your IAM user.
Nodejs ≥v16 installed

Let’s get started.

Creating a React Project for AWS Deployment

I found a beautiful todo app by Ilyas Belaoud on GitHub, and we will use it for this project. To get started, clone the repository:

git clone https://github.com/ilyasbelaoud/react-todo-app.git

Install the dependencies by running this command:

npm install

When it’s done installing, run the app with this command:

npm run start

The app will start at [http://localhost:3000](http://localhost:3000) on your browser. You should see something like this:

Great! We’ve set up the React app.

How to Set Up an Amazon S3 Bucket for Your React Website

Let’s go ahead and create the S3 bucket to host the React app.

Write the CloudFormation template to create an S3 bucket

To create an S3 bucket using CloudFormation, you must define the bucket resource in a YAML or JSON template file. In this example, I'll use YAML.

Create a file called s3-react-static-website.yaml and add these lines of code:

Resources:
  StaticWebsiteBucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      BucketName: <random-unique-string>

This template defines a single S3 bucket resource named "StaticWebsiteBucket" with the specified bucket name. Replace my-static-website-bucket with a unique bucket name of your choice.

Configure the bucket to act as a static website host

To configure the S3 bucket for hosting a static website, add the WebsiteConfiguration property to the bucket definition in the CloudFormation template.

Resources:
  StaticWebsiteBucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      BucketName: <random-unique-string>
            PublicAccessBlockConfiguration:
        BlockPublicAcls: false
        BlockPublicPolicy: false
        IgnorePublicAcls: false
        RestrictPublicBuckets: false
      WebsiteConfiguration:
        IndexDocument: index.html
        ErrorDocument: 404.html

Here, we've specified index.html as the index document and 404.html as the error document. Adjust the file names according to your project structure.

The PublicAccessBlockConfiguration property is important because all Block Public Access settings are automatically enabled when a new bucket is created. So for the purpose of this demo, we are setting them to false.

Set up appropriate bucket policies for public access

To grant public read access to the objects in your S3 bucket, you need to create an S3 bucket policy. Add the following resource to your CloudFormation template:

Resources:
  # ... (previous resources) ...

  StaticWebsiteBucketPolicy:
    Type: 'AWS::S3::BucketPolicy'
    Properties:
      Bucket: !Ref StaticWebsiteBucket
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal: '*'
            Action:
              - 's3:GetObject'
            Resource: !Sub 'arn:aws:s3:::${StaticWebsiteBucket}/*'

This policy allows public GetObject access to all objects in the bucket. The !Ref function is used to reference the bucket created earlier, and the !Sub function is used to substitute the bucket name into the resource ARN.

This is the complete Yaml code:

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Create an S3 bucket for hosting a static React website'

Resources:
  StaticWebsiteBucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      BucketName: my-static-website-bucket
            PublicAccessBlockConfiguration:
        BlockPublicAcls: false
        BlockPublicPolicy: false
        IgnorePublicAcls: false
        RestrictPublicBuckets: false
            WebsiteConfiguration:
        IndexDocument: index.html
        ErrorDocument: 404.html

  StaticWebsiteBucketPolicy:
    Type: 'AWS::S3::BucketPolicy'
    Properties:
      Bucket: !Ref StaticWebsiteBucket
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal: '*'
            Action:
              - 's3:GetObject'
            Resource: !Sub 'arn:aws:s3:::${StaticWebsiteBucket}/*'

Amazon CloudFront Setup for React Static Website

In this section, we will set up the CloudFront distribution. These are the steps we will take:

Write the CloudFormation template to create an S3 bucket
Configure the distribution to use the S3 bucket as the origin
Set up caching, SSL, and other settings as needed

Let’s get started.

Write the CloudFormation template to create a CloudFront distribution

To create a CloudFront distribution using CloudFormation, you must define the distribution resource in the YAML template file. Update the existing YAML file that you used to set up the S3 bucket:

Resources:
  # ... (previous resources) ...

  StaticWebsiteCloudFrontDistribution:
    Type: 'AWS::CloudFront::Distribution'
    Properties:
      DistributionConfig:
        Enabled: true
        DefaultRootObject: index.html
        Origins:
          - DomainName: !GetAtt StaticWebsiteBucket.RegionalDomainName
            Id: StaticWebsiteS3Origin
            S3OriginConfig:
              OriginAccessIdentity: ''

This template defines a single CloudFront distribution resource named StaticWebsiteCloudFrontDistribution. The distribution is enabled and configured to use the S3 bucket as its origin.

Let me break down the relevant parts of this code snippet.

The Properties section is where you define the properties of the CloudFront distribution. The DistributionConfig property contains the configuration settings for the CloudFront distribution.
The Enabled property is set to "true", which means that the CloudFront distribution is active.
The DefaultRootObject property is set to index.html. This means that when a user accesses the root of your CloudFront distribution, CloudFront will return the index.html file.
The Origins property lists origins for the CloudFront distribution. In this case, there's only one origin: the S3 bucket you created earlier for hosting the static website.
- DomainName: The domain name of the S3 bucket. !GetAtt StaticWebsiteBucket.RegionalDomainName is a CloudFormation function that retrieves the regional domain name of the S3 bucket you created earlier.
- Id: A unique identifier for the origin, in this case, "StaticWebsiteS3Origin".
- S3OriginConfig: Configuration settings specific to the S3 origin. OriginAccessIdentity is set to an empty string, meaning the CloudFront distribution will use the S3 bucket's public access settings.

Configure the distribution to use the S3 bucket as the origin

In the YAML file, we've already configured the CloudFront distribution to use the S3 bucket created earlier as its origin. The !GetAtt function is used to get the regional domain name of the S3 bucket.

Set up caching, SSL, and other settings as needed

For caching and other settings, you can configure the CacheBehaviors and DefaultCacheBehavior properties of the distribution. You can add an ACM (AWS Certificate Manager) certificate ARN to the ViewerCertificate property to enable SSL. However, seeing as we don’t have a custom domain, we will not include the ViewerCertificate.

Does this mean the website connection will be unsafe using HTTP? No, it doesn’t. The CloudFront distribution will use the default CloudFront domain (e.g., d12345abcd12345.cloudfront.net). The connection will still be secure using HTTPS with the default CloudFront certificate, but the URL will not use a custom domain.

Update your Yaml file with these lines of code:

Resources:
  # ... (previous resources) ...

  StaticWebsiteCloudFrontDistribution:
    Type: 'AWS::CloudFront::Distribution'
    Properties:
      DistributionConfig:
        Enabled: true
        DefaultRootObject: index.html
        Origins:
          - DomainName: !GetAtt StaticWebsiteBucket.RegionalDomainName
            Id: StaticWebsiteS3Origin
            S3OriginConfig:
              OriginAccessIdentity: ''
        DefaultCacheBehavior:
          AllowedMethods:
            - GET
            - HEAD
          CachedMethods:
            - GET
            - HEAD
          Compress: true
          ForwardedValues:
            QueryString: false
            Cookies:
              Forward: none
          MinTTL: 3600
          MaxTTL: 86400
          DefaultTTL: 86400
          TargetOriginId: StaticWebsiteS3Origin
          ViewerProtocolPolicy: redirect-to-https

This configuration sets up caching, enables Gzip compression, and enforces HTTPS. Let’s break down some of the relevant parts of this code snippet. You can notice some properties you’ve used previously repeated, right? I think this is how you get to learn faster.

The DefaultCacheBehavior property is used to configure how CloudFront processes requests and caches content. In this case, the AllowedMethods property specifies which HTTP methods are allowed for requests. We only allow "GET" and "HEAD" methods since it's a static website; these are the only methods needed to fetch content.
The CachedMethods property lists the HTTP methods for which CloudFront caches the responses. We cache GET and "HEAD" responses to serve content faster to users from edge locations.
The Compress property is set to true, which enables automatic Gzip compression of files. This reduces the transmitted files' size, resulting in faster load times and reduced data transfer costs.
The ForwardedValues property specifies how CloudFront forwards query strings and cookies to the origin (the S3 bucket in this case). In this configuration, we set QueryString to false, meaning CloudFront does not forward query strings to the origin. We set Forward to none for the Cookies property, indicating that CloudFront does not forward any cookies to the origin.
These properties set the Time-to-Live (TTL) values for cached objects in seconds: MinTTL is the minimum amount of time that objects stay in the cache, MaxTTL is the maximum time, and DefaultTTL is the default time if no other value is specified in the cache-control header from the origin. In this configuration, the minimum TTL is set to 1 hour (3600 seconds), the maximum TTL is set to 24 hours (86400 seconds), and the default TTL is also set to 24 hours (86400 seconds).
The TargetOriginId property specifies the origin (in this case, the S3 bucket) to which CloudFront forwards requests. The value "StaticWebsiteS3Origin" matches the "Id" value specified in the "Origins" property earlier.
The ViewerProtocolPolicy property sets how CloudFront handles HTTP and HTTPS requests from users. In this case, "redirect-to-https" means that CloudFront automatically redirects HTTP requests to HTTPS, ensuring users access the site securely.

So far, this is how our Yaml file looks like:

AWSTemplateFormatVersion: '2010-09-09'
Description: 'AWS CloudFormation Template: Static Website with React, Amazon S3, and Amazon CloudFront'
Resources:
  StaticWebsiteBucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      BucketName: your-unique-bucket-name
            PublicAccessBlockConfiguration:
        BlockPublicAcls: false
        BlockPublicPolicy: false
        IgnorePublicAcls: false
        RestrictPublicBuckets: false
      WebsiteConfiguration:
        IndexDocument: index.html
        ErrorDocument: error.html

  StaticWebsiteBucketPolicy:
    Type: 'AWS::S3::BucketPolicy'
    Properties:
      Bucket: !Ref StaticWebsiteBucket
      PolicyDocument:
        Id: PublicReadForWebsiteContent
        Version: '2012-10-17'
        Statement:
          - Sid: PublicRead
            Effect: Allow
            Principal: '*'
            Action: 's3:GetObject'
            Resource: !Sub 'arn:aws:s3:::${StaticWebsiteBucket}/*'

  StaticWebsiteCloudFrontDistribution:
    Type: 'AWS::CloudFront::Distribution'
    Properties:
      DistributionConfig:
        Enabled: true
        DefaultRootObject: index.html
        Origins:
          - DomainName: !GetAtt StaticWebsiteBucket.RegionalDomainName
            Id: StaticWebsiteS3Origin
            S3OriginConfig:
              OriginAccessIdentity: ''
        DefaultCacheBehavior:
          AllowedMethods:
            - GET
            - HEAD
          CachedMethods:
            - GET
            - HEAD
          Compress: true
          ForwardedValues:
            QueryString: false
            Cookies:
              Forward: none
          MinTTL: 3600
          MaxTTL: 86400
          DefaultTTL: 86400
          TargetOriginId: StaticWebsiteS3Origin
          ViewerProtocolPolicy: redirect-to-https

Deploying Your CloudFormation Stack on AWS

This section will deploy the cloud formation stack using the AWS CLI.

Follow these steps:

Run the following AWS CLI command to create the CloudFormation stack:
```
aws cloudformation create-stack --stack-name <YourPreferredStackName> --template-body file://s3-react-static-website.yaml
```
It might take some minutes to deploy, depending on your internet connection.
To verify the stack creation progress, run the following command:
```
aws cloudformation describe-stacks --stack-name <YourStackName>
```
If it’s deployed successfully, you should see this on your terminal:

You can also verify from your cloud formation console:

Awesome!

Building and Uploading Your React App to S3

Now that your CloudFormation stack has been successfully deployed and the S3 bucket and CloudFront distribution are set up, it's time to build and upload your React app.

Build the React app

Navigate to your React app's root directory in your terminal and run the following command to create a production-ready build of your React app:

npm run build

This command generates a build folder in your project directory containing the minified and optimized files necessary for deploying your React app.

Upload the contents of the `build` folder to the S3 bucket

Let’s now use the AWS CLI to upload the build folder contents to the s3 bucket.

Navigate to the build folder in your React app's directory. Run the following command to sync the contents of the build folder to your S3 bucket:

aws s3 sync . s3://your-bucket-name

You can find your bucket name in your s3 dashboard. You should get something like this:

After uploading the contents of the build folder to the S3 bucket, your React static website should be accessible through the CloudFront distribution URL. You can find the URL in the Amazon CloudFront console under the "Domain Name" column for your distribution.

And yes, it works!

Leveraging AWS for Frontend React Projects: Final Thoughts

In this tutorial, we've gone through the step-by-step process of hosting and deploying a React static website on AWS using S3, CloudFront, and CloudFormation. We've learned to create and configure an S3 bucket for hosting our website files, set up a CloudFront distribution to optimize performance, and used CloudFormation to automate the provisioning and management of these resources.

By leveraging these AWS services, we've successfully deployed a scalable, high-performance, and globally accessible React static website. We've also familiarized ourselves with the AWS ecosystem, gaining valuable skills and knowledge that can be applied to future projects.

This tutorial serves as a solid foundation for more advanced use cases, enabling you to harness the full potential of AWS CloudFormation Infrastructure as Code Service.

Additional Resources for Further Learning

Getting Started with Infrastructure as Code: AWS CloudFormation

Samuel Umoren — Wed, 19 Apr 2023 20:21:10 +0000

In my previous article, I introduced Infrastructure as Code (IaC) and discussed its key benefits, including automation, consistency, version control, scalability, and cost savings. That article focused on Terraform, an open-source IaC tool that enables defining, managing, and provisioning cloud infrastructure using the HashiCorp Configuration Language (HCL). I provided a step-by-step guide to creating an EC2 instance with Terraform, which you can find here.

In this article, we'll shift our focus to AWS CloudFormation, a widely-used IaC tool in the AWS ecosystem. AWS CloudFormation allows you to model, provision, and manage your AWS infrastructure using JSON or YAML templates. It offers a consistent, automated approach to managing infrastructure, enabling you to create and update resources in a controlled and predictable manner.

Throughout this article, we'll cover the basics of AWS CloudFormation, demonstrating how to create and manage AWS resources using this powerful tool. By the end of this article, you'll better understand AWS CloudFormation and be equipped to decide if it's the right IaC solution for your needs.

Why AWS CloudFormation?

Imagine building a web app on AWS, using EC2 for compute, S3 for storage, RDS for managed databases, and Lambda for API requests. Managing these resources separately and configuring them to work together can be complex and time-consuming.

As your application gains traction globally, availability becomes crucial. To improve it, you can replicate the application in multiple AWS regions. This ensures users can access your app even if one region experiences an outage. However, replication involves duplicating resources and configurations across regions, which can be challenging.

This is where AWS CloudFormation comes in:

Solving app replication: CloudFormation templates define resources and configurations, allowing you to provision identical resources in different regions consistently and repeatedly. This ensures consistency and reduces configuration drift.

Solving resource management: CloudFormation automates resource provisioning and configuration, making it easier to create, update, and delete resources. Deleting a stack removes all associated resources, ensuring efficient cleanup.

By using CloudFormation, managing a collection of resources as a single unit becomes simpler, streamlining the process of maintaining consistency across your infrastructure.

CloudFormation Concepts

In AWS CloudFormation, stacks and templates are essential components to define and manage your infrastructure. Let's use an analogy to help illustrate these concepts:

Templates

Imagine that you're constructing a building. A template can be thought of as the blueprint for your building. The blueprint contains detailed information about the structure, such as the number of floors, rooms, doors, and windows. Similarly, a CloudFormation template is a JSON or YAML formatted text file that describes the AWS resources and their properties required for your application or infrastructure.

Here's a CloudFormation example template in YAML format that defines an Amazon S3 bucket:

YAML:

Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-sample-bucket

or JSON:

{
  "Resources": {
    "S3Bucket": {
      "Type": "AWS::S3::Bucket",
      "Properties": {
        "BucketName": "my-sample-bucket"
      }
    }
  }
}

Stacks

Continuing with the building analogy, a stack can be thought of as the actual constructed building based on the blueprint. It is a collection of AWS resources that are created and managed as a single unit when you provide the template. In the context of CloudFormation, a stack is the live instantiation of a template, where each resource defined in the template is created and associated with the stack.

For instance, when you create a stack using the example template above, CloudFormation will create an S3 bucket with the specified name my-example-bucket. The stack will be responsible for managing the lifecycle of this bucket, such as updating its properties or deleting it when the stack is deleted.

To provide more clarity, when you build web or mobile applications using Amplify and select resources like Cognito for authentication, Analytics for notifications, Datastore for GraphQL APIs, or any other resources for your app, Amplify automatically creates CloudFormation templates based on your choices. These templates are then deployed to an S3 bucket, and CloudFormation is used to create, update, or delete the corresponding stack.

In other words, Amplify simplifies the process of managing AWS resources for your application by generating and managing CloudFormation templates on your behalf. This makes it easier to deploy and manage your application's infrastructure.

When you look at your CloudFormation dashboard, you will see the stacks that have been created or managed by Amplify, along with any other stacks you've created manually or through other means.

You can find the Template on the public gist.

Change Sets

Imagine you have a blueprint (your CloudFormation template) of a house (your stack). The blueprint contains all the details about the house, such as the number of rooms, the layout, and the materials used for construction.

Now, you decide to make some changes to the house, like adding a room or changing the layout of the living room. Instead of immediately making the changes to the house itself, you first update the blueprint to reflect the desired changes. Change sets in AWS CloudFormation are like comparing the updated blueprint with the original one. They allow you to see the differences between the two versions, such as the new room or the altered living room layout.

With the change sets, you can review the changes and understand how they will impact the house before actually making the updates. This way, you can be sure that you're making the right modifications without causing any unintended damage or altering the house in an undesired manner. After reviewing the change set (the differences between the two blueprints), you can decide whether to apply the changes to the house or cancel them. If you're satisfied with the changes, you can update the house according to the new blueprint. If you decide against the modifications, you can discard the change set and leave your house unchanged.

Creating your first AWS CloudFormation Template

You should have these prerequisites to follow through with the rest of this article.

AWS Account: Sign up for an AWS account if you don't have one already.
AWS CLI: Install and configure the AWS CLI on your local machine. For instructions, follow this guide: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
Code editor (preferably VS Code)
Enable AmazonS3FullAccess and AWSCloudFormationFullAccess Permission for your IAM user.

Let’s cover the basic components of a CloudFormation template and walk through an example of creating an S3 bucket. If you went through this GitHub Gist that contains a sample template, you’ll notice these components:

Resources: The core component of a CloudFormation template is the resources section, where you define the AWS resources you want to create and manage. Each resource has a unique logical ID and a resource type that identifies the AWS service it belongs to.
Parameters: CloudFormation parameters allow you to pass values into your template, making it customizable and reusable. They enable you to specify dynamic values, such as the name of the S3 bucket or the instance type for an EC2 instance.
Outputs: CloudFormation outputs are used to export values from the created resources, making them accessible outside of the stack. They can be used to display specific information, like the URL of a created S3 bucket or the public IP address of an EC2 instance.

Create an s3_bucket_template.yaml file and add these lines of code:

AWSTemplateFormatVersion: '2010-09-09'
Description: 'A simple AWS CloudFormation template to create an S3 bucket'

Parameters:
  BucketName:
    Description: 'The name of the S3 bucket'
    Type: String

Resources:
  MyS3Bucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      BucketName: !Ref BucketName

Outputs:
  BucketURL:
    Description: 'The URL of the created S3 bucket'
    Value: !GetAtt MyS3Bucket.WebsiteURL

In this template:

We define a parameter BucketName of type String to allow users to specify the desired name for the S3 bucket.
Under the Resources section, we define a resource of type AWS::S3::Bucket with a logical ID MyS3Bucket. We use the !Ref function to reference the value of the BucketName parameter.
In the Outputs section, we define an output BucketURL that displays the URL of the created S3 bucket using the !GetAtt function to retrieve the WebsiteURL attribute from the MyS3Bucket resource.

To deploy the CloudFormation template you just created, follow these steps:

Create a CloudFormation stack using the AWS CLI and your template file. Replace <STACK_NAME> with a unique name for your stack and <BUCKET_NAME> with the desired name for your S3 bucket:
```
aws cloudformation create-stack --stack-name <STACK_NAME> --template-body file://s3_bucket_template.yaml --parameters ParameterKey=BucketName,ParameterValue=<BUCKET_NAME>
```

Ensure the s3 bucket name is very unique. Something like this my-unique-bucket-8f3gh1t2-202434537 to avoid the stack creation from failing.

💡 To generate a unique name, you should use a combination of a prefix, a random string, and a timestamp.

The AWS CLI command will return a StackId in the response, indicating that the stack creation has started. You can monitor the progress of the stack creation in the AWS CloudFormation console. If the stack creation fails, navigate to the Events tab and check the log.
Once the stack creation is complete, you can retrieve the output value for the BucketURL by running the following command, replacing <STACK_NAME> with the name of your stack:
```
aws cloudformation describe-stacks --stack-name <STACK_NAME> --query "Stacks[0].Outputs[?OutputKey=='BucketURL'].OutputValue" --output text
```

You should see the output like this on your terminal

Or on your Amazon S3 console:

For the purpose of the article, i won’t be creating any objects (🙂).

Updating the CloudFormation Template

In the S3 bucket example, let's say you want to update the stack to enable versioning for the created S3 bucket. Versioning is a feature in Amazon S3 that allows you to preserve, retrieve, and restore every version of every object in your bucket.

You will have to modify the CloudFormation template to include the versioning configuration and then update the stack using the AWS CLI.

Add the VersioningConfiguration property to the MyS3Bucket resource in your s3_bucket_template.yaml file:

    AWSTemplateFormatVersion: '2010-09-09'
    Description: 'A simple AWS CloudFormation template to create an S3 bucket'

    Parameters:
      BucketName:
        Description: 'The name of the S3 bucket'
        Type: String
        Default: MyS3Bucket

    Resources:
      MyS3Bucket:
        Type: 'AWS::S3::Bucket'
        Properties:
          BucketName: !Ref BucketName
          VersioningConfiguration:
            Status: Enabled

    Outputs:
      BucketURL:
        Description: 'The URL of the created S3 bucket'
        Value: !GetAtt MyS3Bucket.WebsiteURL

Run the following command to update the stack:

  aws cloudformation update-stack --stack-name my-new-s3-stack --template-body file://s3_bucket_template.yaml --parameters ParameterKey=BucketName,ParameterValue=your-unique-bucket-name

Ensure you monitor the progress of the stack update using the AWS Management Console. The stack update is complete when the stack status changes to UPDATE_COMPLETE.

After the stack update is complete, the S3 bucket will have versioning enabled.

Deleting the Stack

Deleting a CloudFormation stack means removing all the resources associated with the stack and the stack itself.

💡 This is important because keeping unused resources running can increase your AWS costs. Deleting a stack helps you optimize costs by removing no longer required resources.

Let’s go ahead and delete the S3Stack

Run this command:

  aws cloudformation delete-stack --stack-name my-new-s3-stack

Replace my-new-s3-stack with the name of the stack you want to delete. This command will initiate the deletion process, and AWS CloudFormation will start removing the resources associated with the stack.

Please note that the deletion process may take a few minutes.

To check the progress of the stack deletion, you can use the AWS Management Console or the following AWS CLI command:

aws cloudformation describe-stacks --stack-name my-new-s3-stack

I want to keep practicing…

If you want to dive deeper, you must learn by creating more stacks and writing templates that actually do something. Here are some ideas:

Get Started with CloudFormation from the docs:

Get started - AWS CloudFormation

Use AWS CloudFormation Designer to create a basic LAMP server:

Walkthrough: Use AWS CloudFormation Designer to create a basic web server - AWS CloudFormation

Static website: Create a simple static website hosted on Amazon S3 and distributed using Amazon CloudFront. Use CloudFormation to provision and configure the S3 bucket, CloudFront distribution, and Route53 records for custom domain setup.
Serverless REST API: Build a serverless REST API using AWS Lambda, Amazon API Gateway, and Amazon DynamoDB. Use CloudFormation to create and configure the necessary resources, including Lambda functions, API Gateway, and DynamoDB tables.
Scalable web application: Design a scalable web application using Amazon EC2 instances, Elastic Load Balancing, and Amazon RDS. Utilize CloudFormation to create and manage Auto Scaling groups, load balancers, and RDS instances.

Before you stop reading…

Here is the full list of best practices to consider while working with CloudFormation:

AWS CloudFormation best practices - AWS CloudFormation

Some of the practices that stood out for me based on my recent experience are:

Use IAM to control access: You should use IAM with AWS CloudFormation to specify what AWS CloudFormation actions users can perform, such as viewing stack templates, creating stacks, or deleting stacks.
Do not embed credentials in your templates: Rather than embedding sensitive information in your AWS CloudFormation templates, we recommend you use dynamic references in your stack template
Manage all stack resources through AWS CloudFormation: After you launch a stack, use the CloudFormation console, API, or AWS CLI to update resources in your stack. Don't make changes to stack resources outside of CloudFormation.
Validate templates before using them: Before you use a template to create or update a stack, you can use CloudFormation to validate it. For the AWS CLI or CloudFormation API, use the aws cloudformation validate-template command or ValidateTemplate operation.

So far, this is what I know about AWS CloudFormation…

AWS CloudFormation is a powerful and versatile Infrastructure as Code tool that allows you to model, provision, and manage your AWS infrastructure efficiently. In this article, we delved into the basics of CloudFormation, explored its key components, and walked through a practical example of creating, updating, and deleting an S3 bucket using templates, parameters, and outputs.

By leveraging AWS CloudFormation, you can enjoy the benefits of automation, consistency, version control, scalability, and cost savings when managing your cloud infrastructure. This article has provided a foundation for understanding AWS CloudFormation and inspired you to further explore and experiment with this tool.

Getting Started with Infrastructure as Code (IaC): Terraform

Samuel Umoren — Tue, 11 Apr 2023 23:27:35 +0000

In my previous article, I introduced Infrastructure as Code (IaC) as a key principle of DevOps and likened it to creating a recipe for setting up a computer system. To provide a more technical definition, HashiCorp, the company behind Terraform, describes IaC as infrastructure components (CPUs, memory, disk, firewalls, etc.) defined as code within definition files.

As the backbone of the DevOps movement, IaC brings a host of benefits, including increased efficiency, consistency, and collaboration between DevOps teams. By adopting IaC, teams can automate the provisioning and management of infrastructure, making it easier to scale and adapt to changing needs.

Infrastructure as Code (IaC) plays a critical role in DevOps by streamlining the process of managing and provisioning infrastructure. IaC allows for increased efficiency, collaboration, and automation by treating infrastructure like software code. Here are some key benefits of IaC in DevOps:

Automation: With IaC, you can create reusable templates to automate the provisioning and management of your infrastructure. This reduces manual intervention and minimizes the risk of human error, ultimately leading to more reliable and consistent environments.

Version control: IaC allows you to store your infrastructure definitions in version control systems like Git, making it easier to track changes, roll back to previous configurations, and collaborate with team members.

Consistency: IaC ensures that your infrastructure is consistent across different environments, such as development, testing, and production. This consistency helps avoid configuration drift and makes identifying and fixing issues easier.

Scalability: IaC simplifies scaling your infrastructure up or down as needed. You can easily replicate your infrastructure setup across multiple cloud regions or accounts, ensuring that your resources are available when and where they're needed.

Cost savings: By automating repetitive tasks and reducing the risk of human error, IaC can help you save time and money. Additionally, IaC enables you to manage your cloud resources better and optimize costs by quickly spinning up or tearing down resources based on demand.

In this article, I'll dive deeper into Infrastructure as Code, focusing on two widely-used IaC tools: Terraform and CloudFormation. I'll explore their features, similarities, and differences to help you decide which tool best suits your needs.

Terraform

Terraform is an open-source Infrastructure as Code (IaC) tool that allows you to define, manage, and provision cloud infrastructure using a simple, human-readable language called HashiCorp Configuration Language (HCL). With Terraform, you can create a blueprint for your infrastructure that can be version-controlled, shared, and easily modified.

Features

Declarative language: Terraform uses HCL, a declarative language that focuses on describing the desired end-state of your infrastructure. This makes it easy to understand and maintain, even for those new to IaC.
Modularity: Terraform encourages the use of modules, which are reusable building blocks for your infrastructure. This allows you to create and share reusable templates, improving collaboration and reducing duplicate code.
Plan & apply: Terraform's two-step process involves first generating an execution plan, which shows you the changes that will be made to your infrastructure, and then applying those changes if the plan is approved. This provides better visibility and control over your infrastructure changes.
State management: Terraform maintains a state file that tracks the current state of your infrastructure. This enables Terraform to detect changes, track dependencies, and ensure consistency between your infrastructure definition and actual deployed resources.
Providers: Providers in Terraform are plugins that enable communication with specific cloud platforms, services, or APIs. They define the resources, data sources, and input variables needed to manage infrastructure on a particular platform.

Terraform supports a wide range of cloud providers, including major players like AWS, Google Cloud Platform, and Azure, as well as smaller providers and on-premises solutions. The list of providers is on the Terraform Registry.

To better understand how and why Terraform is used, let’s dive into the Terraform Workflow.

Terraform Workflow

Write the configuration: Define the desired infrastructure configuration in a Terraform file using a declarative language like HCL. This file specifies the resources you want to create, modify, or delete, along with their configuration settings.
Initialize the backend: Run terraform init to initialize Terraform in your working directory, download necessary provider plugins, and set up the backend for storing your Terraform state. This step only needs to be performed once per Terraform project.
Plan and apply changes: Run terraform plan to preview the actions that Terraform will take based on the defined configuration. This step generates an execution plan, showing you what actions Terraform will perform on your infrastructure to reach the desired state. Review the plan and if everything looks correct, run terraform apply to create or modify the infrastructure. Terraform will prompt you to confirm before executing the necessary API calls.
Destroy resources: If the resources are no longer needed, run terraform destroy to remove them. Terraform will prompt you to confirm before deleting the resources, ensuring that you don't accidentally remove something you still need.

Let’s implement this workflow with a real use case.

Creating a Single EC2 Instance on AWS with Terraform

AWS EC2 (Amazon Web Services Elastic Compute Cloud) is a scalable cloud computing service that provides virtual server instances for running applications and workloads. An EC2 instance has variety of purposes, including:

Hosting web applications and websites.
Running databases and data processing tasks.
Deploying and managing containerized applications.
Executing high-performance computing workloads.
Serving as a development and test environment.

Upon creation, the EC2 instance starts running in the specified virtual private cloud (VPC), and you'll be billed for the resources used according to AWS pricing. Let’s go ahead and use terraform to create an EC2 instance on AWS.

Pre-requisites

AWS Account: Sign up for an AWS account if you don't have one already.
AWS CLI: Install and configure the AWS CLI on your local machine. For instructions, follow this guide: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
Terraform: Install Terraform by following the official installation guide: https://learn.hashicorp.com/tutorials/terraform/install-cli
Code editor (preferably VS Code)

The complete code is on Github.

Setting up

Create a new directory for the Terraform project and navigate to it in your terminal.

mkdir terraform-ec2-instance
cd terraform-ec2-instance

Next, Create a file named provider.tf in your working directory and add the following configuration to the provider.tf file to specify the AWS provider and the desired AWS region.

provider "aws" {
  region = "us-east-1"
}

You can find AWS regions far right of the top navbar.

Writing the configuration

To launch an instance in AWS, you need an Amazon Machine Image (AMI). It is a supported and maintained image provided by AWS that provides the information required to launch an instance

Create a file named ec2_instance.tf in your working directory and add the following configuration to the ec2_instance.tf file to define an EC2 instance resource.

resource "aws_instance" "example" {
  ami           = "ami-092401efdf89a2db7"
  instance_type = "t2.micro"

  tags = {
    Name = "new-test-instance"
  }
}

Replace ami-0c55b159cbfafe1f0 with an Amazon Machine Image (AMI) ID for your desired Linux distribution and instance region.

You can find an Amazon Linux 2 AMI ID from the EC2 dashboard here.

I chose this AMI because it’s not on the aws-marketplace so i don’t have to subscribe to use it. Your AMI list might vary based on the region you’re using.

You will want to make sure that the Root device type is EBS (Elastic Block Store) and Virtualization type is hvm (Hardware Virtual Machine). EBS is a persistent block storage service designed for use with Amazon EC2 instances and HVM is a type of virtualization mode available for EC2 instances.

The t2.micro instance is in the general purpose family with 1 vCPUs, 1.0 GiB of memory and low to moderate network performance. In our case, this is perfect because we are not doing any network or memory intensive work.
Navigate to your Instance in your dashboard to see the list of available instance types.

Also, ensure your IAM user has AmazonEC2FullAccess permission allowed.

Initialize and apply the Terraform configuration

Run terraform init in your terminal to initialize your Terraform working directory.

terraform init

Then run terraform validate to validate your configuration files for any syntax errors.

terraform validate

Next, run terraform apply to create the EC2 instance. Terraform will prompt you to confirm that you want to perform the action. Type yes and press Enter to continue.

terraform apply

If everything works fine, you should see something like this on your terminal

Verifying the EC2 instance

Head to your AWS Management Console and navigate to the EC2 Dashboard. You should see something like this:

Click on Instances running and you should see the instance we just created.

Notice how the configuration matches with the ec2_instance.tf.

Clean up

Now we have achieved our goal, let’s destroy the EC2 instance to avoid unnecessary costs.

Run terraform destroy in your terminal. Terraform will prompt you to confirm that you want to perform the action. Type yes and press Enter to continue.

terraform destroy

After a few minutes, Terraform will destroy the EC2 instance. Ensure you check your dashboard to confirm.

Limitations of Terraform

Learning curve: Users may face a learning curve when getting started with Terraform, particularly if they are new to Infrastructure as Code and cloud concepts.
Provider limitations: While Terraform supports many cloud providers, certain features or services might not be available or fully supported due to limitations in the provider implementation.
State management: Terraform relies on a state file to track the resources it manages. This state file can become a point of contention in team environments, requiring additional configuration and tooling, such as remote state backends and locking mechanisms.
Error messages: Terraform can sometimes produce verbose or unclear error messages, making it challenging to diagnose and fix issues.
Performance: Large infrastructure projects with numerous resources and modules can lead to slow performance during planning and applying changes.
No built-in rollback: Terraform does not have a built-in rollback mechanism for reverting changes, which can make recovering from errors more difficult. Users must plan their rollback strategy by leveraging backups, snapshots, or version control systems.

So far this is what i know on IaC and Terraform…

IaC (Infrastructure as Code) is a key DevOps principle that streamlines infrastructure management and provisioning. It increases efficiency, collaboration, and automation by treating infrastructure as code. IaC offers several benefits, including automation, version control, consistency, scalability, and cost savings.

Terraform, an open-source IaC tool, enables defining, managing, and provisioning cloud infrastructure using HCL (HashiCorp Configuration Language). It provides modularity, a plan & apply approach, and state management, working with a wide range of cloud providers.

Terraform's workflow includes writing the configuration, initializing the backend, planning and applying changes, and destroying resources when needed. This simplifies infrastructure setup, encourages collaboration, and ensures consistency across environments.

Resources

Terraform Documentation: Official documentation and getting started guide for Terraform. https://www.terraform.io/docs/index.html
AWS CloudFormation Documentation: Official documentation and getting started guide for AWS CloudFormation. https://docs.aws.amazon.com/cloudformation/index.html
Gruntwork Blog - Terraform vs. CloudFormation: A comparison of the two IaC tools, discussing their strengths and weaknesses. https://blog.gruntwork.io/terraform-vs-cloudformation-f3809ea9ac3a
Medium - Terraform vs. AWS CloudFormation: A detailed comparison of Terraform and AWS CloudFormation, focusing on use cases and examples. https://medium.com/@codeometry/terraform-vs-aws-cloudformation-1d9716122623
What is AWS CloudFormation. https://www.youtube.com/watch?v=0Sh9OySCyb4
*AWS Cloudformation Step by Step Tutorial - Create a DynamoDB Table!* https://www.youtube.com/watch?v=YXVCdGyHDSk
*Terraform Course - Automate your AWS cloud infrastructure.* https://www.youtube.com/watch?v=SLB_c_ayRMo
*Terraform explained in 15 mins | Terraform Tutorial for Beginners.* https://www.youtube.com/watch?v=l5k1ai_GBDE
HashiCorp Learn - Introduction to Terraform: A comprehensive resource for learning Terraform, including tutorials, best practices, and use cases. https://learn.hashicorp.com/terraform
AWS CloudFormation Best Practices: Official best practices guide for using AWS CloudFormation. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html

Turbopack: The successor to Webpack

Samuel Umoren — Sun, 09 Apr 2023 12:02:31 +0000

Once upon a time in web development, building web pages required just HTML, CSS, and some JavaScript for interactivity. This was the typical code structure of most websites:

Most often, the developers will introduce third-party JS libraries for extra interactivity.

JavaScript was perceived as a client-side scripting language and nothing more during this period. That would soon change, especially with the introduction of Nodejs. Node proved that JavaScript had more client-side capabilities, such as handling network requests, routing, complex animations, and storage.

Then we started building large-scale products like eCommerce sites, social media apps, learning platforms, e.t.c, with JavaScript. This introduced more third-party libraries, and CDN (content delivery networks) weren’t popular then, so you had to download the library JS files. This made code so messy and difficult to maintain, and the developer experience was horrible.

During this period, the ever-progressive JS community started focusing on improving developer experience with developer tools. This led to the birth of Bundlers.

Bundlers

A bundler is simply a development tool aggregating all JS files as input and outputs a single JS file that is loadable on a web browser. A bundler ensures that all source code and third-party dependencies are up-to-date and error-free. Before the era of bundling code, optimization and logging were major issues, a bundler solves that with features such as:

Code splitting
Hot module replacement (HMR)
Loggers

So how do Bundlers work behind the scenes?

Dependency Resolution: The bundler generates a dependency graph of all served files.
Bundling: The bundler outputs static assets that the browser can parse. This process is referred to as Packing.

Bundlers like browserify have existed since 2010 using require to load npm packages in the browser. However, JavaScript didn’t have a built-in module system until 2015, with the introduction of ES6. This new wave of modular programming led to the birth of module bundlers like webpack, rollup, parcel, and esbuild. Of all the bundlers, Webpack got everyone’s attention and is currently the most used bundler with ~26million weekly downloads.

Webpack

Webpack is a static module bundler. When introduced to a project, it generates a dependency graph from one entry point (more like index.js) or more, and it combines all the modules (JS and non-JS) into one or more (depending on your configuration) bundles. These bundles become static files (html, css, js, assets) that the browser can process. It requires no configuration to bundle your project but is very configurable.

Let’s briefly take a look at how webpack approaches dependency resolution.

Entry Point: This is where webpack starts when building its internal dependency graph. By default, it is index.js, but you can choose a different entry point or more than one point.

webpack.config.js
```
module.exports = {
  entry: ['../../index.js', '../../server.js'],
};
```

Output: This is the location of the bundles. By default, the output property creates a dist folder.

webpack.config.js

const path = require('path');

module.exports = {
  output: {
    path: path.resolve(__dirname, 'dist'),  },
};

***********Loaders***********: Ever wondered how webpack parses assets such as HTML, CSS and media files? it uses Loaders. Loaders convert these files into consumable modules and add them to the dependency graph.

webpack.config.js

module.exports = {
    module: {
      rules: [
         {
            test: /\.(js|jsx)$/,
            exclude: "/node-modules/",
            use: "babel-loader"

         },
         {
            test: /\.html$/,
            use: "html-loader"
         },
         {
            test: /\.(scss|sass)$/,
            use: ["style-loader", "css-loader", "sass-loader"]
         },
            {
        test: /\.(png|jpe?g|gif)$/i,
        use: [
          {
            loader: 'file-loader',
          },
        ],
      },
      ]
   }

}

Plugins: One of the major reasons webpack is loved by all is its plugin system. Webpack plugins allow you to perform tasks such as bundle optimization, asset management, and injection of environment variables.

webpack.config.js

const BrotliPlugin = require('brotli-webpack-plugin');
module.exports = {
  plugins: [
    new BrotliPlugin({
      asset: '[path].br[query]',
      test: /\.(js|css|html|svg)$/,
    })
  ]
}

Mode: By setting mode, you choose the environment webpack optimizes for.
```
module.exports = {
  mode: 'development',
};  
```

These are the core concepts of webpack. If you’ve worked with JavaScript frameworks such as Vue, React, Angular, and so on, you’ll notice these core webpack concepts are implemented. This is because these frameworks use Webpack for bundling.

The impact of webpack in frontend tooling and architecture is vast. It's widely used in Single Page Applications (SPA), Server-Side Rendering Applications, and Static Site Generators (SSGs). In short, other language frameworks, such as PHP (Laravel) and Ruby(Rails), use webpack to manage JavaScript, CSS, and static assets like images or fonts.

Moreover, with the availability of native ES modules in the browser and the rise of JavaScript tools written in compile-to-native languages, the choice of bundler requires more attention. Webpack has issues such as:

Slow development server: The Webpack plugin system is one of its biggest pros and cons. The heavy reliance on plugins to perform certain tasks can slow down the bundler and hence increase the time it takes to start the development server.

Also, the entire application is rebuilt every time you make changes to a file. Imagine what happens in larger projects.
Complexity: As a project grows and more plugins are introduced, the configuration becomes more complex.
It generates code that is impossible to read. This is always a problem, especially when refactoring code in a large project.

These issues led the ever-progressive JS community to develop better alternatives to Webpack. One of the most successful alternatives so far is Vite. Let’s briefly explore Vite.

Vite

Vite is a build tool that provides a faster development experience in web projects. Unlike bundlers, Vite consists of two parts:

Rollup for code bundling
A dev server with extensive features, including fast Hot Module Replacement (HMR)

The HMR API in Vite is considerably faster than Webpack. Vite solves the slow development server problem we had with Webpack, even as the project expands. Vite ushers in a new era of ESM-based development tools and Bundleless architecture. We won’t go deep into Vite cause it’s past the scope of this article, but the goal of introducing it is so you’ll note these points;

Vite is a build tool, not a bundler. It’s faster, and most teams are migrating from webpack to Vite.
Vite is not a direct replacement for Webpack. It’s just better than webpack in most cases.

These points raise the question, “What’s the successor to Webpack?”. A few weeks ago, Vercel answered that question with the release of Turbopack, and in this article, we’ll learn about what Turbopack is, its pros and cons, how to use it on a Nextjs project, what makes it better than Webpack, and we’ll briefly discuss the future of webpack-based projects.

Turbopack

Turbopack is an incremental bundler optimized for your JavaScript and Typescript projects. Unlike other bundlers written in JS/TS, Turbopack is Rust based. It’s the official successor to Webpack, and the creators of Webpack and Nextjs are building it.

Turbopack claims to be 700x faster than Webpack and 10x faster than Vite (Vite creator disagrees with this) in large projects.

So what makes Turbopack so fast?

Compilation by Request: We’ve discussed the importance of startup time in developer experience and how the Webpack dev server takes seconds/minutes to start as the project gets bigger because it rebuilds the entire application every time a file is changed. Turbopack, on the other hand, compiles only the code needed to start the project.
Turbo Engine: Turbo Engine is a powerful Rust library that enables incremental computation. In computer science, the incremental computation approach is when a sequence of inputs is slightly different from each other, it uses the previously computed output in computing a new output rather than computing the new output from scratch. This is applied in optimizing compilers, and one way to achieve incremental computation is through caching. Turbo Engine implements incremental computation using Function-level caching.

Let’s explore the Features and Cons of Turbopack.

Features and Cons of TurboPack

Let’s highlight some of the features of Turbopack

Faster development server time: Turbopack supports Hot Module Replacement out of the box, and its HMR is way faster due to incremental computation. HMR ensures your dev server doesn’t fully refresh after every file change.
Out-of-the-box support for JS & TS: Turbopack bundles JavaScript and Typescript but not with Babel. Turbopack uses a Rust-based compilation tool, SWC(Speedy Web Compiler). For context, SWC claims to be 17x faster than Babel.
Out-of-the-box support for CJS and ESM imports: Whatever method you use to import modules, dynamic imports, ES Modules, or CommonJS, it’s supported by Turbopack.
Live reloading for Environmental variables: One of the most annoying experiences when developing is having to close and reload your server after changing environmental variables. Turbopack ships with live reloading for environmental variables.

Let’s highlight some cons of Turbopack so far. It’s important to note that Turbopack is still very new and experimental, so these issues might be fixed as it matures.

Lacks god-level Extensibility: Webpack had what I refer to as god-level extensibility with its plugin API. Turbopack doesn’t support plugins, but they promise that the bundler will be extensible in future versions. However, they won’t be porting the Webpack plugin API, meaning most Webpack plugins you enjoy today won’t work with Turbopack.
Does not perform Type Checks: Turbopack uses SWC for compiling TS and doesn’t have out-of-the-box support for type checking. Like Vite and esbuild, with Turbopack, you must run tsc --watch or depend on your code IDE for type checking.
Only supports the Nextjs dev server.

How to use Turbopack

Turbopack is only at its Alpha version and has only been deployed as a Nextjs v13 dev server. To run a Nextjs v13 project powered by Turbopack, run this command on your terminal.

💡 Turbopack for Next.js does not require loaders nor loader configuration for built-in functionality, just as they aren't required for Next.js. Turbopack has built-in support for css and compiling modern JavaScript, so there's no need for css-loader, postcss-loader, or babel-loader if you're using @babel/preset-env.

npx create-next-app --example with-turbopack

This command will bootstrap a Nextjs v13 sample with React Server components. Run yarn install to install dependencies.

Now for the moment of truth. Let’s run the project with yarn dev

6.24ms! with 20+ components!

For context, let’s compare this startup time with a non-turbopack Nextjs v13 project with fewer components and dependencies.

Compiled client and server in 11s!

The difference is clear. We can only look forward to when Turbopack will be a low-level engine for other frameworks.

Migrating from Webpack

As we’ve discussed, Turbopack is still in experiment mode and is not yet ready for production environments. So at the moment, you can’t port your project to Turbopack.

What this means for Webpack users

Firstly, to webpack aficionados, Turbopack is a preview of the future. Webpack has ~26m downloads weekly, which will continue for as long as possible until the project maintainers pull off the plug.

If you visit Snowpack (not maintained anymore), you will be advised to use Vite. The same thing will happen with Webpack and Turbopack in the future.

However, Turbopack is managed by Vercel, and we don’t know when the bundler will be ready for wide adoption. I recommend Vite if you’re looking for an alternative to Webpack.

Conclusion

Turbopack is a promising project that will redefine bundling tools architecture in an era where build tools such as Vite and esbuild are replacing bundlers. In this article, we learned what Bundlers are and how they work. Then we introduced Webpack as the bundler par excellence tool; we went on to learn its core concepts and briefly explored Vite as an alternative to webpack. Furthermore, we discovered Vite is a build tool and not the successor to Webpack. This introduced us to Turbopack. We learned what Turbopack was, how it worked, its top features and issues, how to use it in a project, and how it affects existing Webpack users.

An Introduction to DevOps: Principles and Practices

Samuel Umoren — Sat, 08 Apr 2023 20:47:49 +0000

A few weeks ago, I was on a community call with some front-end engineers, and I noticed how well they were versed in DevOps and Infrastructure. I spent half of the time nodding my head, and whenever I heard “Continuous integration or Continuous deployment or Git”, I would scream, “Yeahhhh,” not cause I really know them, but I remember a few years ago when you had to manually setup GitHub Actions for your Netlify deployments, now it’s automatic. After the meeting, I promised myself I would learn the basics of DevOps and Infrastructure.

My favorite learning method is reading and writing articles about it. This is how I’ll educate myself on DevOps and Infra.

What is DevOps?

DevOps is a combination of the words "development" and "operations." It's a set of practices and principles that aims to bridge the gap between software development and IT operations teams. By promoting collaboration, communication, and integration between these teams that have traditionally worked separately, DevOps enables organizations to build, test, and deploy software more quickly and reliably. The main goal of DevOps is to streamline the entire software development lifecycle, from planning to deployment and beyond.

The Three Ways of DevOps

The Three Ways of DevOps are the guiding principles that form the foundation of DevOps practices. These principles help teams to understand the core values of DevOps better and provide a framework for implementing its practices effectively.

Flow

Flow is all about creating smooth, efficient, and continuous processes throughout the software development lifecycle. Imagine a river flowing from the source to the destination without any obstacles or interruptions. In the context of DevOps, the "river" represents the process of delivering software changes from development to operations and finally to the end-users.

To improve flow, teams should focus on:

Removing bottlenecks: Like rocks in a river, bottlenecks slow down the flow of work. Identify and eliminate them to increase the speed of software delivery.
Minimizing handoffs: When work is passed from one team to another, like passing a baton in a relay race, it can create delays and miscommunication. Reducing these handoffs can streamline the process.
Automating repetitive tasks: Automation can help to speed up processes by performing tasks quickly and consistently, just like a machine on an assembly line.

Feedback:

Feedback is about creating a closed-loop system where information flows back from operations to development, similar to a two-way street. This feedback allows teams to learn from their mistakes, identify areas for improvement, and respond to customer needs quickly.

In the DevOps context, feedback can be achieved through the following:

Monitoring: Keep an eye on the performance and health of your applications and infrastructure, like checking the dashboard of a car.
Incident reports: When issues occur, document and share them with the development team to prevent similar problems in the future.
Customer feedback: Listening to end-users and making improvements based on their needs and experiences.

Continuous Learning and Experimentation

Continuous learning and experimentation encourage teams to refine their processes, tools, and techniques constantly. Think of it as planting a garden: by regularly tending to it, learning from past mistakes, and trying new approaches, you can create a thriving and productive environment.

In a DevOps setting, continuous learning and experimentation involve:

Learning from failures: When things go wrong, treat them as learning opportunities and use the knowledge gained to improve your processes.
Embracing change: Be open to new ideas, tools, and technologies that can help your team work more efficiently and deliver better results.
Experimenting: Test new approaches, measure their impact, and use the results to inform future decisions.

Other DevOps Principles

Some other core DevOps principles I learned of are:

Infrastructure as Code (IAC)

Infrastructure as Code (IaC) is like creating a recipe for setting up a computer system. Instead of manually setting up servers, networks, and storage, you write a set of instructions in code. This "recipe" tells a computer how to set everything up automatically. With IaC, you can easily create and change your system's design, like editing a recipe. This approach saves time, reduces mistakes, and keeps your system consistent as if you were using the same recipe for cooking a dish multiple times. IaC is an essential part of DevOps that helps teams work faster and smarter. Some IaC tools that i hear of from Infra engineers frequently are Terraform, AWS CloudFormation, Ansible, Chef, and Puppet. These tools are essential for automating the management and provisioning of infrastructure.

Continuous Improvement

Have you met DevOps or Infra engineers? They are always trying to be ahead of the world when it comes to improving and refining their projects. Like maintaining a tidy room, it involves regularly reviewing performance, analyzing data, making changes, learning from mistakes, and adapting to new situations. By staying open to new ideas and constantly improving, teams can ensure their processes are efficient and effective, delivering the best possible results in software development and IT operations.

DevOps Practices

These practices are the methods and techniques used to implement DevOps principles in software development. The aim is to improve collaboration, streamline processes, and enhance the overall efficiency of the software development lifecycle. I’ll outline a few because I will dive deep into most of them in future articles.

Continuous Integration (CI): Integrating code changes frequently and automatically testing them to catch issues early.
Continuous Delivery (CD): Ensuring software changes are always in a releasable state, allowing faster and more reliable deployments.
Continuous Deployment: Automatically deploy software changes to production, without manual intervention, once they pass required tests.
Infrastructure as Code (IaC): Managing and provisioning infrastructure using code and automation tools.
Monitoring and Logging: Collecting and analyzing data on application performance and infrastructure health to enable informed decision-making and proactive issue resolution.
Automated Testing: Writing and running automated tests to ensure code quality and reduce the risk of introducing errors during deployment.
Version Control: Using tools like Git to manage and track changes to code, making collaboration and rollback easier.
Microservices Architecture: Designing applications as small, independent services that communicate through APIs, improving scalability and maintainability.
Configuration Management: Automating the process of applying and maintaining the desired state of software components and infrastructure.
Containerization and Orchestration: Containerization puts software and its parts into separate, small boxes called containers, making them work the same everywhere. Orchestration helps control these containers automatically, making big systems easier to handle. Together, they make app development faster and simpler, allowing better use of DevOps resources.

Popular DevOps Tools

I’ve seen a lot of DevOps tools, and I'm just 2 days into this DevOps journey, but these four stand out for me.

Git (Version Control): In DevOps, Git helps track code changes and fosters collaboration between developers and operations teams. It streamlines the development process, allowing for easy rollback and merging of changes, improving the overall software delivery pipeline.
Jenkins (CI/CD): Jenkins plays a key role in DevOps by automating the Continuous Integration and Continuous Delivery processes. It ensures code quality and rapid deployment, catching errors early and facilitating seamless collaboration between development and operations.
Docker (Containerization): Docker enhances DevOps workflows by packaging software into portable containers, ensuring consistent performance across environments. It simplifies development and deployment, enabling faster and more reliable delivery of applications.
Kubernetes (Container Orchestration): In DevOps, Kubernetes efficiently orchestrates containers, automating their deployment, scaling, and management. It optimizes resource utilization and supports complex, large-scale systems, improving the collaboration between development and operations teams.

So far, this is what I know about DevOps…

DevOps brings together developers and IT operations to create better software faster. It's like a team sport where everyone works together.

The Three Ways of DevOps are like a playbook: Flow makes things move smoothly, Feedback is a two-way street for learning, and Continuous Learning encourages us to try new things. Other important ideas in DevOps are Infrastructure as Code (like a recipe for computer systems) and Continuous Improvement (always getting better).

DevOps practices help teams work together, like using containers and orchestrating them to make app development easier. Popular tools in DevOps include Git for tracking code changes, Jenkins for automating testing and deployment, Docker for packaging software, and Kubernetes for managing containers.

Next, Getting Started with Infrastructure as Code (IAC): Terraform vs. CloudFormation

Resources

I’m reading this book: The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
What is DevOps? - Amazon Web Services
An Introduction to DevOps - DigitalOcean
The Top 5 DevOps Principles to Know - DZone
The Top 11 DevOps Tools for 2021 - Stackify
Continuous Integration vs. Continuous Delivery vs. Continuous Deployment - Atlassian
16 DevOps Best Practices Every Developer Should Know - spacelift

Migrating from Monolithic E-commerce Platforms to MedusaJS: A Guide for Team Leads and Project managers

Samuel Umoren — Tue, 04 Apr 2023 00:40:34 +0000

Developers building e-commerce solutions are familiar with popular monolithic e-commerce platforms such as Magneto, WooCommerce, and Oracle. These platforms are famous for being easy to use, their built-in features, faster time to market (arguably), and their established community of developers and users. This is why most developers would downplay the idea of migrating to a non-monolithic platform. To some extent, preferring to stick to monolithic platforms could be justified — if it works, don’t change it, right?

However, as online shopping grows, businesses need more flexibility to offer personalized experiences and quickly adapt to changing customer needs. The reasons for this are:

Increased competition: As the number of online businesses continues to grow, customers have more options to choose from.
Changing customer expectations: Customer expectations are constantly evolving, and businesses need to be able to adapt quickly to meet these changing needs.
Higher customer engagement: By offering personalized experiences, businesses can increase customer engagement and loyalty, leading to higher conversion rates and repeat business.
Improved customer satisfaction: Personalized experiences that cater to each customer's specific needs and preferences can lead to higher customer satisfaction levels, resulting in positive word-of-mouth and increased brand reputation.

Is this where I introduce a headless e-commerce platform like Medusajs? Not yet. If you’re a project manager or team lead, you would be curious as to why you should consider not using a monolithic platform. Here are some common limitations of these platforms:

Limited Flexibility: Monolithic e-commerce platforms often have limited flexibility when it comes to customizing and extending functionality. This can make it difficult for businesses to adapt quickly to changing customer needs or to offer personalized experiences.
Vendor Lock-In: Many monolithic e-commerce platforms are designed to keep users within their ecosystem, which can make it difficult to migrate to a different platform in the future.
Limited Innovation: Monolithic e-commerce platforms may not always be able to keep up with the latest trends and innovations in e-commerce. This can limit a business's ability to offer cutting-edge features and functionality to its customers. In most cases, you will have to request and wait for your vendor to implement a new feature that suits your business/client needs.

In this short guide, I’ll discuss the benefits and challenges of migrating from a monolithic e-commerce platform to MedusaJS and how to create a seamless migration plan.

What to Consider when choosing an E-commerce platform in 2023

When choosing an e-commerce platform for your team or client, consider factors such as business requirements, scalability, customization, security, integration, support, and cost. By carefully evaluating these factors, you can choose an e-commerce platform that meets your specific needs and goals.

This is where a headless e-commerce platform like Medusajs comes in.

Benefits of Migrating to a Headless Commerce System:

Increased Flexibility: MedusaJS, as a headless e-commerce platform, separates the front-end user interface from the back-end business logic, allowing for greater flexibility and agility in designing and implementing custom features and functionality.

Improved Performance: By using a headless architecture, your developer teams can reduce the number of requests sent to the server, resulting in faster page load times and improved performance.
Easier Integrations: MedusaJS is built with APIs, making integrating other systems and platforms easier.
Better Customer Experience: With a headless architecture, your team can offer a more personalized and engaging customer experience by tailoring the front-end user interface to each customer's specific needs and preferences.
Vendor Neutrality: Headless e-commerce systems like Medusa are vendor-neutral platforms, meaning businesses are not locked into a specific vendor or technology stack. This can provide greater flexibility and cost savings over time.
Open Source: MedusaJS is an open-source platform, which means that your team can access the source code and make modifications as needed by contributing to the project.

However, migrating to a headless e-commerce system does not come without challenges.

Challenges of Migrating to a Headless Commerce System:

Technical Complexity: Migrating to a headless commerce system requires a certain level of technical expertise and may be challenging for organizations that lack the necessary skills and resources.
Legacy System Integration: Integrating with existing legacy systems can be a challenge and may require significant effort to ensure compatibility and maintain data integrity.
Customization and Maintenance: Customizing and maintaining a headless commerce system may require a significant investment in resources and ongoing maintenance.
Community Support: Some headless commerce systems, like MedusaJS, may have a smaller community of users and developers compared to more established platforms. This can make it difficult to find support and resources when needed.

Having evaluated the pros and cons of migrating to a headless commerce system and making an educated decision to move on with it, you’ll have to create a migration plan and roadmap.

Creating a Migration Plan and Roadmap

Designing a roadmap for migrating an e-commerce system requires a combined effort from all stakeholders in the team, especially the developers. Thus, the migration plan depends on the team’s goals and business requirements. However, they are core points you should consider when creating the roadmap, such as:

Evaluate the current e-commerce platform and identify pain points and areas for improvement.
Determine the scope of the migration and create a timeline for each phase of the project.
Identify the resources required for the migration, including team members, software tools, and third-party services.
Develop a testing and validation plan to ensure the new system meets business requirements.

Wrapping up…

Plan and prepare: Migrating to a headless commerce system requires careful planning and preparation. Ensure that you have the right team and resources in place before embarking on the migration.

Test and validate: Testing and validation are critical to ensuring the new system meets your business requirements. Test early and often, and involve stakeholders in the process to ensure everyone is on the same page.

Address legacy system integration early: Integrating with existing legacy systems can be a challenge and may require significant effort to ensure compatibility and maintain data integrity. Address this issue early in the migration process to avoid delays and complications later.

Migrating from a monolithic e-commerce platform to a headless commerce system like MedusaJS offers significant benefits in terms of flexibility, performance, and customer experience. However, it requires careful planning, preparation, ongoing maintenance, and customization.

Designing Scalable and High-performance E-commerce Systems with MedusaJS and Microservices Architecture

Samuel Umoren — Mon, 03 Apr 2023 19:20:56 +0000

Have you built an e-commerce app or worked on an existing e-commerce system before? If you have, then you'll agree that e-commerce systems constantly evolve and become more complex, requiring businesses to have scalable and high-performing systems to remain competitive. That's where MedusaJS comes in. It is an open-source headless commerce engine that provides developers with a flexible framework for building modern e-commerce stores using any front-end technology.

However, to truly maximize its potential, combining MedusaJS with microservices architecture can take your e-commerce system to the next level. Microservices architecture is an approach to software development that structures an application as a collection of loosely coupled services. Each service is responsible for a specific functionality, and they can all communicate with each other through APIs. Integrating MedusaJS with microservices allows you to build a modular and scalable e-commerce system that can handle high traffic and deliver exceptional performance.

This guide explores the benefits of combining MedusaJS with microservices architecture and shows you how to design and implement a modular e-commerce solution. With MedusaJS and microservices architecture, you can create a modern, efficient, and flexible e-commerce platform that can keep up with the evolving demands of the market.

The Benefits of Combining MedusaJS and Microservices Architecture

When you combine MedusaJS with microservices architecture, you unlock numerous benefits that can lead to a more efficient and scalable e-commerce platform. Here are some key advantages of this approach:

Scalability

E-commerce platforms must handle varying loads, including peak traffic during special promotions or seasonal events. By using microservices, you can independently scale individual components based on their specific needs. This enables you to optimize resource utilization while ensuring that your platform can handle increased demand.

Flexibility

MedusaJS provides a flexible framework for building modern e-commerce stores, and combining it with microservices architecture further enhances this flexibility. Each service can be developed and deployed independently, allowing you to mix and match technologies that best fit your requirements. This modular approach makes it easier to update or replace components without affecting the entire system.

Enhanced Performance

Microservices allow each component of your e-commerce system to operate independently, which can lead to improved performance. By decoupling services, you can allocate resources efficiently and minimize bottlenecks in your system. This results in a faster, more responsive e-commerce platform that can handle high traffic without sacrificing user experience.

Designing a Modular E-commerce Solution with MedusaJS and Microservices

To create a scalable and high-performing e-commerce platform, you need a well-thought-out design. Here are some key steps to designing a modular solution with MedusaJS and microservices:

Define your services: Identify the core functionalities of your e-commerce platform and break them down into individual services. For our example e-commerce platform, let's define the following services:
- Product Catalog Management: Handles product-related operations, such as listing, searching, and updating product information.
- Shopping Cart: Manages customers' shopping carts and their operations, including adding, updating, and removing items.
- Payment Processing: Processes payments and handles refund requests.
- Order Management: Manages orders from creation to fulfillment, including tracking order status and handling shipping.
Choose the right technology stack: Pick the right technologies for each microservice based on your specific requirements. MedusaJS supports various technologies, allowing you to choose the most suitable stack for each service. For instance, consider the following stack:
- Backend: Node.js and Express.js for building RESTful APIs
- Frontend: React for building a responsive user interface
- Database: PostgreSQL for storing e-commerce data

Extend MedusaJS with custom plugins: MedusaJS provides a plugin architecture that allows you to extend its functionality to meet the needs of your specific use case. For example, you can create a custom plugin to handle order management:

// order-management-plugin.js
module.exports = {
  name: "order-management",
  extend: (Medusa) => {
    Medusa.models.Order = require("./models/order");
    Medusa.routes.push(require("./routes/order"));
  },
};

Design the API contracts: Establish the communication protocols between your microservices. Design the APIs for each service, ensuring that they are well-documented and easy to understand. MedusaJS allows you to define API routes for your services:

// routes/order.js
const { Router } = require("express");

module.exports = (app, Medusa) => {
  const router = Router();

  router.post("/", async (req, res) => {
    const order = await Medusa.models.Order.create(req.body);
    res.status(201).json(order);
  });

  app.use("/orders", router);
};

Implement proper monitoring and logging: To maintain a high-performing e-commerce platform, implement robust monitoring and logging solutions for each service. This will help you identify performance bottlenecks and troubleshoot issues quickly. Consider using tools like Prometheus for monitoring and Winston for logging:

// server.js
const { createLogger, transports, format } = require("winston");

const logger = createLogger({
  format: format.combine(format.timestamp(), format.json()),
  transports: [new transports.File({ filename: "application.log" })],
});

const Medusa = require("medusa");
Medusa.start({ logger });

Implement API Gateway: To integrate Medusajs with microservices for seamless interaction, it is important to implement an API Gateway to route requests to the appropriate microservices, handling authentication, load balancing, and request/response transformation. A basic API gateway looks like this:

// api-gateway.js
const express = require('express');
const httpProxy = require('http-proxy');
const { URL } = require('url');

const app = express();

const productServiceUrl = new URL('http://localhost:3000');
const shoppingCartServiceUrl = new URL('http://localhost:4000');
const orderServiceUrl = new URL('http://localhost:5000');
const paymentServiceUrl = new URL('http://localhost:6000');

const apiProxy = httpProxy.createProxyServer();

app.all('/api/products/*', (req, res) => {
  apiProxy.web(req, res, { target: productServiceUrl });
});

app.all('/api/cart/*', (req, res) => {
  apiProxy.web(req, res, { target: shoppingCartServiceUrl });
});

app.all('/api/orders/*', (req, res) => {
  apiProxy.web(req, res, { target: orderServiceUrl });
});

app.all('/api/payments/*', (req, res) => {
  apiProxy.web(req, res, { target: paymentServiceUrl });
});

const PORT = process.env.PORT || 8080;
app.listen(PORT, () => {
  console.log(`API Gateway listening on port ${PORT}`);
});

Managing Data Consisitency and communication between services: It is important that you implement strategies to manage data consistency and communication between the microservices because this is vital to the overall performance and reliablity of the e-commerce app. To manage data consistency and communication, consider the following approaches:
- Data Synchronization Patterns: Implement data synchronization patterns such as eventual consistency, compensating transactions, or sagas to coordinate updates across multiple microservices.
- Message Broker: Use a message broker like Kafka or RabbitMQ to facilitate communication between microservices, allowing them to exchange messages and maintain data consistency asynchronously.
- Caching Strategies: Implement caching strategies to store frequently accessed data, reducing the need for inter-service communication and improving performance.

When building Microservices for e-commerce platforms with Medusajs, you’ll want to extend some of it’s functionalities. Medusa has a plugin system that allows developers to implement custom features or integrate third-party services into Medusa. Let’s explore this.

Implementing MedusaJS Plugins for Microservices

Plugins can be used to add new endpoints, integrate with third-party services, or modify existing behavior to suit your application needs.

Creating custom plugins to extend MedusaJS functionality

To create a custom plugin in MedusaJS, you can follow these steps:

Create a new file in your MedusaJS project directory and define a function that accepts a Medusa object as its argument. This function will be your plugin.
Use the Medusa.router() function to create an instance of an Express router, and define your custom endpoint or middleware.
Add the router to the Medusa app using the Medusa.app.use() method.
Register your plugin with MedusaJS by adding the plugin file to the plugins array in your medusa-config.js file.

Let’s create a custom plugin for order management.

Create a new file named order-management-plugin.js in your MedusaJS project directory and import the necessary dependencies, including the Medusa models/entities and any external libraries you may need:

const { Order } = require("medusa-core/models");
const axios = require("axios");

Next, define the plugin by exporting a function that receives a Medusa object as its argument:

module.exports = function orderManagementPlugin(Medusa) {
  const router = Medusa.router();

  // Define the custom endpoint for fetching orders
  router.get("/orders", async (req, res) => {
    try {
      // Fetch all orders from database
      const orders = await Order.findAll();

      // Return the orders to the client
      res.json({ orders });
    } catch (error) {
      console.error(error);
      res.status(500).json({ error: "Failed to fetch orders" });
    }
  });

  // Define a custom middleware for handling order fulfillment
  router.post("/fulfillment", async (req, res, next) => {
    try {
      const { order_id } = req.body;

      // Fetch the order from the database
      const order = await Order.findOne({
        where: {
          id: order_id,
        },
      });

      // Call an external fulfillment API to fulfill the order
      const response = await axios.post("https://your-fulfillment-api.com", {
        order_id: order.id,
        items: order.items,
        shipping_address: order.shipping_address,
      });

      // Update the order status to "fulfilled"
      await order.update({
        fulfillment_status: "fulfilled",
        fulfillment_response: response.data,
      });

      // Call the next middleware in the chain
      next();
    } catch (error) {
      console.error(error);
      res.status(500).json({ error: "Order fulfillment failed" });
    }
  });

  // Add the router to the Medusa app
  Medusa.app.use(router);
};

Here, we have two custom endpoints: one for fetching all orders from the database, and another for handling order fulfillment requests. The /orders endpoint uses the Order model from Medusa to fetch all orders from the database and return them to the client. The /fulfillment endpoint uses Axios to call an external fulfillment API and update the order's fulfillment status in the database.

Next, register your plugin with MedusaJS by adding the following line to your medusa-config.js
file:

module.exports = {
  plugins: [
    require("./order-management-plugin.js")
  ]
};

This line tells MedusaJS to load your custom order management plugin when starting the server.

Learn more about Medusa Plugins.

Conclusion

In conclusion, I hope this guide has been helpful in exploring the benefits of combining MedusaJS with microservices architecture and demonstrating how to design and implement a scalable and high-performing e-commerce solution.

We covered several key concepts and techniques in this guide, including identifying and defining microservices, choosing the right technology stack, designing API contracts, implementing monitoring and logging, and creating custom plugins to extend MedusaJS functionality. By following these best practices and leveraging the power of MedusaJS and microservices architecture, you can build a modern, efficient, and flexible e-commerce platform that can keep up with the evolving demands of the market.

Looking ahead, headless commerce and microservices architecture are set to continue growing in popularity as businesses seek to stay competitive in the rapidly evolving e-commerce landscape.

DEV Community: Samuel Umoren

How I Stopped Chasing Clients and Started Building Assets: A Technical Writer's Guide to Multiple Income Streams

Why I Had to Think Beyond the 9-to-5

The Technical Writing Areas That Actually Pay Well

Where to Find Real Freelance Opportunities

Creating Content That Opens Doors

Unconventional Ways to Monetize Your Skills

The Hard Truths About Freelance Challenges

Building Products from Your Knowledge

How Technical Writing is Evolving

Building Assets That Work for You

Optimize Your Node.js API with Clustering, Load Testing, and Advanced Caching

Prerequisites

Understanding Node.js Clustering

Load Testing with Autocannon

Setting Up Autocannon

Advanced Caching with LRU Cache

Conclusion

Resources

Automating Code Review in Node.js with DeepSource

Prerequisites

Getting Started

DeepSource Integration

Prioritizing and Reviewing Issues with DeepSource

Automating Issue Creation for Immediate Action

Understanding Severity Categories in DeepSource

Integrating DeepSource into Your Node.js REST API Development Workflow

Setting Up Code Coverage with DeepSource

Configuring CI/CD Pipeline with GitHub Actions

Conclusion

Improve Data Fetching in Next.js Applications through SWR

How SWR works

What we’ll be building

Pre-requisites

Getting Started

Fetching, Displaying, and Updating Data with SWR

Handling Errors and Loading States

Implementing loading indicators for a better user experience

Optimistic UI updates

Using SWR for paginated data fetching

Implementing infinite scrolling in Next.js with SWR

Wrapping up…

Resources

Backstage.io: The Ultimate Developer Portal for Enhancing Team Efficiency and User Satisfaction.

Understanding Backstage.io: A Powerful Developer Tool

How Backstage.io Boosts Software Development Efficiency Through Centralization, Automation, and Extensibility

Enhancing User Satisfaction with Backstage.io: Streamlining Workflows for Rapid Software Deployments

A Streamlined Developer Experience

Rapid Iterations and Deployments

Enhanced Communication and Collaboration

Reliable and Error-Free Software

Conclusion

Resources

Step-by-Step Guide to Hosting and Deploying a React Static Website on AWS

How would we build this?

What’s the purpose?

Pre-requisites

Creating a React Project for AWS Deployment

How to Set Up an Amazon S3 Bucket for Your React Website

Write the CloudFormation template to create an S3 bucket

Configure the bucket to act as a static website host

Set up appropriate bucket policies for public access

Amazon CloudFront Setup for React Static Website

Write the CloudFormation template to create a CloudFront distribution

Configure the distribution to use the S3 bucket as the origin

Set up caching, SSL, and other settings as needed

Deploying Your CloudFormation Stack on AWS

Building and Uploading Your React App to S3

Build the React app

Upload the contents of the build folder to the S3 bucket

Leveraging AWS for Frontend React Projects: Final Thoughts

Additional Resources for Further Learning

Getting Started with Infrastructure as Code: AWS CloudFormation

Why AWS CloudFormation?

CloudFormation Concepts

Templates

Stacks

Change Sets

Creating your first AWS CloudFormation Template

Updating the CloudFormation Template

Upload the contents of the `build` folder to the S3 bucket