Blog
//
Blog
About Me
//

블로그 이사 테스트

Category
Author
citeFred
citeFred
Tags
PinOnMain
1 more property
Tistory에서부터 5번정도 블로그를 바꿔나가면서 그 중심엔 Notion이 있었다.
Table of Content

블로그 이사 템플릿 테스트..

상단 목차가 생성 템플릿에 기본으로 적용되도록 설정

정신없는 블로그.. 처리하기

노션의 기능을 이것저것 사용하다보면서, 점점 복잡해지는 문제가 발생했다.

Toggle H1

Toggle H1

Toggle H2

Toggle ㅇ

Toggle ㅇㅁ

Search

1. MVC 디자인 패턴

[Node.js] 13. MVC 디자인 패턴과 리팩토링

1. 백엔드 NestJS+내장 Express 컨테이너화 및 실행

1.1 Dockerfile 및 .dockerignore 작성

•
MP_Project/Back-end/Dockerfile 생성
•
MP_Project/Back-end/.dockerignore 생성

1.2 이미지 빌드

•
터미널 MP_Project/Back-end/ 경로(Root)에서
•
Docker-Desktop에서 생성된 NestJS 백엔드 프로젝트가 빌드된 이미지 확인

1.3 컨테이너 실행

•
CLI를 통한 이미지→컨테이너 실행 명령어
[Docker] Docker VM 활용 통합 배포와 CI/CD 파이프라인 구축

1. 플러그인 설치

Marketplace에서 아래 키워드로 검색하여 각각 설치한다.
•
SQLTools
•
@tag:sqltools-driver

2. 설치 후 커넥션 추가

•
좌측 하단 원통형 DB 아이콘이 생성되고 Add New Connection으로 DB와 연결해야 한다.
•
드라이버 플러그인도 설치가 정상적으로 되었다면 아래와 같이 아이콘이 나타난다. MySQL 선택
[Node.js] 12. 데이터베이스 GUI VSCode 플러그인

Ajax → Fetch API

이전 Ajax를 통해서 REST 아키텍처를 갖추었지만 jQuery AJAX는 요청을 보내고, 성공 및 오류에 대한 각각의 콜백 함수를 직접 구현하고 있었다. success 부분의 function, error 부분의 function 이를 통해 비동기 요청을 처리하는 기능은 구현되고 있는 것이다.
하지만 여러 콜백함수를 직접 작성, 사용해야 하므로 코드가 다소 복잡해질 수 있는 문제점이 있었다.
이러한 문제점을 개선 할 수 있었던건 Promise객체로 실패, 성공 상태를 가지는 객체로써 Fetch API 함수는 항상 이 객체를 반환하는 것으로 설계되었다.
따라서, fetch() 메서드를 통해서 메서드 체이닝(. 연결)을 통해 .then()과 .catch() 메서드를 사용 할 수 있어 구조적으로 가독성을 높이는 역할을 하게 되었다.
•
Ajax 요청의 일반적인 형태
•
Fetch API 요청의 일반적인 형태
[Node.js] 10. 모던 자바스크립트 스타일Fetch API 요청 리팩토링

1. 네트워크

2. Client와 Server

3. Web Server와 Web Application Server

[CS] 서버 개발을 위한 기초 CS 지식 정리

1. Generics

새로운 폴더(metaverse/greeter/src/generics)
　｜　Main Page　｜　Category　｜　 Tags　｜　About Me　｜　Contact　｜　Portfolio
[TypeScript] 8. TypeScript의 Generics
[TypeScript] 6. TypeScript의 타입 - 2편

1. 원시 타입

새로운 폴더 (metaverse/greeter/src/types)

2. 배열

3. 변수와 함수에 대한 타입 표기

[TypeScript] 5. TypeScript의 타입 - 1편
[TypeScript] 4. TypeScript 의 기본 기능

1. 릴레이션(테이블)과 관련된 것들

2. 관계대수 vs 관계해석

[정처기] 데이터베이스구축-논리 데이터베이스 설계

1. MVP 기능 구현 추가 계획

2. 게시글 CRUD 구성

2.1 현재 상태 점검

[NestJS] 17. 게시글 및 회원 관리 기능 보완(CRUD) 리팩토링

1. 시스템 아키텍쳐(System Architecture)

1.1 System Architecture란?

1.2 문서화(Documentation)

[NestJS] 20. Architecture Diagram 그리기와 README.md 프로젝트 소개 꾸미기

1. File Input/Output이란?

2. Multipart/form-data란?

3. Multer 라이브러리

