DEV Community: Marie Otaki

Separating Concerns in Next.js for Better Performance, Security, and Maintainability

Marie Otaki — Fri, 21 Mar 2025 10:11:14 +0000

I built an MVP version of AI journaling app using v0 about a month ago. Thanks to v0 the development speed was quite fast, but architecture-wise there were a lot of parts that needed improvement. That's why I decided to review the structure and transform it from "something that just works" to a design that's easier to scale and has better performance. This post is what I presented in the lightning talk that I held. It covers how I addressed key architectural challenges in my Next.js application by properly separating concerns between server-side and client-side components.

Performance improvement

MVP version

"use client";

function EditJournalContent({ id }: { id: string }) {
 // Details omitted
  const supabase = createClient();
  const [editedText, setEditedText] = useState("");
  const [editedTitle, setEditedTitle] = useState("");
  const [editedMood, setEditedMood] = useState(5);
  const [createdAt, setCreatedAt] = useState("");

  useEffect(() => {
    // Data fetching and displaying data logic are coupled in the same component
    const fetchJournal = async () => {
      const { data: selectedData, error: dbError } = await supabase
        .from("journal_entries")
        .select("id, text_data, title, mood, created_at")
        .match({
          id,
        })
        .single();

      if (dbError) {
        console.log({ dbError });
      }
      setEditedText(selectedData?.text_data);
      setEditedTitle(selectedData?.title);
      setEditedMood(selectedData?.mood);
      setCreatedAt(selectedData?.created_at);
    };

    fetchJournal();
  }, [supabase, id]);
}

// UI logic is coming below

This is a client component because "use client" directive is at the top.
Quite a few components were handling both data fetching and UI rendering simultaneously in client components.
This might causes slowing down communication between client and server and increase JavaScript bundle size.

Improved version

import React from "react";
import { QUERIES } from "@/app/server/db/queries";
import EditJournal from "@/app/journal/[id]/edit/edit-journal";

export default async function EditJournalPage(props: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await props.params;
  const parsedId = parseInt(id, 10);
  const journal = await QUERIES.getJournalById(parsedId);

  return <EditJournal id={parsedId} journal={journal} />;
}

Created server components by deleting "use client" that handle data retrieval and pass only necessary data to client components.
This creates a clear separation between data access and UI rendering.
Better performance: this possibly speed up communication between client and server and reduce JavaScript bundle size.

Security improvement

MVP version

"use client";

function EditJournalContent({ id }: { id: string }) {
 // Details omitted
  const supabase = createClient();
  const [editedText, setEditedText] = useState("");
  const [editedTitle, setEditedTitle] = useState("");
  const [editedMood, setEditedMood] = useState(5);
  const [createdAt, setCreatedAt] = useState("");

  useEffect(() => {
    // Database query is written directly in a client component
    const fetchJournal = async () => {
      const { data: selectedData, error: dbError } = await supabase
        .from("journal_entries")
        .select("id, text_data, title, mood, created_at")
        .match({
          id,
        })
        .single();

      if (dbError) {
        console.log({ dbError });
      }
      setEditedText(selectedData?.text_data);
      setEditedTitle(selectedData?.title);
      setEditedMood(selectedData?.mood);
      setCreatedAt(selectedData?.created_at);
    };

    fetchJournal();
  }, [supabase, id]);
}

Database credentials and queries were potentially exposed to client browsers, creating significant security vulnerabilities.

Improved version

import React from "react";
import { QUERIES } from "@/app/server/db/queries";
import EditJournal from "@/app/journal/[id]/edit/edit-journal";

export default async function EditJournalPage(props: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await props.params;
  const parsedId = parseInt(id, 10);
  // Database query is detached from UI logic
  const journal = await QUERIES.getJournalById(parsedId);

  return <EditJournal id={parsedId} journal={journal} />;
}

// This directive ensures this component can be used only on server components.
import "server-only";

import { createClient } from "@/utils/supabase/server";
import { JournalEntry } from "@/types/diary";

