[#349] 메타 데이터 추가

[hanyugeon]

구현 내용

메타 데이터를 추가했어요
무엇이 추가되었는지 항목별로 볼 수 있도록
리스트형식으로 PR을 정리해 보았어요 ㅎ

메타태그 리스트

• title
• description
• keywords
• google-site-verification (구글 사이트 소유권 등록)
• naver-site-verification (네이버 사이트 소유권 등록)
  (네이버의 경우엔 release에 Merge되면 정상적으로 등록될거에요!)

사이트맵

api를 활용하여 동적으로 사이트맵을 생성하고있어요!
사이트맵에 포함된 주소 리스트에요 사이트맵 프리뷰

• 비로그인 북카이브에 노출된 책장 페이지 (ex: /bookshelf/[bookshelfId])
• 비로그인 북카이브에 노출된 도서 페이지 (ex: /books/[bookId])
• 모든 독서 모임 페이지 (ex: /group/[groupId])
  (api가 한정적이다보니 더 많은 사이트맵을 확보하는대엔 무리가 있었어요 😢 )

Etc.

• 오픈그래프 이미지
• robots.ts
  (robots.ts의 역할은 검색 엔진 크롤러가 사이트에서 액세스할 수 있는 URL을 알려줘요)

스크린샷

추가 된 메타태그 이미지 👀

PR포인트

getSitemap.ts

해당 파일의 fetch는 서버사이드에서 실행되요
그래서 axios나 react-query같은 클라이언트 펑션은 사용이 불가능합니다! 참고해주세요!

비로그인의 사용자가 서비스에 접근할 수 있는 최대한의 페이지를
api를 활용하여 동적으로 사이트맵에 담도록 도와주는 유틸 함수 입니다.

관련 이슈

• Close 메타 데이터 추가 #349

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
dadok	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 11, 2024 7:47am

[github-actions]

🚀 Storybook: https://64aba10cd478ad51307a8997-yjjhouvvvw.chromatic.com/

[github-actions]

⚡️ Lighthouse Average Scores Across Reports:

Category	Score
🔴 performance	60
🟠 accessibility	81
🟢 best practices	98
🟢 seo	100
🔴 pwa	51

⚡️ Average Details Across All Reports:

Category	Score
🟢 first contentful paint	1.1s
🔴 largest contentful paint	12.8s
🔴 interactive	9.8s
🟠 total blocking time	323.8ms
🟢 cumulative layout shift	0.0

[hanyugeon]

comment;

해당 파일의 데이터 패칭은 서버사이드에서 실행되요

그래서 axios나 react-query같은 클라이언트 펑션은 사용이 불가능합니다!
참고해주세요!

[gxxrxn]

comment;

axios는 클라이언트와 서버 사이드 모두에서 사용가능한 라이브러리라고 알고 있어요! (서버사이드에서는 axios 내부적으로 fetch 메서드를 사용하는걸로 알고 있어요.)

await fetch(
    `${process.env.NEXT_PUBLIC_API_URL}/api/suggestions/bookshelves/default`,
    options
  )

fetch 대신

await RecommendAPI.getUnAuthRecommendedBookshelf();

axios를 사용해도 동일한 결과가 나오긴 하더라구요!

다만 api 호출을 위해 정의해뒀던 publicApi axios 인스턴스에는 auth를 위한 로직이 포함되어 있기도 하고, 서버사이드에서 기본 fetch를 사용했을 때 캐싱 등에 이점이 있는걸로 알고 있어서, 기본 fetch를 사용하는건 좋아보여요! (그리고 왜인지는 모르겠으나.. fetch와 axios를 비교해봤을 때 api 응답 속도에.. 약 2배 정도의 차이가 있더라구요..?🙄 axios가 좀 더 느리더라구요..)

[hanyugeon]

comment;

booksId은 북카이브 책장에 노출된 책들의 Id값을 담은 배열이에요
booksId에는 중복되는 책 Id가 존재할 수 있어요.

filteredBooksId은 중복되는 책 Id를 필터링한 배열이에요.

[gxxrxn]

comment;

오.. 중복이라는 단어를 보자마자 Set이 생각났어요! Set 객체를 활용해보면 어떨까요?

[hanyugeon]

@gxxrxn

Set 객체를 활용했을 때 나타나는 타입 에러에요..!

해당 에러가 나타나는 이유는 TypeScript에서 Set은 이터러블(iterable)하지만, ECMAScript 2015(ES6) 이전의 타겟 버전으로 컴파일할 경우에는 기본적으로 이터레이션(iteration)을 지원하지 않기 때문이라고해요!

tsconfig.ts에 있는 target을 es6로 수정했을때는 해당 타입에러가 발생하지 않아요!
(현재 저희 프로젝트는 target: 'es5'로 되어있습니다.)
es6로 변경 후에 빌드했을 때 사이드이펙트가 생기진 않는 것 같네요!

규란님의 의견이 궁금해요!! 저는 바꾸어도 될 것 같아요 👀

[gxxrxn]

const books = new Set<APIBook['bookId']>();

data.bookshelfResponses.forEach(bookshelf =>
  bookshelf.books.forEach(book => books.add(book.bookId))
);

const filteredBooks = Array.from(books);

books 변수 자체를 set 객체로 생성하고, Array.from() 메소드를 사용해서 배열로 변환하는 방법을 사용하면 어떨까요?!

[hanyugeon]

반영하였습니다! 25bd581

javascript 기본기의 필요성을 느꼈습니다 👍

[gxxrxn]

각 상세페이지에 대한 url을 동적으로 생성하는데 어려움이 많았을 것 같아요 😞 수고 많으셨습니다!! 👏🏻 코멘트가 좀 긴데.. 고민되는 부분을 담은거라 편하게 읽어주시면 감사하겠습니당..ㅎㅎ 🙇🏻‍♀️

---

책, 책장, 모임 상세 페이지처럼 동적으로 생성해야하는 url들은 사이트맵을 분할해서 관리해도 좋겠다는 생각이 들었어요.

물론 sitemap 파일 하나당 최대 url 개수가 50000개라 (Google 기준) 다독다독 정도의 사이즈에서는 분할했을 때 이점이 크지 않을 수 있지만, getSitemaps.ts 파일 내에서 각 상세 페이지에 대한 url 리스트를 따로 만들고 있는만큼 각 route에서 sitemap 생성을 관리하는 구조도 괜찮을 것 같다는 생각이 들었어요! 이렇게 구현해둔다면 추후 상세 페이지 수가 많아졌을 때 next.js에서 제공하는 generateSitemaps() 를 통해 더 작은 사이즈의 sitemap으로 분할도 가능하다는 이점이 있을 것 같아요.

// app/bookshelf/sitemap.ts
// 생성된 sitemap > https://local.dev.dadok.app:3000/bookshelf/sitemap.xml

import { MetadataRoute } from 'next';

import { APIRecommendedBookshelf } from '@/types/bookshelf';

export async function getBookshelves() {
  try {
    const res = await fetch(
      `${process.env.NEXT_PUBLIC_API_URL}/api/suggestions/bookshelves/default`,
      options
    );

    if (!res.ok) {
      return Promise.reject();
    }

    const data: APIRecommendedBookshelf = await res.json();
    return data.bookshelfResponses.map(({ bookshelfId }) => ({
      bookshelfId,
    }));
  } catch {
    return [];
  }
}

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const bookshelves = await getBookshelves();
  return bookshelves.map(({ bookshelfId }) => ({
    url: `${process.env.NEXT_PUBLIC_HOST}/bookshelf/${bookshelfId}`,
    lastModified: new Date(),
  }));
}

