eucis의 등록된 링크

키자드에 등록된 총 233개의 포스트를 확인하실 수 있습니다.

Naver Blog

이진트리 레벨탐색(BFS)

넓이우선탐색 넓이우선탐색(BFS)란 시작 정점으로부터 가까운 정점을 우선적으로 방문하고 멀리 떨어져 있는 정점을 나중에 방문하는 탐색 방법으로 다음과 같은 순서로 탐색이 진행된다. 시작 정점으로부터 가까운 정점을 우선적으로 방문한다는 것은 시작 정점과 연결된 간선의 수가 적다는 것을 의미하기 때문에, 트리의 낮은 레벨부터 마지막 레벨까지 순차적으로 정점을 방문하며 탐색을 진행하게 된다. public void BFS(Node root){ Queue<Node> Q=new LinkedList<>(); Q.add(root); int L=0; while(!Q.isEmpty()){ int len = Q.size(); System.out.print(L+" : "); for(int i=0; i<len; i++){ Node cur = Q.poll(); System.out.print(cur.data+" "); if(cur.lt!=null) Q.add(cur.lt); if(cur.rt!=null) Q.

Naver Blog

그래프와 인접행렬

무방향 그래프란 무방향 그래프는 그래프 이론에서 특정한 방향성이 없는 그래프를 의미합니다. 즉, 각 간선(엣지)이 두 노드를 연결하는데, 이 노드 간의 연결에는 방향성이 없습니다. 예를 들어, 노드 A와 노드 B가 있다고 하면, 노드 A에서 노드 B로 가는 연결과 노드 B에서 노드 A로 가는 연결이 동일하다는 것입니다. 이는 방향 그래프(혹은 유향 그래프)와 반대의 개념으로, 방향 그래프에서는 노드 간의 연결에 방향성이 있습니다. 무방향 그래프는 다양한 문제에서 유용하게 쓰이는데, 예를 들면 소셜 네트워크에서의 친구 관계나 전력 그리드에서의 전력 흐름 등에서 볼 수 있습니다. 방향그래프란 방향 그래프, 또는 유향 그래프(directed graph)는 각 간선(엣지)에 방향이 있는 그래프를 의미합니다. 이는 간선이 노드 A에서 노드 B로의 방향성을 가진다는 것을 나타내며, 이 경우에는 노드 B에서 노드 A로의 이동은 반드시 허용되는 것은 아닙니다. 즉, 방향 그래프에서 간선은 순서가

Naver Blog

일정 API 개발

협업 때문에 팀원은 회원정보 나는 일정 관련 API를 개발하기로 분담하였다. 항상 큰 틀로 만드는 클래스는 Request/Response, Controller, Repository, Servcie, ServiceImpl, DTO 클래스이다. 이번 프로젝트는 최대한 역할을 분리하여 계층마다 각자 역할을 모르도록 설계하는 것이 목표이다. 일정 추가 API 일정 추가의 경우 Method: POST URL: /schedule Request @Data public class RequestSaveSchedule { private String scheduleId; private Integer year; private Integer month; private Integer date; private String fromDate; private String toDate; private String where; private String memo; private Boolean closed; privat

Naver Blog

2023/09/19 코드리뷰

진행상황 팀원: 아이디 중복 검사/이메일 중복 검사/이메일 인증/이메일 인증 코드 입력/회원가입 성공 나: 월별 일정 정보/일별 간략 정보/일정 추가/일정 수정/일정 삭제 ISSUE(팀원) REDIS를 사용해 Email 인증을 로직을 구현했다. Redis에 익숙하지 않아 여러 질문들을 통해 새로운 내용을 학습할 수 있었다. Redis 레디스는 세계에서 가장 인기있는 Key-Value Store 중 하나이다. Remote Dictionary Server의 약자로, 원격 Dictinary 자료구조 서버 라는 직관적인 이름을 가지고 있다. Key로 올 수 있는 자료형은 기본적으로 String이지만, Value는 다양한 타입을 지원한다. 메모리 기반의 데이터베이스이기 때문에, Disk를 기반으로 하는 RDBMS보다 read가 빠르다. (RDBMS가 아닌 NoSQL인거 자체로도 RDBMS보다 빠를것이라 생각이 되는데 메모리 기반이라고 하니 속도 측면에서 훨씬 빠를것이라 생각됐다.) 이 Red

Naver Blog

일정 API 및 ERD 리펙토링

일정 추가/삭제/월별일정 조회/일별일정 조회 API와 관련되어 원래 구현은 현재 날짜/시작 시간/끝나는 시간 이렇게만 Entity를 구성하고 설계하였다. 시간 날짜/시간, 끝나는 날짜/시간으로 로직을 수정해야했고 이에 따라 ERD와 Request/Response/Service 코드 모두 수정해야했다. 아래는 UI인데 이래서 처음 ERD를 설계할때 꼼꼼하게 하고 개발에 들어가야한다 ... 일정 상세보기 API를 개발하려고 하던 찰나에 발견해버렸다.. Schedule Entity를 아래와 같이 수정하여 LocalDateTime으로 start와 end를 설정해주었다. (LocalDateTime 사용에 익숙하지 않아 연/월/일/시간을 시작/끝으로 전부 나눠서 Entity에 저장해야 하나 고민이 많았다...) 아래는 변경된 Schedule Entity와 ERD이다. LocalDateTime을 통해 start와 end 필드를 설정해주었다. /** * packageName : project.wh

Naver Blog

Service Discovery

Intro REST API를 이용해서 다른 서비스를 호출할 때는 다른 서비스 인스턴스가 있는 곳의 네트워크 정보를 알아야합니다. 그 정보는 IP주소와 포트 정보가 될 것입니다. 하지만 클라우드의 경우에 인스턴스는 동적으로 할당되기 때문에 IP주소와 포트정보가 바뀔 수 있고 오토스케일링 등 변화가 생길 때 네트워크 위치가 계속 바뀌게 됩니다. 따라서 클라이언트나 API 게이트웨이는 호출할 서비스를 찾는 매커니즘이 필요하고(서비스 등록, 검색) 이것을 서비스 디스커버리 라고 부릅니다. Service Discovery Service Discovery는 위의 사진과 같이 KEY에 어떤 서비스인지, VALUE에는 해당 서비스가 어디에 위치하고 있는지 값이 적혀있다고 합니다. 작동원리 각각의 서비스들은 Service Discovery에 서비스와 위치 정보를 등록합니다. 클라이언트는 Load Balancer 혹은 API Gateway를 통해 요청을 보냅니다. Load Balancer 혹은 API

Naver Blog

API Gateway Service

API Gateway Service의 역할 사용자가 설정한 라우팅 설정에 따라서 각각 엔드포인트로 클라이언트 대신해서 요청하고 응답을 받으면 다시 클라이언트에 전달해주는 프록시 역할을 하게됩니다. 시스템의 내부 구조는 숨기고 외부의 요청에 대해서 적절한 형태로 가공해서 응답할 수 있는 장점을 가지고 있습니다. 마이크로서비스가 3개가 있다고 가정했을 때 클라이언트 사이드에서 마이크로서비스를 직접호출하는 그림입니다. 클라이언트 측에서 마이크로서비스의 주소를 직접 입력해서 요청을 받고 응답을 받는다고 생각하면 됩니다. 만일 새로운 마이크로서비스가 추가되거나 기존에 있었던 마이크로서비스의 주소가 변경되거나 파라미터 인자값이 변경되었다고 했을 때 마이크로서비스 자체는 독립적으로 빌드되고 배포되기 때문에 문제가 없지만 클라이언트 사이드에서는 마이크로 서비스의 주소를 직접 이용해서 호출했었기 때문에 클라이언트 사이드도 같이 수정 배포가 되어야합니다. 그러다 보니 아래와 같이 단일 진입점을 가지고

Naver Blog

Spring Cloud Gateway - Filter

Spring Cloud Gateway에서 filter 적용 프로세스 클라이언트는 원하는 서비스를 호출하기 위해 Spring Cloud gateway로 요청을 보냅니다. 그리고 Spring Cloud gateway에서는 어떤 서비스로 가야하는지 분기처리를 해줍니다. 위의 점선 네모 박스는 Spring Cloud gateway안에서 일어나는 일을 확대한 것입니다. 우선 요청이 들어오면 Gateway Handler Mapping 을 통해 클라이언트로부터 어떤 요청이 들어왔는지 정보를 받고 요청에 대한 사전 조건을 분기해주는 곳이 Predicate입니다. 그후 사전 Filter와 사후 Filter를 통해 요청정보를 구성할 수 있습니다. Filter란? 디스패처 서블릿에 요청이 전달되기 전/후에 url 패턴에 맞는 모든 요청에 대해 부가작업을 처리할 수 있는 기능을 제공합니다. 필터는 스프링 범위 밖에서 처리가 됩니다. Filter 적용방법 filter를 적용하는 방법은 크게 2가지가 있습니

Naver Blog

일별 일정 상세 정보 API 개발

일별 일정 상세 정보 API Method: GET URL: /schedule/details Request @RequestParam String memberId, String scheduleId Response /** * packageName : project.whereareyou.vo.response.schedule * fileName : ResponseDetailSchedule * author : pjh57 * date : 2023-09-21 * description : 일별 일정 상세 정보 Response * =========================================================== * DATE AUTHOR NOTE * ----------------------------------------------------------- * 2023-09-21 pjh57 최초 생성 */ @Data @Builder @JsonInclude(JsonInclude.I

Naver Blog

Spring Cloud Gateway - Load Balancer

Load Balancer 로드 밸런서(Load Balancer)는 네트워크 트래픽이나 애플리케이션의 워크로드를 여러 서버나 리소스 간에 분산시키는 역할을 하는 장치나 소프트웨어를 말합니다. 로드 밸런싱은 시스템의 성능을 향상시키고, 가용성을 높이며, 자원의 중복 사용을 최소화하는 데 도움이 됩니다. 로드 밸런서의 주요 기능 및 장점은 다음과 같습니다: 효율성: 여러 서버 간에 트래픽을 균등하게 분산하여 한 서버에 과부하가 걸리는 것을 방지합니다. 높은 가용성: 한 서버가 실패하면 로드 밸런서는 트래픽을 여전히 동작 중인 다른 서버로 자동으로 리디렉션합니다. 확장성: 필요에 따라 서버를 추가하거나 제거할 수 있습니다. 로드 밸런서는 자동으로 새 서버를 인식하고 트래픽을 분산시킵니다. 유연성: 트래픽 분산 방식, 헬스 체크, 세션 유지 등 다양한 설정 옵션이 제공됩니다. 보안: 악의적인 트래픽이나 DDoS 공격을 방지하기 위한 보안 기능을 포함할 수 있습니다. 로드 밸런서는 크게 하드웨

Naver Blog

E-commerce 어플리케이션 개요 및 구성

E-commerce 애플리케이션 간단하게 세 가지의 마이크로 서비스를 만들어봅니다. CATALOG-SERVICE USER-SERVICE ORDER-SERVICE 전체적인 애플리케이션 구성 전체적인 애플리케이션 구성 구성요소 설명 Git Repository 마이크로서비스 소스 관리 및 프로파일 관리 Config Server Git 저장소에 등록된 프로파일 정보 및 설정 정보 Eureka Server 마이크로서비스 등록 및 검색 API Gateway Server 마이크로서비스 부하 분산 및 서비스 라우팅 Microservices 회원 MS, 주문 MS, 상품(카테고리) MS Queuing System 마이크로서비스 간 메시지 발행 및 구독 애플리케이션 APIs 마이크로서비스 RESTful API HTTP Method Catalog Service /catalog-service/catalogs : 상품 목록 제공 GET User Service /user-service/users : 사용자

Naver Blog

Users Microservice

Users Microservice 개요 APIs 기능 URI (API Gateway 사용시) URI (API Gateway 미사용 시) HTTP Method 사용자 정보 등록 /user-service/users /users POST 전체 사용자 조회 /user-service/users /users GET 사용자 정보, 주문 내역 조회 /user-service/users/{user_id} /users/{user_id} GET 작동 상태 확인 /user-service/users/health_check /users/health_check GET 환영 메시지 /user-service/users/welcome /users/welcome GET Users Microservice 프로젝트 생성 Lombok Spring Boot DevTools Spring Web Eureka Discovery Client 어플리케이션 클래스에 유레카 사용을 위한 어노테이션(@EnableDiscoveryClient

Naver Blog

2023/09/22 회의

월별 일정 정보 Response API 변경 해당 Response API에서 hasSchedule로 일정이 존재하는지 안하는지 여부 뿐 아니라 그 날에 몇개의 일정이 존재하는지까지 Response 할 수 있도록 수정 요청 해당 UI Design 기존 Response API { "year": "Integer", "month": "Integer", "schedules": [ { "date": 1, "hasSchedule": "Boolean" }, { "date": 2, "hasSchedule": "Boolean" }, { "date": 3, "hasSchedule": "Boolean" }, // ... (이하 생략, 4일부터 30일까지 객체들이 배열에 추가되어 있음) ] } Java Code .. MonthlyScheduleResponseDTO.java /** * packageName : project.whereareyou.dto * fileName : MonthlyScheduleRes

Naver Blog

월별 일정 정보 API 수정

2023/09/22 회의 내용에 따라 월별 일정 정보 API 수정 https://blog.naver.com/eucis/223221340277 2023/09/22 회의 월별 일정 정보 Response API 변경 해당 Response API에서 hasSchedule로 일정이 존재하는지 안하... blog.naver.com MonthlyScheduleResponseDTO /** * packageName : project.whereareyou.dto * fileName : MonthlyScheduleResponseDTO * author : pjh57 * date : 2023-09-17 * description : * =========================================================== * DATE AUTHOR NOTE * ----------------------------------------------------------- * 2023-09-17

Naver Blog

일정 수락 API 개발/일정 수정 JPQL 전환 리펙토링

일정 간략 정보 API Method: PUT URL: /schedule/accept Request /** * packageName : project.whereareyou.vo.request.schedule * fileName : RequestScheduleAccept * author : pjh57 * date : 2023-09-25 * description : 일정 수락 Request * =========================================================== * DATE AUTHOR NOTE * ----------------------------------------------------------- * 2023-09-25 pjh57 최초 생성 */ @Data public class RequestScheduleAccept { private String acceptMemberId; private String scheduleId; } Response

Naver Blog

JwtToken/RefreshToken 구현

Session/Cookies/Token Access Token(JWT)를 통한 인증 방식의 문제는 만일 제 3자에게 탈취당할 경우 보안에 취약하다. 유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편하다. 그러나 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 된다. “그러면 유효기간을 짧게 하면서 좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 "Refresh Token"인 것이다. Refresh Token은 Access Token과 똑같은 형태의 JWT이다. 처음에 로그인을 완료했을 때 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 발급해주는 열쇠가 된다. (여기서 만료라는 개념은 그냥 유효기간을 지났다는 의미) 예를들어, Refresh Token의 유효기간은 2주, Access Token의 유효기간은 1시간이라

Naver Blog

Catalogs and Orders Microservice

APIs 기능 마이크로서비스 URI 상품 목록 조회 Catalogs Microservice /catalog-service/catalogs 사용자 별 상품 주문 Orders Microservice /order-service/{user_id}/orders 사용자 별 주문 내역 조회 Orders Microservice {user_id}/orders 현재 상황 Catalogs Microservice Users Miroservice와 유사하기 때문에 코드만 구현 프로젝트 생성 패키지 정보 application.yml/data.sql server: port: 0 spring: application: name: catalog-service h2: console: enabled: true settings: web-allow-others: true path: /h2-console datasource: url: jdbc:h2:mem:test driver-class-name: org.h2.Driver

Naver Blog

Github Actions & Elastic Beanstalk

Github Actions를 통해 CI/CD를 Elastic Beanstalk을 통해 서버 환경을 구축할 예정이다. 간략한 아키텍처는 아래와 같이 구성될 것 같다. CI/CD 서비스 기능 개발 이후에는 빌드, 테스트, 소스 병합, 릴리즈, 배포라는 일련의 과정을 거친다. 하지만 이런 작업들은 생각보다 굉장히 번거로운 작업이며 프로젝트 규모가 클수록 괴로움은 증가한다. CI/CD는 Continuous Integration, Continuous Deliver, Continuous Deployment를 나타내는 용어이며 위 과정들을 자동화하여 불필요한 공수를 줄이고 보다 빠른 서비스 제공을 할 수 있는 효과를 가질 수 있다. CI/CD 구축을 지원하는 툴은 생각보다 많다. Jenkins Travis CI Circle CI Google Cloud Build AWS CodeBuild … Github Action이란? github action은 18년에 공개되어 베타 테스트를 거쳐 19년 부터

Naver Blog

Config Service

애플리케이션 개발에서 코드 내에 상수나 절대 경로를 직접 기입하는 것은 피해야 합니다. 이러한 값을 properties 같은 환경 변수에서 관리하는 것이 일반적입니다. 그러나 프로퍼티가 변경될 때마다 애플리케이션을 재배포하는 불편함이 있습니다. 특히 클라우드 환경에서는 여러 인스턴스가 실행 중일 때 모두 재실행해야 하는 상황이 발생할 수 있습니다. Spring Cloud Config는 이 문제를 해결하기 위한 도구입니다. 클라우드 환경에서의 MSA 애플리케이션 개발 시, 애플리케이션의 구성 정보를 중앙저장소(Git)에 보관하게 해줍니다. 이렇게 함으로써 애플리케이션과 그 구성 정보를 완전히 분리할 수 있습니다. 실행 중인 모든 애플리케이션 인스턴스는 시작 시 중앙저장소에서 해당 구성 정보를 가져올 수 있으며, 프로퍼티가 변경되면 중앙저장소에서 다시 해당 정보를 가져와 업데이트할 수 있습니다. Spring Cloud Config는 크게 두 가지 구성 요소가 존재한다. 1. Git 과

Naver Blog

일정 종료 API 개발

일정 종료 API Method: PUT URL: /schedule/closed Request @RequestParam private String creatorId; private String scheduleId; Response Status Code: 200 OK Exception 404 ScheduleNotFoundException: scheduleId Not Found 400 NotCreatedScheduleByMemberException: This is not a user-created schedule 401: Unauthorized (추후에 추가할 예정) 500 updateQueryException: update Fail 500: Server ScheduleController Controller에서 creatorId, scheduleId를 받아 Service 단으로 넘긴다. ..코드 생략 /** * 일정 종료 * * @param requestScheduleClosed the

Naver Blog

도착 여부 API 개발

도착 여부 API Method: PUT URL: /schedule/arrived Request @RequestParam private String arrivedMemberId; private String scheduleId; Response Status Code: 200 OK Exception 404 ScheduleNotFoundException: scheduleId Not Found 400 NotCreatedScheduleByMemberException: This is not a user-created schedule 401: Unauthorized (추후에 추가할 예정) 500 updateQueryException: update Fail 500: Server ScheduleController Controller에서 arrivedMemberId, scheduleId를 받아 Service 단으로 넘긴다. ..코드 생략 /** * 도착 여부 * * @param requestSchedu

Naver Blog

위도 경도 API 개발

사용자 위도 경도 API Method: POST URL: /info Request @RequestBody private String memberId; private Double latitude; private Double longitude; Response Status Code: 200 OK Exception 404 UserNotFoundException: memberId Not Found 401: Unauthorized (추후에 추가할 예정) 500 updateQueryException: update Fail 500: Server ScheduleController Controller에서 memberId, latitude, longitude를 받아 Service 단으로 넘긴다. 조건을 두개로 분리하였다. 만약 기존의 위도/경도 정보가 없을 경우 save로 insert 쿼리문을.. 만약 원래 있었다면 update 쿼리문으로 설정하였다. ..코드 생략 /** * 위도/경도 * * @pa

Naver Blog

검색 기록 API 개발

사용자 검색 기록 입력 API Method: POST URL: /search Request @RequestBody private String memberId; private String searchHistory; Response private String searchHistoryId; Exception 404 UserNotFoundException: memberId Not Found 401: Unauthorized (추후에 추가할 예정) 500: Server SearchHistoryController Controller에서 memberId, searchHistory를 받아 Service 단으로 넘긴다. ..코드 생략 /** * 사용자 검색 기록 입력 * * @param requestSearchHistory the request search history * @return the response entity */ @PostMapping() public ResponseEntity<Res

Naver Blog

친구요청 ERD에 대한 고찰

사용자는 다른 사용자에게 친구요청을 보낼 수 있고 사용자는 여러 명에게 친구요청을 받을 수 있다. 이러한 관점을 시작으로 Entity 설계에 있어 관계를 어떻게 해석해 나가야할지 잘 모르겠다.. 프로젝트에서 FriendRequest 테이블을 통해 친구요청한 사용자를 모아놓는 Entity를 따로 설계했었다. 물론 Member와 FriendRequest는 1:N 관계로 해석될 수 있다. (Member는 여러 요청을 보낼 수 있기 때문) 애초에 FriendRequest(친구 요청. 즉, 친구 신청을 보냈지만 친구 수락을 하지 않아 친구 요청 대기 목록에 들어 있는 테이블)을 만든 이유가 Friend라는 테이블에 boolean으로 친구 수락 여부를 확인할 수 있지만, 친구 전체 목록을 가져와야하는 API. 혹은 친구 목록을 이용하는 API를 개발할 때 for문을 통해 Friend 테이블을 훑으며 boolean의 여부를 확인해 다시 List로 만들어야 한다고 생각하기 때문에 FriendReq

Naver Blog

푸시알림

사용자가 일정을 생성하면 같이 일정에 들어올 친구들을 추가하게 된다. 이 때, 일정에 들어온 친구들의 위도/경도 정보를 통해 실시간 GPS로 위치를 확인할 수 있기 때문에 일정 추가 시 친구들에게 푸시알림을 보내 동의여부를 확인할 수 있도록 설계해야한다. 푸시 알림을 구현할때 프론트에서만 구현할 수 없는지 생각했었지만 서버가 꼭 필요한 문제인 것 같다. 푸시알림을 클라이언트에서 관리한다면 시간 동기화 문제가 가장 큰 것 같다. 시간 동기화 문제란 핸드폰을 임의적으로 조작해서 공지를 자기만의 시간에 받게 하거나 할 수 있다는 뜻이다. 즉, 서버를 통해 공지를 만드는게 확장성과 시간 동기화 문제로부터 자유로워지는 것이다. 스프링 자체에서 푸시알림을 구현해도 되지만 직접 만드는 것보다 구글에서 지원하는 메시징 서비스를 사용하는 것이 훨씬 편리하다. FCM: Firebase Cloud Messaging 1. 여기서 이야기 하는 토큰은 Client App을 켜면 각각 Client App을 구

Naver Blog

친구 그룹 ERD에 대한 고찰

친구 요청 ERD에 이어서 친구 그룹에 대한 ERD도 개발하는 단계에서 다시 생각해보니 잘못 설계되었다고 생각이 들었다. 이전의 ERD는 FriendGroup(친구 목록) - Member(회원)에 대한 ERD만 구축하고 @ManyToOne, @OneToMany로 양방향 연관관계 매핑을 해줬었다. 근데 한 명의 Member는 여러개의 Group을 가질 수 있고, 그 Group안에는 여러명의 Member가 들어갈 수 있다. 이전의 FriendGroup ERD는 아래와 같다. @Entity @Data @AllArgsConstructor @NoArgsConstructor @Builder public class FriendGroup { @Id @GeneratedValue(generator = "uuid2") @GenericGenerator( name = "uuid2", strategy = "org.hibernate.id.UUIDGenerator" ) @Column(name = "group_i

Naver Blog

Response 값에 대한 고찰

옛날부터 항상 의문이 있었던 문제였고 다른 FE 개발자들과 많은 이야기를 나누어 봤지만 결론이 나지 않았던 문제가 오늘 회의하면서 대두되었다. 데이터를 Response 값에 PK 값을 넘겨주어야하나. 완성된 데이터를 넘겨주어야하나 하는 문제였다. 완성된 데이터란 정말 필요한 데이터를 전부 Response로 받아 클라이언트에서 View로 띄워주기만 하면 되는 Response라고 생각하면 될 것 같다. 난 지금까지 PK 값을 넘겨주어 FE에서 한 번 더 API 통신을 하도록 항상 API 명세서를 짜왔고 프로젝트를 진행해왔다. 무슨 뜻인가 하면 아래와 같다. 만약 친구 목록을 불러오는 API가 있다고 가정해보면 Response에 두 가지의 경우가 있을 것이다. (Member Entity에는 단순히 nickName, name 두가지 항목만 있다고 가정) -- 첫번째 가능한 Response값. (위에서 이야기한 완성된 데이터) [ { "memberId": PK "nickName": "stri

Naver Blog

공유 일정으로 기능 확장

지금까지 일정을 만든 당사자만 볼 수 있도록 구현을 했었다. 그러나 오늘 회의하며 일정을 생성하면서 추가했던 친구들 또한 일정 초대를 수락하면 친구들도 일정을 같이 볼 수 있도록 코드를 리펙토링 해야 했다. 또한, 모든 일정은 Creator 즉, 일정을 만든 사람만 수정할 수 있도록 하였다. Schedule(일정 정보) - MemberSchedule(일정을 공유하는 Member) Entity에서 일정을 생성하면 Creator는 default로 accept를 true로 넣고 나머지 Member들은 일정을 수락하면 true로 변경하는 식으로 코드를 바꿨다. public ResponseSaveSchedule save(RequestSaveSchedule requestSaveSchedule) { /* 예외처리 404 UserNotFoundException: MemberId Not Found 400 FriendListNotFoundException: FriendListNot Found 400

Naver Blog

일정 거절 API 개발

일정 거절 API는 일정 생성자(Creator)가 일정을 생성할 때, 일정에 친구를 추가할 수 있다. 이때, 추가된 사용자는 해당 일정에 들어가고 싶지 않을때, 거절할 수 있는 기능이다. refuseSchedule 메소드를 구현하여 특정 사용자가 특정 일정에 대한 참여를 거부하고 해당 MemberSchedule 엔터티를 삭제하는 로직을 추가한다. 이 메소드는 RequestRefuseSchedule 객체를 매개변수로 받아, 주어진 refuseMemberId와 scheduleId에 해당하는 MemberSchedule을 찾아 삭제한다. /** * Refuse schedule. * * @param requestRefuseSchedule the request refuse schedule */ public void refuseSchedule(RequestRefuseSchedule requestRefuseSchedule){ // 거부하는 멤버 찾기 Member refuseMember = memb

Naver Blog

친구 그룹 API 개발

친구 그룹 생성 API 일정을 추가할 때, 친구를 추가하는 기능이 있기 때문에 미리 그룹을 지정하면 좋겠다 싶어 넣은 기능이다. UI 같은 경우는 아래와 같다. 먼저 Request와 Response 같은 경우는 아래와 같이 설정했다. Request { "naem": "String", "ownerId" : "String", "groupMemberId": [ "string" ] } Response { "groupId" : "String", } ERD 같은 경우도 일정과 같게 설계하였다. FriendGroup이라는 Entity에서 Group의 이름, 소유자등을 관리하고 FriendGroupMember에서 FriendGroup에 속하는 Member들을 관리하도록 설계하였다. 기본적인 Entity와 Repository의 설계는 아래와 같다. 그룹 추가 기능이기 때문에 따로 설계해야 할 것은 없지만 그룹 멤버를 추가할 때, Group을 먼저 생성하고 Group안에 있는 Member들을 추가하도

Naver Blog

일정(Schedule) API 리팩토링

개발이 끝나서 배포 과정 전까지 코드 리팩토링에 들어갈 생각이다. 리펙토링의 과정은 두 가지를 염두해서 리펙토링을 진행할 예정이다. 1. 하드코딩하지 않는다. Constant 변수로 뺄 수 있는건 다 빼도록 노력한다. 2. 메서드 하나당 하나의 역할만 하도록 분리한다. 일정 추가 API 리펙토링 기존의 일정 추가 API의 Service 같은 경우의 코드는 아래와 같다. /** * Save response save schedule. * * @param requestSaveSchedule the request save schedule * @return the response save schedule */ public ResponseSaveSchedule save(RequestSaveSchedule requestSaveSchedule) { Member creator = memberRepository.findById(requestSaveSchedule.getMemberId()) .orEls

Naver Blog

일정 회원 목록(MemberSchedule) API 리팩토링

MemberSchedule 같은 경우, Schedule이 공유 일정이기 때문에 MemberSchedule에서 Schedule에 들어있는 Member를 관리하는 DB이다. 스케줄 수락, 스케줄 거절 두 메서드만 있기 때문에 리팩토링하는데 오랜 시간이 들지 않았다. 스케줄 수락 API 리팩토링 기존의 스케줄 수락 API는 아래와 같다. 단순하게 Member와 Schedule을 가지고와 해당 MemberSchedule의 accept를 True로만 바꿔주면 된다. /** * Schedule accept. * * @param requestScheduleAccept the request schedule accept */ public void scheduleAccept(RequestScheduleAccept requestScheduleAccept){ Member acceptMember = memberRepository.findById(requestScheduleAccept.getAcceptMem

Naver Blog

회원 위치 정보(MemberInfo) API 리팩토링

앱 자체가 GPS 기반의 친구 위치 정보를 확인할 수 있기 때문에 사용자의 위도/경도를 관리하는 MemberInfo Entity가 필요했다. 이 Entity와 관련된 Service를 리팩토링할 계획인데, 사용자의 위도/경도를 저장, 가져오는 두 가지 API 밖에 없다. 사용자 위도/경도 저장 API 기존의 비즈니스 로직은 아래와 같다. 먼저 Request를 통해 Member를 가져온 후 MemberInfo Entity에 저장한다. 이때, 기존에 저장되어 있는 위도/경도 정보가 있다고 한다면 update쿼리문을 통해 위도/경도를 update해준다. 만약, 기존에 저장되어 있는 위도/경도 정보가 없으면 save 메서드를 통해 insert 쿼리를 날리게 된다. public void setMemberInfo(RequestMemberInfo requestMemberInfo){ memberRepository.findById(requestMemberInfo.getMemberId()) .orEls

1 2 3