일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Stomp
- 운영체제
- springboot
- cs지식
- 소켓
- socket
- 자바
- OS
- 스프링소켓통신
- java
- Security
- 기술면접
- CS
- 채팅구현
- jwt
- 반효경
- rabbitmq
- JPA
- 스프링
- CS면접
- 자바문법
- spring
- 스프링부트
- Mock
- 테스트코드
- jwt토큰
- 단위테스트
- MongoDB
- 소켓통신
- 스프링시큐리티
- Today
- Total
목록spring (23)
Dev_Henry

최근 진행한 프로젝트는 '개인 경매 플랫폼' 이었다. 해당 서비스에서는 일반적으로 생각할 수 있는 '경매'도 물론 가능하고, '역경매'라는 서비스도 제공했다. '경매'는 다르게 말하면 '판매' 카테고리로 판매글을 올리고 경매시간이 되면 다른사람들이 경매에 참여할 수 있다. '역경매'는 반대로 '구매' 카테고리다. 구매하고싶은 물건을 올리면 다른사람들이 본인 물건을 어필하며 역경매가 진행된다. 이렇게 이번 서비스에서는 '판매'와 '구매'가 존재했고, 둘 모두 '거래'라는 공통점을 가지며 공통적으로 필요한 필드도 많이 존재했다. 중복이 많이 존재하면 공간의 낭비, 코드 중복, 개발자의 귀찮음 등 다양한 문제들이 생긴다. 문제를 인지를 했으니 이것을 어떻게 효율적이게 설계할지 고민해보았다. 위 사진은 프로젝트..