[NestJS] 16. 파일 입출력(I/O) 기능 구현

1. Client Side Rendering이란?

2. IONIC, Angular 환경 구축해보기

[NestJS] 15. CSR과 프론트엔드의 API 요청(Fetch API / HttpClient API)

1. OAuth란?

2. 카카오 개발자(Kakao Developers) 앱 생성

3. API 사용을 위한 여러 환경 구축

[NestJS] 14. Kakao API 소셜 로그인 기능 구현(OAuth)

1. 페이징 기능 추가

2. 프론트엔드 무한스크롤 참고 자료

[NestJS] 13. 게시글 페이징(Pagenation)과 무한스크롤(Infinity Scroll)

1. 파일 업로딩과 스트리밍

1.1 뷰 템플릿 엔진

•
목표: NestJS에서 뷰 템플릿 엔진을 사용하여 서버 사이드 렌더링(SSR) 구현
•
서버 측에서 HTML 템플릿을 렌더링하여 클라이언트에 동적인 콘텐츠를 제공

1.2 파일 업로드

•
목표: 파일을 서버로 업로드하고 관리하는 기능 구현
•
사용자 파일 업로드, 프로필 사진 등 다양한 파일을 서버에 저장

1.3 파일 스트리밍

•
목표: 서버에서 클라이언트로 대용량 파일을 스트리밍하는 기능 구현
[NestJS] 11. 심화 목표 키워드

서버 실행에서 오류 발생

MySQL 서버 실행 시 다음과 같은 오류가 나타날 때가 있다.
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'
또는 아래와 같은 내용이다.
/usr/local/Cellar/mysql@8.0/8.0.39_1/bin/mysqld_safe: line 199: /usr/local/var/mysql/Freds-MacBookPro.local.err: Permission denied /usr/local/Cellar/mysql@8.0/8.0.39_1/bin/mysqld_safe: line 144: /usr/local/var/mysql/Freds-MacBookPro.local.err: Permission denied ERROR! The server quit without updating PID file (/usr/local/var/mysql/Freds-MacBookPro.local.pid).
이 에러는 mysqld(mysql daemon) 프로세스가 서버를 실행한 후 pid 파일을 설치 경로에 생성하려는데 권한이 없는 경우 발생하는 오류이다.
검색을 통해서는 재설치, 또는 homebrew를 업데이트하면 해결된다는 스택오버플로우 의견도 있었다. 하지만 이것을 먼저 해보고 재설치하는 것을 추천한다. 재설치 시 기존 데이터베이스가 제거되기 때문이다.
아래 명령어를 통해서 mysql이 경로에 소유자 권한을 주어 읽기/쓰기 모두 가능하도록 설정한다.
이후 서버를 재실행하면 정상적으로 실행 된다.
[MySQL] MySQL 서버 실행 실패 오류 - ERROR! The server quit without updating PID file

1. 현재까지 진행된 상태에서 짚어 볼 수 있는 문제점

1.1 컨벤션(Convention) 이란?

1.2 명명 규칙 오류 발견하기

[NestJS] 10. 프로젝트 문제 인식과 컨벤션 리팩토링, 트러블 슈팅

논리적 문제 해결 프로세스

1. User와 Board 엔터티의 현재 상황(문제의 인식)

1.1 엔터티 관계 설계 시 기본 과정(문제해결방안 탐색1)

[NestJS] 8. 엔터티의 연관 관계(Relationships) feat. 문제 인식과 해결

1. Service 계층 리팩토링

임시DB에서 MySQL, TypeORM을 적용했으므로 Service 계층 코드를 전체적으로 수정한다.

2. Controller 계층 리팩토링

위 Service 계층 수정사항에 따라 일부 반환 타입등에 Promise가 추가되었으므로 아래처럼 Controller도 수정한다.
•
임시 주석을 해제하고 일부 변경 사항을 확인하여 수정한다.
•
단일 객체 반환은 Promise<Board> 리스트 배열 반환은 Promise<Board[]> 와 같다.
•
boards.controller.ts
[NestJS] 6. DB+TypeORM → CRUD Operation 연동 리팩토링 | 🎯 중요

1. 데이터베이스 환경 구축

1.1 데이터베이스란?

데이터베이스(Database)는 데이터를 체계적으로 저장하고 관리하는 시스템, 데이터의 집합을 이야기 한다.
DBMS란? DBMS(Database Management System)
RDBMS란?
NoSQL? Not Only SQL

1.2 MySQL 설치

[NestJS] 5. DB와 TypeORM 연동

