DEV Community: Sabin Adams

What is an API? A Beginner's Guide

Sabin Adams — Wed, 02 Aug 2023 18:36:43 +0000

The world of software relies on the ability of different applications and software to interact with each other by sharing data and communicating. This communication is typically done through APIs (Application Programming Interfaces).

In this article, we will take a close look at what an API is and how they enable developers to effectively and efficiently build software.

Understanding APIs

Most applications in this day and age are data-driven, relying heavily on data from multiple services. These services are typically separate and manage isolated data sets specific to the context of that service. What happens, however, when a service needs to retrieve data or perform an action that is outside its own context?

As a basic example, consider a multi-tier application with a:

Frontend application
Backend application
Database

What happens when the frontend application's interface allows you to add data to your database? For security reasons, the frontend application should not have direct access to the database, so how would you go about creating that data?

In this example, the backend application may provide an API that exposes operations that allow you to perform CRUD (create, read, update, delete) operations on your database.

The API's role

The way these operations are exposed may vary depending on the type of API the backend application provides, however in general an API will expose some set functions or endpoints that allow you to perform pre-defined sets of operations.

These pre-defined operations act as "contracts" between the two services. For any given operation, you should be able to request its invocation and expect some sort of response back. Often, you will provide data via a request body or URL variable and expect a JSON response back, however, this varies based on the flavor of API you are working with.

We won't cover the various types of APIs in this article, however, to name a few there are:

REST
GraphQL
gRPC
SOAP

The common factor between all of these and the important takeaway of this section is:

APIs are software intermediaries that allow two services to communicate with each other by passing data to and from each other.

Benefits of using APIs

Without APIs, there would be no such thing as third-party services such as Stripe and Mailchimp, and front-end applications would have no way to communicate with a server.

Every application or website you use is likely communicating with some sort of API. This is why APIs are such a powerful concept. Rather than re-inventing the wheel when adding things like payments, email services, mapping data, etc... APIs allow you to re-use existing functionality simply and consistently.

APIs allow you to consistently re-use functionality without re-inventing the wheel.

Conclusion

To recap, APIs allow applications and software to communicate with each other using pre-defined, repeatable actions exposed by the API.

APIs are commonly provided by service providers to give you access to easily implement payments, email services, and much more. Along with this, essentially any multi-tier application will need to make use of some sort of custom API to allow client-side applications to interact with data from a database.

The Most Valuable Trait of a Developer: Curiosity

Sabin Adams — Fri, 28 Jul 2023 17:32:34 +0000

Diving into the world of a software developer can be daunting. There are a million things to learn, and the more you learn the more you find you still need to learn!

This can be a challenging reality when working in the field alongside other professionals. The goal of this article is to ease your mind about this a help you focus on what matters as a developer.

Why curiosity is so important

There are many essential qualities that characterize a successful developer. A successful developer should be a good communicator, a team player, organized, etc... but there is something I see as a precursor to all of these.

These characteristics describe behaviors you exhibit while working in a job you love. They come from a genuine interest in your work and show themselves through effective professionalism.

This genuine interest, or curiosity, is a necessary prerequisite to the others in my opinion. Without a true curiosity about how things work, how to progress in your career, and how to grow as a developer, the other traits become infinitely more difficult.

How to stay curious

All developers go through the ups and downs of curiosity throughout their careers. Varying levels of burnout affect your mindset and interest in growing as a developer, however, there are tricks to keep that fire alive:

Pace yourself

This one may seem counterintuitive, however, I believe a major factor in maintaining a healthy curiosity about your work is to set healthy limits to the amount of time you spend honing your skills.

You may think pouring yourself day and night into learning and building knowledge is the secret to becoming a great developer. This behavior is actually detrimental but points to a positive trait. The mindset behind that (unhealthy) behavior is curiosity!

Rather than focusing on pouring excess amounts of time into learning and practicing, focus on maintaining that curiosity and desire to learn by giving yourself time each day to dedicate to learning.

Be open to trying new things

Another way to remember that you are not in school. You aren't being forced to learn any one thing. If one thing starts to feel like work, expand your expertise and try something new!

Have you been playing with databases for too long and feel like you don't ever want to write a SQL query again? Try learning some new CSS tricks!

Being open to trying new things not only expands your technical toolbelt but also gives you time away from whatever topic you were becoming burned out on.

Set goals for yourself

The last trick to help you maintain a healthy curiosity in your development journey is to set goals for yourself.

Look at what other developers out there are doing. Become active on Twitter, Discord, and other communities where people share their accomplishments. Doing this will help you formulate ideas about accomplishments you would like to achieve.

As you find things that spark your interests, take note! Set a goal to get your hands on that technology and understand it. You don't need to become an expert in something to justify spending time with it. Set small goals to incrementally build your knowledge across many different tools and paradigms.

The result

We've talked about why curiosity is so important and how to maintain your curiosity, but what will this do for you?

As mentioned before, curiosity is the precursor for other traits of a successful developer. Being curious will:

Be apparent to your team and show you care about your job
Help you to be constantly building your technical knowledge
Give you genuine interest in understanding how to communicate your knowledge effectively
Help you be constantly aware of your interests and goals in your career

All of these are incredibly important during your career and will be the defining factors of how you grow as a developer.

I hope this helped ease your mind by giving you one primary goal: build, maintain and enjoy your curiosity in the wide field of software development!

Add Sign In and Sign Up to Your React App With Clerk

Sabin Adams — Wed, 26 Jul 2023 23:08:32 +0000

It can look like a daunting task if you haven't had to add authentication to your application before. This is because there are so many things to consider:

Where do I store my user data?
How do I make sure it is secure?
What should the sign-up and sign-in flows look like?

Fortunately, many tools out there take away these concerns and give you a clean and simple way to set up secure authentication in your applications.

My personal favorite of these tools is Clerk.

In this article, you will learn how to use Clerk to add sign-in and sign-up functionality to a React application.

The starting point

To start a React application, you will use Next.js. Next.js provides a framework that allows you to easily build React applications of varying complexity and provides built-in niceties such as routing, bundling, and local development tools.

In the past, we may have opted for a simple React application without a framework, however, the React team now suggests using a framework such as Next.js or Remix to scaffold your React applications.

See the React docs for more information.

To start a Next.js application, navigate via the terminal into a folder where you would like to save your project and run the following command:

$ npx create-next-app@latest

You will be asked for a few bits of information. For this tutorial, you should use all of the default values except opt out of TypeScript by selecting No when asked if you would like to use TypeScript.

Navigating the project

Once your project is set up and you have installed your node modules, you should have a complete project ready to be run locally.

If you did not opt to have your node_modules installed, run npm i in the terminal.

The bulk of your application is stored in src/app. Here you will find a file named page.js which contains the boilerplate page the project comes with.

To start your development server run the following command in your terminal:

$ npm run dev

After running that command, head to http://localhost:3000 in your browser to see what the starter project looks like.

To stop the development server hit CTRL+C in the terminal that is running the process.

For more information about Next.js projects, check out their documentation.

Add Clerk

With a project up and running, you are now ready to begin setting up authentication for that project using Clerk.

Create an account

Head over to Clerk and sign up. After signing up you should land in a personal workspace with the option to create an application.

Click Add application:

This will open a view that allows you to customize the sign up and sign in elements and choose your authentication methods. Customize this however you like.

Store the application secrets

The important piece comes after this. The page you are redirected to contains your project's secrets: NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY and CLERK_SECRET_KEY.

Copy those values by clicking the clipboard icon.

Those values will need to be stored securely for your application to access. At the root of your application create a new file named .env:

$ touch .env

Paste the contents you copied into this file:

# .env
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_fake_cHJvYmFmbGUtY2hhbW9pcy0zNi5jbGVyay5hY2NvdW50cy5kZXYk
CLERK_SECRET_KEY=sk_fake_gdcBCVQM0TEQaA5krQI154JbRWJDgWIKP5LHSwuYw3

Never store or post your keys anywhere they can be publicly accessed! These values are fake.

Set up the Clerk provider

To begin using Clerk in your application, you first need to install it.

Install Clerk's Next.js SDK with the following command:

$ npm i @clerk/nextjs

This package gives you access to various tools Clerk provides, including a React context provider which provides session and user data to Clerk's components.

Within src/app/layout.js, import ClerkProvider and use it to wrap the application:

// src/app/layout.js

import "./globals.css";
import { Inter } from "next/font/google";
import { ClerkProvider } from "@clerk/nextjs"; // 👈🏻

const inter = Inter({ subsets: ["latin"] });

export const metadata = {
  title: "Create Next App",
  description: "Generated by create next app",
};

export default function RootLayout({ children }) {
  return (
    <ClerkProvider> // 👈🏻
      <html lang="en">
        <body className={inter.className}>{children}</body>
      </html>
    </ClerkProvider> // 👈🏻
  );
}

The layout.js file is a special file in Next.js. Read more about it here.

Add the authentication middleware

The next step is to add middleware to the application. This middleware will intercept every navigation and verify the current user and session have access to the destination page.

Create a new file in src/ named middleware.js:

$ touch src/middleware.js

Inside that file, add the following code snippet:

// src/middleware.js

import { authMiddleware } from "@clerk/nextjs";

// This example protects all routes including api/trpc routes
// Please edit this to allow other routes to be public as needed.
// See https://clerk.com/docs/nextjs/middleware for more information about configuring your middleware
export default authMiddleware({});

export const config = {
  matcher: ["/((?!.*\\..*|_next).*)", "/", "/(api|trpc)(.*)"],
};

This middleware.js file is another special file that Next.js handles and applies automatically. See more information here.

Within this middleware, you can configure which pages in your application are protected and should only be viewed by signed-in users.

Add The Sign-In Page

With the middleware and Clerk context in place, we are now ready to build a sign-in page.

Create a new directory in src/app named sign-in/[[...sign-in]] and a new file inside of that new directory named page.js

$ mkdir -p "src/app/sign-in/[[...sign-in]]"
$ touch src/app/sign-in/'[[...sign-in]]'/page.js

The file path for this looks strange because it uses Next.js's new App directory with file-based routing. This means Next.js looks at the files and folders in the src/app directory and builds your application's routing automatically based on how they are named.

For information on this, refer to the docs here.

This new file is where you will build your sign-in page. Add the following to src/app/sign-in/[[...sign-in]]/page.js:

// src/app/sign-in/[[...sign-in]]/page.js

import { SignIn } from "@clerk/nextjs";

export default function Page() {
  return <div className="h-screen w-full flex items-center justify-center">
    <SignIn />
  </div>
  ;
}

This adds a sign-in page, but we also need to configure where to navigate the user after the sign-in action is completed.

Add the following to .env:

# .env
# ... other variables
NEXT_PUBLIC_CLERK_SIGN_IN_URL=/sign-in
NEXT_PUBLIC_CLERK_AFTER_SIGN_IN_URL=/

The variables shown here are used by Clerk to determine where the sign-in page is and where to navigate the user after a sign-in is complete.

Add user details to the screen

You now have a complete and functional sign-in page and measures in place to keep your application secure. In src/app/page.js, replace all of the existing code with the following to show the logged in user after logging in:

// src/app/layout.js

import { UserButton } from "@clerk/nextjs";
import { currentUser } from "@clerk/nextjs";

export default async function Home() {
  const user = await currentUser();
  return (
    <div className="h-screen w-full flex flex-col">
      <header className="bg-slate-800 w-full p-3 h-16 flex items-center">
        <UserButton afterSignOutUrl="/" />
      </header>
      <main className="flex-1 flex items-center justify-center">
        <div>Hello {user?.firstName}!</div>
      </main>
    </div>
  );
}

The snippet above displays the signed-in user's name as well as a component provided by Clerk, UserButton, which allows a user to sign out and manage their account.

Test it out

At this point, your authenticated application is complete! Start up the application by running:

$ npm run dev

Then head over to http://localhost:3000 in your browser. You should find yourself on the sign-in page:

Signing in will redirect you to the root page and show your user details:

All that is needed now is to add more pages and finish your secure application!

Recap

Over the course of this tutorial, you learned how to:

Set up a Next.js application
Install and configure Clerk
Use Clerk to authenticate your application

The resulting application is equipt with a secure sign-in that allows you to create an account or sign in with Google. With different configurations and customizations, you can allow users to sign in with other social accounts.

Next steps

With this foundation in place, you can now begin to extend the application by adding new pages, updating the middleware to allow public access to specific pages, and much more!

Thanks for following along!

Common React Interview Question: Tic Tac Toe

Sabin Adams — Mon, 24 Jul 2023 17:31:41 +0000

Are you preparing for a technical interview for a position where you'll be working with React? One of the more common tasks I've seen given to interviewees is: "build a simple tic tac toe game".

Oftentimes, the individual you are coordinating interviews with will give you a vague overview of what to expect during your technical interview. If they mentioned implementing a simple game, you're in the right place!

If you just want to check out the final result, head over to this GitHub repository.

Why is Tic-Tac-Toe used for technical interviews?

As is the case with most technical interviews, the tic tac toe challenge gives the interviewer a chance to see a few things:

How you think about building a feature
Your depth of knowledge in React
Your communication

During an interview where you are asked to build anything, not just tic-tac-toe, it is essential to understand that the interviewers are on your side and expect a collaborative session.

If you get stuck, ask questions! Not sure about the prompt? Ask about it! The more you show that you are a team player who isn't afraid to ask for help, the more of a full picture you give the interviewer about what it will be like to work with you.

Aside from personality and collaboration skills though, this test is a great way to see if an individual understands things like:

State management
Controlled components
Context API
CSS and JSX skills
Basic JavaScript skills

What a solution might look like

There are many different ways you could build this game. Here I will walk you through a solution I believe is pretty straightforward and uses patterns that demonstrate a good understanding of React.

This tutorial will assume your technical assessment requires you to use TypeScript, however the concepts translate to JavaScript.

The starting point

Typically during a technical interview with a React-based challenge, you will start with a basic React app. Likely in a platform such as CoderPad or CodeSandbox.

The starting point will typically include things like:

The basic setup for running a React project
A src/ folder containing an App.tsx and main.tsx
Likely some other files that can be deleted or ignored

For the most part, you will not have to worry much about the starting files as your focus will be in App.tsx and new files you add yourself.

Build the game board

To begin building the game, we will build a component that acts as the game board. This is where all of the squares from the tic tac toe grid will eventually be rendered.

To do this, create a new folder within the src/ directory named components and a new file in that folder named GameBoard.tsx:

mkdir src/components
touch src/components/GameBoard.tsx

You'll likely be in an online editor where you will have to create these manually via the UI

The GameBoard.tsx file will export a function component as its default export:

// src/components/GameBoard.tsx
import React from 'react'
const GameBoard: React.FC = () => {
  return <></>
}

export default GameBoard

This component needs to render a 3 x 3 grid of squares. We will assume there is a root-level App.css file where we can provide global styles for the purposes of this tutorial.

In App.css, add the following:

/* src/App.css */
.gameboard {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  border-radius: 10px;
  overflow: hidden;
}

This should give us a class that will style a div's contents as a 3 x 3 grid.

// src/components/GameBoard.tsx
import React from 'react'
const GameBoard: React.FC = () => {
  return <div className="gameboard">
    {/* Render grid here! */}
  </div>
}

export default GameBoard

At this point, we have a GameBoard component that is ready to render some grid items on the game board. Next, we will tackle that.

Build the square component

To start the component that will be rendered for each grid item, create a new file in src/components named Square.tsx:

// src/components/Square.tsx
import React from 'react'
const Square: React.FC = () => {
  return <></>
}

