JIGGAG

2월 한달동안 로그

2020년 3월 1일

2/23 - 2/29

library

  • 오픈소스 라이브러리 커스텀
  • 재설치하면 사라지는 커스텀 -> 해당 라이브러리를 프로젝트로 가져오기
  • package.json에 버전 대신 해당 라이브러리 경로 지정

DNS

  • 서버를 내렸다 올릴때면 ip가 바뀌길래 elastic ip로 고정시켜서 사용했다
  • 우연하게 질문타이밍 EC2마다 각각 elastic ip 연결해줘요?
  • 예상외 답변이 돌아왔다 elastic ip로 public ip를 고정하는게 좋은게 아니다. DNS를 고정하면 되지
  • 생각하지 못했다 해봐야지
  • ELB를 두라고??

Django

  • Python: python 2.x
  • Python3: python 3.x
  • python2는 지원 종료
  • rest framework

MSA = GraphQL

  • MSA를 하고 있다 -> 1였던 API가 2가 되고 있다
  • A와 B는 필요 의존적이다 -> 그럼 B를 호출하기 위해 A가 필수 선행된다면 서버단에서 해결하면 되지 않을까
  • 의존성이 생기면 MSA를 한 의미가 사라진다
  • 각각의 API를 조합해서 사용 -> 이거 GraphQL?
  • GraphQL에는 JOIN이 없다 Resolver로 조합해서 사용한다 -> MSA와 GraphQL이 닮았다
  • 기존 프로젝트를 MSA/GraphQL로 바꾸는건 너무 큰 일이다 -> 신규 프로젝트에서는 의존성을 최소화한다면 세상 간편!?

2/16 - 2/22

pm2

  • 프로세스 관리를 위해 forever 사용했으나 pm2로 변경
  • 간단하지만 미루다 이제야 -> 진작 바꿀걸
  • 내가 쓰는건 start, monit, log 밖에 없지만 직접 로그 파일을 찾아보지 않아도 확인할 수 있다는게 가장 큰 편리함
  • pm2로 nodejs 무중단 서비스
  • old_app 종료 -> 사용자 요청 -> fail -> new_app 실행: 배포하는 사이에 사용자 요청이 들어온 경우 응답 fail을 막고자 무중단 배포
  • new_app 실행 -> 나 준비됬어! 신호 -> old_app 종료: 요청을 받을 준비가 되면 신호를 보내서 기존의 서버를 종료하는 방식
  • 서버가 실행하자마자 요청을 받을 준비가 되는게 아니기 때문에 요청받을 준비가 되면 기존 서버를 종료하는 것으로 무중단 서비스를 운영할 수 있도록한다

프론트엔드 테스트 코드가 필요한가

  • 필요할까
    • 내가 작성한 코드의 안정성/자신감을 위해 테스트 필요
  • 기능적 vs 시각적 
    • 백엔드: input, output 모두 데이터
프론트엔드: input - 이벤트, output - 시각화
    • 기존의 기능적 테스트를 유지 -> 테스트 코드에서 시각적 요소 의존성을 제거하여 기능을 위한 클래스명 또는 테스트를 위한 속성값 사용
    • 시각적 테스트를 위한 html, snapshot, 스크린샷 비교(ex.percy) -> 테스트 실행속도 느림, 의도가 명확하지 않아 문서화되지 않으므로 기능적 케이스 분리하고 시각적인 결과만을 확인
  • 단위 vs 통합
    • 테스트는 작성, 유지보수, 실행 모두 비용이다
    • 복잡한 로직이 없는 단위 테스트는 제거하고 통합으로 포함시키며 로직이 복잡한 경우에만 단위테스트 실행
    • 컴포넌트 단위로 통합 테스트 실행하여 커버리지 향상
  • 작성한 테스트가 신뢰할 수 있는지
  • 결국 테스트는 비용이고 시각적/기능적 테스트의 분리 필요
  • storybook: 컴포넌트를 여러 상황별로 만들어두고 시각적 테스트
  • cypress: 브라우저 내부에서 실행되며 TDD 가능
  • NHN 실용적인 프론트엔드 테스트 전략

