[사이드프로젝트] 그저 그런 REST API로 괜찮은가? - 진정한 REST API 구현해보기 - 프로젝트 종료 및 차후 개선 사항

프로젝트 종료

강의를 수강하면서 나오는 내용을 모두 구현했다.

강의에서의 핵심 구현 내용은 아래와 같다.

• self descriptive와 HATEOAS가 가능한 REST API를 구현한다.
• Spring Security & Oauth2가 적용된 안전한 REST API를 구현한다.
• TDD 기반의 개발 방식에 익숙해진다.

Self descriptive & HATEOAS 만족

이번 프로젝트를 하면서 Self descriptive와 HATEOAS에 대한 개념을 잡을 수 있었고 POSTMAN 테스트를 통해 링크가 주어진다면 정말 쉽게 Client를 구현할 수 있겠다란 생각을 했다.

Spring Security & Oauth2 적용

Spring Security는 공부하면서 여러번 사용했기 때문에 익숙했다. 반면 Oauth2의 경우에는 Front 작업할 때, Google이나 Naver에서 제공하는 Oauth2 로그인 기능을 사용한 게 전부다. 이번 프로젝트에서 실제로 Authlization 서버(password 방식이지만)를 직접 구현해봄으로써 좀 더 Oauth2에 대해 익숙해질 수 있는 기회였다.

TDD 기반의 개발 방식

학과에서 진행한 학과 게시판 리팩토링에 참여하면서 TDD를 경험한 적이 있다. 그 당시에는 기능을 먼저 구현하고 테스트 코드를 작성했다. 하지만 이번 프로젝트에서는 테스트 코드를 작성하고 실제 기능을 구현했다.(물론 중간에 순서가 바뀌긴 했지만 말이다.) 이를 통해 코드가 아주 조금 수정되더라도 사이드 이펙트가 엄청나게 발생한다는 것을 알 수 있었고 테스트 코드 작성의 중요성을 알 수 있었다.

차후 개선 사항

1. Oauth2 -> JWT 기반

현재 Spring Security에서는 Oauth2에 관한 내용을 Migration 했다. 따라서 지금 프로젝트는 legacy 코드에 의존하고 있다. 이를 JWT 기반의 인증 방식으로 바꿔야 한다.

2. 로드밸런싱을 통한 성능 측정

차후 EC2에 서버를 배포한 후, 로드밸런싱을 통해 서버의 성능을 측정해보고자 한다. new Relic도 함께 사용해서 병목 현상이 발생하는 지, Throughput과 latency가 어느 정도인 지 측정해보고자 한다.

그렇다면 프로젝트 개선은 언제?

지금 진행하고 있는 아마존 크롤링 프로젝트와 Kafka 스터디 프로젝트를 마무리하고 여유롭게 해보려고 한다!!