1. UserService 구현

이 글은 Angular 카테고리의 ""에서 구현했던 Angular 애플리케이션을 토대로 MSA prototype architecture를 구성하는 내용을 담고 있습니다. 

실제 구현 방법을 공유하려는 목적보다는 아키텍쳐아키텍처 구성을 공유하고자 하는 목적이므로, 아키텍처의 변화나 이슈 사항에 초점을 맞춰 읽으시길 바랍니다.

 

따라서 Angular에서 사용했던 어플리케이션을 가져와 사용할 것이나, 구조는 변경될 것입니다. 

AS-IS	TO-BE

AS-IS에서는 User정보를 저장하는 방법으로 Angular가 제공하는 inmemoryDB를 사용하고 있었습니다.

TO-BE에서는 이를 제거하고 MongoDB를 사용하기 위해 UserService를 구현했습니다.

 

1. UserService API

UserService에서 제공하는 API는 6가지입니다.

---

2. Webflux CORS Configuration

웹 브라우저의 URL과 어플리케이션 내에서 ajax로 요청하는 URL의 도메인이 다를 경우, 보안상 위험하여 요청이 불가합니다. 따라서 CORS(Cross-origin resource sharing) 설정을 해주어야 합니다.

처음 전송된 리소스(www.A.com)의 도메인과 다른 도메인(www.B.com)으로 리소스를 요청하면 브라우저에서 www.B.com으로 실제 요청을 보내지 않고 서버가 CORS에 대해 허용하는지 확인하는 작업을 먼저 수행합니다.

Http Method 중 OPTIONS을 이용해 서버가 CORS에 대해 허용하는 것을 확인하면 그제야 실제 요청을 보내게 됩니다. 따라서 CORS에 대한 설정은 요청을 받는 서버에서 수행해야 합니다. 

Webflux에서 CORS를 설정하기 위해서 WebFluxConfigurer를 이용합니다.

@Configuration
public class WebFluxConfig {
    @Bean
    public WebFluxConfigurer corsConfigurer() {
        return new WebFluxConfigurerComposite() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/**").allowedOrigins("*")
                        .allowedMethods("*").allowCredentials(true).allowedHeaders("*").exposedHeaders(HttpSessionConfig.X_SESSION_ID);
            }
        };
    }
}

• allowOrigins: origin이 달라도 요청을 허용하기 위해 추가해야 합니다.
• allowMethods: 특정 HttpMethod에 한해서만 요청을 허용할 수 있습니다.
• allowedHeaders: client에서 header를 임의로 추가해서 보낸다한들, 서버에서 허용해주지 않으면 받을 수 없습니다. 서버에서 request에 담겨있는 header정보를 얻고자 한다면 allowedHeaders에 추가해야 합니다.
• exposedHeaders: server에서 response 보낼 때 header를 추가하더라도, 서버에서 허용해주지 않으면 클라이언트에서 사용할 수 없습니다. (개발자 도구의 네트워크에서는 확인 가능하지만 직접 사용할 수는 없습니다.) 클라이언트에서 response에 담겨있는 header정보를 얻고자 한다면 exposedHeaders에 추가해야 합니다.

---

3. Angular http request

 

inmemoryDB에 대한 URL을 UserService서버의 URL로 변경합니다. response가 다르므로 이에 대한 변경이 필요합니다.