Coca Cola Red

오늘은 지난번, 직접 Insomnia로 테스트해보며 HTTP 메서드가 기능은 포함하지 않는다는 사실을 알게 되었습니다. 같은 의미로 상태 코드 또한 어떤 기능도 지니지 않으며 표준을 지키지 않더라도 백엔드 동작에는 아무 문제가 없을 것입니다. 그렇다면 왜 메서드와 상태 코드를 올바르게 작성해야 하는 것일까요1. 컨벤션에 맞지 않는다.- 컨벤션이 맞지 않으니 클라이언트와 서버가 서로 생각하는 동작이 다르게 될 확률이 있습니다. 이는 서비스 자체에 결함을 초래할 수 있습니다. 예를 들어 PATCH를 사용해도 충분한 API에서 PUT으로 작성하게 된다면 매번 해당 데이터 전체를 덮어쓰는 작업을 표준으로 두기 때문에 트래픽 낭비가 생길 수 있습니다.  2. 상태 코드의 쓰임- 같은 맥락에서 올바르지 못한 상태 ..

오늘은부트 캠프를 진행하며 새로운 팀 프로젝트를 시작하고 오늘로써 마쳤습니다. 돌이켜보던 중 API 명세서를 보며 든 질문을 작성해보겠습니다. 작성한 API 명세서입니다. 해당 명세서를 보며 문득 현재 로그아웃 API는 저장된 리프레쉬 토큰을 삭제하는 작업을 수행하는 데POST 메서드로 작성되는 게 옳은 걸까? 라는 생각이 들었습니다. HTTP 메서드는 실제 기능하는가 ? HTTP 메서드는 서버에 요청하는 동작에 의미를 나타내는 동시에, 주어진 리소스에 수행해야 될 동작을 지정하는 방법입니다.그렇다면 GET, DEL 와 같은 메서드를 보내고 리소스를 추가하는 동작을 요청하면 API는 동작하지 않게 되는 것일까요? 그럼에도 동작한다면 ? HTTP 메서드는 명시적인 의미만을 가지는 것인지, 혹은 동작은 하더..

웹소켓(WebSocket)은 웹 브라우저와 웹 서버 간의 양방향 통신 채널을 제공하는 프로토콜이다.  웹소켓의 특징클라이언트와 서버 간 실시간 양방향 통신이 가능하다. 서버에서 클라이언트로 데이터를 보낼 수 있고, 클라이언트에서도 서버로데이터를 보낼 수 있다. HTTP 프로토콜과 달리 헤더 오버헤드가 작아 효율적이다. 초기 핸드셰이크 후에는 작은 데이터 프레임만 주고받는다. 웹소켓 연결은 지속적이며, 서버나 클라이언트 중 어느 한쪽에서 연결을 끊을 때까지 유지된다웹소켓의 동작 과정 Opening Handshake : 클라이언트가 웹소켓 연결을 요청하면 서버와 핸드셰이크를 수행한다. 이 과정에서 HTTP 프로토콜을 업그레이드 한다. Data Transfer : 핸드셰이크 후 웹소켓 프로토콜로 데이터를 주고..

1. 개요이메일 검증과 사용자의 리프레쉬 토큰 저장을 위하여 Redis를 사용해보기로 결정하였습니다.Redis 서버와의 연결 과정에서 발생했던 문제점에 대해 다뤄보겠습니다.2. 트러블슈팅2.1 배경 2.2 발단 Redis 서버와의 연결 작업 중 문제가 발생하였습니다.Redis에서 제공하는 클라이언트 연결 코드를 사용하여 연결을 시도했을때 서버와 연결이 되지 않는다는에러가 발생했습니다. 2.3 전개터미널로 확인해보니 redis는 promise를 반환하고 있었습니다. 2.4 위기문제를 해결하기 위해 함수로 한번 더 감싸 async await 키워드를 넣어주었지만 해결되지 않았습니다. 2.5 절정 async를 지워보고 await만을 사용했을 때 서버와 정상적으로 연결이 이어졌습니다. 2.6 결말튜터님께서 알려..

Redis는 오픈소스 인메모리 키-값 데이터 저장소를 뜻한다. Redis의 정의 원격 사전 서버(Remote Dicionary Server)의 약자이다.키-값 구조 외에도 리스트, 셋, 정렬 셋, 해시 등 다양한 데이터 구조를 지원한다. 모든 데이터를 메모리에 저장하므로 디스크 기반 데이터베이스보다 읽기 속도가 매우 빠르다.단일 스레드 이벤트 루프 모델로 동작하여 효율적이다.Redis의 주요 용도캐싱: 데이터베이스에서 자주 사용되는 데이터를 메모리에 캐싱하여 응답 속도를 높인다. 세션 관리: 웹 애플리케이션의 사용자 세션 정보를 저장한다.메시징 브로커: Pub/Sub 기능을 통해 메시지 큐 시스템으로 사용할 수 있다.Redis의 특징 메모리 기반이므로 디스크 I/O 없이 데이터에 빠르게 접근할 수 있다...

