DEV Community: Mike Cavaliere

Multiple Parallel AI Streams with the Vercel AI SDK

Mike Cavaliere — Wed, 10 Jul 2024 14:10:42 +0000

The Vercel AI SDK makes it easy to interact with LLM APIs like OpenAI, Anthropic and so on, and stream the data so it shows up in your web app rapidly as it loads. In this article we’ll learn how to run multiple prompts at the same time and see their results in parallel.

TL;DR: GitHub Repo is here.

Why would I want to do this?

It’s not uncommon in a web app to want to run multiple data-fetching requests at the same time. For example, in a hypothetical blogging system, when the dashboard interface loads, we might want to fetch the user’s profile data, posts they’ve created, and other user’s posts they’ve favorited all at the same time.

If the same dashboard was making requests to OpenAI at the same time, we might want to simultaneously ask OpenAI for tips on improving the user’s profile, and an analysis of their latest post at the same time. In theory we could use dozens of AI requests in parallel if we wanted to (even from completely different platforms and models), and and analyze information, generate content, and do all types of other tasks at the same time.

Installation & Setup

You can clone the GitHub repo containing the final result here.

To set up from scratch:

Follow the Next.js App Router Quickstart. Just the basics; generate the app, install dependencies, and add your OpenAI API key.
Install and set up shadcn/ui.

Setting up basic UI

The main component that does all the work will contain a form and some containers for the output. Using some basic shadcn-ui components, the form will look like this:

export function GenerationForm() {
    // State and other info will be defined here...

        return (
        <form onSubmit={onSubmit} className="flex flex-col gap-3 w-full">
          <div className="inline-block mb-4 w-full flex flex-row gap-1">
            <Button type="submit">Generate News & Weather</Button>
          </div>

          {isGenerating ? (
            <div className="flex flex-row w-full justify-center items-center p-4 transition-all">
              <Spinner className="h-6 w-6 text-slate-900" />
            </div>
          ) : null}

          <h3 className="font-bold">Historical Weather</h3>
          <div className="mt-4 mb-8 p-4 rounded-md shadow-md bg-blue-100">
            {weather ? weather : null}
          </div>

          <h4 className="font-bold">Historical News</h4>
          <div className="mt-4 p-4 rounded-md shadow-md bg-green-100">{news ? news : null}</div>
        </form>
      )
}

You can see that we have a few things here:

A form
A loading animation (and an isGenerating flag for showing/hiding it)
A container for rendering weather content
A container for rendering news content

For now you can hardcode these values; they’ll all be pulled from our streams.

Setting up the React Server Components (RSCs)

The streamAnswer server action is what will do the work of creating and updating our streams.

The structure of the action is this:

export async function streamAnswer(question: string) {
    // Booleans for indicating whether each stream is currently streaming
  const isGeneratingStream1 = createStreamableValue(true);
  const isGeneratingStream2 = createStreamableValue(true);

  // The current stream values
  const weatherStream = createStreamableValue("");
  const newsStream = createStreamableValue("");

    // Create the first stream. Notice that we don't use await here, so that we
    //  don't block the rest of this function from running.
    streamText({
        // ... params, including the LLM prompt
  }).then(async (result) => {
          // Read from the async iterator. Set the stream value to each new word
          //  received.
      for await (const value of result.textStream) {
        weatherStream.update(value || "");
      }
    } finally {
        // Set isGenerating to false, and close that stream.
      isGeneratingStream1.update(false);
      isGeneratingStream1.done();

      // Close the given stream so the request doesn't hang.
      weatherStream.done();
    }
  });

  // Same thing for the second stream.
    streamText({
        // ... params
  }).then(async (result) => {
      // ...
  })

  // Return any streams we want to read on the client.
  return {
    isGeneratingStream1: isGeneratingStream1.value,
    isGeneratingStream2: isGeneratingStream2.value,
    weatherStream: weatherStream.value,
    newsStream: newsStream.value,
  };
}

Writing the client code

The form’s onSubmit handler will do all the work here. Here’s the breakdown of how it works:

"use client";

import { SyntheticEvent, useState } from "react";
import { Button } from "./ui/button";
import { readStreamableValue, useUIState } from "ai/rsc";
import { streamAnswer } from "@/app/actions";
import { Spinner } from "./svgs/Spinner";

export function GenerationForm() {
    // State for loading flags
  const [isGeneratingStream1, setIsGeneratingStream1] = useState<boolean>(false);
  const [isGeneratingStream2, setIsGeneratingStream2] = useState<boolean>(false);

  // State for the LLM output streams
  const [weather, setWeather] = useState<string>("");
  const [news, setNews] = useState<string>("");

  // We'll hide the loader when both streams are done.
  const isGenerating = isGeneratingStream1 || isGeneratingStream2;

  async function onSubmit(e: SyntheticEvent) {
    e.preventDefault();

    // Clear previous results.
    setNews("");
    setWeather("");

        // Call the server action. The returned object will have all the streams in it.
    const result = await streamAnswer(question);

    // Translate each stream into an async iterator so we can loop through
    //  the values as they are generated.
    const isGeneratingStream1 = readStreamableValue(result.isGeneratingStream1);
    const isGeneratingStream2 = readStreamableValue(result.isGeneratingStream2);
    const weatherStream = readStreamableValue(result.weatherStream);
    const newsStream = readStreamableValue(result.newsStream);

        // Iterate through each stream, putting its values into state one by one.
        //  Notice the IIFEs again! As on the server, these allow us to prevent blocking
        //   the function, so that we can run these iterators in parallel.
    (async () => {
      for await (const value of isGeneratingStream1) {
        if (value != null) {
          setIsGeneratingStream1(value);
        }
      }
    })();

    (async () => {
      for await (const value of isGeneratingStream2) {
        if (value != null) {
          setIsGeneratingStream2(value);
        }
      }
    })();

    (async () => {
      for await (const value of weatherStream) {
        setWeather((existing) => (existing + value) as string);
      }
    })();

    (async () => {
      for await (const value of newsStream) {
        setNews((existing) => (existing + value) as string);
      }
    })();
  }

  return (
    // ... The form code from before.
  );
}