export default Square

This component will render the square that will contain either an X or an O. Create another class to style these squares:

/* src/App.css */
.square {
  width: 100px;
  height: 100px;
  border: 1px solid gray;
  background: #f1f1f1;
  display: flex;
  align-items: center;
  justify-content: center;
}

And then put that to use in the new component:

// src/components/Square.tsx
import React from 'react'
const Square: React.FC = () => {
  return <div className="square"></div>
}

export default Square

Within that div tag is where you will render an X or an O depending on which player clicked the square.

To prepare this component for its future usage, define a few properties that you can pass it to specify the user who selected it and a click handler function:

// src/components/Square.tsx
import React from 'react'

type props = {
  user: string | null
  onClick: () => void
}

const Square: React.FC<props> = ({ user, onClick }) => {
  return <div className="square" onClick={onClick}>
    {user}
  </div>
}

export default Square

We have a game board and a way to render squares on that board now. What we need next is some structure to store the game's data and render the board based on that data.

At this point we are not actually rendering either of the components we have built. That will come soon, hang tight!

Build the game state using the Context API

To handle the state data in this application, you will use React's Context API. This API gives you a way to provide global state management to your application, allowing you to easily share data across components.

To stay organized, contexts are typically stored in their own folder. Create a new folder in src/ named contexts and a file in that new directory named GameState.tsx:

mkdir src/contexts
touch src/contexts/GameState.tsx

This file is where we will create our context. Open it up and start by creating a new context and exporting it:

// src/contexts/GameState.tsx
import React, { createContext } from 'react'

export type GameState = {
  users: string[]
  activeUser: string
  selections: Array<string | null>
}

export const GameStateContext = createContext<GameState>({
  users: ["x", "y"],
  activeUser: null,
  selections: [],
})

In the snippet above, we are importing the createContext function which allows us to create a React context. We are also creating a type GameState to define the properties this context exposes. For now, it contains:

users: An array containing the two players' data
activeUser: The user whose turn it is
selections: The data for each individual grid item

At this point, we have a context, but we also need to export a component that provides that context using a provider:

// src/contexts/GameState.tsx
import React, { createContext, useState } from 'react'
// ...
export const GameStateProvider: React.FC = ({ children }) => {
  const [activeUser, setActiveUser] = useState("x")
  const [selections, setSelections] = useState<Array<string | null>>(
    Array(9).fill(null)
  )

  return <GameStateContext.Provider value={{
    users: ["x", "y"],
    activeUser,
    selections,
  }}>
    {children}
  </GameStateContext.Provider>
}

Notice useState as added to the imports from the react library

This provider component will wrap the entire application, giving it global access to the data it provides. Important to note here are:

The children argument, which contains the child components the provider will eventually wrap.
The useState invocations. We are initializing the provider's state with two pieces of data. the activeUser which is "x" by default and selections which contains an empty array with a length of 9.

There will be a bit more to add to this file, however for now let's move on to putting the context to use so we can begin rendering the game board.

Use the GameState context

To use the context, we will first import the provider component and wrap the entire application in it.

Head into src/App.tsx and put the provider to use by importing it and wrapping the JSX contents in the component:

// src/App.tsx
import './App.css'
import { GameStateProvider } from './contexts/GameState'

function App() {
  return (
    <GameStateProvider>
      {/* original contents */}
    </GameStateProvider>
  )
}

Anything contained inside of that GameStateProvider component will have access to the GameState context.

The GameBoard component will be the entry point for this game. Next import that and replace the contents inside of the GameStateProvider with that component:

// src/App.tsx
import { GameStateProvider } from './contexts/GameState'
import GameBoard from './components/GameBoard'

function App() {
  return (
    <GameStateProvider>
      <GameBoard />
    </GameStateProvider>
  )
}

This will cause the GameBoard to be rendered on the screen, although that component does not currently render any of the squares.

Render the game grid

If you think back to the GameState context initialization, you will remember we initialized the state with an array of nine items, which represents the grid items on the board. To render the game's UI we will render a square for each of the grid items.

In src/components/GameBoard.tsx, use useContext to gain access to the context's data and render a Square component for each item in the selections array:

// src/components/GameBoard.tsx
import React, { useContext } from 'react'
import Square from './Square'
import { GameStateContext } from '../contexts/GameState'

const GameBoard: React.FC = () => {
  const { selections } = useContext(GameStateContext)

  return <div className="gameboard">
    {
      selections.map(
        (selection, i) => 
          <Square 
            key={i}
            user={selection} 
            onClick={null}
          />
      )
    }
  </Container>
}

export default GameBoard

For each item in the array, you are now rendering a Square and passing along the selection data to that square. Eventually, this will hold the name of the user that clicked that square.

If we take a look at the screen, however, we will see a very unorganized grid:

Let's fix this by wrapping the game board in a new div in App.tsx and adding some styles in App.css:

// src/App.tsx
// ... 

function App() {
  return (
    <GameStateProvider>
      <div className="container">
        <GameBoard/>
      </div>
    </GameStateProvider>
  )
}

export default App

/* src/App.css */
/* ... */
.container {
  display: flex;
  width: 100vw;
  height: 100vh;
  align-items: center;
  justify-content: center;
  background: white;
  font-family: roboto;
}

And with those adjustments, you should now see a formatted tic tac toe grid!

We are now rendering a tic tac toe grid and have access to a global state. You have all the pieces you need to begin making this grid functional!

Give players the ability to select a square

To begin, we need to add a method and make it accessible via the global state that mutates the selections array when a user clicks a square. Clicking a square should also switch the turn to the next player.

In src/contexts/GameContext.tsx make the following changes to add a function that selects a square based on the current player and then passes the turn to the next player:

// src/contexts/GameContext.tsx
import React, { createContext, useState } from 'react'

export type GameState = {
  users: string[]
  activeUser: string
  selections: Array<string | null>
  makeSelection: (squareId: number) => void // 👈🏻
}

export const GameStateContext = createContext<GameState>({
  users: ["x", "o"],
  activeUser: null,
  selections: [],
  makeSelection: null, // 👈🏻
})

export const GameStateProvider: React.FC = ({ children }) => {
  const [activeUser, setActiveUser] = useState("x")
  const [selections, setSelections] = useState<Array<string | null>>(
    Array(9).fill(null)
  )

  // Allows a user to make a selection 👇🏻
  const makeSelection = (squareId: number) => {
    // Update selections
    setSelections(selections => {
      selections[squareId] = activeUser
      return [...selections]
    })

    // Switch active user to the next user's turn
    setActiveUser(activeUser === 'x' ? 'o' : 'x')
  }

  return <GameStateContext.Provider value={{
    users: ["x", "o"],
    activeUser,
    selections,
    makeSelection // 👈🏻
  }}>
    {children}
  </GameStateContext.Provider>
}

Take note of where the hands are pointing! Those are the changes that were made.

That's a big code snipped, so let's see what changed:

The GameState type needed a new property called makeSelection to define the function we are adding
The GameStateContext needed an initial value for makeSelection
The provider defines the functionality for makeSelection
The makeSelection function is provided to the value attribute of the provider, exposing it to any component that uses that context

The makeSelection function itself does two things. It takes in the squareId, which is its index in the selections array and uses that to update the value of that index with the name of the current player. It then sets the activeUser to whichever player did not just make a selection, passing the turn.

As a result, this function allows a user to select a square and pass the turn. What's left is to put it to use. Head into GameBoard component and pass this to the onClick handler of the Square components being rendered:

// src/components/GameBoard.tsx
// ...

const GameBoard: React.FC = () => {
  const { 
    selections, 
    makeSelection // 👈🏻
  } = useContext(GameStateContext)
  return <div className="gameboard">
    {
      selections.map(
        (selection, i) => 
          <Square 
            key={i}
            user={selection} 
            onClick={() => makeSelection(i)} // 👈🏻
          />
      )
    }
  </div>
}

export default GameBoard

Now, when a square on the grid is clicked, the current player's symbol will be displayed:

What's left is to add the functionality to check for a winner and reset the game once a winner is found.

Check for a winner

When a player selects a square, a function should fire off that checks whether there is a winning combination.

To accomplish this, we will use useEffect within the GameContextProvider component. Every time selections changes, the effect will fire triggering the check for a winner.

Make the changes below to accomplish this:

// src/contexts/GameState.tsx
import React, { createContext, useState, useEffect } from 'react'
// ...
export const GameStateProvider: React.FC = ({ children }) => {
  const [selections, setSelections] = useState<Array<string | null>>(
    Array(9).fill(null)
  )
  // ...
  // 👇🏻
  useEffect(() => {
    // checkForWinner()
  }, [selections])

  return <GameStateContext.Provider value={{
    users: ["x", "o"],
    activeUser,
    selections,
    makeSelection
  }}>
    {children}
  </GameStateContext.Provider>
}

Remember to import useEffect!

Every time a grid item is selected (or more specifically, whenever the selections variable changes) the code inside of the useEffect callback will be run.

What we need to add to handle selecting a winner is add a new state variable and provide it via the provider named winner. When we check for a winner and find one, the player will be stored in that state variable.

Add the following to do this:

// src/contexts/GameState.tsx
import React, { createContext, useState, useEffect } from 'react'

// ...

export type GameState = {
  users: string[]
  activeUser: string
  selections: Array<string | null>
  makeSelection: (squareId: number) => void
  winner: string | null // 👈🏻
}

export const GameStateProvider: React.FC = ({ children }) => {
  // ...
  const [winner, setWinner] = useState(null) // 👈🏻
  // ...

  return <GameStateContext.Provider value={{
    users: ["x", "o"],
    activeUser,
    selections,
    makeSelection,
    winner // 👈🏻
  }}>
    {children}
  </GameStateContext.Provider>
}

Now there is a piece of state that can keep track of whether or not a winner has been selected and who it is. The last piece for handling a winner is the actual function that reads the game board and finds a line of three matching selections.

Add the following function and uncomment the contents of the useEffect callback:

// src/contexts/GameState.tsx
import React, { createContext, useState, useEffect } from 'react'

// ...

export const GameStateProvider: React.FC = ({ children }) => {
  // ...
  const checkForWinner = () => {
    const winningCombos = [
      [0,1,2],
      [3,4,5],
      [6,7,8],
      [0,3,6],
      [1,4,7],
      [2,5,8],
      [0,4,8],
      [6,4,2]
    ]

    winningCombos.forEach( combo => {
      const code = combo.reduce(
        (acc, curr) => `${acc}${selections[curr]}`, 
        ''
      )
      if ( ['xxx', 'yyy'].includes(code) ) 
        setWinner(code[0])
      }
    )
  }

  useEffect(() => {
    checkForWinner()
  }, [selections])

  return <GameStateContext.Provider value={{
    users: ["x", "o"],
    activeUser,
    selections,
    makeSelection,
    winner
  }}>
    {children}
  </GameStateContext.Provider>
}

When a player wins the game, the winner state variable will be updated to contain the winning player's symbol. At the moment, there is no indication there was a winner though. Let's fix that and wrap up the game.

Display a winner and reset the board

To display a winner, we can make use of the new winner variable that is made accessible to the application via the context provider.

In the GameBoard component, add a useEffect that watches for changes to the winner variable. When that variable is updated and a winner is contained in that variable, display an alert signifying which player won:

// src/components/GameBoard.tsx
// 👇🏻
import React, { useContext, useEffect } from 'react'
// ...

const GameBoard: React.FC = () => {
  // 👇🏻
  const { selections, makeSelection, winner } = useContext(GameStateContext)

  // 👇🏻
  useEffect(() => {
    if ( winner !== null ) {
      alert(`Player ${winner.toUpperCase()} won!`)
    }
  }, [winner])

  return <div className="gameboard">
    {/* ... */}
  </div>
}

export default GameBoard

Don't forget to import useEffect!

If a player selects three in a row, you should now see an alert signifying which user won!

Once that alert is dismissed, the game board does not change. There is currently no way to start over (other than refreshing the browser).

Add and expose a new function in the GameState context that resets the state variables to their original values:

// src/contexts/GameState.tsx
import React, { createContext, useEffect, useState } from 'react'

export type GameState = {
  // ...
  reset: () => void
}

export const GameStateContext = createContext<GameState>({
  // ...
  reset: null
})

export const GameStateProvider: React.FC = ({ children }) => {
  // ...

  const reset = () => {
    setSelections(Array(9).fill(null))
    setWinner(null)
    setActiveUser('x')
  }

  return <GameStateContext.Provider value={{
    // ...
    reset
  }}>
    {children}
  </GameStateContext.Provider>
}

This function will reset the game completely and should be run directly after the alert in the GameBoard component:

// src/components/GameBoard.tsx
import React, { useContext, useEffect } from 'react'

const GameBoard: React.FC = () => {
  // 👇🏻
  const { selections, makeSelection, winner, reset } = useContext(GameStateContext)

  useEffect(() => {
    if ( winner !== null ) {
      alert(`Player ${winner.toUpperCase()} won!`)
      // 👇🏻
      reset()
    }
  }, [winner])

  return <div className="gameboard">
    {/* ... */}
  </div>
}

export default GameBoard

Now, when you dismiss the alert you should see the game board is reset and ready for a new game!

Closing words

I really enjoy this task because, while it seems simple at first glance, it allows interviewers to see you understand concepts such as:

Reusable components
Global state management
JSX
Basic logic
... and more!

If you had trouble following through the tutorial above at all, you can also refer to this GitHub repository with the completed project.

Thanks so much for reading, and good luck interviewing!

To NoSQL or Not to NoSQL

Sabin Adams — Fri, 21 Jul 2023 19:56:58 +0000

NoSQL was a revolutionary advance in technology when it first began to gain popularity. As time has passed and more teams have gained hands-on experience with it in long-living projects, the hype has died down and opinions have changed.

In this article we will take a look at how NoSQL compares to SQL and the considerations to keep in mind when deciding whether or not to use a NoSQL database.

What is NoSQL?

The first step to understanding when you should and shouldn't use NoSQL is having a firm grasp of NoSQL as a concept.

"NoSQL" itself is not a great name as it doesn't really encompass all that a NoSQL database has to offer. There are many different flavors of NoSQL. For example:

Document databases: e.g. MongoDB, DynamoDB
Key-Value databases: e.g. Redis, Memcached, Couchbase
Wide-column stores: e.g. Cassandra, BigTable, CosmosDB
Graph databases: e.g. Neo4j, ArangoDB, TigerGraph

What all of these have in common is that they are non-relational database, meaning they do not adhere to a defined schema of relational tables. Often when someone refers to a NoSQL database, they are referring to a document store such as MongoDB, however as you can see above there are many variations to keep in mind.

NoSQL refers to any databases that store data in non-relational constructs.

Primary features

Below are just a few of the notable features of NoSQL databases that make them such a useful technology:

Flexible data structures

The most obvious feature of NoSQL is the fact that it does not have to follow a schema pre-defined at the database-level. This allows you as a developer to have the flexibility of storing data in a chosen shape per-record. One record in a collection may look completely different than the next!

 {
   "id": "sdf8s7d76sfds9d0fs",
   "firstName": "Sabin",
   "lastName": "Adams",
   "favoriteColor": "#000000"
}

You may have another record in that same collection that looks more like this:

{
   "id": "sdf8s7d76sfds9d0fs",
   "firstName": "Thomas",
   "lastName": "Newman",
   "favoriteColor": "#1f1f1f",
   "hobby": "music composition"
}

Notice the new hobby property

This is perfectly acceptable in a NoSQL database and allows you as a developer to not have to worry about having your long-term data structure defined right from the start.

