분류 전체보기

    테스트하기 쉬운 코드, 구조 (1) : mocking 사용한 테스트코드 작성

    보통 의존성이 얽혀있는 코드는 테스트하기가 어렵다. 하지만 mocking을 사용하면 매우 쉽게 테스트 코드를 작성할 수 있다. (mocking은 "모의 객체로 외부의 다른 서비스나 모듈들을 실제 사용하는 모듈을 사용하지 않고 실제의 모듈을 "흉내"내는 "가짜" 모듈을 사용하는 객체" 이다.) 먼저 mocking을 사용하지 않고 테스트 코드를 작성해 보면 // blog.service.ts import { Test1Repository } from './test2.repository'; import { Test2Repository } from './test2.repository2'; import { Test3Repository } from './test2.repository3'; import { Test4Re..

    Docker 기본 명령어

    생성 실행 동시에 하려면 - docker run [imageName] 생성 - docker create [name] - id 생성됨 생성 후 실행하려면 이 명령어 - docker start -a [생성된id] 중지(1) - docker stop [id] - 하던 작업들 마무리하고 중지시킴 (메세지 같은거 보내고있었으면 다 보내고 중지) - docker kill [id] - 자비없이 그냥 바로 킬 컨테이너 삭제 - 하나씩 삭제 - 중지 한 후에 삭제가능 - docker rm [id] - 전체 삭제 - docker rm docker ps -a -q 이미지 삭제 - docker rmi [id] 컨테이너 이미지 한번에 삭제 - docker system prune 폴더리스트 보기 - docker run [imag..

    객체지향적으로 간단한 머드게임 만들기

    객체지향적으로 간단한 머드게임 만들기

    최근 회사 개발자 전원에게 '객체지향적으로 간단한 머드게임 만들기'라는 과제가 주어졌다. 기본적인 룰은 제공을 해주는 과제였다. 해당 자료는 해당 과제 발표자료이다. 게임 기초 룰 위의 게임 기초 룰을 보면 알 수 있듯이 사실 해당 과제의 기능은 너무 간단해서 구현이 문제가 되진 않는다. 하지만 단순 구현이 과제 핵심 목적이 아니다. 해당 과제의 목적은 객체지향적인 설계에 대한 생각을 기반으로 어떻게 설계했는가 이다. (어떤 구조로 설계했는가) 객체 지향적인 설계 블로그나 커뮤니티에 객체 지향적인 설계에 대한 글은 정말 많다. 그중 빠지지 않고 등장하는 말은 역할과 책임에 따라서 객체를 나눠야 한다는 말이다. 당연히 맞는 소리라고 생각하지만 역할과 책임에 따라서 나눠진 객체들의 관계를 어떻게 관리하는지도..

    백엔드 아키텍처 관련 정리자료

    백엔드 아키텍처 관련 정리자료

    아키텍처 정리 개인적으로 백엔드 아키텍처를 구성하면서 생각했던 것들에 대해 정리했다. 나중에 언젠가 발표자료로 쓰고 싶어서 키노트로 정리 중이다. -> 회사 백엔드 팀 내부에서 간단한 세미나로 공유함 백엔드 아키텍처를 공부하면 매번 나오는 개념들 백엔드 아키텍처에 대한 내용을 검색하면 매번 나오는 개념들이 있다. 바로 IoC와 DI이다. 사실 예전에 어떤 회사의 과제에 해당 개념을 제대로 적용하지 못해 떨어졌던 기억이 있어서 좀 더 자세히 알아보게 됐다. IoC에 대한 설명 먼저 IoC는 제어의 역전이라는 뜻이다. 위 코드는 Nestjs의 서버 시작점이다. 우리는 bootstrap()이라는 함수의 실행을 통해 서버를 시작하는데 bootstrap() 함수 안에 NestFactory 또는 NestFactor..

    테스트 코드 공부 기록_ 20221006

    테스트 코드 공부 기록_ 20221006

    테스트 코드 테스트 코드 이 글은 jest를 활용한 TDD 하는 방법에 대한 내용은 아니다. layer가 나눠져 있는 환경에서의 테스트 코드 작성, 의존성을 활용해 mock 함수 제거에 대한 개인적인 고민이 담긴 글이다. 그렇기 때문에 해당 글이 정답 일리는 없고, 그냥 테스트 코드에 매우 미숙한 1년 차 주니어 개발자의 개인 공부 기록이다. 최근 테스트 코드를 제대로 작성해보고 싶어서 작년에 샀던 강의를 다시 들었다. 해당 강의는 간단한 CRUD 기능을 TDD로 개발하는 강의였다. 강의에선 javascript와 express, jest를 활용해 테스트코드를 작성했지만, 직접 해볼 땐 Typescript와 express, jest를 활용해 진행했다. 먼저 아래는 모든 비지니스 로직이 한 곳에 모여있는 코..

    AWS_CDK

    AWS_CDK

    AWS_CDK 최근 어떤 유튜브 영상에서 CS 세계의 방향성에 대한 얘기를 봤다. 인프라를 추상화해서 관리하고 비즈니스 로직에 집중하는 방향으로 흐른다는 영상이었다. 사실 개발을 처음 시작한 지 아직 1년도 안됐기 때문에 개발 업계의 방향성에 대해서 느껴지는 바는 없지만, 최근 AWS를 다룰 일이 많아지면서 AWS lambda, 서버리스 등의 단어를 자주 접했고, 해당 개념에 대해 궁금해 찾아보니 인프라의 추상화, 비즈니스 로직에 집중이라는 말을 어느 정도 이해할 수 있었다. 서버리스? AWS lambda? 서버리스는 서버가 없다는 뜻이 아니라 서버를 직접 관리할 필요가 없는 (혹은 적은) 아키텍처를 뜻한다. 일반적으로 알고 있는 Firebase 같은 서버리스 아키텍처는 BaaS로 Backend as a..

    헥사고날 아키텍처(포트 앤 어뎁터 아키텍처)_Express example

    헥사고날 아키텍처(포트 앤 어뎁터 아키텍처)_Express example

    클린 아키텍처 클린 아키텍처가 갖는 기본적인 목적은 관심사의 분리다. 각각 계층별로 관심사를 나누고, 도메인 (비즈니스 로직) 중심으로 설계해야 한다. 또한 프레임워크나 외부 UI에 의존하지 않아야 한다. 헥사고날 아키텍처 (포트 앤 어뎁터 아키텍처) 헥사고날 아키텍처는 클린 아키텍처와 거의 비슷하다. 둘은 도메인 (비즈니스 로직)을 인프라 (단순히 AWS와 같은 인프라 뿐만 아니라 view layer와 도 포함)에서 분리하는 것이다. → 위 그림은 클린 아키텍처 그림이다. 엔티티가 가장 안쪽에 있고, 의존성은 밖에서 안쪽으로만 존재한다. 그렇기 때문에 엔티티에 접근하기 위해선 계층을 전부 거쳐야 들어올 수 있다. → 해당 그림은 헥사고날 아키텍처의 그림이다. 클린아키텍처 그림과 동일하게 의존성은 밖에서..

    AWS www.도메인 -> 도메인 리디렉션

    AWS www.도메인 -> 도메인 리디렉션

    AWS www도메인 → 도메인 리디렉션 크롬 브라우저에서 naver.com를 쳐서 들어간 후 url 창을 더블클릭해보면 www.naver.com으로 나와있는 것을 볼 수 있다. 분명 www를 붙이지 않고 접속했는데 www가 붙어있는 이유는 일종의 관습 때문이라고한다. 예전부터 도메인 앞에 www를 붙이던 관습때문에 아직도 메인 도메인역할을 하는 것이다. 하지만 AWS Route53을 이용해 example.com 도메인을 연결해보면 자동으로 www.example.com이 등록되진 않는다. AWS에서 직접 _ www_가 달려있는 도메인을 따로 등록을 해줘야 하는데 EC2의 경우 정말 쉽게 설정이 가능하지만 CloudFront와 S3를 통해 배포된 서비스의 경우 설정하기가 약간 복잡하다. CloudFront와..

    Nest + Graphql 구현하기

    Nest + Graphql 구현하기

    Nest + Graphql + Mongoose 최근에 Express환경에서 Graphql을 구현할 일이 있었다. 원하는대로 완성은 했지만 자유도가 높은 Express 환경에서 구현하다보니 원하는 아키텍처를 구현하는데 어려움(+ 귀찮음)이 있었다. 그래서 이번엔 어느정도 아키텍처가 세팅되어있는 Nest 환경에서 Graphql을 구현해보려고 한다. Express + Graphql에서 나타났던 문제들 첫 번째로 타입 중복선언과 두 번째로 의존성 주입패턴이 있다. 타입 중복선언은 graphql의 typeDef 선언과 DB schema가 따로 선언되는 문제였고, 의존성 주입패턴은 Express에서 구현하다보니 DI나 IoC의 개념들도 직접 구현해줘야 하는 문제들이었다. 하지만 해당 문제들은 Nest에서 기본으로 ..

    Express + Graphql 좀 더 구조적으로 짜기 (+ Type-graphql, Typegoose, Typedi)

    Express + Graphql 좀 더 구조적으로 짜기 (+ Type-graphql, Typegoose, Typedi)

    Express + Type-graphql + TypeDi + Typegoose 회사에서 Graphql을 사용할 일이 있어서 가볍게 Express에서 구현하려고 했었다. 공식문서와 구글링으로 기초적인 세팅과 구현은 완료해서 사용에는 문제가 없었지만, 타입 중복선언과 의존성 주입 부분에서 신경쓰이는 것들이 있어 해당 부분들을 해결하다보니 Express에 Type-graphql, TypeDi, Typegoose를 사용하게 되었다. 1. 타입 중복선언 일반적인 Graphql의 경우 입력이나 리턴되는 값들의 타입을 지정해줘야 한다. 보통 아래와 같이 typeDef를 선언해 할당해 준다 const typeDefs = gql` type User { loginId: String userId: String name: S..