Other fun things to try

Streaming structured JSON data instead of text using streamObject()
Streaming lots more things in parallel
Streaming from different APIs at once
Streaming different models with the same prompts for comparison (e.g., Cohere, Anthropic, Gemini, etc.)
Streaming the UI from the server (using createStreamableUI() )

React vs React Native: How Different Are They, Really?

Mike Cavaliere — Mon, 19 Dec 2022 19:39:18 +0000

Over the years that I’ve been working with React (circa 2014) and React Native (circa 2016), I’ve had everyone from engineers to CEOs to product people ask me some form of the question, "What are the differences between React and React Native?" Developers want to know how much they have to learn, managers want to know how much their team’s velocity will be affected, and what other considerations there are.

TL;DR: mobile application development is a very different world from browser-based application development, so naturally developers will need to learn new tools, paradigms and techniques. Even though the core React API is the same, you're coding for smartphones and tablets instead of browsers, and those have a very different set of rules. In parallel, managers will have to provision some new services for their React Native projects to run effectively. But there’s a lot more to it; I encourage you to read on.

Things that translate over well from React Web to React Native

There’s a good amount of knowledge that will translate for React web developers. Enough, in fact, that this is why React Native is such a compelling choice for web engineers to start working on mobile applications. Here are things that React developers will not have to learn from scratch when starting to work with React Native.

Core React API and concepts

A component is a component is a component. Class-based components and functional components operate the same way in React Native as on the web. You still should think in React apply all of your React best practices like using composition and lifting state up.

React architectural concepts

State management, orchestrating HTTP requests, synchronizing client and server state: all these things will apply to React Native. The differences will only arise when the device layer comes into play (for example, if you have to store data on the client, window.localStorage doesn’t exist, but AsyncStorage does.)

React performance optimization best practices

Many of the JavaScript-based performance optimization techniques that are specific to React will still apply. Namely, the use of React.memo(), useMemo() and useCallback() operate identically. Anything related to build optimization will be different, and React Native requires some additional attention to optimization (more on that below).

Third-party tools

Many tools for monitoring, error reporting, analytics, etc. have SDKs that translate over well. I'm thinking Sentry, Datadog, MixPanel, others.

Pure JavaScript libraries

npm packages that don’t rely on native code or CSS will also work well in React Native. Yes you can still use your beloved lodash, axios, react-hook-form and React Query / Tanstack Query. State management libraries like Redux, MobX, XState, and so on are fine as well.

Things that are quite different between React Web and React Native

As you’ll notice, this section is a lot longer than the previous one 😁 React development principles will certainly translate over to native well; but it’s important to realize that React isn’t a magic bullet. Developers will still need to learn plenty about mobile development in general, and specifically how to do things well in RN.

Hardware

The biggest paradigm shift when going from React web to React Native is perhaps the obvious one: you’re now building apps for completely different devices that run in a completely different environment. Mobile hardware can do things browsers can't, so that's a perk. But it also means new learning. Push notifications, in-app purchases and haptics are things that are now natively supported and have their own APIs for.

Layout and Styling

React Native uses the Yoga engine under the hood, which allows you to use CSS properties to layout your React Native UI in a way that translates really well. Layout in Yoga is limited to Flexbox and absolute/relative positioning, however; there is no CSS grid and no display attribute. This keeps things simpler and more performant, but if developers are accustomed to using other layout techniques on the web, they’ll need to adjust to this new limitation.

React Native does come packaged with block-level (<View> ) and inline (<Text>) which can be thought of to parallel <div> and <span> in html. They support a fair bit of common CSS properties: borders, backgrounds, typography and so on are all in there. But as before, don’t expect fancier properties like calc() to be available.

Library availability

CSS-based UI libs don't make sense on mobile; your new options include NativeBase, React Native Elements and others). Some web-based UI libs do have RN siblings though - such as React Native Material and React Native Paper (for Material-UI), and tailwind-rn (for Tailwind). This just means new decisions to make, some learning, and new paradigms for how to use the new libs.

Library Differences

A great many React libraries do indeed work on React Native as well, which is a great perk for the platform. It’s worth noting that some will have slight configuration changes to make them work on React Native. This is understandable since the environments are different (DOM vs no DOM, hardware differences, and so on).

react-hook-form, for example, uses <form> tags on the web. But since HTML doesn’t exist in React Native, react-hook-form requires developers to wrap their forms in a <Controller> component, which does work in RN.

Navigation

As a user, you already know that moving around a smartphone app is completely different than on a web app. react-navigation is the most common navigation lib for mobile (runner-up: react-native-navigation). Both are fairly different from react-router, Next.js's router, and so on. Not only do developers have to learn new APIs for this, they’ll have to think differently to plan out complex navigation properly. It’s all very achievable, but I wouldn’t advise assuming that the effort is trivial.

Development and developer experience (DX)

Some development tools for the web are similar (Chrome debugger, mostly) to those for React Native, but other aspects are very different (working with the metro bundler, using Flipper, AsyncStorage debugging, more). Some techniques developers will use are the same (breakpoints and console logging), but others are different (knowing when to restart the packager vs reinstall the app on device).

