Demo

I was making some example pages for testing and decided to make a full demo app to showcase each feature and how they affect navigation performance.

Demo App

App Router vs Pages Router

When you compare the performance of the Pages Router with the App Router, you will notice that by default the Pages Router navigation is faster, while the App Router initial page load is faster (although it is hard to notice the initial page load speed difference without some tool to measure). That happens mainly because of 2 things. With the Pages Router, the necessary JavaScript to navigate to another page is already downloaded to the browser on the page's initial load. With the App Router, the javascript downloaded to the browser is usually smaller and the dynamic content is streamed through the same initial page request (while you would have 2 separate requests for the Pages Router).

Displaying Dynamic Content

Initially I thought that I would get a fast navigation just by wrapping the dynamic content with Suspense with a fallback for a loading state. But as you can see from the example, that doesn't happen and the navigation still feels kind of slow.

export default function Page(props: { params: Promise<{ id: string }> }) {
  return (
    <div>
      Static Title
      <Suspense fallback={<Spinner />}>
        <DynamicComponent {...props} />
      </Suspense>
    </div>
  );
}

If we add a loading.tsx to this route segment, we finally achieve a fast navigation. However, this introduces a new issue with the loading cascade: first, the loading from loading.tsx is displayed, and then the loading from the Suspense fallback gets displayed.

We can also make the navigation faster by using the edge runtime. All we need to do is add export const runtime = 'edge'; in our page code and the page load should be faster. That said, the edge runtime does not support all the node.js features and some libraries might not work as expected.

Caching

Client Side

By enabling the client side router cache, we can get a fast navigation on the second time the user visits a certain page. This was the default behavior on Next.js 14, but it changed with Next.js 15. Now if we want to enable this behaviour we need to add the following in the next.config.ts file:

const nextConfig: NextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30,
      static: 180,
    },
  },
};

This will make Next.js cache dynamic visited pages on the client side for 30 seconds. That said, the cache is only for that specific user and it goes away when you reload the page. You can also clear the client side cache programmatically by calling router.refresh().

Server Side

We can also cache the dynamic content on the server side. This won't actually affect the app's navigation speed when compared with wrapping it with Suspense, but it is faster because there will be no loading state.

On the demo I used unstable_cache(), but you can also use the newer experimental use cache directive, which is probably what people will be using in production once it becomes stable.

const getCachedDynamicData = unstable_cache(getDynamicData);

Partial Prerendering (PPR)

Enabling PPR on our app makes it possible to have static content and dynamic content on the same page. Where the pre-rendered static shell is shown instantly while the dynamic content wrapped with Suspense loads asynchronously.

For now we need to be on the latest canary version of Next.js to enable PPR, but hopefully soon it will come to the stable release. When that happens we might be able to build Next.js apps without thinking too much about navigation performance, as wrapping the dynamic part with Suspense will be enough for fast navigation.

const nextConfig: NextConfig = {
  experimental: {
    ppr: true,
  },
};

Prefetching

By default, Next.js already prefetches static content of links that are visible in the screen. If we want to go one step further, we can set prefetch={true} in our Link components. This will make Next.js prefetch the whole page, including the dynamic parts, making navigation instant and without loading even for dynamic pages.

<Link href={link} prefetch>Link</Link>

Of course, this will increase the number of unnecessary requests, which might increase the bandwidth usage on the hosting platform and also cause some unnecessary load on the server.

The server-side load can be avoided if the content can be cached reducing the need for server calls to databases or external services.

Other Tricks

In this demo you can see how fast you can make your app.

In addition to server-side caching and prefetching, this demo also uses two other tricks to make the navigation even faster. The first one is prefetching target page's images on link hover. The other is to navigate onMouseDown (as soon as you click instead of waiting for release).

These tricks were taken from the NextFaster project. The main code you will want to check is the prefetch-images api route and the custom link.tsx component.

They also have a cost breakdown in the README file of this experimental project, which you might want to check.

Conclusion

Right now we still have to do a little bit of work to make our Next.js app navigation fast with the App Router. Hopefully we won't need to think too much about it after PPR becomes stable. That said, the App Router offers many nice features like the ability to directly call backend code from server components, server actions, caching, layouts, and more. So personally I will be using the App Router for my next projects.

Thanks for reading!

👋 Here are my links!

• YouTube

• X

• Bluesky

Features of the Script

• ⭐ JSON Structured Output: Uses OpenAI's GPT-4o-mini model to generate structured JSON output.

• ⭐ Configurable Batch Sizes: You can control how quickly the data is generated.

• ⭐ Image Generation: Generates realistic images for items using DALL·E 3.

• ⭐ Image Optimization: Compresses images into WebP format using Sharp for better performance.

• ⭐ Image Upload: Stores the optimized images in Edge Store for easy access.

• ⭐ Database Integration: Seamlessly inserts the generated data into your database.

• ⭐ Reusable Design: Can be easily adapted for different kinds of mock data.

Running Standalone TypeScript Scripts

The first thing I needed was a way to run scripts in my app, with access to all necessary environment variables. I used tsx and dotenv-cli for this.

Install them using:

npm i -D tsx dotenv-cli

Now, we can create a simple script:

(async () => {
  console.log("TEST");
})();

And run it with:

npx dotenv -e .env tsx ./src/scripts/test.ts

Generating Mock Data

I wanted to generate a list of recipes with specific fields in JSON format to add to my database. When I first ran multiple generations in parallel, I got some duplicate recipes. To avoid that, I switched to generating them sequentially and included the existing recipes in the prompt to minimize duplication. There are definitely ways to implement seeding logic for parallel generation without duplicates, but for this purpose, I was fine with generating them in series.

import { db } from "@/server/db";
import OpenAI from "openai";
import { zodResponseFormat } from "openai/helpers/zod";
import { z } from "zod";

