DEV Community: Dustin Myers

The Frontend Developer Is Dead (And That’s Good)

Dustin Myers — Wed, 25 Feb 2026 18:55:28 +0000

In 2026, “frontend developer” doesn’t mean what it used to.

And that’s a good thing.

Over the past few years, AI has moved from novelty to daily workflow. It scaffolds components, writes tests, refactors functions, and explains unfamiliar codebases in seconds. What used to take hours now takes minutes.

If your definition of frontend engineering is “write components from a design file,” then yes — AI is coming for that role.

But the job isn’t disappearing.

It’s evolving.

And the engineers who understand that evolution are becoming more valuable, not less.

AI Has Already Changed the Nature of Coding Work

We don’t have to speculate about AI’s impact — we have data.

According to GitHub’s 2023 Copilot study, developers using GitHub Copilot completed tasks up to 55% faster than those who did not use it [1]. In follow-up research, GitHub reported that developers accept around 30–40% of AI-generated suggestions in supported languages [2].

Meanwhile, McKinsey (2023) estimated that generative AI could automate 20–45% of activities in software engineering, particularly routine and boilerplate-heavy tasks [3].

What does that include?

Scaffolding UI components
Writing basic state management
Generating test stubs
Refactoring small functions
Translating design tokens to styles

That work used to represent a large portion of frontend development.

Today, it’s increasingly automated.

But that was never the highest-leverage part of the job.

AI Is Exceptional at Execution — Not at Judgment

AI generates code.

It does not own consequences.

Multiple studies highlight this distinction:

Stanford & MIT research (2023) on AI-assisted productivity showed strong gains in execution speed, but also emphasized that human oversight remains essential for quality control and decision-making [4].
Gartner (2024) projected that while AI will generate the majority of new application code by 2028, human engineers will still be required to define architecture, governance, and system constraints [5].

AI does not:

Negotiate tradeoffs between performance and velocity
Decide when abstraction is premature
Understand internal company politics
Anticipate long-term architectural debt
Translate ambiguous business requirements into sustainable systems

It produces answers.

It does not design systems.

That distinction matters.

The Shift: From Code Producer to Systems Thinker

If AI lowers the barrier to execution, the bar for thinking goes up.

The future-proof frontend engineer in 2026 excels at three things:

1. Designing Constraints

Good systems are not just built — they are constrained.

Where does state live?
What patterns are mandatory?
What performance budget is enforced?
What architectural decisions are irreversible?

AI follows rules extremely well.

Humans define them.

In organizations adopting AI-assisted development, engineering leaders increasingly emphasize governance, architecture, and guardrails as primary responsibilities for senior engineers [5].

The more you define clear system boundaries, the more AI becomes a multiplier instead of a liability.

2. Translating Business Problems into Technical Leverage

Founders and executives don’t care about hooks or styling strategies.

They care about:

Revenue
Speed to market
Reliability
Risk

According to the Stack Overflow Developer Survey (2024), over 70% of professional developers report using or planning to use AI tools, but many also report concerns about maintainability and correctness [6].

That signals a shift:

AI increases output.
Senior engineers ensure that output aligns with business outcomes.

Examples:

Reducing API calls reduces infrastructure cost.
Improving perceived load time increases conversion.
Creating reusable primitives accelerates feature velocity.
Instrumenting user behavior improves roadmap accuracy.

That’s not “frontend implementation.”

That’s business leverage.

And leverage is hard to automate.

3. Directing AI Instead of Competing With It

A 2023 MIT study on AI-augmented knowledge work found that high performers using AI increased their output significantly, while lower performers benefited even more — but only when guided appropriately [4].

The implication is clear:

The engineers who thrive are not the fastest typists.

They are the best directors.

They:

Structure context clearly
Define architectural constraints before prompting
Review AI output for long-term system health
Eliminate low-leverage work through automation

AI is not your competition.

It is your force multiplier.

But only if your thinking operates above the level of code generation.

The Identity Shift for Frontend Engineers

There is understandable anxiety in the industry.

“Will AI make my role obsolete?”

History suggests otherwise.

Automation rarely eliminates entire professions; it transforms them. The World Economic Forum’s Future of Jobs Report (2023) predicts both displacement and significant job creation as roles evolve toward higher-order skills [7].