WEB Dashboard

  • 개인 대시보드 프로젝트
  • 아파치에 포트를 추가하여 연결 
    Listen ${PORT}
<VirtualHost :{PORT}>
  DocumentRoot ${PROJECT_ROOT}
  <Directory ${PROJECT_ROOT}>
    AllowOverride None
    Require all granted
  </Directory>
</VirtualHost>
  • 타임존 추가: moment-timezone

Jenkins

  • 드디어 서버에 설치
  • 디폴트 포트 8080을 9090으로 변경
  • systemctl start jenkins.service로 실행
  • 그러나 Starting Jenkins bash: /usr/bin/java: No such file or directory 라며 젠킨스 실행이 안됨
  • jdk를 설치하고 /usr/bin/java안에 넣었는데도 같은 오류 발생 -> which java했더니 /usr/bin/java/bin/java라는 괴이한 경로를 반환
  • vi /etc/init.d/jenkins -> jdk 경로 추가 후 젠킨스 재실행
  • 여전히 실행이 되지 않고 있다...
  • Jenkins requires Java versions [8, 11] but you are running with Java 13 from /usr/bin/java -> 젠킨스에서는 jdk 8-11을 지원하는데 내가 설치한건 13이다
  • Jdk 11을 다시 설치하고 재실행 -> 젠킨스가 드디어 떴다! 그러나 새로운 에러에 도착했다 
    AWT is not properly configured on this server. Perhaps you need to run your container with "-Djava.awt.headless=true"? See also: https://jenkins.io/redirect/troubleshooting/java.awt.headless
  • 대응 1: tomcat 설치 -> cpu 폭등 -> 서버 굿바이
  • 대응 2: 서버를 다시 띄우고 jenkins start -> cpu 폭등 -> 한참을 기다리니 tomcat:8080 대신 jenkins:9090이 연결됨
  • 그러나 젠킨스만 돌리면 CPU 폭발 인스턴스 증설 필요 -> 젠킨스를 포기했다

2/9 - 2/15

  • 하고 싶다, 해볼까, 할 수 있다 + 그럴 수 있지, 해야만 한다, 해내야 한다
  • 좋게 말하면 이전에는 자유로웠다면 이제는 책임을 갖게 되었다
  • 내 의지대로 하고 싶은것을 하며 능동적이였다면 이제는 피동적으로 해야만 하는 것들이 늘어가고 있다.
  • 장단점이 확실하게 있지만 도움이 될 부분들을 이번 프로젝트를 통해 얻을 수 있었다

2/2 - 2/8

OMF

  • UI 개선
  • 데이터 구조 변경으로 마이그레이션 필요
  • 추후 카테고리 내용 분리하여 저장

GraphQL

  • REST API에는 너무 많은 데이터가 내려온다 -> 필요한 데이터만 보내면 되는거 아닐까? -> 갑자기 다른 데이터도 보여줘야 한다 -> 백엔드 + 프론트 모두 다함께 수정 -> 개발 소요시간 증가
  • 수정사항마다 늘어나는 REST API를 줄이고자 GraphQL 도입해볼까
  • REST API로 받아온 데이터를 GraphQL로 다듬어서 사용
  • GraphQL은 클라이언트(인터넷)에서 사용할 수 있도록 개발 + Query이므로 어떤 프로그래밍언어에서도 동일한 방식으로 사용
  • CRUD를 위한 Query, Mutation 타입과 소켓과 비슷한 Subscription 타입으로 구성
  • Join이 될까? 관계형 DB에서 조인은 꼭 있어야하는데 GraphQL에서는 조인을 어떻게 하는 걸까
  • 쿼리에 Join은 따로 없으며 CRUD 쿼리를 만들고 조인이 필요한 쿼리에 리졸버를 생성하여 호출한다
  • GraphQL에서도 REST API에서도 구현 가능 할 것으로 보여진다
  • 그렇다면 더 나은 방법일까?
©Jiggag, Built with Gatsby