Forem: Code Mochi

Migrating NextAuth V3 to V4 with Prisma

Code Mochi — Tue, 08 Mar 2022 16:37:14 +0000

NextAuth (github, website) is an open source library for managing your user authentication and authorization flow. It has a number of plugins including Google Auth, Auth0, Github and user/password login where the data is stored in a database. Using it with Prisma is a breeze because there is a Prisma adapter. After making the necessary changes to your Prisma schema file and performing a migration, you will be ready to add user login functionality to the frontend of your website.

If you are interested in how to set up a new project, NextAuth has a guide here that follows all the steps that you need.

The purpose of this article is to walk through a particular problem I had when I updated Source Compare, with the latest versions of NextAuth (v3->v4) and Prisma(v2->v3). Source Compare is a collaborative universal image version control app that I created for managing web assets. The problem was that the Prisma migration was attempting to drop the entire user's database because it was changing from users to User. With this guide that I highlight below, I was able to safely migrate everything over to User without losing any records.

Migrate to Prisma v3

The upgrade guide for Prisma v3 was very helpful at identifying what needed to be changed. First I installed the latest packages:

npm install prisma@3 @prisma/client@3

When looking through the upgrade guide, I primarily needed to be concerned about the referential actions for my project. In older versions of Prisma v2, when you'd delete something you'd get an error if there were child records associated with the item that you were trying to delete. I actually had a fairly nested set of models for Source Compare, projects -> items -> commits -> images and these limitations meant that in earlier versions of Prisma v2, when deleting a project, I'd first delete all the images, then commits, all the way up the hierarchy until I finally got to projects. This was a little bit of an inconvenience but it had the advantage that the potential issues I might have run into had I relied on the cascading behavior from later versions of Prisma v2 didn't apply. This meant I was able to update to Prisma v3 without needing to rework my code, but if you find that you need to make changes you will find that they center around defining what the referential actions should be for each of your models (SetNull vs OnDelete). Now that referential actions exist though, I'll be sure to later go back and update these messy calls I had to do with simple cascading delete functionality that Prisma now has.

Migrate NextAuth v4

Now that Prisma has been straightened out, we need to move onto NextAuth v4. This proved to be significantly more challenging, so before going into the details, for those who are nervous about this upgrade, there is a legacy adapter that you can always use which will maintain the database schema that you already have. For myself, I wanted to make sure I was using the latest and greatest because it has been noted that the legacy adapter will not receive future updates. Unfortunately, the updated Prisma adapter has a number of fields and tables that have been changed so we will need to perform several Prisma migrations in order to make sure everything is updated properly.

What to do if you run into problems

Before we actually change anything, first a note about the importance of backing up your production database before doing anything. To help put you in the mindset of this process not being perfectly seamless initially, I'm placing this problems section first because it's super important that you read it before you make any potentially destructive changes to your database.

You should always test this set of steps on a clone of your production database locally. This means you should run a sql dump of your database, copy it locally, restore it and update your prisma connection strings to your local instance. Do not test in production without making backups. Also, the changes you need to make should be roughly the same as what I highlight below but due to other differences in your schema, you can't just copy and paste the models that are listed below. Instead, you will need to integrate them with your models.

For the first pass of this, my preference would be to actually start with a clean database where the migrations have been applied up to the two that we discuss here. Then create a user and do some sample actions with that user so you create records for the different models in your schema. Next, you can attempt to do the two migrations below and see if it works smoothly. If it doesn't, stash your changes, and then reset your git commit back to the state before you applied the migrations. You can then repeat creating the user and records again, tweak the migration and try it again.

It took me a number of tries to allow the migrations to cleanly apply. I knew I was in trouble when the Prisma migration was asking me if I wanted to drop tables or fields I wasn't comfortable with. I'm forgetting at the moment how it actually would prompt you about migrations where the names changed- if you are finding that it is erroneously stating that it will drop the tables or fields even though you are actually renaming them based on the migration commands then you'll know you can ignore those.

Once you can cleanly apply the two migrations below to your test data, you can then restore your production database locally and try the same thing. If that works as well, you can then attempt to migrate the production database. Since you have a backup from running the database dump, you can always restore that if you run into problems.

Back to NextAuth v4 migration

Now that we've done all the preparation needed to have a proper backup we can attempt the NextAuth v4 migration. These updates are nice because they standardize the database names used so that they have the same capitalization and pluralization scheme that Prisma uses. The problem is that when you make the changes to the Prisma schema, you will get warnings that rather than changing the names, Prisma will actually drop and recreate the tables and fields. Yikes!

A way around destructively dropping your tables and fields is to create your own custom migration. You can do this by running the following command:

prisma migrate dev --create-only

This will allow you to create a migration that's empty. You can make the migration something like "changed user table names". After creating the migration, I filled in the sql file with the following:

ALTER TABLE "users" RENAME TO "User";

ALTER TABLE "accounts" RENAME TO "Account";

ALTER TABLE "sessions" RENAME TO "Session";

ALTER TABLE "Account" RENAME CONSTRAINT "accounts_pkey" TO "Account_pkey";

ALTER TABLE "Session" RENAME CONSTRAINT "sessions_pkey" TO "Session_pkey";

ALTER TABLE "User" RENAME CONSTRAINT "users_pkey" TO "User_pkey";

ALTER TABLE "Account" RENAME COLUMN "user_id" TO "userId";
ALTER TABLE "Account" RENAME COLUMN "provider_id" TO "provider";
ALTER TABLE "Account" RENAME COLUMN "provider_type" TO "type";
ALTER TABLE "Account" RENAME COLUMN "access_token_expires" TO "expiresAt";
ALTER TABLE "Account" RENAME COLUMN "provider_account_id" TO "providerAccountId";

ALTER TABLE "Session" RENAME COLUMN "user_id" TO "userId";
ALTER TABLE "Session" RENAME COLUMN "session_token" TO "sessionToken";

ALTER TABLE "User" RENAME COLUMN "email_verified" TO "emailVerified";

Then after saving that migration file, I went ahead and made the changes to the prisma schema that they outline here:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider        = "prisma-client-js"
}

model Account {
  id                 String  @id @default(cuid())
  userId             String
  type               String
  provider           String
  providerAccountId  String
  refresh_token      String?  @db.Text
  access_token       String?  @db.Text
  expires_at         Int?
  token_type         String?
  scope              String?
  id_token           String?  @db.Text
  session_state      String?

  user User @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@unique([provider, providerAccountId])
}

model Session {
  id           String   @id @default(cuid())
  sessionToken String   @unique
  userId       String
  expires      DateTime
  user         User     @relation(fields: [userId], references: [id], onDelete: Cascade)
}

model User {
  id            String    @id @default(cuid())
  name          String?
  email         String?   @unique
  emailVerified DateTime?
  image         String?
  accounts      Account[]
  sessions      Session[]
}

model VerificationToken {
  identifier String
  token      String   @unique
  expires    DateTime

  @@unique([identifier, token])
}

These schema details are in addition to all of the other schema details that you've added, so in my case I have other parameters in my user model and have other models such as Project that aren't shown here for simplicity.

We've now created one migration that we haven't run and made additional changes up and above those sql changes by editing the Prisma schema file. To incorporate those new Prisma schema changes, we need to create a second migration to incorporate those changes in properly. Run:

prisma migrate dev --create-only

This should apply all those changes into a new migration. Mine created the following sql file:

DROP INDEX "accounts.compound_id_unique";

DROP INDEX "providerAccountId";

DROP INDEX "providerId";

DROP INDEX "userId";

DROP INDEX "sessions.access_token_unique";

ALTER TABLE "Account" DROP COLUMN "compound_id",
DROP COLUMN "created_at",
DROP COLUMN "expiresAt",
DROP COLUMN "updated_at",
ADD COLUMN     "expires_at" INTEGER,
ADD COLUMN     "id_token" TEXT,
ADD COLUMN     "oauth_token" TEXT,
ADD COLUMN     "oauth_token_secret" TEXT,
ADD COLUMN     "scope" TEXT,
ADD COLUMN     "session_state" TEXT,
ADD COLUMN     "token_type" TEXT;

ALTER TABLE "Session" DROP COLUMN "access_token",
DROP COLUMN "created_at",
DROP COLUMN "updated_at";

DROP TABLE "verification_requests";

CREATE TABLE "VerificationToken" (
    "identifier" TEXT NOT NULL,
    "token" TEXT NOT NULL,
    "expires" TIMESTAMP(3) NOT NULL
);

CREATE UNIQUE INDEX "VerificationToken_token_key" ON "VerificationToken"("token");

CREATE UNIQUE INDEX "VerificationToken_identifier_token_key" ON "VerificationToken"("identifier", "token");

CREATE UNIQUE INDEX "Account_provider_providerAccountId_key" ON "Account"("provider", "providerAccountId");

ALTER TABLE "Account" ADD CONSTRAINT "Account_userId_fkey" FOREIGN KEY ("userId") REFERENCES "User"("id") ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE "Session" ADD CONSTRAINT "Session_userId_fkey" FOREIGN KEY ("userId") REFERENCES "User"("id") ON DELETE CASCADE ON UPDATE CASCADE;

ALTER INDEX "sessions.session_token_unique" RENAME TO "Session_sessionToken_key";

ALTER INDEX "users.email_unique" RENAME TO "User_email_key";

Now you can run prisma migrate dev and you should see that it cleanly applies all the changes necessary to your database.

That's it! If you find use cases where this guide isn't sufficient, let me know and I'll be happy to add to this guide but it worked well for me.

Dockerizing Next.js with Prisma for Production Environments

Code Mochi — Tue, 08 Mar 2022 16:19:44 +0000

Here is the sample repository for this blog post

Next.js is a phenomenal framework for building SEO friendly, performant webpages with React. For static pages, Next.js is enough to create your web page, but when you need to store persistent state such as when you have users, or perhaps blog pages that are dynamically being created once the web page has been deployed, you need a database to keep track of the various changes in state that the web page will undergo. Prisma is a library that will create a connector with your database and allow you to easily perform CRUD (create, read, update and delete) operations whenever your backend needs to.

The combination of Next.js and Prisma is a powerful one, and I’ve created blog posts and courses if you are interested in how to create a complete web application from scratch, but for this post we will discuss how to deploy Prisma and Next.js in a production docker container.

If you haven’t used Docker before, it is a containerization technology that allows you to reproducibly build and run your code in a way that will consistently run across all platforms, both on your computer and up in the cloud. The primary configuration that we need to do with Docker is to create a Dockerfile that essentially can be thought of as the command line steps that you’d type into your terminal in order to build your Next.js and Prisma app.

We will build up our production image in multiple stages which will allow us to take the approach of building the code in one image that is all loaded up with the development npm dependencies and then copy the built code into a clean production image to dramatically save on space.

The four main commands used in a Dockerfile are the following:

FROM: this is your starting spot for building your docker image. The first time that you use this in a Dockerfile, you will be pulling from an already existing image on the internet. When you have multiple stages, it is good practice to label the stage using the AS followed by the name. Then, later in the Dockerfile you can use FROM to import the current state of that layer, which we’ll talk about in a bit.

RUN: used for running any commands just like you would from the command line. Keep in mind that the shell you are in is dictated by the base image that you are loading. For example, alpine images are widely used due to their small size but they also use the sh shell rather than bash, so if you are using alpine make sure that your RUN commands are sh compatible. In this example below, we will use the slim family of docker images as our base which uses bash as its shell. This makes installing Prisma dependencies much easier.

WORKDIR: This will set the current working directory to whatever path is specified.

COPY: Takes two or more parameters, the first up through the second to last parameters are paths to the desired file(s) or folder(s) on the host. The last parameter is the destination path for where those files should be copied into.

There are two other commands you sometimes see in Dockerfiles, but since they can also be configured with docker-compose, kubernetes or whatever your hosting provider is, they are less important:

EXPOSE: allows you to explicitly open certain ports in the container. Can be overridden when running the container.

CMD: indicates the command that Docker runs when the container starts up. Can also overridden when run.

Armed with those basics, let’s take a look at the start of our Dockerfile. The goal with creating this base docker image is to have everything that both our development and production images without anything more. There will be 4 layers that we create to our Dockerfile:

base layer has system dependencies, package.json, yarn.lock, and .env.local file.
build layer starts with base and installs all dependencies to build .next directory that has all of the site’s code ready for use.
prod-build layer starts with base and installs production dependencies only.
prod layer starts with base and copies production dependencies from prod-build, .next folder from build
Create the base layer

