DEV Community: Jon

Loading SportsDB into Supabase

Jon — Fri, 22 Jul 2022 11:18:26 +0000

What is SportsDB?

In the real world, data is raw and complex, requiring a relational database to store and model it. One example is a complex dataset like SportDB, a sample dataset compiled from multiple sources, encompassing a variety of sports including football, baseball, ice hockey and more.

SportsDB has been designed to model "Sports Reality" as effectively as possible in a relational database context. The schema inherits from the open SportsML standard, adopting its vocabularies and core approach toward commonalities among the sports. It is capable of supporting queries for the most intense of sports data applications, yet is simple enough for use by those with minimal database experience.

SportsDB contains more than 80000 rows of data and more than 100 tables. It is often used to model a sports betting application, and it has been utilized in research projects dealing with sports data. The figure below shows SportsDB's schema and the relationships between the various entities.

What is Supabase?

Supabase is a backend-as-a-service built on top of PostgreSQL that can handle complex datasets like SportsDB and provide you with insights. Its easy-to-use APIs and superior querying capabilities make it the ideal backend-as-a-service for building today's modern applications. Supabase also natively includes security features like authentication and authorization using Row Level Security (RLS), which means more time can be spent developing your app.

Now let's look at how we can load SportsDB data into Supabase.

Loading SportsDB into Supabase

Supabase is built for developers, and you can get started for free using your existing Github account. Once your Supabase account is set up, you will access the Supabase dashboard. From here, go to All Projects > New Project.

Give your project a name and set the database password. You can also choose the region and adjust the pricing plan based on the requirements of your project. Now click the Create new project button.

Your project will take some time to initialize.

Download the SportsDB dataset using this link. The SportDB dataset consists of four tables: player table, team table, league table, and competition table. The table names are self-explanatory, so it is easy to find the table you want to work with. These four tables are related to one another through keys (IDs) which identify the relationships between them.

To run simple queries, we can use the built-in SQL Editor in the Supabase UI. With more complex queries, you can use psql, a terminal-based tool to work with a Postgres database. To learn how to install psql, check the documentation here.

To establish a connection with Supabase, you need a few details like Host, User, and Password or you can use an existing connection string. All these details can be found under Connection info in the Settings > Database section of our Supabase project page.

Database Information:

Connection String:

Here, we’re using the connection string to connect to the database.

Note: The password for the database will be the password that was provided when we created the project.

Once you are connected to the database, use the below command to load the SportsDB dataset.

\i  <path that has the SQL file>

After executing the command, you should see the SportsDB objects getting created and loaded with data.

This may take some time, but once the data loading is finished, you can verify these newly created tables from your Supabase project page by going to the Table Editor tab. You can see all the newly created tables here.

Now go to the API section on your Project page. Here we can see that Supabase has created all the required REST API endpoints to perform the CRUD operations.

Next, let’s make an HTTP request using cURL using anonymous access (key type as “anon”) for simplicity.

Now copy the required cURL command and run it in your terminal. The output should look like the screenshot below:

Here, we have selected all rows from the affiliations table. Similarly, we can perform all the other CRUD operations using the respective APIs.

Conclusion

Whether you have a simple or complex application, Supabase provides an excellent backend-as-a-service allowing you to build apps more easily and faster. With its inbuilt enterprise features such as authentication, file storage, and autogenerated APIs, you can now free up your time and focus more on building critical business app requirements, without worrying about the data management issues.

Now, become a Supabase developer today by starting a new project on our free tier.

Implementing subscriptions with Stripe

Jon — Wed, 21 Apr 2021 13:37:11 +0000

Project repo

This is our last week building a SaaS project with Next.js, Auth0, Vercel and Stripe. We have covered a lot so far! This week we will focus on implementing subscriptions with Stripe. This will allow our users to gain access to all premium courses while their subscription is active.

Extending User schema

In order to track whether a user is currently subscribed or not, let's extend our Prisma user to contain an isSubscribed field.

// prisma/schema.prisma

model User {
  id Int @id @default(autoincrement())
  email String @unique
  courses Course[]
  stripeId String @unique
  isSubscribed Boolean @default(false)
  createdAt DateTime @default(now())
}

This will be a simple Boolean field to determine whether our user is allowed to see premium content.

When building this feature I initially created a separate subscription model with all the relevant data from Stripe - such as frequency of subscription, next payment date, etc. However, I realised this was just unnecessarily duplicating data that was already available in Stripe, and took a huge amount more code to keep in sync.

Simplifying it down to an isSubscribed field greatly reduced the amount of code I needed to write, and bugs I was trying to iron out. It is also the one piece of data that really matters to my application. All levels of subscription see the same content, therefore, all I need to know is should they be able to see it or not!

Let's create a migration for our new changes.

npx prisma migrate dev --name add-isSubscribed-to-user --preview-feature

Subscription options

From Stripe's dashboard navigate to Products and create the different tiers you would like. I have created one for monthly and one for annual subscriptions.

Next we want to display these options in our Next.js application. I have created a new pricing page, and am using the Stripe library to fetch the prices in getStaticProps. Remember this function is called when we build a new version of our application, so will happen very infrequently.

// pages/pricing.js

import initStripe from 'stripe'

const PricingPage = ({ prices }) => {
  console.log(prices)
  // display prices
}

export const getStaticProps = async () => {
  const stripe = initStripe(process.env.STRIPE_SECRET_KEY)
  const { data: prices } = await stripe.prices.list()

  return {
    props: {
      prices,
    },
  }
}

export default PricingPage

Unfortunately, Stripe's price type does not give us the product name - such as Basic or Pro. We could hard-code this in the frontend, but I would like to be able to change the name of the product in Stripe, and have it automatically flow through to the frontend.

To get the product name we are going to fetch the product for each price and create a new plan object that contains an aggregated collection of the bits of data that we care about from price and product.

// pages/pricing.js

export const getStaticProps = async () => {
  // other stripe stuff

  const productPromises = prices.map(async price => {
    const product = await stripe.products.retrieve(price.product)
    return {
      id: price.id,
      name: product.name,
      price: price.unit_amount,
      interval: price.recurring.interval,
      currency: price.currency,
    }
  })

  const plans = await Promise.all(productPromises)
}

Here we are iterating over each price and creating a new promise (request to Stripe for product). We are then using Promise.all to send all the requests simultaneously and waiting until we get back all of the data.

At the end of this function plans should be an array of aggregated data that looks something like this.

const prices = [
  {
    id: 'price-123',
    name: 'Basic',
    price: 2000,
    interval: 'month',
    currency: 'aud',
  },
  // other pricing options
]

The final file should look something like this.

// pages/pricing.js

import initStripe from 'stripe'

const PricingPage = ({ plans }) => {
  // display plans
}

export const getStaticProps = async () => {
  const stripe = initStripe(process.env.STRIPE_SECRET_KEY)
  const { data: prices } = await stripe.prices.list()

  const productPromises = prices.map(async price => {
    const product = await stripe.products.retrieve(price.product)
    return {
      id: price.id,
      name: product.name,
      price: price.unit_amount,
      interval: price.recurring.interval,
      currency: price.currency,
    }
  })

  const plans = await Promise.all(productPromises)

  return {
    props: {
      plans,
    },
  }
}

export default PricingPage

Creating a subscription

We are going to create a new serverless function to initiate a subscription session. This is going to look very similar to the charge-card function.

// pages/api/subscription/[priceId].js

import initStripe from 'stripe'
import { withApiAuthRequired, getSession } from '@auth0/nextjs-auth0';
import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()
const stripe = initStripe(process.env.STRIPE_SECRET_KEY)

module.exports = withApiAuthRequired(async (req, res) => {
  const { priceId } = req.query
  const { user: { email }} = getSession(req, res);

  const user = await prisma.user.findUnique({
    where: { email },
  })

  await prisma.$disconnect()

  const lineItems = [
    {
      price: priceId,
      quantity: 1,
    },
  ]

  const session = await stripe.checkout.sessions.create({
    customer: user.stripeId,
    mode: 'subscription',
    payment_method_types: ['card'],
    line_items: lineItems,
    success_url: `${process.env.CLIENT_URL}/success`,
    cancel_url: `${process.env.CLIENT_URL}/cancelled`,
    metadata: {
      userId: user.id,
    },
  })

  res.json({ id: session.id })
})

Then we can trigger this from a function anywhere in our frontend.

import { loadStripe } from "@stripe/stripe-js";
import axios from 'axios'

const processSubscription = async (priceId) => {
  const stripe = await loadStripe(process.env.NEXT_PUBLIC_STRIPE_PUBLIC_KEY);
  const { data } = await axios.get(`/api/subscription/${priceId}`);
  await stripe.redirectToCheckout({ sessionId: data.id });
}

Now we need to extend our stripe-hooks API route to listen for the new subscription event. We will need to determine who the Stripe customer is, and update their Prisma record to say they are now subscribed. These will be the lines we are adding.

// pages/api/stripe-hooks

const stripeId = event.data.object.customer

case 'customer.subscription.created':
  if (stripeId) {
    await prisma.user.update({
      where: {
        stripeId,
      },
      data: {
        isSubscribed: true,
      },
    })
  }
  break

The whole file should look something like this.

// pages/api/stripe-hooks

import initStripe from 'stripe'
import { buffer } from 'micro'
import { PrismaClient } from '@prisma/client'

const stripe = initStripe(process.env.STRIPE_SECRET_KEY)
const prisma = new PrismaClient()

export const config = { api: { bodyParser: false } }

export default async (req, res) => {
  const reqBuffer = await buffer(req)
  const signature = req.headers['stripe-signature']
  const signingSecret = process.env.STRIPE_SIGNING_SECRET

  let event

  try {
    event = stripe.webhooks.constructEvent(reqBuffer, signature, signingSecret)
  } catch (err) {
    console.log(err)
    return res.status(400).send(`Webhook Error: ${err.message}`)
  }

  const { metadata } = event.data.object
  const stripeId = event.data.object.customer

  switch (event.type) {
    case 'charge.succeeded':
      if (metadata?.userId && metadata?.courseId) {
        const user = await prisma.user.update({
          where: {
            id: parseInt(metadata.userId)
          },
          data: {
            courses: {
              connect: {
                id: parseInt(metadata.courseId)
              }
            }
          },
        })
      }
      break
    case 'customer.subscription.created':
      if (stripeId) {
        await prisma.user.update({
          where: {
            stripeId,
          },
          data: {
            isSubscribed: true,
          },
        })
      }
      break
    default:
      console.log(`Unhandled event type ${event.type}`)
  }

  res.send({ received: true })
}

We will need to test this through the app again, as we need to know which customer is subscribing.

Great! Now our users should be able to subscribe, but what about when they want to change or cancel their subscription?

Stripe customer portal

Stripe have once again gone above and beyond and created a customer portal for users to manage their payment details and subscriptions. We need to enable this in the Stripe dashboard and tell it what options we would like to be available.

Go to Settings > Billing > Customer Portal and enable whatever you would like the customer to be able to manage.

You will need to create new pages for Terms of Service and a Privacy Policy. Make sure you set this to your production URL, as Stripe does not know what your localhost is.

Now we can create a new serverless function to initiate the customer portal.

// pages/api/customer-portal

import { withApiAuthRequired, getSession } from '@auth0/nextjs-auth0';
import initStripe from 'stripe'
import { PrismaClient } from '@prisma/client'

const stripe = initStripe(process.env.STRIPE_SECRET_KEY)
const prisma = new PrismaClient()

module.exports = withApiAuthRequired(async (req, res) => {
  const { user: { email } } = getSession(req, res);

  const user = await prisma.user.findUnique({
    where: {
      email,
    },
  })

  await prisma.$disconnect()

  const session = await stripe.billingPortal.sessions.create({
    customer: user.stripeId,
    return_url: process.env.CLIENT_URL,
  })

  res.send({
    url: session.url,
  })
})