export const QUERIES = {
  getJournalEntries: async function () {
    const supabase = await createClient();
    const { data: journalEntries, error: fetchError } = await supabase
      .from("journal_entries")
      .select("id, text_data, title, mood, created_at")
      .order("created_at", { ascending: false });

    if (fetchError) throw Error("Error fetching diary entries");

    return journalEntries as JournalEntry[];
  },

  getJournalById: async function (id: number) {
    const supabase = await createClient();
    const { data: entry, error: fetchError } = await supabase
      .from("journal_entries")
      .select("id, text_data, title, mood, created_at, updated_at")
      .match({
        id,
      })
      .single();

    if (fetchError) throw new Error("Error fetching diary by id", fetchError);

    return entry as JournalEntry;
  }
};

Added 'server-only' import to files containing database queries.
This creates a boundary that prevents client components from importing server-only code.
Better security: Ensures all database operations and credentials stay strictly on the server.

Maintainability improvement

MVP version

Look at the MVP version of the code in Security improvement section.

Had identical database query code (fetchJournal) repeated across multiple components.

Improved version

Look at the MVP version of the code in Security improvement section.

Created a dedicated queries file with all database operations
Organized queries as methods of a single object (e.g., QUERIES.getJournalById())
Better maintainability: When changes are needed (like removing a field), I only need to update one place

Column: What's the difference between `import server-only` and `use server`?

This is the great question asked by one of the participants when I did lightning talk.

The main differences between import server-only and use server in Next.js are:

Purpose:
- import 'server-only' is a package that ensures code is never executed on the client.
  - Using server-only to prevent leaking secrets:this link on React document makes more sense to me.
- 'use server' marks server-side functions that can be imported and called from client components.
  - Explanation about use server in React document: this makes sense to me as well.
Usage:
- import 'server-only' is used as an import statement at the top of files containing server-only code.
  - Data fetching code contains sensitive credentials is a great use case.
- 'use server' is a directive placed at the top of a file or before individual functions to mark them as server actions.
  - Server Functions in forms are most common usage.
Behavior:
- server-only prevents the entire module from being imported on the client.
- use server allows client components to call specific server functions, facilitating client-server communication.
Scope:
- server-only affects the entire file.
- use server can be applied to the entire file or to specific functions.

Here's a simple example of each:

// database.js
import 'server-only';

export function fetchData() {
  // Database operations that should never run on client
}

// actions.js
'use server';

export async function submitForm(formData) {
  // Server-side form processing
  // Can be called from client components
}

Conclusion

Refactoring my AI journaling app from MVP to a robust architecture has delivered three key improvements:

Better Performance: Moving data fetching to server components reduced bundle size and eliminated unnecessary client-server communication.
Enhanced Security: Using server-only created a boundary that keeps database operations and credentials strictly on the server.
Improved Maintainability: Centralizing database queries in one file made the codebase easier to update and maintain.

This architectural shift shows how taking time to learn and implement Next.js best practices can transform an app from "something that just works" to "something that works well." Hope this article helps!

Maximizing SEO and Performance with Next.js: Strategies from an Activity Booking Platform Project

Marie Otaki — Thu, 22 Aug 2024 06:36:40 +0000

Introduction

Among thousands of pieces of content in search engines, standing out in results is crucial. Recently, I had the opportunity to lead SEO and performance optimization when building a new webpage for a Japanese activity booking platform. This project provided valuable insights into effective SEO and performance strategies using Next.js. In this article, I'll share the key learnings from this experience.

Our Approach

We adopted a multifaceted approach, focusing on three key areas:

Performance Optimization
Structured Data and Metadata Enhancement
Technical SEO Implementation

1. Performance Optimization

Key Strategies:

Utilizing Next.js's built-in image optimization can improve page load times, especially by using the sizes prop which determines how wide and tall the image will be at different breakpoints. If you forget to apply this prop, your app will possibly get larger images than you actually need, which leads to poor performance.
Knowing when to use priority and lazy loading for images. If the image is the Largest Contentful Paint (LCP) element and visible in the first view, it's time to use priority, which automatically disables lazy loading. This allows preloading of the elements. Alternatively, you can use lazy loading, which is set by default when using next/image. It can reduce the initial load time because it defers loading the image until it reaches a calculated distance from the viewport.
Incremental Static Regeneration (ISR) perfectly balances static site generation and server-side rendering, allowing for fast page loads while keeping content fresh.
- Fast page loading: Due to static generation at build time, the initial load becomes very fast
- Improved SEO: Statically generated pages can be easily indexed by search engines
- Automated updates: By using ISR (Incremental Static Regeneration), pages can be regenerated at specified intervals to reflect new product information