// Schema for the recipe data returned by OpenAI
const recipeSchema = z.object({
  recipes: z.array(
    z.object({
      name: z.string(),
      description: z.string(),
      ingredients: z.array(z.string()),
      steps: z.array(
        z.object({
          instruction: z.string(),
        })
      ),
      duration: z.number(),
      servings: z.number(),
    })
  ),
});

type Recipe = z.infer<typeof recipeSchema>["recipes"][number] & {
  image?: string; // This will be populated later
};

async function generateRecipes(count: number, allRecipeNamesStr: string) {
  const prompt = `Generate ${count} unique and diverse recipes that are different from the following recipes: ${allRecipeNamesStr}.`;

  // Generate a list of recipes in JSON format using OpenAI's API
  const completion = await openai.chat.completions.create({
    model: "gpt-4o-mini",
    messages: [{ role: "user", content: prompt }],
    response_format: zodResponseFormat(recipeSchema, "recipes"),
  });

  const responseContent = completion.choices[0]?.message?.content ?? "";
  return recipeSchema.parse(JSON.parse(responseContent)).recipes;
}

Generating Images

To generate images, I used the dall-e-3 model. The cost is $0.04 per image. You could opt for dall-e-2 at half the cost, but the images aren’t as good.

async function generateRecipeImage(recipe: Recipe) {
  console.log(`Generating image for ${recipe.name}`);

  const imagePrompt = `An appetizing photo of the dish: ${recipe.name}`;

  const res = await openai.images.generate({
    model: "dall-e-3",
    prompt: imagePrompt,
    size: "1024x1024",
  });

  const url = res.data[0]?.url;
  if (!url) {
    throw new Error("No image url found");
  }
  return url;
}

Optimizing the Image

The images generated by DALL-E were quite large, so I used Sharp to convert them to WebP. This reduced the size from about 1.7MB to 170KB, without noticeable loss of quality.

import sharp from "sharp";

async function optimizeImage(imageUrl: string) {
  const response = await fetch(imageUrl);
  if (!response.ok) {
    throw new Error(`Failed to fetch image: ${response.statusText}`);
  }

  const arrayBuffer = await response.arrayBuffer();

  const optimizedBuffer = await sharp(Buffer.from(arrayBuffer))
    .webp() // Default quality is 80
    .toBuffer();

  return new Blob([optimizedBuffer], { type: "image/webp" });
}

Uploading the Image

The images from DALL-E are hosted on URLs that expire, so I needed to upload them to my storage. Naturally, I used Edge Store for this, which made storing the images easy and free.

• Set up the Edge Store project keys in your environment variables:

EDGE_STORE_ACCESS_KEY=xxx
EDGE_STORE_SECRET_KEY=xxx

• Configure the bucket for the images:

import { initEdgeStore } from "@edgestore/server";

const es = initEdgeStore.create();
const edgeStoreRouter = es.router({
  img: es.imageBucket(), // A simple public image bucket
});

export const backendClient = initEdgeStoreClient({
  router: edgeStoreRouter,
});

• Upload the image blob:

async function uploadImage(blob: Blob) {
  const res = await backendClient.img.upload({
    content: {
      blob,
      extension: "webp",
    },
  });
  return res.url;
}

P.S. I'm the creator of Edge Store, so I'm obviously biased towards it. 😇

Inserting Data into the Database

Once I had all the data and images ready, I inserted them into my database. I used Drizzle with Postgres on Supabase, but this approach works with any database technology you prefer.

async function insertRecipesIntoDB(recipes: Recipe[]) {
  await db
    .insert(tRecipe)
    .values(
      recipes.map((recipe) => ({
        name: recipe.name,
        description: recipe.description,
        ingredients: recipe.ingredients,
        steps: recipe.steps,
        duration: recipe.duration,
        servings: recipe.servings,
        image: recipe.image,
      }))
    )
    .execute();
}

Cost Considerations

The cost of text generation is negligible compared to image generation, which costs $0.04 per image ($0.02 if using dall-e-2). For example, generating 30 items costs about $1.20.

Full Code

Here's the complete code that brings everything together.

import { db } from "@/server/db";
import { tRecipe } from "@/server/db/schema";
import OpenAI from "openai";
import { zodResponseFormat } from "openai/helpers/zod";
import { z } from "zod";
import { backendClient } from "@/lib/edgestore";
import sharp from "sharp";

const openai = new OpenAI();

// Schema for the recipe data returned by OpenAI
const recipeSchema = z.object({
  recipes: z.array(
    z.object({
      name: z.string(),
      description: z.string(),
      ingredients: z.array(z.string()),
      steps: z.array(
        z.object({
          instruction: z.string(),
        })
      ),
      duration: z.number(),
      servings: z.number(),
    })
  ),
});

type Recipe = z.infer<typeof recipeSchema>["recipes"][number] & {
  image?: string; // Add an image field that will be populated on a future prompt
};

(async () => {
  const totalRecipes = 20; // Total number of recipes to generate
  const recipesPerBatch = 10; // Number of recipes to generate per batch
  const totalBatches = Math.ceil(totalRecipes / recipesPerBatch); // Calculate the total number of batches

  // Fetch existing recipe names from the database to avoid duplicates
  const allRecipeNames = (await db.query.tRecipe.findMany().execute()).map(
    (recipe) => recipe.name
  );

  for (let batchNumber = 1; batchNumber <= totalBatches; batchNumber++) {
    console.log(`Generating recipes batch ${batchNumber}/${totalBatches}`);

    // Generate a batch of new recipes, ensuring they are unique
    const recipes = await generateRecipes(
      recipesPerBatch,
      allRecipeNames.join(", ")
    );

    // Generate images for each recipe in the batch
    await generateImagesForRecipes(recipes);

    // Insert the new recipes into the database
    await insertRecipesIntoDB(recipes);

    // Update the list of all recipe names with the newly added recipes
    allRecipeNames.push(...recipes.map((recipe) => recipe.name));
  }
})();