This returns us the url of the session, so when we write a function to call this in our frontend we need to manually redirect the user to this URL.

import { loadStripe } from '@stripe/stripe-js'
import axios from 'axios'

const loadPortal = async () => {
  const stripe = await loadStripe(process.env.NEXT_PUBLIC_STRIPE_PUBLIC_KEY)
  const { data } = await axios.get('/api/customer-portal')
  window.location.href = data.url
}

Great, now our users can manage their own payment and subscription settings, but how do we know they have updated or cancelled their subscription?

WEBHOOKS!

Add events to webhook

This logic should look very similar to customer.subscription.created. We just want to update the Prisma user with that Stripe ID to have isSubscribed set to true if they are updating their subscription and false if they're unsubscribing. These are the lines we will be adding.

// pages/api/stripe-hooks

case 'customer.subscription.updated':
  if (stripeId) {
    await prisma.user.update({
      where: {
        stripeId,
      },
      data: {
        isSubscribed: true,
      },
    })
  }
  break
case 'customer.subscription.deleted':
  await prisma.user.update({
    where: {
      stripeId,
    },
    data: {
      isSubscribed: false,
    },
  })
  break

The whole file should look something like this.

// pages/api/stripe-hooks

import initStripe from 'stripe'
import { buffer } from 'micro'
import { PrismaClient } from '@prisma/client'

const stripe = initStripe(process.env.STRIPE_SECRET_KEY)
const prisma = new PrismaClient()

export const config = { api: { bodyParser: false } }

export default async (req, res) => {
  const reqBuffer = await buffer(req)
  const signature = req.headers['stripe-signature']
  const signingSecret = process.env.STRIPE_SIGNING_SECRET

  let event

  try {
    event = stripe.webhooks.constructEvent(reqBuffer, signature, signingSecret)
  } catch (err) {
    console.log(err)
    return res.status(400).send(`Webhook Error: ${err.message}`)
  }

  const { metadata } = event.data.object
  const stripeId = event.data.object.customer

  switch (event.type) {
    case 'charge.succeeded':
      if (metadata?.userId && metadata?.courseId) {
        const user = await prisma.user.update({
          where: {
            id: parseInt(metadata.userId)
          },
          data: {
            courses: {
              connect: {
                id: parseInt(metadata.courseId)
              }
            }
          },
        })
      }
      break
    case 'customer.subscription.created':
      if (stripeId) {
        await prisma.user.update({
          where: {
            stripeId,
          },
          data: {
            isSubscribed: true,
          },
        })
      }
      break
    case 'customer.subscription.updated':
      if (stripeId) {
        await prisma.user.update({
          where: {
            stripeId,
          },
          data: {
            isSubscribed: true,
          },
        })
      }
      break
    case 'customer.subscription.deleted':
      if (stripeId) {
        await prisma.user.update({
          where: {
            stripeId,
          },
          data: {
            isSubscribed: false,
          },
        })
      }
      break
    default:
      console.log(`Unhandled event type ${event.type}`)
  }

  res.send({ received: true })
}

Great, we should now get notified from Stripe anytime a user updates or cancels their subscription via the customer portal, so we can stop showing them premium courses, other than those they have purchased directly.

The customer.subscription.deleted event is triggered when the user's subscription expires, not when they click cancel. Depending on the configuration you set in your customer portal settings, this is likely at the end of the period they have already paid for.

We can test this is working through the Stripe dashboard by going to Customers > Subscriptions, clicking the more options dots and selecting "cancel subscription".

If we select cancel immediately the event should be triggered, our serverless function should be called and our Prisma user should be updated.

This requires the stripe forward command and our next.js dev server to be running.

Production webhooks

Great, now we have this running in development mode but what about our production app?

Head on over to the Stripe dashboard and select Developers > Webhooks, and add an endpoint. Here we can tell it which URL to send events to, and which events we actually care about.

Now within our endpoint dashboard we can copy our signing secret.

And follow the steps from Hosting on Vercel, automatic deploys with GitHub and configuring custom domains to add a new secret in Vercel.

Awesome! Now our stripe-hooks function will work in prod too! So how do we actually restrict the user from seeing the premium content in the app?

Gate the premium content

So we have setup all this complicated backend stuff to know when the user has purchased a course and whether or not they have an active subscription, but we haven't actually enforced this in the frontend. There are many ways we can do this but the main thing you should keep in mind is:

YOU CANNOT TRUST THE CLIENT!

A good way to ensure that only premium users can see premium content, is determine what they are allowed to see on the server, and only return the bits for that particular user. An example of this is if I had a video URL link that I only wanted users who have paid to be able to see then I should do that check in getServerSideProps and only return the videoUrl field if they have an active subscription or have paid for this particular course.

export const getServerSideProps = withPageAuthRequired({
  async getServerSideProps({req, params}) {
    // fetch course and user from Prisma

    const userIsAllowed = course.price === 0 || user.isSubscribed || user.courses.find(course => course.id === lesson.course.id)

    if (!userIsAllowed) {
      course.videoUrl = null
    }

    return {
      props: {
        course
      }
    }
  }
})

Then in the page component itself you could display a video element if they're allowed to view this content, or a buy/subscribe button if they're not.

const CoursePage = ({ course }) => course.videoUrl ? (
  <video src={course.videoUrl} />
) : (
  <button onClick={handleBuy}>Buy course</button>
)

export default CoursePage

A more comprehensive example of this logic can be seen in the Lesson component.

Wrapping up

That's it! We did it! We built a SaaS project in six weeks using Next.js, Prisma, Auth0 and Stripe. Check out the project repo for a more complete working application. What now?

I recommend you take what was covered in this blog series and try to implement something similar but a little bit different. Following steps in a tutorial is a great way to get an understanding of what you can do with a particular library or technology, but the real learning comes from trying to do something you want to do and running into problems!

Processing payments with Stripe and webhooks

Jon — Wed, 21 Apr 2021 13:36:11 +0000

Project repo

This week is all about taking payments with Stripe. We will implement a serverless function to charge a card and implement webhooks to update our Prisma user with courses they have purchased.

Extending User schema

In order to track which courses a user has purchased we will need to extend our User schema to contain a field for stripeId.

// prisma/schema.prisma

model User {
  id Int @id @default(autoincrement())
  email String @unique
  courses Course[]
  stripeId String @unique
  createdAt DateTime @default(now())
}

This will be used to map a Prisma user to a Stripe customer.

This modification will temporarily break our application as a stripeId is now a required field, and we are not setting one when we create a user in our application.

Let's create a migration to apply these changes to our DB.

npx prisma migrate dev --name add-stripe-id-to-user --preview-feature

Setting up Stripe

First thing you will need to do is create a Stripe account.

Once you have created an account and have landed on your Stripe dashboard, you will need to enter your business's details in order to activate your account. This will give you access to production API keys and allow you to process real payments. You do not need to activate your account to complete this series, but something you may want to do if you want to use this in the real world!

Next we need to install the two Stripe libraries in our application.

npm i stripe @stripe/stripe-js

stripe is a backend library that we will use to process payments, and @stripe/stripe-js is a frontend library that our client will use to initiate a payment session.

Now we need to modify our .env file to add our new API keys - these can be found in the Stripe dashboard under the "Get your API keys" panel. Make sure you use the "test" keys for local development.

// .env

// other secrets
STRIPE_SECRET_KEY=your-secret-key
NEXT_PUBLIC_STRIPE_PUBLIC_KEY=your-publishable-key

We must prepend frontend environment variables with NEXT_PUBLIC_. Variables that do not contain this will only be available to our serverless fuctions.

Follow the same logic from Hosting on Vercel, automatic deploys with GitHub and configuring custom domains to add secrets in Vercel - without this our hosted application will not work.

Great! Now we should have stripe wired up!

Create Stripe customer

We will need to create a Stripe customer to keep a track of purchases and whether a subscription is active. We could do this when the user makes their first purchase, however, we do not know whether that will be when they purchase a particular course or activate their subscription. This would require us to add some logic to each of our payment scenarios to first check if a stripe user exists before charging their account. We can simplify this logic greatly by just creating a Stripe customer at the same time as our Prisma user - the first time a new user signs in to our application.

Let's modify our auth hook to create a stripe customer before we create a user in Prisma. That way we can use the newly created Stripe ID to create our user.

// pages/api/auth/hooks.js

// other imports
import initStripe from 'stripe'
const stripe = initStripe(process.env.STRIPE_SECRET_KEY)

module.exports = async (req, res) => {
  // other auth code
  const customer = await stripe.customers.create({
    email,
  })
  const user = await prisma.user.create({
    data: { email, stripeId: customer.id },
  })
}

The whole file should look something like this.

// pages/api/auth/hooks.js

import { PrismaClient } from '@prisma/client'
import initStripe from 'stripe'

const prisma = new PrismaClient()
const stripe = initStripe(process.env.STRIPE_SECRET_KEY)

module.exports = async (req, res) => {
  try {
    const { email, secret } = JSON.parse(req.body)
    if (secret === process.env.AUTH0_HOOK_SECRET) {
      const customer = await stripe.customers.create({
        email,
      })
      const user = await prisma.user.create({
        data: { email, stripeId: customer.id },
      })
      console.log('created user')
    } else {
      console.log('You forgot to send me your secret!')
    }
  } catch (err) {
    console.log(err)
  } finally {
    await prisma.$disconnect()
    res.send({ received: true })
  }
}

Great, now anytime a new user signs in we should be creating a Stripe customer, then a Prisma user that has a reference to the customer's ID.

Charging a card with Stripe

Now we want to build a serverless function that can process a payment for a particular course. We will need to tell this function which course the user is purchasing, so will use a Dynamic API Route to pass in the course ID. Let's create a new serverless function at /pages/api/charge-card/[courseId].js.

// pages/api/charge-card/[courseId].js

module.exports = async (req, res) => {
  const { courseId } = req.query
  res.send(`charging card for course ${courseId}`)
}

You can trigger this serverless function by going to http://localhost:3000/api/charge-card/any-value-you-want. In this case it should print out "charging card for course any-value-you-want.

The next step would be working out how much we need to charge for the course. We could just pass this along with the request from the frontend, however, this could easily be tinkered with by the user.

We can't trust anything from the client!

Let's make a call to our Prisma DB to find out the real price.

// pages/api/charge-card/[courseId].js

import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

module.exports = async (req, res) => {
  const { courseId } = req.query

  const course = prisma.course.findUnique({
    where: {
      id: parseInt(courseId),
    },
  })

  await prisma.$disconnect()

  res.send(`charging ${course.price} cents for ${courseId}`)
}

We use parseInt() here to turn the string we get from the req's query into an integer, which Prisma is expecting for the ID.

Next we want to know who the user is that is purchasing this course. This means we want the API route to only be accessible by logged in users. Let's wrap it in withApiAuthRequired and work out who the user is by their session email.

// pages/api/charge-card/[courseId].js

import { PrismaClient } from '@prisma/client'
import { withApiAuthRequired, getSession } from '@auth0/nextjs-auth0';

const prisma = new PrismaClient()

module.exports = withApiAuthRequired(async (req, res) => {
  const { courseId } = req.query
  const { user: { email } } = getSession(req, res)

  const course = prisma.course.findUnique({
    where: {
      id: parseInt(courseId),
    },
  })

  const user = await prisma.user.findUnique({
    where: {
      email,
    },
  })

  await prisma.$disconnect()

  res.send(`charging ${user.email} ${course.price} cents for ${courseId}`)
})

Next we want to tell Stripe what we are actually charging the customer. We do this by creating a list of line items and a payment session.

// pages/api/charge-card/[courseId].js

//other imports
import initStripe from 'stripe'

const stripe = initStripe(process.env.STRIPE_SECRET_KEY)