현재 deal은 image를 oneToMany로 가지고있음. public abstract class Deal { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private long id; @CreatedDate private LocalDateTime createTime; @LastModifiedDate private LocalDateTime updateTime; private String title; private String content; @ManyToOne(fetch = FetchType.LAZY) private Member writer; @Enumerated(EnumType.STRING) private Category category; @El..

1. 스웨거 springfox 사용 불가 -> springdoc 사용 문법도 조금 바뀜. 2. spring security 6.2이상에서 설정 방법 변경 public final class HttpSecurity extends AbstractConfiguredSecurityBuilder implements SecurityBuilder, HttpSecurityBuilder { . . public HttpSecurity cors(Customizer corsCustomizer) throws Exception { corsCustomizer.customize(getOrApply(new CorsConfigurer())); return HttpSecurity.this; } . . } HttpSecurity를 구성할때,..

스프링 프로젝트를 만들면 application.properties 혹은 yml 파일에 각종 설정 정보를 입력하게 된다. 이 정보에는 api key, db 접속정보 등 보안정보도 포함되기 때문에 그대로 Git과 같은 온라인상에 올려버리면 낭패를 겪게된다. 이런 문제를 해결하기 위한 방법으로는 암호화 라이브러리를 사용하여 암호화하는 방법과 해당 정보를 다른 파일로 분리하고 gitignore에 추가하는 방법이 있다. 나는 정보를 다른 파일로 분리하는 방법을 사용할 것이고 git에 공개된 설정파일에서도 대략적인 코드 구성을 파악하기 쉽도록 해당 '보안데이터' 만 분리 할 것이다. 스프링 프로젝트를 할 때 항상 properties만 사용했는데 이번에는 yml파일을 사용해보고싶어서 처음으로 시도했고 yml에서는 설..
우테코 프리코스를 진행하다보면 배워갈게 많다고 해서 프리코스를 진행중이다. 과제의 요구사항이 적다보니 1주차는 별 생각없이 구현을 했었는데 사람들을 보니 전부 MVC패턴으로 구현하고 있더라.. 그래서 2주차는 나도 좀 분리를 해서 작성했는데, 음 여전히 요구사항 자체가 별로 없다보니 굳이 잘게잘게 분리하는게 비효율적으로 느껴져서 적당한 크기로만 분리했었다. 그리고 이번 3주차 과제는 좀 더 본격적으로 분리를 하려고 했다. 분리를 하는김에 spring을 흉내내서 각각 객체들을 싱글톤으로 관리하고, 처음 프로젝트를 돌릴때 의존성 주입방식으로 생성해주면 더욱 효율성 좋고 유지보수가 편리하도록 만들 수 있을것 같아서, 이렇게 진행하려한다. 보통 싱글톤을 간단하게 구현하는 방식으로는 lazy initializat..

이제까지 프로젝트를 하면서 값을 주고 받을 때 다양한 방법으로 객체와 데이터를 매핑시켰다. 그런데 구체적으로 어떻게 매핑이 되는지 이해하지 못한 상태로 사용하다보니 종종 에러가 발생하는 경우가 있었기 때문에, 이에 대해서 공부해보려 한다. 우선 objectMapper와 modelMapper를 알아본 뒤에 아래에서 간단한 테스트도 진행해 보겠다. 우선 객체 데이터를 json으로 주고받을때 많이 사용하는 objectMapper. @RequestBody는 내부적으로 objectMapper를 사용한다. 스프링 부트에서는 기본적으로 jackson이 내장되어있고, 여기에 objectMapper클래스가 있다. 직렬화를 할때는 getter를 통해 필드 값을 알아내고 값을 내보낸다. 즉 getter가 필요하다. (맴버변..

이어서 controller의 테스트 코드를 작성해 보겠다. memberAccountController @ApiOperation(value = "회원가입") @PostMapping("/join") public ResponseEntity joinPOST(@Valid @RequestBody MemberJoinDTO memberJoinDTO){ memberService.join(memberJoinDTO); //return ResponseEntity.ok(ResultResponse.of(REGISTER_SUCCESS, true)); return ResponseEntity.status(HttpStatus.CREATED).body(ResultResponse.of(REGISTER_SUCCESS, true)); } 테스..

1편에 이어서 service의 테스트 코드를 만들어 보자. memberServiceImpl @slf4j @Service @RequiredArgsConstructor public class MemberServiceImpl implements MemberService{ private final AccountUtil accountUtil; private final ModelMapper modelMapper; private final MemberRepository memberRepository; private final PostRepository postRepository; private final ScrapRepository scrapRepository; private final PasswordEncoder ..

스프링부트를 이용하여 프로젝트를 하던중 1차 개발이 끝나고 2차 개발을 시작하기 전에 컨벤션에 맞지 않는 무분별한 네이밍과 깔금하지 못한 코드들을 리팩토링하는 과정을 먼저 거쳤다. 팀원 모두 스프링에 대한 이해도가 부족한 상태에서 처음 진행하는 프로젝트다보니 테스트코드를 작성할 여유도 없었고, 어떤식으로 작성하는지도 몰랐기 때문에 테스트코드 없이 postman을 이용해 직접 테스트하며 구현했었는데, 나중에 리팩토링을 하려니 문제가 생겼다. 기존 변수명,함수명, 클래스 구조 등이 바뀌다 보니 예상치 못한 에러가 많이 발생해서 어려움을 겪었는데 테스트코드가 있었다면 이 과정이 훨씬 편해졌을 것이란걸 알고서 테스트코드의 필요성을 느꼈다. 이런 이유로 spring mvc의 테스트 코드 작성법을 공부하고 조금씩 ..

+ 내용 추가 프론트에서 카카오 로그인 - 인가코드를 받는 부분까지 처리하고 인가코드를 백엔드에게 넘겨준 후에 나머지 처리하는 로직이 일반적으로 프론트와 백엔드가 분리되어있을 때 사용하는 방식은 맞지만 몇가지 문제가 더있었다. 프론트에서 웹뷰를 사용한다면 이런 로직으로 구현하는데 전혀 문제가 없고 주로 사용하는 방법이다. 그런데 우리 프론트는 flutter를 사용하고 있었고, flutter에서 카카오가 제공해주는 로그인 api를 사용하기 위한 방법은 두가지가 있다. 웹뷰에서 사용할 수 있는 redirect방식 네이티브에서 사용할 수 있도록 기능을 제공하는 sdk 아래에 구현한 내용은 일반적으로 1번 방식에서 가능한 방식이다. 네이티브에서 사용하는 sdk는 인가코드만 달랑 받아와서 따로 서버에 전달할 수 ..