세상에 나쁜 코드는 없다

API 설계내가 맡은 부분은 프로젝트의 메인 로직 부분인 팀과 관련된 부분이었다. 팀에서 요구되는 기능은 아래와 같다.팀은 2가지 분류로 나뉜다. (공모전 팀, 스터디 팀)각 팀에 대한 정보를 조회할 수 있어야 한다.공모전 팀은 특정 공모전에 해당하는 팀들을 모아 볼 수 있어야 한다.스터디 팀은 스터디의 세부 분야 (어학, 자격증, 프로그래밍 등)에 따라 모아볼 수 있어야 한다.팀 조회시 최신순과 마감순으로 정렬하여 확인할 수 있어야 한다.팀을 생성 및 수정할 수 있어야 한다.사용자는 원하는 팀에 신청할 수 있다.팀의 개설자는 신청한 팀원의 정보를 확인하고 팀원으로 승인하거나 거부할 수 있다.사용자는 마이페이지에서 자신이 참여하고 있는 팀의 정보를 확인할 수 있다. 위 기능을 수행하기 위해 구성된 API..

ScouterScouter는 APM(Application Performance Management) 소프트웨어로 서버의 성능을 모니터링 하기위한 도구이다.오픈소스여서 무료로 사용할 수 있다.ConceptScouter Server (Collector)모니터링할 데이터를 수집하는 서버이며, 데이터는 자체 제작된 내부 DB에 저장된다.Scouter AgentScouter Agent에는 Host Agent와 Java Agent가 있다.Host Agent : CPU, MEMORY, DISK 의 데이터를 전달한다.Java Agent : Heaps, TPS, Response time, Service Profile 등의 데이터를 전달한다.Scouter Client스카우터 서버에 접속하여 수집된 정보를 확인할 수 있는 ..

application.yml 파일 분리하기Spring Boot에서는 application-{profile}.yml 와같은 포맷으로 application.yml 파일을 분리하여 빌드 시 특정 profile에 대한 파일이 적용되게 할 수 있다.각각의 profile에는 별도의 포트를 지정해 주어서 추후에 한 서버에서 dev와 prod 프로그램이 동시에 실행될 수 있게 했다.dev 환경에서는 더미데이터가 존재하는 개발용 DB와 연결되게 하였고, prod에는 실제 운영할때 사용할 DB에 연결하게 하였다.각각의 yml 파일에는 env라는 변수를 놓고 local, dev, prod라는 값을 주어 프로그램 내에서 환경에 대한 값을 사용할 수 있게 하였다. 이후 build.gradle 에 다음과 같은 코드를 통해 gra..

요구사항 다음 4개의 도메인에 ssl 인증을 통한 https 접속이 될 수 있게 해야 한다.www.dev.dongaribang.shopdev.dongaribang.shopwww.prod.dongaribang.shopprod.dongaribang.shop만약 http로 접속이 오는 경우, https 로 리다이렉트 해야 한다.해결리버스 프록시 서버 세팅nginx 설정 파일을 작성해 주었다. certbot은 지금 생성한 설정 파일들 중 알맞은 domain name 을 가진 파일을 찾아 https 에 대한 설정을 추가해준다.nginx 설정 파일이 들어갈 위치는 /etc/nginx/conf.d/ 이다.sudo vi /etc/nginx/dev.dongaribang.shop ## 이후 아래 작성 server { li..

0.인트로0.1 소개 이 글은 웹 프론트엔드 개발자에게 “내가 작성한 코드가 어떻게 서버의 코드와 상호작용하여 사용자에게 전달되는가”를 설명하려는 목적으로 작성되었습니다. 글은 웹 프론트엔드 개발 입문자와, 프론트엔드 지식을 어느정도 갖고 있으면서 백엔드에 입문하고자 하시는 분들을 대상으로 작성되었습니다. 입문자를 기준으로 작성하였으므로 아는 분야의 지식이 나온다면 넘어가면서 읽으셔도 무방합니다.글의 내용이 스프링부트에 의존하고 있습니다. 그럼에도 불구하고 최대한 일반적인 내용을 담을 수 있도록 해보겠습니다.잘못된 내용이 있을 수 있습니다.추가로, 거의 동일한 주제로 올라온 유튜브 영상이 있으니 참고하시면 도움이 될 것 같습니다.웹 프론트엔드 개발자가 알아야할 최소한의 백엔드 지식과 코드 (API)htt..

에러코드가 필요한 이유개발 단계에서 서버에 요청을 보냈을 때 서버에서 “Oops, something went wrong” 따위의 오류 메시지를 반환한다면 Client의 문제인지 Server의 문제인지 알 기 어렵다. 따라서 Server 는 Client의 요청에 대해 구체적인 에러 메시지를 전달해 줄 필요가 있다.장점HTTP Status code 만으로 Response에 대한 충분한 설명을 할 수 없다.더욱 구체적인 에러 내용을 정의하여 소통할 수 있다.오류 메시지는 API 사용 방법에 대한 가시성을 제공하는 핵심 도구가 된다.클라이언트단에서 에러 코드에 따라 다른 처리 로직을 개발할 수 있다.HTTP status code만으로 모든 예외처리를 할 수 없다.따라서 status code와 응답의 messag..