module.exports = async (req, res) => {
  // course and user stuff

  const lineItems = [
    {
      price_data: {
        currency: 'aud', // swap this out for your currency
        product_data: {
          name: course.title,
        },
        unit_amount: course.price,
      },
      quantity: 1,
    },
  ]

  const session = await stripe.checkout.sessions.create({
    customer: user.stripeId,
    payment_method_types: ['card'],
    line_items: lineItems,
    mode: 'payment',
    success_url: `${process.env.CLIENT_URL}/success`,
    cancel_url: `${process.env.CLIENT_URL}/cancelled`,
  })

  res.json({ id: session.id })
})

We need to provide a success and cancel url for stripe to forward the user to. These will need to be created at pages/success.js and pages/cancelled.js. Additionally, we need to create an environment variable for CLIENT_URL. Follow the previous steps to add this to the .env with the value http://localhost:3000, and a new secret in Vercel with the value of whatever your hosted URL is - mine is https://courses-saas.vercel.app.

Lastly we want to wrap all of this in a try/catch block in case something goes wrong. The whole file should look something like this.

// pages/api/charge-card/[courseId].js

import { withApiAuthRequired, getSession } from '@auth0/nextjs-auth0';
import { PrismaClient } from '@prisma/client'
import initStripe from 'stripe'

const prisma = new PrismaClient()
const stripe = initStripe(process.env.STRIPE_SECRET_KEY)

module.exports = withApiAuthRequired(async (req, res) => {
  try {
    const { courseId } = req.query
    const { user: { email } } = getSession(req, res)

    const course = prisma.course.findUnique({
      where: {
        id: parseInt(courseId),
      },
    })

    const user = await prisma.user.findUnique({
      where: {
        email,
      },
    })

    const lineItems = [
      {
        price_data: {
          currency: 'aud', // swap this out for your currency
          product_data: {
            name: course.title,
          },
          unit_amount: course.price,
        },
        quantity: 1,
      },
    ]

    const session = await stripe.checkout.sessions.create({
      customer: user.stripeId,
      payment_method_types: ['card'],
      line_items: lineItems,
      mode: 'payment',
      success_url: `${process.env.CLIENT_URL}/success`,
      cancel_url: `${process.env.CLIENT_URL}/cancelled`,
    })

    res.json({ id: session.id })
  } catch (err) {
    res.send(err)
  } finally {
    await prisma.$disconnect()
  }
})

Next we need to add a function in our frontend to trigger this payment. This block can be triggered from a button click anywhere in the app, and just needs to be passed a course ID to initiate the payment with Stripe.

import { loadStripe } from "@stripe/stripe-js";
import axios from 'axios'

const processPayment = async (courseId) => {
  const stripe = await loadStripe(process.env.NEXT_PUBLIC_STRIPE_PUBLIC_KEY);
  const { data } = await axios.get(`/api/charge-card/${courseId}`);
  await stripe.redirectToCheckout({ sessionId: data.id });
}

Lastly, we want to know when a course has been purchased so that we can update our user in Prisma. This is made possible by Stripe's webhooks. Similarly to our Auth0 hook, we can subscribe to particular events, and when that happens Stripe will call our serverless function and tell us which user purchased a particular course.

We get a lot of data from Stripe about the transaction itself, but not which course or Prisma user. Let's modify our charge-card function to pass this across as metadata with the session.

// pages/api/charge-card/[courseId].js

const session = await stripe.checkout.sessions.create({
  // other session stuff

  payment_intent_data: {
    metadata: {
      userId: user.id,
      courseId,
    },
  },
})

The whole file should look something like this.

// pages/api/charge-card/[courseId].js

import { withApiAuthRequired, getSession } from '@auth0/nextjs-auth0';
import { PrismaClient } from '@prisma/client'
import initStripe from 'stripe'

const prisma = new PrismaClient()
const stripe = initStripe(process.env.STRIPE_SECRET_KEY)

module.exports = withApiAuthRequired(async (req, res) => {
  try {
    const { courseId } = req.query
    const { user: { email } } = getSession(req, res)

    const course = prisma.course.findUnique({
      where: {
        id: parseInt(courseId),
      },
    })

    const user = await prisma.user.findUnique({
      where: {
        email,
      },
    })

    const lineItems = [
      {
        price_data: {
          currency: 'aud', // swap this out for your currency
          product_data: {
            name: course.title,
          },
          unit_amount: course.price,
        },
        quantity: 1,
      },
    ]

    const session = await stripe.checkout.sessions.create({
      customer: user.stripeId,
      payment_method_types: ['card'],
      line_items: lineItems,
      mode: 'payment',
      success_url: `${process.env.CLIENT_URL}/success`,
      cancel_url: `${process.env.CLIENT_URL}/cancelled`,
      payment_intent_data: {
        metadata: {
          userId: user.id,
          courseId,
        },
      },
    })

    res.json({ id: session.id })
  } catch (err) {
    res.send(err)
  } finally {
    await prisma.$disconnect()
  }
})

Now we can create an API route that can deal with these events from Stripe.

// pages/api/stripe-hooks

export default async (req, res) => {
  // check what kind of event stripe has sent us
  res.send({ received: true })
}

So that we don't get ourselves into the same problem we had with Auth0 Hooks, let's implement a signing secret to confirm that the request is coming from Stripe.

Let's first install the Stripe CLI to be able to simulate a webhook event. If you have macOS and homebrew installed, we can run this command.

brew install stripe/stripe-cli/stripe

Now run the following to authenticate the CLI with Stripe.

stripe login

Now we should be able to run the following to forward webhook events to our localhost.

stripe listen --forward-to localhost:3000/api/stripe-hooks

This will print out a signing secret to the terminal. Copy this into your .env file with the name STRIPE_SIGNING_SECRET.

// .env

// other secrets
STRIPE_SIGNING_SECRET=your-webhook-signing-secret

Stripe provides a handy helper function called constructEvent that can confirm whether this request was sent from them. Unfortunately, there is a little bit of tinkering we need to do to get this working in Next.js. Here is a really good guide that steps through the process.

Let's start by installing micro.

npm i micro

Now we can update our stripe-hooks API route to validate the request is coming from Stripe.

// pages/api/stripe-hooks

import initStripe from 'stripe'
import { buffer } from 'micro'

const stripe = initStripe(process.env.STRIPE_SECRET_KEY)

export const config = { api: { bodyParser: false } }

export default async (req, res) => {
  const reqBuffer = await buffer(req)
  const signature = req.headers['stripe-signature']
  const signingSecret = process.env.STRIPE_SIGNING_SECRET

  let event

  try {
    event = stripe.webhooks.constructEvent(reqBuffer, signature, signingSecret)
  } catch (err) {
    console.log(err)
    return res.status(400).send(`Webhook Error: ${err.message}`)
  }

  // check what kind of event stripe has sent us

  res.send({ received: true })
}

The req object from Vercel is not structured the way Stripe is expecting, so does not validate properly unless we do a bit of work.

stripe.webhooks.constructEvent() is a function that Stripe recommends using to confirm that they have sent this request. If it can validate this then it returns the Stripe event, otherwise it will throw an exception, and we will return a 400 status code. Read more here.

Okay, so now we can forget all about that validation and focus on processing the event we are receiving from Stripe.

// pages/api/stripe-hooks

export default async (req, res) => {
  // signing logic

  switch (event.type) {
    case 'charge.succeeded':
      // update user in prisma
      console.log('charge succeeded')
      break
    default:
      console.log(`Unhandled event type ${event.type}`)
  }
}

event.type will contain a string for the event that has been triggered. We will extend this later for subscriptions so are using a case statement to keep it clear.

We can test that this is working by running the following command in a new terminal window - this requires the stripe listen and npm run dev commands to be running.

stripe trigger charge.succeeded

This should print out "charge succeeded" to the console.

Next we need to pull the user and course ID out of the metadata, and update the user's courses they have purchased in Prisma.

// pages/api/stripe-hooks

import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

export default async (req, res) => {
  // signing logic

  const { metadata } = event.data.object

  switch (event.type) {
    case 'charge.succeeded':
      // update user in prisma
      if (metadata?.userId && metadata?.courseId) {
        const user = await prisma.user.update({
          where: {
            id: parseInt(metadata.userId)
          },
          data: {
            courses: {
              connect: {
                id: parseInt(metadata.courseId)
              }
            }
          },
        })
      }
      break
    default:
      console.log(`Unhandled event type ${event.type}`)
  }
}

connect is used to insert an existing course ID into the array of courses for the user. If we wanted to create this course then we would use create.

The full file should look something like this.

// pages/api/stripe-hooks

import initStripe from 'stripe'
import { buffer } from 'micro'
import { PrismaClient } from '@prisma/client'

const stripe = initStripe(process.env.STRIPE_SECRET_KEY)
const prisma = new PrismaClient()

export const config = { api: { bodyParser: false } }

export default async (req, res) => {
  const reqBuffer = await buffer(req)
  const signature = req.headers['stripe-signature']
  const signingSecret = process.env.STRIPE_SIGNING_SECRET

  let event

  try {
    event = stripe.webhooks.constructEvent(reqBuffer, signature, signingSecret)
  } catch (err) {
    console.log(err)
    return res.status(400).send(`Webhook Error: ${err.message}`)
  }

  const { metadata } = event.data.object

  switch (event.type) {
    case 'charge.succeeded':
      // update user in prisma
      if (metadata?.userId && metadata?.courseId) {
        const user = await prisma.user.update({
          where: {
            id: parseInt(metadata.userId)
          },
          data: {
            courses: {
              connect: {
                id: parseInt(metadata.courseId)
              }
            }
          },
        })
      }
      break
    default:
      console.log(`Unhandled event type ${event.type}`)
  }

  res.send({ received: true })
}

Now we should have a complete solution where we can trigger a payment for a particular course in our app - we need to do it from the app, rather than the CLI so that it includes our metadata. This will make a request to our charge-card serverless function to create a payment session for that course. The user should then be taken to Stripe's UI where they can enter their credit card details, and then be redirected to our success page after they have been charged. In the background Stripe will call our webhook serverless function, which will update our Prisma user with the newly purchased course!

Amazing! And our app doesn't need to know anything about our users' credit card details!

The Stripe documentation is fantastic and I highly recommend checking out all the awesome things you can do beyond what we cover in this series!

Next week

Implementing subscriptions with Stripe

Social login with GitHub and Auth0 rules

Jon — Wed, 21 Apr 2021 13:35:11 +0000

Project repo

This week we look at using Auth0's social signon to authenticate with GitHub. We also setup webhooks to create a local user in our Prisma database anytime a new user logs into Auth0.

Social login with GitHub

Enabling different social providers is super simple with Auth0. Follow this guide to configure a range of social providers - Google, Facebook, Twitter etc. I am just going to setup GitHub.

By default Auth0 has local username and password configured. Disable this to enforce only signing in with social providers.

Auth0 Hooks

We are going to setup a webhook that sends a request to one of our serverless functions anytime a new user logs into Auth0. We can create a Rule in Auth0 to do this.

async function (user, context, callback) {
  // do some stuff
  callback(null, user, context);
}

Rules are serverless functions that Auth0 will call anytime a user logs in

Auth0 tells us who the user signing in is, gives us a context object with additional data and a callback function that we can invoke to continue the sign in process.

The first parameter the callback expects is an error. If this is null or undefined it will continue the sign in process. If this parameter is any truthy value it will throw an exception and stop the sign in process.

If we do not invoke the callback function the sign in process will eventually timeout.

Let's setup a new API route in our Next.js application to handle the request from the Auth0 hook.

// pages/api/auth/hooks.js

module.exports = async (req, res) => {
  const { email } = JSON.parse(req.body)
  // create user in prisma
  console.log('created user')
  res.send({ received: true })
}

We need to call res.send so that the hook receives a 200 status code and can keep going with the sign in process.