Quick iterations

A side-effect of having flexible schemas is that NoSQL allows developers and teams to iterate very quickly as their applications progress and evolve.

When an application requires data structure changes within the database, making those changes is as simple as adding or removing columns from the data model. The database doesn't care what data you give it, so long as it is of a valid format.

Potentially faster queries

NoSQL has the potential for faster queries compared to similar queries against a traditional relational database.

In NoSQL, relations are not handled via an underlying schema. Instead they are manually maintained using nested data structures. For example, consider a model where a user can have many posts:

{
   "id": "9879sdfs98df",
   "fullName": "Sabin Adams",
   "posts": [{ ... }]
}

As is shown above, the posts data is nested within the user record itself. This makes it very easy and efficient to search for a user's related posts. Rather than having to make use of a foreign key to point to a separate table and scan that table for linked data, it's all packaged nicely in one spot.

Horizontally scalable

The last point I will touch on is that NoSQL databases excel at being horizontally scalable.

Horizontal scaling refers to increasing the capacity of a system by adding additional machines (nodes), as opposed to increasing the capability of the existing machines. This is also called scaling out. - Cockroach Labs

The way data is structured in a NoSQL database makes it easier to shard and duplicate across multiple machines (or nodes). When using a NoSQL database, you give up a lot of the built-in features a traditional relational database gives you, such as referential integrity and transactions in return for an easily partition-able pool of data.

When a NoSQL database runs up against performance walls, you can simply add more nodes to your pool of databases that split the processing power between each other.

How Is It Different From SQL?

The sections above focused specifically on the features of NoSQL, but now let's take a look at how those features set NoSQL apart from traditional relational databases:

Rigid data structure

A SQL database has a very rigid data structure. In fact, you cannot begin using and storing data in your database without first defining a data structure and the relationships within that data structure.

This has positive and negative implications. In regards to how this causes SQL to differ from NoSQL, rigid data structures:

Make iteration much slower. Changing your SQL data model requires you to update your schema via a migration before you can store new data or remove data.
Cause a higher barrier of entry. Migrations are difficult to manage and easy to get wrong. Because of this, it is best practice to think all the way through your data needs before applying your initial schema to minimize the number of major structure changes. This takes time and resources.

The above are presented as negatives, however the time spent defining and updating a rigid data model allow you to construct well-defined relations in your data which allow you to:

Enforce relation rules
Establish ACID properties, allowing safe transactional operations across many tables of data
Improve data compatibility

Vertically scalable

Unlike NoSQL, which is horizontally scalable, traditional SQL databases are scaled vertically.

Vertical scaling refers to increasing the capacity of a system by adding capability to the machines it is using (as opposed to increasing the overall number of machines). This is also called scaling up. - Cockroach Labs

Relational data, due to the nature of the underlying data structure that make up relations, does not support the concept of horizontal scaling. Writing a SQL query with joins across different tables assumes it has immediate access to the related data. If the database were stored horizontally, the related data from such a query might only exist in a particular node, requiring a network request to fetch that segment of the data.

This poses problems as the database will have no way to determine whether it has access to all of the data when generating a query plan.

Because of this, SQL database are typically scaled vertically. When a SQL database runs up against performance issues, the database server itself is upgraded to a more powerful machine that can handle the desired workload.

Considerations

At this point, you should have a general overview of some of the primary differences between NoSQL and SQL databases. But, as we saw above, both have their own pros and cons.

So we now come to the question this article is aiming to answer: To NoSQL or Not to NoSQL. The answer to this question is the typical: It depends.

Every application is different and has different functional and organizational needs. SQL and NoSQL each solve specific problems the other can't account for. The answer to the question will depend on what your specific applications' needs are.

Below are a few considerations to keep in mind when deciding if NoSQL is a fit for your needs:

Structure of data

One major consideration is the structure and nature of the data your application needs.

If are expecting your data to primarily consist of non-relational data or large sets of unstructured data, NoSQL is a fantastic choice.

A few examples of when you might opt for a NoSQL database:

Social media-like applications where data and relationships are user-defined
Storage for unstructured variable data such as logs or IoT data
Applications such as content management systems where the data is primarily non-relational

Evolution of data

As discussed briefly above, the lack of a structured schema allows you to modify your data structure with little to no effort. This can be important for a team working to get an application out as soon as possible.

If your application is in its early phases and you are hoping to iterate and evolve it quickly, a NoSQL is definitely the best option.

Often teams will use a NoSQL database during experimentation phases. Once the product is complete, you can always take a look at the data needs of that application and determine whether a switch to a tradition SQL database would be beneficial.

Your team's capabilities

Another thing to consider when choosing a database type is the knowledge your team members possess. Working with a traditional SQL database requires the developer to understand how to write efficient SQL queries, often complex ones.

One of the reasons NoSQL was invented was due to the frustrating of the SQL language. With most NoSQL providers, your queries are run via an API built in your language of choice.

If your team consists primarily of developers who are not SQL-savvy, you may be best suited running a NoSQL database.

Cost

Due to the flexible nature of hosting and deploying NoSQL databases, you also gain access to more granular control of the costs that go into your database.

As your database scales up and down, the cost of hosting your data scales with it. This can often lead to much lower costs compared to a traditional SQL database which is run 24/7 on a machine with static allocations of resources.

Key Takeways

The key takeway here is that the NoSQL vs. SQL debate does not have any one definitive answer. Each type of database has its own special attributes that make it more suitable for specific situations.

When choosing your database, be sure to consider the strengths and weaknesses of each kind of database, the human resources available on your team and the future data needs of your application.

Stop Hating On Array.reduce()

Sabin Adams — Thu, 20 Jul 2023 05:01:32 +0000

There has been some controversy recently about whether or not JavaScript developers should use the Array.reduce() method.

Here's just a few posts that were part of the recent Tweet storm:

// Detect dark theme var iframe = document.getElementById('tweet-1681027968985104386-239'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1681027968985104386&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1681285782475259905-188'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1681285782475259905&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1681148216585392128-168'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1681148216585392128&theme=dark" }

Of course, everyone is entitled to their own opinion! But this article is dedicated to why everyone with the opinion that Array.reduce() is bad is wrong 😈

Disclaimer: They aren't wrong 😅 I'm as opinionated as the rest of 'em!

What does it do?

Array.reduce() is an array function in JavaScript that is used to reduce the contents of an array down to a single value using a function called a reducer.

A popular example usage of the function is a reducer that returns the sum of all numbers in an array:

const value = [1,2,3,4].reduce((acc, cur) => { 
    return acc + curr 
}, 0)

// value: 10

The function takes in two arguments:

callback: A callback function, the reducer
initialValue: The initial value the accumulated value builds upon

The callback function takes in 4 optional parameters:

accumulator: The accumulated value
currentValue: The current item in the array you are iterating through
currentIndex: The current index of the array you are iterating through
array: The entire array you are iterating through

A full signature looks like:

const reducer = (accumulator, currentValue, currentIndex, array) = > { 
    return accumulator; 
}

const value = [...].reduce(reducer, 0)

What's the problem?

After digging through the complaints, the recurring theme is that Array.reduce() is too difficult to read and understand.

While reviewing code, scanning through a new codebase or reading documentation, coming across an Array.reduce() requires you to stop and think for a moment about what is actually happening with an array.

These opinions are based around the fact that you can achieve the same result with another Array method such as Array.forEach() or even a simple for loop in a way that is more readable.

While the opinions hit on a good point... they're wrong!

My reasoning

There are a few things that come to mind when I read these comments. I think a lot of the reasoning behind these opinions are perfectly valid! But the frustration is directed at the wrong thing.

My first thought about this matter is that the real frustration isn't about the method signature and complexity at all, but rather about a developer's worst enemy: naming things.

In fact, this in my opinion is so deeply rooted in the controversy that it shows itself in two different ways!

Exhibit A: It shouldn't be named reduce

First, the method itself is named reduce. While this method name makes sense in many situations... the Array.reduce() method is so powerful that it can do far more than reduce an array to a single value.

Consider the following usage of the function:

const smallNumbers = [1,2,3,4,5] 
const largeNumbers = smallNumbers.reduce((newArray, current) => { 
    newArray.push(current ** 2) 
    return newArray 
}, [])

// largeNumbers: [1,4,9,16,25]

In this case, we aren't reducing the initial array at all... we are transforming it! So... is this reason enough to hate Array.reduce()? I think not!

Array.prototype.transform = Array.prototype.reduce;

Boom, fixed.

Obviously, that's a joke. A joke that would fix the problem completely, but still a joke.

Exhibit B: People are lazy when naming parameters

How many times have you seen a loop like the following:

const array = [...] 
let crazyValue = 0; 
for (let i = 0; i < array.length; i++) { 
    for (let j = 0; j < i; j++) { 
        crazyValue = i + j; 
    } 
}

Really?? i and j? Why are these single-character variable names so common that it almost seems normal to look at?

The same (disgusting) problem exists with Array.reduce() usage. You will often see this:

const array = [...]; 
const crazyvalue = array.reduce((acc, curr, i, arr) => { 
    return acc + curr 
}, 0)

acc, curr, i and arr....really guys?? We can do better. Let's fix this confusing problem by being a lot more descriptive with our variable names:

const array = [...]; 
const crazyvalue = array.reduce((total, currentValue, index, originalArray) => { 
    return total + currentValue 
}, 0)

Or better yet:

const array = [...]; 
const initalValue = 0; 
const addValues = (total, currentValue, index, originalArray) => { 
    return total + currentValue; 
}

const crazyvalue = array.reduce(addValues, initialValue)

Now, this may not be the perfect solution but it certainly makes the code a lot easier to read and digest.

What do you think?

So, is Array.reduce() all that bad? Personally, I would say no. If you understand that Array.reduce() is a powerful function that can do more than simply reduce an array to a single value, it is actually pretty easy to follow.

A lot of the issues I see with it are user-errors related to naming conventions.

What do you think? Am I completely off-base here? @ me on Twitter and we can fight about it 🤺

Bonus question:

Array.prototype.transform = Array.prototype.reduce 
const add = (total, current) => total + current 
const intialValue = 0 
const sumOfNumbers = [1,2,3,4,5].transform(add, initialValue)

Yay or nay?

Managing a Remix Site's Content With Sanity.io

Sabin Adams — Tue, 23 Aug 2022 20:56:15 +0000

In this day and age, the world runs on data. Your phone, your favorite game, the internet itself! Everything comes down to data. This has lead to a realization by developers over the years: data is hard to manage.

Introduction

In this article, you will learn how to use Sanity.io, a content platform that includes the Content Lake where your content is stored, a content management studio and various APIs to access your content from. Sanity will be used to manage the content (data) of a book catalog's website built with Remix.

By the end, you will have Sanity set up to manage your content and a fully functional Remix application. This application will use Sanity's GraphQL API to retrieve your content.

Finally, you will deploy your finished website using Vercel.

Prerequisites

While not completely necessary, I believe you will get the most out of this article if you come with:

A basic understanding of JavaScript and its tooling
Experience working with React
A basic understanding of GraphQL

Make sure you have node.js installed on your machine.

Tools you will use

Below are the various tools and technologies you will get to touch in this tutorial:

Remix, your application framework
Sanity, a headless CMS to manage your data
graphql-request, a minimal GraphQL client
GraphQL Codegen, generates TypeScript types from a GraphQL schema
TailwindCSS, as your CSS framework
Vercel, as your website hosting provider

Set up a Sanity.io project

Sanity gives you the ability to set up Sanity Studio, an application that allows you to configure different content types and inputs. The studio interacts with Sanity's APIs, allowing you to manage your data from a self-hosted application.

In order to set up a Sanity project, you first need to install the Sanity CLI:

npm i -g @sanity/cli

Next, initialize a Sanity project in a directory where you would like the project to live. For the purposes of this tutorial I will work in /Documents/projects:

# /Documents/projects
sanity init

Note : If you did not already have a Sanity account set up, sanity init will walk you through setting up a new account.

This will walk you through setting up your project and will download a starter template of Sanity Studio. You will be prompted for a few bits of data and asked a few questions about your project. I chose the name catalog-sanity for my project and will use that for the remainder of this tutorial.

At some point in the process, you will be asked to Select project template. Select the Clean project with no predefined schemas option, as you will configure this project yourself.

Once your project has been set up, follow the instructions outputted to start up Sanity Studio:

# /Documents/projects
cd catalog-sanity
sanity start

Sanity Studio should start up at localhost:3333. Pop that open to see what the starter template looks like:

Note : You will be asked to sign in to the studio. Use the credentials you used when creating an account on Sanity.io.

You should see a page similar to the one above. As the message on the page indicates, you have not yet configured a schema.

In the next section, you will set up a schema to define a Book document and its fields.

Define a `Book` document type

In Sanity, JavaScript objects are used to build schemas that define your content model. This model consists of "documents", or the types of content you are creating. In this catalog scenario, the only type of content you will create is Books.

Open up your Sanity project in a code editor. You will find a folder within named schemas. This is the folder that will contain all of your project's schemas.

Create a new file within the schemas folder named book.js:

# /Documents/projects/catalog-sanity
touch schemas/book.js

Add the following code to the new book.js file:

// /Documents/projects/catalog-sanity/schemas/book.js

export const book = {
  name: 'book',
  type: 'document',
  title: 'Book',
  fields: []
}

This object defines a document named book. Within Sanity Studio, this document will be referred to as Book because of the title field. The fields array is empty at the moment.

In your application, a book will have three pieces of data associated with it:

Title: The title of the book
Author: The author of the book
Description: A quick description of the book

Update the fields array to define these data points:

// /Documents/projects/catalog-sanity/schemas/book.js

// ...
fields: [
    {
        name: "title",
        type: "string",
        title: "Title",
    }, {
        name: "author",
        type: "string",
        title: "Author",
    }, {
        name: "description",
        type: "text",
        title: "Description",
    },
],
// ...

Apply `Book` to your schema

At this point, you have completely defined the Book document type, however that type has not yet been applied to the project's schema.

In schemas/schema.js, import the new Book type and add it to the types array within the createSchema configuration object argument:

// /Documents/projects/catalog-sanity/schemas/schema.js

import createSchema from "part:@sanity/base/schema-creator";

import schemaTypes from "all:part:@sanity/base/schema-type";
import { book } from "./book"; // <- Import the type

export default createSchema({
  name: "default",
  types: schemaTypes.concat([
    book // <- Add it to the array
  ]),
});

Once you save all of your changes and head back to the browser, you should now see the UI updated with your new content type.

Clicking the Book option under the Content header will reveal a list of your existing books (it will be empty for now). Here, you are provided all of the tools you need to create, update, and delete books.

Create a couple of books by clicking the pencil icon on the top right of that section:

Once you've added a few books, you are almost ready to move on to the last section!

The last thing you need to do, however, is install the @sanity/cli as a development dependency in the project:

npm i -D @sanity/cli

This will allow you to deploy to Vercel later on in this tutorial.

Build the Remix application

Now that Sanity is set up to manage your content, you need a way to display that content. You will use Remix, a full stack JavaScript framework, to create a book catalog website where your data will be displayed.

Initialize a Remix application

This application will be separate from the Sanity project. Navigate out of the Sanity project's directory and into a directory where you would like your Remix project to live. Then run the following command:

# /Documents/projects
npx create-remix@latest

This command will ask you a series of questions and scaffold the beginnings of a Remix application for you. Answer the questions with the following:

Where would you like to create your app? : catalog-remix
What type of app do you want to create? : Just the basics
Where do you want to deploy? : Vercel
TypeScript or JavaScript? : TypeScript
Do you want me to run npm install? : Yes