async function generateRecipes(count: number, allRecipeNamesStr: string) {
  const prompt = `Generate ${count} unique and diverse recipes that are different from the following recipes: ${allRecipeNamesStr}.`;

  // Generate a list of recipes in JSON format using OpenAI's API
  const completion = await openai.chat.completions.create({
    model: "gpt-4o-mini",
    messages: [{ role: "user", content: prompt }],
    response_format: zodResponseFormat(recipeSchema, "recipes"),
  });

  // Extract the content from the AI's response
  const responseContent = completion.choices[0]?.message?.content ?? "";

  // Parse and validate the response using the defined schema
  const generatedRecipes = recipeSchema.parse(
    JSON.parse(responseContent)
  ).recipes;

  return generatedRecipes;
}

async function generateImagesForRecipes(recipes: Recipe[]) {
  const batchSize = 5; // Number of images to generate concurrently
  for (let i = 0; i < recipes.length; i += batchSize) {
    const batch = recipes.slice(i, i + batchSize);
    // Generate images for the current batch concurrently
    await Promise.all(
      batch.map(async (recipe) => {
        try {
          const imageUrl = await generateRecipeImage(recipe);
          recipe.image = imageUrl; // Add the image URL to the recipe
        } catch (error) {
          console.error(`Failed to generate image for ${recipe.name}:`, error);
        }
      })
    );

    console.log(`Waiting before the next batch...`);
    // The tier1 rate limit is 5 requests per minute 😢
    // You might be able to remove this delay if you have a higher tier
    await new Promise((resolve) => setTimeout(resolve, 50000)); // Wait for 50 seconds
  }
}

async function generateRecipeImage(recipe: Recipe) {
  console.log(`Generating image for ${recipe.name}`);

  const imagePrompt = `An appetizing photo of the dish: ${recipe.name}`;

  // Call OpenAI's image generation API with the prompt
  const res = await openai.images.generate({
    model: "dall-e-3",
    prompt: imagePrompt,
    size: "1024x1024",
  });

  // Extract the image URL from the response
  const url = res.data[0]?.url;
  if (!url) {
    throw new Error("No image url found");
  }

  // Optimize the image before uploading
  const blob = await optimizeImage(url);

  // Upload the optimized image to edgestore
  const esRes = await backendClient.img.upload({
    content: {
      blob,
      extension: "webp",
    },
  });

  return esRes.url;
}

async function optimizeImage(imageUrl: string) {
  // Fetch the image from the provided URL
  const response = await fetch(imageUrl);
  if (!response.ok) {
    throw new Error(`Failed to fetch image: ${response.statusText}`);
  }

  // Convert the response to an ArrayBuffer for processing
  const arrayBuffer = await response.arrayBuffer();

  // Use sharp to convert the image to WebP format
  const optimizedBuffer = await sharp(Buffer.from(arrayBuffer))
    .webp() // Default quality is 80
    .toBuffer();

  // Create a Blob from the optimized buffer
  return new Blob([optimizedBuffer], { type: "image/webp" });
}

async function insertRecipesIntoDB(recipes: Recipe[]) {
  await db
    .insert(tRecipe)
    .values(
      recipes.map((recipe) => ({
        name: recipe.name,
        description: recipe.description,
        ingredients: recipe.ingredients,
        steps: recipe.steps,
        duration: recipe.duration,
        servings: recipe.servings,
        image: recipe.image,
      }))
    )
    .execute();
}

Conclusion

Automating the creation of mock data with AI saved me a lot of time, especially when compared to manually generating and managing data. This approach scales well, whether you need a handful of items or hundreds. Plus, having realistic data adds to the overall presentation of your app, making it feel more complete. Although it requires some time investment initially, having the logic ready now means that I'll be able to do it much faster in future projects. If you’re in need of lots of mock data, you might want to try this approach!

Thanks for reading!

👋 Here are my links!

• YouTube

• X

Current solution

Let's start with the basics. To use my current process, I need to ① have an AWS account. This requires a credit card, which can be a pain for some users. Then, ② I need to set up a private S3 bucket and ③ link it to a CloudFront distribution, along with setting up all the necessary permissions. Finally, ④ I use presigned URLs generated from my API with the logic of who has access to what.

All in all, this current process works for me, but I'm always on the lookout for an easier, more efficient way of doing things. So I'm wondering - how are other people handling it? Are there any alternative methods out there that I might have missed? If anyone has any ideas or suggestions, I'd love to hear them in the comments section below.

Thanks in advance for any input you might have!

The idea

Here's the idea I have. I've been calling it "Edge Store".

With Edge Store, you would be able to:

• create a free account and get enough storage for at least 2 or 3 small projects.

• use the SDK to abstract the logic for handling image access and uploads.

• configure a JWT-based access control.

• enjoy the great performance on accessing the image from anywhere in the world by leveraging the AWS edge infrastructure.

You wouldn't need to worry about scalability and capacity in the paid plan, as Edge Store would use a pay-as-you-grow model. Additionally, here are some other features that I believe would be nice to have:

• Use the service web app to batch upload images

• Batch resize images

• Change extensions

• Automatically upload a small version of the image

I'd love to hear your thoughts on this idea so let me know what you think.

SDK Example

Client

To set up the client SDK, you would use your service public key, and optionally you could pass the JWT cookie name if you wish to control who can access and upload each image.

import { EdgeStore } from "@edge-store/client";

const edgeStore = new EdgeStore({
  publicKey: "your-public-key",
  jwtCookie: "your-jwt-cookie-name",
});

The following code is to upload an image. Under the hood, it would check the JWT with your configuration, generate the presigned URL, and then upload the image.

await edgeStore.uploadImage({
  file: file,
  name: "image.jpg",
  // Optionally you could resize your images on the fly.
  width: 300,
  height: 300,
});