FROM node:lts-buster-slim AS base
RUN apt-get update && apt-get install libssl-dev ca-certificates -y
WORKDIR /app

COPY package.json yarn.lock ./

This starts with a slim version of the long term stable version of node and labels it base. Going with the slim variety allows the base image to only be 174MB while the full-blown image is 332MB. Alpine images are even smaller- around 40MB but since the shell is sh rather than bash, I ran into problems getting everything needed for Next.js and Prisma to compile properly. (Found a way to get alpine to work? Let me know in the comments!)

In any case, we start with Buster Debian base image that has node lts preinstalled, and then we run apt-get update to ensure that all of our package lists are up to date. We then install libssl-dev and ca-certificates which are dependencies of Prisma and then set the working directory as /app.

Create the build layer

By then creating a new FROM designation, we are saving off those first set of steps under the layer base, so that any steps created from here on out get saved to the build layer, rather than the base layer.

From the top:

FROM node:lts-buster-slim AS base
RUN apt-get update && apt-get install libssl-dev ca-certificates -y
WORKDIR /app

COPY package.json yarn.lock ./

FROM base as build
RUN export NODE_ENV=production
RUN yarn

COPY . .
RUN yarn run prisma:generate
RUN yarn build

Running yarn does an install of all the packages that we have in our package.json which we copied in during the base step. From there, we can copy in our entire next.js app to the /app folder with the command COPY . .. Once we have our dependencies, we can run the prisma:generate command which we define in the package.json as prisma generate. This generates the client library in our node_modules folder that’s specific to the Prisma schema that we’ve already defined in prisma/schema.prisma.

Create the prod-build layer

Now that we have our site’s code built, we should turn to installing the production dependencies so we can eliminate all the packages that are only for development. Picking up with the base image, we install the production npm packages, and then copy in the Prisma folder so that we can generate the Prisma library within the node_modules folder. To ensure that we keep this production node modules folder intact, we copy it off to prod_node_modules.

FROM base as prod-build

RUN yarn install --production
COPY prisma prisma
RUN yarn run prisma:generate
RUN cp -R node_modules prod_node_modules

Create the production layer

Now that we’ve created all of our build layers, we are ready to assemble the production layer. We start by coping prod_node_modules over to the app's node_modules, next we copy the .next and public folders which are needed for any Next.js apps. Finally, we copy over the prisma folder, which is needed for Prisma to run properly. Our npm start command is different from the development npm run dev command because it runs on port 80 rather than 3000 and it is also using the site built out of .next rather than hot-reloading the source files.

FROM base as prod

COPY --from=prod-build /app/prod_node_modules /app/node_modules
COPY --from=build  /app/.next /app/.next
COPY --from=build  /app/public /app/public
COPY --from=build  /app/prisma /app/prisma

EXPOSE 80
CMD ["yarn", "start"]

In all, by creating a layered approach we can save often save a 1GB or more off the image size which can really speed up the deployment to AWS Fargate, or whatever hosting platform that you choose to do.

Here’s the final full Dockerfile:

FROM node:lts-buster-slim AS base
RUN apt-get update && apt-get install libssl-dev ca-certificates -y
WORKDIR /app

COPY package.json yarn.lock ./

FROM base as build
RUN export NODE_ENV=production
RUN yarn

COPY . .
RUN yarn run prisma:generate
RUN yarn build

FROM base as prod-build

RUN yarn install --production
COPY prisma prisma
RUN yarn run prisma:generate
RUN cp -R node_modules prod_node_modules

FROM base as prod

COPY --from=prod-build /app/prod_node_modules /app/node_modules
COPY --from=build  /app/.next /app/.next
COPY --from=build  /app/public /app/public
COPY --from=build  /app/prisma /app/prisma

EXPOSE 80
CMD ["yarn", "start"]

Running Noted: a cryptocurrency tracker locally and in production

The sample project used for this repo is a simple cryptocurrency tracking application that allows you to add how much of each cryptocurrency you have and it will tell you the current worth based on the market prices. You should create a .env.local that looks like this:

DATABASE_URL=file:dev.db
#CMC_PRO_API_KEY=000-000-000-000-000

The CMC_PRO_API_KEY is optional but if set will pull the latest currency data for the top cryptocurrencies using CoinMarketCap. If you'd like to use it, sign up for a free account over at CoinMarketCap and replace the blank api key with your actual api key and remove the # from the start of the variable definition. If you choose not to use the api, the app will populate with some default coins and prices.

To run it locally, feel free to delete any prisma/dev.db file and prisma/migrations folder that you already have. Next run npm install. Ideally your version of node will match the lts version used in the docker images. You can use nvm to set the version and node --version to check that they are the same. Then you can runnpm run prisma:generate which will generate the library followed by npm run prisma:migrate to create a dev.db file.

From there, you have two options. First, you can run it locally without docker which will allow you to make changes and see them instantly change in your app. This works best for the development stage of things. To run this, run npm run dev.

To run it locally in the docker environment, first you need to build the image with docker-compose build. Next, you can run docker-compose up to actively run the image. There is a volume set up so that it will utilize the prisma/dev.db folder that you have mounted on your host. I'll discuss in a minute why this is not ideal, but in a pinch this can be used to run your webapp in a production environment because the dev.db file is being mounted on your host which will mean that it will persist when the containers crash or the machine or docker has been restarted.

The downsides to running the app with a local dev.db file is that there are no backups or redundancies. For a true production environment, the datasource should be migrated from sqlite to postgresql or mysql connectors with the url being changed to a database connection string. Here's an example of how you'd switch to postgresql.

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

DATABASE_URL="postgresql://your_user:your_password@localhost:5432/my-prisma-app?schema=public"

For the purposes of this tutorial we wanted to keep it with sqlite because the local development is just so much easier and it is essentially a drop-in replacement to switch over to a more production friendly environment.

Stay tuned for a future blog post where we go through all of the inner-workings of this app and show how Prisma can be used with Next.js to create a nimble fullstack web application!

Originally posted at Code Mochi.

Using Finite State Machines to Simplify Frontend User Flow

Code Mochi — Mon, 07 Jun 2021 22:20:25 +0000

Controlling the flow of events on a frontend can appear to be a simple task but it becomes significantly more challenging as there are more elements that need to be controlled in unison. In this post I'm going to discuss best practices for controlling many objects at once using a unified store of state. This technique is called finite state machines and it is frequently used with backend code because it can eliminate whole classes of errors by ensuring that the app never goes into combinations of states that are flat out prohibited from happening.

I found using a unified store of state immensely useful in developing the home page for an app that I just released called Source Compare which allows people version control images within their team to keep everyone on the same page.

If you check out the home page in the link above, you'll see that there is an interactive set of steps for how the app works that has 17 different elements which can show, hide or dim based on which step the person is hovering on. Combinatorially, this could result in about 50 possible states, but here I only ever wanted to show 6. Initially I tried the approach of having certain hover events set the state of other elements but this quickly turned to madness as the number of elements that I needed to control grew.

In this post, we will first discuss in more detail the actual problem that we are trying to solve, and then we will go into how to use the unified store of state. Let's start with a simple hover event. We'll be using React and Tailwind but I'll be ignoring the fact that Tailwind has built in hover support using the hover:opacity-50 type classes so that we can get in the practice of storing state in variables, not as a class setting.

With that in mind, a simple image with a hover event would look something like this:

export const OneIcon = () => {
  const [hoverState, setHoverState] = useState(false)

  return (
    <img
      src="path/to/image.jpg"
      onMouseEnter={() => setHoverState(true)}
      onMouseLeave={() => setHoverState(false)}
      className={`${hoverState ? 'opacity-100' : 'opacity-50'}`}
    />
  )
}

This image shows how when we hover over the image, its opacity increases. The component uses onMouseEnter and onMouseLeave to detect when the person is hovering over the image and we will set the hover state to true or false accordingly. Then, in the class we will set the desired opacity based on the hoverState variable. Now let's say we want to level up the complexity to this:

Here, we have 2 steps and 2 icons. When the mouse cursor is over neither step, both of the images' opacity are set to 50%. When we hover over step 1, the opacity of image 1 goes to 100% and image 2 remains at 50. Then when we move the mouse cursor to step 2, the opacities of the two images flip.

Let's create the react code for a 2 step, 2 image system:

// Bad- don't do it this way!
export const IconSet = () => {
  const [hoverState1, setHoverState1] = useState(false);
  const [hoverState2, setHoverState2] = useState(false);


  return (
    <span
        onMouseEnter={() => {
            setHoverState1(true)
            setHoverState2(false)
        }}
        onMouseLeave={() => {
            setHoverState1(false)
            setHoverState2(false)
        }}
    >
        1
    </span>
    <span
        onMouseEnter={() => {
            setHoverState1(false)
            setHoverState2(true)
        }}
        onMouseLeave={() => {
            setHoverState1(false)
            setHoverState2(false)
        }}
    >
        2
    </span>
    <img
      src="path/to/image1.jpg"
      className={`${hoverState1 ? 'opacity-100' : 'opacity-50'}`}
    />
    <img
      src="path/to/image2.jpg"
      className={`${hoverState2 ? 'opacity-100' : 'opacity-50'}`}
    />
  );
};

This will work, but it is less than ideal- we need to have individual setState calls for each <img> and every onMouse event has a series of setState calls that are brittle because if you ever wanted to change the behavior of something you'd need to change them in the corresponding handlers. This means that it would be all too easy to introduce bugs if you accidentally caused contention among the handlers by, say, setting a hover state to true on a mouse leave.

We can improve the code clarity and eliminate unexpected state combinations by creating a state that is shared amongst all the images and triggers. Let's define the 3 states right now to match what we had in Figure 2.

Mouse is neither hovered over step 1 or step 2.
Mouse is hovered over step 1.
Mouse is hovered over step 2.

For each finite state of the system, we will need to specify the local state for each of the images. Let's say that state 0 is if the opacity is 50% and state 1 is if the image opacity is 100%. Then we can create a string for each finite state which will be a bunch of 1s and 0s for each of the images.

Image 1 is in state 0, Image 2 is in state 0 => "00"
Image 1 is in state 1, Image 2 is in state 0 => "10"
Image 1 is in state 0, Image 2 is in state 1 => "01"

From here we can create an array possibleStates which has all the possible states will allow for this system. Note that although "11" is technically a situation that could occur, we flat out prohibit it from happening since it is not in the possibleStates array we define here:

const possibleStates = ['00', '10', '01']

By virtue of being in an array, we can easily tell for a given finite state what all of the individual image's behaviors should be. Starting with the possibleStates array as the bounds of possible states, we create a IconSet component which has the only useState hook we will use. Our default state will be '00' so we will set that as the default state.

Next for the images, we will use a OneIcon component which takes a src parameter which is simply the path to the image and hoverState which we take the current state, say '00' and use the charAt function call to pick out either the 0th or 1st position in that string and we convert it to an integer. We can use whatever kind of switching logic we want based on this hoverState number. Here it is the case that if its 1 we set the opacity to 100% and otherwise we set it to 50%, but you could imagine that we could use a multitude of numbers to signify a variety of states for that OneIcon component.

The OneStep component, uses the setMainState method to change the global state to either '10' or '01' based on the positional variable that we pass in to stateArrayPosition.

const possibleStates = ['00', '10', '01']

const OneIcon = ({ src, hoverState }) => (
  <img
    src={src}
    className={`${hoverState === 1 ? 'opacity-100' : 'opacity-50'}`}
  />
)

const OneStep = ({ setMainState, stateArrayPosition }) => (
  <span
    onMouseEnter={() => {
      setMainState(possibleStates[stateArrayPosition])
    }}
    onMouseLeave={() => {
      setMainState(possibleStates[0])
    }}
  >
    {`${stateArrayPosition}`}
  </span>
)

const IconSet = () => {
  const [mainState, setMainState] = useState(possibleStates[0])

  return (
    <div>
      <OneStep setMainState={setMainState} stateArrayPosition={1} />
      <OneStep setMainState={setMainState} stateArrayPosition={2} />
      <OneIcon
        src={'path/to/image1.png'}
        hoverState={parseInt(mainState.charAt(0))}
      />
      <OneIcon
        src={'path/to/image2.png'}
        hoverState={parseInt(mainState.charAt(1))}
      />
    </div>
  )
}

We can visualize this system by drawing circles for each of the finite states and we label them with the strings we have been using from the possibleStates array that represent what each of the elements are doing within a particular finite state.

