[인프런 워밍업 클럽 1기/BE] 세번째 발자국

인프런 워밍업 클럽1기 세번째 회고록 Day11: 기본적인 배포를 위한 준비 Day12: AWS와 EC2 배포 Day13: Spring Boot 설정, 버전업 Day14: 마무리[Day11] 기본적인 배포를 위한 준비 https://warp-fig-837.notion.site/Day11-847e0e87085d4dd897d3b38924dc9dd3?pvs=4배포가 무엇인지 이해하고, 배포를 하기 위한 준비 과정 중 profile 설정과 git/github에 대해 배울 수 있었다. 앞서 작성한 library application 코드에 profile을 적용해 local profile에서는 h2 DB를 , dev 환경에서는 MySQL 을 사용하도록 설정할 수 있었다. 배포란 무엇인가?최종 사용자에게 SW를 전달하는 과정= 전용 컴퓨터에 우리의 서버를 옮겨 실행시키는 것전용 컴퓨터에 코드를 옮기고 필요한 프로그램을 설치해 최종 사용자가 접속할 수 있도록 한다. profile동일한 서버 코드를 실행시키지만 실행 설정을 다르게 하고 싶을 때 profile을 사용한다 git과 githubgit코드를 쉽게 관리할 수 있도록 해주는 버전 관리 프로그램githubgit으로 관리되는 프로젝트의 코드가 저장되는 저장소 [Day12] AWS와 EC2 배포 AWS의 EC2를 이용해 서버를 배포하는 방법을 배울 수 있었다. 이전에 배포를 해보고 싶어서 AWS의 EC2를 사용해본 적이 있었는데, 무엇을 해야 하는지 여러 블로그를 참고해가며 진행하느라 시간이 오래 걸렸었다. 이번 강의를 통해 EC2 배포를 따라해보며 손쉽게 정돈된 절차를 익힐 수 있어서 유익했다. [Day13] Spring Boot 설정, 버전 업 https://warp-fig-837.notion.site/Day13-Spring-Boot-cc0fc9ac855546d591b4c4a1ff4d2ab9?pvs=4스프링과 스프링 부트는 무엇이 다른지 관계를 알아보았다. 그리고 스프링부트의 build.grale , application.yml 파일이 무엇이고, 어떤 역할을 하는지 문구를 하나씩 살펴보았다. 또한 lombok 어노테이션 도입해보면서 왜 해당 어노테이션을 사용하는지 이해할 수 있었다. Spring과 Spring bootSpring boot는 Spring에서 어떤 부분이 업그레이드 된 것일까?간편한 설정 → xml 대신 Java 어노테이션을 사용해 기본적인 설정들을 자동으로 해줌간단한 의존성 관리 → 의존성을 묶어 starter로 관리함강력한 확장성 → starter 추가만으로 원하는 기술 도입 가능내부 톰캣 내장 → 간단한 배포 과정MSA에 적합한 모니터링 build.gradle빌드 스크립트gradle을 이용해 프로젝트를 빌드하고 의존성을 관리하기 위해 작성한 파일 application.yml과 application.properties스프링부트 설정에는 application.yml or application.properties가 쓰인다 Lombok보일러 플레이트 코드(boiler plate code)의 번거로움을 해소하기 위해 사용getter, setter, 생성자, equals, toString을 자동으로 만들어줌 [Day14] 마무리워밍업 클럽 백엔드 스터디를 통해 스프링부트로 서버를 만들고 배포하는 전체적인 과정을 쉽고 빠르게 경험해 볼 수 있었다. 강의 진행 커리큘럼과 과제 제출 날짜가 정해져 있었기 때문에 미루거나 포기하는 일 없이 수강을 완료할 수 있었던 것 같다. 특히 2차례의 Live QnA가 정말 유익했는데, 앞으로 어떤 방향으로 공부해야 할 지 방향성을 잡는데 도움이 되었다.예전에 자바를 배운 적이 있어 무작정 스프링부트로 백엔드 공부를 시작한 상태였는데, 백엔드 개발자를 목표로 한 걸음 더 나아가려면 자바와 더 친해져야 할 것 같다고 느끼게 되었다. 우선 워밍업 미니 프로젝트를 어느 정도 마무리하면 자바 기초를 복습하고 좀 더 딥한 내용까지 살펴보려고 한다. 제출 과제 [과제6] Controller 역할 분리제출 결과물 https://warp-fig-837.notion.site/6-Controller-2866a79d18364be5b962d0e9ac355912?pvs=4이전 과제에서 작성한 코드를 Layered Architecture의 Controller, Service, Repository 에 맞춰 역할을 분리했다. @Primary나 @Qualifier 어노테이션을 사용해 두 가지 Repository를 교체해 사용하는 것을 연습해볼 수 있었다. [과제7] JPA 연습하기제출 결과물 https://warp-fig-837.notion.site/7-JPA-2bdf39802c02470e83204716819f3d00?pvs=4이전 과제에서 작성한 코드에 JPA를 도입하고 추가적인 API를 작성하는 과제였다. 과일의 개수를 세거나 특정 기준을 만족시키는 금액을 계산하는 API를 만들어보며 Spring Data JPA 의 쿼리 작성을 연습해볼 수 있었다.

