DEV Community: Naman Agarwal

Intro to Next.js API and handling Form-Data

Naman Agarwal — Sun, 06 Nov 2022 12:38:57 +0000

A walkthrough on how to build a full-stack application using Next.js for both the frontend and the backend 🔥 🔥.

The framework provides the API functionality which allows us to build dynamic API's at scale. The API can be used in production with ease and can replace a full fledged backend service for certain business usecases.

Decision to use Next.js API depends on the scale of the system that we are trying to build and I personally think it's a no-brainer for small businesses and MVP's. Another criteria before choosing Next API is to decide if your team can work effectively on a monolith architecture. Below I have listed down some usecases where Next API's can be used:

Form submission
Gateway/Proxy server
UI Theme Provider

Note: This writeup assumes basic knowledge about building Next.js frontends.

Building API's is similar to building frontends in Next. We put all the API logic inside the api folder within the pages folder. Each folder/file within the api folder is a route, similar to how page routing works. Let's see how it looks so far.

Let's start by building an API route /form. There are 2 ways to do so, either make a form.js file within the api folder or create a form folder with an index.js file. As you can sense this is exactly similar to how frontend routing works.

This route is accessible on the same port as the frontend app, and the way to access it is: http://hostname:port/api/form

It's time to start coding the logic for /form. As repetitive as it can get while coding anything in Next, start by default exporting a function, which acts as the handler for all request on the /form route. Note, similar to how vanilla Node.js handles requests, any request on /form route irrespective of the HTTP method (GET, POST etc) will be sent to this handler. Let's take a look how the handler looks:



export default async function handler(req, res) {

}

req: An instance of http.IncomingMessage, plus some pre-built middlewares
res: An instance of http.ServerResponse, plus some helper functions

By default (using the default config) following helpers are available:

req.query: parses the request query params string as object.
req.body: parses the request body json to object.

Default config can be changed as below:



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

The config disables parsing request json body to object.

I'll end my intro to Next API's here. To explore more complex usecases, checkout the Next.js documentation here 😌.

Lastly, I'll leave you with a small example on how to handle form-data in Next API 😮:

Handling Form-Data in Next.js API 🔥

Find the GitHub Repository: here



import formidable from "formidable";
import * as yup from "yup";

let formSchema = yup.object().shape({
  name: yup.string().required(),
  email: yup.string().email().required(),
  image: yup.mixed().required(),
});

async function saveFormData(fields, files) {
  // save to persistent data store
}

async function validateFromData(fields, files) {
  try {
    await formSchema.validate({ ...fields, ...files });
    return true;
  } catch (e) {
    return false;
  }
}

async function handlePostFormReq(req, res) {
  const form = formidable({ multiples: true });

  const formData = new Promise((resolve, reject) => {
    form.parse(req, async (err, fields, files) => {
      if (err) {
        reject("error");
      }
      resolve({ fields, files });
    });
  });

  try {
    const { fields, files } = await formData;
    const isValid = await validateFromData(fields, files);
    if (!isValid) throw Error("invalid form schema");

    try {
      await saveFormData(fields, files);
      res.status(200).send({ status: "submitted" });
      return;
    } catch (e) {
      res.status(500).send({ status: "something went wrong" });
      return;
    }
  } catch (e) {
    res.status(400).send({ status: "invalid submission" });
    return;
  }
}

export default async function handler(req, res) {
  if (req.method == "POST") {
    await handlePostFormReq(req, res);
  } else {
    res.status(404).send("method not found");
  }
}

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

To parse the form-data in request body, I have used Formidable package which is quite easy to work with. I have also provided a saveFormData function which can used to save data on persistent stores like firebase, mongoDB etc.

Next, sending a request to the API from a page:



async function submitForm(data) {
    const f = new FormData();

    f.append("name", data.name);
    f.append("email", data.email);
    f.append("image", data.image.fileList[0]);

    const res = await fetch("/api/form", {
      method: "POST",
      body: f,
    });

    const resBody = await res.json();

    if (res.status == 200) {
      notification.success({
        duration: 3,
        message: "Submission Status",
        description: resBody.status,
        onClose: () => router.reload(window.location.pathname),
      });
    } else {
      notification.error({
        duration: 2,
        message: "Submission Status",
        description: resBody.status,
      });
    }
  }

I'll end here and as I said, the usefulness of Next API depends on the problem you are trying to solve, the scale of the system and collaboration required.

I hope this writeup was useful, have a nice day ✌️.

References

Save-My-Dates: A React-Native App

Naman Agarwal — Thu, 26 Aug 2021 13:52:53 +0000

This article is published under @androidvitc, which is a mobile first community and deals with everything android. Follow us for more such articles.

About this article

I am writing this article solely to document my experience while developing and publishing my react-native applications.

I hope you get a gist of how to start building mobile apps.

Repo

Android-Club-VITC / SaveMyDates

This app will save all types of dates for you.

The Idea

When I started building this app for my technical club (androidclubvit), I soon released that even though a to-do app is very trivial to build, there are still few complexities that are often ignored by people demonstrating how to build a to-do app in 10 minutes.

The functionality is not the only thing that a developer should focus on. Things like edge-case handling, abstraction, and robustness is an important aspect of a developer's journey.

Imagine how Visual Studio Code (VS Code) is able to support so many extensions and use cases without ever changing the way it looks and feels. Everything seems so seamlessly integrated.

