728x90

결국 스프링이 원하는 방향에 대해 생각해 보자.

지금까지 느낀 스프링은 OOP를 제대로 적용하기 위해, IOC/DI 기술을 활용한 프레임워크라고 느껴진다.

 

스프링의 정의는 이렇다고 한다.

"자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크"

 

이거에 대해서 생각해 보면

 

  • 애플리케이션 프레임워크

스프링은 어느 분야에만 사용되는 프레임워크가 아니다.

MVC, Log, AOP, 인증, ORM 등등 웹 개발에 필요한 대부분의 기술을 가지고 있다.

스프링의 일차적인 존재 이유는 웹 기술에 담긴 프로그래밍 모델을 일관되게 적용해 애플리케이션 개발을 편리하게 만들어주는 것이다.

 

  • 경량급

솔직히 스프링이 가볍다고 생각해 본 적은 없다.

nest... 와 같은 프레임워크가 훨씬 가볍다고 생각했었다.

그럼에도 스프링이 가볍다고 말하는 이유는 불필요한 부분이 없기 때문이라고 한다.

 

스프링이 처음 등장하던 시기에는 EJB가 개발환경과 운용서버, 개발과 빌드, 테스트 과정 등등... 코드들을 엄청 무겁게 만들었다고 한다.

그렇기에 서버를 동작하기 위해서는 고성능의 무거운 자바 서버가 필요했다고 한다.

그렇기에 스프링은 가장 단순한 톰캣에서도 동작할 수 있도록 등장했으며, 이것만으로도 충분하게 애플리케이션을 개발할 수 있었다고 한다.

 

  • 자바 엔터프라이즈 개발을 편하게

스프링이 배우기 쉬웠던 기술이라고는 생각되지 않는다.

하지만 여기서 말하는 편하다라는 뜻은 그런 의미는 아니고, 개발의 비즈니스 로직에 집중하다록 만들어주었다는 것이다.

 

기존에 개발자가 로우레벨의 트랜잭션, 상태관리, 멀티쓰레딩과 같은 부분까지 신경을 쓰며 개발을 해야했다면 스프링은 그런 문제를 해결해주었다는 것이다.

물론 여기서 이런 기술을 아예 무시하고 개발한다는 것이 아니다.

이런 요구들을 스프링 엔터프라이즈 시스템에서 최대한 해결해준다는 것이다.

 

  • 오픈소스

스프링은 처음부터 지금까지 오픈소스로 개발되고 있다.

그렇기에 공개된 커뮤티니의 공간 안에서 다양한 사람이 투명하게 참여하여 개발하기에 빠르고 유연하게 성장이 가능하다.

사용자의 피드백도 빠르게 반영되고 있다.

 

라이센스에 대한 비용도 없기 때문에, 부담없이 큰 기업에서도 사용해 개발이 가능하다.

 

728x90

스프링의 현재와 미래 같은 챕터이다.

스프링의 핵심인 객체지향은 그대로지만, 이 객체지향을 지키기 위한 기술들이 많이 바뀌었다고 한다.

 

  • 어노테이션의 메타정보 활용

자바는 소스코드를 컴파일 후 클래스 파일로 만들었다가, JVM에 의해 메모리에서 로딩되어 실행된다.

이런 자바코드를 리플렉션등과 같은 방법으로 클래스내의 인터페이스, 필드 등의 메타정보를 확인 할 수 있다.

 

자바5에 어노테이션이 등장했다.

자바의 클래스나 인터페이스, 필드와 메서드들은 그 자체로 직접 이용이 가능하지만 어노테이션은 그런 방식으로는 이용이 불가능하다.

리플렉션을 이용해 메타정보를 조회하고, 어노테이션에 설정된 값을 가져와서 참고하는 방법이 전부라고 한다.

그럼에도 이렇게 직접 영향을 주지 못하는 어노테이션은 빠르게 발전했다고 한다.

어노테이션이 IOC 방식의 프레임워크, 프레임워크가 참조하는 메타정보라는 이 구성방식에 잘 어울리기 때문이라고 한다.

 

기존에 작성하던 이 긴 xml을 어노테이션으로 교체가 가능하다.

@Seungkyu
public class SK{}

이렇게만 작성해도 클래스의 정보와 해당 클래스가 어떤 인터페이스를 구현하고 있는지 알아 올 수 있기 때문이다.

 

이런 방식을 사용하여 XML을 최대한 작성하지 않도록 만들 수 있었고, 스프링 3.1에서는 대부분의 기능을 이 어노테이션으로 대체가 가능하다고 한다.

 

기존에 작성했던 xml을 어노테이션을 사용하는 방법으로 리펙토링 해보도록 하자.

 

자바 코드를 이용한 빈 설정

우선 test-applicationContext.xml을 사용하는 테스트를 타깃으로 리펙토링 해보자.

테스트가 작성되어 있기에, 바로 확인이 가능하기 때문이다.

해당 xml은 @ContextConfiguration(locations="/test-applicationContext.xml")을 붙인 클래스들이 사용 중이다.

 

이거를 그대로 가져올 클래스를 먼저 만든다.

@Configuration
public class TestApplicationContext {
}

이제 이게 xml이다.

 

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = TestApplicationContext.class)
class UserDaoTest {

이제 테스트 클래스의 configuration을 위치가 아닌, 해당 클래스로 변경해준다.

 

일단 이거도 단계적으로 나아가기 위해 처음에는 해당 xml을 불러오는 것으로 시작한다.

@Configuration
@ImportResource("/test-applicationContext.xml")
public class TestApplicationContext {
}

 

이렇게하고 테스트를 실행하면 당연히 성공한다.

하나씩 고치면서 계속 테스트를 실행해보자.

 

우선 step1은 context:annotation-config라고 한다.

사실 이거

@PostConstruct를 위해서 작성했던 것인데, @Configuration을 사용하면 자동으로 등록해주기 때문에 바로 삭제해도 문제 없다고 한다.

 

step2는 가장 많을 bean이다.

현재 이 DataSource를 SimpleDriverDataSource 구현체로 주입받고 있다.

이거를 클라이언트가 SimpleDriverDataSource로 주입받는 것이 아니라, DataSource 인터페이스로 받도록 해야한다.

 

그렇기에 이런식으로 Bean을 생성해야 한다.

    @Bean
    public DataSource dataSource() {
        return null;
    }

 

이제 내용과 리턴 타입을 채워보자.

 

xml의 내용을 setter를 사용해 그대로 넣으면 된다.

    @Bean
    public DataSource dataSource() {

        SimpleDriverDataSource dataSource = new SimpleDriverDataSource();
        dataSource.setDriverClass(Driver.class);
        dataSource.setUrl("jdbc:mysql://localhost:3306/test");
        dataSource.setUsername("root");
        dataSource.setPassword("1204");
        
        return dataSource;
    }

 

이렇게 작성하게 테스트를 돌려보면

비록 DataSource를 찾지 못해 intellij의 xml에서는

이렇게 에러가 발생한다고 나오지만, 실제 실행하면 @Bean의 정보를 불러오기에 테스트는 정상적으로 동작한다.

 

 

마찬가지로 transactionManager도 아래와 같이 옮긴다.

