[WIL] 항해 Chapter 03 (2022.07.08~2022.07.14)
Chapter 3 | 주특기 기본/심화
회원가입, 로그인, 댓글 작성/수정/삭제 기능이 추가된 나만의 항해 블로그 백엔드 서버 만들기
요구사항
1) 서비스 완성
, 2) AWS 배포
두 가지를 모두 완수해야 합니다.
1) 서비스 완성
- 프로젝트 구성
- Springboot 2.6.9 이하 버전으로 프로젝트를 생성하세요
- 현재 블로그, 강의자료 등 참조할 수 있는 레퍼런스들은 2.7미만에서 동작합니다. 2.7버전 이상에서 구현시 공식문서만 참조하여 구현하여야 합니다.
- jwt 를 사용하여 로그인, 회원 기능을 구현하세요
- 아래 요구사항에서 언급되는 토큰은 Jwt를 의미합니다.
- 회원 가입 API
- 닉네임, 비밀번호, 비밀번호 확인을 request에서 전달받기
- 닉네임은
최소 3자 이상, 알파벳 대소문자(a~z, A~Z), 숫자(0~9)
로 구성하기
- 비밀번호는
최소 4자 이상이며, 닉네임과 같은 값이 포함된 경우 회원가입에 실패
로 만들기
- 비밀번호 확인은 비밀번호와 정확하게 일치하기
- 데이터베이스에 존재하는 닉네임을 입력한 채 회원가입 버튼을 누른 경우 "중복된 닉네임입니다." 라는 에러메세지를 response에 포함하기
- 로그인 API
- 닉네임, 비밀번호를 request에서 전달받기
- 로그인 버튼을 누른 경우 닉네임과 비밀번호가 데이터베이스에 등록됐는지 확인한 뒤, 하나라도 맞지 않는 정보가 있다면 "닉네임 또는 패스워드를 확인해주세요"라는 에러 메세지를 response에 포함하기
- 로그인 검사
아래 API를 제외하고
모두 로그인 토큰을 전달한 경우만 정상 response를 전달받을 수 있도록 하기
- 회원가입 API
- 로그인 API
- 게시글 목록 조회 API
- 게시글 조회 API
- 댓글 목록 조회 API
- 로그인 토큰을 전달하지 않은 채로 로그인이 필요한 API를 호출한 경우 "로그인이 필요합니다." 라는 에러 메세지를 response에 포함하기
- 로그인 토큰을 전달한 채로 로그인 API 또는 회원가입 API를 호출한 경우 "이미 로그인이 되어있습니다."라는 에러 메세지를 response에 포함하기
- 댓글 목록 조회 API
- 로그인 토큰을 전달하지 않아도 댓글 목록 조회가 가능하도록 하기
- 조회하는 게시글에 작성된 모든 댓글을 목록 형식으로 response에 포함하기
- 제일 최근 작성된 댓글을 맨 위에 정렬하기
- 댓글 작성 API
- 로그인 토큰을 전달했을 때에만 댓글 작성이 가능하도록 하기
- 로그인 토큰을 전달하지 않은 채로 댓글 작성란을 누르면 "로그인이 필요한 기능입니다." 라는 에러 메세지를 response에 포함하기
- 댓글 내용란을 비워둔 채 API를 호출하면 "댓글 내용을 입력해주세요" 라는 에러 메세지를 response에 포함하기
- 댓글 수정 API
- 로그인 토큰에 해당하는 사용자가 작성한 댓글만 수정 가능하도록 하기
- API를 호출한 경우 기존 댓글의 내용을 새로 입력한 댓글 내용으로 바꾸기
- 댓글 삭제 API
- 로그인 토큰에 해당하는 사용자가 작성한 댓글만 삭제 가능하도록 하기
- 회원가입 테스트 코드 작성
- 회원가입시 구현한 아래 조건을 검사하는 테스트 코드를 작성하기
- 닉네임은
최소 3자 이상, 알파벳 대소문자(a~z, A~Z), 숫자(0~9)
로 이루어져 있어야 합니다.
- 비밀번호는
최소 4자 이상이며, 닉네임과 같은 값이 포함된 경우 회원가입에 실패
합니다.
- 비밀번호 확인은 비밀번호와 정확하게 일치해야 합니다.
- 데이터베이스에 존재하는 닉네임을 입력한 채 회원가입 버튼을 누른 경우 "중복된 닉네임입니다." 라는 에러 메세지를 response에 포함하기
- 테스트 코드 실행 시 실제로는 데이터베이스에 연결되지 않도록 하기
- 각 조건 별로 2개 이상의 테스트 케이스가 존재하도록 하기
+) 과제를 다 하셨다면?
- 내 블로그 글에 좋아요 기능 달기
- 로그인 토큰을 전달했을 때에만 좋아요 할 수 있게 하기
- 로그인 토큰에 해당하는 사용자가 좋아요 한 글에 한해서, 좋아요 취소 할 수 있게 하기
- 게시글 목록 조회시 글의 좋아요 갯수도 같이 표출하기
- 내 프로젝트에 swagger 적용해보기
- swagger란?
- Open Api Specification(OAS)를 위한 프레임워크 입니다. API들이 가지고 있는 스펙(spec)을 명세, 관리할 수 있으며, 백엔드와 프론트엔드가 협업할 때 사용할 수 있습니다!
2) AWS 배포
- RDS 연결
- EC2 배포
- Ubuntu EC2 를 구매한 뒤, 8080 포트와 80번 포트를 연결하여 포트 번호 없이도 서비스에 접속 가능하게 하기
HangHaeLog API 설계
HangHaeLog 데이터베이스 설계
결과물 링크
프로젝트 후기
ORM(Object Relational Mapping)
ORM이란
- 객체 지향 프로그래밍의 객체와 관계형 데이터베이스의 데이터를 매핑하는 기술
- 객체 지향 프로그래밍에서 사용할 수 있는 가상의 객체 지향 데이터베이스를 만들어 프로그래밍 코드와 데이터 연결
- SQL을 사용하지 않고도 DB의 데이터를 쉽게 객체로 만들어줌
ORM 장점
- 객체 지향적인 코드로 인해 더 직관적이고 비즈니스 로직에 좀 더 집중할 수 있게 도움
- 선언문, 할당, 종료 같은 부수적인 코드가 없거나 급격히 줄어듦
- 각종 객체에 대한 코드를 별도로 작성하기 때문에 코드의 가독성을 올려줌
- SQL의 절차적이고 순차적인 접근이 아닌 객체지향적인 접근으로 인해 생산성이 증가
- 재사용 및 유지보수의 편리성 증가
- ORM은 독립적으로 작성되어있고, 해당 객체들을 재활용 할 수 있음
- 때문에 모델에서 가공된 데이터를 컨트롤러에 의해 뷰와 합쳐지는 형태로 디자인 패턴을 견고하게 다지는데 유리
- 매핑정보가 명확하여, ERD를 보는 것에 대한 의존도를 낮출 수 있음
- DBMS에 대한 종속성이 줄어듦
- 대부분 ORM 솔루션은 DB에 종속적이지 않음
- 종속적이지 않다는것은 구현 방법뿐만 아니라 많은 솔루션에서 자료형 타입까지 유효
- 프로그래머는 Object에 집중함으로 극단적으로 DBMS를 교체하는 거대한 작업에도 비교적 적은 리스크와 시간이 소요됨
- 또한 자바에서 가공할경우 equals, hashCode의 오버라이드 같은 자바의 기능을 이용할 수 있고, 간결하고 빠른 가공이 가능
ORM 단점
- 완벽한 ORM 으로만 서비스를 구현하기가 어려움
- 사용하기는 편하지만 설계는 매우 신중하게 해야함
- 프로젝트의 복잡성이 커질경우 난이도 또한 올라갈 수 있음
- 잘못 구현된 경우에 속도 저하 및 심각할 경우 일관성이 무너지는 문제점이 생길 수 있음
- 일부 자주 사용되는 대형 쿼리는 속도를 위해 SP를 쓰는등 별도의 튜닝이 필요한 경우가 있음
- DBMS의 고유 기능을 이용하기 어려움
(하지만 이건 단점으로만 볼 수 없음 : 특정 DBMS의 고유기능을 이용하면 이식성이 저하됨)
- 프로시저가 많은 시스템에선 ORM의 객체 지향적인 장점을 활용하기 어려움
- 이미 프로시저가 많은 시스템에선 다시 객체로 바꿔야하며, 그 과정에서 생산성 저하나 리스크가 많이 발생할 수 있음
SQL(Structured Query Language)
SQL이란
- 관계형 데이터베이스 관리 시스템(RDBMS)의 데이터를 관리 및 처리하기 위해 설계된 특수목적의 프로그래밍 언어
- 관계형 데이터베이스 관리 시스템에서 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안됨
- MySQL, MariaDB, MSSQL, 오라클 등의 데이터베이스 관련 프로그램들이 SQL을 표준으로 채택
SQL 문법 종류
DDL(Data Definition Language, 데이터 정의 언어)
- 각 릴레이션을 정의하기 위해 사용하는 언어
- ex) CREATE, ALTER, DROP
DML(Data Manipulation Language, 데이터 조작 언어)
- 데이터를 추가/수정/삭제하기 위한, 즉 데이터 관리를 위한 언어
- ex) SELECT, INSERT, UPDATE, DELETE
DCL(Data Control Language, 데이터 제어 언어)
- 사용자 관리 및 사용자별로 릴레이션 또는 데이터를 관리하고 접근하는 권한을 다루기 위한 언어
- ex) GRANT, REVOKE
SQL 언어적 특성
- SQL은 대소문자를 가리지 않음
- 단, 서버 환경이나 DBMS 종류에 따라 데이터베이스 또는 필드명에 대해 대소문자를 구분하기도 함
- SQL 명령은 반드시 세미콜론(
;
)으로 끝나야 함
- 고유의 값은 따옴표(
""
)로 감싸줌
- ex)
SELECT * FROM EMP WHERE NAME = 'James';
- SQL에서 객체를 나타낼 때는 백틱(
``
)으로 감싸줌
- ex)
SELECT `COST`, `TYPE` FROM `INVOICE`;
- 주석은 일종의 도움말로, 주석처리된 문장은 프로그램에서 동작하지 않음
- 한 줄 주석은 문장 앞에
--
를 붙여서 사용
- ex)
-- SELECT * FROM EMP;
- 여러 줄 주석은
/* */
로 감싸줌
- ex)
/* SELECT * FROM EMP WHERE EMPID = (SELECT * FROM EMP WHERE NAME = '홍길동'; */
MVC(Model-View-Controller)
MVC패턴이란
- 애플리케이션 개발을 세 부분의 레이어로 구분해 처리하는 개발방법론
모델(Model)
- 애플리케이션이 무엇을 할 것인지 정의
- 내부 비즈니스 로직을 처리하기 위한 역할
- 데이터 저장소(DB)와 연동하여 사용자가 입력한 데이터나 사용자에게 출력할 데이터를 다룸
- 여러 개의 데이터 변경 작업을 하나의 작업으로 묶은 트랜잭션을 다루는 일도 함
- 다른 컴포넌트들에 대해 알지 못하며 자기 자신이 무엇을 수행하는지만 알고 있음
뷰(View)
- 사용자에게 결과를 화면(UI)로 보내줌
- 화면에 무엇을 보여주기 위한 역할
- Model이 처리한 데이터나 그 작업 결과를 가지고 사용자에게 출력할 화면을 만듦
- 다른 컴포넌트들에 대해 알지 못하며 자기 자신이 무엇을 수행하는지만 알고 있음
컨트롤러(Controller)
- Model과 View 사이에 있는 컴포넌트
- Model이 데이터를 어떻게 처리할지 알려주는 역할
- 클라이언트의 요청을 받으면 해당 요청에 대한 실제 업무를 수행하는 Model을 호출
- 클라이언트가 보낸 데이터가 있는 경우엔 모델을 호출할 때 전달하기 쉽게 적절히 가공하여 전달
- Model이 업무 수행을 완료하면 그 결과를 가지고 화면을 생성하도록 View에 전달
- 클라이언트의 요청에 대해 Model과 View를 결정하여 전달하는 일종의 조정자로서의 일을 함
- 다른 컴포넌트들에 대해 알고있으며 자기 자신 외에 Model과 View가 무엇을 수행하는지 알고 있음
MVC패턴 방식
Model 1
Model 2
MVC패턴 장점
- 비즈니스 로직과 UI 로직을 분리하여 유지보수를 독립적으로 수행 가능
- Model과 View가 다른 컴포넌트들에 종속되지 않아 애플리케이션의 확장성, 유연성에 유리
- 중복 코딩의 문제점 제거