GraphQL 그리고 MSA
MSA 환경에서 일하는 Front-end 개발자들을 만나면 나는 종종 이런 말을 듣는다. 주문서 화면을 만들 때 4~5개를 호출해서 조합해야 했어요. - 개발자 A 기부 상세 화면을 만드는데 같은 기부 번호로 여러 API를 호출해서 조합하고 있어요 - 개발자 B 벡엑드 개발자분이 API를 너무 잘 개 만들어 놔서 하나의 화면을 만들때 여러 번
Latest
코드 복잡도 줄이기 (Cyclomatic Complexity, NPath Complexity)
이번 포스팅도 어떤 백엔드 서비스의 코드를 리팩터링한 내용을 정리하는 것으로, 이번에는 코드 복잡도 줄인 리팩터링에 대한 내용을 정리한다. 이전에 포스팅했던 '가변 Context 클래스는 신중하게 사용하자'와 '고차 함수로 의존성 줄이기'로 코드의 의존성 문제들이 많이 정리된 상태라서 복잡도 줄이기를 진행할 수 있었다. 아래는 어떤 백엔드 서비스
고차 함수로 의존성 줄이기
스프링을 사용한 프로젝트에서 종종 보이는 어노테이션에 사용한 의존성 주입의 남용과 오랜 세월의 흐름으로 의도치 않게 서비스 간의 의존성 그래프가 복잡하게 강결합으로 묶이면서 코드를 읽기도 어렵고 단위 테스트를 구성하기도 어려운 상황이 생긴다. 아래는 어떤 백엔드 서비스의 의존성 그래프다. 순환 종속성이 포함된 복잡한 왼쪽의 의존성 그래프를 오른쪽의 단순한 의존성 그래프로 리팩터링하여 라이브
아키텍트
트레이드오프와 아키텍트 그리고 개발자의 소통 문제
브런치에서 뉴스를 빠르고 유익하게 소비하는 사례로 썼던 글을 popit의 주요 독자들이 흥미로워 할 주제라 생각에 이곳에도 옮겨봅니다. 두 가지 이야기를 하려고 합니다. * 트레이드오프 즉, 상충관계에 대한 생각 * 개발자에게 아키텍트로 나아가는 길 먼저 트레이드오프는 과거 제가 소프트웨어 아키텍트로 일할 때, 가장 자주 다루던 개념이자 주요 관심사였습니다. 서로 다른 이해관계를 갖는 참여자
적당히 갖춰나간 운영 환경
2016년, 중국 패션 리테일 영역의 클라우드 서비스 회사가 되겠다는 야심 찬 희망을 품고 아기 발걸음[1]을 시작했고, 2020년 현재 아래와 같은 구성을 갖추었다. 처음부터 이런 구성을 그려놓고 차근차근 갖춰 나간 것은 아니었다. 2016년 봄, 알리 클라우드에 3대의 리눅스 서버를 구매해서 1대에 대충 스테이징 환경과 각종 관리 툴을 세팅하고 2대
클라우드와 구독형 서비스는 무슨 관계인가?
어제 글쓰기 흥미[1]를 자극하는 글이 올라왔다. 조금 더 정확하게 말하면 글에서 인용한 이미지가 내 시선을 잡아 끌어 여러 가지 생각을 만들도록 했다. 그래서 아래 이미지에 기초해 주관적인 감상을 쓴다. 빙산의 일각을 비교해보자 그림이 주는 시각적 흡수가 오해일 수 있어 오류를 줄이려 원문을 찾아보았으나 원하는 설명은 없었다. 후에 확인을
마이크로서비스
스파게티 조인을 피하고 경계안에서 캐시 구현하기
아침에 출근했더니 동료가 나에게 링크를 하나 던지며 이렇게 말했다. 위 블로그가 어제 말한 오퍼레이션 캐쉬 설명하는것 같은데 한번 검토해주실수있을까요? Why duplication isn’t always a bad thing in micro-services CTO님이 데이터 중복이 필요할 때가 있다고 설파하던 기억이 난다. 그 당시 대부분의 개발자들이 못알아듣는 눈치였는데, 역시 사람들이 배워서 써먹는 데에는
클린 아키텍처 번역을 마치며...
"이 글은 책을 소개하는 글입니다. 과도한 책 광고가 포함될 수 있습니다" 번역이라는 어두컴컴한 동굴을 빠져나와 출간을 앞두고 있습니다. 책에 대한 소개보다는 "번역"이라는 일을 시작하게된 개인적인 경험을 풀어써 보고자 합니다. 2010년... 때는 바야흐로 2010년. 팀을 이끌던 선배가 "질질 끌던" 번역 작업을 이제 마무리해야 한다며
테스트 용이성(Testability) 향상을 위한 델리게이션(Delegation)
이전 포스팅 ‘테스트 용이성(Testability) 향상을 위한 DI(Dependency Injection)’에서 이어지는 내용이다. 종속성 문제 테스트 코드 없이 개발할 때는 잘 인지하지 못하다가 테스트 코드를 넣으려고 할 때 만나는 문제 중 하나로 종속성 문제가 있다. 테스트 환경에서 특정 객체 하나를 생성하기 위해서 너무 많은 객체가 필요해지는 상황과 특정 객체가 내부적으로
AWS EBS(Elastic Block Storage) 비용 최적화
[원본글] https://ericygkim.wordpress.com/2019/07/11/aws-ebselastic-block-storage-의-비용-최적화/ 애플리케이션 개발 후 AWS에 애플리케이션을 설치할 때 성능, 가용성, 확장성, 비용, 서비스 특성등 많은 요구사항들을 고려하여 복잡한 고민을 거쳐 EC2 인스턴스 사이즈등 AWS 자원들을 선택하게 됩니다. 그 중 중요한 요소 중 하나가 EC2인스턴스나 RDS에 연결되는
Spring Boot JPA Step-15 Querydsl를 이용해서 Repository 확장하기 (2)
해당 코드는 Github를 확인해주세요. JpaRepository의 쿼리 메서드를 통해서 간단한 쿼리들을 아래 예제 처럼 쉽게 만들수 있습니다. public interface AccountRepository extends JpaRepository<Account, Long> { boolean existsByEmail(Email email); boolean exsistByxxx(...) long countByEmail(Email email); long countByxxx(...) } 유사한 쿼리가 필요해지면 쿼리 메서드를 지속적으로 추가해야 하는 단점이 있습니다. 이런 경우에 QuerydslPredicateExecutor를
Spring Guide - Directory 가이드
해당 코드는 Github를 확인해주세요. Spring Guide 1. Test 전략 가이드 2. Exception 전략 가이드 3. Domain 객체 가이드 4. 외부 API 가이드 5. Service 적절한 크기 가이드 6. Directory 가이드 패키지 구성은 크게 레이어 계층형, 도메인형 이렇게 2 가지 유형이 있다고 생각합니다. 각 유형별로 간단하게 설명하고 제 개인적인 Best Practices를