[인프런 워밍업 클럽 1기/BE] 두번째 발자국

인프런 워밍업 클럽1기 두번째 회고록 Day06 : 스프링 컨테이너의 의미와 사용 방법Day07 : Spring Data JPA를 사용한 데이터베이스 조작Day08 : 트랜잭션과 영속성 컨텍스트Day09 : 조금 더 복잡한 기능을 API로 구성하기Day10 : 객체지향과 JPA 연관관계 [Day06] 스프링 컨테이너의 의미와 사용 방법 스프링 컨테이너와 빈?스프링 컨테이너서버가 시작될 때 스프링 서버 내부에 만들어지는 컨테이너컨테이너 내부에 클래스가 들어가게 된다스프링 빈스프링 컨테이너 내부로 들어간 클래스빈을 식별할 수 있는 이름, 타입 등 다양한 정보가 저장되고 인스턴스화된다 스프링 컨테이너 사용 이유Service의 코드를 변경하지 않고 Repository만 갈아 끼울 수 있다제어의 역전(IoC; Inversion of Control)컨테이너가 대신 인스턴스화 하고, 그 때 알아서 결정해준다컨테이너가 Repository 구현체 중 하나를 선택해 Service를 만들어준다의존성 주입(DI; Dependency Injection)컨테이너가 Service를 인스턴스화 할 때 Repository 중 하나를 선택해 넣어주는 과정 스프링 빈 다루기@Configuration : 클래스에 붙이는 어노테이션, @Bean 과 함께 사용@Bean :메소드에 붙이는 어노테이션, 반환 객체를 스프링 빈에 등록@ComponentRestController, Service, Repository, Configuration은 모두 Component를 가짐해당 어노테이션이 붙은 클래스를 스프링 서버가 뜰 때 자동 감지@Primary : 의존성 주입에서 우선권을 결정하는 어노테이션@Qualifier의존성을 주입 받는 쪽에서 특정 스프링 빈을 선택할 수 있도록 한다스프링 빈을 사용하는 쪽/등록하는 쪽 모두 사용 가능 → Qualifier 어노테이션에 적어준 값이 같은 것끼리 연결된다@Qualifier 가 @Primary 보다 우선순위가 높다 [Day07] Spring Data JPA를 사용한 데이터베이스 조작 SQL 직접 작성의 한계점작성 실수를 인지하는 시점이 느리다(런타임에 발견된다)특정 데이터베이스에 종속적이다반복 작업테이블과 객체의 패러다임 차이이런 문제점을 해소하기 위해 등장한 것이 JPA (Java Persistence API) 이다 JPA자바 진영의 ORM객체와 관계형DB를 짝지어 데이터를 영구적으로 저장할 수 있도록 정해진 Java 진영 규칙 HibernateJPA의 구현체 프레임워크 → JPA는 인터페이스이므로 실질적인 구현 코드가 필요하다내부적으로 JDBC를 사용 Spring Data JPA복잡한 JPA 코드를 스프링에서 쉽게 사용할 수 있도록 도와주는 라이브러리SQL을 작성하지 않아도 쿼리가 나갈 수 있도록 자동으로 처리해준다 [Day08] 트랜잭션과 영속성 컨텍스트 트랜잭션쪼갤 수 없는 업무의 최소 단위모든 SQL을 성공시키거나(commit) / 하나라도 실패하면 모두 실패시킨다(rollback)@Transactional 어노테이션을 대상 메서드에 붙여 적용한다 영속성 컨텍스트테이블과 매핑된 Entity 객체를 관리/보관하는 역할트랜잭션 사용 → 영속성 컨텍스트 생성트랜잭션 종료 → 영속성 컨텍스트 종료 영속성 컨텍스트의 능력변경 감지(Dirty Check) 영속성 컨텍스트 내의 Entity는 명시적 save가 없어도 변경을 감지해 자동으로 저장된다쓰기 지연(Lazy Loading)DB의 INSERT/UPDATE/DELETE SQL을 그때그때 날리지 않고 트랜잭션이 commit 될 때 모아서 한 번만 날린다통신 횟수가 줄어드는 이점1차 캐싱조회 요청이 올 때 우선 1차 캐시에서 데이터를 찾는다만약 1차 캐시에 데이터가 있으면 → DB를 찾아보지 않고 바로 반환만약 1차 캐시에 데이터가 없다면 → DB에서 데이터를 찾고 1차 캐시에 저장 후 반환 [Day09] 조금 더 복잡한 기능을 API로 구성하기 도서를 생성, 대출, 반납하는 API를 만들어보며 이전에 배운 것들을 익힐 수 있었다.book, user_loan_history 테이블 설계 및 추가테이블에 맞춰 객체를 만들어준다DTO, Controller, Service 구현 HTTP Body 스펙이 동일할 때, DTO를 새로 만들어야 할까?→ 새로 만드는 것이 좋다→ 한쪽의 기능에 변화가 생겼을 때 side-effect 없이 대처할 수 있기 때문! [Day10] 객체지향과 JPA 연관관계 객체 지향적으로Service에서 UserLoanHistory에 접근하던 기존의 구조→ User 에서 UserLoanHistory를 가져와 처리하도록 바꾸고 싶다→ User와 UserLoanHistory는 서로를 알고 있어야 한다 연관 관계@ManyToOneN : 1 의 관계를 표현하기 위해 사용하는 어노테이션1명의 사람이 여러 개의 대출 기록을 가질 수 있다 → UserLoanHistory와 User 의 관계는 N : 1단방향으로만 활용 가능하다UserLoanHistory에서 User로 접근할 수 있다User에서 UserLoanHistory로 접근할 수 없다@OneToMany1 : N 의 관계를 표현하기 위해 사용하는 어노테이션mappedBy 옵션: 연관관계의 주인이 아님 → JPA에게 알려주기 위해 필요한 옵션@OneToOne1 : 1 의 관계를 표현하기 위해 사용하는 어노테이션@ManyToManyN : M 의 관계를 표현하기 위해 사용하는 어노테이션직관적이지 않으므로 사용하지 않는 것을 추천 연관관계의 주인객체가 연결되는 기준 → 연관관계의 주인을 기준으로 테이블이 연결된다Table을 보았을 때 관계의 주도권(FK)을 가지고 있는 쪽을 의미한다User와 UserLoanHistory의 테이블을 보면 UserLoanHistory가 FK를 가지고 있다연관관계의 주인은 UserLoanHistory연관 관계의 주인이 아닌 User에 mappedBy 옵션을 달아주어야 한다주인을 통해 객체를 이어줬을 때 즉시 반대쪽이 이어지는 것은 아니다(주의)하나의 setter 안에서 객체를 완전히 연결 시켜 해결할 수 있다 옵션cascadecascade = “폭포처럼 흐르다”객체가 저장되거나 삭제될 때, 연관 관계에 놓인 테이블까지 함께 저장되거나 삭제됨orphanRemovalorphan = “고아” + removal = “제거”연관관계가 끊어진 데이터를 자동으로 제거 지연 로딩영속성 컨텍스트의 4번째 능력이다예시: User와 UserLoanHistory는 연관관계이다User를 가져올 때, UserLoanHistory 를 필요할 때 가져온다fetch 옵션LAZY : 꼭 필요할 때 가져온다EAGER : 처음 데이터를 로딩할 때 바로 가져온다 제출 과제 [과제4] 과일 가게 API제출물 :https://warp-fig-837.notion.site/4-API-cdb1a87c4c1844bab92ed2af71f247e2?pvs=4API의 요청에 따라 MySQL DB에 데이터를 저장하고 데이터를 가져오는 것을 연습할 수 있었다. Controller에서 SQL을 작성해 jdbcTemplate로 전달하도록 구현된 상태이다. [과제5] 클린 코드 적용하기제출물 :https://warp-fig-837.notion.site/5-e53bf1459ff84cc594907426b1e359d9?pvs=4과제 5를 바탕으로 깜짝 라이브가 있었다. 라이브의 핵심 내용을 요약하자면 다음과 같다.리팩토링 전 가장 먼저 테스트 코드를 준비해야 한다테스트 코드를 작성하기 어려운 구조라면, 테스트 코드 작성을 위한 준비부터 해야 한다(Point!) 테스트를 작성하려고 노력하면 자연스럽게 좋은 구조가 나올 확률이 올라간다과제 5를 진행하며 테스트 코드에 대한 생각은 하지 않았기 때문에… 과제 5의 코드를 바탕으로 실제 테스트코드를 작성하고 리팩토링 하는 과정을 살펴보며 얻어가는 부분이 많았다. 특히 랜덤 부분을 테스트하기 위해 NumberGenerator라는 인터페이스를 생성하고 인터페이스를 inplements하는 RandomNumberGenerator를 만들었던 부분이 인상적이었다.

