라즈베리파이에서 제일 힘들었던 것 두개 중 하나가 DB 설치였다.리눅스 명령어도 익숙하지 않은데다, 설치가 안되면 프로젝트 후반부에 DB를 교체해야 한다는 심적 부담감이 컸다.MySQL 5.7을 설치하기가 정말 어려웠다. MySQL 8.x 버전으로 업그레이드 하자니 인
이번 프로젝트에서 가장 어려웠고, 가장 많이 배운 것이다.여태까지는 아키텍쳐의 중요성을 몰랐다. 웹 개발할 때는 서버, 클라이언트, 디비를 두고 AWS에 배포하여 브라우저로 접근하는 것이 숨쉬듯 당연했다.그런데 배경지식이 없는 IoT 프로젝트를 하려니 막막하게 다가왔다
API를 개발할 때에 uri, request data, response data 등을 사전에 협의해야 한다. 우리는 기획 단계에서 API 명세서를 작성했다.맡은 API를 개발하면 로컬에서 테스트를 진행했다. 그런데 다른 사람이 개발한 API를 테스트하려면 어떻게 해야할
SOP의 필요성OriginSOPCORSOrigin = PROTOCOL + HOST + PORTSOP란, 브라우저는 다른 도메인의 리소스를 차단하겠다는 정책이다.http는 stateless한 바보니까, 요청이 들어오면 죄다 처리한다. 그래서 (www.mybank.com)
코드값의 대표적인 예시는 jwt의 만료시간, error code와 메시지 등이 있다. 규모가 작을 때는 static 변수에 담거나, enum 값으로 관리했었다.1) JwtProperties 클래스를 만들고 static 변수에 담았다2) 관계가 있는 경우에는, enum
운영 정책이라는 건 유행이 있다. 예전에는 통합이 유행이었고, 요즘에는 잘게 쪼개는 게 유행이다. 잘게 쪼갰을 때 장점은 프로그램 수정 시 영향도를 분리하고, 발빠르게 수정이 가능하다는 점이다. 단점은 변경점이 많고, 관리 포인트가 늘어난다. 그래서 쪼갤 때 어디까지
was로 들어온 request는 톰캣 큐에 쌓인다. 그런데 톰캣 queue의 캐파보다 더 많은 request가 들어온다면? was가 터질 수 있다. 이러한 문제를 방지하기 위해 was와 request queue를 분리할 필요가 있다. 더하여, 인터페이스에 대한 요건이
MSA 환경에서의 운영 IT 서비스가 커지면 > 서버가 쪼개지고 > 조직이 생겨난다. 조직 간에는 알력 다툼이 있고, 조직원은 웬만하면 일하기 싫어한다. 이러한 조직 + MSA 환경에서 에러가 터진다면 어떨까? 웬만하면 에러를 해결하려 들지 않고 책임을 떠넘기려 한다