The options above will set up a Remix starter template in a folder named catalog-remix. This application will be a bare bones template configured to use TypeScript and deploy to Vercel.

Enter the new directory and run the dev script to start up the development server:

# /Documents/projects
cd catalog-remix && npm run dev

Now, if you open up a web browser and navigate to localhost:3000, you should see the starter page Remix provided!

Set up TailwindCSS

This starter is very basic and is not very visually appealing yet. To style your application, you will use TailwindCSS.

To set up TailwindCSS, you first need to install a few dependencies:

# /Documents/projects/catalog-remix
npm i -D tailwindcss postcss autoprefixer concurrently

These packages provide you the TailwindCSS CLI and PostCSS. You also installed autoprefixer, which is a PostCSS plugin needed to use TailwindCSS. concurrently is a tool that will allow you to run your development server and build your TailwindCSS styles at the same time.

With all of those pieces installed, run the following command to use TailwindCSS CLI to initialize TailwindCSS in your project:

# /Documents/projects/catalog-remix
npx tailwindcss init

This command will generate a new file at the root of your project named tailwind.config.js. This file is where you will configure TailwindCSS.

Open that file and add the following value to the content key's array:

// /Documents/projects/catalog-remix/tailwind.config.js

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./app/**/*.{js,ts,jsx,tsx}", // <-- Added this "blob"
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

What this does is tells TailwindCSS which files in your project will be using its utilities and classes. This helps TailwindCSS decide which of its utilities and classes should be generated into its minified output when a build is run on your project.

The next step is to update your development scripts to include a step to build your CSS when you build or develop your application.

Open up package.json and replace the contents in the scripts section with the following:

// /Documents/projects/catalog-remix/package.json 

// ...
"scripts": {
  "build": "npm run build:css && remix build",
  "build:css": "tailwindcss -m -i ./styles/app.css -o app/styles/app.css",
  "dev": "concurrently \"npm run dev:css\" \"remix dev\"",
  "dev:css": "tailwindcss -w -i ./styles/app.css -o app/styles/app.css"
},
// ...

Now when you run npm run dev or npm run build, rather than simple starting up or building your Remix application it will also generate a CSS file based off of the TailwindCSS classes and utilities you are using in your application.

These steps require the existence of TailwindCSS's base "layers", as signified in the -i ./styles/app.css argument of the tailwindcss command. Those layers provide the pieces TailwindCSS uses to provide its styling.

Create a new directory named styles and within that directory create a new file named app.css:

# /Documents/projects/catalog-remix
mkdir styles && touch styles/app.css

Add the following CSS to that file to import TailwindCSS's layers:

/* /Documents/projects/catalog-remix/styles/app.css */

@tailwind base;
@tailwind components;
@tailwind utilities;

The new steps that build your CSS file will output your CSS into a file at app/styles/app.css. In order to actually use those generated styles, however, you will need to import that file into your application.

In app/root.tsx, add the following to import those styles and use them in your application:

// /Documents/projects/catalog-remix/app/root.tsx

import type { 
  MetaFunction,
  LinksFunction // <-- Added the LinksFunction type
} from "@remix-run/node";

// ... other imports

import styles from "./styles/app.css"

export const links: LinksFunction = () => {
  return [{ rel: "stylesheet", href: styles }]
}

// ...

Now TailwindCSS is configured and ready to use in your application!

To verify everything is working correctly, replace the contents of app/routes/index.tsx with the following code:

// /Documents/projects/catalog-remix/app/routes/index.tsx

export default function Index() {
  return (
    <div className="h-screen w-full p-4 font-mono">
      <div className="rounded-xl p-6 bg-gray-100 border-4 border-gray-600">
        <h2 className="font-bold text-4xl text-gray-600">Book Catalog</h2>
      </div>
    </div>
  );
}

If you run npm run dev and head back to localhost:3000, you should see a page similar to the following:

If you get a page similar to this one, TailwindCSS is set up and working!

Build a `Book` component

Now, you need a component that will display each book in your catalog.

Create a new folder in the app directory named components. Then create a file within that folder named Book.tsx:

# /Documents/projects/catalog-remix
mkdir app/components
touch app/components/Book.tsx

Paste the following function into that file:

// /Documents/projects/catalog-remix/app/components/Book.tsx

export default function Book() {
    return (
        <a href="/" className="m-2 rounded-xl p-6 border-4 border-gray-600 transition hover:-translate-y-1">
            <h2 className="font-bold text-2xl text-gray-600">How To: DevRel</h2>
            <p className="text-xs text-gray-400">by Sabin Adams</p>
            <p className="text-gray-500 mt-2 text-md">
                This book walks the reader through the ins and outs of working in the DevRel space.
            </p>
        </a>
    );
}

This function simply returns some JSX, which will render a dummy Book onto the page. The data in this component is static for now, however in the next section you will populate this component with your book data from the Sanity API.

Over in app/routes/index.tsx, import that new component and render it within a grid a couple of times to populate your screen with a set of dummy books:

// /Documents/projects/catalog-remix/app/routes/index.tsx

import Book from '../components/Book' // <-- Imported the `Book` component

export default function Index() {
  return (
    <div className="h-screen w-full p-4 font-mono">
      <div className="rounded-xl p-6 bg-gray-100 border-4 border-gray-600">
        <h2 className="font-bold text-4xl text-gray-600">Book Catalog</h2>
      </div>
      {/* Renders 6 Books within a grid 👇🏻 */}
      <div className="grid grid-cols-3 p-12">
        <Book /><Book /><Book /><Book /><Book /><Book />
      </div>
    </div>
  );
}

Back over in your browser, you should now see your set of books rendered in a stylized grid:

Get your data from Sanity.io

At this point you have Sanity set up to manage your content, and a Remix application ready to render some live data.

You will now use Sanity's GraphQL API to fetch your content and render it into the browser.

To do this, you will make use of a tool called GraphQL Codegen to generate TypeScript types based on the GraphQL schema Sanity provides. You will then use graphql-request to actually fetch the data.

Set up GraphQL Codegen

First, you will set up GraphQL Codegen to generate TypeScript types based off of your GraphQL schema. It will also generate types based on the queries you write that represent the data you actually query for.

To get started, install these packages in your Remix application:

# /Documents/projects/catalog-remix
npm i -D graphql @graphql-codegen/cli @graphql-codegen/typed-document-node @graphql-codegen/typescript @graphql-codegen/typescript-operations

These give you access to the GraphQL Codegen CLI and all of the plugins you need to generate the types representing your GraphQL schema and queries. In order to generate these types, you first need to configure GraphQL Codegen.

Create a new file at the root of your Remix project named codegen.yml with the following contents:

# /Documents/projects/catalog-remix/codegen.yml

generates:
  ./app/models/sanity-generated.ts:
    schema: <placeholder>
    documents: <placeholder>
    plugins:
      - typescript
      - typescript-operations
      - typed-document-node

This configuration lets GraphQL Codegen know to generate a file at app/models/sanity-generated.ts with all of the types you need.

There are three different configurations provided for this generated file:

schema : The URL of your GraphQL API
documents : Tells the CLI which files in your project have GraphQL queries
plugins : Lets the CLI know which plugins to use to generate types

Currently, the schema and documents fields have dummy data in them. You will need to populate these.

To populate schema, you first need to deploy your Sanity project's GraphQL API. To do so, navigate to the Sanity project's folder and run the following command:

# /Documents/projects/catalog-sanity
sanity graphql deploy

After running this command, the URL to your GraphQL API will be outputted into the terminal. Copy that URL:

Then, paste that value into the codegen.yml file's schema field:

# /Documents/projects/catalog-remix/codegen.yml

generates:
  ./app/models/sanity-generated.ts:
    schema: # paste the API URL here #
    documents: <placeholder>
    plugins:
      - typescript
      - typescript-operations
      - typed-document-node

The next piece you will need to fill in is the documents key. You will write all of your queries in a file at app/graphql. Create that directory and add a file named books.query.gql:

# /Documents/projects/catalog-remix
mkdir app/graphql
touch app/graphql/books.query.gql

Then paste the file path ./app/graphql/**/*.ts into the documents field in the codegen.yml file:

# /Documents/projects/catalog-remix/codegen.yml

generates:
  ./app/models/sanity-generated.ts:
    schema: <hidden>
    documents: # paste the file path here #
    plugins:
      - typescript
      - typescript-operations
      - typed-document-node

GraphQL Codegen is now configured to ready all queries from .ts files within the app/graphql folder, but you need a way to actually generate the types.

In package.json, add the following script to the scripts field:

// /Documents/projects/catalog-remix/package.json

// ...
"scripts": {
  // ...
  "codegen": "npx graphql-codegen"
}
// ...

At this point, you are ready to generate types based off of your queries and the GraphQL Schema! There is only one problem... you don't have any queries yet!

You will use graphql-request and its helpers to write your GraphQL queries and fetch the data from Sanity's GraphQL API.

Install the graphql-request library:

# /Documents/projects/catalog-remix
npm i graphql-request

Then, in app/graphql/books.query.ts, add the following GraphQL query to fetch your book data:

// /Documents/projects/catalog-remix/app/graphql/books.query.ts

import { gql } from "graphql-request";

export default gql`
  query GetBooks {
    allBook {
      _id
      title
      author
      description
    }
  }
`;

Note : If you'd like to see all of the data available from the GraphQL API, check out the GraphQL playground by going to your GraphQL API's URL in your web browser.

Now that you have a query written, run the following command to generate your types:

# /Documents/projects/catalog-remix
npm run codegen

You should see a new app/models directory with a file named sanity-generated.ts inside of it. This file contains your TypeScript types!

Query Sanity's GraphQL API

You now have TypeScript types to represent the data you expect to retrieve from the Sanity API. At this point, you can write the queries for your data.

Create a new directory named services within the app directory and create a file within that directory named sanity.service.ts:

# /Documents/projects/catalog-remix
mkdir app/services
touch app/services/sanity.service.ts

This is where you will write the function that will fetch the data.

Add the following code to create a function that fetches the API for your books and properly types the response:

// /Documents/projects/catalog-remix/app/services/sanity.service.ts

import { GraphQLClient } from "graphql-request";
import type { GetBooksQuery } from "../models/sanity-generated";
import BookQuery from "../graphql/books.query";

export async function getBooks() {
  const graphcms = new GraphQLClient(process.env.SANITY_API_URL || "");
  const { allBook } = await graphcms.request<GetBooksQuery>(BookQuery);
  return allBook;
}

The code above assumes you have an environment variable named SANITY_API_URL that contains the URL of the GraphQL API.

Create a file named .env at the root of your project:

# /Documents/projects/catalog-remix
touch .env

Then add the following contents to that file:

# /Documents/projects/catalog-remix/.env

SANITY_API_URL=<your_api_url> 
# Example: SANITY_API_URL=https://gsithqzp.api.sanity.io/v1/graphql/production/default

Now that your getBooks function is ready and your environment has the correct API URL available you are ready to run your query.

Within Remix, you have the ability to create a "loader" function that, when deployed, is treated as a serverless function and is deployed separately from the client-side code.

In app/routes/index.ts, create a loader function that simply fetches your books and returns them.

// /Documents/projects/catalog-remix/app/routes/index.ts

import Book from '../components/Book'
import type { LoaderFunction } from '@remix-run/node';
import { getBooks } from '../services/sanity.service'

export const loader: LoaderFunction = async () => {
  const books = await getBooks()
  return { books }
}
// ...

Then, import the useLoaderData hook Remix provides and use it to capture the results of your loader function. Be sure to type the variable using the useLoaderData function's generic:

// /Documents/projects/catalog-remix/app/routes/index.ts

// ...

export default function Index() {
  const { books } = useLoaderData<{
    books: GetBooksQuery['allBook'][0][]
  }>()

  return (/* JSX */);
}

You are now querying your data and accessing that data from your application. The data from your API In the next section, you will fix up your Book component so that it will render the actual book data and render one for each book in the API response.

Render your Book data

Head back over to app/components/Book.tsx and import the GetBooksQuery type. Use that type to define a book prop on the Book component:

// /Documents/projects/catalog-remix/app/components/Book.tsx

import type { GetBooksQuery } from "../models/sanity-generated";

export default function Book({ book }: { book: GetBooksQuery['allBook'][0] }) {
  // Component code
}

The code above sets up a book property on the component whose type matches the type of a single book from your API response.

You can now use that property to render your book data into the component. Update the JSX in that component to use the book's data:

// /Documents/projects/catalog-remix/app/components/Book.tsx

import type { GetBooksQuery } from "../models/sanity-generated";

export default function Book({ book }: { book: GetBooksQuery['allBook'][0] }) {
    return (
        <a href="/" className="m-2 rounded-xl p-6 border-4 border-gray-600 transition hover:-translate-y-1">
            <h2 className="font-bold text-2xl text-gray-600">{ book.title }</h2>
            <p className="text-xs text-gray-400">{ book.author }</p>
            <p className="text-gray-500 mt-2 text-md">{ book.description }</p>
        </a>
    );
}

Finally, head back to app/routes/index.ts and render one Book component for each book in your books variable:

// /Documents/projects/catalog-remix/app/routes/index.ts

// ...

export default function Index() {
  const { books } = useLoaderData<{ books: GetBooksQuery['allBook'][0][] }>()

  return (
    <div className="h-screen w-full p-4 font-mono">
      {/* ... */}
      <div className="grid grid-cols-3 p-12">
        {/* Render the books here 👇🏻 */}
        {books.map(book => <Book book={book} key={book._id} />)}
      </div>
    </div>
  );
}

Back over in your browser, you should now see a list of your actual data rendered out onto the page!

At this point your application is complete! Sanity is managing all of the data for your book catalog, which you are rendering via your Remix application 🎉

This is something to share with the world! In the next section, you will wrap things up by deploying your application.

Deploy your applications

In order to deploy this application, you will need to host both projects on GitHub. You will also deploy the Sanity project so you can access your Sanity Studio at any time via the web browser.

Push both projects to GitHub

Note : If you do not have a GitHub account, you can create one for free here.

To host your Remix applicaiton on GitHub, you first need to create a new GitHub repository that will hold your code. Head over to the GitHub dashboard and hit the New button to create a new repository:

You will be asked for a few details about the repository. Give the repository a name and hit Create repository. You should then be redirected to a page that looks similar to this one:

Grab the SSH URL for the repository by hitting the copy button signified in the image below:

Finally, in your terminal head over to the Remix application and run the following set of commands:

# /Documents/projects/catalog-remix
git init
git remote add origin <YOUR SSH URL>
git branch -m main
git add .
git commit -m "Initial Commit"
git push --set-upstream origin main

If you head back over to your GitHub repository page and refresh, you should now see your project's contents:

Next, within your Sanity project's code base create a new file at the root named .gitignore:

# /Documents/projects/catalog-sanity
touch .gitignore

Add the following to the contents of that file:

node_modules

This will ensure you do not push the node_modules folder to GitHub.

Note : Your Remix application came with this already set up.

Then, repeat all of the steps you followed to push your Remix application to a new GitHub repository on this project.

Once you have finished adding your Sanity project to its own GitHub repository, you will be ready to deploy your application and the Sanity Studio!

Deploy the Remix application

You will use Vercel to deploy and host your applications.

Note : You can create a free account if you do not already have one here.

Once you are in the dashboard, hit the Add New... button to create a new project in Vercel:

Select the Project option that drops down when you hit that button:

You will land on a page where you can choose a GitHub repository to deploy.

Note : You may have to connect your GitHub account. The steps to accomplish this will be on the page if you haven't connected an account already.