Each of the transitions are represented by arrows and they get triggered whenever any of the onMouseEnter or onMouseLeave events gets triggered on the OneStep components.

The beauty of this whole setup, is that it is adaptable to a variety of changes we might want to make in the future:

Need to add a step 3? No problem, just add a 3rd state to all the strings in possibleStates and then copy and paste the OneStep and OneIcon components and you are good to go.
Need to allow an image to have more possible states than a 1 and 0? Just add the additional state handling to the OneIcon.
Need to add more possible states, like '11'? Just add it to the array and then have some function call where you call this new possible state like this: setMainState(possibleStates[3])
Need to change around the individual behaviors for a given finite state? All of that information is contained within the possibleStates array so just flip those numbers around to match the desired image state for a particular finite state.

No method is without its drawbacks, and probably the biggest thing to watch out for here is that having state arrays for some systems that have, say, 10 or 20 items in it could be a little daunting when you need to count and change individuals 1s and 0s in a large block of numbers. Here, some code documentation about what all the positions are for can go a long way to clarify your intent to future developers (and yourself!).

Without a doubt though, finite state machines make moderate tasks easy and challenging tasks possible, so this is definitely my go-to method for managing complex state on a web page.

There is more where that came from!
Click here to give us your email and we'll let you know when we publish new stuff. We respect your email privacy, we will never spam you and you can unsubscribe anytime.

Originally posted at Code Mochi.

Corona Examiner- open source virus tracking with Gatsby.js

Code Mochi — Fri, 12 Jun 2020 03:49:48 +0000

The spread of the Corona Virus has been rapid and absolutely devastating for countries that have been hard hit. Due to the virus’ exponential growth and how wholly unprepared many countries were to handle this crisis, we saw the number of cases particularly skyrocket in China, Italy, and the U.S. in the beginning of 2020. The sudden rise became so fast that at one point, the doubling times for new cases was as short as 2-6 days in late March in the U.S. alone according to NPR.

To help us better understand what was happening, I created a tool that easily allows for comparing the growth trends between countries called the Corona Examiner.

Benefits

Allows for tracking the case and death count between any set of countries.
Since the population counts vary drastically from country to country, you can also view these metrics on a per million people basis.
Support for log scales so that you can tell whether the rate is slowing down or speeding up. (Exponential growth produces a straight line while a curve downward indicates that we are getting under an R0 of 1.)

The data is pulled from Johns Hopkins University CSSE dataset which gets updated hourly and published to Github, so you can always be sure that you are viewing the most up to date information.

In the interest of transparency and allowing everyone to build their own and see how it ticks, I open-sourced the entire project on Github. Let’s go through some of the details about how it works.

Tech Specs of the App

Built using Gatsby.js and hosted on Github Pages. This turned out to be a really nice combination because Github provides free static hosting and Gatsby.js produces statically built pages built with React.js.
gh-pages to publish the statically built app onto a special branch in Github called gh-pages that is used to serve the app from.
Recharts for plotting. They provide gorgeous plots that will animate redrawing the lines as people switch from counts to count per million or check/uncheck different countries. As someone who has scratched their head with trying to understand d3, I'm very thankful that someone has taken the power of d3 and made it easier to use for simple cases of plotting like this.
React Simple Maps for the maps. This was another pleasant surprise because it was almost trivial to get a stock world map up on a react app with cool features like hovering to display tooltips.
Tailwinds CSS rather than Antd or Bootstrap for all of the styling on the app.

Data Processing

My data science chops were a little rusty but I sure had to dust them off for this project. The central problem was that we were getting data formatted a particular way. The data itself is stored on Github and by clicking on the view raw setting for both the cases and deaths dataset, you can get a URL to the actual csv that your app can fetch when you visit the Corona Examiner Website.

We use React Hooks to create a hook called useFetchTimeSeries which manages fetching the csvs, converting it into a JavaScript object and formatting it as timeseries dataset.

Here is the format for the confirmed cases object. You can see that we save off both the case counts for the cases-per-million (CPM) and the raw-case number (NORMAL). Then each of those datasets consists of an array of objects where each object represents a given day specified by its date and each country uses its ISO3 value, which is a unique standardized 3 letter code.

const allConfirmed = {
  CPM: [
    {
      date: '1/22/20',
      AFG: 0,
      ALB: 0,
      // many more countries here
      ZWE: 0,
    },
    {
      date: '1/23/20',
      AFG: 0,
      ALB: 0,
      // many more countries here
      ZWE: 0,
    },
    // many more dates here
  ],
  NORMAL: [
    {
      date: '1/22/20',
      AFG: 0,
      ALB: 0,
      // many more countries here
      ZWE: 0,
    },
    {
      date: '1/23/20',
      AFG: 0,
      ALB: 0,
      // many more countries here
      ZWE: 0,
    },
    // many more dates here
  ],
}

Standardization shall set you free

It turns out that using the ISO3 as a standardized code is critical, because the Map itself also has a set of country data and as I found out the country names didn't always agree. Sometimes things would be abbreviated, have different capitalization, or have formatting differences that would mean that if I clicked on the country South Korea on the map, it wouldn't know how to find that in a list of COVID cases where it was instead represented as Korea, South.

Instead of dealing with all of those headaches I could simply use the ISO3 figure which both the COVID and the Map data had in common and I was good to go.

Corner cases are the last set of gotchas

The last set of gotchas was how to handle cases with territories. The COVID dataset split China, US, Canada and Australia into a number of provinces but the map itself did not make that distinction. In those cases, I aggregated the population and case data on a whole country basis.

The exception to this was certain territories which were geographically distinct from the main country. Greenland is an example of this because before doing this project, I forgot that it was part of Denmark. In cases of a distinct area that you can hover over but is still part of another country, the count-per-million metrics are based on that territory without including the primary country.

How does it work?

Despite the complexity regarding all of the data-handling, the main functionality of the app is relatively straightforward. As you hover over different countries, you can see how their COVID numbers compare to the world-wide cases. A tooltip also appears which gets set by the tooltipContent state hook on the index page.

When you click on a country, it gets colored with a given color and
that country's timeseries data gets displayed on the plot with a matching color. We store the currently selected countries and their colors in a selectedCountries state hook on the index page. As you click on more countries, they get added to the plot and get colored accordingly.

To switch between confirmed cases and deaths, total cases and cases-per-million, or normal versus log, just switch it on the right dropdown.

Takeaways

I hope you enjoy this project as much as I had with making it. Feel free to hack on it by downloading the source code and share it with all of your friends, family and co-workers. And wash those hands!

Originally posted at Code Mochi.

How to add Auth0 to Nextjs- the Ultimate Guide

Code Mochi — Wed, 01 Apr 2020 14:10:37 +0000

In this video, we will show how you can add Auth0 to your Next.js application. This is something that used to be quite tricky but after the release of the api feature in Next.js which makes it super easy to add your own api-only endpoints to a Next.js application, the task of adding Auth0 became a lot more manageable. This became dead simple after Auth0 created a auth-nextjs package which we will use in this video to set up all of our api endpoints.

Github Starter Project

First, go ahead and clone our Next.js Auth0 Starter project on github. Make sure to checkout the start-here tag or you will end up with the finished project. I'm adding a -b development flag so that you will check out the tag and immediately create a development branch so that you won't be in a dreaded detached HEAD state. Feel free to name the branch whatever you'd like:

git checkout start-here -b development

Video of what we are doing:

Let’s first start by installing the @auth0/nextjs-auth0 package.

npm install @auth0/nextjs-auth0 --save

Next, we want to initialize auth0 on the server so that we can use it in all of our api methods. Make sure to define all of the variables in a .env file in the root of your project. You should be able to find the clientId, clientSecret, and domain from auth0 once you create a new single-page application project. Make sure to add the redirect Uri and the postLogoutRedirectUri urls into the respective fields within your auth0 app so that auth0 knows which urls that it should trust during the entire redirect process.

utils/auth.ts

import { initAuth0 } from '@auth0/nextjs-auth0'

export default initAuth0({
  domain: process.env.domain,
  clientId: process.env.clientId,
  clientSecret: process.env.clientSecret,
  scope: 'openid profile',
  redirectUri: process.env.redirectUri,
  postLogoutRedirectUri: process.env.postLogoutRedirectUri,
  session: {
    cookieSecret: process.env.cookieSecret,
    cookieLifetime: 60 * 60 * 8,
    storeIdToken: false,
    storeAccessToken: false,
    storeRefreshToken: false,
  },
  oidcClient: {
    httpTimeout: 2500,
    clockTolerance: 10000,
  },
})

domain=your-auth0-domain.auth0.com
clientId=your-client-id
clientSecret=your-client-secret
redirectUri=http://localhost:3000/api/callback
postLogoutRedirectUri=http://localhost:3000/
cookieSecret=here-is-a-really-long-string-please-use-a-unique-one

In order for the .env variables to be recognized by Next.js we have one more step. Create a next.config.js file and add the following to it:

next.config.js

require('dotenv').config()

module.exports = {}

Make sure to restart your next.js development server after you do this or these settings won't get loaded in. Then, add dotenv to the project:

npm install --save dotenv

This will load the environmental variables from the .env into our app but they will only be accessible from the server, which is exactly what we want. Now let's go ahead and make our api routes. They are all very similar except we will be calling different methods from the auth0 instance that we are defining above.

pages/api/login.ts

import auth0 from '../../utils/auth0'

export default async function login(req, res) {
  try {
    await auth0.handleLogin(req, res, {})
  } catch (error) {
    console.error(error)
    res.status(error.status || 500).end(error.message)
  }
}

pages/api/callback.ts

import auth0 from '../../utils/auth0'

export default async function callback(req, res) {
  try {
    await auth0.handleCallback(req, res, {})
  } catch (error) {
    console.error(error)
    res.status(error.status || 500).end(error.message)
  }
}

pages/api/me.ts

import auth0 from '../../utils/auth0'

export default async function me(req, res) {
  try {
    await auth0.handleProfile(req, res, {})
  } catch (error) {
    console.error(error)
    res.status(error.status || 500).end(error.message)
  }
}

pages/api/logout.ts

import auth0 from '../../utils/auth0'

export default async function logout(req, res) {
  try {
    await auth0.handleLogout(req, res)
  } catch (error) {
    console.error(error)
    res.status(error.status || 500).end(error.message)
  }
}

We start by defining an async function that has a req and a res. This is similar to express middlewares where we get access to the request through the req and modify the response by writing over pieces of the res object. In our case, we have a try/catch block where we try to call the auth0 method and pass the req and res into it. In the event that an error occurs, we log the error and return the error status and the error message.

Next, we need to create a way to store the user state on the client. The following code is pulled directly from the auth-nextjs example folder. The general idea is that we create a react context that will store the user profile information. We will create a provider component called UserProvider which we will have in the root of our project and we will call the useFetchUser react hook in any of the nested react components that need access to the user profile information.

utils/user.tsx

import React from 'react'
import fetch from 'isomorphic-unfetch'

// Use a global to save the user, so we don't have to fetch it again after page navigations
let userState

const User = React.createContext({ user: null, loading: false })

export const fetchUser = async () => {
  if (userState !== undefined) {
    return userState
  }

  const res = await fetch('/api/me')
  userState = res.ok ? await res.json() : null
  return userState
}

export const UserProvider = ({ value, children }) => {
  const { user } = value

  // If the user was fetched in SSR add it to userState so we don't fetch it again
  React.useEffect(() => {
    if (!userState && user) {
      userState = user
    }
  }, [])

  return <User.Provider value={value}>{children}</User.Provider>
}

export const useUser = () => React.useContext(User)

export const useFetchUser = () => {
  const [data, setUser] = React.useState({
    user: userState || null,
    loading: userState === undefined,
  })

  React.useEffect(() => {
    if (userState !== undefined) {
      return
    }

    let isMounted = true

    fetchUser().then(user => {
      // Only set the user if the component is still mounted
      if (isMounted) {
        setUser({ user, loading: false })
      }
    })

    return () => {
      isMounted = false
    }
  }, [userState])

  return data
}

Let's now update the MainLayout component to add the UserProvider. Since the MainLayout was a class-based component we need to also convert it to a functional component because hooks require functional components to function. We will also call the useFetchUser hook here so that we can feed the user and loading boolean into the provider itself.

components/layout/MainLayout.tsx

import { Layout } from 'antd'
import { ReactNode, Component } from 'react'
import Navbar from './Navbar'
import styled from 'styled-components'
import { UserProvider, useFetchUser } from '../../utils/user'