    @Bean
    public PlatformTransactionManager transactionManager() {
        DataSourceTransactionManager transactionManager = new DataSourceTransactionManager();
        transactionManager.setDataSource(dataSource());
        return transactionManager;
    }

 

만약 다른 빈의 주입이 필요하면 이렇게 빈의 메서드를 직접 호출해서 넣어주면 된다.

 

여기서 현재 sqlService()를 만들지 않아서 에러가 발생 중이다.

그럴 때는 다른 곳에 있는 SqlService 빈을 불러와야 하기에, Configuration 자체에 주입 받으면 된다.

 

이렇게 주입받아서 사용하고, 테스트를 수행해보니 정상적으로 수행되는 것을 볼 수 있었다.

 

    <jdbc:embedded-database id="embeddedDatabase" type="H2">
        <jdbc:script location="classpath:schema.sql"/>
    </jdbc:embedded-database>

 

이것도 옮겨야 하는데 이 친구는 <bean>이 아니다.

하지만 저번에 EmbeddedDatabaseBuilder를 사용했던 것을 떠올리며, 결국 해당 타입으로 주입을 하게 되는 것이기에 그렇게 만들어서 넣어준다.

 

    @Bean
    public DataSource embeddedDataSource() {
        return new EmbeddedDatabaseBuilder()
                .setName("embeddedDatabase")
                .setType(EmbeddedDatabaseType.H2)
                .addScript("/schema.sql").build();
    }

 

메서드의 이름은 우리가 등록했던 bean의 id로 해준다.

 

마지막으로 트랜잭션 어노테이션을 위해 해당 어노테이션까지 TestApplicationContext에 붙여준다.

@EnableTransactionManagement

 

이렇게해서 모든 bean을 옮겼다.

초기 테스트를 위해서 붙였던 @ImportResource를 지금은 제거가 가능하다.

 

그렇게 수정하고 테스트를 돌려보니 성공하는 것을 볼 수 있었다.

 

빈 스캐닝과 자동와이어링

이렇게 만든 빈들을 생성자나 setter를 통해 주입해야한다.

 

스프링은 @Autowired가 붙은 수정자 메서드가 있으면 타입을 보고 주입 할 수 있는 빈을 주입한다.

만약 타입으로 주입 가능한 빈이 2개 이상이면, 그 중에서 해당 프로퍼티와 동일한 이름의 빈으로 주입한다.

 

그렇기에 이렇게 동일한 타입이 2개라도 각각의 이름을 통해서 빈을 주입 가능한 것이다.

@Bean
public DataSource dataSource() {}

@Bean
public DataSource embeddedDataSource() {}

 

@Autowired
public UserDaoImpl(
            DataSource dataSource,
            SqlService sqlService) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
        this.sqlService = sqlService;
    }

이렇게 DataSource로 받지만, 실제 사용하는건 JdbcTemplate과 같은 경우 JdbcTemplate을 주입받을 수는 없으니 반드시 setter나 생성자를 통해 주입 받아야 한다.

 

@Component를 통해서도 빈 등록이 가능하다.

이 @Component는 클래스에 사용하는 어노테이션이고, 이 어노테이션이 부여된 클래스는 자동으로 빈으로 등록된다.

 

현재 작성한 UserDaoImpl을 보면

@Component
public class UserDaoImpl implements UserDao { 
	//
}

 

이렇게 해당 클래스에 @Component를 붙이는 것 만으로도

    @Bean
    public UserDao userDao() {
        return new UserDaoImpl(dataSource(), sqlService());
    }

이거를 대체할 수 있다는 것이다.

 

대신에 @ComponentScan을 통해 @Component들을 검색할 범위를 지정해야 한다.

@Configuration
@EnableTransactionManagement
@ComponentScan(basePackages = "seungkyu")
public class TestApplicationContext { }

이렇게 범위를 지정해서 그 패키지들의 하위 클래스들을 검색하도록 해야한다.

 

@Component에서 클래스는 해당 클래스로 등록하고, 빈의 아이디는 특별하게 지정하지 않으면 클래스의 이름을 첫글자 소문자로 바꿔서 사용한다.

 

현재 UserDaoImpl이기에 빈의 아이디는 userDaoImpl로 지정이 되겠지만, UserDao의 구현체이기에 해당 UserDao의 타입으로도 주입이 되게 된다.

 

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Component
public @interface SeungkyuComponent {
}

이런 식으로 @Component 어노테이션을 가지고 있는 어노테이션은 빈으로 등록이 된다.

 

그런 빈 중에서도 @Service, @Repository와 같은 특별한 역할을 하는 빈들이 있기에 맞게 달아주도록 하자.

여기는 현재 데이터베이스에 접근하는 코드이니 @Repository를 붙여주도록 하겠다.

 

빈을 등록하다보면 다음과 같은 상황이 생길 수 있다.

타입으로 주입을 시도하려고 했지만, 같은 타입이 2개 있고 이름으로도 주입할 수 없는 상황이다.

기존에는 UserServiceImpl을 UserService로 id를 지정해서 빈을 등록했지만, 지금은 클래스의 이름으로 등록이 되었기에 저 중 어떤 id도 userService와 맞지 않아 어떤 빈을 주입할지 에러가 생긴 것이다.

 

이 문제를 해결해주기 위해서는 다시 UserServiceImpl을 UserService로 등록해주면 된다.

@Component("userService")
@RequiredArgsConstructor
public class UserServiceImpl implements UserService{}

 

이 방법으로 빈을 등록해주도록 하자.

 

그러면 나머지 이 testUserServiceImpl은 어떻게 사용하게 될까?

 

컨텍스트 분리와 @Import

이렇게 DI를 사용해왔던 이유는 언젠가 사용할 테스트 때문이다.

그리고 지금 이 testUserServiceImpl도 테스트 때에만 사용하기에 어떻게 처리를 할지 고민하는 것이다.

다른 애플리케이션 빈에서는 분리하는 것이 더 좋아보인다.

 

일단 테스트에서 사용할 빈들을 따로 빼두는 Configuration을 만들어보자.

@Configuration
public class TestAppContext {

    @Autowired UserDao userDao;

    @Bean
    public UserService testUserService(){
        return new TestUserServiceImpl(userDao, mailSender());
    }

    @Bean
    public MailSender mailSender() {
        return new MailSenderTest();
    }
}

 

이제 테스트 환경에서는 이거를 주입하면 될 거 같다.

그렇다고 이거를 ComponentScan의 범위로 넣을 수는 없을 것이기에, 해당 테스트 환경에서만 주입해주도록 해야한다.

 

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {TestApplicationContext.class, TestAppContext.class})
class UserDaoTest {}

 

마지막으로 데이터베이스 연결과 같은 부분도 분리하도록 하겠다.

