일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- equals
- jpa
- docker
- AOP
- 열 속성
- static
- lambda
- 테스트 코드
- KEVISS
- 인덱스
- stream
- VUE
- 바이너리 카운팅
- hashcode
- Spring
- 재정의
- redis
- 조합
- cache
- 생성자 주입
- MSA
- SQL
- select_type
- java
- Test
- 필드 주입
- DI
- jwt
- DDL
- StringBuilder
- Today
- Total
목록전체 카테고리 (196)
백엔드 개발자 블로그
![](http://i1.daumcdn.net/thumb/C150x150.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/dxG4h3/btsG0GMSlc1/b063Tr3y5S4A5bGOSDJ6pK/img.png)
병렬처리를 이용한 이미지 리사이즈 개선을 통해 이미지 로딩문제를 개선한 경험을 작성해봤습니다.문제 상황1. 렌더링으로 인한 이미지 로드 지연사용자의 원본 이미지를 그대로 S3에 업로드해서 사용해왔습니다. 그렇다보니 네트워크 / 디바이스 성능에 따라 페이지 렌더링 되면서 이미지가 늦게 로드 되는 경우가 많았습니다. 2. 고화질 원본 이미지로 인한 이미지 로드 지연대부분 원본 이미지가 3MB이상인 고화질 이미지였기에 늦게 로드 되었습니다. 해결안1. 원본 이미지 경량화 (선택)현실적으로 지금 당장 빠르게 해결할 방법은 백엔드쪽에서 원본 이미지를 경량화하는 것입니다. 단, 페이지마다 사용하는 이미지 사이즈가 다르기 때문에 4가지 유형으로 리사이즈해서 프론트에서 적절한 유형의 리사이즈 이미지를 사용하도록 합시..
![](http://i1.daumcdn.net/thumb/C150x150.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/bwu8j2/btsG0u6wbNk/RcCjYCoD3dmTFixUgWrGN1/img.jpg)
Blocking | Non Blocking | Sync | Async 에 대해 알아봅시다.BLOCKING vs NON BLOCKING 제어권을 넘기는지 / 안넘기는지로 구분합니다.Blocking다른 주체의 작업이 시작되면 제어권이 넘어가기에 다른 작업이 끝날 때까지 기다립니다.Non Blocking제어권이 자신에게 있으므로 다른 추젝의 작업과 관련없이 자신의 작업을 합니다.SYNC vs ASYNC순서와 결과에 관심이 있는지 없는지로 판단합니다.Sync앞 작업 결과 반환이 있어야 다음 작업 시작이 가능합니다.ASync앞 작업 결과 반환이 없어도 다음 작업 시작이 가능합니다.조합해봅시다블럭킹 & 동기 호출한 함수(A)는 호출되는 함수(B)의 작업 결과에 관심이 있고, 제어권이 없기 때문에 호출되는 함수(B)..
![](http://i1.daumcdn.net/thumb/C150x150.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/YJj8S/btsGNanfvs5/wM9Y9Lu6zRkYRap6r2Zfxk/img.gif)
보통 사용자들은 인증으로 구글이나 카카오 로그인을 선호한다. 보안에 대한 신뢰도와 id, pwd를 일일히 기억하기 힘들기 때문이다. 이런 사용자들의 니즈를 파악하고 OAuth2를 사용하여 구글이나 카카오 로그인을 직접 구현해 보면서 글을 적어보았다. 용어 정리 Resource Owner : 개인 정보의 소유자를 말한다 (서비스 사용자) Resource Server : 개인 정보를 저장하고 있는 서버를 의미한다. (구글, 카카오, 네이버) Client : Resource Server로부터 인증을 받고자 하는 서버다. (우리가 개발중인 서비스의 서버) OAuth2 로그인 요청 처리 흐름 Resource Owner가 Client에 접근하기 위해 Resource Server의 로그인 창을 클릭한다. 로그인에 성..
![](http://i1.daumcdn.net/thumb/C150x150.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/eDHPCt/btsGNusdTjH/MMN3Nbqc0ZNhjvDkCkDz4K/img.png)
프로젝트를 진행하면서 Spring Security를 활용해서 회원 로그인/로그아웃 처리 과정을 구현 했었다. 당시 시간이 촉박하다는 핑계로 상세하게 들여다보지 않고 로그인이 되는 상세 처리 과정만 이해하고 넘어갔었다. 로그인 과정 로그인 시도 -> username, password 정보를 HTTP body로 전달 인증 관리 -> UserDetailsService에게 username을 전달하고 회원 상세정보를 요청 회원 DB에서 회원 조회 -> 조회된 정보를 UserDetails로 변환 인증 관리자가 인증 처리 -> UserDetailsService가 전달해준 UserDetails의 정보와 클라이언트가 시도한 username,password 일치 여부 확인 UserDetails의 password는 암호문이..