Select your Remix application's GitHub repository from the list of available repositories:

This will bring you to a page where you can configure the deployment.

On this page, expand the Environment Variables section and add a SANITY_API_URL environment variable, using the Sanity GraphQL API URL as the value:

Be sure to click Add after filling in the variable's details.

Note : If you are unsure about what to input for the environment variable's value, check the value you used in your .env file.

Finally, you can hit Deploy to deploy your application. This will kick off the Remix project's build process and deploy the application to a live URL!

When that finishes up, you will be sent to a page that looks like this:

If you click the image preview of your site, a new tab will open to your newly deployed website!

Deploy the Sanity project

The steps to deploy your Sanity application are all exactly the same, except you do not have to add an environment variable.

Head back over to the Vercel dashboard and click the Add New... button again, selecting the Project option from the dropdown.

You will again be redirected to a page where you can select with GitHub repository you want to deploy. Choose the repository that holds your Sanity project:

On the next page, simply hit the Deploy button to deploy the Sanity Studio:

Once the deployment completes, open up the live site to see what it looks like:

Oops... this doesn't look right! This problem occurred because Sanity is currently only accessible through localhost.

Head over to your local Sanity project's directory via a terminal and run the following command, replacing <YOUR_APP_URL> with the URL of your deployed studio:

# /Documents/projects/catalog-sanity
sanity cors add <YOUR_APP_URL> --credentials
# Example: sanity cors add https://book-catalog-sanity-ffwumik6d-sabinadams.vercel.app/desk --credentials

If you now head back to the browser and refresh, you should reach the Sanity Studio login page. Upon logging in, you will see your studio:

Wrapping Up

Throughout this tutorial you accomplished a lot!

Just to recap, throughout this tutorial you:

Built a Sanity project to host your book catalog data
Built a Remix application to retrieve and render your data
Added both projects to GitHub
Deployed both projects with Vercel

The end result is an easy-to-use book catalog, where you can at any time log in to your Sanity Studio from your web browser and add records to your book catalog without having to re-deploy the Remix application.

Tools like Sanity are super powerful, especially when you have complex content and/or multiple types of content to manage. They allow you to easily manage your data in an environment completely separate from your application.

If you have any questions, please feel free to reach out to me on Twitter!

Managing Lambda Size with Multiple Prisma Clients

Sabin Adams — Sun, 06 Feb 2022 07:49:32 +0000

The serverless architecture allows you to set up your applications in a way that is massively scalable, highly available, potentially cheap, and hands-off in terms of managing the host server.

These benefits have drawn many to begin adopting this architecture. There are, however, some snags you may run into along the way.

The one we'll be looking at today is Lambda's size-limit, specifically when your application uses Prisma, and how to architect your system in a way that maintains a low lambda size.

Let's jump right in!

Prerequisites

We will be talking about and building out a sample serverless function on AWS Lambda using the Serverless framework. As such, you should be at least somewhat familiar with:

Node.js
ExpressJS Framework
Serverless concepts
Serverless Framework
Prisma
AWS ecosystem

If you aren't super familiar with any or all of these, don't sweat it. I'll try to explain as we go. But a basic understanding will be helpful.

Make sure you've got Node.js installed
Also make sure you have an AWS Account

The full code for the sample project can be found here

The Problem We're Solving

Prisma is a fantastic tool that allows you to easily set up a fully type-safe "next-gen ORM" and generate a feature-rich library that you can use to interact with your database.

As Prisma grows in popularity, more and more people are starting to use it in their serverless applications and functions. One finding resulting from this, however, is that the Prisma library can be pretty expensive in terms of file-size, especially when using multiple Prisma Clients.

This problem is largely due to the size of the Prisma Engine binaries, which are files that handle the connections and interactions with the database.

Each Prisma Client includes a copy of the binary for your OS (or whichever OS you have configured Prisma to use) and currently you need a separate Prisma Client for each database and each schema within those databases you would like to use.

NOTE: The prisma team is working on an enhancement to alleviate a part of this issue and allow multiple schemas in one client.

There are multiple different operating systems the Prisma Engine binary can be built for. AWS Lambda uses the rhel-openssl-1.0.x binary, which is downloaded into each generated Prisma Client as well as into the node_modules/@prisma folder. This binary tends to be around 41mb at the time of writing this article.

AWS Lambda has upload limits of 50mb for zipped artifacts (unless you opt to use S3 to store your deployment package and download it when the function is invoked) and 250mb for the unzipped version.

As you can imagine, as you add Prisma Clients (maybe your database has 5 schemas you want access to and you therefore need 5 clients), the sizes of all those files add up quickly!

In order for this awesome technology to be feasible in a serverless setting, we need to figure out a way to get that file size down...

To demonstrate the method I've come up with to alleviate this size problem, let's build out a simple ExpressJS application with a couple of Prisma Clients and deploy it in a way that keeps the file size manageable.

Setting Up An ExpressJS Server

First off, we'll get the basic skeleton of our Express server started. Head over to your directory of choice and create a folder to hold your project. I'll be creating a function that handles recording Dogs and Cats in my pet store 🐶🐈.

mkdir petstore && cd petstore

We're going to want a few dependencies to allow us to use and run Express and perform a few tasks later on.

npm init -y
npm i -s express dotenv fs-extra serverless-http

We'll also need a few development dependencies to allow us to use Prisma, run our server with live-reload, and configure custom scripts in our Serverless config later on.

npm i -d nodemon prisma serverless-scriptable-plugin

Open up the project (code . for VSCode users) and create a file named index.js at the root of the project with the following boilerplate code to start off our Express app:

const express = require("express");
const port = process.env.PORT || 8000;

// Get express application
const app = express();

// Set up default route
app.get("/", (req, res) => {
    res.status(200).send(`Welcome to the Petstore!`);
});

// Start 'er up!
app.listen(port, async () => {
  console.log(
    `Listening on: http://localhost:${port} `
  );
});

Go ahead and run the application using Nodemon

nodemon index

You should see your server come up! If you hit that default route at localhost:8000, either using some HTTP client or your browser, you should see your response come back successfully!

NOTE: I'm using Thunder Client, an HTTP client extension for VSCode. It's amazing, give it a try if you haven't already!

Setting Up Multiple Prisma Clients

The next thing we'll want to do is set up two Prisma Clients so we can interact with two different databases in our Express app. We'll first use the Prisma CLI to initialize Prisma in our project and scaffold out our first schema.

prisma init

This will create a /prisma folder and a fresh schema for you to work with. If you aren't familiar with Prisma and its set of tools, definitely check out the docs! It's a powerful piece of software!

We'll go ahead and rename that initial schema.prisma to dog.prisma, as it will define our Dog database. That file should contain a default shell of a schema already set up. We're going to update those contents to use SQLite as the database and add a Dog model.

generator client {
  provider = "prisma-client-js"
  output = "../node_modules/.prisma/dog-client"
  binaryTargets = ["native", "rhel-openssl-1.0.x"]
}

datasource db {
  provider = "sqlite"
  url = env("DOG_URL")
}

model Dog {
  id String @id @default(cuid())
  name String
  color String
}

So what does this do exactly?

Sets up a datasource that will connect to a SQLite database found at a path provided in the environment (we'll set that up in a sec).
Defines a Dog model that will correlate to a Dog table in our database.
Important: Specifies that we want to download the rhel-openssl-1.0.x binary along with the native binary, which is the binary needed by AWS Lambda
Important: Specifies an output directory for our generated client.

By default the output of the Prisma Client is node_modules/.prisma/client. This is fine for a single client, but we are going to use multiple clients! We are creating our own folder in .prisma to hold our dog client.

NOTE: You can output the client anywhere, even outside of node_modules, but I've chosen here to allow us to easily make use of Layers in AWS later on.

The prisma init command also created a .env file. Go ahead and replace the contents with the following to set up our database's file path:

DOG_URL="file:./dog.db"

We'll now do the same exact process, but create a Cat database! Add another file to the /prisma folder called cat.prisma with these contents:

generator client {
    provider = "prisma-client-js"
    output = "../node_modules/.prisma/cat-client"
    binaryTargets = ["native", "rhel-openssl-1.0.x"]
}

datasource db {
    provider = "sqlite"
    url = env("CAT_URL")
}

model Cat {
    id String @id @default(cuid())
    name String
    color String
}

And update .env to add an environment variable named CAT_URL:

CAT_URL="file:./cat.db"

We can now generate our databases and Prisma Clients.

# Create the DBs using Migrations
prisma migrate dev -name init --schema=prisma/dog.prisma
prisma migrate dev -name init --schema=prisma/cat.prisma

Great! Your file tree should look something like this at this point:

Those migrate commands set up a migration history for your databases, created the database files (because we are using SQLite) and generated the Prisma Clients for us to use in our application!

Let's put those to use and start playing with data.

We'll need to import the Prisma Clients and instantiate them in index.js so we can use them in our routes.

const express = require("express");
const { PrismaClient: DogClient } = require('.prisma/dog-client'); // <- 
const { PrismaClient: CatClient } = require('.prisma/cat-client'); // <-
const port = process.env.PORT || 8000;

const dogClient = new DogClient(); // <-
const catClient = new CatClient(); // <-

Error Handling and Middlewares

Our routes will have some asynchronous actions, so let's add a utility function after we instantiate our Express app to wrap our routes in. We'll use this to gracefully throw errors in the asynchronous context.

I'm also adding a middleware here to parse out JSON bodies in our requests.

const app = express();

// Parse JSON bodies in requests
app.use(express.json());

// Wrapper for async routes
const asyncHandler = (fn) => (req, res, next) => {
  Promise.resolve(fn(req, res, next)).catch(next);
};

Next we'll want to set up an error handler to gracefully catch our application's errors. Add this near the bottom of the file, right before we call app.listen.

// Catch any errors, throw detailed info if in development
app.use((err, req, res, next) => {
  res.status(500).json({
    message: "Something went wrong",
    ...(process.env.NODE_ENV === "development"
      ? { devMessage: err.message, devStack: err.stack }
      : {}),
  });
});

Adding Routes To Our API

Great, now we're ready to add some routes! We're going to create four endpoints in our API:

POST /dog: Creates a dog
GET /dog: Gets all dogs
POST /cat: Creates a cat
GET /cat: Gets all cats

Make sure to add these routes before the error handler middleware we added previously

We'll keep these routes super simple:

// Get all dogs
app.get(
  "/dog",
  asyncHandler(async (req, res) => {
    const dogs = await dogClient.dog.findMany();
    res.json(dogs);
  })
);

// Create a dog
app.post(
  "/dog",
  asyncHandler(async (req, res) => {
    const { name, color } = req.body;
    const newDog = await dogClient.dog.create({
      data: { name, color },
    });

    res.status(200).json(newDog);
  })
);

// Get all cats
app.get(
  "/cat",
  asyncHandler(async (req, res) => {
    const cats = await catClient.cat.findMany();
    res.json(cats);
  })
);

// Create a cat
app.post(
  "/cat",
  asyncHandler(async (req, res) => {
    const { name, color } = req.body;
    const newCat = await catClient.cat.create({
      data: { name, color },
    });

    res.status(200).json(newCat);
  })
);

Beautiful! We've got ourselves an API in the works! If you hit a few of the endpoints, you should find you are able to create and view your Cats and Dogs.

NOTE: You can also use Prisma Studio to view this data in your database. Run prisma studio --schema=prisma/dogs.prisma to check out the Dogs database. Change the schema file to cats.prisma to see the Cats.

Configuring Serverless

Okay enough setup, we've got our app going and working! Let's deploy this sucker to AWS Lambda so we can start analyzing and trimming things down!

Wrapping The Express App

In order to run this application in a serverless environment, we'll need to wrap our app using serverless-http and export that as our serverless function handler.

const express = require("express");
const { PrismaClient: DogClient } = require(".prisma/dog-client");
const { PrismaClient: CatClient } = require(".prisma/cat-client");
const serverless = require('serverless-http'); // <-
const port = process.env.PORT || 8000;

// Our code...

module.exports.handler = serverless(app); // <-

Our application should be runnable in a serverless environment now!

Setting Up Credentials in Serverless Framework

The next thing we need to do is install the Serverless Framework CLI globally.

npm i -g serverless

This provides us with a set of tools and a framework to help us easily build out our AWS deployment configurations and architecture.

We'll also need to configure our AWS access keys so the Serverless Framework will have access to deploy to our AWS account. Sign in to your AWS account and grab your access keys. You can find them by following along below:

Once you've got those, run this command to configure your credentials locally in Serverless Framework.

serverless config credentials \
  --provider aws \
  --key <access-key> \
  --secret <secret-access-key>

More details on setting up your credentials here

Configuring The Service

Next we'll create a serverless.yml file in the root of the application where we will configure what to deploy to AWS and how.

service: petstore
frameworkVersion: '3'
provider:
  name: aws
  runtime: nodejs12.x
  stage: dev
  region: us-east-1
functions:
  petstore-api:
    handler: index.handler
    events: 
      - httpApi: '*'

This does a few different things. Notably:

Defines a service we are going to deploy
Defines the petstore-api function we want to deploy
Sets up our Express API as the function handler (index.handler corresponds to the handler export in index.js)
Allows the function to handle ALL HTTP requests

That's all the config we need to get this thing up and running. It won't be slimmed down yet, but this is the most basic setup.

Go ahead and run sls deploy to deploy this function. This will take a few minutes, but as you are waiting you may notice this output:

Our function is already almost 114mb! And that's the zipped artifact! That's already above the limit enforced in AWS Lambda functions. This deployment will fail.

If we unzip the artifact we attempted to deploy (found in the .serverless folder) and take a look at where the size is coming from you'll find something like this:

As you can see here, unzipped we're at ~299mb, and ~281mb of that is coming from Prisma's files!

So with two minimal Prisma Clients configured we can't even deploy! We're going to need to trim some of this down to get things going. No problem though, there are a few things we can do to accomplish this.

Trimming Things Down

We have a few different tricks we can use to get this file size down and to keep it low as we add more and more Prisma Clients. These can be used individually, or in combinations. In this example, we'll employ each different method together to get a super slim deployment.

Using Patterns To Exclude Files

The first thing we can do is use patterns to exclude files from the zipped output. Prisma generates files in node_modules within folder called @prisma, prisma, and .prisma.

A lot of these files are not needed for our application to run. For example, @prisma contains a bunch of engine binary files we don't need and that take up a lot of space.

Add the following configurations above your function definition in serverless.yml:

package:
  patterns:
    - '!node_modules/@prisma/engines'
    - '!node_modules/prisma'
    - '!node_modules/.prisma/**/libquery_engine-*'
    - 'node_modules/.prisma/**/libquery_engine-rhel-openssl-1.0.x.so.node'

Here we are:

Excluding every engine from @prisma/engines
Excluding the node_modules/prisma folder. It's only used locally for things like CLI operations that aren't needed in our running application
Excluding all engines from the generated clients except for the openssl-1.0.x file Lambda needs.

If you go to deploy this you'll notice your file size is already significantly smaller and should actually succeed (my deployment ended up around ~42mb).

Does This Solve All The Size Problems?

This is fantastic and should alleviate the majority of your size issues. There is, however, still a potential problem depending on your use-case.

As more and more clients get added, each of those clients will still have their openssl-1.0.x binary file. Soon enough we'll get right back to the size we were at before!

Let's say we add Bird, Snake, and Rabbit clients to the project. Go ahead and create new schemas for each of these, run your migration and generate the Prisma Client for each.

Now, to make our lives a little easier, create a folder called ci and add a file named generate-prisma.sh with these contents:

echo "Building Libraries to ensure binaries are available..."
for file in **/*.prisma
do
    echo "Generating ${file##*/}" 
    npx prisma generate --schema=${file}
