분류 전체보기

REST와 GraphQL은 인터넷을 통한 데이터 교환을 위한 API를 설계하는 두 가지 접근 방식이다. REST를 사용하면 클라이언트 애플리케이션이 HTTP METHOD(GET, PUT, UPDATE, DELETE ..)를 사용하여 서버와 데이터를 교환할 수 있으며, 이는 인터넷의 표준 통신 프로토콜이다. 반면 GraphQL은 클라이언트 애플리케이션이 원격 서버로부터 데이터를 요청하는 방법에 대한 사양을 정의하는 API 쿼리 언어이다. REST와 GraphQL의 공통점 기반 통신 프로토콜이 HTTP 이다. 둘 다 유사한 데이터 형식을 지원하면 대부분 JSON이 사용된다. 모두 캐싱을 지원한다. REST와 GraphQL의 차이점 REST 요청 작동에 사용되는 요소는 다음과 같다. HTTP METHOD HT..

하나의 서비스를 만들때 빼놓을 수 없는것은 바로 '데이터베이스'이다. 데이터베이스가 없다면 우리는 정보를 어떻게 저장하고 유지하고 분석할 수 있을까? 이번 글에서는 어떤 서비스든 빼놓을 수 없는 '회원' 데이터베이스에 대해서 어떻게 짜는게 좋을지에 대해 글을 써보겠다. 그리고 겸해서 RDB와 NOSQL중에 어느 상황에서 선택하면 좋을지도 써보겠다. Member Table 내가 보통 회원 데이터베이스를 설계할 때는 이러한 정보는 주로 넣는다. Primary Key 용 id 로그인 아이디 (요새는 이메일을 로그인용 아이디로 쓴다.) 비밀번호 닉네임 권한 (ROLE) 생년월일 성별 핸드폰번호 가입일 어떤 테이블을 만들던 가장 고민하는 것은 "PK를 auto_increment로 두는게 가장 좋은 방식일까?" 이..

백엔드 개발자를 꿈꾸는 사람으로서 주로 스프링부트를 이용하여 개발을 한다. 그저 기능개발을 위해서라면 단순 구글링을 통해 어찌저찌 완성시킬 수 있지만 만든 후에 내 머릿속에 크게 남는게 없는 느낌이 든다. 글을 정리하며 머리속에 남겨보도록 하자. 사용자 인증(Authentication)과 권한 부여(Authorization) Authentication이라 불리는 인증은 말그대로 '인증'을 뜻한다. 예를 들어 클라이언트가 서비스를 이용하기 위해 '로그인'을 하는 과정이 해당된다. Authorization이라 불리는 인가(권한 부여)는 '인증' 단계를 거친 사용자에게 특정 리소스나 기능에 접근할 수 있는 권한을 부여하는 것이다. 예를 들어보면 사이트에 접속한 클라이언트가 특정 파일 또는 글에 접근하려 할 때..

나도 이런식으로 주입하고 싶었다. 근데 난 왜이래? 에러를 읽어보면 lombok의 Value를 쓴게 문제인거같다. 즉, import 잘못한것이다. 이렇게 lombok의 Value가 아닌 factory의 Value를 import 해주면 잘 작동되는걸 볼 수 있다.

스프링부트가 3.x 버전이 되면서 JavaEE 에서 JakartaEE로 변경된 걸 알고있을 것이다. 그렇기에 Java Mail APi를 사용함에 있어 build.gradle을 과거의 방식대로 하면 안된다. 스프링부트 3.x 이전의 방식 implementation 'javax.mail:javax.mail-api:1.6.2' 스프링부트 3.x 버전의 방식 implementation 'jakarta.mail:jakarta.mail-api:2.1.2' 스프링부트 3.x버전이 나오면서 이전 버전의 프로젝트들의 버전업을 할 때 신경써야 할것이 꽤나 많으니 주의하자.

그동안 잔디밭을 잘 가꾸지 않았었는데 문득 내가 커밋한 거에 비해 너무 휑한 잔디밭이 어이가 없었다... 이거 왜이러지? 결과부터 보자면 깃허브에 등록되어있는 이메일과 터미널상 저장되어있는 이메일이 서로 달라서 반영이 안됐던것 ...!!!! ㅠㅠㅠ 이것이 현재 내 Github에 등록되어있는 이메일 이다. 그리고 터미널에서 git config --list 이 명령어를 쳤을때 이렇게 터미널상에 등록되어있는 이메일이 나오는데 Github와 같아야 커밋이 반영 된다고 한다... 하하.. 터미널 상에서 이메일 변경을 위해 git config --global user.email "내 이메일 주소" 이 명령어를 실행해주었다. 해당 명령어는 global이 들어간만큼 내 로컬 환경 전반적으로 모두 적용된다. 그러므로 특..