Now let's update our Auth0 hook to send a request to our new endpoint. We will provide the user's email as the body of our request.

async function (user, context, callback) {
  await request.post('http://localhost:3000/api/auth/hooks', {
    body: JSON.stringify({
      email: user.email,
    })
  });

  callback(null, user, context);
}

Auth0 hooks like semicolons - you can choose what you prefer elsewhere but probably best to put them in here!

Now let's trigger the hook by signing in with our Next.js application.

ERROR!

The problem is that this Auth0 hook is running on some remote Auth0 server, not our local machine. Therefore, it has no idea what localhost is. Ngrok to the rescue!

Ngrok

This is a tool that forwards a public URL on the internet through to a specific port running on localhost (our Next.js dev server). This is often referred to as tunneling.

We can install it using npm.

npm i -g ngrok

And then forward it to port :3000.

ngrok http 3000

This should give you a URL that you can use to replace "http://localhost:3000" in our Auth0 hook request.

async function (user, context, callback) {
  await request.post('https://0d4d01c96799.au.ngrok.io/api/auth/hooks', {
    body: JSON.stringify({
      email: user.email,
    })
  });
  callback(null, user, context);
}

Now you should be able to trigger a request to our new API route by going through the sign in flow with the Next.js app.

Remember to set this to your production URL when you deploy your app!

You should see this logging out "created user" to the terminal console, but we're not yet doing that. Let's create a new user in Prisma.

// pages/api/auth/hooks.js

import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()

module.exports = async (req, res) => {
  const { email } = JSON.parse(req.body)

  const user = await prisma.user.create({
    data: { email },
  })

  await prisma.$disconnect()

  console.log('created user')
  res.send({ received: true })
}

Let's wrap that in a try, catch block just so that if we fail to create a user we still send a response to the hook and don't hold up the auth process.

// pages/api/auth/hooks.js

import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()

module.exports = async (req, res) => {
  try {
    const { email } = JSON.parse(req.body)
    const user = await prisma.user.create({
      data: { email },
    })
    console.log('created user')
  } catch (err) {
    console.log(err)
  } finally {
    await prisma.$disconnect()
    res.send({ received: true })
  }
}

The finally block will run regardless of whether we successfully created a user or an exception was thrown. Writing cleanup logic here helps DRY up our code.

This should now be creating a new user in Prisma every time a user logs in. Wait, EVERY SINGLE TIME?!?! that's no good!

Problem 1: New user every single login!

Lucky we haven't pushed anything to prod. This one could have cost us some money in a high traffic application!

We only want to create a user the first time time they login, therefore, we need some way to know whether we have successfully created a user in the past. We could expose another API route to ping the Prisma database and make sure a user with this email does not yet exist, but this would require another trip from Auth0 servers across to Vercel. We don't want to keep our user waiting unnecessarily.

Thankfully, Auth0 give us the ability to set metadata on our user.

We can set the metadata after creating the user like this.

user.app_metadata = user.app_metadata || {};
user.app_metadata.localUserCreated = true;

We need to manually tell Auth0 to persist this metadata like this.

await auth0.users.updateAppMetadata(user.user_id, user.app_metadata);

And can read the metadata to make sure we want to create a user like this.

if (!user.app_metadata.localUserCreated) {
  // create prisma user
}

The full rule should look something like this.

async function (user, context, callback) {
  user.app_metadata = user.app_metadata || {};

  if (!user.app_metadata.localUserCreated) {
    await request.post('https://0d4d01c96799.au.ngrok.io/api/auth/hooks', {
      body: JSON.stringify({
        email: user.email,
      })
    });
    user.app_metadata.localUserCreated = true;
    await auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
  }
  callback(null, user, context);
}

Let's also wrap that in a try catch block to make sure we respond if an exception is thrown.

async function (user, context, callback) {
  try {
    user.app_metadata = user.app_metadata || {};

    if (!user.app_metadata.localUserCreated) {
      await request.post('https://0d4d01c96799.au.ngrok.io/api/auth/hooks', {
        body: JSON.stringify({
          email: user.email,
        })
      });
      user.app_metadata.localUserCreated = true;
      await auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
    }
    callback(null, user, context);
  } catch (err) {
    callback(err);
  }
}

Great! So now anytime a user signs in and we do not have an account in prisma it will call our API route to create a user.

WAIT! Do we just have an open API route that will create a user anytime we send a request to it?!? That's no good! How do we know this is coming from Auth0?!?

Problem 2: Our API Route to deal with authentication is not authenticated!

Okay, there are a few ways we could solve this. You might think "isn't that what we have that Auth0 library for? Just wrap it in that withApiAuthRequired function you were raving about!"

Since this is coming from Auth0, and not our Next.js app the session does not actually exist!

We will need to manually send a secret value from the Auth0 hook and validate it is present and correct in the API route. This is a similar solution to something like API keys that map to a particular user.

In the Rules menu we can create a new secret.

I recommend setting the value to a long randomly generated string.

Now we can access that value in our Auth0 Hook like this.

configuration.AUTH0_HOOK_SECRET

Let's post this across with our request to the API route.

async function (user, context, callback) {
  try {
    user.app_metadata = user.app_metadata || {};

    if (!user.app_metadata.localUserCreated) {
      await request.post('https://0d4d01c96799.au.ngrok.io/api/auth/hooks', {
        body: JSON.stringify({
          email: user.email,
          secret: configuration.AUTH0_HOOK_SECRET,
        })
      });
      user.app_metadata.localUserCreated = true;
      await auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
    }
    callback(null, user, context);
  } catch (err) {
    callback(err);
  }
}

Now we need to update our Next.js app's .env file to contain this value.

// .env

// other secrets
AUTH0_HOOK_SECRET=that-super-secret-value-that-no-one-else-knows

And wrap our create user logic in a check to make sure that value is correct.

const { email, secret } = JSON.parse(req.body)

if (secret === process.env.AUTH0_HOOK_SECRET) {
  // create user
} else {
  console.log('You forgot to send me your secret!')
}

The whole API route should look something like this.

// pages/api/auth/hooks.js

import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()

module.exports = async (req, res) => {
  try {
    const { email, secret } = JSON.parse(req.body)
    if (secret === process.env.AUTH0_HOOK_SECRET) {
      const user = await prisma.user.create({
        data: { email },
      })
      console.log('created user')
    } else {
      console.log('You forgot to send me your secret!')
    }
  } catch (err) {
    console.log(err)
  } finally {
    await prisma.$disconnect()
    res.send({ received: true })
  }
}

Follow the same logic from Hosting on Vercel, automatic deploys with GitHub and configuring custom domains to add our new Auth0 secrets in Vercel - without this our hosted application will not work.

Excellent! That's it! We did it!

Now anytime a new user logs into our Next.js application, Auth0 will let us know so we can create a user in our Prisma database, to keep a track of those extra bits of data that our application cares about!

Next week

Processing payments with Stripe and webhooks

Authentication with Auth0 and Next.js

Jon — Wed, 21 Apr 2021 13:34:11 +0000

Project repo

This week was all about users and authentication! The point of our SaaS project is to offer courses that can be purchased individually, or a recurring subscription that unlocks access to everything. In order to accomplish this we need to know some things about the user!

Auth0

Given my limited experience with complex auth solutions, I wanted to lean on a third-party service as much as possible. Ideally I want all that complexity abstracted away so I can focus on building really good content - the product I am actually selling!

One of the big benefits of Next.js, over something like Gatsby or a custom React application, is that we have access to a server at runtime. This means we can validate who the user is and what they should see - something we can't really trust on the client.

There are numerous auth options compatible with Next.js, varying greatly in amount of code you need to write. My key requirements were:

Social login - GitHub
No need to write session cookie logic
Convenient functions to lock down pages and API routes

Essentially I just want to be able to ask a library "should I show the thing?" and it give me an answer I can trust!

Auth0 have done just that with an amazing library specifically for Next.js - very creatively called nextjs-auth0. This allows you to use the power of Auth0 to manage account creation, logging in and out, session cookies etc, and provides a simple set of functions that you can use to created gated content.

First thing we need to do is create a free auth0 account and a tenant, which can be used to group together applications that share a user database. Here is a good guide to get this setup.

Next we need to install and configure @auth0/nextjs-auth0 in our project. The README steps through exactly what we need to do to accomplish this!

Remember to follow the same steps from Hosting on Vercel, automatic deploys with GitHub and configuring custom domains to add all those Auth0 secrets to Vercel - without this our hosted application will not work.

This gives us access to some super awesome helper functions, my favourite of which are:

withPageAuthRequired

This is a client-side function that we can use to wrap protected pages that we only want the user to be able to visit if they have logged in. If they are not logged in they will be redirected to the auth0 sign in page. Simply wrap the page-level component in this function like so.

// pages/dashboard.js

import { withPageAuthRequired } from '@auth0/nextjs-auth0';

const Dashboard = withPageAuthRequired(({ user }) => {
  return <p>Welcome {user.name}</p>
})

export default Dashboard

useUser

This is a client-side React Hook we can use to get the user object anywhere in any of our components.

// pages/index.js

import { useUser } from '@auth0/nextjs-auth0';

const Home = () => {
  const { user, error, isLoading } = useUser();

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

  if (user) {
    return (
      <div>
        Welcome {user.name}! <a href="/api/auth/logout">Logout</a>
      </div>
    );
  }
  return <a href="/api/auth/login">Login</a>;
};

export default Home

withPageAuthRequired

This is a serverside function that we can wrap around Next.js' getServerSideProps to ensure the user cannot visit a page unless logged in.

// pages/dashboard.js

import { withPageAuthRequired } from '@auth0/nextjs-auth0';

const Dashboard = ({ user }) => {
  return <div>Hello {user.name}</div>;
}

export const getServerSideProps = withPageAuthRequired();

export default Dashboard

withApiAuthRequired

This is a serverside function that we can wrap around our API route to ensure that only an authenticated user can send a request to it.

// pages/api/courses.js

import { withApiAuthRequired, getSession } from '@auth0/nextjs-auth0';

module.exports = withApiAuthRequired(async (req, res) => {
  const { user } = getSession(req, res)

  // validate user can view courses

  res.send(courses)
})

User Schema

Auth0 is fantastic for logging a user in and validating that their session is valid, however, if we want to keep a track of other information - such as courses purchased - we will need to create a user in our Prisma db.

Let's extend our schema by adding a user model.

// prisma/schema.prisma

model User {
  id Int @id @default(autoincrement())
  email String @unique
  courses Course[]
  createdAt DateTime @default(now())
}

We will use the email from Auth0 to determine who our user is, therefore, it will need to be unique.

We will also add a list of users to each course.

// prisma/schema.prisma

model Course {
  id Int @id @default(autoincrement())
  title String @unique
  description String
  lessons Lesson[]
  users User[]
  createdAt DateTime @default(now())
}

Next we're going to use Prisma's migration API to capture the changes to the structure of our database.

npx prisma migrate dev --name create-user-schema --preview-feature

This is creating a new migration with the name "create-user-schema" and we need to append "--preview-feature" as this is still experimental.

This may prompt you with some questions about overwriting existing data. Select YES.

If it cannot apply the migration you can try resetting your database - this will drop the entire db so make sure you don't run it without thinking later!

npx prisma migrate reset --preview-feature

Next let's add a price and URL slug to our course schema.

// prisma/schema.prisma

model Course {
  id Int @id @default(autoincrement())
  title String @unique
  description String
  lessons Lesson[]
  users User[]
  price Int
  slug String @unique
  createdAt DateTime @default(now())
}

And a slug to our Lesson schema.

// prisma/schema.prisma

model Lesson {
  id Int @id @default(autoincrement())
  title String @unique
  description String
  courseId Int
  course Course @relation(fields: [courseId], references: [id])
  videoUrl String
  slug String @unique
  createdAt DateTime @default(now())
}

The whole file should look something like this.