And you can also use the SDK to get the image URL:

const src = await edgeStore.getImageSrc({
  name: "image.jpg",
  // Optional: images can be resized on the edge
  width: 100,
  height: 100,
});

Server

There is also a server-side SDK, that you can use in your backend to create your own custom logic for access control, instead of using the service's JWT access control.

import { EdgeStore } from "@edge-store/server";

const edgeStore = new EdgeStore({
  accessKey: "your-access-key",
  secretKey: "your-secret-key",
});

const signedUrl = await edgeStore.getSignedUrl({
  name: "image.jpg",
});

React component

I also want to build a react component to easily create customizable drag and drop image inputs in your react app. (And in the future, for other frameworks as well)

import { ImageInput } from "@edge-store/react";

const App = () => {
  return <ImageInput />;
}

Would you use it? Would you pay for it?

When it comes to services, it's important to ensure that they are up to the mark and provide value to the user. That's why I want to know your opinion on this particular service. What do you think of it? Is it worth it to join the waiting list on the landing page or comment on this post?

Building in public

Welcome to my journey of building my first startup! I’m so excited to be starting on this journey and I hope to share the whole process with you through my YouTube channel. I want to detail the process as best as I can so that it can serve as a reference for other aspiring entrepreneurs looking to build their startups.

I’m sure this process is going to be a rollercoaster filled with highs and lows, and I’m sure it’s going to be one of the most challenging experiences I’ve ever faced. But I’m ready for the journey and I’m sure it’s going to be a rewarding experience.

Here is the first video of the journey: https://youtu.be/7oZw4gZjYiw

Thanks for reading!

👋 Here are my links!

• YouTube

• Twitter

• Tasks that take a long time to finish.

• Tasks that use a lot of CPU and memory.

• Tasks that overloads you database, and need to be scheduled for when people are not using the app. Those kinds of tasks are usually developed as batch jobs.

In this tutorial we will learn how to:

• 💻 Use TypeScript with Commander to create a CLI.

• 📦 Dockerize the cli.

• 🌥 Deploy and run it on AWS.

It is possible that TypeScript might not be the best suited language for your use case. But the concepts from this tutorial can be used for deploying batch jobs in other languages as well. You will just need to adapt the first part.

※ Following this tutorial might result in some costs from used AWS Resources. (It should be just a little bit, though)

Requirements

• Have node and npm installed.

  • Check with node --version and npm --version.

• Have Docker installed and running.

  • Check with docker version and make sure both the 'Client' and 'Server' versions are displayed.

• Have aws-cli installed and configured for your account.

  • Check by trying to list you s3 buckets with aws s3 ls

Project structure

To start the project, run the following command from inside the projects empty folder.

npm init -y

This will generate a package.json file with some default values.

After the whole tutorial, our folder structure should look something like this:

Setup TypeScript

First, let's install the necessary packages.

npm i -D typescript ts-node
npm i source-map-support

In the next section, we will register the source-map-support in our main ts file. This will make the error's stacktrace point to the TypeScript file instead of the compiled file.

Now let's make a simple configuration file for TypeScript in the root of the project.

// tsconfig.json
{
  "compilerOptions": {
    "target": "esnext",
    "module": "commonjs",
    "sourceMap": true,
    "lib": ["es2022"],
    "outDir": ".out",
    "rootDir": "bin",
    "strict": true,
    "types": ["node"],
    "esModuleInterop": true,
    "resolveJsonModule": true
  }
}

In the configuration above, we chose to write our TypeScript code inside bin and the compiled code will be outputted to .out. Feel free to change this to what you like.

※ You might want to add the following configuration to your VSCode workspace settings, so that VSCode uses the project's TypeScript version instead of the version bundled with the IDE.

"typescript.tsdk": "node_modules/typescript/lib"

Setup Commander

First, we will install Commander.

npm i commander

Now we will create our first command:

// bin/commands/greeting/index.ts
import { Command } from 'commander';

const folderName = __dirname.split('/').slice(-1)[0];

/**
 * This is an example command
 * that will take your name as an argument
 * and say hello to you in the console.
 */
export default new Command()
  .command(folderName)
  .description('Say hello to you!')
  .argument('<string>', 'Your name')
  .option('-s, --suffix <char>', 'Suffix greetings', ',')
  .action((name: string, options: { suffix: string }) => {
    console.log(`Hello, ${name}! ${options.suffix}`);
  });

Now, we will create a script that exports all commands from inside the commands directory. This will allow us to add new commands just by creating the command file. Without having to add a new export for every command we add.

// bin/commands/index.ts
/* eslint-disable @typescript-eslint/no-var-requires */
import { Command } from 'commander';
import { readdirSync } from 'fs';

const commands: Command[] = [];

readdirSync(__dirname + '/').forEach(function (file) {
  // This will import all files inside the commands directory (except this one)
  if (!file.startsWith('index.')) commands.push(require('./' + file).default);
});

export default commands;

And finally, we will create the main file that will create our cli, and add all commands to it.

// bin/index.ts
#!/usr/bin/env node
import 'source-map-support/register';
import { Command } from 'commander';
import commands from './commands';

const program = new Command();

program.name('cli').description('TypeScript CLI').version('0.0.0');

commands.forEach((cmd) => {
  program.addCommand(cmd);
});

program.parse();

Run the CLI with ts-node

Now we can run our command.

npx ts-node bin/index.ts greeting Ravi -s 'Nice name!'

> Hello, Ravi! Nice name!

We can add this command as a script in our package.json

{
  // ...
  "scripts": {
    "cli": "ts-node bin/index.ts"
  },
  // ...
}

Now we can run the same command with:

npm run cli -- greeting Ravi -s 'Nice name!'

Dockerize

Let's start by creating the Dockerfile.