Testing while you develop anything is crucial; the iOS simulator and Android emulators let you simulate a variety of devices. Naturally the iOS sims only run natively on a Mac, which is worthy of note, as this is a roadblock for any dev team that uses Windows or Linux and doesn’t have a Mac readily available.

Dev machine setup is also more time-consuming, and can be quirky. Devs will need to have both XCode and Android Studio installed beforehand, so that builds will compile and emulators on both platforms exist for running code. watchman is also a prerequisite along with rvm (or rbenv) and CocoaPods — but it’s important to note that our beloved Expo makes a lot of this way easier. (It’s one of the many reasons we use it for all of our React Native projects at Echobind.)

Lastly, both the iOS simulator and Android emulators have limited or no support for certain features of smartphones: haptics, geolocation, app store purchases, and the camera, just to name a few. It’s best to have at minimum one real device for each operating system to properly test with while developing.

Performance optimization

Besides React optimization (which is arguably more necessary on mobile), developers will now have different hardware and a different internal architecture to work with. They’ll have to know about the JS and UI threads, and different (and IMO more challenging) ways to avoid jank and prevent crashing. Memory and energy consumption are now even more important, since mobile devices are more limited in these areas.

And they’ll have to use new performance analysis tools. Have a look at React Native’s performance overview page just to get a sense of the approach.

The stakes are also higher for both devs and product teams on mobile - crashes and bad performance are huge killers of App Store reviews.

Other React Native differences that engineering leads and managers should know about

Besides all of the technical differences, development process is different for web vs mobile apps, so naturally it also will be for React vs React Native apps. So here are some of the process-related considerations for how your dev team’s workflow will be affected when transitioning from React web to mobile development.

Deployments and releases

You can deploy to prod without restriction on web; on mobile you have to deal with both app stores, which can be cumbersome and slow especially for the initial release/approval process. You have to fill out lots of documentation before the first time you release to production.

Even distributing a beta version of your app for non-developers to test, either for formal QA or for casual testing, can be a process. It’s not as easy as just deploying anymore; depending on your distribution method and which app store you’re working with (more so for iOS distributions than Google, FWIW) you may have to add each tester to the portal manually, then kickoff another build for them to be able to access it.

We use tools to simplify all of this at Echobind (like Expo Application Services, GitHub Actions and others), but we make sure to accommodate time for this in our project budgets since it can be non-trivial to set up.

Testing and QA

Unit testing with Jest and React)Testing Library is similar on React Native; developers use the same syntax (and the React Native version of React Testing Library), so there isn’t a huge paradigm shift there. Developers will have to mock out different third-party libraries on native, though, since unit test suites won’t be able to run native code.

End-to-end testing is completely different on React Native, however. None of the Selenium-based E2E testing tools will work; neither will newer tools like Cypress or Playwright. You may have expected this - these are all DOM-based, and there’s no DOM in React Native. So instead developers will have to learn Detox or Appium.

Also since it’s mobile, you can’t avoid manual testing completely, no matter how much you automate. Plan to allocate time for testing setup in each project, since TestFlight and Play Store configuration are non-trivial (especially the former). Once again, EAS makes this easier, so save yourself frustration and use it.

And with every release, plan time to manually test each build on each platform.

DevOps

Continuous Integration/Continuous delivery are a different animal for React Native apps as well. You may end up making different choices on services and tools to use, and setting them up separately.

Firstly, keep in mind that if you’re building for both Android and iOS, you’ll need to run your CI builds on a Mac (at least for the iOS builds). Which means that you’re gonna pay a LOT more for your build runs than on Linux boxes. Look at EC2’s cheapest mac instance compared to it’s cheapest Linux instance (which has more powerful hardware):

And similarly, GitHub Actions’ per-minute pricing for Linux vs MacOS instances:

A MacOS instance costs 2.5 times as much Linux instance with almost three times the processing power; but compared to a Linux instance with one less CPU core, the Mac instance costs 10 times as much (!!).

That’s just a visual way to say that you’ll need to think through your CI setup carefully, for more reasons than one.

At Echobind for example, we typically setup Expo Application Services (EAS) and GitHub Actions for our React Native client projects and internal projects. Builds get triggered by a PR merge to main; GitHub Actions runs JS-related automation (linting, typechecking, unit tests, etc), then hands off control to EAS to do the actual builds and releases.

For us, this setup provides the a good balance of ease of setup, features, DX and reasonable costs. It also makes testing a lot easier since people can scan install builds to their phones just by scanning a QR code. But one CI setup doesn’t fit all projects, so choose yours carefully.

This is a fairly thorough list of differences between React for the web and React Native; please keep all of these things in mind when starting to learn React Native (if you’re a developer) or transitioning your dev team to React Native (if you’re a manager). Planning accordingly will save you a lot of time and frustration, and reduce surprises.

Originally published at https://echobind.com.

Comparing Previous useEffect Values in React

Mike Cavaliere — Tue, 07 Dec 2021 16:55:43 +0000

With functional components now being the standard in React, we lost one notable perk of using the lifecycle hooks (such as componentDidUpdate()) of class-based components: the intrinsic ability to compare previous values to new ones.

If I wanted to respond to a component's "count" change for example, I could do something like:

componentDidUpdate(prevProps, prevState) {
  if (this.props.count > prevProps.count) {
    // Count incremented! Do something.
  }
}

I came across the need to do this while working on Emoji Battle yesterday—I wanted to show an animation anytime an emoji's vote count incremented.

