<div id="readability-page-1" class="page"><div><h3 id="1-러닝커브만-넘어서면-단순해-진다-feat-첫-웹-api-개발-경험">1. 러닝커브만 넘어서면 단순해 진다 (feat. 첫 웹 API 개발 경험)</h3>
<p>파일 다운로드 클라이언트의 REST API를 구현해 코어 파일 클라이언트 모듈과 연결했다. 그리고 RestAssured를 사용해 통합 테스트를 작성해 보았다. 러닝커브만 넘어서니 개발이 정말 쉽고, 테스트도 간편했다. 나의 첫첫첫 경험들.</p>
<h3 id="2-진짜-부하테스트-시작-with-locust">2. 진짜 부하테스트 시작 (with Locust)</h3>
<p>그리고 Locust를 사용해 부하 테스트를 해보았다. 가볍게 노트북에서 루프백 통신(서버와 클라이언트 그리고 Locust까지 같은 컴퓨터에 띄우고)으로 16개의 동시 요청을 모의해 보았다. 요청 하나 당 5MB 크기의 파일이 루프백 인터페이스로 다운로드 된다. 결과는 실제로는 초 당 약 5개의 동시 요청이 처리되고, 다운로드 처리 시간(응답 시간)은 평균 30ms, 최소 20ms, 최대 100ms 정도 된다. JVM이 실행되고 처음 몇개의 요청은 warm-up 과정에 의해 시간이 200ms 정도로 오래걸려서 데이터에서 제외했다.</p>
<p><img src="https://velog.velcdn.com/images/joosing/post/1da08be1-a503-427c-8d83-12167f758e45/image.png"></p>
<h3 id="3-fig-클래스">3. Fig 클래스</h3>
<p>스프링 캠프에서 접한 Strangler 패턴을 코드를 개선하는데 사용해 본다. 레거시 클래스를 바꾸기 위해 Fig 클래스를 추가한다. 레거시 클래스를 다 삭제하고 다시 개발하기 시작하면 리스크가 크다. Fig 클래스가 검증되면 레거시를 삭제한다. 간단하지만 건강한 루틴 같다.</p>
<h3 id="4-rest-vs-graphql">4. REST vs GraphQL</h3>
<p>서비스 Setting 정보 제공을 위한 클래스를 서비스 곳곳에서 참조한다. 불필요하게 모든 부분을 열고 있는 것 같아서 몇 개의 그룹으로 인터페이스를 나누어 본다. 그래도 사실 사용자 클래스가 꼭 사용하는 정보만 제공하는 것은 아니다. Setting을 각 사용자 클래스가 사용하는 항목만 뽑아서 전달하기 위한 별도의 DTO 클래스를 만들까 생각하다가 과하다는 생각이 든다. 문득 진짜 필요한 것만 쿼리해서 쓸 수 있는 방법을 제공한다는 GraphQL 컨셉이 떠오르고 내가 하려던게 REST API 컨셉 같다는 생각이 든다.</p></div></div>

Joo's Work

JooSing

1. 러닝커브만 넘어서면 단순해 진다 (feat. 첫 웹 API 개발 경험)
파일 다운로드 클라이언트의 REST API를 구현해 코어 파일 클라이언트 모듈과 연결했다. 그리고 RestAssured를 사용해 통합 테스트를 작성해 보았다. 러닝커브만 넘어서니 개발이 정말 쉽고, 테스트도 간편했다. 나의 첫첫첫 경험들.
2. 진짜 부하테스트 시작 (with Locust)
그리고 Locust를 사용해 부하 테스트를 해보았다. 가볍게 노트북에서 루프백 통신(서버와 클라이언트 그리고 Locust까지 같은 컴퓨터에 띄우고)으로 16개의 동시 요청을 모의해 보았다. 요청 하나 당 5MB 크기의 파일이 루프백 인터페이스로 다운로드 된다. 결과는 실제로는 초 당 약 5개의 동시 요청이 처리되고, 다운로드 처리 시간(응답 시간)은 평균 30ms, 최소 20ms, 최대 100ms 정도 된다. JVM이 실행되고 처음 몇개의 요청은 warm-up 과정에 의해 시간이 200ms 정도로 오래걸려서 데이터에서 제외했다.
3. Fig 클래스
스프링 캠프에서 접한 Strangler 패턴을 코드를 개선하는데 사용해 본다. 레거시 클래스를 바꾸기 위해 Fig 클래스를 추가한다. 레거시 클래스를 다 삭제하고 다시 개발하기 시작하면 리스크가 크다. Fig 클래스가 검증되면 레거시를 삭제한다. 간단하지만 건강한 루틴 같다.
4. REST vs GraphQL
서비스 Setting 정보 제공을 위한 클래스를 서비스 곳곳에서 참조한다. 불필요하게 모든 부분을 열고 있는 것 같아서 몇 개의 그룹으로 인터페이스를 나누어 본다. 그래도 사실 사용자 클래스가 꼭 사용하는 정보만 제공하는 것은 아니다. Setting을 각 사용자 클래스가 사용하는 항목만 뽑아서 전달하기 위한 별도의 DTO 클래스를 만들까 생각하다가 과하다는 생각이 든다. 문득 진짜 필요한 것만 쿼리해서 쓸 수 있는 방법을 제공한다는 GraphQL 컨셉이 떠오르고 내가 하려던게 REST API 컨셉 같다는 생각이 든다.

개발일기 #113 : 러닝커브만 넘어서면 단순해 진다 (feat. 첫 웹 API 개발 경험)

댓글