1. 게시글 엔터티 설계

엔터티란?
게시글이 가지게되는 속성은 어떤것들이 있을까?
board.entity.ts
board-status.enum.ts

2. READ 1 - 모든 게시글을 조회하는 기능

boards.service.ts
[NestJS] 3. NestJS CRUD Operation 개발

1. 프로젝트 기본구조

1.1 프로젝트 생성

프로젝트 생성 하기

1.2 프로젝트 기본 요소

src 폴더
그 외 중요 요소
[NestJS] 2. NestJS 기본 요소

2. 요구사항 확인

요구분석 기법

•
요구공학이란? : 소프트웨어의 요구사항을 식별, 분석, 문서화, 관리하는 과정(체계화)
요구공학의 필요성
요구사항 개발 프로세스(순서) 1. 도출 : 사용자, 이해관계자로부터 요구사항 수집(인터뷰, 워크숍, 설문, 브레인스토밍 등) 2. 분석 : 실제 구현가능성 검토, 우선순위, 중복 또는 충돌되는 사항 수정
요구사항 분석 기법 - 인터뷰 : 인터뷰 - 브레인스토밍 : 아이디어 도출, 제시, 적합 선택 - 원인-효과 다이어그램 : 요구사항이나 문제,결과 등 시각화하는 다이어그램으로 분석, 복잡한것에 적합 - 프로토타이핑 : 실제 모습 프로토타입으로 피드백 유도 - 사용사례(Use Case) : 사용자의 시스템 사용 과정을 스토리보드 형태로 묘사, 가정 - 요구사항 검토 : 수집된 요구사항을 검토하여 중복, 충돌, 모호, 불안전 요소 찾기

UML(Unified Modeling Language)

