프로젝트 후기 (feat. 코로나 캐치)

wlsdud2194·2020년 4월 4일
4
post-thumbnail

2020년을 맞이 하여 마지막 고등학교 생활을 즐겨야 하는 상황에서 코로나라는 바이러스 때문에 개학을 하지 못하는 상황이 발생하였습니다. 개학이 3주 이상 미루어지고 개학도 온라인 개학으로 이루어진다고 합니다.

개학이 연기되고 학교에서 한 과제가 내려졌는 데, 2주 내로 프로젝트를 진행하여 제출해야하는 과제였습니다. 마침 기존에 하던 토이 프로젝트가 끝나가고 방학동안 하고 싶었지만 못했던 기술을 써보기에 좋은 기회라고 생각했습니다.

어떤 프로젝트가 좋을까

어떤 프로젝트를 할지 고민하던 중, 개학 연기의 원인 코로나19에 관련된 주제로 프로젝트를 하면 재미있을 것 같아 코로나19에 관한 정보를 제공하는 사이트를 만들기로 하였습니다.

코로나 관련 데이터 수집을 위해 구글링으로 찾아보는 도중 질병관리본부에서 공식 제공하는 사이트인 "코로나바이러스감염증-19" 라는 사이트와 개발자 분들이 개인적으로 만드신 "코로나나우", "코로나보드" 등의 서비스가 있었습니다.

국외, 국내 확진자 데이터에 대한 공식 Open Api는 제공하지 않고 있기 때문에, 공식 제공하는 사이트를 파싱을 하는 방법을 선택하였고 그 외 추가적인 기능들은 open api를 이용하기로 하였습니다.

이번 프로젝트에서는 위에서 말한 사이트 + 웹 디자인 사이트 등을 일부 디자인과 아이디어를 레퍼런스하여 진행하였습니다.


Typescript

방학동안 했던 토이 프로젝트에서도 Typescript를 사용했는 데, 익숙해지기 위해서 한 번 더 사용하였습니다. 사실 앞으로도 별일 없으면 Typescript를 사용할 것 같습니다.

기존에 Javascript로 개발할 땐 몰랐지만, Typescript를 사용했을 때, IDE의 다양한 도구의 지원받을 수 있고, 타이핑 제공을 통해 디버깅하는 것과 구조적으로 설계하는 부분에서 많은 이점을 얻을 수 있는 것 같습니다.

이번 프로젝트에서는 클라이언트, 서버 모두 Typescript로 진행하였습니다.


REST API vs GraphQL

웹 상에서 클라이언트와 서버가 통신할 때는 기본적으로 클라이언트가 요청하면 서버는 응답하는 형식으로 통신이 끝이 납니다. 이 과정 속에서 REST API와 GraphQL이 나뉩니다. 잠깐 두 개의 특성을 이야기해보자면,

REST API의 가장 큰 장점은 http의 특징을 이용하여 통신 과정이 간단하다는 것입니다. 하지만, 서버에서 보내주는 데이터의 크기를 고정해서 받기 때문에, 클라이언트에서 특정 컬럼을 사용하지 않아도 곧지곧대로 받아야 합니다. 이 과정에서 불필요한 "오버해드"가 발생할 수 있습니다.

GraphQL의 경우에는 클라이언트에서 보내는 Query을 이용하여 필요한 데이터 컬럼을 선택적으로 불러와 응답의 크기를 줄이고, 하나의 Query에 필요한 요청을 모두 넣어서 요청할 수 있기 때문에, 요청횟수를 줄일 수 있습니다. 하지만, 요청 주소가 /graphql 하나로 통일되어 Http에서 제공하는 캐싱 전략을 이용할 수 없기 때문에 캐싱을 위한 다른 방법을 필요로 합니다. 또한 Query 요청을 통해 발생할 수 있는 1+N 문제 또한 해결해주어야 합니다.

(GraphQL 1+N 문제는 다음 포스터에서 다뤄보겠습니다.)