웹소켓이란 웹 브라우저와 웹 서버 간의 양방향 통신을 위한 프로토콜이다.웹소켓의 특징클라이언트와 서버 간 실시간 양방향 통신 가능HTTP 프로토콜과 달리 헤더 오버헤드가 작아 효율적서버에서 클라이언트로 데이터를 주기적으로 전송할 수 있다.웹소켓 연결 후에는 HTTP 요청/응답 없이 데이터를 주고받을 수 있다.웹소켓 동작 과정Opening Handshake : HTTP를 통해 웹소켓 연결을 요청하고 승인받는다.Data Transfer : 웹소켓 프로토콜로 데이터를 주고받는다. 데이터는 프레임 단위로 전송되며 여러 프레임이 모여 하나의 메시지를 구성한다.Closing Handshake : 연결을 종료한다.

TDD란?TDD는 소프트웨어 개발 방법론 중 하나로, 테스트 케이스를 먼저 작성한 후 그 테스트를 통과하는 실제 코드를 구현하는 반복적인 개발 프로세르를 말한다.  TDD 프로세스 TDD는 다음과 같은 반복적인 단계로 진행된다. Red - 실패하는 테스트 케이스를 작성한다. Green - 가능한 빠르게 테스트를 통과하는 최소한의 코드를 작성한다. Refactor - 코드를 리팩토링하여 중복을 제거하고 가독성을 높인다.이 과정을 반복하여 점진적으로 기능을 구현해 나간다.  TDD의 장점 높은 코드 품질 - 테스트 케이스 기반으로 개발하므로 버그가 적고 유지보수성이 높아진다. 자신감 있는 리팩토링 - 테스트 케이스가 존재하므로 코드 변경 시 안전성이 높아집니다. 명확한 요구사항 정의 - 테스트 케이스를 먼저..

3계층 아키텍처는 소프트웨어 시스템을 프레젠테이션 계층, 애플리케이션 계층, 데이터 계층으로 논리적으로 분리하는 아키텍처 패턴이다.  프레젠테이션 계층 사용자 인터페이스를 제공하는 계층클라이언트 측에서 실행되며 사용자와 상호작용한다. 웹 브라우저, 모바일 앱 등이 이 계층에 해당한다. 애플리케이션 계층 비즈니스 로직을 처리하는 계층프레젠테이션 계층의 요청을 받아 필요한 데이터를 데이터 계층에서 가져와 처리한다. 데이터 계층 데이터베이스나 파일 시스템 등 데이터를 영구적으로 저장하는 계층애플리케이션 계층의 요청에 따라 데이터를 제공하거나 수정한다. 3계층 아키텍처는 각 계층을 분리하여 개발하고 유지보수할 수 있어 시스템의 확장성과 유연성을 높일 수 있는 장점이 있다.

빈약한 도메인 모델은 도메인 객체에 비즈니스 로직이 거의 없고 단순한 데이터 게터/세터 메서드만 존재하는 안티패턴을 말한다.대신 대부분의 비즈니스 로직이 서비스 계층에 구현되어 있다. 빈약한 도메인 모델의 특징 도메인 객체는 단순한 데이터 컨테이너 역할만을 담당.비즈니스 로직은 서비스 계층에 집중객체지향 설계 원리를 위반하며 절차적 코드 스타일도메인 객체가 무의미해지고 도메인 지식이 서비스 계층에 섞여있다. 빈약한 도메인 모델의 단점 도메인 객체의 무결성과 불변성을 보장하기 어려움도메인 로직 변경 시 서비스 계층의 변경이 불가피객체지향 설계 원리를 위반하여 유지보수성이 떨어진다.도메인 지식이 서비스 계층에 섞여 이해하기 어려움따라서 도메인 모델에 충분한 비즈니스 로직을 포함하는 풍부한 도메인 모델을 사용..

SOLID 원칙은 객체 지향 프로그래밍 및 설계의 5가지 기본 원칙으로,시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들기 위해 적용된다.  단일 책임 원칙 (Single Responsibility Principle)한 클래스는 하나의 책임만을 가져야 하며, 클래스를 변경하는 이유는 하나여야 한다.  개방-폐쇄 원칙 (Open/Closed Principle)소프트웨어 엔티티 또는 개체(클래스,모듈,함수)는 확장에는 열려있으나 변경에는 닫혀 있어야한다. 즉 기능을 추가할 때는 기존 코드를 변경하지 않고 새로운 코드를 작성해야 한다. 리스코프 치환 원칙 (Liskov Substitution Principle)프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않고 상위 타입의 인스턴스로 바꿀 수 있어야 한다...