// prisma/schema.prisma

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

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

model User {
  id Int @id @default(autoincrement())
  email String @unique
  courses Course[]
  createdAt DateTime @default(now())
}

model Course {
  id Int @id @default(autoincrement())
  title String @unique
  description String
  lessons Lesson[]
  users User[]
  price Int
  slug String @unique
  createdAt DateTime @default(now())
}

model Lesson {
  id Int @id @default(autoincrement())
  title String @unique
  description String
  courseId Int
  course Course @relation(fields: [courseId], references: [id])
  videoUrl String
  slug String @unique
  createdAt DateTime @default(now())
}

Let's run the migration command again to snapshot those changes and update our db.

npx prisma migrate dev --name add-slugs --preview-feature

Awesome! We now have our application authenticating with Auth0, protecting our protected stuff and have our database schema ready to go!

Next week

Social login with GitHub and Auth0 rules

Hosting on Vercel, automatic deploys with GitHub and configuring custom domains

Jon — Wed, 21 Apr 2021 13:33:11 +0000

Project repo

This week we are focusing on all things hosting: making our next.js application available to the world wide webs; setting up automatic deploys when we change code; and configuring a custom domain!

Build app

We can build a production version of our application by running the build script - this is what our hosting platform will use too!

npm run build

ERROR!

This is giving us the following error.

Error: connect ECONNREFUSED 127.0.0.1:80

And that's because I made a small blunder in our first week! We are trying to load data from a serverless function, but that serverless function is also built when we build a new version of our application. This would be fine if the "building the serverless functions" step came before the "build our next app" step, but unfortunately that is not the case!

This worked locally because next does some performance magic and rebuilds the page when we request it by refreshing the browser.

Looks like we can't read data for our pre-rendered/statically generated pages from our serverless functions, but that is okay! Every one of our getStaticProps functions is actually a little chunk of server-side logic so we can just build our Prisma queries there!

Let's create a new utils folder at the root of our project and add a db.js file with the following content.

// utils/db.js

import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()

const getCourses = () =>
  prisma.course.findMany({
    include: {
      lessons: true,
    },
  })

export { getCourses }

Now we can import our getCourses function and call it in our getStaticProps function.

// pages/index.js

import CourseList from 'components/CourseList'
import { getCourses } from '../utils/db'

const Index = ({ courses }) => {
  return (
    <div>
      <h1>Courses</h1>
      <pre>
        {JSON.stringify(courses, null, 2)}
      </pre>
    </div>
  )
}

export const getStaticProps = async () => {
  const data = await getCourses()

  return {
    props: {
      courses: data,
    },
  }
}

export default Index

Let's run that build again!

npm run build

MORE ERRORS!

Error: Error serializing `.courses[0].createdAt` returned from `getStaticProps` in "/".
Reason: `object` ("[object Date]") cannot be serialized as JSON. Please only return JSON serializable data types.

Okay, this is a weird one but basically when the createdAt date comes back from Prisma, Next.js attempts to turn it into a string (serializing) and is not happy.

A quick trick we can use here is manually stringify the courses we get back from Prisma and then parse them back into json.

// pages/index.js

import { getCourses } from '../utils/db'

// other component stuff

export const getStaticProps = async () => {
  const data = await getCourses()

  return {
    props: {
      courses: JSON.parse(JSON.stringify(data)),
    },
  }
}

Our whole component should look something like this.

// pages/index.js

import { getCourses } from '../utils/db'

const Index = ({ courses }) => {
  return (
    <div>
      <h1>Courses</h1>
      <pre>
        {JSON.stringify(courses, null, 2)}
      </pre>
    </div>
  )
}

export const getStaticProps = async () => {
  const data = await getCourses()

  return {
    props: {
      courses: JSON.parse(JSON.stringify(data)),
    },
  }
}

export default Index

And run that build one last time!

npm run build

NO ERRORS!

Yay! Our application is building properly! We can run npm start to run the production build locally and make sure it looks good in the browser.

This is now hostable! But where to host?!?

Vercel

We need to actually host our application to get a public URL that we can give to someone with an internet connection, so they can see our super dope site!

There are many serverless hosting providers to choose from. My two favourites are Netlify and Vercel. They are both super focused on developer experience and have exceptional free tiers! Absolutely free to get started and you would need to have a pretty successful app to get to the point where you need to pay! Next.js can be hosted on either of these platforms, however, I find Vercel tends to implement new Next.js features a little ahead of Netlify (probably because they're also the creators of Next.js!), so I am going to use them for this SaaS project.

You will need to create an account with Vercel and install the CLI tool with the following command.

npm i -g vercel

Now you can login.

vercel login

And deploy your application.

vercel --prod

This will step you through a few questions about the project. You can just accept all the default options, since Vercel is very much optimised to host Next.js applications!

That's it! Super simple!

Add a secret in Vercel

When running locally we have specified an environment variable (or secret) for connecting to our Supabase DB instance. We need to tell Vercel about this so our application can connect to the DB in prod.

This is a good article about the different types of environment variables and how to configure them in Vercel.

Head over to the Vercel dashboard for you application and go to Settings > Environment Variables. Select "secret" for the type of variable, enter "DATABASE_URL" as the name and then dropdown the value input to "Create a new Secret for null".

Now enter your connection string from Supabase as the value, and make the name "@database-url". Secrets always start with "@" in Vercel.

Now we can select this secret from the dropdown to link it to our DATABASE_URL environment variable.

This distinction of environment variable separate from secret allows you to share environment variables across different projects.

Automatic deploys from GitHub

Next we want to tell Vercel to automatically deploy our application anytime we make changes. To do this we are going to use GitHub. Initialise the repo as a git project.

git init

Now create a new GitHub repo. You can do this through the GitHub UI, however, the gh CLI allows you to stay in your terminal!

brew install gh

gh repo create courses

Now we need to create a .gitignore file so we don't end up pushing a whole bunch of unnecessary stuff to GitHub - node_modules, easily generated files etc.

// .gitignore

node_modules/
.next/
.DS_Store
out/

Now we can add, commit and push to GitHub.

git add .
git commit -m 'create initial project'
git push origin master

Now we have some code in GitHub, let's tell Vercel about it.

Now navigate to Settings > Git and click Connect git repository.

This will require you to authenticate with GitHub and allow Vercel access to your repos.

Select your project repo and your production branch - mine is master.

Now Vercel will automatically deploy a new version of your application anytime you push changes to that branch. Give it a go!

Make a small change to your home page, commit and push to GitHub. You should see this kicks off a new deployment in your Vercel Dashboard. Once this is done your changes should be live on your deployed site!

Custom domain

The last thing I am going to setup this week is a custom domain. This is the only part of this series that is going to cost money, but it is entirely optional! Vercel will give us a public URL that we can use to share our application with the world. A custom domain just allows us to customise things a little more, which may be important for your branding.

Vercel offer a super easy way to purchase domains through their dashboard, however, I have found that other services often have the same domain names a little bit cheaper. I have a few domains registered with hover.com and have had a really good experience with them so far, but any domain registration service will do. They should all let you add DNS records and change name servers, which is what we need to do.

Now that you have purchased your amazingly custom domain name, you need to add two DNS records. There should be a menu item for DNS somewhere and it should contain fields for type, hostname and IP address.

Create one with this info:

Type: A
Hostname: @
IP Address: 76.76.21.21

And one with this info:

Type: A
Hostname: *
IP Address: 76.76.21.21

The @ means anything looking for this domain, send to Vercel's IP address, and the * does the same for subdomains - such as www.

This is what this should look like in Hover.

Lastly, we need to point the nameservers to Vercel. In Hover this is located on the Overview page.

Update these to the following values.

ns1.vercel-dns.com
ns2.vercel-dns.com

Again, this is what it looks like in Hover.

Now we need to tell Vercel that this is the domain name we would like to use for our project. Head on over to the Vercel dashboard for your project and navigate to Settings > Domains, and in the Domains input box enter your new custom domain and click Add.

This will send a request to your domain and make sure it is configured correctly. If everything is all good it will look like this.

If there is a problem it will look something like this.

Sometimes it can take a little bit of time to propagate DNS changes through, so don't panic straight away! Maybe grab a coffee or have a nap. If it is still not working, double check that configuration above.

If everything is green ticks your application will now be available at your custom domain! Great work!

Wrapping up

Awesome! Our application is hosted, we have automatic deploys setup for anytime we push changes to GitHub, and we have (maybe) configured our own custom on-brand domain!

Helpful resources

Next week

Authentication with Auth0 and Next.js

Tech stack and initial project setup

Jon — Wed, 21 Apr 2021 13:32:11 +0000

Week one down! How exciting! This week was all about coming up with an idea and configuring the new project. I will be keeping the GitHub repo up to date as I build out this project so make sure you check that out!

Idea

I will be building a video tutorial/course platform that contains a collection of free and paid courses. You will be able to watch any of the free courses once you create an account. For the premium content, you can choose to purchase a single course to own forever, or subscribe on a monthly or yearly basis to access all the premium courses.

Readme Driven Development (RDD)

I will be following Tom Preston-Werner's Readme Driven Development methodology, whereby the first thing you create is a readme describing your project. My key takeaways from Tom's article were:

Making a product for users is a waste of time if it doesn't provide value
Thinking about how your software will be used gives you a pathway with achievable milestones
Helps inform tech decisions
Creates a shared language and understanding across other devs and stakeholders.

You can checkout my readme to see what I am planning to build.

Stack

As the majority of this project can be statically generated ahead of time I will be building a Jamstack app. This will help keep the loading speed fast for users and keep the hosting costs ~~down~~ free!

Next.js

Since most of the content can be generated at build time I was keen to use something that makes this process simple - Next.js or Gatsby. I went with Next.js as it gives me all that SSG (Static Site Generation) magic I am after, but also offers SSR (Server Side Rendering) if my application does require it in the future!

Additionally, I really like Next's API for generating static content. You just declare a getStaticProps function, co-located with the page component that uses the data. Next.js will iterate over any components that declare this function and make these requests at build time. I find this workflow to be a little more convenient than Gatsby, and requires less context switching than jumping out of the component and implementing some data fetching in gatsby-node.js.

That is just personal preference though. Both of these frameworks are absolutely awesome and are perfectly capable of building what we need!

Setting up Next.js was super simple. Just create a new folder and initialise it as an NPM project. My project will be called "courses".

mkdir courses && cd courses && npm init -y

Now to install Next.js and its dependencies.

npm i next react react-dom

Let's add some scripts to build and run our application. In the package.json file, replace the test script (that no-one uses in a side project) with the following.

"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
  "export": "next export"
},

Next.js uses file-based routing so we can create pages simply by putting React components in the pages directory.

mkdir pages

Now create an index.js file and add the following code to create a welcoming home page.

// pages/index.js

const HomePage = () => <h1>Welcome to Courses!</h1>

export default HomePage

We now have a fully functioning Next.js application. Run the following command and go and visit it at http://localhost:3000.

npm run dev

API routes

We will need some serverside code in order to process payments with Stripe and interact with the database. These chunks of serverside code will be quite isolated and single purpose. This is a perfect usecase for serverless functions and Next.js makes this super simple!

Just create an API folder in the pages directory!

mkdir pages/api

And add a test.js file with the following content.

// pages/api/test.js

module.exports = async (req, res) => {
  res.send('it works!')
}

That's it! It's done! To run this serverless function just go to http://localhost:3000/api/test.

Next.js will pick up any .js files in this api folder and automatically turn them into serverless functions!

Super cool!

SQL vs Document DB

We are going to need a database to store information about our users, and remember which courses they have purchased. There are a huge number of options here, but first we need to decide whether we want to use an SQL db - such as PostgreSQL - or a document db - such as MongoDB.

The biggest factor to consider between these two options is how you want to model relationships between different bits of data. An SQL db can stitch together data from different tables using one complex query, whereas you may need to do multiple queries in a document db, and stitch it together yourself.