결국 Configuration에도 같은 관심사끼리 모아두는 것이 유지보수에는 유리할 것이다.

@Configuration
public class SqlServiceContext {

    @Bean
    public SqlRegistry sqlRegistry() {
        return new ConcurrentHashMapSqlRegistry();
    }

    @Bean
    public SqlReader sqlReader() {
        return new YmlSqlReader("/sqlmap.yml");
    }

    @Bean
    public SqlService sqlService() {
        return new YmlSqlService(sqlReader(), sqlRegistry());
    }

    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
                .setName("embeddedDatabase")
                .setType(EmbeddedDatabaseType.H2)
                .addScript("/schema.sql")
                .build();
    }
}

 

이렇게 일단 지금 가지고 있는건 SqlServiceContext, TestAppContext, TestApplicationContext 이렇게 3개이다.

일단 혼동되지 않게 TestApplicationContext를 AppContext로 바꿔주자.

 

이거를 모두 배열로 @ContextConfiguration에 넣어줘야 할까?

하지만 여기서 의존관계를 살펴보면 SqlServiceContext를 AppContext가 필요로하고, 솔직히 테스트 클래스나 TestAppContext는 관심이 없다.

그렇기에 SqlServiceContext를 AppContext에만 직접 넣어주도록 만들어주는 것이 좋을 것 같다.

 

@Import(SqlServiceContext.class)
public class AppContext {}

이 방법으로 직접 넣어주고 다른 부분은 수정하지 않도록 만들자.

 

프로파일

현재 방법은 다음과 같은 문제가 있다.

현재 운영, 테스트가 공통으로 사용하는 AppContext와 TestAppContext 이렇게 2개가 있고 여기 모두에서 UserService 타입의 빈이 정의되어있다.

하나는 MailSenderImpl 타입이고 다른 하나는 MailSenderTest이다.

 

그럼 MailSender를 주입 받을 때, 어떤 타입을 주입받게 될까.

지금도 이렇게 충돌이 일어나고 있고, 우리는 테스트 환경에서는 testUserService를 데리고 오고 싶은 것이다.

이렇게 테스트 환경과 운영환경에서 각각 다른 빈을 가져와야 하는 경우가 많다.

 

스프링은 이렇게 환경에 따라서 빈 설정정보가 달라져야 하는 경우에 간단하게 해당 설정들을 만들 수 있도록 방법을 제공한다.

 

프로파일은 클래스 단위로 지정한다.

@Profile 어노테이션을 사용해서 프로파일의 이름을 넣어주면 된다.

 

@Configuration
@Profile("test")
public class TestAppContext {
}

이제 이렇게 하고 실행을 해보면, 당연히 실패한다.

 

MailSender를 가져오지 못해 실패하는데, 따로 저 profile을 활성화해주지 않아 에러가 발생하는 것이다.

 

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {AppContext.class, TestAppContext.class, ProductionAppContext.class})
@ActiveProfiles("test")
class UserDaoTest {}

이렇게 ActiveProfiles로 test를 활성화 해줘야, test의 profile들을 불러오게 된다.

 

이렇게 설정을 하고 다시 테스트를 돌려보니, 다음과 같이 성공하는 것을 볼 수 있다.

 

 

프로퍼티 소스

현재 데이터베이스의 정보가 이렇게 코드로 들어가있다.

이런 정보가 깃에 올라가면 안되기도 하고, 배포서버와 개발서버에서 다른 데이터베이스를 연결하기에 이런 정보는 코드로 작성해서는 안된다.

 

프로퍼티 파일로 빼도록 하자.

database.yml라는 파일을 만들고 데이터베이스의 정보는 그곳에다가 저장하도록 하겠다.

 

 

그리고 AppContext 내의 코드를 다음과 같이 수정해준다.

 

    @Autowired
    Environment environment;

    @Bean
    public DataSource dataSource() {

        SimpleDriverDataSource dataSource = new SimpleDriverDataSource();

        try
        {
            dataSource.setDriverClass((Class<? extends java.sql.Driver>)Class.forName(environment.getProperty("db.driverClass")));
        }
        catch (ClassNotFoundException e)
        {
            throw new RuntimeException(e);
        }

        dataSource.setUrl(environment.getProperty("db.url"));
        dataSource.setUsername(environment.getProperty("db.username"));
        dataSource.setPassword(environment.getProperty("db.password"));

        return dataSource;
    }

Enviroment를 주입받고, 거기서 하나씩 값을 빼서 사용하는 것이다.

 

이건 뭐랄까, 한번에 많이 가져오는 방법이고 하나씩 가져오는 방법도 있다.

 

    @Value("${db.driverClass}")
    private Class<? extends Driver> driverClassName;

    @Value("${db.url}")
    private String url;

    @Value("${db.username}")
    private String username;

    @Value("${db.password}")
    private String password;

 

이렇게 @Value로 값을 명시하고 값을 가져올 수 있다.

 

이 중 원하는 방법으로 변수들을 빼오면 된다.

나는 아마 @Value...?

728x90

저번에 말했던 실시간으로 수정이 가능한 UpdatableSqlRegistry를 만들어보고자 한다.

 

Sql을 업데이트 할 때, 쿼리를 호출하게 된다면 깨진 Sql이 나타날 수 있기 때문에 동시성 문제에 주의해서 구현해야 한다.

그렇기에 자바에서 동시성 문제를 도와주는 라이브러리를 사용해 만들어보도록 하겠다.

 

ConcurrentHashMap을 이용한 수정 가능 SQL 레지스트리

HashMap에서는 역시 멀티스레드 환경에서 동시성 문제가 발생할 수 있기 때문에, 이런 문제에 최적화된 ConcurrentHashMap을 사용하도록 하겠다.

ConcurrentHashMap은 업데이트시에 해당 부분에만 락을 걸기에, 성능이 많이 떨어지지 않는다.

 

우선 다음과 같은 테스트를 작성한다.

이 테스트가 통과해야 할 것이다.

public class ConcurrentHashMapSqlRegistryTest {

    UpdatableSqlRegistry sqlRegistry;

    @BeforeEach
    public void setUp() {

        sqlRegistry.registerSql("KEY1", "SQL1");
        sqlRegistry.registerSql("KEY2", "SQL2");
        sqlRegistry.registerSql("KEY3", "SQL3");
    }

    @Test
    public void find(){
        Assertions.assertTrue(
                sqlRegistry.findSql("KEY1").equals("SQL1") &&
                        sqlRegistry.findSql("KEY2").equals("SQL2") &&
                        sqlRegistry.findSql("KEY3").equals("SQL3")
        );
    }

    @Test
    public void notFoundKey(){
        Assertions.assertThrows(ChangeSetPersister.NotFoundException.class, () -> sqlRegistry.findSql(UUID.randomUUID().toString()));
    }
    
    @Test
    public void updateSql(){
        sqlRegistry.updateSql("KEY1", "U_SQL1");
        Assertions.assertTrue(
                sqlRegistry.findSql("KEY1").equals("U_SQL1") &&
                        sqlRegistry.findSql("KEY2").equals("SQL2") &&
                        sqlRegistry.findSql("KEY3").equals("SQL3")
        );
    }
    