const { Content } = Layout

const StyledContent = styled(Content)`
  min-height: 100vh;
`

export const MainLayout = ({ children }: { children: ReactNode }) => {
  const { user, loading } = useFetchUser()
  return (
    <UserProvider value={{ user, loading }}>
      <Layout>
        <Navbar />
        <StyledContent>{children}</StyledContent>
      </Layout>
    </UserProvider>
  )
}

We are now ready to update the Navbar component to add the useFetchUser hook and use the user object that we get back as a way to tell if the user is logged in or not. If it is undefined we can assume the user is not logged in an display the login button. Otherwise, if there is a user object then we know they are logged in and we can display the logout and profile buttons:

components/layout/Navbar.tsx

import { Layout, Menu } from 'antd'
import Link from 'next/link'
import styled from 'styled-components'
import { useFetchUser } from '../../utils/user'

const { Header } = Layout

const StyledHeader = styled(Header)`
  background-color: #dddbe8;
  .ant-menu {
    width: 100%;
    background-color: #dddbe8;
    a {
      height: 64px;
    }
  }
`

const Navbar = () => {
  const { user, loading } = useFetchUser()

  return (
    <StyledHeader>
      <Menu mode="horizontal">
        <Menu.Item key="/">
          <Link href="/">
            <a>Home</a>
          </Link>
        </Menu.Item>
        {user && !loading
          ? [
              <Menu.Item key="/api/logout">
                <Link href="/api/logout">
                  <a>Logout</a>
                </Link>
              </Menu.Item>,
              <Menu.Item key="/profile">
                <Link href="/profile">
                  <a>Profile</a>
                </Link>
              </Menu.Item>,
            ]
          : null}
        {!user && !loading ? (
          <Menu.Item key="/api/login">
            <Link href="/api/login">
              <a>Login</a>
            </Link>
          </Menu.Item>
        ) : null}
      </Menu>
    </StyledHeader>
  )
}

export default Navbar

Finally, let's update the profile page so that we can display the user's profile information if they are logged in. Otherwise, we will redirect them to the home page.

pages/profile.tsx

import { MainLayout } from '../components/layout/MainLayout'
import styled from 'styled-components'
import { useFetchUser } from '../utils/user'
import Router from 'next/router'

const StyledProfile = styled.div`
  padding: 50px 10px;
  text-align: center;
  h1 {
    font-size: 60px;
  }
`

export default function Profile() {
  const { user, loading } = useFetchUser()

  if (loading) {
    return (
      <MainLayout>
        <p>Loading...</p>
      </MainLayout>
    )
  }
  if (!user && !loading) {
    Router.replace('/')
  }

  return (
    <MainLayout>
      <StyledProfile>
        <h1>🤸</h1>
        <p>Welcome to the Profile Page! Here is your profile information:</p>
        <p>{JSON.stringify(user)}</p>
      </StyledProfile>
    </MainLayout>
  )
}

That's it! You should now have a working Next.js application with Auth0 and are now ready to build the next great web application with this as a starter. Cheers!

If you liked this tutorial, I created an entire course that teaches you how to build a recipe sharing application from the ground up using Next.js, Auth0 and a graphQL CMS called GraphCMS. We will go through how to take the foundation that you learned here and build a fully-featured application that has file uploads, user permissions, responsive design with Ant Design, and the entire app is hosted serverlessly using Zeit's Now service so that you can deploy it with one command and be confident that it will be reliable and scalable no matter how many people visit the page.

Frontend Serverless with React and GraphQL

5 Reasons why GraphCMS should be your next backend for MVPs

Code Mochi — Mon, 02 Mar 2020 13:50:53 +0000

Birthing a new idea into the world is always a labor of love and this is especially true when you are building a web application. Today, there are so many different kinds of technologies that you need to bring together to make a rich user experience that people expect in a website. In this post, I’m going to go over why I think that a serverless graphQL backend makes for the perfect developer experience for MVP projects, especially as a solo developer.

There are many ways that you can create a graphQL server, but this post will focus on backend-as-a-service options and in particular GraphCMS. I’ve found that after making many different graphQL servers over the years, that when I chose GraphCMS to build my recently completed Frontend Serverless Course, that it was just so much faster getting off than ground that I wanted to share my experiences. This post is not sponsored by GraphCMS, I'm just a fan!

Reason #1: It’s a backend as a service so you can focus on the frontend

Web applications that pull dynamic data generally have two main components to them- a frontend which serves the javascript, html, and css, and a backend that connects to your database and provides all of the dynamic data that your frontend uses to create the user experience.

If you have a small team or especially as a solo developer, you need to make sure above all else that you are creating an experience that your users love. Since the frontend is what the users are seeing and interacting with, you should be spending most of the time building an experience that will delight your users. Especially when you are starting out, it is alluring spend time trying to optimize caching on your backend, rolling your own authentication, or a host of other things you read about in blogs as must-haves for an application but premature optimization will truly be the death of your idea in the beginning when your resources are limited. This is a mistake I have made in the past and it kills your ideas by first sapping your time and then your enthusiasm for the project.

Don't let this happen to you- kill all premature optimization with fire and use tried-and-true solutions for things that don't differentiate your business!

Reason #2: Strong typing of data models make development so much easier and allows you to change them as business priorities shift

There are many backend-as-a-service options out there but many of them do not support graphQL. For me, this is a deal-breaker because I am so spoiled that I can define models on my backend and have them propagate across my stack. I’ve previously discussed (I, II, III) how graphQL code generator makes it really easy to extract all of the data models by querying the backend server for the schema and creating typescript models that you can use on the frontend. This means that you won’t be in a position where you are accidentally trying to call parameters on a user field that doesn’t exist because you will get a typescript error immediately so that you will know to fix it.

To make it even nicer, the graphQL code generator can be run every time that you change your models so that those typescript types instantly will be updated on your frontend code. This is a godsend for a frontend developer because it means that you can easily tell how to change your code when you change your backend because you will have errors in places where you are referring to fields that no longer exist.

GraphCMS makes this even nicer because you can use this nice UI to build your models with all of their fields and a wide variety of property types. Take a look at this recipe model for example from the Frontend Serverless Course. We can see that the recipes have a title, which is a string, ingredients that are json, and images that are actually linked to images that we’ve uploaded.

What makes this even nicer is that we can even establish relationships between different models so here we have a recipe that can have many userLikes, which is an array of records that each represent a single like that a user has given to this particular recipe. This means to the user that when they click a recipe and say that they like it, we can create a new userLike record to track the total amount of people who have liked a given recipe.

Reason #3: It’s serverless so it will seamlessly scale with your backend

Your frontend is only useful if other people can access it and so and important aspect to consider is what happens if your website’s hits go through the roof. This is where self-hosted solutions such as those that revolve around express.js solutions can get you into trouble because unless you hosted them on a solution such as Amazon’s Elastic Beanstalk, a single instance of a backend will definitely fail above a certain load. Using a serverless option is really nice because you don’t have to worry about the scaling at all and GraphCMS has a pretty generous free tier of 1 million api operations per month and 500 GB asset traffic.

Reason #4: GraphCMS uses standard graphQL so you are never locked into proprietary systems and you can use all the libraries that you are used to

Using GraphCMS, you can use all of the tools from graphQL that you know and love- Apollo client and graphQL codegen works great with GraphCMS as a backend, and you can integrate Auth0 to add user login and roles. In the Frontend Serverless course I just finished, I talk about how to integrate all of those libraries together and if you are interested to see how, I posted the source code over on Github.

Any time that you are considering using a service, it is absolutely critical that you carefully consider how locked in you will be with that service so that you can get out of it if you need to in the future. Although GraphCMS provides a nice ecosystem to build your app, if you ever needed to switch away to a backend that you rolled yourself or something else like AWS Appsync, I don’t anticipate that it would be too difficult.

GraphCMS provides a Graphiql admin interface that provides you full access to your data and you could just download it all and then execute a createMany mutation against your new backend to migrate everything over. Unlike something like AWS Cognito which is storing user passwords and can’t be transferred to a new service without notifying the user, you wouldn’t have this worry here so you could always start with GraphCMS and then migrate if you needed to.

Reason #5: It has a beautiful UI so you don’t have to roll your own admin panel

One of the biggest time sinks that I’ve run into in the past is this situation where you feel that the first thing you need to build is the admin portal so that you have a way to insert all of the data that your customers will see on the client-facing part of the site. For example, on my science course website Pocket Scholar, I built an admin backend so that I could enter my course, lecture, question and answer data and it ended up being the most complicated part of the site because it needed to have tables for inserting data, image uploading to s3, and linking capabilities to associate a lecture with its respective course.

Using a CMS makes it so much easier because you can enter all the information into a web admin UI and then get started right away building your customer-facing features. Here's an example of what the Recipe UI looks like based on the model that we defined above. We can see linked images, one-to-many relationship counts with the UserLikes models.

When we click on one item we can edit all of the data in place, which makes it super easy when we need to update anything. You can see here that we can edit any of the fields, update the pictures, or delete it if we need to.

Conclusion

Hopefully this post has shown why graphQL backends-as-a-service are so powerful and why GraphCMS, in particular, is an amazing way to get your MVP off the ground as fast as possible. They have a nice free tier, you don't get locked in because you have full access to your data, and it plays nicely with React, graphQL tools, and user authentication/authorization flows that you'd be using in your app anyway.

The primary reason why you would not want to consider this solution is that as of when this post is published, although you can use a proxy for enforcing permissions against the GraphCMS backend if you have more elaborate permission requirements, a more conventional backend might suit your needs better. To give an example, although this would work well for blocking users from accessing certain mutations or enforcing that a user can only access or edit documents that they own if you have mutation requirements that required more nuanced resolvers, GraphCMS might not be the ideal situation for you. With that said though, I think that the advantages of speed and rapid iteration that this platform provides outweigh the downsides, so if your use case allows for it, you should definitely consider building your next app with GraphCMS.

Love this post and want to get started on your GraphCMS journey by building this application from scratch? Check out my Frontend Serverless Course!

Originally posted at Code Mochi.

Nested GraphQL Mutations with Prisma 2 Photon

Code Mochi — Thu, 19 Sep 2019 13:24:52 +0000

Photon by Prisma, is an amazing package that takes care of all the heavy lifting of performing CRUD operations on your data from the backend side of your full stack web application. We have previously shown how you can use Photon to easily create a GraphQL api [1, 2, 3]. In that example, Users can have many Blogs, but we had to first create a user and then create blogs.

Video of what we are doing:

You might wonder whether there would be a more straightforward way to perform a single nested mutation that would both create the user and then the blogs and it turns out that Photon makes that really easy.

A mutation is a GraphQL term that refers to an operation that changes the data. Here are two mutations that we’ve used in the past for creating Users and Posts.

Create a User

mutation signupUserMutation($name: String!, $email: String!) {
  signupUser(data: { name: $name, email: $email }) {
    ...UserFragment
  }
}

Create a Blog Post

mutation createDraftMutation(
  $title: String!
  $content: String!
  $authorEmail: String!
) {
  createDraft(title: $title, content: $content, authorEmail: $authorEmail) {
    ...PostFragment
  }
}

To create a nested mutation, we use the create method within our posts field of the user creation mutation. We can specify an array of all the posts that we want to add to our new user and Photon, along with the Nexus plugin for Prisma will create both the new user and all the new posts that we desire.

Create a User first, then several Blogs associated to the user

mutation {
  signupUser(
    data: {
      email: "stephen@codemochi.com"
      name: "Stephen"
      posts: {
        create: [
          { title: "First Post", content: "Yay", published: true }
          { title: "Second Post", content: "Oh yeah", published: false }
        ]
      }
    }
  ) {
    id
    name
    email
    posts {
      id
      title
      content
    }
  }
}

Remember in Spiderman when they say "with great power comes great responsibility"? Well, that holds true here. Nexus, will auto-generate queries and mutations that we specify. An issue we need to be aware of is that since we are using the stock create user mutation as created by Nexus instead of a custom resolver, this mutation has a lot more flexibility in what it allows for.

In the past we made a custom createDraft mutation that looked like this:

t.field('createDraft', {
  type: 'Post',
  args: {
    title: stringArg(),
    content: stringArg({ nullable: true }),
    authorEmail: stringArg(),
  },
  resolve: (_, { title, content, authorEmail }, ctx) => {
    return ctx.photon.posts.create({
      data: {
        title,
        content,
        published: false,
        author: {
          connect: { email: authorEmail },
        },
      },
    })
  },
})