2. Structured Data and Metadata Enhancement

Key Strategies:

Implementing Schema.org structured data for product listings can potentially lead to rich snippets in search results, increasing click-through rates.
Carefully crafted meta titles and descriptions, incorporating primary keywords can significantly improve search visibility.
Proper implementation of OG tags and Twitter cards can boost social media sharing, indirectly supporting SEO efforts.

3. Technical SEO Implementation

Key Strategies:

By using the WebP format, you can significantly reduce file sizes while maintaining almost the same image quality. This results in an expected improvement in display speed.
Setting appropriate alt tags for images allows users to understand the content even in poor network conditions through text-to-speech functionality, and provide web content audibly to users with visual impairments. While it's unclear whether this directly improves SEO, it's expected that enhancing usability will improve the user experience, potentially leading to better evaluation and recognition.
Implementing an efficient pagination strategy is crucial for large e-commerce sites to ensure all products are crawled and indexed.
Semantic HTML Structure: We ensured our HTML structure was semantic and well-organized, using appropriate heading tags (H1, H2, etc.), paragraph tags, and so on.
Setting proper hreflang tags for Google to identify our website, which offers multiple languages.

Conclusion

SEO optimization is not something that can be achieved overnight, and there are many things you can do. Among these, Next.js provides numerous features that make it easier to improve performance. I hope you can utilize the features that suit your project to enhance SEO and performance!

If you know of any other methods to improve SEO, please let me know in the comments!

Things I got stuck with when unit testing REST APIs using Jest and React Testing Library.

Marie Otaki — Tue, 22 Dec 2020 06:30:06 +0000

The reason why I started to write test code

I’m a React lover and have been creating a lot of web apps using React. However, I’ve never written test cases for them before. Usually, I start with a tutorial when I learn something new. Then, I create my app based on the knowledge that I gained from the tutorial. Either way, I didn’t have to write testing. When it comes to creating some apps with tutorials, testing is out of their scope most of the time. What about the time I create apps by myself?
Honestly, I thought that’s fine as long as the app is working. Yeah… that might be okay, but I can make it better!

Especially when it comes to production-level application, it must work safely. If I cause system failure on the production, the effect would be enormous. It’s enough reason to start learning test, isn’t it? That is why I started writing tests.

How is the project I write test cases for like?

The latest project I created by myself was a YouTube clone app. This is a simple React app working almost the same as YouTube. You can search for videos that you want to watch by keywords, and play them on it. Though I created it following a tutorial, there was no instruction about testing as usual. So, I decided to write testing for this app.

I’m using Jest and React Testing Library this time to write unit testing. Please note that I’ll skip the explanation about what they are in detail this time. If you’d like to know them more in detail, I recommend reading this article.

You can play around with this app here, by the way.😀

What kind of tests do I write?

Since the YouTube clone app fetches data from the YouTube API and passes them to each React component I decided to check if it executes as expected.

Here is my GitHub repo. If you feel something missing in my explanation, it might help.

I've taken out the part of the code that fetches data from the API. When hitting each endpoint by a GET method, the YouTube API returns a response as requested. I'm going to check if fetching data from the API (mock API) and being displayed correctly in React DOM.

import axios from 'axios';

const KEY = process.env.REACT_APP_YOUTUBE_API_KEY;

const youtube = axios.create({
  baseURL: 'https://www.googleapis.com/youtube/v3',
});

axios.defaults.withCredentials = true;

const params = {
  part: 'snippet',
  maxResults: '40',
  key: KEY,
  regionCode: 'CA',
  type: 'video',
};

export const fetchPopularData = async () => {
  return await youtube.get('/videos', {
    params: {
      ...params,
      chart: 'mostPopular',
    },
  });
};

export const fetchSelectedData = async (id) => {
  return await youtube.get('/videos', {
    params: {
      ...params,
      id,
    },
  });
};