    @Test
    public void updateMulti(){
        Map<String, String> sqlmap = new HashMap<>();
        
        sqlmap.put("KEY1", "U_SQL1");
        sqlmap.put("KEY3", "U_SQL3");
        
        sqlRegistry.updateSql(sqlmap);
        Assertions.assertTrue(
                sqlRegistry.findSql("KEY1").equals("U_SQL1") &&
                        sqlRegistry.findSql("KEY2").equals("SQL2") &&
                        sqlRegistry.findSql("KEY3").equals("U_SQL3")
        );
    }
}

동시성 관련해서는 멀티쓰레드를 만들어야 하고, 해당 환경에서도 문제가 발생할지 안할지를 잘 모르기에 테스트가 어렵다.

우선은 자바에서 제공해주는 라이브러리를 믿어보도록 하자.

 

그리고 ConcurrentHashMap을 사용하는 Registry를 다음과 같이 구현한다.

public class ConcurrentHashMapSqlRegistry implements UpdatableSqlRegistry {

    private Map<String, String> sqlMap = new ConcurrentHashMap<>();

    @Override
    @SneakyThrows
    public void updateSql(String key, String sql) {
        if(sqlMap.get(key) == null)
            throw new ChangeSetPersister.NotFoundException();

        sqlMap.put(key, sql);
    }

    @Override
    public void updateSql(Map<String, String> sqlmap) {
        sqlmap.forEach(this::updateSql);
    }

    @Override
    public void registerSql(String key, String sql) {
        sqlMap.put(key, sql);
    }

    @SneakyThrows
    @Override
    public String findSql(String key) {
        String sql = sqlMap.get(key);
        if(sql == null) throw new ChangeSetPersister.NotFoundException();
        return sql;
    }
}

 

이거를 바탕을 테스트를 돌려보면

역시 성공하는 것을 볼 수 있다.

 

현재 SqlService에 해당 빈으로 등록 하도록 하자.

<bean id="sqlRegistry" class="seungkyu.ConcurrentHashMapSqlRegistry"/>

 

내장형 데이터베이스를 이용한 SQL 레지스트리 만들기

SqlRegsitry를 ConcurrentHashMap 말고도 데이터베이스로도 만들어 볼 수 있다.

외부로 트래픽이 필요한 외장 데이터베이스보다 애플리케이션에 내장되어 애플리케이션과 함께 실행되고 종료되는 내장 데이터베이스를 사용하는 것이 더 편리하고 빠를 것이다.

 

많이 사용되는 내장 데이터베이스는 Derby, HSQL, H2가 있다고 한다.

이 친구들은 스프링에서 돌아가기에 따로 SQL 스크립트를 만들어서 같이 실행해야 한다고 한다.

초기 Sql을 통해 데이터를 삽입하고 나면 그 뒤에는 JDBC와 같은 기술들을 동일하게 사용 할 수 있다고 한다.

 

일단 이 내장 데이터베이스를 간단하게 사용해보도록 하자.

내장 데이터베이스는 DB가 실행될때마다 테이블을 새로 생성하기에, 테이블을 생성하는 SQL을 같이 넣어줘야 한다.

 

schema.sql

CREATE TABLE SQLMAP(
    KEY_ VARCHAR(100) PRIMARY KEY,
    SQL_ VARCHAR(100) NOT NULL
);

 

그리고 초기에 데이터도 넣어주기 위해 insert로 구성된 data.sql을 작성한다.

INSERT INTO SQLMAP(KEY_, SQL_) values('KEY1', 'SQL1');
INSERT INTO SQLMAP(KEY_, SQL_) values('KEY2', 'SQL2');

 

간단하게 테스트를 작성해보니

package seungkyu;

import org.junit.jupiter.api.*;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.datasource.embedded.EmbeddedDatabase;
import org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseBuilder;
import org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseType;

import java.util.concurrent.atomic.AtomicInteger;

public class EmbeddedDbTest {

    EmbeddedDatabase db;
    JdbcTemplate jdbcTemplate;

    @BeforeEach
    public void setUp() {

        db = new EmbeddedDatabaseBuilder()
                .setType(EmbeddedDatabaseType.H2)
                .addScript("/schema.sql")
                .addScript("/data.sql")
                .build();

        jdbcTemplate = new JdbcTemplate(db);
    }

    @AfterEach
    public void tearDown() {
        db.shutdown();
    }

    @Test
    public void initData(){
        Assertions.assertEquals(2, jdbcTemplate.queryForObject("select count(*) from sqlmap", Integer.class));

        AtomicInteger index = new AtomicInteger();

        jdbcTemplate.queryForList("SELECT * FROM sqlmap").forEach(
                (mapEntry) -> {
                    Assertions.assertEquals("KEY" + (index.get() + 1), mapEntry.get("key_"));
                    Assertions.assertEquals("SQL" + (index.get() + 1), mapEntry.get("sql_"));
                    index.getAndIncrement();
                }
        );
    }

}

 

 통과하는 것을 볼 수 있었다.

 

이제 이 내장 데이터베이스를 사용해서 SqlRegistry를 수정해보자.

 

일단 이 내장 데이터베이스를 사용하기 위해서 빈으로 등록하도록 하자.

 

    <jdbc:embedded-database id="embeddedDatabase" type="H2">
        <jdbc:script location="classpath:schema.sql"/>
    </jdbc:embedded-database>

schema는 실행하면서 생성만 하면 되기에 여기에 넣어준다.

 

이제 embeddedDatabase 빈이 등록되어 그냥 이 데이터베이스를 사용하면 된다.

 

이 빈을 사용해서 UpdatableSqlRegistry를 만들어보자.

 

주입받은 내장 데이터베이스의 DataSource를 통해 저장하고 업데이트 하도록 만든다.

package seungkyu;

import org.springframework.dao.EmptyResultDataAccessException;
import org.springframework.data.crossstore.ChangeSetPersister;
import org.springframework.jdbc.core.JdbcTemplate;

import javax.sql.DataSource;
import java.util.Map;

public class EmbeddedDbSqlRegistry implements UpdatableSqlRegistry {

    private final JdbcTemplate jdbcTemplate;

    public EmbeddedDbSqlRegistry(DataSource dataSource) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
    }

    @Override
    public void registerSql(String key, String sql) {
        jdbcTemplate.update("INSERT INTO sqlmap (key_, sql_) values (?, ?)", key, sql);
    }

    @Override
    public String findSql(String key) {
        try
        {
            return jdbcTemplate.queryForObject("SELECT sql_ FROM sqlmap WHERE key_ = ?", String.class, key);
        }
        catch(EmptyResultDataAccessException e)
        {
            throw new RuntimeException();
        }
    }

    @Override
    public void updateSql(String key, String sql) {
        int changed = jdbcTemplate.update("UPDATE sqlmap SET sql_ = ? WHERE key_ = ?", sql, key);
    }

    @Override
    public void updateSql(Map<String, String> sqlmap) {
        for(Map.Entry<String, String> entry : sqlmap.entrySet()) {
            this.updateSql(entry.getKey(), entry.getValue());
        }
    }
}

 

 

