Go 언어로 만든 REST에 ETag 캐시 적용하기

ETag는 Entity Tag의 줄임말이다. Entity라는 말이 생소할 수도 있는데 Entity는 HTTP 메시지(Messages)와 연관이 있다. HTTP 메시지와 Entity HTTP 메시지는 HTTP 통신상에서 웹 서버와 클라이언트가 서로 주고받는 것을 의미한다. 클라이언트가 웹 서버로 보내는 메시지를 요청 메시지(Request Messages)라고 부르며, 웹 서버가 요청에 의해 클라언트에게 보내는 메시지를 응답 메시지(

GraphQL 그리고 MSA

MSA 환경에서 일하는 Front-end 개발자들을 만나면 나는 종종 이런 말을 듣는다. 주문서 화면을 만들 때 4~5개를 호출해서 조합해야 했어요. - 개발자 A 기부 상세 화면을 만드는데 같은 기부 번호로 여러 API를 호출해서 조합하고 있어요 - 개발자 B 벡엑드 개발자분이 API를 너무 잘 개 만들어 놔서 하나의 화면을 만들때 여러 번

코드 복잡도 줄이기 (Cyclomatic Complexity, NPath Complexity)

이번 포스팅도 어떤 백엔드 서비스의 코드를 리팩터링한 내용을 정리하는 것으로, 이번에는 코드 복잡도 줄인 리팩터링에 대한 내용을 정리한다. 이전에 포스팅했던 '가변 Context 클래스는 신중하게 사용하자'와 '고차 함수로 의존성 줄이기'로 코드의 의존성 문제들이 많이 정리된 상태라서 복잡도 줄이기를 진행할 수 있었다. 아래는 어떤 백엔드 서비스

버려지는 서비스를 바라보며

몇 개월 동안 애정을 가지고 개발한 서비스가 있었다. 계약이 종료됨에 따라 인수인계를 해야 하는 상황이 되었고 인수인계 과정에서 알게 된 것은 만든 서비스를 버리려 한다는 사실이었다. 마이크로서비스 아키텍처를 차용하여 별도 서비스로 만들었지만 누군가는 그것을 모놀리스로 합치려 하고 있었고, 태블릿 기기에서 사용하도록 만들었지만 누군가는 그것을 PC 데스크톱으로 만들려 하고 있었다. 의도한

Golang Panic을 Rocover 할 때 Error Stack Trace 함께 출력하기

나는 Go에서 Error가 발생할 때 Stack Trace를 함께 출력하는 ‘Golang Error Stack Trace와 로깅’ 라는 글을 쓴 적이 있다. 하지만 시스템을 운영하면서 Panic을 Recover한 경우 Error Stack Trace가 출력되지 않는다는 것을 발견했다. 이 글은 ‘Golang Error Stack Trace와 로깅’ 에 이어지는 글로 Panic을 Recover한 경우에도 Stack Trace를 출력하는 방법을 소개한다.

파이썬으로 티스토리 백업 유틸리티 만들기

배경 티스토리를 사용한 지 10년이 넘다 보니 글도 제법 쌓였고, 백업도 한번 받고 싶은데, 백업 기능이 없다. (없었다.) 백업 기능을 만들어 달라고 문의도 해봤는데, 안 만들어준다. 구글링을 해보니 티스토리 백업 유틸리티가 제법 많이 나오기는 하는 데 사용하기가 조금 애매하던 차에 이번에 고등학교 로봇동아리 학생들을 대상으로 '개발자에 대한 궁금증'

장애는 ‘우리의 문제’다

내가 주니어 시절에 있었던 일이다. 입사 한지 얼마 되지 않았던 상황에서 코드를 수정해야 할 일이 생겼고 수정한 코드를 운영에 배포했다. 그리고 일주일이 지난 후, 특정 옵션 상품이 장바구니에 담기지 않는다고 연락이 왔다. 배포 당시에 문제를 발견하지 못하고 일주일 간 장애가 발생한 것이었다. 다른 팀 기획자에게 전화가 왔으며, 추궁이 이어졌다. 황급히

엘라스틱이 쉬웠던 이유 - 2nd

검색엔진은 잘 모르지만 엘라스틱을 데이터 분석툴로 사용할 때 데이터 전처리가 차지하는 비중은 생각보다 크다. 그렇다 보니 자연스럽게 로그스태시 필터 기능을 소개하는 데 많은 시간을 할애한다. 그때 종종 받는 (툴을 잘 쓰면 데이터 분석이 쉬워질거라는 기대가 담긴) 질문.   저 기능들을 언제 다 익혔나요? 그러게? 난 언제 저 기능들을 익혔지? 사실은 익힌

고차 함수로 의존성 줄이기

스프링을 사용한 프로젝트에서 종종 보이는 어노테이션에 사용한 의존성 주입의 남용과 오랜 세월의 흐름으로 의도치 않게 서비스 간의 의존성 그래프가 복잡하게 강결합으로 묶이면서 코드를 읽기도 어렵고 단위 테스트를 구성하기도 어려운 상황이 생긴다. 아래는 어떤 백엔드 서비스의 의존성 그래프다. 순환 종속성이 포함된 복잡한 왼쪽의 의존성 그래프를 오른쪽의 단순한 의존성 그래프로 리팩터링하여 라이브

‘프론트냐 백엔드냐’를 고민하는 당신에게

나는 ‘개발자를 코칭하며 배운 7 가지’ 라는 제목의 글을 쓴 적이 있는데 내가 코칭한 대부분의 개발자들이 토로하는 고민이 있었다. 프론트를 해야 할지 백엔드를 해야 할지 잘 모르겠어요. 내 경험에 의하면 많은 이들이 자신에게 물어야 할 질문을 남에게 묻는다. 왜 그럴까? 자신이 무엇을 좋아하는지, 무엇을 하고 싶은지 잘 모르기 때문이다. 그래서

하위 버전 CentOS Linux에 배포할 때의 glibc, libstdc++ 라이브러리 버전 문제

배경 최근에 읽은 ‘구글 엔지니어는 이렇게 일한다.’에서 컴파일러 버전업에 대한 이야기가 나와서 예전에 작업했던 GCC 컴파일러 버전업에 대한 내용을 정리해본다. 몇 년 전 새로운 팀에 합류했을 때 서비스 중인 서버군들 중에서 C++ 구현된 서버군이 gcc 4.4.7을 사용하고 있었고, 컴파일러 버전이 낮아서 모던 C++의 시작인 C++ 11를

JWT 인증은 무엇이고 어떻게 사용해야 할까?

마이크로서비스 아키텍처가 많이 보급 되면서 클라이언트와 서버 간의 인증 상태를 유지하는 기존의 전통적인 서버 세션 방식과는 다른  클라이드 사이드 세션인 JWT(JSON Web Token) 방식이 많이 활용되고 있습니다. 필자도 처음에는 "마이크로 서비스에서는 인증은 주로 JWT를 사용한다" 라는 의견에 공감하면서 그냥 생각없이 사용하고 있었는데 한번은 정리해야 할 필요성을 느껴