FROM node:16.16.0-slim

WORKDIR /cli

# Leverage the cached layers to only reinstall packages
# if there are changes to `package.json` or `package-lock.json`
COPY package.json package-lock.json ./
RUN npm ci

# Copy the rest of the files and compile it to javascript
COPY . .
RUN npx tsc \
    && chmod +x .out/index.js

ENTRYPOINT [ ".out/index.js" ]

We want to ignore some files in the COPY command. For this we will create a .dockerignore file.

# .dockerignore
node_modules
.out

Dockerfile
.dockerignore

Now we can build it by running:

docker build -t typescript-cli .

# If you are using a Mac device with an apple chip (M1 or M2), build with the following command:
# This is needed to run on Fargate
docker buildx build --platform=linux/amd64 -t typescript-cli .

And finally we can run the job with:

docker run --rm -it typescript-cli greeting Ravi -s 'Nice name!'

> Hello, Ravi! Nice name!

Push to ECR

First, we need to create the ECR repository.

• Go to the ECR Console.

• Create a new private repository named typescript-cli.

  

Now, we need to push our local image to the ECR repository.

• Login to ECR.

aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<region>.amazonaws.com

• ※ Replace the <***> with your information.

• Tag your image for the ECR repository

docker tag typescript-cli:latest <aws_account_id>.dkr.ecr.<region>.amazonaws.com/typescript-cli:latest

• Push your image

docker push <aws_account_id>.dkr.ecr.<region>.amazonaws.com/typescript-cli:latest

Setup AWS Batch

Now, we are ready to setup the job in AWS Batch

Create an Execution Role