이제 이 EmbeddedDbSqlRegistry를 테스트 해봐야 한다.

근데 재미있게도 ConcurrentHashMapSqlRegistry와 구현한 인터페이스가 같다.

그리고 우리는 그 인터페이스의 내용만 테스트하면 끝이다.

 

그렇기에 해당 테스트 코드를 공유해보자.

 

이런식으로 추상 클래스를 만들고

public abstract class AbstractUpdatableSqlRegistryTest {

    UpdatableSqlRegistry sqlRegistry;

    abstract protected UpdatableSqlRegistry injectSqlRegistry();

    @BeforeEach
    public void setUp() {
        sqlRegistry = injectSqlRegistry();

        sqlRegistry.registerSql("KEY1", "SQL1");
        sqlRegistry.registerSql("KEY2", "SQL2");
        sqlRegistry.registerSql("KEY3", "SQL3");
    }
    //.....
}

 

기존의 ConcurrentHashMapSqlRegistryTest도 이렇게 간단하게 변경했다.

public class ConcurrentHashMapSqlRegistryTest extends AbstractUpdatableSqlRegistryTest{

    @Override
    protected UpdatableSqlRegistry injectSqlRegistry() {
        return new ConcurrentHashMapSqlRegistry();
    }
}

이렇게만 작성하고 테스트를 해봐도

 

기존에 작성한 4개의 테스트를 수행하는 것을 볼 수 있다.

 

이거를 그대로 상속받아 EmbeddedDbSqlRegistryTest를 만들어보자.

public class EmbeddedDbSqlRegistryTest extends AbstractUpdatableSqlRegistryTest{

    EmbeddedDatabase db;

    @Override
    protected UpdatableSqlRegistry injectSqlRegistry() {
        db = new EmbeddedDatabaseBuilder()
                .setType(EmbeddedDatabaseType.H2)
                .addScript("/schema.sql")
                .build();

        return new EmbeddedDbSqlRegistry(db);
    }

    @AfterEach
    public void tearDown() {
        db.shutdown();
    }
}

 

이렇게 작성하고 테스트를 실행해보니, 다행하게 통과하는 것을 볼 수 있었다.

 

이제 저 EmbeddedDbSqlRegistry에 DataSource를 주입해줘야 한다.

아무생각없이 DataSource를 찾아 넣으면 MySql로 들어가기에 내장 데이터베이스를 잘 찾아서 넣어줘야 한다.

 

    <bean id="sqlRegistry" class="seungkyu.EmbeddedDbSqlRegistry">
        <constructor-arg ref="embeddedDatabase"/>
    </bean>

    <jdbc:embedded-database id="embeddedDatabase" type="H2">
        <jdbc:script location="classpath:schema.sql"/>
    </jdbc:embedded-database>

이렇게 embeddedDatabase의 빈을 또 만들고 그 빈으로 주입을 해줘야 내장데이터베이스로 설정이 된다.

 

트랜잭션 적용

만약 쿼리들이 등록되고 있는 중간에, 해당 쿼리를 조회하면 어떻게 될까?

반복문을 통해 등록하는 중간에 아직 등록되지 않은 쿼리를 조회할 수도 있을 것이다.

이런 이유로 각 메서드에 알맞은 트랜잭션 설정을 해줘야 한다.

 

우선 테스트 먼저 작성한다.


    @Test
    public void transactionTest(){
        Map<String, String> sqlmap = new HashMap<>();
        sqlmap.put("KEY1", "U_SQL1");
        sqlmap.put(UUID.randomUUID().toString(), UUID.randomUUID().toString());

        try
        {
            sqlRegistry.updateSql(sqlmap);
            Assertions.fail();
        }
        catch (RuntimeException e)
        {
            Assertions.assertTrue(
                    sqlRegistry.findSql("KEY1").equals("SQL1") &&
                            sqlRegistry.findSql("KEY2").equals("SQL2") &&
                            sqlRegistry.findSql("KEY3").equals("SQL3")
            );
        }
    }

 

중간에 없는 key로 조회를 하면 에러가 발생하는지 테스트이다.

그리고 만약 에러가 발생했다면 롤백도 되는지 테스트한다.

 

당연히 지금은 롤백이 되지 않아 실패한다.

 

트랜잭션은 마지막 부분에만 필요하기에

package seungkyu;

import org.jetbrains.annotations.NotNull;
import org.springframework.dao.EmptyResultDataAccessException;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.datasource.DataSourceTransactionManager;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.TransactionCallbackWithoutResult;
import org.springframework.transaction.support.TransactionTemplate;

import javax.sql.DataSource;
import java.util.Map;

public class EmbeddedDbSqlRegistry implements UpdatableSqlRegistry {

    private final JdbcTemplate jdbcTemplate;
    private final TransactionTemplate transactionTemplate;

    public EmbeddedDbSqlRegistry(DataSource dataSource) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
        this.transactionTemplate = new TransactionTemplate(new DataSourceTransactionManager(dataSource));
    }

    @Override
    public void updateSql(Map<String, String> sqlmap) {
        transactionTemplate.execute(new TransactionCallbackWithoutResult() {
            protected void doInTransactionWithoutResult(@NotNull TransactionStatus status) {
                for(Map.Entry<String, String> entry : sqlmap.entrySet()) {
                    updateSql(entry.getKey(), entry.getValue());
                }
            }
        });
    }
}

해당 부분만 트랜잭션으로 감싸준다.

 

그리고 테스트를 수행해보면 다음과 같이 성공하는 것을 볼 수 있다.

728x90

권장되지는 않지만 서버 운영 중에 SQL을 변경해야 할 수도 있다고 한다.

스프링답게 이 방법을 만들어보도록 하자.

 

DI와 기능의 확장

DI는 기술이 아니다.

DI 자체를 공부한다는 느낌보다는 최대한 이용하며 설계하는 방법을 배우고 있는 중이다.

단순히 Controller, Service, Repository를 사용하는 것이 아니라 DI를 통해 유연하게 의존관계를 지정하도록 설계해야 제대로 DI를 사용하는 것이다.

제대로 DI를 사용할 수 있도록 의식하면서 프로그래밍을 하는 습관이 필요하다.

하나의 커다란 오브젝트를 적절한 책임에 따라 분리해주는 습관을 들여야 한다.

물론 당장 사용하지는 않겠지만, DI를 미래에 대한 보험이라고 생각하면 될 것이다.

 

DI를 사용할 때에는 최대한 인터페이스를 사용해야 한다.

물론 클래스를 직접 주입해서 사용하는 것도 가능은 하다.

하지만 그러면 그 클래스에 직접적으로 의존하게 된다.

만약 구현코드가 변경된다면, 해당 클래스를 의존하고 있는 모든 오브젝트도 변경해야 한다.

 

