Programming/TDD Project31 Pull Request 030. 바버샵 등록 기능 구현하기 - Slack WebHook 연동 및 비동기 이벤트 처리 해보기 + 계층 간 통신 고민하기 처음 구상에는 바버샵을 네이버 지도 같은 데에서 크롤링해서 한 번에 쫙 등록하는 걸 생각했다. 그런데 직접 네이버 지도에 바버샵을 검색해보니 샵마다 등록된 정보가 너무 제각각이더라, 데이터를 하나의 형태로 통합해서 저장하는게 어려워보였다. 그래서 일단 등록은 바버들이 마음대로 할 수 있도록 진행했다. 이렇게 진행하면 문제는 한 명의 바버가 너무 많은 샵을 등록할 수도 있고, 샵 자체를 장난으로 등록할 수도 있다. 따라서 서버측에서는 바버샵이 등록되었다는 정보를 알아야 할 필요가 있다. 이러한 문제를 해결하기 위해 일차원적인 해결 방안으로 서버측에 알람을 보내는 방법을 생각했다. Slack WebHook을 이용하면, 서버에서 발생한 상황을 Slack에 메세지로 전달하여 확인할 수 있다. 오늘은 바버샵을 .. 2024. 5. 20. Pull Request 029. Record를 적용한 리팩토링 진행하기 이번에 자바 버전을 21버전으로 마이그레이션 하면서, 기존에 사용하던 11버전과의 가장 큰 차이는 역시 Record의 도입이 아닐까 싶다. Record에 관한 자세한 설명은 밸덩의 아티클을 참조하면 좋을 것이다. 이번 포스트에서는 간단한 Record의 특징과 리팩토링에 어떻게 적용했는지를 다룰 예정이다. Record의 특징 Record의 가장 큰 특징이라면 모든 필드가 private final로 강제 선언되며, 해당 필드에 대한 getter가 주어진다는 것이다. 또한, equals(), hashCode(), toString()의 Object기본 메서드들이 자동으로 생성된다. 이러한 특징들을 바탕으로 어떤 형태의 Object들에 Record를 적용해보면 좋을지 고민해 보았다. Record는 어디에 쓰면 좋.. 2024. 4. 18. Pull Request 028. Spring Security + OAuth2.0 로그인 적용하기 최근 국내 서비스 중에 OAuth 로그인을 지원하지 않는 서비스가 있을까? 아마 거의 없을 것이다. 이번 프로젝트에도 OAuth2.0을 사용한 로그인 방식을 적용하고자 한다. OAuth 로그인은 쉽게 말해 '사용자 인증을 다른 기관에 맡기는' 로그인 방식이다. 운영중인 서비스의 서버에 저장된 사용자 정보가 아니라, 다른 신뢰할만한 서비스에 저장되어있는 사용자 정보를 가져와서 사용하는 방식이다. 물론, 해당 과정에서 자체적으로 토큰 발급 등의 인증 / 인가 시스템을 이용하기 위해서는 받아온 사용자 정보를 자체 서버에 저장해야한다. 이번 프로젝트에는 구글, 카카오, 네이버의 소셜 로그인을 제공할 예정이다. 현재 구글과 카카오를 구현 완료하였으며 이번 포스팅에서는 해당 과정을 다룬다. Spring Securi.. 2024. 1. 23. Pull Request 027. 로그인 / 로그아웃 로직 리팩토링하기 - Http Header 대신 Cookie를 사용해보자 이전 글에서 JWT의 적절한 사용 방법을 고민했었다. 그 결과 인증은 Stateful하게, 인가는 Stateless하게 사용하자!는 결론을 내렸다. 중복 로그인 방지나 로그아웃을 구현하기 위해서는 Stateful한 방식을 사용하는 것이 불가피했기 때문이다. 반면 인가는 어떤가? 상대방이 보낸 토큰이 내가 만든 토큰이 맞는지만 검증할 수 있으면 굳이 서버에서 어떤 토큰이 발급되었고, 만료 시간은 얼만지는 알 필요가 없다. 따라서 JWT가 지닌 Stateless한 성질을 야무지게 사용할 수 있다. 이 방식을 구현하기 위해 다른 분의 글을 참고하여 리팩토링을 진행했다. 이번 포스팅에서는 내 코드에서 수정된 부분만을 기록할 예정이며, 큰 틀은 링크를 타고 들어가 확인하길 바란다. 로그인 JwtAuthentica.. 2024. 1. 9. Pull Request 026. 자유 게시글 테스트 코드를 리팩토링하며 느낀 점 자유 게시글에 헥사고날 아키텍처를 적용하면서, 많은 클래스의 변동이 일어났다. 이에 맞춰 테스트 코드도 리팩토링해야 한다. 크게 달라진 것은 없다. 로직 자체가 많이 바뀌지 않았기 때문에, 테스트 코드 작성도 전과 비슷한 맥락에서 진행되었다. 그럼에도 가장 크게 느낀 점 몇 가지를 기록해보고자 한다. 먼저, DTO를 많이 사용하는만큼 테스트 코드의 길이가 길어졌다. 기존에는 하나의 DTO를 여러 계층에서 사용했기 때문에 테스트 코드에서도 많게는 2개, 적게는 1개 정도의 DTO만을 만들어서 사용했다. 그러나 Client -> API / API -> Client / API -> Application / Application -> API / Application -> Persistenct / Persist.. 2023. 12. 29. 이전 1 2 3 4 ··· 7 다음 반응형