이렇게 작성했는데 잘 동작하더라구요!!

다만.. 한가지 이슈가 있어요..🫠

sitemap을 분할한 경우, sitemap index 파일을 생성해서 하위의 여러 sitemap을 한번에 제출하는 형태가 일반적인데 nextjs에서는 sitemap을 분할하는 기능만 제공하고 아직 sitemap index 파일을 생성해주진 않는 것 같더라구요..😭

관련 discussion을 찾았는데 아직까지는 sitemap index 파일을 생성하려면 이렇게 동적으로 생성하는게 최선의 방법인 것 같았어요!

그래서 고민해봤는데, 추후 확장성을 생각해서 각 route에서 sitemap을 생성하는 코드는 추가하되, sitemap index를 생성하는 대신 root sitemap에서 하위 sitemap들을 합쳐주는 형태로 작성해보는건 어떨까요?!

import { MetadataRoute } from 'next';

// bookgroup, book sitemap도 아래와 같은 형태로 추가
import bookshelvesSitemap from '@/app/bookshelf/sitemap';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  return [
    {
      url: 'https://dadok.app/bookarchive',
      lastModified: new Date(),
    },
    {
      url: 'https://dadok.app/book/search',
      lastModified: new Date(),
    },
    {
      url: 'https://dadok.app/group',
      lastModified: new Date(),
    },
    {
      url: 'https://dadok.app/profile/me',
      lastModified: new Date(),
    },

    ...(await bookshelvesSitemap()),
  ];
}

