project : post-mobism

post-mobism(포스트 모비즘, 이하 모비즘)은 mobithon API를 활용해 만든 기본 CRUD 기능 구현에 충실한 미니 토이 프로젝트입니다.

• 프로젝트 진행 기간 : 2024.02.03 ~ 2024.02.17
• 리팩터링 기간 : 2024.02.16 ~ 2024.02.17

설 연휴 3일을 포함해 약 12일동안 진행한 프로젝트 post-mobism의 목표는 아래 두 가지였습니다.

1. backend API 분석 제대로 해보기
2. Redux Toolkit(RTK)를 사용해 전역 상태 관리하기

이전 프로젝트 Chap-Chap에서 부족했던 부분은 백엔드 API의 분석 부족이었습니다.
백엔드 API 분석을 제대로 하지 않고 들어가 당시 mobithon API를 활용하지 못했고
프론트 단 개발을 진행하면서 로직 수정을 굉장히 자주해야 했습니다.

그래서 이번에는 같이 API를 분석해보고 분석한 내용을 토대로 디자인을 진행해보기로 했습니다.

API 분석은 sequence diagram을 통해 진행했습니다.
같이 진행한 부분은 gitHub의 readme 마크다운 파일에 첨부되어 있습니다.

처음에 페이지 별로 프론트 단을 나누어 총 5단계(클라이언트-프론트(3페이지)-백엔드)로 나누어 분석을 진행했으나 프로젝트의 크기가 작기 때문에 라이트하게 진행하는 것이 좋을 것 같다는 피드백을 받고 위와 같이 간소화해 다이어그램을 그렸습니다.

처음에 작업 순서를 잘못 짜서 살짝 딜레이가 됐습니다.
설계 → 와이프레임 → 디자인 → 개발 순으로 진행하기 위해 각자 sequence diagram에 대해 알아보고 그려보는 시간을 갖기로 했으나 설계를 진행하다보니 디자인이 없이 진행하기가 애매한 부분이 있었습니다.

디자인에 관련된 얘기를 사전에 하지 않아 다시 와이어프레임 → 설계 → 디자인 → 개발 순으로 같이 진행했습니다.

---

Designing... 🎨

post-mobism은 post-modernism(포스트 모더니즘)에서 착안한 이름입니다.

본 프로젝트의 주 기능이 post와 comment의 CRUD이기 때문에 'post'라는 키워드를 넣고 싶었습니다. 바로 post-modernism(포스트 모더니즘)이 떠올라 mobi주의(mobi사상)에 맞게 code를 post한다는 주제로 이름을 붙여 프로젝트를 진행하게 되었습니다.

post-mobism은 mobi 새싹들의 코드를 공유하고 서로 리뷰해주는 사이트입니다.

| "Less is Bore"

아래는 와이어프레임의 일부입니다.
올해의 컬러인 peach fuzz(피치퍼즈)를 베이스 컬러로 사용, 포인트 컬러는 이와 잘 어울리는 밝은 레드 컬러를 사용했습니다.

🖼️ 참고 블로그

---

Developing... 💻

결론부터 말하자면...
이번 토이 프로젝트에서 API 분석은 제대로 이뤄지지 않았습니다. 🥲

분석과 설계 과정에서 어떤 얘기들을 했어야 하는지, 분석을 토대로 어떤 부분들을 사전에 의논했어야 개발을 더 효율적으로 할 수 있는지를 제대로 모르고 진행했기 때문에 이번 프로젝트를 진행하면서도 많이 헤맸습니다.

아래는 mobism을 진행하는 과정에서 겪은 시행착오를 토대로 앞으로 어떻게 진행하면 좋을지 다시 한 번 더 생각해본 뒤 작성해봤습니다.

---

⚙️ basic-settings

협업을 위해 사용 예정인 라이브러리와 협업 툴을 깔아줍니다.
기본 세팅은 프로젝트 폴더 생성 후 API 관련 로직 작성 전에 진행하면 됩니다.