We opted for doing this instead of simply doing t.crud.createOnePost({ alias: ‘createDraft’ }) because using the long form version, allows us to control exactly which arguments we will accept and how they get passed into the photon create method. In the case of the nested mutation above, we allow the users to enter the boolean value of the published field which allows them to specify whether they want it published or not, and this is explicitly forbidden in the createDraft mutation because we are setting every post’s published field that is created to false.

If you are fine with your user’s having that level of flexibility for that particular model item, then this whole discussion likely won’t matter. If you’d still like to do nested mutations, but you want to limit which fields the user can update, we can create a custom mutation where we limit which arguments we can pass into it. Create a new mutation that looks like this:

t.field('createUserAndDrafts', {
  type: 'User',
  args: {
    name: stringArg(),
    email: stringArg(),
    posts: arg({ type: 'PostCreateManyWithoutPostsInput' }),
  },
  resolve: (_, { name, email, posts }, ctx) =>
    ctx.photon.users.create({
      data: {
        email,
        name,
        posts: {
          create: posts.create.map(({ title, content }) => ({
            title,
            content,
            published: false,
          })),
        },
      },
    }),
})

Here, the mutation will remain unchanged from what we used above in the graphql section, but we are only using the title and content and we are setting our own value for published in the resolver.

Originally posted at Code Mochi.

Hot Module Reloading with Next.js Docker development environment in 4 steps

Code Mochi — Tue, 27 Aug 2019 12:52:53 +0000

This post will go through how to add hot module reloading to Next.js running a docker environment. This is critical to development for your Next.js application because you want the app to reload your webpage as you change files in the application’s folder. When we are finished, any changes that you make to your React codebase will automatically be reloaded and you should see the changes show up in your development environment within 1 second of the change.

Video of what we are doing:

Step 1: Create a Dockerfile for your Next.js application.

We’ve previously built a Dockerfile for our Next.js application in a previous blog post, but if you are trying to dockerize your application for the first time, you need to create a Dockerfile.

FROM node:10.16.0

RUN mkdir /app
WORKDIR /app

COPY package*.json ./
RUN npm install

CMD [ "npm", "run", "dev" ]

The idea here is to start with a base ubuntu image and copy the package.json and package-lock.json files into the directory and running an npm install command.

Step 2: Add a volume mount between your host and docker environment.

We are using docker-compose to create a volume mount between the /app directory and our actual working directory on our native operating system (/frontend). The service block for this application looks like this- where frontend is the directory that our Next.js application lives in.

  frontend:
    container_name: frontend
    ports:
      - '3000:3000'
    build:
      context: frontend
      dockerfile: Dockerfile
    volumes:
      - ./frontend:/app
      - /app/node_modules
      - /app/.next

Step 3: Add docker volumes for your node_modules and .next folders.

As we allude to in Step 2, we also need to add docker volumes for the node_modules and .next folders so that docker will use the docker folders instead of the host OS folders.

Step 4: Modify our webpack middleware for our Next.js app.

In the frontend/next.config.js file, we need to give the webpack middleware, instructions for when to reload itself. If your app does not have a next.config.js file, you can simply add the following code:

module.exports = {
  webpackDevMiddleware: config => {
    config.watchOptions = {
      poll: 1000,
      aggregateTimeout: 300,
    }
    return config
  },
}

For our previous project, we don’t need to create an entire new object to export, we can instead just add the webpackDevMiddleware block to our already existing configuration object:

const withCSS = require('@zeit/next-css')

module.exports = withCSS({
  target: 'serverless',
  env: {
    BACKEND_URL: process.env.BACKEND_URL,
  },
  webpackDevMiddleware: config => {
    config.watchOptions = {
      poll: 1000,
      aggregateTimeout: 300,
    }
    return config
  },
})

That should be it- you should now see that as you update your react components from within Next.js, that they instantly show up as changed in your web browser without having to run a docker-compose down followed by docker-compose up.

Originally posted at Code Mochi.

Developer Bliss- Serverless Fullstack React with Prisma 2 and GraphQL

Code Mochi — Thu, 08 Aug 2019 20:32:11 +0000

In this post, we will show how you can deploy a totally serverless stack using Prisma 2 and Next.js. This type of solution has only been recently available and while it is still in beta, it really represents a full stack developer's paradise because you can develop an app, deploy it, forget about worrying about any of the DevOps particulars and be confident that it will work regardless of load.

Benefits:

One command to deploy the entire stack (Now)
Infinitely scalable, pay for what you use (lambda functions)
No servers to maintain (lambda functions)
All the advantages of React (composability, reusability and strong community support)
Server-side rendering for SEO (Next.js)
Correctly rendered social media link shares in Facebook and Twitter (Next.js)
Easy to evolve api (GraphQL)
One Schema to maintain for the entire stack (Prisma 2)
Secure secret management (Now)
Easy to set up development environment with hot code reloading (Docker)
Strongly typed (GraphQL and Typescript) that is autogenerated when possible (graphql-gen)

Before you start, you should go ahead and set up an RDS instance and configured like our previous blog post.

Videos:

I. Install Dependencies

II. Add Environmental Parameters

III. Configure the Backend

IV. Configure the Now Service

V. Set up Now Secrets and Deploy!

We will pick up from the example from our multi-part blog series [1], [2], [3]. If you aren't interested in following along from the start, you can start by checking out the repo from the now-serverless-start tag:

git clone https://github.com/CaptainChemist/blog-prisma2
git fetch && git fetch --tags
git checkout now-serverless-start

I. Install and clean up dependencies

Upgrade to Next v9

In the frontend/package.json make sure that next has a version of "^9.02" or greater. Previously we were using a canary version of 8.1.1 for typescript support, but since the post version 9 of next was released so we want to make sure we can take advantage of all the latest goodies.

Install webpack to the frontend

As a precaution, you should install webpack to the frontend folder. I've seen inconsistent behavior with now where if webpack is not installed, sometimes the deploy will fail saying that it needs webpack. When I read online it sounds like it shouldn't be required so this is likely a bug, but it can't hurt to add it:

npm install --save-dev webpack

Remove the main block from package.json and frontend/package.json

When we generated our package.json files, it auto-populated the main field. Since we are not using this feature and don't even have an index.js file in either folder, we should go ahead and remove them. In frontend/package.json go ahead and remove line 5. We didn't use it previously and it has the potential to confuse the now service.

"main": "index.js",

Also, do the same in the package.json in the root folder.

Install Prisma2 to the backend

Although we globally install prisma2 in our docker containers, we need to now add it to our backend package.json file so that when we use the now service it will be available during the build step up in AWS. Navigate to the backend folder and install prisma2:

npm install --save-dev prisma2

Install Zeit Now

We should install now globally so that we will be able to run it from the command line:

npm install -g now

II. Add Environmental Variables

Add a .env file to the root of your project. Add the following variables which we will use across our docker environment.

MYSQL_URL=mysql://root:prisma@mysql:3306/prisma
BACKEND_URL=http://backend:4000/graphql
FRONTEND_URL=http://localhost:3000

Modify the docker-compose.yml file to inject these new variables into our docker containers. This is what the updated file looks like:

docker-compose.yml

version: '3.7'
services:
  mysql:
    container_name: mysql
    ports:
      - '3306:3306'
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: prisma
      MYSQL_ROOT_PASSWORD: prisma
    volumes:
      - mysql:/var/lib/mysql
  prisma:
    links:
      - mysql
    depends_on:
      - mysql
    container_name: prisma
    ports:
      - '5555:5555'
    build:
      context: backend/prisma
      dockerfile: Dockerfile
    environment:
      MYSQL_URL: ${MYSQL_URL}
    volumes:
      - /app/prisma
  backend:
    links:
      - mysql
    depends_on:
      - mysql
      - prisma
    container_name: backend
    ports:
      - '4000:4000'
    build:
      context: backend
      dockerfile: Dockerfile
      args:
        - MYSQL_URL=${MYSQL_URL}
    environment:
      MYSQL_URL: ${MYSQL_URL}
      FRONTEND_URL: ${FRONTEND_URL}
    volumes:
      - ./backend:/app
      - /app/node_modules
      - /app/prisma
  frontend:
    container_name: frontend
    ports:
      - '3000:3000'
    build:
      context: frontend
      dockerfile: Dockerfile
    environment:
      BACKEND_URL: ${BACKEND_URL}
    volumes:
      - ./frontend:/app
      - /app/node_modules
      - /app/.next

volumes: #define our mysql volume used above
  mysql:

Let's take a look at the parts that were changed, below are the parts snipped out that we added to the above file:

prisma:
  environment:
    MYSQL_URL: ${MYSQL_URL}
### ..more lines ###
backend:
  build:
    context: backend
    dockerfile: Dockerfile
    args:
      - MYSQL_URL=${MYSQL_URL}
  environment:
    MYSQL_URL: ${MYSQL_URL}
    FRONTEND_URL: ${FRONTEND_URL}
### ..more lines ###
frontend:
  environment:
    BACKEND_URL: ${BACKEND_URL}

We added environment blocks to the prisma studio, backend, and frontend containers. Since we have the .env file, any variables that we define in the .env file, such as VAR1=my-variable, we can call it in the yml as \${VAR1} and that will be like we used the my-variable string directly in that spot of the yml file.

Dynamically set Backend url on the frontend

We need to set the uri that the frontend connects to dynamically instead of hardcoding it. In the frontend/utils/init-apollo.js we previously had this line which would connect to localhost if the request came from a user or from the backend if it came from the next.js server:

uri: isBrowser ? 'http://localhost:4000' : 'http://backend:4000', // Server URL (must be absolute)

We need to still keep track of whether we are in the browser or server in the docker environment. In addition, though, we need to check whether we are in a docker environment or whether we are deployed via now into a lambda function.

We can access environment variables by using the process.env.ENVIRONMENTAL_VARIABLE. We check if the url matches our local environment url and if so, we know that we are in a docker environment. Now our logic is that if we are in a docker environment and the browser is making the request, we return the localhost, otherwise we pass the BACKEND_URL as the uri.

frontend/utils/init-apollo.js

function create(initialState) {
  // Check out https://github.com/zeit/next.js/pull/4611 if you want to use the AWSAppSyncClient
  const isBrowser = typeof window !== 'undefined'
  const isDocker = process.env.BACKEND_URL === 'http://backend:4000/graphql'
  return new ApolloClient({
    connectToDevTools: isBrowser,
    ssrMode: !isBrowser, // Disables forceFetch on the server (so queries are only run once)
    link: new HttpLink({
      uri:
        isDocker && isBrowser
          ? 'http://localhost:4000/graphql'
          : process.env.BACKEND_URL,
      credentials: 'same-origin', // Additional fetch() options like `credentials` or `headers`
      // Use fetch() polyfill on the server
      fetch: !isBrowser && fetch,
    }),
    cache: new InMemoryCache().restore(initialState || {}),
  })
}

Now that should really be all that we need to do, but since Next.js is both rendered on the server and in the client, we won't have access to server environmental variables unless we take one more step. We need to expose the variable in our frontend/next.config.js file:

frontend/next.config.js

const withCSS = require('@zeit/next-css')

module.exports = withCSS({
  target: 'serverless',
  env: {
    BACKEND_URL: process.env.BACKEND_URL,
  },
})

Note that due to how exactly Next.js handles process.env, you cannot destructure variables off of it. So the line below will not work, we need to use the entire process.env.BACKEND_URL variable.

const { BACKEND_URL } = process.env // NO!

III. Configure our backend server

Update the backend server to the /graphql backend and configure CORS

We updated the url above to the /graphql endpoint for the backend server. We are doing this because in now we will deploy our backend graphql server to ourdomain.com/graphql. We need to make this change in our backend/src/index.ts so that the server will be running at the /graphql endpoint instead of /.

