Log 8/25

개발(공부) 자국·2021년 8월 25일
0

Dev log

1

어제 배포버전에서 Sequelize 문제가 작동되지 않는 문제를 가지고 next.js의 공식문서를 찾아보고 sequelize 공식문서도 찾아봤다. 그리고 aws amplify도 찾아봤지만 문제를 해결 할 수 있을 만한 단서를 찾지 못했다. vercel 배포를 생각해야 하는 건지도 생각을 해야 했다. 하지만 vercel로 배포하기 전에 왜 이 문제가 발생한 것인지 알아야 vercel에서도 문제 없이 작동할 것 같았다. 그러던 중 팀원 중에 한 분이 원인을 찾고 해결 방안을 가지고 오셨다. 문제는 Database를 Sequelize가 설정되어 있는 lib/config/config.js에 명시적으로 mysql2를 넣지 않은 것이 이유였다.

    dialectModule: require('mysql2')

이 부분을 넣고서는 sequelize가 작동하는 모습을 볼 수 있었다. 아래의 링크를 보고 해결할 수 있었다고 했다. 스택오버플로우에서 찾는 것이 아직 쉽지 않았다. 어려워서 적극적으로 찾지 않았다. 그런데 이 부분을 찾아서 해결한 모습을 보고 많이 반성했다. 이제는 스택오버플러우에서 더 적극적으로 찾아서 여기서도 잘 찾는 노하우를 빨리 익히는 것도 중요한 것을 알았다.
Stack overflow 참고 링크1

2

배포가 성공하고 나서 배포환경에서의 login이 제대로 작동하지 않는 모습을 보였다. 우선 sequelize는 정상 작동하는 것을 ranking 정보가 정상적으로 불려오는 것으로 확인을 했기 때문에 다른 문제가 발생한 것임을 알 수 있었다. 그 문제를 찾아보니 503 Error로

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
</BODY></HTML>

<BR clear="all">
<HR noshade size="1px">
<ADDRESS>
Generated by cloudfront (CloudFront)
</ADDRESS>
</BODY></HTML>

이런 에러가 응답에 담겨있었다. 막 배포가 해결되었는데 login을 최근에 연결을 내가 했었다. dev에서는 작동하는 것을 확인을 했기 때문에 더 혼란스러웠다. 그래서 위의 에러코드들을 방금 해결될 때 좋았던 스택오버플로우를 이요해서 찾아봤다. 이 문제에 대한 질문이 올라왔다. 500번대가 아닌 400번 300번대의 문제들이 많이 보였고 500번 문제는 몇개 없었다.
Stack overflow 참고 링크2
이렇게 찾아보면 해결이 될 것 같았는데 해결책을 보니 전부다 다른 종류의 해결책을 이야기 하고 있었다. ssl 암호화를 설정해야 한다는 부분, CNAME 연결 부분의 문제, HTTPS의 리디렉션 문제 등등 여러 다른 해결책을 말하고 있었다. 어느 부분이 문제인지 알 수가 없었다. 그러던 중 아까와는 다른 팀원분이 해결을 하셨는데 이 부분은 api 설정 문제가 원인이었다. 그래도 해결되어 login 기능이 정상작동을 하는 것을 확인했다.

3

배포 문제를 찾을 때 대안으로 graph-ql도 찾아봤다. graph-ql은 알아보기전에는 Database의 한 종류인줄 알았다. 그래서 sequelize 가 문제라면 orm이 문제이니 다른 부분을 찾아봐야 할까 생각한 것이다. graph-ql이 MongoDB와 같은 것인 줄 알았는데 API의 작성 방법을 나타내는 것으로 Rest API와는 다른 방식의 API를 구성하는 방법이었다. Rest API는 endpoint인 URL과 Method로 요청들을 구분해서 처리하는 방식이으로 GET, POST, PUT, PATCH, DELETE 등으로 CRUD를 구현했다. graph-ql은 query로 GET의 역할을 하고 나머지는 mutation이라는 변화한다는 의미로 모든 CUD를 구현하는 것을 볼 수 있었다. 그리고 요소들을 필요한 자료만 선별해서 받을 수 있는 장점을 가진 방식이었다. 찾아보면서 정말 많은 자료를 가지고 있고 필요한 자료만 선별해서 가져오는 작업이 많은 프로젝트에는 정말 좋은 방법이 되겠다는 생각을 했지만 우리 프로젝트에는 어울리지 않는 것 같았다. graph-ql도 사용해볼 수 있었으면 좋겠다. 그전에 rest api를 잘 하고나면 해봐야겠다.

느낀점

오늘은 내가 원하는 정보를 찾는데 익숙하지 않은 점들이 많이 드러났고 그 부분이 힘들기도 했다. 무엇을 모르는지 모르는 것 같은 막막한 기분이 들기도했고 내가 무엇을 한 것인지 허무할 때도 있었다. 개발자는 이런 경험을 삽질을 한다고 하는데 삽질도 의미있는 삽질과 의미없는 삽질이 있는 것처럼 느껴졌다. 좀 더 의미있는 삽질이 되려면 내가 한 삽질을 기록해야 되겠다고 생각했다. 정말 아무것도 못하는 사람이 된 것 같아서 심적으로도 어려움이 있지만 그래도 움직여야지 성장하기 때문에 보는 것을 포기하지 않을 것이다.

profile
기록을 중요하게 생각하는 사람입니다. 학습한 내용을 정리한 것이라 잘못된 정보가 있을 수 있습니다. 잘못된 정보는 언제든 말씀해 주시기 바랍니다.

0개의 댓글