done

This will go through every schema file and generate the Prisma Client. We'll run this automatically every time we start to package a deployment using the serverless-scriptable-plugin to make sure we have our client generated and ready for use. Over in serverless.yml add the following config:

plugins:
  - serverless-scriptable-plugin
custom:
  scriptable:
    hooks:
      'package:initialize': 'sh ./ci/generate-prisma.sh'

If you run sls deploy again you should see your Prisma Clients all get generated and packaged. My package ended up being around ~95mb, even with the excludes we configured before! That's getting awful big again and doesn't allow much space for your actual function's code.

We need to set something up to consolidate those engine binaries to one location and share it across all clients.

Setting Up A Layer

The next thing we can do is make use of the concept of Layers in AWS. A layer allows us to split out libraries and dependencies into a "layer" that can then be applied to our serverless function to help with code-sharing and maintaining a small file size.

Each function can have up to five layers attached, however in our scenario we are only going to use one.

The goal here is to break out our Prisma-related dependencies from node_modules into a layer and apply that layer to our function when invoked.

To start this off, let's create another script in the ci folder named create-prisma-layer.sh that will be responsible for building out our layer.

echo "Clearing out old layer..."
rm -rf .prisma-layer

echo "Generating Prisma Client"
sh ci/generate-prisma.sh

echo "Creating Prisma Layer..."
mkdir -p .prisma-layer/nodejs/node_modules/.prisma
mkdir -p .prisma-layer/nodejs/node_modules/@prisma

echo "Copying over @prisma and .prisma to the layer"
cp -r node_modules/.prisma .prisma-layer/nodejs/node_modules
cp -r node_modules/@prisma .prisma-layer/nodejs/node_modules

echo "Copying over the prisma folder, where our SQLite DBs are (not necessary for non-sqlite)"
cp -r prisma .prisma-layer/nodejs/prisma

echo "Layer Built"

This creates a folder called .prisma-layer that will hold our generated layer. Then we move in all of the modules we need.

I am also moving over the prisma folder that contains our SQLite DBs so we don't have to package those up with our actual function.

Now over in serverless.yml, replace the custom hook we added with this to run our script before packaging our artifacts:

custom:
  scriptable:
    hooks:
      'package:initialize': 'sh ./ci/create-prisma-layer.sh'

We can then describe that layer in our service configuration:

layers:
  prisma:
    path: .prisma-layer
    description: 'Layer for Prisma Clients'
    package:
      patterns:
        - '!nodejs/node_modules/@prisma/engines/*'
        - '!nodejs/node_modules/.prisma/**/libquery_engine-*'
        - 'nodejs/node_modules/.prisma/**/libquery_engine-rhel-openssl-1.0.x.so.node'
        - '!nodejs/prisma/**'
        - 'nodejs/prisma/*.db'

And apply that new layer to our function:

functions:
  petstore-api:
    handler: index.handler
    layers:
      - { Ref: PrismaLambdaLayer }
    events: 
      - httpApi: '*'

For info on how to use Layers, check out the AWS docs

Because we've done this, we no longer need to include any of those Prisma dependencies in our function's package. Let's be sure to filter those out using our patterns configuration. Replace the current config with the following:

package:
  patterns:
    - '!node_modules/prisma'
    - '!node_modules/.prisma'
    - '!node_modules/@prisma'
    - '!.prisma-layer'
    - '!prisma'
    - '!ci'
    - '!*.*'
    - '!.env'
    - 'index.js'

This essentially tells the Serverless Framework not to package any files in the root except index.js and to not include the modules, temporary folders, and util folders we don't need in our deployment.

Alright, we've got our CI functions generating Prisma and building out a Prisma layer. We've got the deployment for our function and layer configured.

Let's give it a shot! Go ahead and deploy the project.

Fantastic! Our function's artifact size is down to ~4.3mb! But look at the size of that layer! 💥 We just moved the bulk from one place to another...

A layer has the same size constraints as a full function does, so this deployment is going to fail.

This is because even though we moved off our Prisma dependencies to a layer, that layer still has all those copies of the Prisma Engine binaries!

We'll need to somehow find a way to only keep one copy and make sure every Prisma Client uses it... 🤔

Fortunately I've got a trick for that!

Slimming Down The Layer

When a Prisma Client is instantiated in your code it will look in .prisma/<client-folder> to find the binary it needs. If it doesn't find it there, it searches a number of other places where the binary might be hiding.

One of those places is a folder called .prisma/client.

What this means for us is that if we create a folder called .prisma/client in our layer and place the binary there, we can delete it everywhere else and all the clients should use that one!

Let's see it in action. Pop open that /ci/create-lambda-layer.sh file and make the following changes:

echo "Clearing out old layer..."
rm -rf .prisma-layer

echo "Generating Prisma Client"
sh ci/generate-prisma.sh

echo "Creating Prisma Layer..."
mkdir -p .prisma-layer/nodejs/node_modules/.prisma
mkdir -p .prisma-layer/nodejs/node_modules/@prisma

echo "Copying over @prisma and .prisma to the layer"
cp -r node_modules/.prisma .prisma-layer/nodejs/node_modules
cp -r node_modules/@prisma .prisma-layer/nodejs/node_modules

echo "Copying over the prisma folder, where our SQLite DBs are (not necessary for non-sqlite)"
cp -r prisma .prisma-layer/nodejs/prisma

# Add this
echo "Copying over the OpenSSL 1.0.x Binary to the generic client folder in the layer"
mkdir -p .prisma-layer/nodejs/node_modules/.prisma/client
cp -f node_modules/.prisma/**/libquery_engine-rhel-openssl-1.0.x.so.node .prisma-layer/nodejs/node_modules/.prisma/client

echo "Layer Built"

This will go through each client folder and copy (with a replace) the binary we want into our layer at .prisma/client. The result is we get one binary file in that folder.

Now over in our serverless.yml we can configure our Prisma layer's package pattern matcher to exclude binary files that aren't in this folder:

layers:
  prisma:
    path: .prisma-layer
    description: 'Layer for Prisma Clients'
    package:
      patterns:
        - '!nodejs/node_modules/@prisma/engines/*'
        - '!nodejs/node_modules/.prisma/**/libquery_engine-*'
        - 'nodejs/node_modules/.prisma/client/libquery_engine-rhel-openssl-1.0.x.so.node'
        - 'nodejs/node_modules/.prisma/**/libquery_engine-rhel-openssl-1.0.x.so.node'
        - '!nodejs/prisma/**'
        - 'nodejs/prisma/*.db'

Give that a run and see what you get!

Now that's more like it! 🎉

Our function and layer are pretty slim and should be able to deploy successfully!

Setting Up Environment Variables For Lambda

The only problem at this point is that in order to test out the API running on our serverless function, we need to set up some environment variables and handle an issue with SQLite on serverless.

In the configuration for your function, we'll add a few environment variables our function needs.

functions:
  petstore-api:
    environment:
      DOG_URL: file:/tmp/prisma/dog.db
      CAT_URL: file:/tmp/prisma/cat.db
      BIRD_URL: file:/tmp/prisma/bird.db
      SNAKE_URL: file:/tmp/prisma/snake.db
      RABBIT_URL: file:/tmp/prisma/rabbit.db
      NODE_ENV: aws-testing
    handler: index.handler
    layers:
      - { Ref: PrismaLambdaLayer }
    events: 
      - httpApi: '*'

You may be confused about why we're pointing to /tmp/prisma to find the SQLite db files. That's because in a Lambda function's file system, only the /tmp folder is writable.

If we leave the db files outside of that directory, we would only be able to perform READ operations on the database!

Because of this limitation, in our code we need to copy those files over to /tmp when the application starts up in an AWS Lambda environment.

const fs = require("fs-extra");

// ... application code ...

// Start 'er up!
app.listen(port, async () => {
  // Only needed for SQLite
  if (process.env.NODE_ENV === "aws-testing") {
    // If we are on AWS, our SQLite DBs aren't writable unless in tmp
    await fs.copy("/opt/nodejs/prisma", "/tmp/prisma");
  }
  console.log(`Listening on: http://localhost:${port} `);
});

This is just a workaround to get our example working. In a production setting using a database other than SQLite these steps wouldn't be necessary.

Alright, that's all configured. Now we should be able to re-deploy and actually use our function!

NOTE: This data will be short-lived as it will only exist as long as the Lambda function exists

Awesome! We're able to save and return our Dogs! The same should work with Cats. And we're doing it all on a super slimmed-down function with multiple databases!

Pretty rad 🤘🏻

Conclusion

The solutions we looked at above make it super possible to use Prisma in a serverless setting without having to worry about hitting size constraints.

While we took a specific path to fit our specific needs, the same concepts can be applied to nearly any project structure you may have with some careful thought.

The main goals are:

✂️ Remove any un-necessary files
🖖🏻 Split out the large Prisma files into a layer
♻️ Slim that layer down and consolidate the binaries to one shared location

Hopefully this example has helped and gives you the information you need to slim down your serverless functions that are using Prisma!

If you have any other tips or tricks to accomplish this same goal, I'd love to hear them! Shoot me a message on Twitter!

Thanks for reading, and have fun deploying some serverless functions using Prisma!

Dynamically Setting Meta Tags in Remix

Sabin Adams — Tue, 01 Feb 2022 11:18:59 +0000

Often when developing a website, the meta information about a webpage is determined by some of the content that gets loaded into the page.

A product's page for headphones might have a description: Sony Headphones, the number one product in its class!, a chat page might be titled: Conversation with Leeland, or maybe your page has a specific image you'd like to show up on google's search results, etc...

This is easy enough to set up with Meta tags in HTML, but how would you set the metadata on a page that uses a shared component that can handle many different pages? (For example a re-usable product page component)

Remix gives us a way to set this up super easily.

The repository for the final sample project can be found here

Starting A Remix Project

We're going to create a Profile Page at a url like /profile/<username> and updates the browser's title tab using metadata to <username>'s Profile Page.

To get things started, we'll go ahead and create a new Remix project.

npx create-remix@latest

This tutorial assumes you have node installed and up-to-date

Once you've gone through that, go ahead and pop open your new project.

Setting up a Profile Route

Remix's routing system works off of the files in your project. The existing /app/routes/index.tsx will be your home page route at /.

We need to set up a route for a profile that can take any username and fetch the user's data accordingly.
In /app/routes create a file named profile.$username.tsx.

Because of the naming convention used here, this will be a route at /profile and has a sub-route with a wild-card param $username. Combined we get our /profile/$username route.

Go ahead and paste the following code into that file:

import { json, LoaderFunction, useLoaderData } from 'remix'

type User = {
    username: string;
    first: string;
    last: string;
}

export let loader: LoaderFunction = async ({ params }) => {
    const users: User[] = [
        {
            username: 'sabinthedev',
            first: 'Sabin',
            last: 'Adams'
        },
        {
            username: 'leeland',
            first: 'Leeland',
            last: 'Adams'
        }
    ]

    const user = users.find(user => user.username === params.username)

    if (!user) {
        throw new Response('Not Found', {
            status: 404
        })
    }
    return json(user)
}

export default function Profile() {
    const user = useLoaderData()

    return (
        <div style={{ display: 'flex', height: '100%', justifyContent: 'center', alignItems: 'center', background: '#0c0f12' }}>
            <h2 style={{ flex: 1, textAlign: 'center', color: '#f1f1f1', fontFamily: 'system-ui' }}>{user.first} {user.last}</h2>
        </div>
    );
}

This sets up just a basic page that will display the user's first and last name. Currently, we have manually added two users to our "database", but we can imagine this is connected to an actual data store!

To test this out, start up your server by running npm run dev and head over to http://localhost:3000/profile/leeland.

Beautiful! But notice up at the top that not-so-useful New Remix App tab title? We'll want to change that to something more meaningful.

Setting Dynamic Metadata

To set up our metadata, we can export a meta function from our route that Remix will use to automatically wire up our desired metadata.

Start off by making sure to import MetaFunction from the remix library.

import { 
    json,
    LoaderFunction,
    useLoaderData,
+    MetaFunction
} from 'remix'

Then to get things started go ahead and add this exported meta function:

export const meta: MetaFunction = () => {
    return {
        title: 'Profile Page'
    }
}

If you check back in your browser now, you'll see that Remix registered that function and automatically added the meta tag for you to set up the tab title!

This is cool, but what if we want a custom title depending on the user's profile we are visiting? The MetaFunction in remix takes in an object with a bunch of useful data. Particularly the data key, which contains the data from our Loader function.

Let's tap into that to get access to the user we loaded up.

export const meta: MetaFunction = ({ data }: { data: User }) => {
    const formatName = (name: string) => name.charAt(0).toUpperCase() + name.slice(1)
    return {
        title: `${formatName(data.username)}'s Profile Page`
    }
}

Now back over on our profile page we should see a much more descriptive message!

Using a process like this, we can dynamically set any kind of metadata we'd like for our page!

Bonus: Setting up Twitter Metadata

What if we want to share the link to this profile on twitter?

I'll be using a tool called Ngrok and a Twitter Card Validator to preview what our link preview would look like in a Twitter post.

Currently if we check out our link preview, we will see something like this 👎🏻:

We don't have any metadata describing to Twitter how we want this data displayed! Let's update our meta function to include some details:

export const meta: MetaFunction = ({ data }: { data: User }) => {
    const formatName = (name: string) => name.charAt(0).toUpperCase() + name.slice(1)
    return {
      title: `${formatName(data.username)}'s Profile Page`,
      'twitter:card': 'summary_large_image',
      'twitter:creator': `@${data.username}`,
      'twitter:site': `@${data.username}`,
      'twitter:title': `${data.first} ${data.last}`,
      'twitter:description': `${data.first} ${data.last}'s profile page. Check it out @${data.username}`
    }
}

Now we should get something more like this:

Ahh, much better! It displays some useful information about the link we are sharing! We could also add a preview image to this using the twitter:image property.

Conclusion

Remix has a great set of tools that take a lot of the grunt-work out of the mix for you. This is just one example of those!

Hopefully this was helpful and will encourage you to set some of that important metadata to help provide users and search engines more context into what your site has to offer!

Thanks for reading!

p.s. If you like this article, be sure to follow me on Twitter for updates when I post new articles!

When Serverless Meets Traditional Relational Databases

Sabin Adams — Sat, 22 Jan 2022 04:02:52 +0000

FaaS, or Functions as a Service, is a concept you have likely heard of recently as it has rapidly risen in popularity over the past few years.

As more and more people are beginning to take a look at and try out Serverless models in their own projects, be it via AWS Lambda, Azure Functions, or any other provider available, we have began to see the amazing possibilities it brings to the table.

We have also, however, found a few pitfalls. One being the realization that a Serverless model does not get along with a traditional Relational Database very well.

In this article we're going to take a look at some specific problems relating to traditional databases that have been found, and potential solutions to those problems.

What Is Serverless and Why Is It Popular?

Before we dive into the potential issues with Serverless and traditional databases, let's get some insight into what Serverless is and some of the problems it solves.

Shift of Responsibility

A Serverless model, despite its name, still must involve a server. The difference here is a shift in who has to manage that server.

A major selling point of the Serverless architecture is that we as Developers and DevOps Engineers don't have to worry about maintaining the actual server our code is running on. The Serverless provider you use spins up and manages a container for your application to live on automatically.

Potentially Cheaper