•
소프트웨어 시스템을 시각화 및 문서화하고 구조와 동작을 명세하는 표준화된 모델링 언어
UML의 특징 1. 가시화 언어 : 다이어그램으로 시각적으로 이해를 도움 2. 명세화 언어 : 표준화된 언어로 명세하는데 사용 3. 구축 언어 : 설계-구현(개발)에 도움이되며 특히 객체지향 개발에서 중요함 4. 문서화 언어 : 표준 형태로 문서화되어 개발, 유지보수의 커뮤니케이션 됨
UML의 구성요소 1. 사물(Things) : 모델의 기본 요소 2. 관계(Relationship) : 사물간의 연관성 - 일반화 관계(Generalization : 한 클래스가 다른 클래스의 상위 개념 ‘부모’일때 = 상속) - 연관관계(Association : 2개 이상 사물이 관련된 관계, 다른 클래스의 기능을 사용할 때 등 표시) - 의존관계(Dependency : 다른 클래스 제공기능을 사용할때 표시, 연관과 차이점은 매우 짧은시간) - 실체화관계(Realization : 추상 메서드를 오버라이딩하는것 의미, ‘인터페이스’ 와 구현체로 이해. - 집합관계-집약관계(Aggregation : 불고기 = 간,다,미 처럼 has 관계 포함관계, 불 사라져도 다른재료 남음) - 집합관계-합성관계(Composition : 책상 = 다리,몸,나사, 책상이 사라지면 같이 사라짐) 3. 다이어그램 : 사물과 관계를 도형으로 표현 4. 스테레오타입 : 추가적인 의미 부여

구조 다이어그램(정적)

•
클래스 다이어그램
•
객체 다이어그램
소프트웨어설계 - 요구사항 확인

간단한 쇼핑몰 개발 기능목록

•
회원기능
•
상품기능
•
주문기능
•
기타 요구사항

도메인 모델과 데이터베이스 설계

•
회원:주문 = 1:N
•
주문:상품 = N:N이 되므로 중간테이블인 주문상품으로
•
상품:카테고리 = N:N(실제운영에서는 N:N을 지양해야함)
[Boot+JPA] 요구사항 분석 및 설계

H2 데이터베이스 설치

H2 인메모리 데이터베이스를 로컬환경에 설치하여 사용하고자 한다. 과거 MacOS 설치 내용과 동일하므로 해당 내용을 그대로 사용한다.
최초 데이터베이스를 생성하기 위해서는 JDBC URL을 다음처럼 입력한다.
이처럼 연결하고 나면 지정한 URL 경로에 다음과 같이 xx.mv.db와 같은 데이터베이스 파일이 생성되게 된다.
생성 이후부터는 로컬호스트로 접근이 가능하다.
[Boot+JPA] JPA, DB 설정

프로젝트 생성

프로젝트는 JDK 8(1.8) 버전을 사용하고자 하지만 spring.io에서는 더이상 과거 버전들의 셋업을 제공하지 않는 문제점이 있다. 따라서 원하는 group, artifact 명을 작성하고 우선 17버전으로 생성한 이후 프로젝트 내부에서 build.gradle을 통해 다운 그레이드를 하고자 한다.
과거 버전의 프로젝트 셋업이 된 스켈레톤 백업본이 없어서 아래처럼 진행하게 되었다.

기본 라이브러리 추가

프로젝트 생성 단계에서 원하는 라이브러리를 프로젝트에 추가 할 수 있다. 생성 이후에 build.gradle에 직접 추가해도 되지만 우선적으로 자주 사용되는 Spring Web, JPA, Lombok과 H2 Database를 선택하여 추가했다.

build.gradle에서 다운그레이드

다음과 같이 위 build.gradle을 수정한다.
[Boot+JPA] 프로젝트 환경 설정

웹 스코프의 종류

•
“request” : HTTP 요청 하나가 들어 오고 나갈 때 까지 유지되는 스코프, 요청마다 별도 빈 인스턴스가 생성되고 관리된다.
•
“session” : HTTP Session과 동일한 생명주기를 가지는 스코프
•
“application” : 서블릿 컨텍스트와 동일한 생명주기를 가지는 스코프
•
“websocket” : 웹 소켓과 동일한 생명주기를 가지는 스코프
세션, 어플리케이션, 웹소켓은 범위만 다르지만 동작방식은 비슷하다. 대표적으로 request 스코프의 예시를 참고하고자 한다.

0. web 실행 환경

예시를 위해서는 웹 환경에서 동작해야 하므로 build.gradle에 web 라이브러리를 설치해야 한다.

request 스코프

HTTP 요청과 응답까지의 생명주기와 함께하게 된다.
HTTP 요청에 대한 로그를 남기는 예시를 작성해보고자 한다. 동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어렵다. 이럴때 사용하기 적합한 것이 request 스코프이다. 요청의 UUID를 사용해서 HTTP 요청을 구분하고자 한다.
[SpringCore] 빈 스코프 - 웹 스코프

빈 스코프 종류

스프링은 다양한 빈 스코프를 지원한다.
•
싱글톤 : 기본 스코프, 컨테이너 시작과 종료까지 유지되는 가장 넓은 범위
•
프로토타입 : 스프링 컨테이너가 프로토 타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위
•
웹 관련 스코프 :

싱글톤 스코프

싱글톤은 항상 같은 인스턴스의 스프링 빈을 반환한다. 매번 요청마다 같은 인스턴스 주소값을 가진 객체를 반환한다.

프로토타입 스코프

하지만 프로토타입 스코프는 요청 시점에 프로토타입 빈을 생성하고 필요한 의존관계를 주입하고 빈을 반환한 후 더이상 관리하지 않고 새로운 요청에 또 새로운 빈을 생성한다.
[SpringCore] 빈 스코프 - 싱글톤과 프로토타입

외부 네트워크에 미리 연결하는 객체를 하나 생성한다고 가정

간단하게 url필드가 있는 외부 연결 대상 NetworkClient이 있다고 가정한다.

위 클라이언트를 연결하는 테스트코드 1

해당 설정 정보를 보면 NetworkClient 객체를 생성하고 또한 생성자 내부에서 이후에 setUrl()메소드를 통해 url을 전달하고 있다.
이때 결과로는 url이 전달되지 못하는 문제가 발생하는 것을 볼 수 있다.

객체의 생성과 초기화를 분리하자

스프링 빈은 간단하게 객체 생성 → 의존관계 주입 과 같은 라이프 사이클을 가진다.
•
스프링 컨테이너 생성 → 스프링 빈 생성 → 의존관계주입 → 초기화 콜백 → 사용 → 소멸전 콜백 → 스프링 종료
따라서 스프링 빈의 의존관계 주입까지 모두 완료된 후에 데이터를 사용(setUrl로 url을 입력할 수 있는 준비)해야 한다.
[SpringCore] 빈 생명주기 콜백 (올바른 초기화, 종료 방법)

“편리한 자동 기능을 기본으로 사용하자”

스프링이 나오고 시간이 갈수록 자동을 선호하는 추세이다.
•
스프링은 기본적으로 @Component 뿐만 아니라 @Controller, @Service, @Repository 처럼 계층에 맞추어 스캔을 지원하고 있다.
•
@Component만 넣어주면 되는 과정을 @Configuration 등 설정 정보를 지정하고 @Bean으로 등록하는 등 과정은 번거롭다.
•
자동 빈 등록을 통해서 기본적으로 OCP, DIP를 지킬 수 있다.

“수동 빈 등록은 언제 사용하는가?”

어플리케이션은 크게 업무로직과 기술지원 로직으로 나뉜다.
•
업무로직 빈 : 웹을 지원하는 컨트롤러, 비지니스로직, 데이터 계층과 같이 요구사항을 개발되는 부분
•
기술지원 빈 : 기술적인 문제나 공통관심사(AOP)를 처리할때 사용, DB연결, 공통 로그 처리 등 업무로직을 지원하기 위한 기술 부분
업무 로직 부분은 어느정도 유사한 패턴이 있다. 따라서 자동 주입을 적극 사용하기 편리하다.
기술지원 로직은 특정 목적이 따로 있거나 애플리케이션 전반에 광범위(AOP 등)하게 영향을 미칠 수도 있다. 적용이 정상적인지, 어느 부분에서 문제가 있는지 파악도 어려울 수 있기 때문에 가급적 수동 빈 등록을 통해서 보다 명확하게 범위를 한정하는 것이 좋다.

“비지니스 로직 중에서 다형성을 적극 활용할 때”

업무 로직은 유사한 패턴으로 설계 개발되는 경우가 많지만, 다형성을 활용하여 동적인 선택 등이 고려되는 경우 명시적으로 수동 빈을 설정하여 구분되는 것이 명확할 수 있다.
[SpringCore] 자동주입, 수동주입 올바른 실무 운영 기준

전체 테스트 코드

여러 구현체를 주입받은 DiscountPolicy (Map)

우선 DiscoutService 라는 클래스에서는 Map으로 fixDiscountPolicy, rateDiscountPolicy 두 구현체를 모두 주입받았다.
이후 DiscountPolicy 객체를 통해서 내부의 discount 메소드에 String(discountCode)를 파라미터로 전달하여 그 구현체를 선택하도록 하는 방식이다.
Map으로 각 구현체가 저장되어 key, value 쌍으로 저장되어있기 때문에 key값인 String(여기선 discountCode라는 문자열로 특정)로 구현체를 선택한다. 이를 통해 맵의 key값에 스프링 빈 이름이 저장되는 것을 알 수 있고 원하는 것을 파라미터로 넘겨서 선택하는 것도 가능하다는 것을 알 수 있다.
[SpringCore] 조회한 빈이 모두 필요할때(동적으로 선택이 필요할 때)

구현체가 2개인 상황

DiscountPolicy는 고정 할인인 FixDiscountPolicy, 비율 할인인 RateDiscountPolicy 처럼 구현체가 2개가 있으며 계획에 따라 선택하여 사용하고 있다.
하지만 이처럼 두 클래스 모두 @Component를 명시하게 되면 @ComponentScan에 의해 모두 스프링 빈으로 등록되면서 추상 클래스 DiscountPolicy를 호출하는 단계에서 스프링은 어떤 것을 선택 할 지 알 수 없게 된다.
여기서 서비스 코드에 직접 Fix 또는 Rate를 명시하면 DIP를 위반하면서 최상위 부모 또는 추상화를 주입해야되는 설계 원칙을 위반하게 된다.

@Qualifier 어노테이션으로 구분하기

각 구현체 클래스에 어노테이션으로 명시적으로 이름을 구분 할 수 있다.
다음처럼 어노테이션으로 이름을 지정해준다. 구현체를 호출하는 부분에서도 @Qualifier 를 통해 호출하고자 하는 빈을 특정하게 된다.
[SpringCore] @Qulifier 추가 탐색, @Primary 우선권 지정, 애너테이션을 직접 만들기

Lombok 라이브러리 주입

build.gradle 에 롬복 사용을 위해 외부 라이브러리 의존성을 추가해준다.

Lombok으로 리팩토링

OrderServiceImpl 부터 수정해본다. Lombok을 통해 많은 코드량을 줄여주지만 실제로는 class 파일에는 코드가 추가된다.

@RequiredArgsConstructor

해당 클래스의 final 필드를 포함한 생성자를 작성해준다.
기존코드
변경된 코드

@RequiredArgsConstructor vs @AllArgsConstructor

[SpringCore] 롬복을 활용한 리팩토링
Load more
　｜　Main Page　｜　Category　｜　 Tags　｜　About Me　｜　Contact　｜　Portfolio