이렇게 인터페이스를 사용하는 첫번째 이유는 다형성을 얻기 위해서다.

하나의 인터페이스로 여러개의 구현체를 바꿔가며 사용하도록 하는 것이 DI의 첫번째 목표이다.

그리고 또 인터페이스를 사용해야 하는 이유가 있다면 인터페이스 분리 원칙을 통해 클라이언트와 의존 오브젝트 사이의 관계를 명확하게 해줄 수 있기 때문이다.

인터페이스는 하나의 오브젝트가 여러 개를 구현할 수 있으므로, 하나의 오브젝트를 바라보는 관점이 여러가지일 수도 있다.

하나의 인터페이스를 하나의 관심사라고 한다면, 하나의 오브젝트가 다양한 관심사를 구현할 수도 있다는 것이다.

여기서 본인의 관심사에만 의존한다면 의존받는 오브젝트의 다른 부분이 변경되더라도, 의존하는 오브젝트는 관심이 없기 때문에 변경될 필요도 없다.

이런 부분을 잘 이용해서 관심사에 따라 오브젝트를 구현하도록 만드는 것도 DI를 잘 이용하는 방법이다.

 

오브젝트가 그 자체로 응집도가 높게 설계되었더라도, 목적과 관심이 각기 다른 클라이언트가 있다면 이를 적절하게 분리해주는 것이 좋다.

이를 객체지향의 5대 원칙 중 하나인 인터페이스 분리 원칙(Interface Segregation Principle)이라고 한다.

 

인터페이스 상속

인터페이스 분리 원칙이 주는 장점은 모든 클라이언트가 자신의 관심에 따른 접근 방식을 간섭없이 유지할 수 있다는 점이다.

어차피 클라이언트는 본인이 의존하고 있는 인터페이스의 메서드만 신경쓰기에, 다른 부분의 변경은 영향을 주지 않기 때문이다.

 

다음과 같은 구조에서

BaseSqlService는 어떤 클래스가 SqlReader를 구현했던, 신경쓰지 않고 그저 인터페이스만 사용해서 변경없이 코드를 유지할 수 있다.

 

그리고 또 하나의 장점은, 2개의 인터페이스를 구현해서 각각 다른 클라이언트가 사용할 수 있다는 점이다.

 

현재 SqlRegistry는

public interface SqlRegistry{
	void registerSql(String key, String sql);
    
    String findSql(String key) throws SqlNotFoundException;   
}

 

이렇게 2가지를 가지고 있다. 그리고 이 인터페이스를 MySqlRegistry가 다른 인터페이스를 추가로 구현하고 싶다고 한다.

당연히 현재 BaseSqlService는 이런 등록하는 과정이 필요가 없기 때문에 SqlRegistry 인터페이스에 그런 메서드를 추가하면 안된다.

 

이런 부분은 분리를 해야한다.

public interface UpdatableSqlRegistry extends SqlRegistry{
    
    public void updateSql(String key, String sql);
    
    public void updateSql(Map<String, String> sqlmap);
}

 

 

이렇게 SqlRegistry에 업데이트를 하는 기능을 추가한다.

 

이러면 현재 BaseSqlService는 저 위의 메서드들만 사용하고 있기에, 아래의 메서드들에는 영향을 전혀 받지 않는다.

 

이런 Sql의 Update를 담당하는 클래스를 SqlManager라고 하자.

이런 식으로 BaseSqlService는 결국 SimpleUpdatableSqlRegistry를 주입받지만, 그 중 SqlRegistry의 메서드만 사용하게 된다.

그리고 이런 업데이트들은 다시 UpdatableSqlRegistry의 메서드들을 통해서 일어나게 되며, 해당 인터페이스의 구현체 또한 SimpleUpdatableSqlRegistry 이기 때문에 이런 업데이트가 결국 BaseSqlService에도 반영이 되는 것이다.

 

이렇게 인터페이스를 추가하거나 상속을 통해 확장하는 방식을 잘 이용하면 기존의 인터페이스를 사용하는 클라이언트가 있더라도 유연한 확장이 가능해진다.

 

잘 적용된 DI는 결국 잘 설계된 오브젝트 의존관계에 달려있다.

인터페이스를 적절하게 분리하고 확장하는 방법을 항상 고민하고, 의존관계를 명확하게 해주는 방법을 항상 고민하며 개발하자.

728x90

JAVB외에도 XML과 클래스의 멤버에 데이터를 매핑하는 기술들이 있다고 한다.

그리고 XML을 더 자유롭게 읽어올 수도 있다고 한다.

알아보자.

 

OXM 서비스 추상화

OXM은 Object-XML Mapping으로 xml과 자바 오브젝트를 매핑해주는 기술이라고 한다.

JAXB는 자바 표준에 포함되어 있어서 사용했지만, 이 외에도 다음과 같은 XML 기술들이 있다.

Castor XML, JiBX, XmlBeans, Xstream...

 

이 모든 기술들의 목적은 XML에서 데이터를 가져오는 것이다.

그 중 어떤 기술을 사용할지 모르기에 추상화로 만들어두는 것도 좋은 방법이라고 생각된다.

자바 -> XML을 Marshaller라고 하고

XML -> 자바를 Unmarshaller라고 한다.

 

'우리는 XML에서 값을 불러와야 하기에 Unmarshaller를 사용해야 한다'가 목표였지만, xml에서 무언가 조작하기가 힘들어서 yml에서 가져와서 만드는 것으로 바꿨다...

 

기존에 작성했던 SqlMap으로 쿼리들을 불러와보자.

 

@Getter
@Setter
@ToString
@Configuration
@ConfigurationProperties(prefix = "sqlmap")
public class SqlMap {

    private List<SqlType> queries;
}

 

@Getter
@Setter
@ToString
public class SqlType {
    private String value;
    private String key;
}

 

이렇게 해두고 우선 테스트를 돌려보자.

 

@ExtendWith(SpringExtension.class)
@ContextConfiguration(locations = {"/test-applicationContext.xml"})
public class OxmTest {

    @Test
    public void unmarshallSqlMap() throws Exception {
        ObjectMapper mapper = new ObjectMapper(new YAMLFactory());

        try (InputStream inputStream = getClass().getResourceAsStream("/sqlmap.yml")) {
            assert inputStream != null;

            SqlMap sqlMap = mapper.readValue(inputStream, SqlMap.class);
            System.out.println(sqlMap);
            
            
        }
    }
}

 

우선 이렇게 작성해두면

 

이렇게 제대로 출력되는 것을 볼 수 있다.

 

OXM 서비스 추상화 적용

yml을 읽어오는 기능을 바탕으로 SqlService를 만들어보자.

기존에 사용하던 SqlRegistry를 그대로 사용하면 될테니, Reader만 yml을 읽어오도록 추가해서 등록해주면 된다.

@RequiredArgsConstructor
public class YmlSqlService implements SqlService {

    private final SqlReader sqlReader;