Tools

These are the various tools and technologies I used and honesty I am impressed.

1. React-Native

Today, react-native is the language of choice for many developers for building mobile applications. There are obviously other tools but I found the react-native community to be very active.

2. Typescript

Typescript is a wrapper over JavaScript making it type safe. JavaScript in terms of development is awesome but the freedom it provides is often misused to write bad code.

Bad code works but in the long run or when there is an increase in user base, the application might break.

Again typescript is not the perfect solution but it makes us less inclined towards using bad coding practices.

3. Firebase

Firebase is a very useful platform to easily deploy databases and messaging services on the go. It is maintained by google and it's close to perfect for personal projects.

Checkout react-native-firebase, it has brilliant guides on integrating Firebase with react-native

The App

For the primary release I took into account two types of use cases for the app.

Private To-Do
Public Shareable To-Do

My aim was to build these features without handling specific edge cases, making the code reusable. This thought had a massive impact on some the coding practices I used.

Private To-Do

A set or list of To-Do added by the user which are private. In the sense of the application these To-Do doesn't need to have a public footprint and will be stored locally.

Public To-Do

A set or list of To-Do added by the user which are public. In the sense of the application these To-Do need to have a public footprint and will be stored on a remote database, I have used Firestore as the database provided by Firebase.

This public data will also be shareable i.e other people can also access this data through the app.

Basic Login System

Now the problem was how to restrict this access so that only the publisher of the To-Do's can decide accessibility.

I didn't want to complicate the app by building a full proof login system, so I created something less secure and in future I can update it anytime.

This again brings me to the point of decoupling functionalities in the code base. The login system is used as a separate layer which resides before other functionalities and any future updates won't affect the core functionalities of the code base.

Project Structure

I went with a component based structure with a service layer. Let's see by example what I mean by that:

Project
|   App.tsx
|
|__ components
|   |  ToDoCard
|   |  ToDoForm
|   |  Loader
|   |  CreateProfile
|   |  ...
|
|__ routes
|   |  Public
|   |  Personal
|
|__ screens
|   |  ToDoAdd
|   |  ToDoListView
|   |  LoginProfileScreen
|   |  CreateProfileScreen
|   |  ...
|
|__ services
    |  asyncStoreService.ts
    |  firestoreService.ts

I'll brief what each directory is meant to achieve

App.tsx : Root component of the tree. Mostly is used to define various paths/endpoints that lead to deeper levels into the app tree. In this scenario it packs the root navigator with two routes, the public and the personal.
components : One of the core aspects about react-native is modularisation, which directly can be handled by breaking bigger structures into smaller components. For example cards, forms, modals and loaders are components that can be used while building a bigger components or screens in mobile development.
routes : It takes care of further breakdown of the App tree into branches, that is, it holds other nested navigators.
screens : Screens are standalone components in react-native that has both a user-interface and related functionality linked to it. For example login screen.
service : This layer acts as an API to add functionality to screens while abstracting the service specific complexities. The app has only two services, a remote service (firebase) and a local service (async-storage).

Demystifying Components, a shot at Decoupling

Components can be thought as basic building blocks that can be used to build full fledged screens.

Let's take a look at how at the Form components

Probable use-cases:

Add New ToDo : A new entry is to be made
Update ToDo : An old entry needs to be identified and updated

Idea is to create an interface such that it handles both the use-cases seamlessly.

Pay attention to the interface todoFormProps (extends todoProps), look at the types of each parameter. The questions mark indicates that the field is not required and can be omitted.

If you think about it, can you figure out the condition when we don't need to send the various parameters.

When we need to add a new To-Do, the initial state of the form needs to be empty. While for updating we need to pass the various parameters which act as the initial state of form.

So, you might already have an idea that we can make this component versatile for both the use-cases by simply checking if parameters are passed or not (lines 30-38).

Another key aspect of components is that we don't want to handle use-case effects like submitting a To-Do inside the components, rather allow the parent to dictate how to handle the specific use-case effect. Although the component can maintain state for its internal components (eg. loader) which does not effect the use-case in anyway.

This aspect is handled by the storeToDo and onSubmitRoute props (lines 11-15) in the above component.

Following the same methodologies components like Card can also be abstracted. Below I have added the snippet for Card component.

Demystifying Services, Another shot at Decoupling

The service layer handles the various effects that might be exited by different screens or components by providing an API like structure.

Starting a project without a planned structure will often lead to bigger code base and unwanted complexity.

Many effects/functionalities can be abstracted by using modular services which is just a fancy way of saying writing abstract functions or class with methods to suite the use-cases.

For example: I easily abstracted the storing functionality into two services, the remote service and the local service.

Let's take a look

Async Storage Service (local service)

Firebase Service (remote service)

Whenever creating API in general always prefer using self explanatory names/definitions, it helps structure the project more (as I would like to say) poetically.

The component and screens doesn't need to know how to access the remote service or the local service. Instead they use this service API as an interface.

The snippets above are extremely user friendly and easy to understand by just reading the method definition.

Any component can access the services by a basic syntax:

await serviceClassName.methodName(...params)

Imagine migrating from Firebase to some other database, just the service methods needs to be changed while other layers remain intact.

I hope this article was able to demonstrate my development journey and provide you a gist of how you can start your own journey.

While for more such articles follow @androidvitc

Peace Out!!!