Another upside of Serverless is the potential for it to, in the long-run, end up being cheaper than a traditional deployment model.

Your code in this model is no longer running on a server that is charged by the hour or second. Instead, your code becomes available as-needed on a container that is spun up by your provider and brought back down when the request is complete.

Scalability

The last upside is definitely one of the major points of Serverless that makes it a game-changer, and a different class of deployment models.

As mentioned above, your code becomes available as-needed, and as your demand increases your infrastructure will automatically scale up the amount of available instances of your code to support that demand. Individual containers are kept alive for pre-configured amounts of time in case they can be re-used.

This is HUGE as it allows for a significant amount of traffic to be handled in a way that is efficient and cost-effective.

This is also where we find one of the major issues with Serverless in relation to traditional Relational Databases such as MySQL or Postgres.

Where Problems Arise

To better understand why the otherwise beneficial scaling capabilities of Serverless could be a bad thing when paired with traditional databases, let's get an idea of how different deployment models connect to and interact with a database server.

There are many different architectures and models, but we will look at three major ones that tend to be the most commonly seen in the wild:

Monoliths
Microservices (Distributed Systems)
Serverless

Monoliths

In a monolithic architecture, your entire application lives on one server. You might have multiple copies of your entire application on separate servers behind a load-balancer, but the idea is that all of your services, data access layers, user interface, and everything else relating to your application is shipped as one package.

This type of architecture makes it relatively easy to manage connections to a database server. In your application, you can define a connection pool limit and fairly simply and confidently know how many connections to your database to expect from your applications at any given time.

No auto-scaling is going on, no changes are going on. A single set of connections are used for your entire application.

Microservices

In a microservice architecture, things start to get a little bit more complicated. Rather than having one large layer where every piece of your application lives and one database to serve them all, you instead split the application up into logical services. Each service typically has its own set of connections to its own database.

Serverless

Now we get to the topic in question, the serverless model. In a serverless model you can have many different serverless functions running in containers and autoscaling to fit your needs.

These containers are not in existence until called upon via an API gateway, which may trigger a new connection pool to your database server.

As your application receives more and more traffic, possibly during a peak time, new instances will pop into existence and run concurrently, each setting up a connection pool to the database server. Depending on the traffic this could reach up to 1,000 concurrent executions of your serverless function! (or more)!

Why This Can Be A Problem

As you may have begun to already see, this can pose a real problem for a traditional database.

Any database has a limited amount of connections it will support in order to reserve network and memory usage. In a traditional architecture you would likely have a connection pool set up, which helps manage the re-use of connections and removal of idle or unused connections.

This whole orchestration, however, depends on the concept of keeping a connection open and available. That doesn't really fit into the model of serverless functions that only exist when they are needed. Following this model, you will find that you are frequently and quickly exhausting your connection pool when traffic picks up.

To put this into perspective let's think about some numbers. Let's say we've configured a connection pool in a serverless function with the following settings:

"pool": {
   "min": 0,
   "max": 15,
   "idle": 10000
}

This will tell our function instance that it should open up 15 connections and close out any connections that have been idle for 10 seconds.

Function Instances	Connections
1	15
5	~75
10	~150
20	~300
50	~750

Now keeping this in mind, let's take a look at the connection limits for some of AWS's instance classes. The connection_limit for MySQL-Flavored RDS is determined by the calculation: {DBInstanceClassMemory/12582880}.

If we were to choose the db.m5.xlarge instance class which has 16gb of memory, that equates to 1,365 maximum connections. (Keep in mind, we don't want to get close to the limit for performance reasons).

For more info on AWS's connection limits, there is documentation here.

Thinking back on those numbers in the table, imagine your product was having a huge spike in traffic due to an event and 200 concurrent requests hit your API gateway.

At this point, your database would begin to bottleneck. Connections would begin to stack up and soon enough you'd hit the limit.

This could end up being detrimental to the functionality of your code, your data, and even your product's reputation.

While this problem is inevitable with this infrastructure, there are some potential solutions and workarounds that can alleviate, and depending on your needs resolve, the symptoms of this issue.

Potential Code-Based Solutions

The first set of potential solutions are changes and precautions you can implement in your serverless functions to help manage the connection pool a bit.

Lowering The Connection Pool Limit

While keeping a balanced connection pool may be important in a traditional architecture to allow your application to handle concurrent requests to the database, that isn't very import (actually it isn't important at all) in the context of a serverless function.

A serverless function, by design, can only handle a single request at a time. It executes upon receiving a request and traffic to that instance is blocked until the execution resolves.

What this means for us is that we don't really need to care about having multiple connections available to any single instance of our function. We can, and should, set the connection maximum in our pool to 1.

"pool": {
   "min": 0,
   "max": 1,
   "idle": 10000
}

This will significantly boost the amount of concurrent requests your function should be able to handle. As new instances spin up and queues build up on existing instances each new instance will have one open connection to your database server.

Adjusting The Idle Time

While the previous potential solution will likely help out a ton, there are still scenarios where a limit can be hit. Heavy traffic for an extended period of time can cause a myriad of problems.

More and more instances will be spun up, each opening a database connection
As instances finish their processes, they will remain open for some time, possibly holding on to their connection
When a connection is finally dropped from the pool, it does not necessarily mean that connection is available right away. The database engine still needs to process the closing of the connection.

Because of the composition of these problems, connections will continue to rise and rise when receiving massive amounts of rapid requests until the database reaches its max and gets plugged up.

In a short-lived function, lowering the idle time will allow the connections to be dropped from the pool in a shorter amount of time to free up connections for new instances that need a connection.

"pool": {
   "min": 0,
   "max": 1,
   "idle": 5000
}

WARNING: While lowering the idle time can significantly help under extended periods of heavy traffic, lowering it too much can be a negative. In fact, it could significantly hurt your connection availability.

This is because of the fact that a function's execution time may be slower than that idle time if it gets too low. In some edge cases, this may cause a database connection to be dropped from the pool before the function needs it mid-execution, and a new one will need to be created to finish off the request.

The database server likely hasn't closed the connection yet so you are essentially doubling your connections in that instance!

In a long-living function, it may be a good idea to do the opposite and increase the timeout limit to allow you to keep your connections open long enough to be effectively re-used across multiple executions in your instance's lifetime.

Another warning is worth mentioning here. Keeping the connections open for too long may result in an overwhelmed database because more connections may begin to stack up before the cleanup process drops idle connections.

Finding a good balance is key.

A Warning: Manually Closing Connections

One potential workaround worth you might initially think of is manually opening and closing your connections within your actual function to ensure the connection closes at the end of execution.

While this can theoretically lower the amount of concurrent connections, this should not be the go-to solution. You'll likely want to try the other options first and make sure your connection pool settings are optimized.

This is because manually opening a connection on each run creates a trade-off: you get easy connection handling at the cost of huge amounts of latency.

Take this code for example:

module.exports.handler = (event, context, callback) => {
  var client = mysql.createConnection({
    /* your connection info */
  })

  client.connect()

  /* Your business logic */

  client.end()
}

While this would fix the problem of having a stale connection, the latency this would cause by having to open and close a connection on each execution is likely not worth it. There would also be no potential for re-use of connections.

In general, it is recommended to initialize your connection outside of your handler because that connection will get frozen with the instance during downtime and will be thawed if another request in the queue executes the function before it is spun down.

Potential Infrastructure-Based Solutions

Until now we have looked at changes to the actual code that could help lower the amount of concurrent connections. There are also measures we can take on the Infrastructure side to try to streamline some of this.

Database Proxy

One possible remedy to the connection pool issue is a Database Proxy such as AWS RDS Proxy or Prisma’s Prisma Data Proxy.

What a database proxy does is manage a connection pool for you outside of your serverless function's context. In doing so, it removes the latency caused by opening a connection for each new instance of your function.

The configured proxy will queue up requests from your functions and throttle them in a way that, although causing some latency, prevents your database from being bombarded with an overwhelming amount of requests at once.

Caching

The last potential solution I will mention is Caching. Effective usage of tools such as AWS's ElastiCache may allow some requests to not have to hit the database at all.

If a set of data is being retrieved from the database often, storing that in the cache will allow you to check for the existence of that data in the cache before running your query. If it exists, you can skip the query altogether!

This would cause some, and potentially many, executions of your function that would have otherwise used up a connection to not use one at all! In the long run, under heavy load, this could be HUGE.

Conclusion

In this article we took a look at the potential problems that come about when connecting to a traditional database from a function, or set of functions, deployed using the serverless model.

The solutions, whether used individually or in combination with each other, provide potential resolutions and definite alleviation of the symptoms of this bad relationship between the two technologies.

The main takeaway here should be that a serverless architecture can definitely run effectively in conjunction with a traditional database as long as the proper configurations are put in place and precautions are taken, while taking into consideration how both pieces work individually.

I hope this was helpful in understanding the problem presented and how we might go about avoiding them! Thanks so much for following along!

End-To-End Type Safety: What, Why and How

Sabin Adams — Fri, 21 Jan 2022 11:46:45 +0000

A difficult challenge developers often face is creating and managing types across the entirety of their software stack in a way that allows for quick and easy error and change detection.

Without a proper system in place, simple changes to your database's schema, your API layer's definition of an object, or even your web client's definition of that object could result in missing or malformed data somewhere in the chain of commands if each place wasn't updated properly.

These kinds of problems are NO FUN to debug!

In this article we're going to take a look at the cause of this issue, what a safe solution might look like, and then work through a simple full-stack application that puts a solution in place to solve the problem, making the DX (developer experience) a million times better!

Prerequisites

The application we will be building will require the following:

Node.js installed on your machine
A basic understanding of JavaScript, TypeScript, and their ecosystem

We will be using these technologies and tools to build our application:

Nx: A build system that makes developing monorepos simple
React: Front-end library
NestJS: Back-end Node.js Framework
Prisma: ORM
SQLite: Database

Don't worry if you aren't familiar with the individual pieces. I'll explain as we go!

You can find the final application on GitHub

A Little History

Let's take a step back in time for a second. It's the early 2010's and Node.js is the cool new kid on the block. Every developer is eager to jump in and get their hands into some JavaScript that magically runs on a server!

More and more people begin adopting and contributing to this new technology, and soon even large companies like Uber and LinkedIn start switching over to the shiny new toy!

But then the applications start to get big... a little too big for their developers to remember things like "What does my createUser function actually expect as its parameters? And what does it return? What all is available from the database?".

Organizing functionality becomes tedious as the concept of Object Oriented programming doesn't exist in JavaScript and every time you hit deploy you have a little voice in the back of your head that wonders if you're sure everything was set up correctly...

Enter, TypeScript

This exact scenario is what lead to the development of what we know today as TypeScript.

TypeScript brought with it a whole new world of tooling and type-safety that was previously impossible. You could organize your code into classes, provide interfaces for those classes, and set up types for various pieces of your code.

Editor tooling also evolved in a way that made it super easy to develop efficiently and detect bugs before even compiling your code!

This all sounds great and was a huge step in the right direction, but it shed light on another problem.

The Problem

While TypeScript made development way smoother, safer, and less error-prone, developers began to realize that there was some disconnect in their applications even with these types.

Here's why:

A typical application nowadays is organized generally into three main layers:

Client Layer: The website you interact with
API Layer: The layer that allows your client to indirectly interact with the database
Database Layer: The layer where your data is kept

Let's imagine we have an application following this structure and in our database we have a table called users.

Your front-end code (the client layer) and your back-end code (the api layer) each have their own typings that describe what a User from your database schema (the database layer) should look like:

type User = {
  id: number;
  fullname: string;
  email: string;
}

If everything was set up correctly, we can assume our imaginary application is working great! Your front-end might be able to fetch an array of users from the API. Both of those ends are aware of what a user is and how to handle it within its own layer and all is well.

... But then things change. A nit-picky database admin decides the fullname column should be split into two: firstName and lastName. A schema update is prepared and it's up to you as a developer to make absolutely sure the code and types are updated to reflect the new schema changes.

type User = {
  id: number;
-  fullname: string;
+  firstName: string;
+  lastName: string;
  email: string;
}

What happens, however, if you forget to update the front-end code? Your editor and the TypeScript compiler won't throw any errors because, as far as they're concerned, in the front-end a User still only has the fullname column!

We can imagine our layers currently look like this:

Each individual layer has its own definition of the object's shape, or a type. But they are unaware of their counterpart's version of that type because they live in their own box.

Requests made between the individual layers are working fine, but the shape of the data being passed around can't be known for sure as it crosses borders.

This issue is what can, and tends to, arise as an application grows without implementing end-to-end type safety.

Fixing the type in your front-end code would suddenly reveal a bunch of squiggly red lines under every instance of user.fullname that was accidentally left behind, but you would never have known unless the type was fixed or an error popped up after thorough testing (or a deployment 😬)!

In a less-severe scenario, we can imagine all of the types were properly updated throughout the stack and everything works fine. While the end-result is functional, the developer experience is not great at all because every change to a type or the database schema would require the developer to have to make the same change in a bunch of different locations.

End-To-End Type Safety

With end-to-end type safety, the goal is to have a single source of truth for your types across all layers of your application. Ideally this would occur in an automated fashion as your database schema changes.

If this is achieved, the walls between each layer are essentially broken down and allow the data to flow to and from each layer in a much more simple way that makes sense to the developer who has to work with it.

As data passes through each layer of the application, crossing borders via requests, we can be sure that in each area of the stack we are expecting the same object.

The benefits of this implementation include:

Great DX
Less testing, because TypeScript handles a lot of what we would normally test for
Easier debugging because of the tooling and linting TypeScript comes with
Ease-of-mind when making changes because we can allow ourselves to lean on the TypeScript Compiler
A lot of your code ends up becoming self-documented across your stack

There are, of course, many different ways to achieve end-to-end type safety, and those implementations can vary depending on your tech stack.

Putting It Into Practice

As a developer myself, I understand that the best way for a developer to grasp a concept like this is to jump in and get your hands dirty, so let's take a look at one possible implementation of end-to-end type safety.

We'll set up a Monorepo with Nx that has a NestJS API and a React client. The API will consume a SQLite database.

Our goal with the application will be to have fully automated type safety across all three layers. Making changes to our database should automatically update the type definitions in the API and Client layers.

Generate an Nx Workspace

We'll start up by setting up the Nx Workspace. Navigate to a directory where you'd like to generate your project and run the following command:

npx create-nx-workspace bookstore

This should take you through a series of prompts asking you how to initialize your monorepo. Go ahead and pick nest to start off and name the nest application api. I chose no for the Nx Cloud option.

If you pop open the workspace that was generated, inside of the /apps/api folder you should find a boilerplate NestJS application!

cd bookstore
code . # if you're using VSCode

This was conveniently set up for you by Nx and is ready to run!

We're going to also need our React front-end, so lets download Nx's React project generator and generate a project in our monorepo.

npm i -D @nrwl/react
nx g @nrwl/react:app

These are the options I went with for the react app:

Note: A client-e2e folder was also generated. This is where any e2e tests for your react application will live. We'll ignore that folder in this tutorial.

And viola! We have a monorepo set up with a NestJS API and React application all ready to serve.

If you'd like to serve the projects, you can use:

nx serve client # The react app
nx serve api    # The nest api
nx run-many --parallel --target=serve --projects=client,api # Both

If you are unfamiliar with Nx and want to learn more about what it can do, check out the docs here.

Initialize Prisma

The next thing we'll want to set up is our database, and we're going to do that through Prisma.

Prisma has a rich set up features that go beyond just being a fantastic ORM. Through it we can define the shape of our database in a schema file, apply our schema to the actual database, and manage deployments and our migration history.