export const fetchRelatedData = async (id) => {
  return await youtube.get('/search', {
    params: {
      ...params,
      relatedToVideoId: id,
    },
  });
};

export const fetchSearchData = async (query) => {
  return await youtube.get('/search', {
    params: {
      ...params,
      q: query,
    },
  });
};

Preaparetion for the testing for APIs

Before diving into tests, you have to create a server that acts like the real API. That means you have to make the API returns data when its endpoint is hit as the YouTube API does so. How would you do that? Let's take a look at the example.

To create a server, I use Mock Service Worker. Their documentation is well organized and very easy to understand. I recommend looking over it. I'll move forward on the premise that you already know MSW this time.

const popularItems = [
  {
    id: '0',
    snippet: {
      thumbnails: {
        default: {
          url: 'https://dummyimage1/default.jpg',
          width: 120,
          height: 90,
        },
      },
      title: 'title1',
    },
  },
  {
    id: '1',
    snippet: {
      thumbnails: {
        default: {
          url: 'https://dummyimage2/default.jpg',
          width: 120,
          height: 90,
        },
      },
      title: 'title2',
    },
  },
  {
    id: '2',
    snippet: {
      thumbnails: {
        default: {
          url: 'https://dummyimage3/default.jpg',
          width: 120,
          height: 90,
        },
      },
      title: 'title3',
    },
  },
];
const server = setupServer(
  rest.get('https://www.googleapis.com/youtube/v3/videos', (req, res, ctx) => {
    return res(ctx.status(200), ctx.json({ items: popularItems }));
  })
);

beforeAll(() => {
  server.listen();
});

afterEach(() => {
  server.resetHandlers();
  cleanup();
});

afterAll(() => {
  server.close();
});

The core part is the code below. When you hit the endpoint('https://www.googleapis.com/youtube/v3/videos') this server returns 200 status(success status that indicates that the request has succeeded) and JSON data, which has items property and value called popularItems.

const server = setupServer(
  rest.get('https://www.googleapis.com/youtube/v3/videos', (req, res, ctx) => {
    return res(ctx.status(200), ctx.json({ items: popularItems }));
  })
);

I'll explain the other code briefly.
Before starting testing, you should listen to the server with beforeAll().

beforeAll(() => {
  server.listen();
});

You can reset any request handlers that you may add during the tests by using afterEach(), so they don't affect other tests.

afterEach(() => {
  server.resetHandlers();
  cleanup();
});

You can clean up after the tests are finished using afterAll().

afterAll(() => {
  server.close();
});

Let's write test cases!

Here is the code of test cases. Let's take a closer look at the code.

describe('Mocking API', () => {
  it('[Fetch success] Should fetch data correctly', async () => {
    render(
      <StoreProvider>
        <Router>
          <Top />
        </Router>
      </StoreProvider>
    );

    //check if the first object in popularItems is displayed correctly.
    expect(await screen.findByText('title1')).toBeInTheDocument();
    expect(screen.getByAltText('title1')).toBeTruthy();
    expect(screen.getByAltText('title1')).toHaveAttribute(
      'src',
      'https://dummyimage1/default.jpg'
    );

    //check if the second object in popularItems is displayed correctly.
    expect(await screen.findByText('title2')).toBeInTheDocument();
    expect(screen.getByAltText('title2')).toBeTruthy();
    expect(screen.getByAltText('title2')).toHaveAttribute(
      'src',
      'https://dummyimage2/default.jpg'
    );

    //check if the third object in popularItems is displayed correctly.
    expect(await screen.findByText('title3')).toBeInTheDocument();
    expect(screen.getByAltText('title3')).toBeTruthy();
    expect(screen.getByAltText('title3')).toHaveAttribute(
      'src',
      'https://dummyimage3/default.jpg'
    );
  });
});

I'll explain a bit about the keywords used in this code.