JWT와 Redis를 이용한 클라이언트의 로그아웃 로직을 구현하던 도중 발생한 트러블이다. 간단하게 클라이언트가 로그아웃 요청을 보낼 경우 해당 클라이언트의 Header에서 AccessToken을 받아와 토큰을 이용해 RefreshToken을 블랙리스트에 등록하는 로직이다. 로그아웃 로직이 완성됐다고 생각하고 포스트맨으로 실행시켰을때 위의 사진에서 볼 수 있듯 500 서버에러가 발생하였다. 왜 이런 이유가 발생할까? 에러 로그를 슥 살펴보던 도중 "Member가 UserDetails로 cast 될 수 없다"는 로그를 발견함과 동시에 "loadByUser"쪽에서 문제가 발생한걸 확인해 볼 수 있었다. 이게 그 문제의 loadByUsername 메서드이다. 코드를 쓱 봤을때는 마지막에 (UserDetails..

https://www.acmicpc.net/problem/29160 29160번: 나의 FIFA 팀 가치는? 첫 번째 줄에 선수의 수 $N$과 $K$가 공백으로 구분되어 주어진다. $(0\leq N\leq 1\,000\,000;$ $1\leq K\leq 50\,000)$ 두 번째 줄부터 $N$개의 줄에 걸쳐 각 줄에 $i$번째 선수의 포지션 $P_{i}$, 선수 가치 $W_{i}$가 www.acmicpc.net 문제를 보자마자 떠올렸던 방식은 1. 포지션 번호가 11개니 총 11개의 List를 만들기 2. K년동안 List를 Sort하여 마지막 원소값을 빼주기 3. List 재정렬 4. List의 마지막 원소값을 모두 더해 정답 출력 이대로 코드를 짜다보니 11개의 List를 만들고있는 순간 현타가 와서..

어느덧 벌써 3주차를 회고하는 날이 되었다. (이미 프리코스는 끝났다. ㅋㅋ) 로또 미션을 진행하면서 고민했던 내용들에 대한, 얻었던 지식에 대한 이야기를 풀어나가고자 한다. 필요한 객체 객체지향은 말그대로 '객체'들의 소통으로 프로그램을 돌아가게 하는것이다. 그러니 객체지향스러운 프로그램을 만들기 위해선 제일 먼저 어떤 객체가 필요한지 파악하는건 자연스럽고 중요한 행동이다. 나는 코딩을 하기전 이렇게 낙서형식으로 필요한게 무엇인지 적어보는 과정을 필수적으로 진행한다. 내가 머리가 나쁜건지 머릿속에 있는 내용들이 도무지 정리가 안되기 때문에... 이렇게라도 정리를 해야 마음이 한결 편해진다. 자, 일단 객체들의 역할은 저기 적혀있는게 다다. 최대한 객체들에게 최소한(필수)의 역할만 하게 객체 설계를 해보..

오늘은 3주차가 끝난 날이다... 3주차에 치이고치여 이제서야 2주차 회고록을 남겨본다 🥲 2주차는 자동차 경주 미션이 있었다!! 문제를 딱 본 순간 "이번 주차도 지난 기수의 미션문제네?" 생각이 들었다. 아마 나머지 문제들도 지난 기수들과 똑같지 않을까 싶다.. (3주차도 똑같았다...!!) 이번 주차 또한 나만의 설계로 풀어나가고자 했다. 빠진 부분도 많지만 내가 직접 그려보며 프로그램이 어떻게 돌아가야 할지 간략하게 나타내보니 확실히 설계나 구현면에서 편했다. 객체 설계에서도 그림으로 나타내보았다. ㅋㅋㅋㅋ 지금보니 정리가 안된거같고 막 적어놓은거 같지만 구현측에서는 많이 도움이 된 그림이다 ^^,, 이렇게 프로그램의 전체 흐름과 객체들 사이의 흐름도를 그려보니 구현에 있어서 편리함을 가져간거 같..