Our application is going to be hosted on a different server to our db - potentially in a different continent - so making a single request, letting the db do some of the hard work and sending back a smaller dataset is likely going to be much more performant.

Again, the scope of this application is quite small so this is probably not going to be a problem, but since we know we will need at least a relationship between our user and the courses they have purchased, I am going to go with an SQL solution.

Additionally, the methodology of the Jamstack is all about being able to scale up easily and I think SQL gives us more options than a document db as things get more complex!

Supabase

Again, there are a million options for a hosted SQL database. I have used Heroku extensively in the past and would highly recommend, however, I have been looking for an excuse to try Supabase and I think this is it!

Supabase is an open source competitor to Firebase. They offer a whole bunch of services - db hosting, query builder language, auth etc - however, we are just going to use it as a free db host.

Head on over to their website and create an account.

Once you're at the dashboard click "create a new project" - make sure to use a strong password (and copy it somewhere as we will need it again soon!) and pick a region that is geographically close to you!

Once it is finished creating a DB, head over to Settings > Database and copy the Connection String. We are going to need this in the next step!

Prisma

Now we need to decide how we want to interact with our database. We could just send across big SQL query strings, but we're not living in the dark ages anymore!

I have a background in Rails and really like the ORM (object relational mapping) style of interacting with databases so I am going to choose Prisma!

Prisma is a query builder. It basically abstracts away complex SQL queries and allows you to write JavaScript code to talk to the DB. It's awesome! You'll see!

Let's set it up! First we need to install it as a dev dependency

npm i -D prisma

Now we initialise Prisma in our project.

npx prisma init

Next we need to create our models - how we want to represent our data.

// prisma/schema.prisma

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

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

model Course {
  id Int @id @default(autoincrement())
  title String @unique
  createdAt DateTime @default(now())
  lessons Lesson[]
}

model Lesson {
  id Int @id @default(autoincrement())
  title String @unique
  courseId Int
  createdAt DateTime @default(now())
  course Course @relation(fields: [courseId], references: [id])
}

Here we are creating a course which has a collection of lessons. A lesson belongs to a course.

We are just going to focus on our courses for now - users can come later!

Now we want to update the DATABASE_URL in our .env with that connection string from Supabase.

// .env

DATABASE_URL="your connecting string"

Make sure you replace the password in the connection string with the password you used to create the Supabase project!

Now we need to make sure we add this .env file to our .gitignore so as to never commit our secrets to GitHub.

// .gitignore

node_modules/
.next/
.DS_Store
out/
.env

Okay, now that we have this hooked up to an actual database, we want to tell it to match our schema.prisma file. We do this by pushing the changes.

npx prisma db push --preview-feature

We need to pass the --preview-feature flag as this is an experimental feature, and may change in the future.

Now we want to install the Prisma client, which we will use to send queries to our database.

npm i @prisma/client

And generate our client based on the schema.

npx prisma generate

Lastly, let's create a serverless function to create some data in our database, and confirm everything is wired up correctly!

// pages/api/create-course

import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

module.exports = async (req, res) => {
  await prisma.course.create({
    data: {
      title: 'Learning to code!',
      lessons: {
        create: { title: 'Learn the terminal' },
      },
    },
  })
  // TODO: send a response
}

This will create a new course with the title "Learning to code!", but it will also create the first lesson "Learn the terminal".

This is the power of using a query builder like Prisma! Queries that would be quite complex in SQL are super easy to write and reason about!

Let's add another prisma query to select the data we have written to the DB and send it back as the response.

// pages/api/create-course.js

module.exports = async (req, res) => {
  // write to db
  const courses = await prisma.course.findMany({
    include: {
      lessons: true,
    },
  })
  res.send(courses)
}

Our entire function should look like this.

// pages/api/create-course.js

import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

module.exports = async (req, res) => {
  await prisma.course.create({
    data: {
      title: 'Learning to code!',
      lessons: {
        create: { title: 'Learn the terminal' },
      },
    },
  })
  const courses = await prisma.course.findMany({
    include: {
      lessons: true,
    },
  })
  res.send(courses)
}

Excellent! Now we can run this serverless function by navigating to http://localhost:3000/api/create-course.

You should get back the newly created course and lesson. We can also see this has actually been written to the DB by inspecting our data in the Supabase dashboard.

I recommend deleting this serverless function to avoid accidentally running it later and adding unnecessary courses! If you want to keep it as a reference, just comment out the code that creates the course.

// api/create-course.js

import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

module.exports = async (req, res) => {
  // await prisma.course.create({
  // data: {
  // title: 'Learning to code!',
  // lessons: {
  // create: { title: 'Learn the terminal' },
  // },
  // },
  // })
  // const courses = await prisma.course.findMany({
  // include: {
  // lessons: true,
  // },
  // })
  // res.send(courses)
  res.send('This is only here as a guide!')
}

Okay! Let's wire this up to Next!

SSG

Back in our pages/index.js component we want to query our DB for all courses and display them in a list. We could make this request when a user visits our site, but since this data is not going to change very often this will mean a huge number of unnecessary requests to our API and a lot of users waiting for the same data over and over again!

What if we just requested this data when we build a new version of our application and bake the result into a simple HTML page. That would speed things up significantly and keep our users happy! A happy user is a user who wants to buy courses!

Next.js makes this super simple with a function called getStaticProps. Lets extend our index.js file to export this function.

export const getStaticProps = async () => {
  const data = await getSomeData()

  return {
    props: {
      data, // this will be passed to our Component as a prop
    },
  }
}

Since this is going to be run when Next.js is building our application, it will be run in a node process, rather than in a browser. This might seem confusing since it is being exported from a component that will be running in the user's browser, but at build time there is no user - there is no browser!

Therefore, we will need a way to make a request to our API from node. I am going to use Axios because I really like the API, but any HTTP request library will do!

npm i axios

// pages/index.js

import axios from 'axios'

// component declaration

export const getStaticProps = async () => {
  const { data } = await axios.get('http://localhost:3000/api/get-courses')

  return {
    props: {
      courses: data,
    },
  }
}

// component export

Whatever we return from getStaticProps will be passed into our component, so let's display that JSON blob in our component.

// pages/index.js

const Homepage = ({ courses }) => {
  return (
    <div>
      <h1>Courses</h1>
      <pre>
        {JSON.stringify(courses, null, 2)}
      </pre>
    </div>
  )
}

export default Homepage

We can pass JSON.stringify additional arguments (null and 2) in order to pretty print our data.

Our whole component should look like this.

// pages/index.js

import axios from 'axios'

const Homepage = ({ courses }) => {
  return (
    <div>
      <h1>Courses</h1>
      <pre>
        {JSON.stringify(courses, null, 2)}
      </pre>
    </div>
  )
}

export const getStaticProps = async () => {
  const { data } = await axios.get('http://localhost:3000/api/get-courses')

  return {
    props: {
      courses: data,
    },
  }
}

export default Homepage

Now we just need to create that get-courses serverless function.

// pages/api/get-courses.js

import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()

module.exports = async (req, res) => {
  const courses = await prisma.course.findMany({
    include: {
      lessons: true,
    },
  })
  res.send(courses)
}

That's it! We should now have an entire system wired up end-to-end!

Next.js is requesting our courses from the serverless function at build time
Our serverless function is using Prisma to query the Supabase DB for the courses
The results are piping through from Supabase -> Serverless function -> Next.js, which is baking them into a static page
The user requests this page and can see the courses

Tailwind

I also decided to challenge my opinion that Tailwind is just ugly inline styles, and actually give it a try! You will be hearing from me often if I do not like it!

Let's install it!

npm i -D tailwindcss@latest postcss@latest autoprefixer@latest

Next let's initialise some configuration.

npx tailwindcss init -p

We can also tell Tailwind to remove any unused styles in prod.

// tailwind.config.js

