블로그 이전 이전까지 세션과 인터셉터를 모두 개발 완료했다. 이제 매 요청 전 세션만 체크해주면 된다. 일단 해당 기능 적용 전 이전 글에서 Request 객체에 세션과 관련된 함수를 추가해주는 기능을 인터셉터로 변경해줬다. SessionManagerInterceptor 이렇게 매 요청마다 getSession(), removeSession()함수를 Request 객체에 정의해주는 함수를 호출하도록 인터셉터를 개발했다. ConfigLoader에 추가 ConfigLoader객체에서 loadInterceptorConfig()를 통해 이용자가 개발한 인터셉터를 등록하기 전 `load

블로그 이전 지난번 개발한 세션의 구조적인 변경을 진행했다. 이유는 현재 사내 프레임워크는 config.js라는 object에 필요한 정보들(DB host, port 등 과 같은 정보들)을 필드로 가지게 하고, 필요한 곳에서 모듈로 가져와 참조하는 방식을 사용했다. 그 중 Redis client와 관련된 정보도 있었다. 문제는 여기서 발생한다. 나는 config.js에 어떤 세션 스토어를 사용할지 명시할 계획이었으므로 개발자가 레디스 스토어를 사용하게 된다면 config.js에 와 같이 적히게 되고 RedisSessionStore.js는 와 같은 형태로 client를 생성하기 때문에 순환참조 문제가 발생한다. 이 외에도 많은 곳에서 config를 참조하게돼 구조적으로 좋지 않다고 생각했다. 일단 config.js 자체가 썩 좋아보이진 않았지만, 이미 만들어진 구조는

블로그 이전 HttpSession class 여러 세션 스토어에 저장될 세션 객체는 공통으로 사용하도록 구상하고 개발했다. 기본적으로 Map변수에 정보들을 key-value형태로 담고 꺼내도록 구상했다. SessionStore class interface로 추상-구현 관계를 사용하고 싶었지만 만들어진 프레임워크 자체가 TS를 지원하지 않아 어쩔수 없이 비슷하게 함수들을 선언하고 재정의 없이 호출하면 Error가 나도록 구현했다. 사실 JS 장점이라면 장점인 동적 프로그래밍으로 자료형을 정해주지 않아도 위 함수들이 구현되어 있다면 동작하는데는 문제가 없다. 하지만 전글에도 적었듯이 나는 서버는 신뢰성이 중요하다 생각해 상속을 하면 함수들을 한번씩은 확인할것이라 생각해 이런 구조로 개발했다. MemorySessionStore Memory에 저장하는 SessionStore이다.