Frontend engineering is experiencing exactly that.

Framework knowledge alone is no longer a moat.

Your value is not:

React
Vue
Svelte
Tailwind
Any specific tool

Your value is:

Decision-making under constraint
Translating ambiguity into clarity
Designing maintainable systems
Reducing long-term complexity
Increasing business leverage

The framework changes.

Leverage does not.

What This Means for Mid-Level Engineers

This is actually good news.

AI lowers the barrier to execution.

That means you can spend more time learning:

System design principles
Performance tradeoffs
Data flow architecture
Observability and instrumentation
Business impact modeling

If AI handles 30–40% of repetitive code generation [2], you can redirect that time toward architectural growth.

That’s a faster path to seniority — if you use it intentionally.

What This Means for Engineering Leaders

AI is redefining what “senior” means.

Gartner predicts that by 2028, 75% of enterprise software engineers will use AI code assistants daily [5].

When that happens, evaluation criteria change.

Senior engineers will be the ones who:

Define system boundaries AI can safely operate within
Protect long-term maintainability
Improve velocity through tooling
Elevate conversations to product and business impact

Typing speed is no longer a differentiator.

Judgment is.

The Frontend Developer Isn’t Dead. The Old Definition Is.

The market doesn’t need more component assemblers.

It needs:

Systems thinkers
Product-aware engineers
Constraint designers
AI-native leaders

The good news?

That work is more strategic.
More creative.
And significantly harder to replace.

If AI can generate your components, good.

Now you’re free to design the system.

References

GitHub. Research: Quantifying GitHub Copilot’s Impact on Developer Productivity and Happiness, 2023.
GitHub. The State of AI in Software Development, 2023–2024 reports.
McKinsey & Company. The Economic Potential of Generative AI, 2023.
Brynjolfsson, E., Li, D., Raymond, L. Generative AI at Work, Stanford & MIT, 2023.
Gartner. Top Strategic Technology Trends and AI in Software Engineering Forecasts, 2024.
Stack Overflow. Developer Survey 2024.
World Economic Forum. Future of Jobs Report 2023.

What Even Is A Dispatch Function?

Dustin Myers — Sat, 15 Feb 2020 16:02:23 +0000

Learning redux? Or useReducer? Then chances are you've been frustrated by the black magic that is the dispatch function 🧙‍♂️! Well, luckily you have found this post. I will help you understand what happens under-the-hood and remove the mystery behind dispatch.

What makes dispatch so hard?

There are a couple of reasons that learning Redux or the reducer hooks can be confusing.

First - both flows rely on a programming paradigm called "functional programming". Thinking in this way requires you to switch your mental model of how to manage data in your application. For more on functional programming, read the first half of this article - Functional Programming in JavaScript: How and Why. The basic idea here that makes these patterns hard is that data is flowing from function to function, and often changes shape a little (or even a lot 😬) before your state is updated and the component re-renders.

Second - both flows "abstract" some of the logic into different functions. Think about it. If you're using Redux, you call an action creator function and POOF... a reducer is called and state and an action object are passed in. Like, what the heck?!? 😡 The reducer hook flow has one less layer of abstraction, but there is still some there that adds to the confusion.

Rebuilding dispatch

I think looking at how the dispatch function is built really helps remove the mystery behind reducers. So let's build a simple implementation of dispatch to see the logic that is abstracted out of our view. We start with the function definition.

function dispatch() {

}

Wooooo 🎉! We're doing great so far 😁. Next step, we will add action as a parameter for the function.

function dispatch(action) {

}

So, with this, we know that when the dispatch function is called, it will be passed an action object as an argument. If you're using useReducer or useDispatch, you already know this. Upon some kind of event occurring in the UI, you, not the Redux library, call the dispatch function like this: dispatch({ type: 'ACTION_TYPE' }). If you're using Redux and the connect function, even that part is abstracted away from your view and it’s the Redux library that calls the dispatch function. We’ll talk more on that towards the end. Let's continue though.

Now we need to do a couple of checks. We need to make sure that the action object that is passed in is an object, and that it has a type property. If either of those is not true, we will throw an error. When a reducer function is written, it assumes that those are both true.