    private final SqlRegistry sqlRegistry;

    @PostConstruct
    public void loadSql(){
        this.sqlReader.read(this.sqlRegistry);
    }

    public String getSql(String key){
        return this.sqlRegistry.findSql(key);
    }
}

 

이렇게 껍데기를 만들어두고, SqlReader를 구현해보자.

@RequiredArgsConstructor
public class XmlSqlReader implements SqlReader {

    private final String path;

    @Override
    public void read(SqlRegistry sqlRegistry) {
        ObjectMapper mapper = new ObjectMapper(new YAMLFactory());

        try (InputStream inputStream = getClass().getResourceAsStream(path)) {
            assert inputStream != null;

            SqlMap sqlMap = mapper.readValue(inputStream, SqlMap.class);

            for(SqlType sqlType: sqlMap.getQueries())
            {
                sqlRegistry.registerSql(sqlType.getKey(), sqlType.getValue());
            }
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

 

이러면 저번에 만들었던 xml과는 동일하게 동작할 수 있을 것이다.

 

이렇게 서비스 자체를 추상화로 만들어두니 테스트도 성공했다.

728x90

어떤 관계들이 존재하는지에 대해서는 생략하고, 바로 OneToMany와 ManyToOne의 관계에 대해서 알아보자.

 

여기서는 사용자와 해당 사용자가 작성하는 보고서에 대한 관계로 설명을 해보려고 한다.

 

우선 OneToMany 관계이다.

한명의 사용자가 많은 양의 보고서를 작성할거기에 One이 사용자, Many가 보고서이다.

따라서 OneToMany는 User 쪽에 작성하는 데코레이션이다.

 

    @OneToMany(() => Report, (report) => report.users)
    reports: Report[];

 

@OneToMany로 2가지의 파라미터를 넘긴다.

우선 첫번째 파라미터는 Many 쪽의 타입이다.

Many로 가져올 타입을 명시하며, () => Report 처럼 함수형으로 반환하는 이유는 곧 보겠지만

Report 쪽에도 이렇게 Users 타입을 주게 되는데, 이 때 두 Entity 간에 순환 참조 에러가 발생하게 된다.

그렇기에 함수의 리턴타입으로 명시해주는 것이다.

 

그리고 2번째 파라미터는, Many 쪽에서 해당 Entity를 가지고 있는 property다.

지금은 하나밖에 없어서 그냥 users로 명시하고 있지만

 

만약 updateUser가 추가된다면

    @OneToMany(() => Report, (report) => report.updatedUser)
    updateReports: Report[];

이렇게 updateUser와 같은 속성을 명시해주는 것이다.

 

이런 이유로 OneToMany에도 2가지의 파라미터를 더 넘기게 된다.

 

이제 Many쪽으로 넘어가보자.

    @ManyToOne(() => Users, (Users) => Users.reports)
    users: Users

Many쪽도 다음과 같은 이유로 2개의 파라미터를 작성한다.

 

그리고 이렇게 작성을 하면 Many 쪽에는

다음과 같이 user쪽의 PK를 가지는 column이 추가된다.

 

근데 여기서 다음과 같은 문제가 발생한다.

우선 지금과 같이 작성해서는

    @Get("/check")
    @UseGuards(AuthGuard)
    async checkLogin(@Authentication() authentication: Users): Promise<Users>{
        console.log(authentication.reports)
        return authentication
    }

해당 코드에서 undefined가 출력되게 된다.

OneToMany 관계에서 Many를 불러오지 못하는 것이다.

 

불러오기 위해서는 다음과 같이 eager:true를 설정해줘야 한다.

@OneToMany(() => Report, (report) => report.users, {
        eager: true
    })
    reports: Report[];

이러면 출력은 된다.

 

하지만 또 문제가 발생한다.

이러면 로그인만 하더라도 모든 report까지 조회하게 된다.

로그인을 하면 user entity를 조회하게 될텐데, 그 때마다 report를 조회한다면 큰 오버헤드 일 것이다.

 

그렇기에 필요할 때만 가져오도록 만들어야 한다.

그러기 위해서는 해당 property를 다음과 같이 수정한다.

    @OneToMany(() => Report, (report) => report.users, {
        lazy: true
    })
    reports: Promise<Report[]>;

이렇게 타입을 Promise로 설정하고, lazy를 true로 하면 해당 property를 사용하려고 할 때 다시 쿼리를 날려서 report를 조회해온다.

 

테스트로 다음과 같이 코드를 작성하고 실행하면

    @Get("/check")
    @UseGuards(AuthGuard)
    async checkLogin(@Authentication() authentication: Users): Promise<Users>{
        console.log("before query")

        console.log(await authentication.reports)
        return authentication
    }

 

로그가 출력되고 그 다음에 다시 쿼리를 날리는 것을 볼 수 있다.

 

이 외에도 다양한 방법의 관계에서의 설정들이 있을텐데, 꾸준하게 nest를 공부하면서 알아보도록 하자.

728x90

기존에는 데이터베이스와 관련된 부분을 그냥 코드로 작성했었다.

 

이런 부분을 당연히 그대로 git에 올리면 안되기 때문에 환경변수로 만들어서 주입해야 한다.

 

우선 환경변수를 .env 파일로부터 가져오기 위해 다음 의존성들을 추가해준다.

 

그리고는 .env.{환경}으로 환경변수를 저장할 파일을 만들어준다.

 

당연히 올리면 안되기에 gitignore에 추가해준다.

 

그리고 데이터베이스는 같게 하더라도 스키마는 다르게 해주었다.

DB_HOST=localhost
DB_PORT=3306
DB_USERNAME=root
DB_PASSWORD=1204
DB_DATABASE=usedCars_dev

.env.development

 

DB_HOST=localhost
DB_PORT=3306
DB_USERNAME=root
DB_PASSWORD=1204
DB_DATABASE=usedCars_test

.env.test

 

테스트에서 다른 데이터베이스를 사용하기 위해 구별해주었다.

 

이제 app.module.ts로 가서 해당 환경변수들을 주입해줘야 한다.

@Module({
  imports: [
      ConfigModule.forRoot({
        isGlobal: true,
        envFilePath: `.env.${process.env.NODE_ENV}`
      })
   ]
})
export class AppModule {}

우선 ConfigModule.forRoot()로 환경변수를 읽어올 파일을 지정해준다.

 

여기에서 .env의 뒷 부분을 모듈 런타임의 환경변수로 지정해서 development, test를 구별해주었다.

 

그 다음에는 기존에 사용하던 TypeOrmModule을 수정해줘야 한다.

forRoot가 아니라 forRootAsync로 가져와야 한다.

forRoot는 정적이거나 process.env로 접근할 때 사용하며

forRootAsync는 동적으로 config 파일을 가져올 때 사용한다고 한다.

 

      TypeOrmModule.forRootAsync({
        inject: [ConfigService],
        useFactory: (config: ConfigService) => {
          return {
            type: "mysql",
            host: config.get<string>('DB_HOST'),
            port: config.get<number>('DB_PORT'),
            username: config.get<string>('DB_USERNAME'),
            password: config.get<string>('DB_PASSWORD'),
            database: config.get<string>('DB_DATABASE'),
            entities: [__dirname + '/**/*.entity{.ts,.js}'],
            synchronize: true
          }
        }
      }),

inject를 통해서 환경변수를 가져올 서비스를 지정해준다.

 

이제는 해당 환경에 대한 정보를 서버 시작 전에 넘겨줘야 한다.

이 쪽 부분에 해당하는 내용을 말이다.

 

현재 npm을 통해서 서버를 실행하고 있으니

package.json의 이쪽 부분을 수정해주면 된다.

 

우리는 런타임 환경을 부여하기 위해 cross-env 라이브러리를 설치했었다.

우리는 NODE_ENV를 줘야 하기에 NODE_ENV={원하는 값}을 주입해준다.

 

한 번 실행해서 원하는 데이터베이스에 값이 생기는지 확인해보자.

이렇게 설정하고 create-user.http를 실행하니 데이터베이스에 값이 원하는대로 들어가는 것을 볼 수 있었다.

 

728x90

자 이제 로그인을 하면 세션에 사용자 정보를 넣어두고, 다른 API를 요청하면 그 사용자 정보를 가져오도록 해보자.

 

우선 사용자가 로그인을 하면 세션에 사용자의 id를 넣어줘야 한다.

    @Post("/signIn")
    async signIn(@Body() loginUserDto: LoginUserDto, @Session() session: any): Promise<Users>{
        const user = await this.authService.signIn(loginUserDto)

        session.userId = user.id;

        return user;
    }

이렇게 user의 id를 먼저 넣어준다.

 

그리고 로그인을 해보면, 우선 다음과 같이 쿠키가 생긴 것을 볼 수 있다.

 

이제 이 정보를 다른 API에서 불러와야 한다.

 

일단 로그인 체크 API를 만들고 거기에서 사용자의 아이디를 콘솔로 출력해보자.

    @Get("/check")
    async checkLogin(@Session() session: any): Promise<string>{
        console.log(`userId: ${session.userId}`);
        return ""
    }

일단 사용자의 아이디가 출력되었다.

 

사용자 로그아웃도 구현해보자.

 

그냥 userId를 null로 바꿔주면 끝이다.

    @Post("/signOut")
    async signOut(@Session() session: any): Promise<void>{
        session.userId = null;
    }

로그아웃 API를 요청하고 다시 check 해보면 userId가 null로 출력되고 있었다.

 

이렇게 만들었지만, 항상 컨트롤러에서 세션을 통해 userId를 가져올 수는 없을 것이다.

 

로그인을 하지 않았다면 해당 경로의 접근을 막고, 데코레이터를 통해 사용자의 정보를 가져오도록 수정해보자.

@Authentication이라는 데코레이션으로 User의 정보를 가져올 수 있도록 만들어보자.

 

export const Authentication = createParamDecorator(
    (data: any, context: ExecutionContext) => {
        
    }
)

우선 다음과 같은 방법으로 데코레이터를 작성한다.

 

여기서 data는 데코레이터에 넘기로 넘기는 값, ExecutionContext는 NestJs에서 제공하는 Http요청이나 Websocket등 컨텍스트의 실행 정보를 담고 있다고 한다.

 

getType()을 통해 연결종류로 'http', 'rpc', 'ws' 중 하나를 반환하며, 우리는 이 중 http를 사용하기에 switchToHttp()를 통해서 http context를 반환한다.

 

그리고 해당 데코레이터에서 반환환 값은 

여기에서 받아서 사용한다.

 

        const httpRequest = context.switchToHttp().getRequest();

        const userId = httpRequest.session.userId;

이렇게 다음과 같은 방법으로 http로 변환하고 거기서 session을 가져와서 userId를 추출할 수 있다.

하지만 우리는 이 userId를 바탕으로 사용자 정보를 가져오고 싶다.

그렇기에 UserService가 필요하다.

하지만 이 UserService는 그냥 가져오는 것이 아니라, 의존성을 통해 주입받아야 한다.

그렇기에 여기서 우리는 의존성을 주입받을 수 있는 인터셉터를 사용해야 한다.

 

인터셉터를 통해 Session을 읽고 사용자를 조회한다.

그리고 그 조회한 사용자를 데코레이터를 통해 읽어오도록 만드는 것이다.

 

다시 인터셉터부터 만들어보자.

@Injectable()
export class ExtractUserInterceptor implements NestInterceptor {

    constructor(private readonly usersService: UsersService) {}

    async intercept(context: ExecutionContext, next: CallHandler<any>): Promise<Observable<any>> {

        //HTTP Context를 가져온다
        const request = context.switchToHttp().getRequest();

        //session에서 userId를 가져온다.
        const {userId}: {userId: number} = request.session || {};

        //userId가 없으면 인증에러를 반환한다.
        if(!userId) {
            throw new UnauthorizedException();
        }

        //User 정보를 데코레이터에서 가져올 수 있도록 context에 넣기
        request.curUser = await this.usersService.findOne(userId);

        return next.handle()
    }
}

우선 이렇게 만들어두고, 의존성을 주입받을 수 있도록 모듈에 인터셉터를 추가해준다.

 

@Module({
  imports: [TypeOrmModule.forFeature([Users])],
  controllers: [UsersController],
  providers: [UsersService, AuthService, ExtractUserInterceptor],
})
export class UsersModule {}

 

이제 User를 추출할 데코레이터를 다음과 같이 수정하고

export const Authentication = createParamDecorator(
    (data: never, context: ExecutionContext) => {

        const httpRequest = context.switchToHttp().getRequest();

        return httpRequest.curUser;
    }
)

 

 

인터셉터를 달아준 후 테스트 해보도록 하자.

 

이렇게 잘 나오는 것을 볼 수 있다.

 

이거를 컨트롤러마다 설정하기 복잡하다면, 다음과 같은 방법으로 모듈에 글로벌하게 설정할 수 있다.

@Module({
  imports: [TypeOrmModule.forFeature([Users])],
  controllers: [UsersController],
  providers: [
      UsersService, AuthService,
    {
      provide: APP_INTERCEPTOR,
      useClass: ExtractUserInterceptor,
    }],
})
export class UsersModule {}

 

경로 중 인증정보가 없다면 401, 403 에러를 반환하고 싶을 때가 있다.

그럴 때를 위해 CanActivate를 위해 AuthGuard를 만들어주자.

export class AuthGuard implements CanActivate {
    canActivate(context: ExecutionContext): boolean | Promise<boolean> | Observable<boolean> {
        const request = context.switchToHttp().getRequest();

        return request.session.userId;
    }
}

 

여기서는 userId가 존재하지 않으면 접근을 막는다.

 

다음과 같이 설정하고

 

로그아웃하고 API를 요청하면

이렇게 403으로 거부되는 것을 볼 수 있다.

 

 

+ Recent posts