Along with this, Prisma generates an ORM that is derived from the schema we define and is fully type safe. This allows us to already tick a few things off our list of type-related concerns!

To use Prisma we'll first need to install it as a development dependency and initialize Prisma in our project:

npm i -D prisma
npx prisma init

This will generate a /prisma folder at the root of your project with a file inside named schema.prisma.

schema.prisma is what we'll call our source of truth. We'll see more about why later on, but for now let's move on to setting up an actual database for Prisma to interact with.

Set Up SQLite

To keep things nice and simple, we're going to use SQLite as our database.

Add the following blocks to your schema.prisma file:

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url = "file:./dev.db"
}

This tells Prisma we are using SQLite and it should generate the db file into the same directory as the schema file.

It also lets Prisma know we want to generate the Prisma Client.

For more information about Prisma's PSL (Prisma Schema Language), check out their docs.

Add A Model

Now that we've got a database set up and Prisma configured, let's model out our data. We'll keep things clean and just add a Book model to the schema.Prisma file.

model Book {
  id         Int    @id @default(autoincrement())
  title      String
  authorName String
  pages      Int
}

Remember, this schema is the source of truth that not only describes the database schema, but will generate types for us to use in our code via the Prisma Client!

To apply the new model (or table) to our SQLite database, we can run Prisma's migrate tool.

prisma migrate dev --name init

This command generates a migration file in /prisma/migrations, applies that migration to our database, and finishes by generating our Prisma client.

At this point, we have successfully set up control of our database schema, but those walls are still up between each layer.

Set Up An API Endpoint

Okay, so we've got a database set up, our API and Client generated, and the Prisma client automatically modeled around our database. Let's put these to use.

Inside of your /apps/api/src folder, create a new file called prisma.service.ts. This file will initialize and handle the Prisma Client that was generated when we ran our migration.

// prisma.service.ts

import { Injectable, OnModuleInit, OnModuleDestroy } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';

@Injectable()
export class PrismaService extends PrismaClient
  implements OnModuleInit, OnModuleDestroy {
  async onModuleInit() {
    await this.$connect();
  }
  async onModuleDestroy() {
    await this.$disconnect();
  }
}

Here we are wrapping Prisma in a service so that it can be provided via NestJS's dependency injection system

Now, over in your app.module.ts we need to register the new PrismaService as a provider for that module.

First, go ahead and get rid of the existing app.service.ts and app.service.spec.ts files and remove that service's references in the app module file. We won't be needing those.

Once those are cleaned out, replace them with references to the PrismaService we created.

Your app.module.ts file should look like this:

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { PrismaService } from './prisma.service'

@Module({
  imports: [],
  controllers: [AppController],
  providers: [PrismaService],
})
export class AppModule {}

Now our service is registered in NestJS's DI (Dependency Injection) system, so we should be able to reference the PrismaService in our controller. Open up app.controller.ts and update it to match the code below:

import { Controller, Get } from '@nestjs/common';
import { PrismaService } from './prisma.service'

@Controller()
export class AppController {
  constructor(private readonly prisma: PrismaService) {}

  @Get()
  getData() {
    return {}
  }
}

This controller is where we can set up our API routes. The @Get decorator on getData lets NestJS know that it can be accessed at the base route: /.

We want this endpoint to return all of the books in our database.

In the return of getData, if we begin to type out a query with Prisma, you will see we get some nice autocompleting features.

Once the query for all of the books is written, if you hover over the function definition you should notice the return type of that function is PrismaPromise<Book[]>.

That's super convenient! ...but where did the Book type come from?? That was Prisma, our source of truth!

We have now broken down the wall between our database schema's shape and our API types by having a single source defining each of those.

Our types in the API are automatically updated whenever the database changes and the prisma client gets re-generated! If you play around with the query a bit and narrow down the selected fields, you should see that the return type of the route function dynamically changes based on the fields you select.

That's pretty slick, and checks off two layers of the three layers we need to worry about!

Before moving on to that third layer though, let's add some data to the database via Prisma Studio so we can query it and make sure everything is working nicely.

prisma studio

This command should open up the studio to a list of models. If you click into the Book model you should see a table view of our Book table. Go ahead and add a few records to the database.

Finally, serve up the api via Nx and head over to http://localhost:3333/api to check out your data.

Awesome! We're getting data and ready to set up our front-end to safely consume that data.

Build The Front-End

In order to interact with our api, we'll first need to enable cors on the server. In /apps/api/src/main.ts, we can use our NestJS app's enableCors method to accomplish this.

// main.ts
async function bootstrap() {
  ...
  const app = await NestFactory.create(AppModule);
  app.enableCors();
  ...
}

Now we should be okay to make requests from our client to our api. In /app/client/src/app/app.tsx, we'll start off by fetching our list of books from the api.

Add this effect and state variable to the top of the App component function.

const [books, setBooks] = useState([])

useEffect(() => {
  fetch('http://localhost:3333/api')
    .then( result => result.json())
    .then( setBooks )
}, [])

And to display those books, we'll replace the return of that function with:

return (
  <>
    {
      books.map( (book: any) => (
        <div key={book.id} style={{ border: '1px solid black', padding: '2rem'}}>
          <p>{book.id}</p>
          <p>{book.title}</p>
          <p>{book.authorName}</p>
        </div>
      ))
    }
  </>
);

If you serve up the API and Client and navigate to http://localhost:4200/, you should see our books beautifully displayed 🎨 (or not so beautifully...)

Okay, before you TypeScript junkies start getting queazy seeing that any type, let me explain.

Currently, even though our Database knows what a Book looks like and our API knows what it looks like, our front-end has no clue! The TypeScript compiler complains about that when we try to access properties on the mapped books.

Fortunately, we're implementing an end-to-end type safe system and Prisma gives us access to those types.

At the top of this file, let's import the Book type Prisma generated for us (yes, the same book type we're using in the API layer!).

import { Book } from '@prisma/client';

And we'll tell our state variable that it should hold an array of books.

const [books, setBooks] = useState<Book[]>([])

If you remove the any type now from the mapped books, you should see that the editor stopped complaining!

Also, if you go to modify a key being accessed on the book variable, you should see you get a nice set of auto-complete options that show the fields available to a Book.

That's pretty awesome if you ask me! We now have a single source of truth for:

Our database schema
Our back-end types
Our front-end types

All the walls between layers have been broken down and our types and data flow nicely and automatically across our entire stack!

Congratulations, you have implemented an end-to-end type safe full-stack application!

Now We Break It

Alright, enough celebrating! What fun is building a working project if you don't get to break it in the end?

I've decided I don't really care how many pages a book has. That data is taking up precious (and expensive) space in my database server, so let's get rid of it.

Pop open that schema.prisma file we worked in before and remove the pages field from the model.

model Book {
  id         Int    @id @default(autoincrement())
  title      String
  authorName String
-  pages      Int
}

Since our schema definition changed, run a new migration to apply that to our database and generate the new Prisma Client.

prisma migrate dev --name removed-field

You will get some prompts letting you know you have non-null values in the field you are removing.

That's pretty awesome Prisma thinks to warn you about that!
Go ahead and allow it, we aren't concerned about data loss here 💣

Now that our schema is migrated and the new client generated, let's find out what we broke!

Run both the API and the Client:

nx run-many --parallel --target=serve --projects=client,api

Aha! We broke it! You should see an error in your console letting you know what the problem is. Also in your code you'll see those red squiggly lines I mentioned earlier.

Think about what just happened. Our Database changed and because we have implemented end-to-end type safety our front-end code was smart enough to tell us it needs to be updated because of that! All without us having to change anything in the code!

Our back-end code would have done the same if we were actually accessing the pages field directly anywhere.

That is the power of TypeScript and end-to-end type safety. Because of this, we would have been able to easily catch any problems using the TypeScript compiler.

Okay, I know the developer inside you is dying to fix the bug, so go ahead and remove that <p> tag with the erroneous key.

Wrapping Up

I hope after following through that example you're as excited as I am about how powerful TypeScript is when combined with tools like Prisma and Nx that allow you to generate and share types across the entire stack of your application.

Of course, as mentioned near the beginning of this article, there is no one-size-fits-all solution and this example was one specific case. Maybe you need partial types, are using GraphQL, or have some other requirement. Implementing a end-to-end type safe experience is possible with the proper tools and configuration.

Thanks so much for following along and I hope you found this useful

Adding Custom Font Classes to TailwindCSS

Sabin Adams — Tue, 18 Jan 2022 05:29:12 +0000

In this article we'll be taking a look at how to use Custom Fonts with TailwindCSS and make those available as Tailwind classes.

TailwindCSS is one of the most useful CSS frameworks to date and has tons of amazing features that make building beautiful UIs quick and simple.

A lot of its features come out-of-the-box and it's up to you to combine those building blocks into the UI you envision.

While that alone is awesome, TailwindCSS takes things a step further and allows you to configure custom options by extending the themes available in case you have specific needs that it just doesn't support.

The Goal

To learn how to use custom fonts, we're going to:

Get a basic React app started
Set up TailwindCSS
Add our custom font and configure it in TailwindCSS's config
Put the font to use!

I'll approach this from the very basics all the way up, so no worries if you don't know React or Tailwind yet!

In order to follow along you'll want to make sure you have NodeJS installed.

Setting Up React using `create-react-app`

The first thing we'll want to do is get a project going in React. We're going to use a tool called create-react-app to scaffold the project out for us.

Go ahead and use your terminal to navigate to a folder you'd like to generate your project in. Then run the following command to create a React application (name it whatever you want):

npx create-react-app react-tailwind-project

This should create a folder for your project, configure some things for you, and then give you instructions on how to manage your new application:

For now, we'll just navigate into the project and start our React application:

cd react-tailwind-project && npm start

This will start up your dev server at http://localhost:3000 and should look something like this.

Now we've got our starter, let's move on to setting up Tailwind!

You can stop your dev server by hitting CTRL + C in your terminal window

Setting Up Tailwind

Before we start initializing and configuring Tailwind in our project, we'll need to install a few dependencies it will need.

npm install -D tailwindcss postcss autoprefixer

We should have all the packages now we'll need to run TailwindCSS in our project. Next we'll initialize TailwindCSS.

npx tailwindcss init -p

This should generate a two files in your project:

postcss.config.js (we won't touch this)
tailwind.config.js

Go ahead and pop open that tailwind.config.js file. We need to tell Tailwind which files to care about in our project.

In the content array, add the following glob pattern to match any of our files that will be using Tailwind's classes and tools:

module.exports = {
  content: [
    './src/**/*.{js,jsx,ts,tsx}',
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Tailwind uses that to know which files to scan when generating the classes it needs during build time.

The last thing we'll need to get Tailwind set up and usable in our project is to import Tailwind's directives into our root index.css file at /src/index.css. Add these imports to the top of that file.

@tailwind base;
@tailwind components;
@tailwind utilities;

Let's make sure this is all working. In /src/App.js, we'll add a Tailwind class to some of the text. How about we change the "Edit" instructions to a yellow color.

<p className="text-yellow-500">
  Edit <code>src/App.js</code> and save to reload.
</p>

If everything was set up properly you should see the text color change!

Adding Our Custom Font and Class

Now comes the part you've all been waiting for!

In Tailwind, we have a set of classes that allow us to change our font family, such as font-sans, font-serif, and font-mono. But what if we want to use a font that Tailwind doesn't have built in?

Fortunately, TailwindCSS allows us to build our own custom extensions of the theme to provide custom font families along with classes for those families.

The first thing we'll need to do is pick a font we like and import it into our index.css file.

I'll be using Google Fonts' Nova Flat, but feel free to pick your own!

In index.css after our Tailwind directive imports, import the font you like:

@tailwind base;
@tailwind components;
@tailwind utilities;

@import url('https://fonts.googleapis.com/css?family=Nova+Flat');

At this point, the font is usable in our project, but I'm lazy and want Tailwind to build up a class for me automatically so I can use that font 🤣

To configure this, head back over to tailwind.config.js. Under the theme key, we can use the fontFamily key to add a custom font family to Tailwind.

module.exports = {
  content: [
    './src/**/*.{js,jsx,ts,tsx}',
  ],
  theme: {
    fontFamily: {
      'nova-flat': '"Nova Flat"'
    },
    extend: {},
  },
  plugins: [],
}

If your font name has spaces, be sure to surround it in Quotes. Tailwind doesn't like spaces

If you want to add multiple families to nova-flat, you can add them either as a comma-separated list (e.g. '"Nova Flat", arial, mono') or turn that value into an array *(e.g. ['"Nova Flat"', 'arial', 'mono'])

After saving that, we will now have a new class available via Tailwind named font-<our name>. In my case it will be font-nova-flat.

Let's put it to use!

In /src/App.js, we'll change the font of the "Learn React" label to our new font...

<a
  className="App-link font-nova-flat"
  href="https://reactjs.org"
  target="_blank"
  rel="noopener noreferrer"
>
  Learn React
</a>

If everything was set up properly, your cool new font should show up!

Pretty awesome how Tailwind created a usable class for us that we can now use anywhere!

Wrapping Up

This example we looked at is just the beginning of the many options we have when configuring TailwindCSS to fit our picky, artsy needs 🎨

I definitely encourage you to check out all the things TailwindCSS has to offer!

Thanks so much for reading, hope you found this helpful!

Til' next time, and Happy Coding!

P.S. 🧠🔎

There is a shortcut to what we learned here.

Without configuring the theme extension in tailwind.config.js, we could have used what Tailwind calls an arbitrary value, which essentially is a class that we can pass a value.

In our case, our arbitrary value would have looked like font-['Nova_Flat'].

DEV Community: Sabin Adams

What is an API? A Beginner's Guide

Understanding APIs

The API's role

Benefits of using APIs

Conclusion

The Most Valuable Trait of a Developer: Curiosity

Why curiosity is so important

How to stay curious

Pace yourself

Be open to trying new things

Set goals for yourself

The result

Add Sign In and Sign Up to Your React App With Clerk

The starting point

Navigating the project

Add Clerk

Create an account

Store the application secrets

Set up the Clerk provider

Add the authentication middleware

Add The Sign-In Page

Add user details to the screen

Test it out

Recap

Next steps

Common React Interview Question: Tic Tac Toe

Why is Tic-Tac-Toe used for technical interviews?

What a solution might look like

The starting point

Build the game board

Build the square component

Build the game state using the Context API

Use the GameState context

Render the game grid

Give players the ability to select a square

Check for a winner

Display a winner and reset the board

Closing words

To NoSQL or Not to NoSQL

What is NoSQL?

Primary features

Flexible data structures

Quick iterations

Potentially faster queries

Horizontally scalable

How Is It Different From SQL?

Rigid data structure

Vertically scalable

Considerations

Structure of data

Evolution of data

Your team's capabilities

Cost

Key Takeways

Stop Hating On Array.reduce()

What does it do?

What's the problem?

My reasoning

Exhibit A: It shouldn't be named reduce

Exhibit B: People are lazy when naming parameters

What do you think?

Bonus question:

Managing a Remix Site's Content With Sanity.io

Introduction

Prerequisites

Tools you will use

Set up a Sanity.io project

Define a Book document type

Apply Book to your schema

Build the Remix application

Initialize a Remix application

Set up TailwindCSS

Build a Book component

Get your data from Sanity.io

Set up GraphQL Codegen

Query Sanity's GraphQL API

Render your Book data

Deploy your applications

Push both projects to GitHub

Define a `Book` document type

Apply `Book` to your schema

Build a `Book` component

Setting Up React using `create-react-app`