기본 세팅이 궁금하다면? 👉 55555-jyeon 게시글 참고하기

---

📊 API

🔎 API 분석 및 설계

sequence diagram으로 API 문서와 wire-frame을 토대로
기능의 구현 가능 여부를 따져봅니다.

---

⚡️ thunder client로 response.data 받아보기

BE 개발자로부터 전달받은 API 안내서(?)를 토대로 썬더 클라이언트에 요청을 보내봅니다.
확인 및 응답으로 어떤 형태의 데이터가 오는지 확인하기 위해 꼭 진행하는 것이 좋습니다.

썬더 클라이언트로 요청을 보내보면서 어떤 값을 필요로 하는지, 어떻게 보낼지 등을 확실히 할 수 있습니다. 추가적으로 요청 진행 중 오류를 발견한 경우, BE 개발자에게 빠른 notice를 할 수 있어 효율적인 개발을 진행할 수 있습니다.

sign-up & sign-in

get & post post data

`post comment`

---

📞 response.data를 토대로 type과 mockData 생성

위에서 thunder client로 확인한 데이터의 형태를 그대로 가져와 목데이터와 type을 만듭니다.

form type

export type SignUpUser = {
  userId: string
  password: string
  nickname: string
}

export type SignInUser = {
  userId: string
  password: string
  nickName: string
  profileUrl: string
  token?: string
}
  
export type User = {
  id: string
  nickName: string
  profileImg: string
}

post type

export type TPostsResponse = {
  data: Post[] | []
  pageNation?: Pagination
}

export type Post = {
  id: string
  data: { title: string; content: string }
  dataUser: { data: { nickName: string }; profile_url: string; userId: string }
  dataImage?: []
  createdAt: string
}

export type Pagination = {
  start: number
  end: number
  total: number
  set: number
  current: number
}

comment type

export type TCommentsResponse = {
  data: Comment[]
  pageNation?: Pagination
}

export type Comment = {
  id: string
  data: { content: string }
  dataUser: { data: { nickName: string }; profile_url: string; userId: string }
  createdAt: string
}

---

🛠️ API 로직 구현하기

먼저 겹치는 로직을 core.ts에 따로 분리해 파일을 생성합니다.
그리고 각각 기능별로 파일을 나눠 정리합니다.

features/core.ts

const token = localStorage.getItem(ACCESS_TOKEN)

export const axiosInstance = axios.create({
  baseURL: import.meta.env.VITE_BACKEND_URL,
  headers: {
    authorization: token ? `Bearer ${token}` : null,
  },
  params: {
    apiKey: import.meta.env.VITE_API_KEY,
    pair: import.meta.env.VITE_PAIR,
  },
  withCredentials: true,
})
// and others ...

features/user/auth.api.ts

const PATH = "/user"

export const AuthApi = {
	// sign-up
  	// sign-in
  	// sign-out
  	// refresh
}

  async SignIn(data: SignInType) {
    const res = await axiosInstance.post(PATH + "/sign-in", data)
    const userInfo = {
      userId: res.data.userId,
      nickName: res.data.info.nickName,
      profileUrl: res.data.info?.profileUrl,
    }
    localStorage.setItem("userInfo", JSON.stringify(userInfo))
    return res
  },
}
// and others ...

features/post/post.api.ts

const POST_PATH = "/data/post"

export const PostApi = {
	// getPost
  	// postPost
  	// editPost
  	// deletePost
}

  /**
   * @function getPost
   * @method GET
   * @params dataName: string
   * @queries parentId: string, page: number, limit: boolean
   */
  async getPosts(pageParam: number) {
    const res = await axiosInstance.get<TPostsResponse>(POST_PATH, {
      params: {
        page: pageParam,
      },
    })
    console.log("getPosts", res.data)
    return res.data
  },
 // and others ...

---

🌏 전역 상태 관리는 RTK로