In addition, while we are here, we will disable subscriptions and enable CORS. CORS stands for cross origin resource sharing and it tells the backend server which frontend servers it should accept requests from. This ensures that if someone else stood up a frontend next server that pointed to our backend server that all requests would fail. We need this because you could imagine how damaging this could potentially be if someone bought a domain crazyamazondeals.com (I'm just making this up) and pointed their frontend server to the real backend server of amazon's shopping portal. This would allow a fake amazon frontend to gather all sorts of customer information while still sending real requests to amazon's actual backend server. Yikes!

In order to enable CORS we will pass in our frontend url. We will also enable credentials for future authentication-related purposes.

backend/src/index.ts

server.start(
  {
    endpoint: '/graphql',
    playground: '/graphql',
    subscriptions: false,
    cors: {
      credentials: true,
      origin: process.env.FRONTEND_URL,
    },
  },
  () => console.log(`🚀 Server ready`)
)

Update the backend/prisma/project.prisma file to use environmental variables and set our platform.

We can use the env("MYSQL_URL") which will take our MYSQL_URL environmental variable. Starting with prisma preview-3+ we need to specify which platforms that we plan to use with prisma2. We can use "native" for our docker work, but we need to use "linux-glibc-libssl1.0.2" for Zeit Now.

backend/prisma/project.prisma

datasource db {
  provider = "mysql"
  url      = env("MYSQL_URL")
}

generator photon {
  provider  = "photonjs"
  platforms = ["native", "linux-glibc-libssl1.0.2"]
}
// Rest of file

Update the backend/Dockerfile to pass the environmental variable into the prisma2 generate. We first have to define a docker argument using ARG named MYSQL_URL. Then, we take the MYSQL_URL environmental variable and assign it to this newly created ARG.

We need the MYSQL_URL environment variable so that our url from the prisma file gets evaluated properly.

backend/Dockerfile

FROM node:10.16.0
RUN npm install -g --unsafe-perm prisma2

RUN mkdir /app
WORKDIR /app

COPY package*.json ./
COPY prisma ./prisma/

ARG MYSQL_URL
ENV MYSQL_URL "$MYSQL_URL"

RUN npm install
RUN prisma2 generate

CMD ["npm", "start" ]

Note that the only reason we have access to the $MYSQL_URL variable in this Dockerfile is due to an args block that we previously added to the docker-compose.yml file. Adding variables to the environment block of docker-compose is only accessible during the runtime of the containers, not the building step which is where we are at when the Dockerfile is being executed.

backend:
  build:
    context: backend
    dockerfile: Dockerfile
    args:
      - MYSQL_URL=${MYSQL_URL}

IV. Add our Now Configuration

Create now secrets

Locally, we have been using the .env file to store our secrets. Although we commit that file to our repo, the only reason why we can do that is because there are no sensitive environmental variables there. Ensure that if you ever add real secrets to that file, such as a stripe key, you need to never commit that to github or else you risk them being compromised!

For production, we need a more secure way to store secrets. Now provides a nice way to do this:

now secret add my_secret my_value

Now will encrypt and store these secrets on their servers and when we upload our app we can use them but we won't be able to read them out even if we try to be sneaky and read it out using console.logs. We need to create variables for the following variables that were in our .env file:

MYSQL_URL=mysql://user:password@your-mysql-database-url:3306/prisma
BACKEND_URL=https://your-now-url.sh/graphql
FRONTEND_URL=https://your-now-url

Note that by default your-now-url will be yourProjecFoldername.yourNowUsername.now.sh but you can always skip this step for now, get to Step V of this tutorial, deploy your site and then look at where it deploys to because it will be the last line of the console output. Then you come back to this step and add the now secrets and redeploy the site.

Add a now.json file to the root directory

We need to create a now.json file which will dictate details about how we should deploy our site. The first part of it has environmental variables for both the build and the runtime. We will be using secrets that we created in the previous step by using the @our-secret-name. If you forget what names you used, you can always type now secrets ls and you will get the names of the secrets (but critically not the secrets themselves).

Next we have to define our build steps. In our case we have to build both our nextjs application and our graphql-yoga server. The nextjs is built using a specially designed @now/next builder and we can just point it to our next.config.js file which is in our frontend folder. Our other build will use the index.ts file in our backend/src directory and the builder is smart enough to compile the code down into javascript and deploy it to a lambda function.

Finally, we have to define our routes. The backend server will end up at the /graphql endpoint while the frontend directory will use everything else. This ensures that any page we go to under ourdomain.com will be forwarded onto the nextjs server except the /graphql endpoint.

now.json

{
  "version": 2,
  "build": {
    "env": {
      "MYSQL_URL": "@mysql_url",
      "BACKEND_URL": "@backend_url",
      "FRONTEND_URL": "@frontend_url"
    }
  },
  "env": {
    "MYSQL_URL": "@mysql_url",
    "BACKEND_URL": "@backend_url",
    "FRONTEND_URL": "@frontend_url"
  },
  "builds": [
    {
      "src": "frontend/next.config.js",
      "use": "@now/next"
    },
    {
      "src": "backend/src/index.ts",
      "use": "@now/node",
      "config": { "maxLambdaSize": "20mb" }
    }
  ],
  "routes": [
    { "src": "/graphql", "dest": "/backend/src/index.ts" },
    {
      "src": "/(.*)",
      "dest": "/frontend/$1",
      "headers": {
        "x-request-path": "$1"
      }
    }
  ]
}

Add a .nowignore file to the root directory

Finally, we can add our ignore file which will tell now which things it shouldn't bother to upload.

.nowignore

**/node_modules
.next
Dockerfile
README.MD

V. Deploy our now full stack site

This part is easy. Simply type now from the root folder and let it fly!

There is more where that came from!
I created an entire course about using Zeit Now + Next.js to build a recipe sharing application, so if you liked this go check it out!

Frontend Serverless with React and GraphQL

Click here to give us your email and we'll let you know when we publish new stuff. We respect your email privacy, we will never spam you and you can unsubscribe anytime.

Originally posted at Code Mochi.

Setup RDS for Serverless Zeit Now Deployments

Code Mochi — Thu, 08 Aug 2019 13:05:25 +0000

RDS is a fantastic option for hosting your database. It has automatic database backups and logging built-in and you can scale your instance as you get more users. A well-suited database instance for your application ensures that you aren't paying for server costs that you don't need. While RDS is not as hands-off as DynamoDB because you will need to still scale it up and down as your needs adjust, MySQL and Postgres are more popular database options so they tend to be better supported.

In this post we will go through how you can create your very own RDS MySQL instance that’s hosted by AWS and all set up for connecting to the Zeit Now service. You’ll need this setup if you’d like to serverlessly deploy your Prisma 2 backend like we will show in our next post, but this option is also needed for other backend ORM packages such as sequelize for connecting to a database. After setting the database up, we will also go through how you can configure your security groups so that you can connect to it from the outside world or your lambda function.

Video for this post:

Step 1:

Go to the AWS console and then the RDS page. In the resources panel click on the DB Instances link. Then click the create DB button.

Step 2: Configure the RDS instance and template type

Create a MySQL RDS type and then click on the free tier. This probably will be more than good enough for your purposes to start. It will only run one database instance which means that it will not be fault tolerant in the event that the server dies. In the future you can always bump this up to have redundancy across three or more database instances in different availability zones.

Step 3: Configure the RDS settings

We can pick the instance identifier, which is what we will call this database from within. Note that this is not the database name- we will be setting that later. Next, we can set the root username and password. We can always create more users in the future with more scoped down permissions that limit which tables we can write to.

We can also disable storage autoscaling and allocate 20 GB to start.

Step 4: Configure the VPC settings

A VPC is a closed-off section of the cloud. We want to create a new VPC so this database instance can live in its own little world and we want to make sure we go into the advance settings and set it open to the world. If we don’t take that additional step, we won’t be able to access it from our development machine and the Now backend instance won’t be able to reach it.

Next, we have to set the security group- think of this as a firewall. We can control access to the database by selectively opening ports and also specify which IP addresses that the requests are allowed to come from. By default all traffic is allowed out, but only port 3306 is allowed from our dev machine’s IP address. We will need to fix that later in the tutorial.

Step 5: Additional Configuration

Here we can create a default database. In our case I want to make one called prisma because that’s what I’m telling the prisma 2 service to write to in my configuration. We can also specify whether we’d like automatic backups. You’d certainly want this for a production database, but this is for dev purposes so I won’t worry about it.

Step 6: Create the database

After creating the database, AWS tells you that it will take several minutes to finish.

Step 7: Open up your incoming RDS IPs to the world

Next we need to change the security group so that it is open to the world. By default it will only be open to your current IP address, which is great for debugging, but it won’t work for Zeit’s Now service because it is up on AWS so the IP will be different. To further complicate issues, Zeit doesn’t adhere to a particular subset of IP addresses which is unfortunate because it means that we need to open up our RDS instance to the entire world and we can’t limit it to the just Zeit lambda functions. This means that it is super critical that we choose a very secure username and password so others can’t get in even if the port is exposed.

Step 8: Connect to our database

Finally we can now connect to our database. We can copy the database URL from the RDS pane. It will be something like:

yourRds-instance-someRandomId-yourRegion.rds.amazonaws.com

With the username and password we set previously and a port of 3306. You can connect to it with whatever program you like but I’m a fan of the (free!) Sequel Pro.

When you want to create a connection string it will be of the following form:

mysql://yourUsername:yourPassword@yourRds-instance-someRandomId-yourRegion.rds.amazonaws.com:3306/yourDatabasename

That’s it! Make sure that if you use this connection string in Zeit Now that you never, ever, ever commit the string to Github. If you accidentally do compromise your connection string on Github or anywhere else, make sure that you immediately change your password. Instead, use now secrets to manage your connection string. We discuss this in our post about serverless deployment, so be sure to check it out!

Originally posted at Code Mochi.

Create a Fullstack Blog App with Next.js, Prisma 2 and Docker- Part III Build the UI

Code Mochi — Fri, 12 Jul 2019 14:42:35 +0000

In the final post of this series, we will build out the UI for this Blog site built with Next.js, Prisma 2 and Docker. Be sure to check out the first two posts to make sure you are caught up first.

import React, { ReactNode, Component } from 'react'
import { Layout } from 'antd'
import Link from 'next/link'
import Head from 'next/head'

const { Footer, Header, Content } = Layout

type Props = {
  title?: string
  children: ReactNode
}

class MainLayout extends Component<Props> {
  render() {
    const { children, title } = this.props
    return (
      <Layout>
        <Head>
          <title>{title}</title>
          <meta charSet="utf-8" />
          <meta
            name="viewport"
            content="initial-scale=1.0, width=device-width"
          />
        </Head>
        <Header>
          <nav>
            <Link href="/">
              <a>Home</a>
            </Link>
          </nav>
        </Header>
        <Content>{children}</Content>
        <Footer>
          <hr />
          <span>I'm here to stay (Footer)</span>
        </Footer>
      </Layout>
    )
  }
}

export default MainLayout

Update the index page to add the Layout component. You'll need to add this Layout on every page you make in the future, but in our case we only have the one:

frontend/pages/index.tsx

import * as React from 'react'
import { NextPage } from 'next'
import Layout from '../components/main-layout'

const IndexPage: NextPage = () => {
  return (
    <Layout title="Blog Layout">
      <h1>Simple Prisma 2 Blog Example</h1>
    </Layout>
  )
}

export default IndexPage

When you reload your page, it should have a header, footer and the body should be a gray color:

2. Create a Users Layout Component

Now that we have Ant Design installed, Apollo configured and our Apollo components autogenerated, it is time to get started making our components. Let's start with a users layout.

frontend/components/users.tsx

import React from 'react'
import { Table } from 'antd'
import { UsersQueryComponent } from '../generated/apollo-components'

type Props = {}

class UsersList extends React.PureComponent<Props> {
  render() {
    return (
      <UsersQueryComponent>
        {({ loading, error, data }) => {
          if (loading) return <p>Loading...</p>
          if (error) return <p>Error</p>

          if (data && 'users' in data && data.users.length > 0) {
            const feedData = data.users.map(({ name, email }, i) => ({
              key: i,
              name,
              email,
            }))
            const columns = [
              {
                title: 'Name',
                dataIndex: 'name',
                key: 'name',
              },
              {
                title: 'Email',
                dataIndex: 'email',
                key: 'email',
              },
            ]
            return <Table columns={columns} dataSource={feedData} />
          }

          return <p>No users yet.</p>
        }}
      </UsersQueryComponent>
    )
  }
}

export default UsersList

We are using an autogenerated component that is called UsersQueryComponent that was made by the GraphQL Codegen plugin. It is doing all the hard work of fetching our data. We first check that it isn't loading and there isn't an error and then we pull off a list of users from the data object.

Antd has a table component that we can feed it an array of objects and a list of column names and it will create a beautiful table for us. If there aren't any users we just report that back instead.

Now we can import that UsersList component into our index.tsx file:

frontend/pages/index.tsx

import * as React from 'react'
import { NextPage } from 'next'
import Layout from '../components/main-layout'
import UsersList from '../components/users'

const IndexPage: NextPage = () => {
  return (
    <Layout title="Blog Layout">
      <h1>Simple Prisma 2 Blog Example</h1>
      <h3>Users List</h3>
      <UsersList />
    </Layout>
  )
}

export default IndexPage

When we look at our webpage now, we should see that it is saying that we don't have any users yet. Let's change that now by creating a signup user component.

3. Create a Signup User Component

Let's create a new file called signup-user.tsx and add the following code:

frontend/components/signup-user.tsx

import React from 'react'
import { Row, Col, Button, Form, Input } from 'antd'
import {
  SignupUserMutationComponent,
  UsersQueryDocument,
} from '../generated/apollo-components'

type Props = {}
const initialState = { name: '', email: '' }
type State = typeof initialState

class SignupUser extends React.Component<Props> {
  state: State = initialState

  handleChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const { name, value } = event.target
    this.setState({ [name]: value })
  }

  render() {
    return (
      <SignupUserMutationComponent>
        {createUser => (
          <Form
            onSubmit={e => {
              e.preventDefault()
              createUser({
                variables: { ...this.state },
                refetchQueries: [{ query: UsersQueryDocument }],
              }).then(() => {
                this.setState({ name: '', email: '' })
              })
            }}
          >
            <Row>
              <Col span={6}>
                <Form.Item>
                  <Input
                    placeholder="name"
                    name="name"
                    value={this.state.name}
                    onChange={this.handleChange}
                    type="text"
                  />
                </Form.Item>
              </Col>
              <Col span={6}>
                <Form.Item>
                  <Input
                    placeholder="email"
                    name="email"
                    value={this.state.email}
                    onChange={this.handleChange}
                    type="text"
                  />
                </Form.Item>
              </Col>
              <Col span={6}>
                <Form.Item>
                  <Button htmlType="submit">Signup User</Button>
                </Form.Item>
              </Col>
            </Row>
          </Form>
        )}
      </SignupUserMutationComponent>
    )
  }
}