Luckily Stack Overflow had a great solution as usual, which I turned into a hook I'll probably reuse in the future.

Basically you create a very simple custom hook that uses a React ref to track the previous value, and refer to it in the useEffect.

function usePreviousValue(value) {
  const ref = useRef();
  useEffect(() => {
    ref.current = value;
  });
  return ref.current;
}

Based on this, I used it to increment my Emoji counter as follows:

export const Count = ({ value }) => {
  const controls = useAnimation();
  const previousValue = usePreviousValue(value);

  useEffect(() => {
    if (!previousValue || value > previousValue) {

      // Trigger the framer-motion animation
      controls.start({
        scale: [1, 1.5, 1],
        transition: {
          duration: 0.5,
        },
      });
    }
  }, [value]);

Try this usePreviousValue hook out next time you need to track value changes in React functional components.

NextAuth.js Intro [3 of 3]: Adding Access Control

Mike Cavaliere — Fri, 21 May 2021 16:51:12 +0000

NextAuth.js Intro [3 of 3]: Adding Access Control

In this series we’re exploring different patterns for using next-auth with Next.js for easy and powerful login and sign up for your app. In this next installment we’ll talk about requiring the user to be logged in to see parts of your app.

Links:

GitHub Repo
Interactive demo on Vercel

In most apps, there are features and screens for which we want to require the users to be logged in. For our example app, we’ll assume the user needs some kind of personal dashboard they’ll see only when logged in (since, we can’t know whose data to put on the dashboard unless we know that (1) they’re logged in and (2) who they are),

Create a restricted page

First we’ll create a dashboard page for our app with some content in it. We’ll require that a user log in to see this page.

In /pages/dashboard.js we'll add some fake-but-neat-looking sample content using Chakra-UI. This can be any sample content, you don’t have to use Chakra-UI. (But if you do, make sure to install it first naturally.)

    export default function Dashboard() {
      return (
        <Flex
          direction='column'
          align='center'
          justifyContent='center'
          minHeight='80vh'
        >
          <Heading mb={3}>My Dashboard</Heading>

          <Stack>
            <Badge mb={2}>Things</Badge>
            <Badge mb={2} colorScheme='green'>
              Stuff
            </Badge>
            <Badge mb={2} colorScheme='red'>
              Foo
            </Badge>
            <Badge mb={2} colorScheme='purple'>
              Bar
            </Badge>
            <Badge mb={2} colorScheme='blue'>
              Baz
            </Badge>
          </Stack>
        </Flex>
      );
    }

Looking good! Chakra-UI is pretty great.

Now let’s do a check to make sure the user is logged in, and redirect otherwise. We’ll do this with 2 great helpers: the getSession() function from next-auth, and Next.js's getServerSideProps function.

    export async function getServerSideProps({ req, res }) {
      const session = await getSession({ req });

      if (!session) {
        return {
          redirect: {
            destination: '/',
            permanent: false,
          },
        }
      }

      return {
        props: {},
      };
    }

Next.js’s getServerSideProps function is executed on every page load, before rendering the page. As a convention, it will allow you to return a redirect object to tell the browser to redirect to another page. Here we call getSession to check that a user's logged in, and return the redirect object if not. If they are logged in, we return an empty props object which will pass through to the page renderer seamlessly.

Restricting a page by hiding it

The above works well if the user knows the address of the page, and is trying to see it without being logged in. This is an effective measure, since there’s no way they can get in.

But why show them a link to it in the first place? We should only show links to restricted pages when the user is logged in.

Let’s start by adding a Navbar component to /components/Navbar/index.jsx:

    export const Navbar = ({ children }) => (
      <Flex
        w='100%'
        bg='green.800'
        px={5}
        py={4}
        color='white'
        justifyContent='space-between'
        alignItems='center'
      >
        <Flex flexDirection='row' justifyContent='center' alignItems='center'>
          <Link href='/'>Next.js Auth & Access Control Demo</Link>
        </Flex>
        <Box>{children}</Box>
      </Flex>
    );

It’s just some styling, and has the ability to pass in children which is important since that makes it fairly composable. That is, we can pass it any children we want and it’ll still work, which also means we can wrap it easily with other components that pass specific children to it.

Now we’ll want a logged in and logged out version of it:

    export const LoggedOutNavbar = () => <Navbar />;

    export const LoggedInNavbar = () => (
      <Navbar>
        <Link href='/dashboard' mr={4}>
          My Dashboard
        </Link>
        <Link onClick={signOut}>Log out</Link>
      </Navbar>
    );

The logged in links to the dashboard we created, and also shows a Log out link (which we shouldn’t show when someone is logged in either).

Now how do we get them to show conditionally? Easy. We export another component that takes in the session as a prop. If it exists, we show the logged-in version of the Navbar. Otherwise we show the logged-out version.

    export const NavbarWithLoginState = ({ session }) =>
      session ? <LoggedInNavbar /> : <LoggedOutNavbar />;

Then inside our DefaultLayout component we add the NavbarWithLoginState, and grab the session from the useSession hook:

    import { Box } from '@chakra-ui/react';
    import { NavbarWithLoginState } from '../../components/Navbar';
    import { useSession } from 'next-auth/client';

    export const DefaultLayout = ({ children }) => {
      const [session] = useSession();

      return (
        <Box>
          <NavbarWithLoginState session={session} />
          {children}
        </Box>
      );
    };

    export default DefaultLayout;

Boom. Only logged in users will see the dashboard link, so there’s a second layer of protection on the private page.

Logged-out homepage

Logged-in homepage

Adding private data and restricting the API route

So we’re redirecting anyone that views the dashboard in the browser who isn’t logged in. But the dashboard will inevitably need some data, which we’ll have to create an API route for. What if someone were to request that API route directly, without being logged in?

We don’t want people fiddling with that endpoint without having at least logged in first. So our API route will need to check that the user is logged in as well. In general the back-end is even more important to restrict, since that’s where all valuable data will come from. So for security reasons and other reasons, let’s put a redirect there as well.

Let’s add an API route to send us some data:

    // pages/api/dashboard.js

    const data = [
      {value: 'Stuff', colorScheme: 'green'},
      {value: 'Foo', colorScheme: 'red'},
      {value: 'Bar', colorScheme: 'purple'},
      {value: 'Baz', colorScheme: 'blue'},
    ];

    export default (req, res) => {
      res.statusCode = 200
      res.json(data)
    }

If we hit this endpoint in Postman, we’ll see the data sent back in JSON:

Then we can have the dashboard page use this data with a simple React fetch/setState pattern. The dashboard will look exactly the same, but it will now render the data dynamically.

    import React, { useState, useEffect } from 'react'
    import { Badge, Flex, Heading, Stack } from '@chakra-ui/react';
    import { getSession } from 'next-auth/client';

    const fetchThings = async () => {
      const response = await fetch('/api/dashboard', {
        headers: {
          'Content-Type': 'application/json',
          'Accept': 'application/json',
        }
      });
      const json = await response.json();

      if (!response.ok) {
        throw json
      }

      return json;
    }

    export default function Dashboard() {
      const [things, setThings] = useState([]);

      useEffect(() => {
        fetchThings().then(things => {
          setThings(things)
        });
      }, [])

      return (
        <Flex
          direction='column'
          align='center'
          justifyContent='center'
          minHeight='80vh'
        >
          <Heading mb={3}>My Dashboard</Heading>

          <Stack>
            {things.map((thing) => {
              return (
                <Badge mb={2} colorScheme={thing.colorScheme} key={thing.value}>
                  {thing.value}
                </Badge>
              )
            })}
          </Stack>
        </Flex>
      );
    }

    export async function getServerSideProps({ req, res }) {
      const session = await getSession({ req });

      if (!session) {
        return {
          redirect: {
            destination: '/',
            permanent: false,
          },
        }
      }

      return {
        props: {},
      };
    }

Now let’s require a session in the API route. next-auth makes that easy from an API route as well. We just pull in the getSession helper from next-auth/client and pass it our request:

    import { getSession } from 'next-auth/client'

    const data = [
      {value: 'Stuff', colorScheme: 'green'},
      {value: 'Foo', colorScheme: 'red'},
      {value: 'Bar', colorScheme: 'purple'},
      {value: 'Baz', colorScheme: 'blue'},
    ];

    export default async (req, res) => {
      const session = await getSession({req});
      if (!session) {
        res.redirect(307, '/')
        return
      }
      res.status(200).json(data)
    }

Now you’ll see below that the postman request will return a 307 for temporary redirects.

NOTE: When testing in Postman, make sure you have automatic redirects turned off in the settings, or you’ll see a bunch of HTML as your response.

Great. Now we’ve locked down the dashboard from both the front-end and the back-end. Go celebrate with your beverage of choice 🎉

This article was originally published on the Echobind Blog.

NextAuth.js Intro [2 of 3]: Magic Link Email Authentication

Mike Cavaliere — Thu, 20 May 2021 17:27:07 +0000

From my previous article in this series, we know that one-click signup / sign in with next-auth using Google, GitHub, Facebook, or any other provider is pretty easy. Another way many apps like to allow people to sign in easily is via use of a “magic link.” The user will enter their email address and receive an email with a link they can click to login to the app.

As you may have guessed, that’s pretty easy with next-auth too 😉 Here’s how to do it.

Shameless Plug

I teach you to use NextAuth.js along with Prisma, Stripe, Chakra-UI, React Hook Form, Vercel and Railway to build a SaaS app in my book, Cut Into The Jamstack.

Create and structure a database

Database integration is required for email auth in next-auth currently, so we need to get this running first.

First we need a database. PostgresSQL is our default relational DB choice at Echobind, so that’s what we’ll use for this example. I use Postgres.app for Postgres on localhost, and often start with a Heroku Postgres DB on the Hobby plan for the deployed version of small projects like this.

Connect to your database using psql or a client like Postico.

First create a database:

CREATE DATABASE "next-auth-example"

The database needs some structure to hold user information in it, which next-auth provides on their website. Run these CREATE TABLE statements and that'll do the trick.

CREATE TABLE accounts  
 (  
 id SERIAL,  
 compound_id VARCHAR(255) NOT NULL,  
 user_id INTEGER NOT NULL,  
 provider_type VARCHAR(255) NOT NULL,  
 provider_id VARCHAR(255) NOT NULL,  
 provider_account_id VARCHAR(255) NOT NULL,  
 refresh_token TEXT,  
 access_token TEXT,  
 access_token_expires TIMESTAMPTZ,  
 created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,  
 updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,  
 PRIMARY KEY (id)  
 );

CREATE TABLE sessions  
 (  
 id SERIAL,  
 user_id INTEGER NOT NULL,  
 expires TIMESTAMPTZ NOT NULL,  
 session_token VARCHAR(255) NOT NULL,  
 access_token VARCHAR(255) NOT NULL,  
 created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,  
 updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,  
 PRIMARY KEY (id)  
 );

CREATE TABLE users  
 (  
 id SERIAL,  
 name VARCHAR(255),  
 email VARCHAR(255),  
 email_verified TIMESTAMPTZ,  
 image TEXT,  
 created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,  
 updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,  
 PRIMARY KEY (id)  
 );

CREATE TABLE verification_requests  
 (  
 id SERIAL,  
 identifier VARCHAR(255) NOT NULL,  
 token VARCHAR(255) NOT NULL,  
 expires TIMESTAMPTZ NOT NULL,  
 created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,  
 updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,  
 PRIMARY KEY (id)  
 );

CREATE UNIQUE INDEX compound_id  
 ON accounts(compound_id);

CREATE INDEX provider_account_id  
 ON accounts(provider_account_id);

CREATE INDEX provider_id  
 ON accounts(provider_id);

CREATE INDEX user_id  
 ON accounts(user_id);

CREATE UNIQUE INDEX session_token  
 ON sessions(session_token);

CREATE UNIQUE INDEX access_token  
 ON sessions(access_token);

CREATE UNIQUE INDEX email  
 ON users(email);

CREATE UNIQUE INDEX token  
 ON verification_requests(token);

Your database will now look like this (screenshot from Postico):

Connect database and enable email provider in next-auth

Next we need to add the database adapter to our repo.

yarn add pg

or npm install --save pg

Add the connection string to your .env file, so next-auth knows where to look for it.

DATABASE_URL="postgres://my-root-user:my-root-pass@localhost:5432/next-auth-example?schema=public"

Then uncomment this line in pages/api/auth/[...nextauth].js so that next-auth knows where the database is:

database: process.env.DATABASE_URL,

Now we tell next-auth that we want to use email for authentication in that same file. In the array of providers, add:

Providers.Email({  
 server: process.env.EMAIL_SERVER,  
 from: process.env.EMAIL_FROM,  
}),

Set default theme

In next-auth 3.2, you’re able to set your sign in pages to use a light or dark theme, or to use the system theme (which is the default). The only quirk with this is that if your system is set to a dark theme, the background of the sign in page will be dark but so will the text, rendering it invisible!

As an easy remedy, I set the theme to light . in pages/api/auth/[...nextauth].js :

const options = {  
 theme: 'light',  
 // ... other options  
};

Connect an email provider

Create an account with an email service so that your app can send emails out transactionally. My default is usually SendGrid, but there are tons of others. With any provider you’ll have to create an account, verify an email address to send from, and get the SMTP credentials from your account.

Once you have those credentials, you can add them to your .env file. My SendGrid configuration looks like this:

EMAIL_SERVER=smtp://apikey:BIG-LONG_CRYPTIC_STRING:587  
EMAIL_FROM=your-verified-sending-email@yourdomain.com

There are different ways you can specify this configuration as well, see the docs.

Restart and test

Restart your local server for the settings to take effect, visit your sign in screen and log in with an email. You should get an email like the below:

That’ll take you to the landing page, now signed in 🎉

One thing to note is that when logging in with email, we don’t have any other information about the user automatically, so their name in the screenshot above is blank since it doesn’t exist. A small conditional will change that.

In pages/index.js we just update our conditional:

{session && session.user && session.user.name && (  
 <h3>Logged in as {session.user.name}</h3>  
)}

And now the text makes a lot more sense.

So far we’ve got two methods for logging in fast, and easily in Next.js using next-auth. Later in this series we'll explore what you can do with user information now that the user is logged in.

This article was originally published on the Echobind Blog.

NextAuth.js Intro [1 of 3]: One-Click Signup

Mike Cavaliere — Tue, 23 Mar 2021 20:01:08 +0000

One-click signup using Google, Facebook, or any other existing provider is a desirable feature for most web applications since it makes it faster and easier for people to create accounts. Integrating one-click signup with
Next.js or any other isomorphic web framework can take a fair bit of work, but the fantastic [next-auth](https://next-auth.js.org/) package makes it incredibly easy and flexible.

In this article, I'll show you how to set up one-click signup in a Next.js application via Google and GitHub, and how to easily force users to be logged in to see your content.

Shameless Plug

I teach you to use NextAuth.js along with Prisma, Stripe, Chakra-UI, React Hook Form, Vercel and Railway to build a SaaS app in my book, Cut Into The Jamstack.

Scaffold app and add dependencies

Let's generate our app as we normally would, then add next-auth.

yarn create next-app next-auth-example
yarn add next-auth

Now we have our app scaffold; nothing surprising here if you've ever done this before.

Create Provider Credentials

Create an account for every provider you want users to be able to log in to your site with. I'm using Google and GitHub in this example, but next-auth supports a ton so go crazy.

From each provider, you'll need to get an access key and secret. Those will go in your local .env file as follows:

GOOGLE_CLIENT_ID=123123123
GOOGLE_CLIENT_SECRET=abcabcabc
GITHUB_CLIENT_ID=123123
GITHUB_CLIENT_SECRET=abcabc

Later when deploying to Vercel, these will go into Vercel environment variables as well.

Configure next-auth

Ok let's get to the code! 🎉

Following https://next-auth.js.org/getting-started/example, first add their route file which makes their magic integration happen. Then add any providers you want. Below i've added Google and GitHub.

Configure next-auth

Ok let's get to the code! 🎉

Following https://next-auth.js.org/getting-started/example, first add their route file which makes their magic integration happen. Then add any providers you want. Below I've added Google and GitHub.

import NextAuth from 'next-auth';
import Providers from 'next-auth/providers';

const options = {
  // Configure one or more authentication providers
  providers: [
    Providers.GitHub({
      clientId: process.env.GITHUB_CLIENT_ID,
      clientSecret: process.env.GITHUB_CLIENT_SECRET,
    }),
    Providers.Google({
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    }),
  ],

  pages: {
    signIn: '/auth/signIn',
  },

  // A database is optional, but required to persist accounts in a database
  // database: process.env.DATABASE_URL,
};

export default NextAuth(options);

Add session and theme to application state

Now we'll add the next-auth session state to our _app.js so that it's available everywhere via the useSession hook. We'll also add Chakra's theme information to the application in the same manner, so we can style everything pretty easily.

import { Provider } from 'next-auth/client';

function MyApp({ Component, pageProps }) {
  return (
    <Provider session={pageProps.session}>
      <Component {...pageProps} />
    </Provider>
  );
}

export default MyApp;

One last .env variable

next-auth also requires the NEXTAUTH_URL environment variable for some functionality, so your .env file should now look something like this.

GOOGLE_CLIENT_ID=123123123
GOOGLE_CLIENT_SECRET=abcabcabc
GITHUB_CLIENT_ID=123123
GITHUB_CLIENT_SECRET=abcabc
NEXTAUTH_URL=http://localhost:3000

Add authentication!

Now that the setup is complete, let's give people the ability to sign in and sign out.

Our index.js will now look like this:

import styles from '../styles/Home.module.css';
import { useSession, signIn, signOut } from 'next-auth/client';

export default function Home() {
  const [session] = useSession();

  return (
    <div className={styles.container}>
      <main className={styles.main}>
        <h1 className={styles.title}>This is the welcome page.</h1>

        <h2>You're currently {session ? 'logged in.' : 'logged out.'}</h2>

        {session ? (
          <button onClick={signOut}>Log out.</button>
        ) : (
          <button onClick={signIn}>Log in.</button>
        )}
      </main>
    </div>
  );
}

Here are the notable pieces:

First we call the useSession hook to determine login status.

The next-auth useSession hook is multi-purpose. By returning an object in the session variable (and not a falsy value), it tells us whether the person is logged in or logged out respectively. It can also return a second loading boolean to tell us whether it's currently checking session status; we're not doing it in this example, but that's useful if you want to show a loading spinner while it's checking.

Then we add the Log in and Log out links that trigger the default signIn and signOut functions provided by next-auth. Now we've got basic one-click login functionality already. 🎉

The other purpose of useSession is getting information about the logged-in user. If session exists, it'll have user information inside of it. So if we add this line to the index.js page:

{session && session.user && <h3>Logged in as {session.user.name}</h3>}

We'll now be able to display the user's name when they're logged in:

That's it. In a matter of minutes you were able to allow a user to create an account on your site with a few clicks.

Here's some even better news: next-auth can do a lot more. In subsequent articles we'll talk about how to control access to private information, allow signing up via email with a magic link, mashup Google profile info with your app's custom data, and more.

This article originally appeared on the Echobind Blog.

Creating Your Own JAMStack Blog in No Time with Next.js and Bison

Mike Cavaliere — Tue, 20 Oct 2020 14:09:08 +0000

Next.js is a fantastic framework for building fast and powerful JAMStack web applications — that’s one reason among many that it’s our go-to JavaScript framework at Echobind. We’ve wrapped Next.js with a set of tools we regularly use into a JAMStack generator called Bison, which makes Next.js even more powerful. In this article, I’ll show you the steps to building a custom blog with Bison and Next.js.

If you want to jump right to the code, here’s the repo on GitHub.

Run the Bison Generator

yarn create bison-app bison-blog

This will generate your app skeleton, run yarn installand create a Git repo automatically.

Set up your database

You’ll want to check the latest README for full steps, but it’s as simple as making sure PostgresSQL is running (I highly recommend Postgres.app) and running yarn db:setup .

You’ll be asked a few questions during setup, and it’ll do the rest of the work for you.

Start the app

Run yarn dev from the directory you just created, and visit http://localhost:3000. Your app is running, and you should see a screen like the one below. We’re in business.

Create a user account

Bison comes pre-packaged with a simple user authentication mechanism, so signing in or signing up is a cinch.

First, tap Login to get to the login screen, then click Sign Up.

Fill out the form and submit, and you’ll be logged in and redirected to the home page.

Add some database tables

We’ll need a Posts table and model to create and list posts. Edit schema.prisma which is the source of truth for the data model. Adding a Post model is pretty easy.

Then run yarn prisma migrate save --experimental, to generate a database migration for it.

Now run the migration using yarn db:migrate .

If you look at your database using Postico or psql, you’ll see the resulting table and columns.

Generate a page for creating posts

Use Bison’s page generator to stub the /posts/new page:

yarn g:page posts/new

Generate components

We’ll need 2 React components for creating and showing posts PostList and PostForm, so we’ll generate them with Bison’s CLI commands. These wrap 👍some pre-packaged Hygen generators that Bison comes with.

yarn g:component PostList
yarn g:component PostForm

Now you’ll see these 4 new files in your folder tree:

All rightie! Let’s add some code.

Create the “New Post” form

The page container for /posts/new.tsx is quite simple; aside from styling, we add the component which we’ll build immediately after.

    import React from 'react';
    import Head from 'next/head';
    import { Heading, Flex } from '@chakra-ui/core';

    import { PostForm } from '../../components/PostForm';

    function PostsNewPage() {
      return (
        <>
          <Head>
            <title>PostsNewPage</title>
          </Head>

          <Flex direction="column" justify="center">
            <Heading size="lg">New Post</Heading>

            <PostForm />
          </Flex>
        </>
      );
    }

    export default PostsNewPage;

Create the component

Full code is here. Here are some highlights.

Bison comes packaged withreact-hook-form, so we build the form out like this:

    <form onSubmit={handleSubmit(onSubmit)}>
          <FormControl isInvalid={errors.title}>
            <FormLabel htmlFor="title">Post Title</FormLabel>
            <Input type="text" name="title" id="title" ref={register({ required: true })} />
            <FormErrorMessage>{errors.title && <span>This field is required</span>}</FormErrorMessage>
          </FormControl>

          <FormControl isInvalid={errors.body}>
            <FormLabel htmlFor="body">Post Body</FormLabel>
            <Textarea name="body" id="body" ref={register({ required: true })} />
            <FormErrorMessage>{errors.body && <span>This field is required</span>}</FormErrorMessage>
          </FormControl>

          <Button type="submit">Submit</Button>
        </form>

Because Bison also sets up nexus-plugin-prismafor us, We add a mutation to create a post like so:

    export const CREATE_POST_MUTATION = gql`
      mutation CreatePost($data: PostCreateInput!) {
        createOnePost(data: $data) {
          id
          title
          body
        }
      }
    `;

In turn, Bison’s graphql-codegen configuration sees the above and generates a nice React hook for us to plug into 🎉:

    import { useCreatePostMutation } from '../types';

We use this and a few other hooks to get our data into the form component:

    export function PostForm() {
      const { register, handleSubmit, errors } = useForm();
      const [createPost] = useCreatePostMutation();
      const router = useRouter();

      const { user: { id: userId } = {} } = useAuth();
      // ...
    }

And here’s the onSubmit handler which triggers the createPost mutation and redirects back to the homepage upon success:

    const onSubmit = async (data) => {
        // Create the post
        await createPost({
          variables: {
            data: {
              ...data,
              author: {
                connect: {
                  id: userId,
                },
              },
            },
          },
        });

        // Redirect to homepage
        await router.replace('/');
      };

Now we’ve got a form that saves a post to the database. Voila. 🚀

Create the component

Now that we’ve got data, let’s display it.

If you remember, we already ran the generator for the component. So we start by importing the into the homepage and displaying it like so:

Now we’ll need to fetch and display the posts. When fetching data with Bison, we recommend something called a “cell.” A cell is a concept borrowed from Redwood.js. It’s a declarative way of wrapping the GraphQL query together with loading, success, and error states.

yarn g:cell FetchPosts will create /cells/FetchPosts.tsx as below.

Now we’ll fill the cell out with the correct query and some formatting for the rendered posts.

Full code here. Important snips:

    export const POSTS_QUERY = gql`
      query posts {
        posts {
          id
          title
          body
        }
      }
    `;

    export const Success = ({ posts }: PostsQuery) => {
      return (
        <Stack>
          {posts.map((p) => (
            <Box p={5} shadow="md" key={p.id}>
              <Heading>{p.title}</Heading>
              {p.body}
            </Box>
          ))}
        </Stack>
      );
    };

Don’t forget to include the cell in the component:

    export function PostList() {  return <FetchPostsCell />;}

And we’re done. You now have a (very simple and basic but functioning) blog built in Next.js. Add some data and start having fun.

Conclusion

Bison is in its early stages, but is already a useful tool for kickstarting your Next.js project quickly with great stuff like Prisma, Nexus, and Hygen built-in.

If you try out this tutorial, please drop me a line with any feedback or questions. Or comment right here.

Contributor’s Bio

Mike Cavaliere is a web development veteran, personal development devotee, and ADHD/brain improvement aficionado who works as a Senior Software Engineer at Echobind.

He also blogs about software at MikeCavaliere.com and brain improvement at ADHDTechies.com.

This post originally appeared on the Echobind blog.

DEV Community: Mike Cavaliere

Multiple Parallel AI Streams with the Vercel AI SDK

Why would I want to do this?

Installation & Setup

Setting up basic UI

Setting up the React Server Components (RSCs)

Writing the client code

Other fun things to try

Further reading & links

React vs React Native: How Different Are They, Really?

Things that translate over well from React Web to React Native

Core React API and concepts

React architectural concepts

React performance optimization best practices

Third-party tools

Pure JavaScript libraries

Things that are quite different between React Web and React Native

Hardware

Layout and Styling

Library availability

Library Differences

Navigation

Development and developer experience (DX)

Performance optimization

Other React Native differences that engineering leads and managers should know about

Deployments and releases

Testing and QA

DevOps

Comparing Previous useEffect Values in React

NextAuth.js Intro [3 of 3]: Adding Access Control

NextAuth.js Intro [3 of 3]: Adding Access Control

Create a restricted page

Restricting a page by hiding it

Adding private data and restricting the API route

NextAuth.js Intro [2 of 3]: Magic Link Email Authentication

Links

Shameless Plug

Create and structure a database

Connect database and enable email provider in next-auth

Set default theme

Connect an email provider

Restart and test

NextAuth.js Intro [1 of 3]: One-Click Signup

Links

Shameless Plug

Scaffold app and add dependencies

Create Provider Credentials

Configure next-auth

Configure next-auth

Add session and theme to application state

One last .env variable

Add authentication!

Creating Your Own JAMStack Blog in No Time with Next.js and Bison

Run the Bison Generator

Set up your database

Start the app

Create a user account

Add some database tables

Generate a page for creating posts

Generate components

Create the “New Post” form

Create the component

Create the component

Conclusion

Contributor’s Bio