본 프로젝트는 전역 상태는 비교적 자주 사용했던 recoil, 비슷한 jotai 등은 뒤로 하고 처음 사용해보는 Redux Toolkit으로 관리하고 있습니다.

현재 인기 있는 전역 상태 관리 라이브러리는 아니지만 이전부터 현재까지(현재는 유지보수를 위해서 주로 사용) 오랜 기간동안 사용되고 있는 라이브러리이기 때문에 저희도 한 번 사용해보기로 했습니다.

기본 세팅 및 사용법은 공식 문서를 참고해 진행했습니다.

| redux의 기본 개념

redux는 애플리케이션의 상태를 하나의 JavaScript 객체로 관리하고, 액션(Action)을 통해 상태의 값을 변경합니다. store는 이 상태를 보유하며, 액션을 디스패치(dispatch)하여 상태를 업데이트합니다.

Redux Toolkit에서 createSlice 함수를 사용하여 리듀서(reducer)를 생성하고, 이를 configureStore 함수를 통해 store로 결합할 수 있습니다. store는 이렇게 생성된 리듀서와 함께 동작하여 전체 애플리케이션의 상태를 효과적으로 관리합니다.

redux-toolkit에 대한 더 자세한 설명과 세팅 과정은 redux-toolkit 게시글을 참고해주세요.

---

✨ OUTCOME

sign in & up

sign-up

sign-in

post CRUD

create-post

read-post : pagination

update-post

delete-post

---

🔗 Links

figma 👉 더 자세한 디자인은 피그마 링크에서 확인하기
vercel 👉 구현된 사이트에서 편하게 확인하기
github 👉 상세한 코드 확인하기

본 사이트는 1920px 기준으로 디자인되었으며 반응형이 적용되어 있지 않습니다.

---

Memoirs 💬

🪨 분석과 설계에 대해 무지했던...

API 분석과 설계를 하기 위해 sequence diagram에 대해 알게 되었습니다.
얘기로만 나눴던 부분들을 표로 그려보면서 이전보다는 api의 흐름에 대해서 잘 파악을 할 수 있었습니다. 다만 같이 진행하는 프로젝트이다 보니 같이 얘기를 하면서 더 많은 것을 공유했어야 하는데 이 부분을 간과했습니다.

와이어프레임을 보면서 "이 기능이 구현 가능할 것인가?"에 대해 얘기를 나눴어야 한다는 피드백을 받고 이 부분을 중점적으로 대화했습니다.

그 외에도 어떤 데이터의 값들이 응답으로 올 것 같은지 thunder client로 찍어봤어야 했습니다. 결과에 맞게 type을 정의하고, 목데이터도 전달되는 데이터의 형태와 동일하게 만들었어야 api 연결 시 기능 구현한 부분을 건드릴 일이 없는데...

response.data의 형태를 임의로 상상해 구현한 것이 화근이었습니다.

🚮 미흡한 준비로 인한 over engineering...

thunder client로 api 호출 시 어떤 형태의 데이터가 오는지 확인을 하지 않은 상태로 목데이터를 만들어 개발 중 로직을 뒤집어 엎는 결과를 초래했습니다.

refactor를 진행한 PR을 살펴보면 정말 많은 파일들에 변화가 있었음을 확인할 수 있습니다.
단순 기능적인 부분의 하드 코딩이 문제가 아니라 API를 정말 잘 분석했다면 이렇게 구현할 수 없을 방법으로 어렵게(?) 개발을 했습니다.

특히 main-page의 post들을 pagination으로 보여주는 파일에서 과도한 엔지니어링이 발생했습니다. BE에서 pagination과 관련된 api를 보내주기 때문에 이를 활용했다면 좀 더 간결하고 쉽게 로직을 짤 수 있었습니다.

---

⛔️ over engineering의 원흉

• 처음 만든 mockData의 형태