export default SignupUser

We are using a different autogenerated component called SignupUserMutationComponent to trigger our signupUser mutation. The SignupUserMutationComponent yields a method that we call createUser here which allows us to trigger a mutation wherever we'd like. We can pass variables into this method when we call it and they will get added to our request for the backend.

We create an HTML form with several inputs- name and email. We use the SignupUser state to save the input as the user types into the two input fields. Since the input fields display the current state of the react component, the user isn't directly typing into the field but instead is triggering an onClick trigger which is updating the state which we then see reflected in the input field.

When the user presses the submit button, we use an onSubmit trigger to fire off the createUser method which we populate with variables from the state.

After the mutation fires off we have a refetchQuery which will re-run the users query to make sure that our UsersList will have the new user's entry that was just added. Finally, we clear the state variables name and email which will clear out the input fields. This approach is called controlled components in React and is a pretty standard way of doing things, so if it is unfamiliar to you, check out the official documentation for more details (or feel free to reach out directly to me for this or other issues for possible future blog posts!).

Now you can add the SignupUser component to the index page:

frontend/pages/index.tsx

import * as React from 'react'
import { NextPage } from 'next'
import Layout from '../components/main-layout'
import UsersList from '../components/users'
import SignupUser from '../components/signup-user'

const IndexPage: NextPage = () => {
  return (
    <Layout title="Blog Layout">
      <h1>Simple Prisma 2 Blog Example</h1>
      <h3>Signup User</h3>
      <SignupUser />
      <h3>Users List</h3>
      <UsersList />
    </Layout>
  )
}

export default IndexPage

Now go back to the Next.js website and try adding a new user and email. You should see that it gets added to the users list just like this:

4. Create a Feed Layout Component

Our blog page will use the Feed Layout twice:

all the published blog posts
all the hidden blog posts

We want to create a FeedList component so that we can display either one based on whether the published boolean that we pass in is true or false.

Create a feed.tsx file and add the following code:

frontend/components/feed.tsx

import React from 'react'
import { Table } from 'antd'
import { FeedQueryComponent } from '../generated/apollo-components'

type Props = {
  published: boolean
}

class FeedList extends React.PureComponent<Props> {
  render() {
    const { published } = this.props
    return (
      <FeedQueryComponent variables={{ published }}>
        {({ loading, error, data }) => {
          if (loading) return <p>Loading...</p>
          if (error) return <p>Error</p>

          if (data && 'feed' in data && data.feed.length > 0) {
            const feedData = data.feed.map(({ id, title, content }, i) => ({
              key: i,
              title,
              content,
              id,
            }))
            const columns = [
              {
                title: 'Title',
                dataIndex: 'title',
                key: 'title',
              },
              {
                title: 'Content',
                dataIndex: 'content',
                key: 'content',
              },
              {
                title: 'Action',
                key: 'action',
                render: () => {
                  return <p>Button Group will go here</p>
                },
              },
            ]
            return <Table columns={columns} dataSource={feedData} />
          }

          return <p>No results yet.</p>
        }}
      </FeedQueryComponent>
    )
  }
}

export default FeedList

The FeedList component looks very similar to the Users component that we already created. We are utilizing the FeedQueryComponent that is autogenerated just like before and now we are going to create a table with 3 columns- title, content and action. The action group will have our buttons for publishing and deleting the posts but we have just stubbed those out for now.

Now modify the index.tsx file in the pages folder to have two instances of the FeedList component- once with the published prop set to true and the second time set to false.

frontend/pages/index.tsx

import * as React from 'react'
import { NextPage } from 'next'
import Layout from '../components/main-layout'
import FeedList from '../components/feed'
import UsersList from '../components/users'
import SignupUser from '../components/signup-user'

const IndexPage: NextPage = () => {
  return (
    <Layout title="Blog Layout">
      <h1>Simple Prisma 2 Blog Example</h1>
      <h3>Create User</h3>
      <SignupUser />
      <h3>Users</h3>
      <UsersList />

      <h3>Feed</h3>
      <FeedList published={true} />
      <h3>Hidden Feed</h3>
      <FeedList published={false} />
    </Layout>
  )
}

export default IndexPage

Now navigate to the Next.js webpage and you should see that it has both Feed components.

5. Create a New Draft Component

Now we will create a New Draft Component so we can make new blog posts. This will be very similar to the SignupUser component that we have already made. The goal here is that when the draft is created, we will see it show up on the unpublished list.

Create a new-draft.tsx file and add the following code:

/frontend/components/new-draft.tsx

import React from 'react'
import { Row, Col, Button, Form, Input } from 'antd'
import {
  CreateDraftMutationComponent,
  FeedQueryDocument,
} from '../generated/apollo-components'

type Props = {}
const initialState = { title: '', content: '', authorEmail: '' }
type State = typeof initialState

class NewDraft extends React.Component<Props> {
  state: State = initialState

  handleChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const { name, value } = event.target
    this.setState({ [name]: value })
  }

  render() {
    return (
      <CreateDraftMutationComponent>
        {createDraft => (
          <Form
            onSubmit={e => {
              e.preventDefault()
              createDraft({
                variables: { ...this.state },
                refetchQueries: [
                  { query: FeedQueryDocument, variables: { published: true } },
                  { query: FeedQueryDocument, variables: { published: false } },
                ],
              }).then(res => {
                console.log(res)
                this.setState({ title: '', content: '', authorEmail: '' })
              })
            }}
          >
            <Row>
              <Col span={6}>
                <Form.Item>
                  <Input
                    placeholder="title"
                    name="title"
                    value={this.state.title}
                    onChange={this.handleChange}
                    type="text"
                  />
                </Form.Item>
              </Col>
              <Col span={6}>
                <Form.Item>
                  <Input
                    placeholder="content"
                    name="content"
                    value={this.state.content}
                    onChange={this.handleChange}
                    type="text"
                  />
                </Form.Item>
              </Col>
              <Col span={6}>
                <Form.Item>
                  <Input
                    placeholder="authorEmail"
                    name="authorEmail"
                    value={this.state.authorEmail}
                    onChange={this.handleChange}
                    type="text"
                  />
                </Form.Item>
              </Col>
              <Col span={6}>
                <Form.Item>
                  <Button htmlType="submit">Create Draft</Button>
                </Form.Item>
              </Col>
            </Row>
          </Form>
        )}
      </CreateDraftMutationComponent>
    )
  }
}

export default NewDraft

The code is very similar to the SignupUser component- we have inputs for title, content, and author email and typing into these fields stores the value in a state which we use as variables in the createDraft mutation when the submit button is pressed.

Note that we are trusting the user to add their email address in the authorEmail field. You would never do this for a real application. You would likely have a user pass a JSON web token (JWT) which would have the user's email encoded inside so that you'd know that you can trust the email you are given. We won't go through how to use JWTs in this example, but this is something that could be added after our application has been completed.

We need to update our index page for a final time to add this NewDraft component.

frontend/pages/index.tsx

import * as React from 'react'
import { NextPage } from 'next'
import Layout from '../components/main-layout'
import FeedList from '../components/feed'
import NewDraft from '../components/new-draft'
import UsersList from '../components/users'
import SignupUser from '../components/signup-user'

const IndexPage: NextPage = () => {
  return (
    <Layout title="Blog Layout">
      <h1>Simple Prisma 2 Blog Example</h1>
      <h3>Create User</h3>
      <SignupUser />
      <h3>Users</h3>
      <UsersList />

      <h3>Create Draft</h3>
      <NewDraft />
      <h3>Feed</h3>
      <FeedList published={true} />
      <h3>Hidden Feed</h3>
      <FeedList published={false} />
    </Layout>
  )
}

export default IndexPage

Now go to the Next.js site and you should see that there is the add draft component. Add a new post, making sure to match the email to the user that you have above and submit it.

You should see that it gets added to the drafts feed list.

6. Create a Publish Draft Button Component

Now that we have a draft, let's publish it! We will create a button that will call a publish mutation with a particular post ID as an input parameter. Our backend will call Prisma 2 which will change that post's published field from false to true.

Create a file called publish-draft.tsx and add the following code:

frontend/components/publish-draft.tsx

import React from 'react'
import { Button } from 'antd'
import {
  PublishMutationComponent,
  FeedQueryDocument,
} from '../generated/apollo-components'

type Props = {
  id: string
}

class PublishDraft extends React.Component<Props> {
  render() {
    const { id } = this.props
    return (
      <PublishMutationComponent>
        {publishDraft => (
          <Button
            onClick={() =>
              publishDraft({
                variables: { id },
                refetchQueries: [
                  { query: FeedQueryDocument, variables: { published: true } },
                  { query: FeedQueryDocument, variables: { published: false } },
                ],
              })
            }
          >
            Publish
          </Button>
        )}
      </PublishMutationComponent>
    )
  }
}

export default PublishDraft

We use an auto generated react component just like before and we nest a button inside the PublishMutationComponent component. When the button is clicked, we will call the publish mutation. We have a refetch query here to fetch both published and non published results to ensure that when a post gets published that both lists get updated.

Now we need to update the feed.tsx file to add the PublishDraft to the Action block. Make sure to import the PublishDraft and Button component at the top of the feed.tsx file.

frontend/components/feed.tsx

import { Table, Button } from 'antd'
import PublishDraft from './publish-draft'
// Lines omitted for brevity
//
{
  title: 'Action',
  key: 'action',
  render: ({ id }: { id: string }) => {
    return (
      <Button.Group>
        {published ? null : <PublishDraft id={id} />}
      </Button.Group>
    );
  }
}

Now when you visit your site, you will see that there is a Publish button next to the post that you created.

Push the publish button and you'll see that it moves from the unpublished to published table. Sweet!

7. Create a Delete Post Button Component

The final component that we have left is to create a delete button for the posts. This button will be very similar to the PublishDraft component that we created. First, create a file called delete-post.tsx and add the following code:

frontend/components/delete-post.tsx

import React from 'react'
import { Button } from 'antd'
import {
  DeleteOnePostComponent,
  FeedQueryDocument,
} from '../generated/apollo-components'

type Props = {
  id: string
}

class DeletePost extends React.Component<Props> {
  render() {
    const { id } = this.props
    return (
      <DeleteOnePostComponent>
        {deleteOnePost => (
          <Button
            type="danger"
            onClick={() =>
              deleteOnePost({
                variables: { id },
                refetchQueries: [
                  { query: FeedQueryDocument, variables: { published: true } },
                  { query: FeedQueryDocument, variables: { published: false } },
                ],
              })
            }
          >
            Delete
          </Button>
        )}
      </DeleteOnePostComponent>
    )
  }
}