module.exports = {
  purge: ['./pages/ **/*.{js,ts,jsx,tsx}', './components/** /*.{js,ts,jsx,tsx}'],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

We are going to want to import Tailwind's CSS on every page, so will create an _app.js file, which automatically wraps every page component.

import 'tailwindcss/tailwind.css'
import '../styles/globals.css'

const MyApp = ({ Component, pageProps }) => <Component {...pageProps} />

export default MyApp

Lastly, create a styles/globals.css file to import the Tailwind bits.

// styles/globals.css

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

Awesome, now we have Tailwind configured. Check out their docs for great examples!

I will not be focusing on the styling aspect of this project throughout the blog series, but feel free to check out the repo for pretty examples.

Great resources

Next week

Hosting on Vercel, automatic deploys with GitHub and configuring custom domains

Getting a job in the tech industry

Jon — Wed, 24 Jun 2020 00:00:00 +0000

So you have just finished a CS degree, bootcamp or are just not super engaged at your current role. Time for a new job! But how do you go about being noticed, standing out or getting the attention of your dream company?

This article will go through some techniques that I have found particularly helpful in my career. I am definitely not a career coach and have no experience as a recruiter, however, in obtaining my last few software development roles I have been able to select the companies I am passionate about working for, and have managed to engage 100% of the companies I have contacted. Okay, there is the lame sales pitch done.

Don't apply for open roles

I know this seems counterintuative - the first places you look for jobs are job boards or LinkedIn, right? Wrong! Sure, these companies have vacancies, but they are publicly inviting people to compete for a small number, or potentially single role. This is a difficult game to win, especially if you're on the lighter side of demonstrated work experience.

Additionally, these companies know that they have broadcasted their desire to employ someone, so the kinds of people who apply are potentially applying because they want/need any job, not necessarily because this job is their dream job! So you are already defending your reasons for applying for the role, rather than demonstrating how capable you are. Wouldn't it be better if your very first engagement with the company could tick the box for convincing them that this is your dream job, and then you only need to convince them of your capability within the role?!

The best way to do this is to not apply for open roles. Shortlist - and I mean "short" - a few companies that you would really like to work for. For me and my first serious tech role, this was companies that would really help me learn and grow in my career, that had the "cool tech company" vibe from the outside. There are heaps of resources you can use to find places near you that match your preferences - GlassDoor, LinkedIn, Reddit etc.

I found it particularly helpful looking at companies that host or sponsor local meetups and conferences, and talking to the speakers about where they work. Chances are if they are putting together interesting talks and mention the companies they work for, they probably have some kind of support from their companies to do these things they are passionate about, and that sounds like the kind of company I want to work for! I live in Melbourne, Australia so my list was Envato, Culture Amp, REA Group and Zendesk.

Great, now I have a shortlist but who do I contact and what do I say to them? I need to get their attention but I don't want to waste their time with my work/education history in black text on a white background! What can I offer that people actually want?

The importance of coffee and beer

Most people like coffee or beer! And throughout the work day, most people would really rather be drinking coffee or beer - depending on what time it is! Why not ask someone from the company if they have time for a coffee during the day or a quick beer after work? Getting someone to sit down with you and have an actual conversation is much more engaging than reading anything you sent them, or speaking with them on the phone. You actually have their attention.

It also feels a lot like the first stage of an interview to me - but one that you didn't need to compete with others to get. This is focused one-on-one time where you can really tell your story, ask any questions you would like clarified and introduce them to your personality. Additionally, this demonstrates that you are self driven and motivated, and have a real interest in this company - getting you over that first hurdle, and into only needing to convince them of your capabilities, rather than your interest.

So who do you contact? How do you contact them?

This is probably the stand alone most important piece of advice from this whole article. If you only take away one thing to actually do, make it this!

Sign up for a free trial LinkedIn Premium account.

The second most important piece of advice is make sure you cancel it before the trial runs out as it is surprisingly expensive!

What a premium account gives you is the ability to privately message people outside your connections. Now to find the actual people. I think a good rule of thumb is to contact three people from each company - at least one of these people from a high up position in the recruitment team and one high up in tech. It's important to mention the names of each of the other people you are contacting in your message so if they do discuss your message in the team it doesn't just look like you blasted everyone at the company with a generic message.

Make sure it is something short and to the point, with an option for the person to palm you off to someone else is best. Something along the lines of:

Hi! My name is BLAH. I am really keen to work at NAME OF COMPANY, and wondered if you would have some time to catch up for coffee or beer after work sometime next week? I have also reached out to PERSON and OTHER PERSON, so please let me know if they - or someone else from your team - would be more appropriate! Thanks for your time and look forward to meeting with you soon!

I have had 100% success rate with this method. When I contacted all four companies I ended up having a coffee catchup and was given the opportunity to explain who I was and what I was after. In all four cases this gave me an advocate within the company who could push on my behalf. It also allowed me to skip the first level of interviews in most cases.

Make sure you prepare well for this catchup. This is your opportunity to show them how keen you are to work at this company and ask any questions that may improve your chances. Stalk them on LinkedIn/Twitter, understand their background and ask them good questions!

Maybe you don't have a great deal of demonstrated work experience in the area of example projects to show your work. What is another way to get their attention?

Do something CRAZY!

Okay, not too crazy but you want to stand out! I know this sounds difficult but it doesn't have to be a giant task. Think about something unique that you enjoy doing, that could help you stand out in this role. It could be as simple as bright colours on your resume, or recording a podcast about the things you have learnt about the company that make you want to work there.

When applying for my most recent role I wanted to work for a company that was very consumer and brand focused. I wanted to build beautiful things that would be appreciated, so I wanted to demonstrate this when getting their attention. I built a clone of their website - using their brand colours, fonts and similar language - but with the content talking about why they should hire me. It worked as an interactive job application, but it stands out much more than black text on a white background! It demonstrated my interest in their specific company and knowledge of their brand.

Okay, so this is a super time consuming activity, right? You can't build 20 unique websites for companies you want to work for. Exactly! Don't do that! Refer to the point in the "Don't apply for open roles" section. You want to specifically target a small handful of companies that you are actually excited to work for. Ones where you can be your authentic self! You are way more likely to get someone's attention building three properly targeted applications than sending out 100 text-based boring, same same, generic job applications. That's probably why you have felt like this was such a hopeless endeavour in the past. You can't stand out doing the same thing as everyone else!

Exaggerate the right things

Okay, you have their attention, now what do they want to hear? All companies and teams have specific things that they value over others, but I would say the most consistent things that companies want from employees are:

Learning: Companies want you to have a burning desire to learn new things. This is a guarantee that their investment in you is going to increase in value over time. The more things you learn over time, the more problems you can solve for them.

Communication: You need to be able to communicate with other people. Companies don't want you to just take a task and complete it on your own. The tech world has become too complicated. It requires a lot of compromises, empathy and discussion.

Resilience: Sometimes people disagree on a solution - especially in an industry of strongly opinionated people. You need the ability to navigate this calmly. Companies want you to demonstrate that you are comfortable calmly defending or justifying your idea, as well as listening to others and negotiating.

Be yourself

I know this just sounds like standard recruitment fluff, but you really do need to be yourself. I have always had a problem with wearing nicely ironed, tucked in shirts to work. I thought that I was just destined to feel uncomfortable during work hours because that's what you need to do to get paid. I'm sure if you have done any work as a software developer (or any "cool" company) in the last five years you are probably laughing at the moment, but this is definitely not required at good companies with good culture!

I realised wearing comfortable clothes was something that was legitimately important to me, and anytime I could get away with it I would not iron my shirt, untuck it or change into a t-shirt the moment work was done. I was desperate to be comfortable and my workplace was not okay with it. But other companies were so I started working there instead. Being comfortable at work made me feel respected as an individual and improved my feelings of belonging and acceptance. It also meant I wasn't wasting mental energy feeling frustrated about something that didn't affect the quality of my work in any way, meaning I could focus on doing better work. Find those things that are important to you and find the companies that are comfortable with it. Your company's expectations being aligned with you being yourself is so important to your overall happiness and productivity!

Work experience and CS degrees are not important

Obviously anything you have to demonstrate your interest and experience in this field is important to help strengthen your argument, but you do NOT need work experience and you do NOT need a CS degree! Some companies will have this as a requirement so don't work for those companies - they sound like shit places to work. Things that really demonstrate interest and experience are:

Bootcamps: These are tough and require a lot of time and dedication. Talk about that!

Side projects: This shows you even want to work on this stuff when you're not being paid to do so!

Building websites for local businesses: This can help you build a portfolio of projects to demonstrate your ability. You also might be able to help out some businesses that may not be doing too well - especially at the moment - so win win. Additionally, you don't need anyone else's permission to do this! Obviously do not impersonate someone else's business if they do not want you to make the website live, but you could build a website for them before contacting them, then send them the finished version and ask if they would like to use it. This may also lead to some referrals and more work meaning you don't actually need to apply for a new role anyway!

Attending meetups: Go check out some local meetups that are related to the kind of work you want to do. A lot of them will have representatives from companies that are looking to hire developers that want to spend their spare evenings learning and talking about code! It is also a great opportunity to network with developers from other companies and learn about what it's actually like working there. I absolutely hate doing this but it has really helped me and my career development. Treat it like getting those needles you know are helping you, or going to the dentist.

Short resume: No one cares about your retail job from 15 years ago if you have three years experience as a developer. Try to keep it as relevent as possible. You can always list your entire work history on LinkedIn and send people there if they want to learn more. Use this resume to list only the things you want to use to entice the person reading it. Try to keep this to one page of distilled, attention grabbing bits of information.

Wrapping up

Applying for jobs sucks! Try to reduce the pain by increasing your chances of working for the first company you contact! Do what you can to reduce the amount of people you are competing with for attention by doing things out of the ordinary and being extraordinarily interesting! Meeting people in person is super effective - you have their full attention so don't waste it! Find companies that are an approprate fit for your personality so neither of you need to lie. Don't undervalue the stuff outside of work experience and formal degrees. Companies want to invest in good people, so just convince them you are that!

Using custom hooks to reduce component complexity

Jon — Thu, 28 May 2020 00:00:00 +0000

This article continues on from where Simple caching with local storage left off. Check that out for context on how local storage can be used as a super simple cache, when requesting data from an API.

In this article we will look at abstracting our request and caching logic into reusable React Hook components. Hooks are a really nice way to bundle up our complicated and confusing code into a package that we don't need to think about anymore, and can reuse across our application and other projects!

This video goes through the same example as the blog, but may be more enjoyable for those that are visual learners/want some extra company!

We have already been using the useState and useEffect hooks that are provided by React to simplify our data logic, but we can do so much more with our own custom hooks!

The important parts to remember from the previous article are the request functions and our <Skaters /> component.

// src/utils/request.js

import axios from 'axios'
import { readFromCache, writeToCache } from './cache'

const getFreshData = async (url, cacheResponse = false) => {
  const { data } = await axios.get(url)
  cacheResponse && writeToCache(url, data)
  return data
}

const getCachedData = url => readFromCache(url)

export { getCachedData, getFreshData }


// src/Skaters.js

import React, { useState } from 'react'
import { getCachedData, getFreshData } from './utils/request'

const url = 'https://thps.now.sh/api/skaters'

const renderSkater = ({ name, stance }) => (
  <div key={name}>
    <p>
      {name} - {stance}
    </p>
  </div>
)

const Skaters = ({ useCache }) => {
  const [skaters, setSkaters] = useState([])

  const getSkaters = async () => {
    setSkaters([])

    if (useCache) {
      const cachedSkaters = getCachedData(url)
      if (cachedSkaters) {
        setSkaters(cachedSkaters)
      }
    }

    const freshSkaters = await getFreshData(url, useCache)
    setSkaters(freshSkaters)
  }

  return (
    <div>
      <div>{skaters.map(renderSkater)}</div>
      <button onClick={getSkaters}>Load</button>
    </div>
  )
}

export default Skaters

Let's first look at refactoring our request logic as a custom React Hook. We can leave the old functions there as a reference and create a new hooks folder under the src directory. Inside this new folder create a new file named useRequest.js. By convention all hooks must start with the word use.

Let's start with creating the skeleton for our useRequest hook, which will take in a url as a parameter.

const useRequest = url => {}

export default useRequest

Next we are going to need some state and the ability to trigger our requests when our hook is being consumed, so let's bring in useState and useEffect.

import { useState, useEffect } from 'react'

const useRequest = url => {
  const [data, setData] = useState()

  useEffect(() => {
    // request data
    // call setData with new value
  }, [])

  return data
}

export default useRequest

This should look pretty familiar. We have a data variable that is being returned from our hook. Anytime we update the value of that variable - by using setData - it will trigger a re-render for anything consuming our hook. You can think of this as a live variable. Any component using that variable does not need to understand when or why it will change, but anytime it does change the component will be told to re-render with the new value. Magic!

useEffect is where we will add some logic for requesting fresh data from the API and updating our data variable with the response. We are giving it an empty array of dependencies [] so that this logic only runs when the hook is first consumed - meaning we are not requesting the data from the API over and over again, just once when our page is loaded. This is slightly different to the example in our previous article - where we were loading data based off a button click - but we don't want our users to have to wait for the page to be loaded and then click a button to see data. We can just give it to them as soon as we can!

Let's bring in axios, make a request for our fresh data and update the data value with the response.

import { useState, useEffect } from 'react'
import axios from 'axios'

const useRequest = url => {
  const [data, setData] = useState()

  const getFreshData = async () => {
    const { data: response } = await axios.get(url)
    setData(response)
  }

  useEffect(() => {
    getFreshData()
  }, [])

  return data
}

export default useRequest

Something that may look a little weird here is

const { data: response } = await axios.get(url)

The { data: response } part is destructuring data from the response, but we already have a data variable in scope. data is the name of our state variable. This will cause a naming collision, as we won't know which data variable we are referring to. So the { data: response } part is destructuring data and immediately renaming the variable to response. This makes our code a little clearer to read aswell, as on the next line we are setting our data variable to be equal to the response.

Awesome! Now we have a useRequest hook that can be consumed by any component that needs to request data from an API. Using this hook in our <Skaters /> component would look something like this.

const url = 'https://thps.now.sh/api/skaters'
const skaters = useRequest(url)

Gosh, that is so much simpler! But now our component would need to check whether the skaters variable contained data before rendering it. Also, if we follow the useRequest logic, the data variable is initialised as null, and then its value is magically be updated to an array when the response comes back from the API. That will require some additional rendering logic in our <Skaters />component to determine whether our request is still waiting for the response (loading).

Why don't we refactor our useRequest hook to provide this information, as determining the loading state of our data does feel like the responsibility of our request hook, rather than our rendering component. Plus it is super simple to do!

import { useState, useEffect } from 'react'
import axios from 'axios'

const useRequest = url => {
  const [data, setData] = useState()

  const getFreshData = async () => {
    const { data: response } = await axios.get(url)
    setData(response)
  }

  useEffect(() => {
    getFreshData()
  }, [])

  const loading = !data

  return {
    data,
    loading,
  }
}

export default useRequest

All we have changed are the last few lines of our hook. We created a loading variable - set to whether we actually have data or not - and instead of returning the data variable, we are returning an object with our data and loading states.

Now our consuming component would look something like this.

const url = 'https://thps.now.sh/api/skaters'
const { data, loading } = useRequest(url)

And again we could use that renaming while destructuring trick to give our data some context.

const url = 'https://thps.now.sh/api/skaters'
const { data: skaters, loading } = useRequest(url)

Great! Now, remaining positive and assuming everything is going to go according to plan is always a good idea ... except in programming! We have a lovely interface exposing our loading and data states, but no way to tell if something went wrong. Let's add error handling. We can wrap our fetching logic in a try catch, which will attempt to run what is in the try block and then trigger the catch block if an error occurs.

try {
  // try something
} catch (e) {
  // an error happened
}

Let's see what that would look like wrapping our request logic.

import { useState, useEffect } from 'react'
import axios from 'axios'

const useRequest = url => {
  const [data, setData] = useState()
  const [error, setError] = useState()

  const getFreshData = async () => {
    try {
      const { data: response } = await axios.get(url)
      setData(response)
    } catch (e) {
      setError(e)
    }
  }

  useEffect(() => {
    getFreshData()
  }, [])

  const loading = !data && !error

  return {
    data,
    loading,
    error,
  }
}

export default useRequest

There are a few small changes here. We added an error variable with useState, wrapped our fetching logic in a try catch, updated our loading state to account for errors, and exposed the error variable to our consumers.

Awesome! Now our consuming component would look something like this.

const url = 'https://thps.now.sh/api/skaters'
const { data: skaters, loading, error } = useRequest(url)

if (loading) return <p>Loading...</p>
if (error) return <p>There was an error!</p>

// At this point we are confident that we have
// our data so we can just render it!
return skaters.map(renderSkaters)

The last thing we need to do here is implement our caching from the previous article. We can do this within the same hook and not need to change our consuming interface. All we need to do is modify our getFreshData to write the API response to the cache and create a new function to attempt to getCachedData first. This is what our final useRequest hook looks like.

import { useState, useEffect } from 'react'
import axios from 'axios'
import { readFromCache, writeToCache } from './cache'

const useRequest = url => {
  const [data, setData] = useState()
  const [error, setError] = useState()

  const getFreshData = async () => {
    try {
      const { data: response } = await axios.get(url)
      writeToCache(url, response)
      setData(response)
    } catch (e) {
      setError(e)
    }
  }

  const getCachedData = () => {
    const cachedData = readFromCache(url)
    cachedData && setData(cachedData)
  }

  useEffect(() => {
    getCachedData()
    getFreshData()
  }, [])

  const loading = !data && !error

  return {
    data,
    loading,
    error,
  }
}

export default useRequest

Before refactoring our <Skaters /> component let's take a quick look at what we had in the previous article.

// src/Skaters.js

import React, { useState } from 'react'
import { getCachedData, getFreshData } from './utils/request'

const url = 'https://thps.now.sh/api/skaters'

const renderSkater = ({ name, stance }) => (
  <div key={name}>
    <p>
      {name} - {stance}
    </p>
  </div>
)

const Skaters = ({ useCache }) => {
  const [skaters, setSkaters] = useState([])

  const getSkaters = async () => {
    setSkaters([])

    if (useCache) {
      const cachedSkaters = getCachedData(url)
      if (cachedSkaters) {
        setSkaters(cachedSkaters)
      }
    }

    const freshSkaters = await getFreshData(url, useCache)
    setSkaters(freshSkaters)
  }

  return (
    <div>
      <div>{skaters.map(renderSkater)}</div>
      <button onClick={getSkaters}>Load</button>
    </div>
  )
}

export default Skaters

It contains a lot of logic around caching and requesting that is not really related to skaters. Let's have a look at the refactored version and see what it's responsible for.

// src/Skaters.js

import React from 'react'

const url = 'https://thps.now.sh/api/skaters'

const renderSkater = ({ name, stance }) => (
  <div key={name}>
    <p>
      {name} - {stance}
    </p>
  </div>
)

const Skaters = () => {
  const { data: skaters, loading, error } = useRequest(url)

  if (loading) return <p>Loading...</p>
  if (error) return <p>There was an error!</p>

  return skaters.map(renderSkater)
}

export default Skaters

Wow! Firstly, it's a lot smaller, easier to read and the component doesn't need to know anything about caching or fetching logic. It simply uses our useRequest hook which handles the complexity and exposes our three different states: loading, error and data. This is a fairly common pattern for data fetching libraries - such as Apollo Client for GraphQL.

This example does not implement the ability to make a request without using the cache. This is because the cache is cool! You wanna use the cache! Forever and always! Right? I guess if you really want to implement the ability to switch off the cache, or just take a look at the full working example, check out the THPS with hooks repo.

Simple caching with local storage

Jon — Tue, 17 Mar 2020 00:00:00 +0000

Computers are fast. Like, really fast! So why do we see so many loading spinners on the web and have to wait so long for things to load? Because networks are slow! Sending information across the world is slow and by using wonderful 3rd party services to solve our problems - Netlify, Stripe, AWS etc - our webapps could be making requests to several places around the world, before the user gets a chance to interact with the page. This is a complicated problem to solve and probably requires a lot of smart devops people and tech leads, or can we solve part of it in JS? Spoilers, we can!

This video above goes through the same example as this blog, but may be more enjoyable for those that are visual learners/want some extra company while implementing caching!

Let's say we have a request that is hitting a Tony Hawks Pro Skater API and requesting all skaters.

Note: I am using the axios library for simplicity's sake but this could definitely be done with fetch

import axios from 'axios'

const getSkaters = async () => {
  const url = 'https://thps.now.sh/api/skaters'

  // wait for a response from the API
  const { data } = await axios.get(url)

  return data
}

This returns a response that looks something like this.

[
  {
    "name": "Tony Hawk",
    "style": "Vert",
    "stance": "Goofy",
    "speed": 6,
    "air": 7,
    "hangtime": 5
  },
  {
    "name": "Bob Burnquist",
    "style": "All around",
    "stance": "Regular",
    "speed": 5,
    "air": 6,
    "hangtime": 5
  },
  ...
]

Everytime we call the getSkaters() function we are waiting for our app to send a request to the Tony Hawk API. This could only take a matter of milliseconds in an ideal scenario - low API traffic, small dataset, our app and API hosted in similar geographic locations - but to address what I'm sure you're all thinking, there are surely millions of people all day every day that wanna hit that API non stop to get those sweet skater stats!

Now we can't do much about the first request, as the client has no idea about player stats until our API tells them, however, we could implement our own way of caching that data the first time - making it available without a full round trip to the API server. Now how will we build a cache? A cache is just some data that we remember we got back from a particular request (or URL). Thankfully the browser has this wonderful and simple way to store data called localStorage.

localStorage.setItem(key, data) // writes the data against that key

localStorage.getItem(key) // returns the data associated with that key

LocalStorage allows us to read and write key/value pairs to and from the browser's storage. To write some data to localStorage we need a key - something unique to identify our data - and the data we want to store there. Let's build some convenience functions for interfacing with localStorage.

// src/utils/cache.js

const writeToCache = (url, data) =>
  localStorage.setItem(url, JSON.stringify(data))

const readFromCache = url => JSON.parse(localStorage.getItem(url)) || null

export { readFromCache, writeToCache }

Hopefully you are comfortable with the ES6 syntax, arrow functions and implicit returns used above. If not, these are two functions that abstract reading and writing from the cache. What is on the right-hand side of => is what is returned from the function.

We are using the url as our key, as this will always be unique.

There are a few other weird things going on here, particularly parse and stringify. These functions are the inverse of each other. One takes a json object and turns it into a big string (stringify), the other takes a big string and turns it into a json object (parse). This is required because localStorage only allows us to store strings.

The || syntax is used to provide a fallback value. So we are checking whether there is any data stored against that url that we can parse into a json object, if not we want to return null.

export is used to expose these functions from the file so that other files can import them.

Next, we want to abstract our request out of our getSkaters() function and make it more generic, and cache-able.

// src/utils/request.js

import axios from 'axios'
import { writeToCache } from './cache'

const getFreshData = async (url, cacheResponse = false) => {
  const { data } = await axios.get(url)
  cacheResponse && writeToCache(url, data)
  return data
}

Again, we are creating a new file to abstract away our reusable logic. Our getFreshData() function now takes a url and a cacheResponse boolean. The url is used to request our data from the API, and cacheResponse tells our function whether we want to write that response to the cache. Let's extend this file to contain a getCachedData() function.

const getCachedData = url => readFromCache(url)

This one is really just wrapping readFromCache, but it means anything that needs to request data can just use this one file, reguardless of whether they want fresh or cached content. The final version of the file should look something like this.

import axios from 'axios'
import { readFromCache, writeToCache } from './cache'

const getFreshData = async (url, cacheResponse = false) => {
  const { data } = await axios.get(url)
  cacheResponse && writeToCache(url, data)
  return data
}

const getCachedData = url => readFromCache(url)

export { getCachedData, getFreshData }

Now let's create our Skaters component.

import React, { useState } from 'react'

const renderSkater = ({ name, stance }) => (
  <div key={name}>
    <p>
      {name} - {stance}
    </p>
  </div>
)

const Skaters = () => {
  const [skaters, setSkaters] = useState([])

  return (
    <>
      <div>{skaters.map(renderSkater)}</div>
      <button>Load</button>
    </>
  )
}

export default Skaters

This is simply interating over an array of skaters and displaying the name and stance of each one.

Let's extend it to take a useCache prop, and make a request for either the fresh or cached version of the skaters.

import React, { useState } from 'react'
import { getCachedData, getFreshData } from './utils/request'

const url = 'https://thps.now.sh/api/skaters'

const renderSkater = ({ name, stance }) => (
  <div key={name}>
    <p>
      {name} - {stance}
    </p>
  </div>
)

const Skaters = ({ useCache }) => {
  const [skaters, setSkaters] = useState([])

  const getSkaters = async () => {
    setSkaters([])

    if (useCache) {
      const cachedSkaters = getCachedData(url)
      if (cachedSkaters) {
        setSkaters(cachedSkaters)
      }
    } else {
      const freshSkaters = await getFreshData(url, useCache)
      setSkaters(freshSkaters)
    }
  }

  return (
    <div>
      <div>{skaters.map(renderSkater)}</div>
      <button onClick={getSkaters}>Load</button>
    </div>
  )
}

export default Skaters

Great, now we can render our Skaters component, either displaying a list of skaters from the cache or requesting a fresh copy from the API. There are a couple of bugs here though.

We can't actually display skaters from the cache if we have not yet made a request for fresh skaters and written them to the cache.
Once we have written the skaters to the cache once, they are there forever. We can never overwrite them or get fresh skaters if the API updates.

Something that will fix both of these problems, and improve our user experience significantly is making a request for the cached version first and then requesting the fresh copy regardless of whether it was in the cache or not. This means if we have a cached version, it will display immediately and when fresh content is available it will automatically update the UI. This sounds complicated but all we really do is remove our else wrapping the fresh request logic.

import React, { useState } from 'react'
import { getCachedData, getFreshData } from './utils/request'

const url = 'https://thps.now.sh/api/skaters'

const renderSkater = ({ name, stance }) => (
  <div key={name}>
    <p>
      {name} - {stance}
    </p>
  </div>
)

const Skaters = ({ useCache }) => {
  const [skaters, setSkaters] = useState([])

  const getSkaters = async () => {
    setSkaters([])

    if (useCache) {
      const cachedSkaters = getCachedData(url)
      if (cachedSkaters) {
        setSkaters(cachedSkaters)
      }
    }

    const freshSkaters = await getFreshData(url, useCache)
    setSkaters(freshSkaters)
  }

  return (
    <div>
      <div>{skaters.map(renderSkater)}</div>
      <button onClick={getSkaters}>Load</button>
    </div>
  )
}

export default Skaters

Awesome! Now our users will see the cached version immediately, and receive any updates once the API responds. Here is a gif demonstrating what this looks like.

As you can see, we can't provide the cached version the first time our users visit the page, but everytime they come back to see those sweet sweet skater stats, we can make the experience feel much more responsive!

Check out the live version of this example or the GitHub repo to see how it all clicks together!

Note: You will need to clear local storage in the dev tools to see the first request again in the cached version (right).

In the next blog we will look at abstracting the getCachedData() and getFreshData() into hooks that we can use in any application!