이번 프로젝트에서는 간단하게 데이터를 읽어오는(GET 요청)이 많다고 생각하였고,
한번 사용해보고 싶었던 GraphQL을 사용하였습니다.

1차 개발 후, GraphQL에 대한 느낌

이번 프로젝트에서 처음으로 GraphQL을 사용하여 클라이언트와 서버 간의 통신을 하였는데, 개발을 하면서 느낀 장점과 단점이 명확했습니다.

장점

  • 필요한 요청을 하나의 Query에 모두 담아서 요청하니 로딩 제어 및 상태(State) 관리가 더욱 간편했다.
  • Apollo Client 엔진를 사용하여 캐싱을 하였기 때문에, 빠른 응답처리가 가능했다.
  • 클라이언트에서 사용하는 key 명으로 변경해야하는 과정을 요청하는 과정에서 처리할 수 있어서 더욱 간결하게 코드를 작성할 수 있었다.
// 예시
query data {
  reports {
    ...
    value: content
    createAt: create_at
    ...
  }
}

단점(아닌 단점)

  • 이번 프로젝트에서는 사실상 거의 모든 컬럼을 사용해서 그래프큐엘의 장점을 최대한으로 사용하지 못한 느낌이다.
  • 서버와 클라이언트가 각각의 resolver에 대한 응답에 대한 타입을 미리 선언해놔야 했기 때문에 이 과정에서 조금 번거롭다고 느껴졌다. (이건 아직 익숙하지 않아서 그런거 일지도 모르겠습니다)

배포 프로세스

클라이언트 (Web)

클라이언트 배포의 경우, AWS S3와 Cloudfront 서비스를 이용하여 배포하기 때문에, package.json에 아래와 같이 AWS CI 배포 명령어를 미리 선언하여 배포를 실행할 수 있도록 하였습니다.

다음에 웹 배포를 하게된다면, 아래 스크립트를 CI/CD 툴에서 작동할 수 있도록 해봐야겠습니다.

// package.json
{
    // React 앱을 빌드해준다
    "build": "react-scripts build",
  
    // 빌드된 앱을 AWS S3에 업로드 한다
    "deploy-s3": "aws s3 sync ./build s3://corona-catch-web --profile=s3-user",
  
    // 이전에 Cloudfront에서 캐싱된 정적파일들을 다시 받으라는 명령어를 통해 실제 클라이언트에 변경이 적용될 수 있도록 해준다.
    "invalidate": "aws cloudfront create-invalidation --profile=s3-user --distribution-id *** --paths / /index.html /service-worker.js /manifest.json /favicon.ico",
  
    // 위 명령어를 순차적으로 실행
    "prod": "yarn build && yarn deploy-s3 && yarn invalidate"
}

서버 호스팅

서버 호스팅을 위해 AWS 서비스 중, 비용이 적고 초기 구축이 간편한 AWS Lightsail을 사용하여 호스팅을 구축한 후, DockerNginx를 이용하여 웹 서버에 접근할 수 있도록 하였습니다.

또한 Cloudfront에서는 https가 아닌 호스트에 요청할 수 없다고 하여 Cloudflare에 무료 https 서비스를 이용하여 서버에 https를 적용하였습니다.

후기

프로젝트의 기능을 구현하는 데에 비교적 금방하였지만, 배포 프로세스를 구축하는데 시간을 꽤 사용한 것 같습니다. 그 중 CDN이나 DNS를 설정하는 것이 오래 걸렸기 때문에, 실제 배포를 할 때 필요한 네트워크 관련 지식을 습득해봐야겠습니다. 또한 다음 프로젝트에서 서버를 배포할 땐, 무중단 배포 방식을 적용해보려고 합니다.

이상 코로나 캐치 프로젝트 후기였습니다.

profile
💻 개발하고 공유하는 것을 좋아하는 고등학생 개발자입니다

0개의 댓글