For AWS Batch to be able to access the ECS related services, we need to create an IAM Role for it. (We're going to use it when creating the 'Job Definition')

First, let's go to the IAM > Roles console. And click in 'Create role'.

Then, search for the 'Elastic Container Service' and select 'Elastic Container Service Task'.

Next, we need to search for 'ecs' and select 'AmazonECSTaskExecutionRolePolicy'. This will give the necessary permissions to access the ECR image we pushed.

Finally, we just choose a name for the role, and click 'Create role'. Let's name it 'ecsTaskExecutionRole'.

Create a Compute Environment

Let's create a Compute Environment.

For that, we need to go to the Batch console > Compute Environment. And then create a new environment.

The only thing we need to set here is the [Compute environment name]. Let's set it to 'ts-batch'.

The rest can be kept on the default values.

※ Make sure Fargate is selected on the provisioning model.
※ Usually we want to run the Batch job inside a Private Subnet. But for the demo, just keep the defaults and it should work.

Create a Job Queue

After we see the Compute Environment created as 'Valid' and 'Enabled'. We can create our job queue.

Go to the job queue tab, and create one.

Just set the [Job queue name] as 'ts-batch-queue' and select the compute environment we created.

Create a Job Definition

Finally, we can create our job definition.

Here is how it looks like:

※ If your batch is running in a public subnet, you need to select the 'Assign public IP', otherwise it wont be able to access the internet and will fail trying to pull the ECR image. If it is on a private subnet with a route to a NAT Gateway on a public subnet, then you should uncheck the 'Assign public IP' since it will be able to access the internet through the NAT Gateway's IP.

Run the job

Now we can run our job.

For that, in the Job Definition tab, select the job definition we've created and click on 'Submit new job'

Now we just need to choose a name for the job (this can be anything you like) and select the queue we've created. If we want, we can also change the default command and other values we have set in the job definition.

After that, we are able to check the running jobs on the 'Jobs' tab. (Click the refresh button if nothing shows up)

If we click on a job, we can see its details.

And also check the logs.

Conclusion

There are many other services that allows us to run batch jobs. and this is definitely not the easiest way to do it. But if you want to leverage the AWS ecosystem, then its definitely worth it.

The pricing is also nice, since you basically only pay for when your jobs are running.

To be honest, I wish that the 'Commander' package was more typesafe. So I'll keep looking for a better package to do it. But from what I saw, 'Commander' is the most used package for building a TypeScript CLI.

Next Steps

• AWS CDK (IaC)

  • Doing everything from the console is good when you are doing it for the first time, so you can understand better how everything fits together, but for more serious projects I would consider using a tool to write all the infrastructure as code, and to be able to deploy it all with a simple command. My recommendation for that is AWS CDK. Although there are other options as well. (e.g. Terraform)

• Schedule with Event Bridge

  • We submitted the job manually, but we can trigger it in a bunch of different ways. One way that is very common is using Event Bridge to schedule the batch job. So that it runs on a recurring schedule that you can configure.

• Choose a faster language

  • When I can, I usually default to TypeScript. But I recognize the it might not be the best language for every project. If you need to do data manipulation, you might want to choose Python. Or if you just want to do general things, but need more performance you can choose Go or Rust. And there are many other choices out there.

Thanks for reading!

👋 Let's connect!

• Twitter

• LinkedIn

You might have noticed that with many React packages, you have to wrap your app with a Provider component.
The reason for that is that those packages are using Contexts so you can easily access the component's variables and functions from anywhere in the app.
And that's what we are going to be learning to do in this tutorial.

The following image shows how the code would look like with and without the use of a provider:

With the provider, you will still need to code the left part in the image. The difference is that you will do it just once, at the base of the application, and will be able to reuse it anywhere you want.

The app structure

I'll be using Next.js and Material UI for this tutorial, but the same concepts can be replicated in a normal React application and with any other component library, or even for custom dialogs built with tailwind.

You can check the final code in the github repo: https://github.com/perfectbase/dialog-and-snackbar-react

The project was created with the following command:

npx create-next-app@latest --typescript

And the necessary packages for Material UI were installed with this command:

npm i -E @mui/material @emotion/react @emotion/styled

Here is the final folder structure:

The Dialog Provider

First let's take a look on how the final provider code looks like so I can start explaining it.

// components/DialogProvider/index.tsx
import {
  Button,
  Dialog,
  DialogActions,
  DialogContent,
  DialogContentText,
  DialogTitle,
} from '@mui/material';
import { createContext, useContext, useState } from 'react';

interface DialogOptions {
  title: string;
  message?: string;
}

interface PromiseInfo {
  resolve: (value: boolean | PromiseLike<boolean>) => void;
  reject: (reason?: any) => void;
}

type ShowDialogHandler = (options: DialogOptions) => Promise<boolean>;

// Create the context so we can use it in our App
const DialogContext = createContext<ShowDialogHandler>(() => {
  throw new Error('Component is not wrapped with a DialogProvider.');
});

const DialogProvider: React.FC<{ children: React.ReactNode }> = ({
  children,
}) => {
  const [open, setOpen] = useState(false);
  const [options, setOptions] = useState<DialogOptions>({
    title: '',
  });
  const [promiseInfo, setPromiseInfo] = useState<PromiseInfo>();
  const showDialog: ShowDialogHandler = (options) => {
    // When the dialog is shown, keep the promise info so we can resolve later
    return new Promise<boolean>((resolve, reject) => {
      setPromiseInfo({ resolve, reject });
      setOptions(options);
      setOpen(true);
    });
  };
  const handleConfirm = () => {
    // if the Confirm button gets clicked, resolve with `true`
    setOpen(false);
    promiseInfo?.resolve(true);
    setPromiseInfo(undefined);
  };
  const handleCancel = () => {
    // if the dialog gets canceled, resolve with `false`
    setOpen(false);
    promiseInfo?.resolve(false);
    setPromiseInfo(undefined);
  };
  return (
    <>
      <Dialog open={open} onClose={handleCancel}>
        <DialogTitle>{options.title}</DialogTitle>
        <DialogContent sx={{ minWidth: '400px' }}>
          {options.message && (
            <DialogContentText>{options.message}</DialogContentText>
          )}
        </DialogContent>
        <DialogActions>
          <Button onClick={handleCancel}>Cancel</Button>
          <Button variant="contained" onClick={handleConfirm}>
            Confirm
          </Button>
        </DialogActions>
      </Dialog>
      <DialogContext.Provider value={showDialog}>
        {children}
      </DialogContext.Provider>
    </>
  );
};

// By calling `useDialog()` in a component we will be able to use the `showDialog()` function
export const useDialog = () => {
  return useContext(DialogContext);
};

export default DialogProvider;

→We want to be able to await until the user confirms or cancels the dialog.
→For that, we need to return a Promise.
→We want to resolve the Promise only after the user makes an action, so we keep the resolve function in the component's state.
→After the user confirms or cancels the dialog, we resolve with true or false.

Wrapping the app with the provider

Now we need to wrap the app with the provider, so we can call the showDialog() function from anywhere on our app.

// pages/_app.tsx
import type { AppProps } from 'next/app';
import DialogProvider from '../components/DialogProvider';

function MyApp({ Component, pageProps }: AppProps) {
  return (
    <DialogProvider>
      <Component {...pageProps} />
    </DialogProvider>
  );
}

export default MyApp;

Call it from any page or component

We can call it like this:

// ...
  const showDialog = useDialog();

  const handleShowDialog = async () => {
    const confirmed = await showDialog({
      title: 'Custom Dialog',
      message: 'Custom message...',
    });
    if (confirmed) {
      console.log('confirmed');
    } else {
      console.log('canceled');
    }
  };
// ...

You can see that the code awaits until you 'confirm' or 'cancel' the dialog.
This helps you keep your code cleaner and easy to read.

What about a Snackbar?

The same logic can be used to create a Snackbar Provider.

Here is how my code looks like:

// components/SnackbarProvider/index.tsx
import { Alert, Snackbar } from '@mui/material';
import type { AlertColor } from '@mui/material';
import { createContext, useContext, useState } from 'react';

type ShowSnackbarHandler = (message: string, severity: AlertColor) => void;

const SnackbarContext = createContext<ShowSnackbarHandler>(() => {
  console.error('Component is not wrapped with a SnackbarProvider.');
});

const SnackbarProvider: React.FC<{ children: React.ReactNode }> = ({
  children,
}) => {
  const [open, setOpen] = useState(false);
  const [message, setMessage] = useState('');
  const [severity, setSeverity] = useState<AlertColor>('success');
  const handleClose = (
    _event: React.SyntheticEvent | Event,
    reason?: string
  ) => {
    if (reason === 'clickaway') {
      return;
    }
    setOpen(false);
  };
  const showSnackbar: ShowSnackbarHandler = (message, severity) => {
    setMessage(message);
    setSeverity(severity);
    setOpen(true);
  };
  return (
    <>
      <Snackbar
        open={open}
        autoHideDuration={4000}
        onClose={handleClose}
        anchorOrigin={{ vertical: 'top', horizontal: 'center' }}
        sx={{ minWidth: '50vw' }}
      >
        <Alert onClose={handleClose} severity={severity} sx={{ width: '100%' }}>
          {message}
        </Alert>
      </Snackbar>
      <SnackbarContext.Provider value={showSnackbar}>
        {children}
      </SnackbarContext.Provider>
    </>
  );
};

export const useSnackbar = () => {
  return useContext(SnackbarContext);
};

export default SnackbarProvider;

In this case is a little simpler because we are not using Promises here.
You could add the Promise logic if you want your snackbar to have actions.

npm package?

I couldn't find a npm package for this. That's the main reason I decided to make this tutorial.

If people want, I could make a package with a customizable version of both providers. If you think this would be a good idea let me know in the comments or tell me on Twitter.

Conclusion

Learning how to use Contexts in React can open a lot of doors and it will definitely help you create the PerfectBase 😉 structure for your future apps!

Example Code Repository

https://github.com/perfectbase/dialog-and-snackbar-react

Thanks for reading!

👋 Let's connect!

• Twitter
• LinkedIn

here is the final sample code: https://github.com/perfectbase/serverless-graphql

Stack

• Serverless Framework

• Webpack

• TypeScript

• Apollo

Some nice features

• TypeScript

  • A strongly typed language helps you prevent writing buggy code and it becomes a lot easier to refactor when you need to.

  • If you are using some javascript framework, chances are that you are already using TypeScript in your frontend. Using the same language in the backend can help you keep productive, while changing from backend to frontend development

• Run Locally with a fast Hot Reload (No server restart)

  • Nowadays it's kind of unthinkable to have a development environment where you cant run the code locally, or that you need to wait a build task so that you can test your code. Nodemon has helped us with that for a long time, but a server restart also takes some seconds that can be annoying. By using serverless-offline you will have an almost instant hot reload, so you can modify your code and test it without breaking your thinking process.

• Apollo Studio

  • Now with apollo 3, we have a different graphql playground. I love how Apollo made it easy to build the Queries and test the GraphQL API's.

• Cheap pricing with serverless

  • The serverless pricing model allows you to pay just for what you use. During development, the price will probably never leave the free tier.

Folder Structure

Here is how the final folder structure is going to look like:

sls-graphql/
├─ src/
│  ├─ functions/
│  │  ├─ graphql/
│  │  │  ├─ index.ts
│  │  │  ├─ handler.ts
│  ├─ lib/
│  │  ├─ helpers/
│  │  │  ├─ lambdaHelper.ts
├─ .babelrc
├─ .env
├─ .gitignore
├─ package-lock.json
├─ package.json
├─ serverless.ts
├─ tsconfig.json
├─ tsconfig.paths.json
├─ webpack.config.js

Setup TypeScript

First, lets start the node project by running the following command:

npm init -y

this will create a package.json file with the default configurations.

Now lets install some TypeScript related packages.

npm i -D typescript tsconfig-paths @types/node

Then we will create 2 files: tsconfig.json and tsconfig.paths.json

Here is how mine look like.

// tsconfig.paths.json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@functions/*": [
        "src/functions/*"
      ],
      "@libs/*": [
        "src/libs/*"
      ]
    }
  }
}

