Spring

📌 공통 관심사를 분리하자. 어플리케이션 전 영역에 걸쳐 사용되는 공통 업무에 관련된 코드를 모든 페이지마다 작성한다면 1) 중복된 코드가 많아진다. 2) 프로젝트 단위가 커질수록 서버에 부하를 줄 수 있다. 3) 유지, 보수가 쉽지 않다. 📌 필터와 인터셉터

Resolver는 ViewResolver만 알고 있었는데 따로 찾아보니 종류가 정말 많았다. 또 따로 Resolver만 찾으려하니 잘 검색도 되지 않아 계속 찾다보니 DispatcherServlet 전략 중에 포함된 속성들이라는 것을 알게 되었고, 이번엔 Resolve

들어가기 전에 정리 로그인 체크 기능을 구현하면서 필터와 인터페이스에 대해 조사한 적이 있었다. 그때 항상 같이 등장하던 것이 AOP였는데, 그 당시 이해하기 어려워서 (아직도 어려움😂) 일단 미뤄두었다가 이제 다시 정리해보려고 한다. 처음 들었을 땐 그냥 필터 같

저번 포스팅에서 AOP에 대한 정리를 했었다. 직접 사용해보면 더 기억에 잘 남고 이해도 잘 될 것 같아서 현재 진행하고 있는 프로젝트에 적용해보려고 했다.현재 로그인 여부를 체크하는 필터를 사용하고 있다. 필터와 인터셉터의 차이를 정리하면서 언급했듯이 보통 스프링에서

현재 모놀리스 구조에서 마이크로서비스 구조로 점진적 변화를 시도해보는 공부를 하고있다. api-gateway의 필요성을 느껴서 netfilx에서 만든 zuul을 적용하던 중 발생한 문제점에 대해 정리해두려고 한다. 현재 더 이상 서비스 되고 있지 않은 zuul을 선택

웹 애플리케이션과 싱글톤 싱글톤 패턴 싱글톤 컨테이너 싱글톤 방식의 주의점 @Configuration과 싱글톤 @Configuration과 바이트코드 조작의 마법 싱글톤 패턴 (Singleton Pattern) > 객체의 인스턴스가 오직 1개만 생성되는 패턴 싱글