[인프런 워밍업 클럽 1기/BE] 첫번째 발자국

인프런 워밍업 클럽1기 첫번째 회고록 최근 스프링과 자바를 독학하고 있었는데, 강의를 듣기 위해 인프런 사이트에 접속했을 때 눈에 들어온 것이 바로 워밍업 클럽 스터디 모집 게시글이었다. 공통의 목표를 가진 사람들과 함께 공부하면 혼자 공부할 때 보다 의욕이 생길 것 같아 고민하지 않고 바로 신청했다.강의 커리큘럼에 스프링 프로젝트를 개발은 물론 배포까지 포함되어 있다는 점이 특히 마음에 들었다. 간단한 프로젝트의 배포를 해 본 적이 있지만 여러 블로그들을 참고하며 이 방법이 맞는지 확신은 없는 상태에서 일단 돌아간다!! 뭔가 된다!! 라는 느낌의 배포였기 때문에… 이번 스터디를 통해 스프링 프로젝트의 전체적인 개발 흐름을 파악하는 것이 목표이다. Section 0 - 소개와 준비강의 소개와 자료를 포함해 강의에 대한 전반적인 설명이 담긴 파트였다.프로그램 공부를 시작할 때 개발 도구 설치 과정에서 막히기 시작하면 슬며시 포기하고 싶어지는 마음이 들기 마련이다. 웹 개발이나 스프링부트를 처음 접하는 사람들을 위해 프로그램 설치 과정이 상세히 담긴 영상이 준비되어 있었다. 천천히 따라하면 해당 강의에서 사용하는 프로그래밍 도구(Java, IntelliJ, PostMan, MySQL, git)를 손쉽게 설치할 수 있을 것이다. Section 1 - 생애 최초 API 만들기 Java를 공부하기 전에 알아두면 좋을 것들스프링 프로젝트를 본격적으로 시작하기에 앞서 Java에 대한 영상이 준비되어 있었다.첫 번째 영상에서는 Java의 JDK, JRE, JVM에 대한 설명이 담겨있었다.JDK: Java Development Kit = JRE + 개발을 위한 도구(컴파일러, 디버그 도구)JRE: Java Runtime Environment = JVM + 실행에 필요한 라이브러리JVM: Java Virtual Machine = 자바 가상머신, 바이너리 코드를 읽고 검증하고 실행함두 번째 영상에서는 빌드가 무엇인지, Java의 대표적인 빌드 도구에는 어떤 것이 있는지 알 수 있었다.빌드: 소스코드 파일을 컴퓨터에서 실행할 수 있는 독립적 SW로 변환시키는 과정Java 빌드 도구: ANT, Maven, Gradle해당 강의에서는 Gradle을 사용한다 서버 실행과 어노테이션본격적인 스프링 강의는 스프링 프로젝트의 서버를 실행시켜 보는 것으로 시작되었다. @SpringApplication 어노테이션과 main 메소드에 대해 알아보았으며, 1주차 과제로 어노테이션에 대한 추가적인 공부를 수행하였다.[인프런 워밍업 클럽1기 BE] Java 커스텀 어노테이션 만들기 네트워크다음으로 네트워크에 대해 배운다. 서버란, 어떠한 기능을 제공하는 프로그램 또는 그 프로그램을 실행시키는 컴퓨터이며 우리는 컴퓨터에 요청을 보내기 위해 인터넷, 네트워크를 사용한다. 백엔드 개발을 위해 네트워크 이론은 꼭 필요한 내용이라는 생각이 들었다. HTTP와 API컴퓨터간 HTTP와 API 통신 방식에 대해 배운다.컴퓨터 간 통신은 HTTP라는 표준화된 규약을 통해 이루어진다.HTTP 요청의 핵심은 method와 path이다.요청에서 데이터를 전달하는 방식에는 쿼리와 바디 방식이 있다.HTTP 응답의 핵심은 상태코드이다.클라이언트와 서버는 HTTP를 주고받으며 기능하고, 이때 정해진 규칙이 API이다. API 개발하기2개의 수를 전달 받아 덧셈, 곱셈 결과를 응답하는 API사용자를 저장, 조회, 수정, 삭제하는 CRUD API위와 같은 활동을 통해 API를 만드는 방법을 배웠다. 처음에는 파라미터로 요청을 받고 응답하던 코드에 DTO를 도입해보면서 DTO의 사용 이유와 방법을 배울 수 있어 좋았다. 또한 과제2를 통해 추가적인 GET, POST API를 구현해보면서 복습할 수 있어 도움이 되었다.과제 2 - API 만들기(GET, POST) Section 2 - 생애 최초 Database 조작하기 Database의 필요성Section1의 활동으로 만든 API에는 문제점이 있었는데, 바로 서버를 종료하면 저장했던 데이터가 사라진다는 점이었다. 서버가 실행된 후의 API 동작 결과는 RAM(메모리)에 쓰여지기 때문에 서버는 Disk(장기기록장치)에 데이터를 저장해줘야 한다. 이때 Database를 사용해 데이터를 저장할 수 있다.Database는 데이터를 구조화 시켜 저장하며, 그 중 Relational Database는 데이터를 표처럼 구조화 시켜 저장한다. 우리가 사용할 MySQL은 대표적인 RDB이다. 데이터베이스를 조작하기 위해서 SQL을 사용해야 한다. MySQL 사용하기MySQL을 사용할 때 Workbench로 접속했었는데, 인텔리제이에서 바로 MySQL에 접근할 수 있다는 것을 알게 되었다. MySQL의 데이터 저장 구조를 포함해 데이터베이스 생성, 테이블 생성 및 삭제 명령어, 데이터 CRUD 명령어를 복습할 수 있어 좋았다. 스프링으로 Database 접근하기Spring 서버에서 MySQL에 접근하기 위해 관련 설정을 해주는 파일이 필요하다. properties 파일 방식도 있지만 개인적으로 yml 방식이 읽기 쉬워서 선호하는데, 강의도 yml으로 진행되었다. 자바 데이터베이스 커넥터에 대한 클래스인 JdbcTemplate로 SQL을 날리는 방식을 배울 수 있었다. 예외 처리존재하지 않는 사용자에 대해 요청이 올 경우에도 성공이라는 의미의 200 상태 코드가 전달되는 문제가 있었다. 따라서 사용자가 있는지 확인하는 코드를 추가해 만약 사용자가 없다면 예외를 던지도록 수정해 500 Error를 보내는 방식을 배웠다. Section 3 - 역할 분리 클린코드와 리팩토링 가이드함수: 최대한 작게 만들고 한 가지 일만 수행하는 것이 좋다클래스: 작아야 하며 하나의 책임만 가져야 한다 앞서 구현한 코드는 Controller에서 모든 동작을 수행하며 3가지 역할을 가지고 있었다.API의 진입 지점으로 HTTP Body를 객체로 변환한다유저의 유무를 확인해 예외 처리를 한다SQL을 통해 실제 DB와 통신을 담당한다 이렇게 하나의 기능이 한번에 구현되어 있으면 다음과 같은 문제점이 있다.동시에 여러 명이 수정할 수 없다읽고 이해하기 어렵다한 부분을 수정하면 전체에 영향이 갈 수 있다너무 큰 기능이라 테스트가 어렵다유지 보수성이 떨어진다 Controller의 역할을 Service, Repository 클래스로 분리해주었다. 클래스가 각자의 역할을 가지고 쌓인 구조를 Layered Architecture이라고 하며, DTO는 계층간 정보를 전달하는 역할을 한다. 계획표를 처음 보았을 때엔 여유롭게 수강 할 수 있을 것이라고 생각했는데, 다른 일정도 생겨서 생각보다 바쁘게 듣고 있다. 시간이 날 때마다 미리 강의를 들어야 할 것 같다.