sitemap index 파일 생성에 복잡함이 있어서 차선의 방법을 작성해보긴 했지만.. 지금 방식도 현재 수준에서는 충분히 괜찮아보여요! 그리고 위와 같이 작성했을 때 sitemap index 파일을 생성하지 않는 이상 하위 sitemap이 생성만 되고 사용되지 않는다는 점도 리소스 낭비가 될 수 있을 것 같다는 생각이 들기도 하구요..

1. 현재처럼 getSitemaps 파일에서 모든 url 동적으로 생성
2. app 디렉토리 내부에서 route별로 sitemap 생성 후 root sitemap에서 import하여 url 동적으로 생성
3. app 디렉토리 내부에서 route별로 sitemap 생성 후 sitemap index 파일 생성

위 3가지 중 어떤 방법이 좋을지 선택하면 될 것 같은데.. 재현님 의견이 궁금해요!! 두서없이 작성한 것 같은데.. 천천히 확인해주세요!!ㅎㅎ 긴 글 읽어주셔서 감사합니다! 🙇🏻‍♀️

[gxxrxn]

comment;

문득.. 지난번처럼 부득이하게 도메인을 수정해야하는 경우, sitemap 관련 파일의 url을 모두 수정해야하기 때문에 불편함이 있을 것 같다는 생각이 들었어요. process.env.NEXT_PUBLIC_HOST 환경변수를 사용하면 어떤 문제가 있을까요..?!

[hanyugeon]

@gxxrxn

앗 제가 놓친 부분이에요!
99ae2df 반영하였습니다!

[gxxrxn]

comment;

axios는 클라이언트와 서버 사이드 모두에서 사용가능한 라이브러리라고 알고 있어요! (서버사이드에서는 axios 내부적으로 fetch 메서드를 사용하는걸로 알고 있어요.)

await fetch(
    `${process.env.NEXT_PUBLIC_API_URL}/api/suggestions/bookshelves/default`,
    options
  )

fetch 대신

await RecommendAPI.getUnAuthRecommendedBookshelf();

axios를 사용해도 동일한 결과가 나오긴 하더라구요!

다만 api 호출을 위해 정의해뒀던 publicApi axios 인스턴스에는 auth를 위한 로직이 포함되어 있기도 하고, 서버사이드에서 기본 fetch를 사용했을 때 캐싱 등에 이점이 있는걸로 알고 있어서, 기본 fetch를 사용하는건 좋아보여요! (그리고 왜인지는 모르겠으나.. fetch와 axios를 비교해봤을 때 api 응답 속도에.. 약 2배 정도의 차이가 있더라구요..?🙄 axios가 좀 더 느리더라구요..)

[gxxrxn]

comment;

오.. 중복이라는 단어를 보자마자 Set이 생각났어요! Set 객체를 활용해보면 어떨까요?

[hanyugeon]

@gxxrxn

규란님의 코멘트 너무 유익하게 잘 보았어요!!
결론부터 이야기 하면 제시하셨던 방법중 2번째 방법을 채택하여 반영하였습니다 682d150

2번째 방법을 채택한 이유는

1. Next.js 공식문서에서 route별로 나누어 layout, template, not-found 등을 작성하는 것을 의도하는것 처럼 보였어요.
2. 3번째를 선택할 수 있지 않았을까? 라는 물음에는 아직 Next.js에서 route별로 나누어진 sitemap을 합쳐주진 않지만 추후에 next에서 index파일로 합쳐주는 기능이 생긴다면 2번이 좀 더 유연하게 마이그레이션이 가능할 것 같아서였습니다!
3. 1번 방법도 나쁜건아니지만... Next측에서 써보라고 내놓은 기능을 조금 더 활용해볼 기회는 이제 거의 없을 것 같아서였어요! 😄
4. 불필요하게 sitemap을 여러번 생성하는게 아닌가 하는 단점도 있지만 많은 리소스가 소모되는것은 아니라 괜찮다고 판단했습니다!

한번 더 제가 작성한 코드에 대해 생각해보고 고민해볼 수 있어서 좋았어요 감사합니다!!! 🙇 👍

[gxxrxn]

👍🏻