// tsconfig.json
{
  "extends": "./tsconfig.paths.json",
  "compilerOptions": {
    "moduleResolution": "node",
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "esModuleInterop": true,
    "removeComments": true,
    "sourceMap": true,
    "lib": [
      "esnext"
    ],
    "module": "commonjs",
    "target": "es2022",
  },
  "include": [
    "src/**/*.ts",
    "serverless.ts"
  ],
  "ts-node": {
    "require": [
      "tsconfig-paths/register"
    ]
  }
}

The tsconfig.paths.json will allow us to import packages by using:
import something from '@libs/helpers/...'
instead of:
import something from '../../helpers/...'

※ If you are using VSCode, you might want to change your workspace settings, so that the editor recognizes the installed TypeScript version, instead of the default version bundled with the IDE. for that, just add the following configuration to your workspace settings json file:

"typescript.tsdk": "node_modules\\typescript\\lib"

Setup Serverless Framework

For the serverless framework setup, we will need the following packages:

npm i -D @serverless/typescript serverless serverless-offline serverless-webpack

Did you know we can create the Serverless Framework configuration with a .ts file instead of a .yml file? With this you get all the auto completion and type checking functionality!

Here is how my serverless.ts looks like:

// serverless.ts
import type { AWS } from '@serverless/typescript';
import graphql from '@functions/graphql';

const serverlessConfiguration: AWS = {
  service: 'sls',
  frameworkVersion: '3',
  useDotenv: true,
  package: {
    individually: true,
  },
  custom: {
    stage: '${opt:stage, "local"}',
    config: {
      local: {
        NODE_ENV: 'development',
      },
    },
    region: '${env:AWS_REGION}',
    webpack: {
      webpackConfig: './webpack.config.js',
      includeModules: {
        // You can delete this setting if you dont use aws-sdk.
        // If you use it, this setting will exclude it from the bundle,
        // since its included inside the lambda by default
        forceExclude: 'aws-sdk',
      },
    },
  },
  plugins: ['serverless-webpack', 'serverless-offline'],
  provider: {
    name: 'aws',
    region: '${self:custom.region}' as any,
    runtime: 'nodejs14.x',
    apiGateway: {
      minimumCompressionSize: 1024,
      shouldStartNameWithService: true,
    },
    environment: {
      AWS_NODEJS_CONNECTION_REUSE_ENABLED: '1',
      NODE_ENV:
        '${self:custom.config.${self:custom.stage}.NODE_ENV, "production"}',
      ENV: '${self:custom.stage}',
      REGION: '${self:custom.region}',
    },
    lambdaHashingVersion: '20201221',
  },
  functions: {
    graphql,
  },
};

module.exports = serverlessConfiguration;

You will also need a .env file for when you are ready to deploy the api to your aws account.

AWS_PROFILE=default
AWS_REGION=us-east-1

※ For deployment you will need to have your aws cli installed and configured: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html

Setup Webpack

Here is what we need to install for the Webpack setup:

npm i -D webpack webpack-node-externals @types/webpack-node-externals tsconfig-paths-webpack-plugin fork-ts-checker-webpack-plugin babel-loader @babel/core @babel/preset-env @babel/preset-typescript

We need a .babelrc file so that our TypeScript code can by transpiled.

// .babelrc
{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": {
          "node": "14"
        }
      }
    ],
    [
      "@babel/preset-typescript"
    ]
  ]
}

Now we can add the webpack configuration:

// webpack.config.js
const path = require('path');
const slsw = require('serverless-webpack');
const nodeExternals = require('webpack-node-externals');
const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');
const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');

