sung.hyun.1204 sung.hyun.1204

기존 프로젝트의 버전은 다음과 같습니다. SpringBoot 의 경우 버전 2.7 을 사용중이였고 , Java 의 경우 버전 17을 사용중이였습니다. plugins { id 'java' id 'org.springframework.boot' version '2.7.7' id 'io.spring.dependency-management' version '1.1.0' } group = 'woowahangongdol' version = '0.0.1-SNAPSHOT' sourceCompatibility = '17' ///gradle-7.6.1 Java 의 버전 선택에서는 다음 3가지는 필수로 존재하는 버전을 선택 하고자 했습니다. 1. Java 12 버전 에서 도입된 동적 Switch 문 2. Java 14 Dto..

배치란 일련의 작업을 한번에 수행하는 작업을 뜻한다고 한다. 1만건의 데이터를 생성한 후 한방 쿼리를 사용하여 데이터베이스에 저장을 하는 테스트 코드이다. @IntegrationTest public class FeedBulkInsertTest { @Autowired private FeedRepository feedRepository; @Test public void bulkInsert() { var easyRandom = FeedFixtureFactory.get( 4L, LocalDate.of(1998, 12, 1), LocalDate.of(2024, 2, 1) ); var stopWatch = new StopWatch(); stopWatch.start(); int _1만 = 10000; var post..

기존의 프로젝트를 진행을 하는데 있어 서비스 레이어는 다음과 같은 목적으로 작성을 하였다. 1. 어플리케이션에서 사용할 로직을 담당한다 . 2. 클라이언트의 인터페이스를 담당하는 컨트롤러 프랜제테이션 계층과 도메인의 비즈니스 로직을 담당하는 모델의 결합을 끊는 역할 3.Dto 매핑을 하는 역할. 4. 다른 도메인 , 루트 에그리거트의 접근을 제어하는 역할. 서비스는 데이터의 crud 와 관련된 로직을 제어 및 호출 하는 역할을 하였지만 하나의 모델과 관련된 기능이 늘어나면서 가독성이 떨어지고 하나의 클라스에서 담당하는 역할이 많아지면서 클라스의 목적이 모호해지는 현상이 생겼다. 추가적으로 , 조회를 위한 조회 성능을 위한 옵션을 설정한 트랜잭션이 자원을 생성하는 매서드 내부에서 호출 되면서 , 트랜잭션의..

도입 배경 기존의 프로젝트는 웹과 앱 모두를 지원을 하는 상황 , 유저의 로그인 인증여부를 firebase Auth 서비스를 사용하였다. 당시 한달이라는 개발 기간안에 Spring Security 까지 다룰 여력이 부족하여 Firebase Auth 를 사용한 시스템을 이용했다. Firebase Authentication 의경우 이메일 존재여부, 중복여부, 연락처 인증 등 다양한 기능을 지원하니 여력이 부족하면 사용하는 것을 추천한다. 대략적인 흐름은 다음과 같다. Client : 안드로이드 모바일 , 리엑트 웹 등 Firebase : Firebase Authentication service Resource Server : SpringBoot , Node server etc.. 클라이언트의 구글 로그인을 ..

공개된 장소 인 퍼블릭 깃허브에는 데이터 베이스의 정보나 aws 키를 유출하면 안된다. 이러한 사유로 .gitIgnore 를 사용해서 application.yml 전부를 제외를 시켰다. 운영 측면에서 민감한 정보를 가지는 부분 즉 비공개용 정보보다는 공개가 가능한 부분이 많아 환경 변수를 이용하여 관리하고자 한다. .gitIgnore 에는 application-credentials.yml 파일만 설정 하고 나머지 yml 은 전부 공개를 해도 되는 환경으로 변경하고자 한다. 기본 사용부터 보자. 데이테이스의 이름을 변수로 바꾸는 방법이다. 1. graddle 에 다음과 같이 추가 해주자. implementation 'org.springframework.boot:spring-boot-configuration..

프로젝트 중 경로를 잘못 입력했을때 500 에러가 나는 것을 확인 했다. api 를 설계하는데 있어 사용자에게 서버 로직에러인 500 에러를 알려주는것은 좋은 설계가 아니라고 한다. 이를 바꿔 보자. connection 을 확인하는 간단한 api의 코드이다. @RestController @RequestMapping("/test") @AllArgsConstructor public class ConnectionCheckApi { @GetMapping(value="/{test-number}") public ApiResponse getConnectTest(@PathVariable Long testNumber){ return ApiResponse.success(testNumber); } } 위와 같이 포스트맨을 ..

기존 코드의 설명을 하면 , 하단의 코드는 서비스 레이어이며 s3 이미지를 담당하는 모듈의 기능들이다. 퍼블릭 클라우드인 aws 의 객체 저장소인 s3 에 이미지 파일을 올리기 위하여 작성을 해온 코드이다. ... @Transactional(readOnly = true) @Service public class AwsS3ImageService { .. public String uploadImageOnly(MultipartFile file, String folderName) throws IOException { .. return amazonS3.getUrl(bucketName, key).toString(); } public List uploadImagesOnly(MultipartFile[] files, St..