{
	id: "",
    title : "",
    content : "",
    Post_img: ["", ""],
    Comments: [{
    	id: "",
      	content: "",
      	User: {
        	id: "",
          	nickName: "",
          	profileImg: "",
        },
      	createdAt: ""
    }],
    createdAt: ""
}

• BE로부터 응답받은 data의 형태

// method : GET   (url : data/post)
{
	data: {
      title: "",
      content: ""
    },
    id: "",
    createdAt: "",
    dataImage: [{"url": ""},{"url": ""}],
    dataUser: {
      data: { nickName: ""},
      userId: "",
      profile_url: ""
    }
  },
}

• TS의 type정의

// before

export type Post = {
  id: string
  title: string
  content: string
  User: User
  Post_img?: string[]
  Comments?: Comment[]
    createdAt: string
}

export type Comment = {
  id: string
  content: string
  User: User
  createdAt: string
}



//after

export type Post = {
  id: string
  data: { title: string; content: string }
  dataUser: { data: { nickName: string }; profile_url: string; userId: string }
  dataImage?: []
  createdAt: string
}

export type Comment = {
  id: string
  data: { content: string }
  dataUser: { data: { nickName: string }; profile_url: string; userId: string }
  createdAt: string
}

export type Pagination = {
  start: number
  end: number
  total: number
  set: number
  current: number
}

데이터의 구조/형태와 type을 BE에서 전달해주는 것과 너무 차이가 생겨 코드의 거의 전부를 수정해야 됐습니다. 위 기본 type으로 변경 후 사용한 type은 아래와 같습니다.

export type TPostsResponse = {
  data: Post[] | []
  pageNation?: Pagination
}

export type TCommentsResponse = {
  data: Comment[]
  pageNation?: Pagination
}

---

🆖 대표적인 사례를 꼽자면...

| getPost

main에서 pagination으로 값을 props로 전달해줄 때의 값에 변화가 있습니다.

MockData로 진행할 때에는 값을 하나 하나 선언해 전달해주었던 반면 API로 진행하게 되면서 별도로 선언한 값들 대신 postList(data)에서 pagination 값에서 바로 전달만 해줄 수 있었습니다.

// develop with MockData
<Pagination 
    listLength={listLength} 
    currentPage={currentPage} 
    perPage={perPage} 
    onPageChange={onPageChange} 
/>
      
// develop with API
<Pagination
    startPage={postList.pageNation?.start}
    endPage={postList.pageNation?.end}
    currentPage={postList.pageNation?.current}
    totalPage={postList.pageNation?.total}
    onPageChange={onPageChange}
/>

아래는 pagination.tsx에서의 변화입니다.

// develop with MockData
const NumberButtons: number[] = Array.from({length: Math.min(pagesPerGroup, totalPage)}, (_, index) => startPage + index).filter(pageNumber => pageNumber <= totalPage);

// develop with API
const NumberButtons: number[] = Array.from({ length: endPage - startPage + 1 }, (_, index) => startPage + index)

pagination 값을 BE에서 따로 전달해주고 있었기 때문에 제가 하나하나 선언할 필요가 없는 값들이었습니다. 중간에 refactor 과정에서 type 변경 후 pageination 값의 사용으로 코드가 훨씬 간결하고 깔끔해진 것을 확인할 수 있었습니다.

| postPost (createPost)

새로운 게시글을 POST할 때 이미지의 전송 위치 때문에 거의 하루를 고군분투했습니다.
formData에서 이미지 배열도 잘못된 위치로 보내고 있어 post된 게시글의 이미지가 화면에 render 되지 않았습니다. mockData의 위치로 보내던 경로를 바꾸지 않아 잘못된 경로로 보내고 있다는 400번대 에러를 맞닥뜨렸던 거였습니다.