module.exports = {
  context: __dirname,
  mode: slsw.lib.webpack.isLocal ? 'development' : 'production',
  entry: slsw.lib.entries,
  devtool: 'source-map',
  target: 'node',
  externals: [nodeExternals()],
  resolve: {
    extensions: ['.js', '.jsx', '.json', '.ts', '.tsx'],
    plugins: [
      new TsconfigPathsPlugin({
        configFile: './tsconfig.paths.json',
      }),
    ],
  },
  output: {
    libraryTarget: 'commonjs2',
    path: path.join(__dirname, '.webpack'),
    filename: '[name].js',
  },
  module: {
    rules: [
      {
        // Include ts, tsx, js, and jsx files.
        test: /\.(ts|js)x?$/,
        exclude: [/node_modules/, /\.serverless/, /\.webpack/],
        use: ['babel-loader'],
      },
    ],
  },
  plugins: [
    new ForkTsCheckerWebpackPlugin(),
  ],
};

Setup Apollo

Now that we have all the structure ready, we just need to implement the api.
For this we will need these packages:

npm i apollo-server-lambda express source-map-support

Finally we can create the api functions:

// src/functions/graphql/handler.ts
// This file is the actual GraphQL API logic
import express from 'express';
import { ApolloServer, gql } from 'apollo-server-lambda';
import { IncomingMessage, OutgoingMessage } from 'http';

const typeDefs = gql`
  type Query {
    hello: String
  }
`;

const resolvers = {
  Query: {
    hello: () => 'world',
  },
};

const apolloServer = new ApolloServer({
  typeDefs,
  resolvers,
  csrfPrevention: true,
  context: ({ express }): Context => {
    return { req: express.req, res: express.res };
  },
});

export interface Context {
  req: IncomingMessage;
  res: OutgoingMessage;
}

export const main = apolloServer.createHandler({
  expressAppFromMiddleware(middleware) {
    const app = express();
    // Enable CORS for all methods
    app.use(function (_req, res, next) {
      res.header('Access-Control-Allow-Origin', '*');
      res.header(
        'Access-Control-Allow-Headers',
        'Origin, X-Requested-With, Content-Type, Accept'
      );
      next();
    });
    app.use(middleware);
    return app;
  },
});

// src/functions/graphql/index.ts
// This file is the lambda configuration for the api path
const handlerDir = `${__dirname
  .split(process.cwd())[1]
  .substring(1)
  .replace(/\\/g, '/')}`;

const slsFunc = {
  handler: `${handlerDir}/handler.main`,
  events: [
    {
      http: {
        method: 'get',
        path: 'graphql',
      },
    },
    {
      http: {
        method: 'post',
        path: 'graphql',
      },
    },
  ],
};

export default slsFunc;

Run and test the api

Now that we have our api, we can run it locally with the following command:

npx sls offline --stage local

You can check your api at: http://localhost:3000/local/graphql

You will probably want to add this command to the package.json so that you can run the server by using npm run dev.

My scripts config in the package.json looks like this:

// package.json
{
// ...
  "scripts": {
    "dev": "sls offline --stage local",
    "deploy:dev": "sls deploy --stage dev",
    "deploy:prd": "sls deploy --stage prd"
  },
// ...
}

※ If your IDE shows some errors, you might need to restart your window so that it picks up all the new configurations.

Next Steps

You are now ready to start adding functionality to your API!
I would recommend you to choose an ORM and a GraphQL library.

just some examples:

• ORM

  • TypeORM

  • PRISMA

• GraphQL

  • TypeGraphQL

  • Nexus

  • GraphQL Tools

Caveats

• Might cost a little if you want to connect to an RDS instance.

  • If you have an RDS instance, chances are that its is inside a private subnet. That means that if you want to connect your lambda to the RDS, you will need to put your lambda inside your VPC. If you want your lambda to have internet access from inside the VPC, you will need a NAT Gateway, that costs by the hour, and can be a little expensive for simple projects.

• It can be a little complicated to setup Subscriptions.

  • Lambdas are short lived cloud functions. That means that they don't work well with Websockets. If you want to use Subscriptions with your lambda GraphQL api, it is possible, but you will need some setup. You could use ApiGateway for websockets, and use Redis as a PubSub, for example. There are also some serverless subscription solutions that you might want to take a look. (e.g. graphql-lambda-subscriptions)

Alternatives

We all know by now that there is no solution that works best for every project. If the solution in this article does not fit your project, here are some alternatives to check out.

Amplify with AppSync

AWS has an out of the box serverless solution for GraphQL APIs.

• Advantages

  • Works great with Cognito authentication and DynamoDB.

  • You can also have custom lambda resolvers.

  • Subscriptions works and its completely serverless.

• Disadvantages

  • I didn't like the local development experience that much. Specially when using custom lambdas and running dynamodb locally on docker. It's been some time since I last tried it, maybe its better now.

  • If you are like me and likes to customize a lot of things, you will probably have a hard time here. (e.g. if you would like to have a Code first approach with TypeGraphQL)

Dockerized server to Fargate

This is probably the most customizable solution. If you choose this approach, you might want to look at some backend framework like NestJS.

• Advantages

  • Its a docker environment, so you can customize it as you could do it with an old school server.

  • You can link AWS Secrets Manager with the container's environment variables, to increase security of secrets. (big companies require it a lot.)

• Disadvantages

  • It's not serverless, so it will cost while it's running. (If you make the container small and setup auto scale, you can make it fairly cheap.)

  • If you want to make it scalable (running in multiple containers) you will have to think on how to setup subscriptions. (Maybe an external Redis as a PubSub?)

Example Code Repository

You might want to checkout some other configurations, like the .gitignore file and linter setup↓↓↓

github.com/perfectbase/serverless-graphql

Thanks for reading!
Follow me on Twitter: https://twitter.com/RaviCoding