개발자
류준열

블로그 제작 과정

티스토리에서 블로그를 운영하고 있지만 프론트엔드 개발자가 쌩으로 만든 블로그 하나는 갖고 있어야 하는것 아닌가? 하는 생각에 블로그를 만들게 되었다.

가장 고민이 되었던 것은 아래 세가지였다.

  1. CMS를 뭘로 할 까
  2. 디자인은 어떻게 하나..

CMS는 노션api로 만들다가 이미지 이슈때문에 DatoCMS로 변경했다.
디자인은 simple is best 전략을 사용했고, atomic 패턴을 사용한 컴포넌트 라이브러리를 만들어 작업하였다.

CMS

처음엔 노션으로 시도했다.

처음에 노션 api를 사용한 이유는 사실 익숙해서 였다. 내가 생각했던 것은 노션api를 통해 내 노션에 작성한 글을 markdown으로 받아와서 화면에 렌더링하는 것이었다.

아무 문제없이 되었는데 문제는 이미지였다. 이미지의 로딩이 너무 느렸고, 해상도나 size등을 내가 원하는대로 변경할 수 없었다.

그리고 가장 치명적인건 노션 api로 이미지를 불러올때, 매 시간마다 새로운 url로 s3에 저장되기 때문에 url이 보존되지 않았고, 1시간후에는 캐싱이 사라지며, 관련한 속성들을 변경할 권한이 내게 없었다.

DatoCMS

이미지를 내가 컨트롤 할 수 있으면서도, 여전히 노션처럼 외부에 글을 쓰면 블로그에 자동 업데이트 되도록 할 수 있는 CMS를 찾다가 DatoCMS라는 것을 알게 되었다.

통신 방식

통신 방식은 graphQL이다.

또한 어드민내에 play ground가 있어서 개발이 편리했다. dato playground

next 신버전인 app-router에서 어떻게 작업해야 하는지도 친절히 가이드하고 있다.

처음에는 apollo를 graphQL과 합쳤는데, 가만 생각해보니 캐싱을 next revalidation으로만 하기 때문에 apollo를 쓸 필요가 없어서 삭제했다.

이미지

Dato 공식문서에 image를 관리할 수 있는 방법이 잘 나와 있었다.

blur

base64도 내려받을 수 있기 때문에 원한다면 손쉽게 placeholder='blur' 처리도 가능하다. (단 마크다운내 이미지들은 내가 직접 base64를 따와야해서 그냥 LCP방지만 하였다.) blur

import Image from "next/image";
import { NO_IMAGE } from "@/utils/constant";

<Image
    {...responsiveImage}
    src={responsiveImage?.src || NO_IMAGE.src}
    alt={responsiveImage?.alt || NO_IMAGE.alt}
    placeholder="blur"
    blurDataURL={responsiveImage?.base64}
/>
리사이징

리사이징 같은 경우 옵션값으로 원하는 크기를 요청할 수 있다.

리사이징

export const IMAGE_SIZE_IN_POSTS = {
  width: 180,
  height: 120,
};

export const GET_META_FIELDS = `
  query allArticles {
    allArticles(orderBy: _createdAt_DESC) {
      id
      category
      _createdAt
      metaField {
        description
        title
        image {
          responsiveImage(imgixParams: { fit: crop, w: ${IMAGE_SIZE_IN_POSTS.width}, h: ${IMAGE_SIZE_IN_POSTS.height}, auto: format }) {
            src 
            sizes
            height
            width
            alt
            title
            base64
          }
        }
      }    
    }
  }
`;

마크다운 내의 이미지는 다음과 같이 url query로 w,h를 붙혀서 리사이징 할 수 있다.
https://www.datocms-assets.com/107137/1700532762-blur.png?w=500 리사이징한 이미지

Component Library

junyeol-components를 npm 배포하였다.

컴포넌트 라이브러리에서 공통 훅, 공통 컴포넌트들을 먼저 만들고 blog에서 가져다쓰는 방식으로 개발했다. blog에서 작업하다가 컴포넌트 문제가 생기면 컴포넌트 라이브러리를 재배포해야했다. 이런 시행착오들을 거치면서 범용성 있는 컴포넌트에 대해 고민 할 수 있었다.

Next app router

서버컴포넌트를 처음 접해서 신기하면서도 조금 애먹었다. 많이 바뀐것 같지만 이전 next를 이용했다면 쉽게 익숙해질 수 있다.

revalidation time, SEO를 위한 meta data 를 작성하는 것이 더욱 직관적으로 변경되었다고 생각했다. 굳이 공식문서에서 볼 수 있는 내용을 설명하지는 않겠다.

컴포넌트 라이브러리는 외부에서 import 해서 사용하기 때문에 컴포넌트 라이브러리를 사용하는 페이지들은 유저인터렉션이 없음에도 client component로 만들어야했다.

배포

배포문제로 고민하기 싫어서 next에 최적화되어 있는 vercel을 선택했다. react로 만든 컴포넌트 라이브러리도 vercel로 배포했다. 코드문제가 아닌 이상은 배포가 막히는 적이 없었다.