결정적으로 문제가 됐던 코드는 아래였습니다.

        <PostDetailContent
          postId={postDetail.data.id}
          title={postDetail.data.data.title}
          content={postDetail.data.data.content}
          postImages={postDetail.data.dataImage} ✔️
          nickName={postDetail.data.dataUser.data.nickName}
          profileImage={postDetail.data.dataUser.profile_url} 
          weekday={postDetail.data.createdAt}
          isEditMode={isEditMode}
          setIsEditMode={setIsEditMode}
        />

props로 postImages를 전달해주는데 잘못된 위치에 전송이 되고 있었기 때문에 post된 게시글의 이미지가 get으로 가져왔을 때 읽히지 않는 이슈가 있었습니다.

그래도 post를 하면서 formData의 유용한 사용법 하나를 새롭게 알게되기도 했습니다.

// upload image : preview
  const onUploadImage = (e: React.ChangeEvent<HTMLInputElement>) => {
    const imageLists = e.target.files as FileList
    let imageUrlLists: string[] = [...showImages]

    for (let i = 0; i < imageLists.length; i++) {
      const currentImageUrl = URL.createObjectURL(imageLists[i])
      imageUrlLists.unshift(currentImageUrl)
    }
    if (imageUrlLists.length > 5) {
      imageUrlLists = imageUrlLists.slice(0, 5)
      alert("한 번에 이미지를 5개 이상 추가하실 수 없습니다.")
    }
    setHasImage(true)
    setShowImages([...imageUrlLists])
  }

// send new post's data to BE 
//before
const { handleCreatePost } = usePostActions()
const currentUser = useAppSelector(state => state.user[0])

const onSubmitCreatePost = async (e: FormEvent<HTMLFormElement>) => {
  e.preventDefault()

   const formData = new FormData()
    formData.append("title", (e.currentTarget.elements.namedItem("title") as HTMLInputElement)?.value || "")
    formData.append("content", (e.currentTarget.elements.namedItem("content") as HTMLInputElement)?.value || "")
    for (let i = 0; i < showImages.length; i++) {
      formData.append("images[]", showImages[i])
    }

  try {
    await handleCreatePost(formData)
  } catch (error) {
    console.error("게시글 등록 중 에러 발생:", error)
  }
}

before

- 직접 폼 데이터에 각 필드를 수동으로 추가
- 이미지를 반복문을 통해 수동으로 폼 데이터에 추가

after

- FormData 생성자에 FormElement를 전달하여 자동으로 폼 데이터를 구성
- 이미지를 자동으로 폼 데이터에 추가

// after
const onSubmitCreatePost = async (e: FormEvent<HTMLFormElement>) => {
  e.preventDefault()
  const formData = new FormData(e.currentTarget)
  try {
    await handleCreatePost(formData)
  } catch (error) {
    alert("게시글을 등록하지 못했습니다! 잠시 후 다시 시도해주세요.")
    console.error("게시글 등록 중 에러 발생:", error)
  }
}

이번 프로젝트를 진행하면서 처음 알게 된 부분으로 FormElement를 전달하면 해당 폼의 모든 field가 FormData에 자동으로 추가할 수 있습니다. form에 있는 모든 입력 field, file 등을 FormData에 포함하여 전송하고자 할 때 유용합니다.
개별적으로 field를 추가하고자 할 때는 append 메서드를 사용하는 것이 유용하겠지만, 모든 field를 한꺼번에 추가할 때에는 위와 같은 방법을 사용할 수 있습니다.

처음에 MMM 프로젝트를 진행할 때 하나 하나 append로 전송했었는데... 나중에 리팩터링할 때 이 부분을 꼭 해주면 좋을 것 같다는 생각이 들었습니다. JavaScript에서 한 번에 보낼 때에는 type만 제거해주면 동일하게 적용 가능합니다.

const onSubmitCreatePost = async (e) => {
  e.preventDefault();
  const formData = new FormData(e.currentTarget);
  try {
    await handleCreatePost(formData);
  } catch (error) {
    alert("게시글을 등록하지 못했습니다! 잠시 후 다시 시도해주세요.");
  }
};