describe: explains what kind of test it is. You can write test cases in the function passed as the second argument.
it: describes the test itself. It takes as parameters the name of the test and a function that hold the tests.
render：the method used to render a given component(in this case, is the target I'd like to test)
expect: the condition that the test needs to pass.

For example, the code below means like that…

I expect 'title1' to exist in the document
I expect 'title1' to exit as an alt attribute (I'd like to check if img tag where alt ='title1' exists)
I expect 'title1' to exist as an alt attribute (I'd like to check if img tag where alt ='title1' exists) has src attribute 'https://dummyimage1/default.jpg'

//check if the first object in popularItems is displayed correctly.
    expect(await screen.findByText('title1')).toBeInTheDocument();
    expect(screen.getByAltText('title1')).toBeTruthy();
    expect(screen.getByAltText('title1')).toHaveAttribute(
      'src',
      'https://dummyimage1/default.jpg'
    );

What are the problems I had and how to solve them?

Problem1: How would you access the global state?

Now that I introduced my final code first, you might not imagine how much I struggled until I finished this project. However, I had several problems when coding, so let me introduce them.

The first point that I got stuck on was to access globalState. When rendering the component to be tested, usually you write code like this.

 render(<Top />);

I went the same way at first. However, as soon as I run the test, I came across the error.

Error: Uncaught [Error: Invariant failed:
You should not use <Link> outside a <Router>

Okay, that is because I used inside the Top component, but I didn't wrap them with . Then, I modified it like so.

render(
   <Router>
     <Top />
   </Router>
);

This time, it seems to fix the error, but it still didn't pass the test.

Unable to find an element with the text: title1. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.

Why a thing like this happened? Because the YouTube clone app is using React context API and state managed by globalState. Let's take a look at App.js and index.js the upper layer of that.

//src/App.js
function App() {
  return (
    <Router>
      <Switch>
        <Route exact path="/" component={Top} />
        <Route exact path="/search" component={Search} />
        <Route exact path="/watch" component={Watch} />
      </Switch>
    </Router>
  );
}

export default App;

//src/index.js
ReactDOM.render(
  <React.StrictMode>
    <StoreProvider>
      <App />
    </StoreProvider>
  </React.StrictMode>,
  document.getElementById('root')
);

In the App.js every component is wrapped with , while in index.js App component is wrapped with which manages the global state. It didn't pass the test because I didn't wrap the Top component with both and . Eventually, the correct code is like this.

render(
      <StoreProvider>
        <Router>
          <Top />
        </Router>
      </StoreProvider>
    );

Now, you should run the test correctly! 👏

Problem2: What if the endpoint needs a certain query?

Let's take a look at another component to be tested.

import React, { useEffect, useContext } from 'react';
import Layout from '../components/Layout/Layout';
import VideoGrid from '../components/VideoGrid/VideoGrid';
import VideoGridItem from '../components/VideoGridItem/VideoGridItem';
import { useLocation } from 'react-router-dom';
import { fetchSearchData } from '../apis';
import { Store } from '../store/index';

const Search = () => {
  const { globalState, setGlobalState } = useContext(Store);
  const location = useLocation();

  useEffect(() => {
    const setSearchResult = async () => {
      const searchParams = new URLSearchParams(location.search);
      const query = searchParams.get('query');
      if (query) {
        await fetchSearchData(query).then((res) => {
          setGlobalState({
            type: 'SET_SEARCHED',
            payload: { searched: res.data.items },
          });
        });
      }
    };
    setSearchResult();
  }, [setGlobalState, location.search]);

  return (
    <Layout>
      <VideoGrid>
        {globalState.searched ? (
          globalState.searched.map((search) => {
            return (
              <VideoGridItem
                id={search.id.videoId}
                key={search.id.videoId}
                src={search.snippet.thumbnails.medium.url}
                title={search.snippet.title}
              />
            );
          })
        ) : (
          <span>no data</span>
        )}
      </VideoGrid>
    </Layout>
  );
};

export default Search;

It's almost the same structure as the component that I mentioned earlier, but you need a query to fetch data from API in this case. So, how would you do the same thing in the test?

If you are using React Router (Most of the React projects are using it, I guess.), you can use createMemoryHistory.

createMemoryHistory(options)
createMemoryHistory creates an in-memory history object that does not interact with the browser URL. This is useful when you need to customize the history used for server-side rendering, as well as for automated testing.

As in this description, it's the best fit for automated testing! So, it's time to write testing!

const searchedItems = [
  {
    id: {
      videoId: 'serched00',
    },
    snippet: {
      thumbnails: {
        medium: {
          url: 'https://dummyimage1/mqdefault.jpg',
          width: 320,
          height: 180,
        },
      },
      title: 'title1',
    },
  }
//omission
];

const server = setupServer(
  rest.get(
    'https://www.googleapis.com/youtube/v3/search?query=dummy',
    (req, res, ctx) => res(ctx.status(200), ctx.json({ items: searchedItems }))
  )
);

beforeAll(() => {
  server.listen();
});

afterEach(() => {
  server.resetHandlers();
  cleanup();
});

afterAll(() => {
  server.close();
});

describe('Mocking API', () => {
  it('[Fetch success] Should fetch data correctly', async () => {
    const history = createMemoryHistory();
    history.push('/search?query=dummy');

    render(
      <StoreProvider>
        <Router history={history}>
          <Search />
        </Router>
      </StoreProvider>
    );

    //check if the first object in popularItems is displayed correctly.
    expect(await screen.findByText('title1')).toBeInTheDocument();
    expect(screen.getByAltText('title1')).toBeTruthy();
    expect(screen.getByAltText('title1')).toHaveAttribute(
      'src',
      'https://dummyimage1/mqdefault.jpg'
    );
  });
});

In this case, it acts like that you are in the path '/search' with query 'dummy'.

//src/pages/Search.test.js
const history = createMemoryHistory();
    history.push('/search?query=dummy');

    render(
      <StoreProvider>
        <Router history={history}>
          <Search />
        </Router>
      </StoreProvider>
    );

This is how you can get the query in the Search component.

//src/pages/Search.js
 useEffect(() => {
    const setSearchResult = async () => {
      const searchParams = new URLSearchParams(location.search);
      const query = searchParams.get('query');
      if (query) {
        await fetchSearchData(query).then((res) => {
          setGlobalState({
            type: 'SET_SEARCHED',
            payload: { searched: res.data.items },
          });
        });
      }
    };
    setSearchResult();
  }, [setGlobalState, location.search]);

Here are more example using createMemoryHistory().
https://testing-library.com/docs/example-react-router/

To learn history a little bit more, this article might help.
https://medium.com/@pshrmn/a-little-bit-of-history-f245306f48dd

Problem3: Didn't pass the tests due to the structure of the dummy data.

I failed to test many times due to the structure of the dummy data, so make sure the data structure is the same as the real data!

Problem4: Didn't pass the tests because I didn't wrap the tests with async.

When you write test cases for APIs, you have to use async because it takes a while until completing to fetch data from it. Don't forget to use it in your test cases.

When you write test cases for the first time, you may face errors a lot like me. I hope this article helps! If you have any questions or suggestions, please let me know! Thank you so much for reading! 😀

I'm open to discussing new opportunities in web development!🔥
Also, I'm working on #100DaysOfCode on Twitter right now. Check it out if you like!

Twitter: @marie_otaki
Note: This article first appeared on my Medium blog.

DEV Community: Marie Otaki

Separating Concerns in Next.js for Better Performance, Security, and Maintainability

Performance improvement

MVP version

Improved version

Security improvement

MVP version

Improved version

Maintainability improvement

MVP version

Improved version

Column: What's the difference between import server-only and use server?

Conclusion

Maximizing SEO and Performance with Next.js: Strategies from an Activity Booking Platform Project

Introduction

Our Approach

1. Performance Optimization

Key Strategies:

2. Structured Data and Metadata Enhancement

Key Strategies:

3. Technical SEO Implementation

Key Strategies:

Conclusion

Things I got stuck with when unit testing REST APIs using Jest and React Testing Library.

The reason why I started to write test code

How is the project I write test cases for like?

What kind of tests do I write?

Preaparetion for the testing for APIs

Let's write test cases!

What are the problems I had and how to solve them?

Problem1: How would you access the global state?

Problem2: What if the endpoint needs a certain query?

Problem3: Didn't pass the tests due to the structure of the dummy data.

Problem4: Didn't pass the tests because I didn't wrap the tests with async.

Column: What's the difference between `import server-only` and `use server`?