export default DeletePost

We are calling the DeleteOnePostComponent component that is autogenerated and we are calling our mutation when the button is clicked. Now that we have the component, we can use it in our FeedList component. Make sure that we import the DeletePost at the top of this file as well.

/frontend/components/feed.tsx

import DeletePost from './delete-post'
// lines omitted for brevity
//
{
  title: 'Action',
  key: 'action',
  render: ({ id }: { id: string }) => {
    return (
      <Button.Group>
        {published ? null : <PublishDraft id={id} />}
        <DeletePost id={id} />
      </Button.Group>
    );
  }
}

Now let's go to our website and we'll see that there is now a delete button. If we press the delete button, it should delete the post.

Before:

After:

So that's it! We've covered all the basics about building a full stack application using Prisma 2 with Next.js in Docker. This configuration is great for development and you shouldn't hesitate to hack on this and build out your own full stack web applications.

Productionize all the things!

For production however, you should make sure to copy your entire code into the docker containers so that you aren't relying on volume mounts for your source code. You'd also likely want to utilize a production ready MySQL instance that has automated backups, scaling, and fault tolerance such as AWS RDS which I've previously discussed how to hook up to Prisma 2. There are numerous other factors to consider when you get to that point though (such as automated deployment with a CI/CD pipeline), but luckily using Docker from the start provides a clear route for productionizing your application in the future.

Video Series for Part III:

Add Main Layout to Next.js

Add Users Component to Next.js

Add Signup User to Next.js

Add Feed Component to Next.js

Add New Blog Draft Component to Next.js

Add Publish Blog Component to Next.js

Add Delete Post Component to Next.js

Originally posted at Code Mochi.

Create a Fullstack Blog App with Next.js, Prisma 2 and Docker- Part II Configure the Frontend

Code Mochi — Wed, 10 Jul 2019 11:32:33 +0000

In this post we are picking up right where we left off in Part I. If you haven't read the first post, you should do that first. As a reminder, we have already built our boilerplate frontend and backend web servers, and dockerized them. In this post we will configure our Frontend server to hook it up with our backend server using Apollo and we will add Ant Design for a nice site layout.

The goal of the first half of this post is to use code generation to create the most difficult React components for us. In order to do that, we need to first specify all the queries and mutations that our frontend will be using. This will include information about which input parameters are needed and which fields we wish to get back from our requests. We will create all of these using graphql files.

Add fragments

First, in order to encourage code reusibility, let's create fragments for our Post and User objects:

/frontend/graphql/fragments/post.gql

fragment PostFragment on Post {
  id
  published
  title
  content
  published
}

/frontend/graphql/fragments/user.gql

fragment UserFragment on User {
  id
  name
  email
}

Add queries

We can use these fragments in our queries and mutations. Let's start by creating our queries first:

/frontend/graphql/queries/feed.gql

#import from '../fragments/post.gql'

query feedQuery($published: Boolean!) {
  feed(published: $published) {
    ...PostFragment
  }
}

/frontend/graphql/queries/post.gql

#import from '../fragments/post.gql'

query postQuery($id: ID!) {
  post(where: { id: $id }) {
    ...PostFragment
  }
}

/frontend/graphql/queries/users.gql

#import from '../fragments/user.gql'

query usersQuery {
  users {
    ...UserFragment
  }
}

Add mutations

Now let's create our mutations:

/frontend/graphql/mutations/createDraft.gql

#import from '../fragments/post.gql'

mutation createDraftMutation(
  $title: String!
  $content: String!
  $authorEmail: String!
) {
  createDraft(title: $title, content: $content, authorEmail: $authorEmail) {
    ...PostFragment
  }
}

/frontend/graphql/mutations/deleteOnePost.gql

#import from '../fragments/post.gql'

mutation deleteOnePost($id: ID!) {
  deleteOnePost(where: { id: $id }) {
    ...PostFragment
  }
}

/frontend/graphql/mutations/publish.gql

#import from '../fragments/post.gql'

mutation publishMutation($id: ID!) {
  publish(id: $id) {
    ...PostFragment
  }
}

/frontend/graphql/mutations/signupUser.gql

#import from '../fragments/user.gql'

mutation signupUserMutation($name: String!, $email: String!) {
  signupUser(data: { name: $name, email: $email }) {
    ...UserFragment
  }
}

2. Add Graphql-Codegen to the frontend

Graphql-Codegen will take in our graphQL queries, mutations, and fragments and query against our backend server to create a generated file that contains React Components for all our possible Apollo operations that we could do with our backend server.

First install the codegen tools:

npm install --save-dev @graphql-codegen/cli @graphql-codegen/typescript @graphql-codegen/typescript-operations @graphql-codegen/typescript-react-apollo graphql

Next, we have to add the codegen file which contains configuration for how the code generation should behave:

frontend/codegen.yml

overwrite: true
schema: 'http://backend:4000/'
documents: graphql/**/*.gql
generates:
  generated/apollo-components.tsx:
    config:
      withHOC: false
      withComponent: true
    plugins:
      - 'typescript'
      - 'typescript-operations'
      - 'typescript-react-apollo'

Finally, add a npm script to the package.json file in our root:

/package.json

"generate": "docker exec -it frontend npm run generate",

and this npm script to your frontend/package.json:

"generate": "gql-gen --config codegen.yml"

Now run npm run generate from the root project. We can see that calling the generate script from the root will execute an npm run script call within our frontend container which will call the gql-gen tool.

Since we created a volume between our frontend app folder and the frontend folder in our computer, any files that are generated in the docker container will make their way to the host. It is for this reason that you should see that there is now a new file frontend/generated/apollo-components.tsx that has all the typescript types, graphql documents, and react components. It is almost 300 lines of code so it is so nice that we don't have go create this. Be sure to run the generate again if you ever add new files to the graphql folder on the frontend so that this file will regenerate for you.

3. Install Apollo and create HOC for Next.js

Within the frontend directory install the following libraries:

npm install --save apollo-boost isomorphic-unfetch react-apollo

Create the frontend/utils/init-apollo.js and frontend/utils/with-apollo-client.js files.

frontend/utils/init-apollo.js

import { ApolloClient, InMemoryCache, HttpLink } from 'apollo-boost'
import fetch from 'isomorphic-unfetch'

let apolloClient = null

function create(initialState) {
  // Check out https://github.com/zeit/next.js/pull/4611 if you want to use the AWSAppSyncClient
  const isBrowser = typeof window !== 'undefined'
  return new ApolloClient({
    connectToDevTools: isBrowser,
    ssrMode: !isBrowser, // Disables forceFetch on the server (so queries are only run once)
    link: new HttpLink({
      uri: isBrowser ? 'http://localhost:4000' : 'http://backend:4000', // Server URL (must be absolute)
      credentials: 'same-origin', // Additional fetch() options like `credentials` or `headers`
      // Use fetch() polyfill on the server
      fetch: !isBrowser && fetch,
    }),
    cache: new InMemoryCache().restore(initialState || {}),
  })
}

export default function initApollo(initialState) {
  // Make sure to create a new client for every server-side request so that data
  // isn't shared between connections (which would be bad)
  if (typeof window === 'undefined') {
    return create(initialState)
  }

  // Reuse client on the client-side
  if (!apolloClient) {
    apolloClient = create(initialState)
  }

  return apolloClient
}

frontend/utils/with-apollo-client.js

import React from 'react'
import initApollo from './init-apollo'
import Head from 'next/head'
import { getDataFromTree } from 'react-apollo'

export default App => {
  return class Apollo extends React.Component {
    static displayName = 'withApollo(App)'
    static async getInitialProps(ctx) {
      const { Component, router } = ctx

      let appProps = {}
      if (App.getInitialProps) {
        appProps = await App.getInitialProps(ctx)
      }

      // Run all GraphQL queries in the component tree
      // and extract the resulting data
      const apollo = initApollo()
      if (typeof window === 'undefined') {
        try {
          // Run all GraphQL queries
          await getDataFromTree(
            <App
              {...appProps}
              Component={Component}
              router={router}
              apolloClient={apollo}
            />
          )
        } catch (error) {
          // Prevent Apollo Client GraphQL errors from crashing SSR.
          // Handle them in components via the data.error prop:
          // https://www.apollographql.com/docs/react/api/react-apollo.html#graphql-query-data-error
          console.error('Error while running `getDataFromTree`', error)
        }

        // getDataFromTree does not call componentWillUnmount
        // head side effect therefore need to be cleared manually
        Head.rewind()
      }

      // Extract query data from the Apollo store
      const apolloState = apollo.cache.extract()

      return {
        ...appProps,
        apolloState,
      }
    }

    constructor(props) {
      super(props)
      this.apolloClient = initApollo(props.apolloState)
    }

    render() {
      return <App {...this.props} apolloClient={this.apolloClient} />
    }
  }
}

These two files are boilerplate code that are taken from Next.js samples of working with Apollo and GraphQL- the first file creates a function that will connect to our backend server in two different ways depending on whether its during the pre-rendering step that occurs on the Next.js server or if it is in the user's browser.

The only change made from the original boilerplate code is that in the create HttpLink, we connect to http://localhost:4000 on the server if we are the browser but if we are in the frontend docker container we actually will connect to http://backend:4000. This is because docker-compose handles networking for us so we don't have to know what the actual IP address of the backend container is within the docker network- we can simply refer to it by a DNS name which is our container name, and docker takes care of the networking for us. Neat!

uri: isBrowser ? 'http://localhost:4000' : 'http://backend:4000',

4. Add React-Apollo to the root of the Next project.

Now that we've created the withApolloClient HOC, we can use it in the _app.tsx file. This is a special file in the pages folder which will run on every page of the Next.js site. This is exactly what we need to ensure that we have Apollo access everywhere.

Create a new file frontend/pages/_app.tsx

import App, { Container } from 'next/app'
import React from 'react'
import withApolloClient from '../utils/with-apollo-client'
import { ApolloProvider } from 'react-apollo'

class MyApp extends App {
  render() {
    // @ts-ignore
    const { Component, pageProps, apolloClient } = this.props
    return (
      <Container>
        <ApolloProvider client={apolloClient}>
          <Component {...pageProps} />
        </ApolloProvider>
      </Container>
    )
  }
}

export default withApolloClient(MyApp)

5. Install Antd for a beautiful site layout

Ant Design is a popular React UI framework that we will be using in this project. It is like Bootstrap but I think that it fits even better into the React landscape because you don't have to install jQuery for modal popups and it just generally has a look that is super clean and doesn't look like every other site out there. First we need to install it in our frontend folder:

npm install --save antd

Then we need to add the css styling to the _app.tsx file. Just add it to the bottom of the depedencies import list:

import 'antd/dist/antd.css'

In Part 3 of this blog post series we will show how to use these Ant Design components to build out all of our React Components so be sure to check back for our final installment.

Video Series for Part II:

Create Queries, Mutations and Fragments for Next.js

Add GraphQL Code Generator

Add Apollo to Next.js

Add Apollo Provider to Next.js

Add Ant Design to Next.js

There is more where that came from!
Click here to give us your email and we'll let you know when we publish new stuff. We respect your email privacy, we will never spam you and you can unsubscribe anytime.

Originally posted at Code Mochi.

Forem: Code Mochi

Migrating NextAuth V3 to V4 with Prisma

Migrate to Prisma v3

Migrate NextAuth v4

What to do if you run into problems

Back to NextAuth v4 migration

Dockerizing Next.js with Prisma for Production Environments

Running Noted: a cryptocurrency tracker locally and in production

Using Finite State Machines to Simplify Frontend User Flow

Corona Examiner- open source virus tracking with Gatsby.js

How to add Auth0 to Nextjs- the Ultimate Guide

5 Reasons why GraphCMS should be your next backend for MVPs

Nested GraphQL Mutations with Prisma 2 Photon

Hot Module Reloading with Next.js Docker development environment in 4 steps

Developer Bliss- Serverless Fullstack React with Prisma 2 and GraphQL

Setup RDS for Serverless Zeit Now Deployments

Create a Fullstack Blog App with Next.js, Prisma 2 and Docker- Part III Build the UI

Table of Contents:

Create a Fullstack Blog App with Next.js, Prisma 2 and Docker- Part II Configure the Frontend

Table of Contents: