이게 외 않되

웹 소켓은 웹에서 양 방향 통신을 지원하며, 그에 따른 실시간 서비스를 구현하기에 적합하다. HTTP의 한계 웹 소켓 이 전의 실시간 통신 방식으로는 폴링Polling, 롱 폴링(Long Polling) 방식이 있다. Polling방식은 브라우저가 일정 주기로 계속해서 HTTP요청을 보내는 방식이다. Long Polling방식은 HTTP요청을 보내고 서버에서 해당 요청을 일정 시간 대기 시키는 방식이다. 대기 시간 안에 업데이트가 된다면 그 때 클라이언트로 응답을 보낸 후, 전달받은 데이터를 처리 후 재요청을 시작하는 방식이다. 지금은 없지만, 네이버 실시간 검색어로 예를 들면 Polling방식은 사용자가 검색을 하고 그로 인해서 실시간 검색어의 데이터에 영향이 미치면 그때마다 실시간으로 반영이 되어야 ..

클론 코딩 프로젝트로 좀 웃기긴 하지만 StarCraftChatting을 클론 코딩해보았다. 사실 채팅 자체를 처음 구현해보는 것이라서 처음에는 좀 겁을 먹은 것이 사실이다. 같은 조원 분들 중 한분께서 채팅을 해보고 싶으시다고 의견을 내주셨는데 그 분께서 진행하시고 있는 사이드 프로젝트에 같이 참여중이신 분들 중에 채팅을 구현해보신 경험이 있으셔서 그 분의 깃허브를 참고해서 하면 어렵지 않을 것 같다고 하셨다. 그래서 처음에는 겁이 좀 났지만 좋은 레퍼런스도 있고 해서 도전해볼만한 가치는 충분하다고 생각했다. 그렇게 다른 분들도 다 좋다고 하셔서 채팅을 구현해보기로 했다. 채팅을 구현하는데에 있어서 다들 처음 해보는 경험이었기 때문에 채팅방을 생성하고, 구독하고, 채팅을 치는 과정이 복잡할 것 같다고 ..

프로젝트를 진행하느라 바빠다는 핑계로 블로그 쓰는걸 계속 미루게 된다. 미니 프로젝트를 진행하면서 사실 기술적인 부분에서는 프론트 분들이 인원이 적기도 해서 볼륨을 작게 가져가는 프로젝트라 많이 얻을게 없을 줄 알았다. 그런데 서버 작업을 끝내고, 프론트분들 작업하시는 동안 기다리면서 많을 것을 해보고 많은 것을 얻어가는 시간이었던 것 같다. 처음 해보는 테스트 코드나 여러 다른 기능들을 구현해보기도 했고, 처음 작업을 시작하면서 패키지 구조를 도메인 별로 나눠 보는 것(DDD), git flow 연습등을 해보면서 정말로 만족스러운 1주일이었다. 이 외에도 협업하면서도 정말 얻어가는게 많은 것 같다. 처음 해보는 협업인만큼 다 같이 배려하면서 진행을 했는데, 서로 요청을 어떻게 주고, 응답을 어떻게 줄지..

https://github.com/14-9 hanghae99-14-toy9 hanghae99-14-toy9 has 2 repositories available. Follow their code on GitHub. github.com https://deadpan-trombone-3c7.notion.site/MiniProject-WeLuvWine-69f2354bbc2d428581cb7aa36b718e1f MiniProject(WeLuvWine) 0. 항해99 14기 미니프로젝트 9조 - We Luv Wine deadpan-trombone-3c7.notion.site https://www.youtube.com/watch?v=dqBlUCRxxps&t=12s

미니 프로젝트를 시작했다. 팀원분들을 너무 잘만나서 내가 팀장이긴 한데 다들 알아서 너무 잘해주신다. 와인 데이터들을 크롤링 해와서 DB에 넣고 그걸 이용해서 와인에 리뷰를 달고 추천하기를 하면, 리뷰를 작성 수정 삭제를 할 수 있고, 추천하기 수를 기반으로 높은 순서대로 8개를 불러오고, 검색기능이 있는 와인 리뷰 사이트를 만드는 것을 주제로 잡았다. 사실 프론트분이 2분이고 백앤드 담당하시는 분들이 나 포함해서 4분인데, 프론트 분들 인원이 너무 적어서, 1주일동안 진행하는 미니 프로젝트를 너무 볼륨을 크게 가져갈 수 없다라고 생각해서, 처음 해보는 협업이라는 키워드에 초점을 두고 진행하기로 했다. 프론트 작업은 잘 모르겠지만 백 작업은 주특기 주차때 했던 기능들을 다시 연습해보는 느낌으로 진행 되고..

스프링 시큐리티에 대해서 잘못 이해하고 있었다. 리프레시 토큰을 적용하고서 인증이 필요 없는 요청은 굳이 필터를 거치지 않게 하고 싶어서 방법을 알아보다가 결국 필터를 안거치게 하는건 불가능하는 것을 알게 되었다. 그리고 애초에 필터를 거쳐서 인증 객체가 생성되었을 때 config에 있는 설정을 통과시켜주고, permitAll이면 인증 객체가 생성되지 않아도 통과시켜주는 것인데, 나는 permitAll이면 그냥 필터도 안거치는 것으로 이해하고 있었다. 그래서 리프레시 토큰을 처음 적용했을 때 내가 로직을 잘못 짰는지 인증이 필요 없는 요청도 내가 설정한 엑세스 토큰이 만료되었다는 응답이 나오는게 문제였다. 위에 있는 내용을 몰랐어서 발생한 문제였는데, 디버그를 찍어보니 필터를 도는 것을 확인 할 수 있었..

이번주에는 스프링주차 레벨 5 과제 했던 코드에여러 기능을 붙여보았다. 원래 빨리 끝내고 같이 끝낸 분들이랑 작은 프로젝트를 해보고 싶었는데, 프론트를 구하지 못해서 무산되었다. 백엔드끼리 하면 되지 않겠냐 싶겠지만, 나는 프론트랑 연결해보는 경험을 해보고 싶었던 거라서 좀 아쉬웠다. 그래서 과제를 다끝낸 몇몇 분들과 다시 페어를 맺어서 여러 기능들을 붙여보는 작업을 했다. DB(MySQL)를 연결하고, RefreshToken, Swagger적용, 페이징, 검색기능, 로그아웃 기능 등을 해보았고, 틈틈히 자바와 스프링 공부도 했다. 로그아웃 기능을 해보면서 DB에 있는 RefreshToken을 지우는 것으로 구현을 했는데, 생각해보니 이렇게 하면, AccessToken은 만료되기 전까지 살아있는 것이 되..

스프링주차 과제리뷰 스터디에서 내 코드에 대해서 지적을 받았다. 좋아요 테이블 하나로 해서 게시글 좋아요와 댓글 좋아요 기능을 구현했는데, 좋아요가 있는지 확인하고, 취소하고, 갯수를 세는 코드를 게시글 좋아요와 댓글 좋아요에서 공용으로 사용했다. 그래서 게시글 좋아요는 댓글 좋아요와 겹치면 안되어서 게시글 좋아요를 확인할 때에는 댓글 아이디에 null값을 넣어서 체크를 했다. findByUserIdAndPostIdAndCommentId(user.getId(), postId, null); 이 코드에서 sql자체에서는 문법에 오류가 없기 때문에 결과로 오류를 반환하지 않지만, DB에서 게시글의 좋아요를 검색할 때 댓글의 아이디까지 검색해야해서, 한번의 검색당 한번의 오버헤드가 일어나고, 이는 N번의 검색당..

5레벨 과제를 리펙토링 하다가 빼먹고 구현하지 않은 기능을 발견했다. 좋아요가 DB에는 쌓이는데, 그게 게시글을 조회했을 때 좋아요 갯수가 0으로 나오게 되어있었다. 좋아요 생성 API에서는 반환할 때 DB에서 좋아요의 갯수를 세어서 반환하게끔 코드를 썼는데, 그게 게시글을 조회할 때의 반환값에는 적용되지 않는게 문제였다. https://github.com/been1118/springPrac-Board GitHub - been1118/springPrac-Board Contribute to been1118/springPrac-Board development by creating an account on GitHub. github.com 그래서 처음에는 Entity에 Repository 생성자 주입을 해줘서..

항해 주특기주차에서 레벨 3과제를 진행하면서 생겼던 고민이다. 레벨 3에서는 게시글에 댓글기능을 추가하는 내용이 있었다. 댓글을 추가하기 위해서 코드를 짜는데, 게시글과 댓글 사이에 무한재귀현상이 문제였다. https://github.com/been1118/springPrac2-jwt GitHub - been1118/springPrac2-jwt Contribute to been1118/springPrac2-jwt development by creating an account on GitHub. github.com 처음에는 뭐가 문제인지도 몰라서 페어분이랑 이 문제에 대해서 대략 6시간정도 고민했던 것 같다. 에러를 검색하고 찾아보고를 반복하면서 찾아낸 방법은 @JsonIgnore어노테이션을 사용하는 것이..

이번주는 내내 항해에서 준 강의를 듣고 과제를 하며 보낸 것 같다. 과제는 Lv.5까지 있는데, 1레벨 과제는 혼자하고 2레벨 과제부터 페어가 생겨서 같이 해결해나가는 형태의 과제이다. 2레벨과제를 끝내면, 끝낸 사람들 중에서 또 랜덤으로 페어가 맺어져서 3레벨 과제를 진행하고, 또 똑같이 4레벨, 5레벨 과제까지 진행하는 형태이다. 3주동안 진행하는데, 나는 5레벨까지 후딱 끝내고 남는 시간에 과제 리마인드도 하고, 자바공부도 따로 하기로 마음먹어서 속도를 내서 진행하고 있다. 토요일에 4레벨까지 끝냈다. 좀 급하게 달린 감이 있는데, 그래서 그런지 변명이지만 TIL 쓰는 것도 넘겼다. 진행한 과제는 내 깃헙을 참고하면 좋을 듯 하다. https://github.com/been1118/springPra..

오늘은 스프링주차 레벨 1 과제 한 내용을 리뷰해보았다. https://github.com/been1118/springPrac-crud PostService에서 게시글이 존재하지 않을때와 비밀호가 일치하지 않을 때 오류를 던지는 코드가 여러번 사용되어서 밑에 따로 메서드로 빼주었는데, 그 메서드를 다른 클래스로 분리를 해야할지 고민을 했었다. @Service @RequiredArgsConstructor public class PostService { private final PostRepository postRepository; @Transactional public ResponseDto createPost(PostRequestDto requestDto) { Post post = new Post(requ..

이번주에는 드디어 스프링 공부가 시작되었다. 아직 자바를 잘 다루지 못해서 좀 어지러운 감이 없지않아 있다. 스프링 공부를 시작하면서, 원래 하던 자바랑 시간 분배를 어떻게 해야할지 고민이 많았다. 1달 전쯤인가 뭣도 모르고 스프링 강의를 들었던 때에는 아무것도 이해 못하고, 막상 알아보면 자바개념이었고, 그랬었는데 객체지향 스터디를 하고나니 어느정도는 스프링이 뭔지 살짝씩 감이 오는 것 같다. 막상 스프링을 시작하고 나니, 스프링은 결국 자바라는 것을 느낄 수 있었고, 공부하는 시간을 나눠서 공부한다기보다는 능동적으로 스프링을 공부하다가 내가 모르는 자바 개념이 나오면 그때그때 찾아보기로 했다. 항해에서 내준 스프링주차의 1주차과제를 다 끝냈는데, https://github.com/been1118/sp..

Spring Framework로 웹 개발을 할 땐 기본적으로 MVC 패턴을 따른다. MVC 패턴은 Model, View, Controller 이 3가지로 나뉘어 역할을 분할하여 처리한다. 역할을 나누어 처리하기 때문에 서로의 결합도가 낮아져서 좋은 코드가 되며 유지보수도 하기 편해진다. Spring MVC Framework 구조를 공부하기 앞서 MVC 패턴의 방식과 개념에 대해 간략히 알아보도록 하자. MVC 패턴 MVC 패턴은 Model, View, Controller 개념이 합쳐지면서 생긴 방식으로 소프트웨어 공학에서 사용되는 디자인 패턴이다. 사용자의 Request를 Controller가 받고, Controller는 Business Logic을 처리를 Service와 같이 처리한 후 결과를 Mode..

HTTP란? Hyper Text Transmission Protocol의 약자이다. 클라이언트-서버 아키텍쳐에서 통신을 위해 사용되는 프로토콜의 하나이다. 현재 구현되어 있는 웹, 앱 등 대다수의 아키텍쳐는 이 HTTP 기반으로 구성되어있다. HTTP를 이해하기 위한, 인터넷 네트워크 기본 Internet Network 네트워크 상의 통신 규약 중 하나인 HTTP(Hyper Text Transmission Protocol)은 약속이다. IP (인터넷 프로토콜) 한계 비연결성: 패킷을 받을 대상이 없거나 대상이 불능이어도 패킷을 전송한다. 비신뢰성: 중간에 인터넷망에서 패킷이 사라져도 찾기 어려움/ 순서구분 어렵다. 프로그램 구분: IP만으로는 해당 서버에서 운영되는 프로그램이 둘 이상인 경우 구분이 어렵..