작성자 없음
작성자 정보가 삭제된 글입니다.
작성
·
1.5K
0
안녕하십니까. 기선님처럼 되고싶은 1년차 주니어 개발자입니다.
제 개인 프로젝트 중에 현재는 동기방식 restTemplate으로 한번에 여러 군데에 요청을 던지는 기능이 구현되어 있는데 일부 요청이 오래 걸리는 것들이 있어서 스레드를 오래 물고있다는 판단을 하여 해당 기능을 nio 방식으로 전환하려고 합니다.(webclient)
웹서버는 io/nio모두 지원하는 undertow를 사용하고 있으며, 스프링 mvc를 사용하고 있습니다. 본론으로 제가 해당 프로젝트에 한번 외부로의 요청에 각각 응답시간이 다른 여러곳에 일부는 오래걸리는 요청을 던지기 위해 비동기 처리로 수정하여 개발하려고 하는데, @Async나 CompletableFuture말고 webflux를 추가하여 mvc+webflux의 형태로 개발해도 괜찮을지 여쭤보고 싶습니다.(이게 개인 프로젝트가 아닌 실무에서도 가능할지)
webflux와 mvc를 같이 쓰면 않좋다는 이전 토비님 말씀과 예전 구글링 글들도 있지만, 제 개인적인 생각에는 undertow는 예전 3.0 서블릿과는 다르게 io/nio를 함께 처리해주기 때문에 webflux + mvc 두개를 같이 써서 필요한 부분에 비동기 처리중에서도 pub/sub구조와 backpressure가 구현되어 있는 webflux-reacotr를 일부 도입해도 괜찮지 않을까하여 여러곳들을 전전하며 찾아보고 있었습니다.
제 부족한 실력으로는 어깨너머로 알게된 지식으로 스스로 원하는 결론을 그냥 내린것 같은 생각이 강하게 들고, 마땅한 결론에 도달하지 않아서 여쭙고싶습니다!!!!!
답변 1
1
"webflux와 mvc를 같이 쓰면 않좋다는 이전 토비님 말씀과"에 대한 근거는 무엇인가요? 어디서 그런 말씀을 하셨을까요? 여기서 "mvc"는 무슨 뜻으로 말씀하시는건가요? 스프링 MVC를 말씀하시는건가요 아니면 서블릿 기반의 애플리케이션을 스프링 MVC라고 말씀하신건가요? 그것도 아니면 순수한 MVC 패턴을 말하시는건가요?
우선 mvc는 문맥상 틀린 표현같습니다. 아마도 mvc대신에 "서블릿 기반의 애플리케이션"이라고 했어야 할 것 같아요. 스프링 MVC는 일종의 추상화된 API이고, 그런 API를 통해서 서블릿 기반의 애플리케이션을 만들거나, Webflux 기반의 애플리케이션을 만들 수 있습니다. 따라서, mvc를 만약에 스프링 MVC라고 말한거라면.. 토비님이 해당 발언 당시 단어 선택을 잘못했거나 저런 말을 했을리가 없습니다. 만약에 저렇게 말씀하셨다는 근거가 있다면 꼭 좀 보내주세요. 토비님 좀 놀릴 수 있게...
"서블릿 기반의 애플리케이션"을 뜻한 거라면 더이상 "mvc" 라고 표현하시면 안됩니다. 스프링 5이전까지는 어쩌면 그렇게 표현해도 괜찮았을텐데요. 5부터는 Webflux도 지원하게 되면서 이젠 좀 더 구체적으로 표현해야하는 상황이 되었네요. 아무튼, 그런 뜻이라면 맞습니다. 스프링 MVC는 둘 중에 하나를 선택해야되요. 대신 그렇다고해서 웹플럭스에서 쓸 수 있는 WebClient를 서블릿 애플리케이션에서 쓸 수 없다는 뜻은 아니고 오히려 그렇게 쓰는 방법을 점진적인 웹플럭스를 적용하는 방법으로 스프링 진영에서도 추천한 적이 있습니다.
정리하자면, 서블릿 기반의 애플리케이션에서 WebClient는 쓰셔도 됩니다.
다만 그걸가지고 "mvc+webflux 형태"라고 지나치게 일반화하거나 단어를 곡해해서 말한다거나, 더 나아가 MVC(가 무슨 뜻으로 쓰인 단어인지 모르니)와 Webflux를 같이 써도 되는건가? 라고 질문하는것은 답이 뭐든지간에 크게 의미가 없을 것 같습니다.
감사합니다.
https://spring.io/img/extra/reactive-5.svg
spring io에는 이런식으로 나눠져있더군요
spring webflux와 spring MVC를 대척점에 두고 비교를 하고 있어요..