function dispatch(action) {
  // check that the action argument is an object
  if (typeof action !== 'object' || obj === null) {
    throw new Error('actions must be plain object.');
  }

  // check that the action object has a 'type' property
  if (typeof action.type === 'undefined') {
    throw new Error('Actions may not have an undefined "type" property.'
  }
}

Good. Now we can build our reducers with confidence knowing that any action that is dispatched will be an object and will have a "type" property.

Now the exciting part! The next thing we will do is call the reducer from within the dispatch function. This is the abstraction part that hides from our view of what is happening behind-the-scenes. There are a couple of points that we need to cover before we can write this though.

The dispatch function is in the same scope as the current state of the app. So that means that inside the dispatch function, we have access to an object called currentState that is the current state in our app.

In that same scope is the reducer function that we have written and passed into createStore or useReducer. So the dispatch function also has access to reducer - our reducer function (no matter what we called it) that we passed in. That means that the dispatch function can invoke the reducer function.

Here’s a very simplified version of what that looks like:

const createStore = () => { 
  // 😮 yep, it’s createStore! But that’s for another article… 

  // state will be initialized then stored here
  const currentState = {};

  // your reducer, or combined reducers, will be accessible here
  const reducer = null;

  // dispatch function in the same scope will have access to the most current state and your reducer(s)
  const dispatch = (action) => {
    // … all the codes
  }

🤯 I know, I know… really cool to see what it looks like under-the-hood, right? Functions and objects. Welcome to functional programming in JavaScript! Once you see it written out like this, it starts to come together! But there is still just a little more to explore.

Let's think about everything that we've learned so far and combine that new knowledge with what we know about reducers.

dispatch has access to currentState and reducer.
When dispatch is called, it receives an action object as an argument.
A reducer function, when invoked, is passed two arguments - state (meaning the current state) and action. See where I'm going with this?

Inside dispatch we will now call reducer and pass in currentState and the action object.

function dispatch(action) {
  // check that the action argument is an object
  if (typeof action !== 'object' || obj === null) {
    throw new Error('actions must be plain object.');
  }

  // check that the action object has a 'type' property
  if (typeof action.type === 'undefined') {
    throw new Error('Actions may not have an undefined "type" property.');
  }

  // call the reducer and pass in currentState and action
  // reducer and currentState are within scope, action is the parameter passed into the function
  reducer(currentState, action);
}

Look at that closely... when an action is dispatched, or in other words, when we invoke dispatch and pass in an action object, the dispatch function calls our reducer and passes in the current state and the action object! 🤩 It's all starting to make sense!

Well, there's one last part to this - updating the state. Think about how you write a reducer function. What does it return? It returns a new state object, right? You've followed immutable principles to return a copy of the old state, updated with new data based on whichever action you had dispatched. So when the dispatch function does this - reducer(currentState, action); - that function call is going to return a brand new state object. Our dispatch function here needs to update currentState with the new state object that is returned by calling the reducer.

function dispatch(action) {
  // check that the action argument is an object
  if (typeof action !== 'object' || obj === null) {
    throw new Error('actions must be plain object.');
  }

  // check that the action object has a 'type' property
  if (typeof action.type === 'undefined') {
    throw new Error('Actions may not have an undefined "type" property.');
  }

  // call the reducer and pass in currentState and action
  // capture the new state object in currentState, thus updating the state
  currentState = reducer(currentState, action);
}

And voila! We have built a simple implementation of the dispatch function. Now, of course, there is more to this in the actual implementations. In Redux, dispatch needs to tell the app that the state has been updated. This happens through listeners and subscriptions. In the useReducer hook, React recognizes that the state was updated and re-renders the component. The updated state is then returned to the component from where the useReducer hook was called.

Regardless of the extra implementations, building out the dispatch function here will really help us understand what is happening under-the-hood when we call dispatch from our components.

Redux and action creators

If you're using Redux and connect, there is one more layer of abstraction to explore. With the connect function, you pass action creators into an object in the connect function. The action creators are then passed to the component via props. In your component, when you call the action creator, it will call dispatch for you. That's the added layer of abstraction. Let's look at what connect does under-the-hood (again in a simplified version).

// inside the connect function implementation
dispatch(actionCreator());

So, connect wraps the dispatch function around the action creator call. When the action creator is invoked, it returns an action. So the above evaluates down to:

dispatch({ type: 'ACTION_TYPE' });

which we now understand will call the reducer! Wooo! 🚀

Conclusion

Hopefully, this helps remove the black magic of reducers and dispatch! If you think through the logic flow, you will realize that this is all about functions calling functions and passing data around. And now that the black magic of Redux has been removed a bit, you can get back to the fun part of building web apps with React and Redux ⚛️!

Using The Request Body With Serverless Functions

Dustin Myers — Sun, 09 Feb 2020 01:10:14 +0000

Harnessing the request body within serverless functions really expands what we can do with our apps.

Greater Power

So far we have seen the most basic setup for serverless functions - returning a set of hardcoded data. In this tutorial, we will look at what we can do with serverless functions to create a more complicated application.

We will be using the Star Wars API (SWAPI) to build a multi-page application that will display a list of Star Wars characters, let your user click on the character to open the character page. We will use serverless functions for two purposes here:

Avoid any CORS issues
Add character images to the data provided by SWAPI, since the data does not include images

We will need to harness the power of the serverless functions request body as built by Zeit to achieve these lofty goals. Let's get started!

Hosting On Zeit

The starting code for this tutorial is in this repo here and the deployed instance here. You will need to fork it so you can connect it to a Zeit project. Go ahead and fork it now, then clone the repository to your own machine. From there, use the now cli (download instructions) to deploy the app to Zeit. This will create a new project on Zeit and deploy it for you.

This app is built with Zeit's Next.js template. This will allow us to open a dev environment on our own machines for testing and debugging our serverless functions, while still giving us the full Zeit workflow and continuous development environment.

After you have cloned the repo, install the dependencies with yarn. Then fire up the app with yarn run dev. This gives you a link you can open up in your browser. You can now use the browser for debugging the Next.js app, and the terminal for debugging your serverless functions.

Refactoring To Use Serverless Functions

Right now, the app works to display the list of characters, but it is just making the fetch request to SWAPI in the component. Take a look at /pages/index.js.

If you are unfamiliar with data fetching in a Next.js app, check out their docs on the subject. We are following those patterns in this app.

Instead of the component calling SWAPI, we want to make a request from the app to a serverless function and have the serverless function make the request to SWAPI for us. This will allow us to achieve the two things listed above.

Let's go ahead and refactor this to use a serverless function.

File structure

/pages/api directory

To start out, add an /api directory inside the /pages directory. Zeit will use this directory to build and host the serverless functions in the cloud. Each file in this directory will be a single serverless function and will be the endpoint that the app can use to make HTTP requests.

get-character-list.js

Now inside /pages/api add a new file called get-character-list.js. Remember adding API files in the last tutorial? Just like that, we can send HTTP requests to the serverless function that will be housed in this file using the endpoint "/api/get-character-list".

The serverless function

Now let's build the get-character-list function. The function will start out like this:

export default (req, res) => {};

Inside this function is where we want to fetch the data for the star wars characters. Then we will return the array of characters to the client.

I have set up a fetchCharacters function outside of the default function. I call that from the default function and then use the res object to return the character data.

Note that we are using "node-fetch" here to give us our wonderful fetch syntax as this is a node function.

const fetch = require("node-fetch");

const fetchCharacters = async () => {
  const res = await fetch("https://swapi.py4e.com/api/people/");
  const { results } = await res.json();
  return results;
};

export default async (req, res) => {
  try {
    const characters = await fetchCharacters();
    res.status(200).json({ characters });
  } catch (error) {
    res.status(500).json({ error });
  }
};

Inside the serverless function, let's add a couple of console.logs so you can see the function at work within your terminal.

const fetch = require("node-fetch");

const fetchCharacters = async () => {
  const res = await fetch("https://swapi.py4e.com/api/people/");
  const { results } = await res.json();

  // ADD ONE HERE
  console.log(results);
  return results;
};

export default async (req, res) => {
  try {
    const characters = await fetchCharacters();

    // ADD ONE HERE
    console.log(characters)
    res.status(200).json({ characters });
  } catch (error) {
    res.status(500).json({ error });
  }
};

When you have a chance to watch those logs happen, go ahead and remove them, then move on to the next step.

Updating the Next.js app

Now that we have our serverless function in place, let's update the call that is happening in /pages/index.js. We need to change the path we provided to useSWR to our serverless function endpoint - "/api/get-character-list".

Notice though, that our serverless function is changing the object that will be sent to our app. Inside the effect hook that is setting the data to state, we need to update that as well to expect an object with a characters property.

We're getting our data through the serverless function! 😁🎉🔥

Adding thumbnail images

The final step for our list page is to add thumbnail images to the data before our serverless function returns the characters to the app. I have collected images for you. You're welcome!

const images = [
  "https://boundingintocomics.com/files/2019/05/2019.05.15-06.10-boundingintocomics-5cdc56295fdf4.png",
  "https://img.cinemablend.com/filter:scale/quill/7/e/9/b/6/f/7e9b6f625b1f06b8c70fe19107bf62bc0f44b6eb.jpg?mw=600",
  "https://www.sideshow.com/storage/product-images/2172/r2-d2-deluxe_star-wars_feature.jpg",
  "https://s.yimg.com/ny/api/res/1.2/soTg5zMneth9YIQz0ae_cw--~A/YXBwaWQ9aGlnaGxhbmRlcjtzbT0xO3c9ODAw/https://images.fatherly.com/wp-content/uploads/2018/12/darthvader-header.jpg?q=65&amp;enable=upscale&amp;w=1200",
  "https://www2.pictures.zimbio.com/mp/oHGHV7BhCfvl.jpg",
  "https://i.ytimg.com/vi/5UW1PIplmlc/maxresdefault.jpg",
  "https://pm1.narvii.com/6293/db859b249381c30a6be8f8242046105e552cd54d_00.jpg",
  "https://lumiere-a.akamaihd.net/v1/images/r5-d4_main_image_7d5f078e.jpeg?region=374%2C0%2C1186%2C666&width=960",
  "https://lumiere-a.akamaihd.net/v1/images/image_606ff7f7.jpeg?region=0%2C0%2C1560%2C878&width=960",
  "https://s.abcnews.com/images/Entertainment/ht_alec_guinness_obi_wan_kenobi_star_wars_jc_160415_16x9_992.jpg"
];

Add this array to your serverless function file, then add a .map() to add these images to the data before you send it back.

export default async (req, res) => {
  try {
    const list = await fetchCharacters().catch(console.error);
    // Map over chatacters to add the thumbnail image
    const characters = list.map((character, index) => ({
      ...character,
      thumbnail: images[index]
    }));
    res.status(200).send({ characters });
  } catch (error) {
    console.log({ error });
    res.status(500).json({ error });
  }
};

Check out the results!

Using The Request Object

Now we will build out the character page. You may have noticed that clicking on a character card navigates you to a character page. The character page URL has a dynamic param /:id. In the /pages/Character/[id].js file we are using Next.js' useRouter hook to get the id param from the URL.

We want to make a request to another serverless function which will fetch the character data for us. That function will take in the id of the character we clicked on via query parameters.

The serverless function file/endpoint

The file structure here will be the same as we've seen thus far. So go ahead and set up a file called /pages/api/get-character-by-id.js. Add a serverless function there. Just have it return some dummy data, like { message: 'hello' } for now. Next add the same useSWR and fetcher functions to [id].js. Make a request to the new function to make sure it's working.

Once you see the request happen (you can check it in the network tab in your browser) we can build in the query param and make a request to SWAPI for the character's data.

The Query Param

The request URL from the page will add a query param for the id. Our endpoint will change to this -/api/get-character-by-id?id=${id}. Then we can grab the id in the serverless function like this - const { id } = req.query. Easy peasy!

Your turn

Using what you've built so far, and what we just learned about the query param, build out the HTTP request in your component to make a request with the query param. In your serverless function, grab that param from the req object and fetch the data you need from SWAPI, adding the id to the end of the URL (e.g. for Luke Skywalker, your request URL to SWAPI should be https://swapi.py4e.com/api/people/1). When the data returns, add the correct image to the object and return the data to your app. Finally, build out your component as a character page to display the character data.

Go ahead, get working on that. I'll wait! When you're done, scroll down to see my implementation.

Solution

Great job! Aren't serverless functions awesome! Here is how I implemented everything for this page.

// get-character-by-id.js
const fetch = require("node-fetch");

// probably should move this to a util file now and just import it :)
const images = [
  "https://boundingintocomics.com/files/2019/05/2019.05.15-06.10-boundingintocomics-5cdc56295fdf4.png",
  "https://img.cinemablend.com/filter:scale/quill/7/e/9/b/6/f/7e9b6f625b1f06b8c70fe19107bf62bc0f44b6eb.jpg?mw=600",
  "https://www.sideshow.com/storage/product-images/2172/r2-d2-deluxe_star-wars_feature.jpg",
  "https://s.yimg.com/ny/api/res/1.2/soTg5zMneth9YIQz0ae_cw--~A/YXBwaWQ9aGlnaGxhbmRlcjtzbT0xO3c9ODAw/https://images.fatherly.com/wp-content/uploads/2018/12/darthvader-header.jpg?q=65&amp;enable=upscale&amp;w=1200",
  "https://www2.pictures.zimbio.com/mp/oHGHV7BhCfvl.jpg",
  "https://i.ytimg.com/vi/5UW1PIplmlc/maxresdefault.jpg",
  "https://pm1.narvii.com/6293/db859b249381c30a6be8f8242046105e552cd54d_00.jpg",
  "https://lumiere-a.akamaihd.net/v1/images/r5-d4_main_image_7d5f078e.jpeg?region=374%2C0%2C1186%2C666&width=960",
  "https://lumiere-a.akamaihd.net/v1/images/image_606ff7f7.jpeg?region=0%2C0%2C1560%2C878&width=960",
  "https://s.abcnews.com/images/Entertainment/ht_alec_guinness_obi_wan_kenobi_star_wars_jc_160415_16x9_992.jpg"
];


const fetchCharacter = async id => {
  const res = await fetch(`https://swapi.py4e.com/api/people/${id}`);
  const data = await res.json();
  return data;
};

export default async (req, res) => {
  const { id } = req.query;
  // Make sure that id is present
  if (!id) {
    res
      .status(400)
      .json({ error: "No id sent - add a query param for the id" });
  }

  // fetch the character data and add the image to it
  try {
    const character = await fetchCharacter(id).catch(console.error);
    character.thumbnail = images[id - 1];
    res.status(200).send({ character });
  } catch (error) {
    console.log({ error });
    res.status(500).json({ error });
  }
};

// [id].js

import { useState, useEffect } from "react";
import { useRouter } from "next/router";
import fetch from "unfetch";
import useSWR from "swr";

import styles from "./Character.module.css";

async function fetcher(path) {
  const res = await fetch(path);
  const json = await res.json();
  return json;
}

const Character = () => {
  const [character, setCharacter] = useState();
  const router = useRouter();
  const { id } = router.query;
  // fetch data using SWR
  const { data } = useSWR(`/api/get-character-by-id?id=${id}`, fetcher);

  useEffect(() => {
    if (data && !data.error) {
      setCharacter(data.character);
    }
  }, [data]);

  // render loading message if no data yet
  if (!character) return <h3>Fetching character data...</h3>;

  return (
    <main className="App">
      <article className={styles.characterPage}>
        <img src={character.thumbnail} alt={character.name} />
        <h1>{character.name}</h1>
      </article>
    </main>
  );
};

export default Character;

There we have it! I did not add much to the character page here so that the code block would be somewhat short. But hopefully, you have built it out to display all of the character's cool data! Drop a link to your hosted site in the comments when you finish! Final code can be found in here and the final deployment here.

Hello World with Serverless Functions

Dustin Myers — Fri, 07 Feb 2020 04:47:27 +0000

Technologies used in this post:

React
Next.js
Node Serverless Functions
Zeit

This post assumes a basic knowledge of React, Next.js, and Node. However, if you have no knowledge of Next.js, that is okay. If you know React, you can still follow along here. Just recognize that the file structure will be different, and there are small differences in the component files. That is another topic for another day, however 😁.

All About Workflows

Zeit's platform is focused on building workflows for the everyday developer. They provide a production-ready, continuous development platform for anyone from brand new devs, to hobbyists, all the way to Enterprise companies like Hulu.

Starting a React project using Next.js and spinning up serverless node functions is incredibly simple. It truly is an amazing world we live in!

Starting a Next.js Project

As Zeit is all about workflows, they have made it so simple to begin a new project. To follow the tutorial here, you'll need to set up a new account on their website, zeit.co.

Step 1 - Choose a template

Once you are logged in, and in the dashboard, you will see a New Project button at the top right. Click that button, then scroll down to the "From a template" section. The Next.js template is the first on the list of templates here.

Click on that template to navigate to the configuration page.

Step 2 - Name your project

Here you will be able to name your project and also see a live example of the web app that is created with this template.

After giving your new project a name, click Continue to move to the last step in the creation process.

Step 3 - Create a repo and deploy

The card in the UI now lets you create a Git repository, name the repository, and make it private if you wish. You will want to make a repo for this tutorial so you can clone the project onto your computer and work on it alongside me.

Also note that you should keep the name of the repo the same as the Zeit project.

Go ahead and hit Deploy!

What is happening?

Behind the scenes here, Zeit will set up a modern React application powered by Next.js, add the repository to your GitHub account, and deploy the project on the Zeit platform. After clicking Deploy you will be navigated to your project's deployment page, where you can watch the progress of the build and deployment.

After the project is deployed, you'll be able to view the deployment overview by clicking the URL under the "Deployment" header. Also, if you click on the preview image, a new tab will be opened where you can view the web app itself.

At this point, go to your repository and clone the project onto your machine. Then you'll be ready to add your first serverless function!

Serverless Functions

According to Zeit's docs, serverless functions "are pieces of code written with backend languages that take an HTTP request and provide a response". Let's look at our project and find the serverless function that was built out already that the React app consumes to get a current timestamp.

In your project, you will see a /pages directory, and inside that, an /api directory. Go ahead and open date.js that is found in /api. Here is your first glimpse at a serverless function!

This is just a node function that, as mentioned, takes an HTTP request and returns the current time. Let's take a look at how these functions work.

Serverless Function Setup

As shown above, the serverless function in our Next.js app is simply an exported function that receives a req and a res object, just like node API endpoints. It is important to note that this actually isn't using Express to build these objects. Zeit has built these objects to mirror what Express does, but it is not Express.

When the HTTP request comes in, this function calls res.json to return the date stamp from the time the request came in. So Zeit allows our React app to make an async HTTP request to this function and will wait for the data to be returned. Let's see how that is set up on the client-side.

React App Setup

Looking at the node function, at first glance it isn't intuitive how you would make a request to that function. What's the endpoint? How do you pass data to it?

It's actually a really cool setup. The deployed (or even the development) instance knows that files in the /api directory are serverless functions. It builds the functions in the cloud, and then any request that goes out to /api/[file-name] is sent to that function.

So there is one single endpoint for each file, and one function for each endpoint. And we can make any HTTP requests to those functions by passing in the file name in the endpoint URL.

Here is the fetch call that is happening in our Next.js app in the /pages/index.js file. Do you remember the name of the file that is housing the serverless function? Go ahead and look at it. That's right! It's date.js. So the React app makes a GET request to /api/date.

It's as simple as that! The call goes out asynchronously to the serverless function, awaits for the function to return the date, then sets the date to state so it can be displayed in the UI.

Writing Your First Serverless Function

Now that you have seen this work, I want you to add this code to the JSX in your React app. Instead of the header saying "Welcome to Next!", I want it to greet you by name. So let's add some state and the extra piece in the JSX:

Once you have that added, follow these tasks:

Add a new serverless file and function that will return your name (you can shape that data however you would like
Build a new useEffect hook that will query that new function to get the name back
Set the returned name to state so it will display in the header

Don't scroll down! Try this out on your own first before you see my implementation below 😁

My Code

How'd you do? Did you get it working? Here is how I implemented this. I added a file called get-name.js in the /api directory. The serverless function in that file looks like this:

Then I fetched the data like this:

Is that about what you had? Share what you did differently in the comments!

Conclusion

Now you know how to add serverless functions to a React app using Next.js and Zeit. The simplicity of the workflow makes this so easy. I love the developer experience and have found that I can build features so much faster with these amazing tools. Let me know what use cases you find for serverless functions, and how you're liking Zeit and Next.js!