---

API로부터 전달받는 data의 형태를 제대로 확인하지 않음으로 발생하는 문제들을 뼈저리게 느낀 프로젝트였던 것 같습니다. 처음에 mockData와 type들을 BE가 전달해주는 data의 형태와 다르게 구성을 하고 진행하다보니 퍼블리싱 단계에서 디자인과 로직을 개발했는데 개발 단계에서 다시 로직을 수정하고 있는 상황이 벌어졌습니다.

API 분석과 설계를 제대로 했다면 개발 단계에서는 목데이터를 사용했던 부분만 API로 변경해주는 등의 일만 진행하면 돼서 금방 프로젝트를 끝낼 수 있었을텐데...

개발 시간만 따져본다면 정말 시간이 아까운 프로젝트였지만 API 분석과 설계에 대한 중요성을 그 어느때보다 확실히 체감할 수 있었고 앞으로 어떻게 진행해야 할지 확실히 알 수 있었던 계기가 되었습니다.

📆 over engineering으로 인한 ETA delay...

ETA가 계속 뒤로 밀린 데에는 크게 3가지의 이유가 있습니다 :

1. 학습을 병행한 개발 기간
2. 처음 사용해보는 Redux ToolKit
3. API 분석 미흡으로 인한 over engineering

﹢ 설 연휴가 포함된 프로젝트 기간 (3일)

먼저 API 설계와 분석 그리고 auth 로직에 대한 공부가 개발 기간 안에 포함되어 있었습니다.
이전 프로젝트에서 pain-point를 느꼈던 부분들에 대한 공부를 이번 프로젝트를 진행하면서 병행했습니다. sequence-diagram이라는 것도 새롭게 알게 되어 만들어 보고 auth 로직에 대해 자세히 알아보는 기간이 포함되어 있어 프로젝트의 규모에 비해 길게 ETA를 설정했습니다.

post-mobism에서 새롭게 사용하는 라이브러리들이 2개 있었습니다.
Redux Toolkit으로 전역 상태를 관리하는 것과 ReactHookForm의 controller + Zod
Redux Toolkit에 대해 학원을 다니면서 간단히 배운 적은 있지만 제가 직접 프로젝트에 사용해보는 것은 이번이 처음이었습니다. 그리고 TS와의 호환성이 좋지 않아 type과 관련된 에러도 정말 많이 발생했습니다.

API 분석 미흡으로 인한 over engineering으로 인해 개발 기간도 예상보다 2배 정도 길어졌고
설 연휴가 포함되어 있는 기간에는 평소보다 적은 시간을 투자해 조금 길어지기도 했습니다.

💪🏻 전반적으로 아쉬웠던 점과 다짐

" post-mobism" 프로젝트는 API 분석과 설계가 얼마나 중요한 과정인지, 이 부분이 잘못 되었을 때 개발 기간에 어떠한 영향을 미치는지 뼈저리게 느꼈습니다. 시간을 과하게 투자한 만큼 sequence diagram도 그려보면서 동료 개발자와 어떤 얘기들을 나눠야 하는지 알 수 있는 계기가 되었습니다. 다음 프로젝트부터는 처음부터 더욱 확실히 response.data의 형태를 파악해 퍼블리싱에서 개발한 코드를 개발 단계에서 과도하게 변경할 일이 없게 하고 싶습니다...!

이 외에도 정말 많은 시간을 갈아 넣으면서 많은 기능들을 이전보다 잘 이용할 수 있게 되었습니다.
thunder client와 개발자 도구의 network, application의 localStorage와 cookie 탭을 통해 response를 확인하는 일들이 특히 그런 것 같습니다. 첫 프로젝트에서는 대부분 console 창으로 확인을 했거든요...👀
왜 안 되는지 확인하기 위해 network, application을 수시로 들어갔더니 이제야 비로소 개발자 도구에 익숙해졌습니다. 🥲