Jonghyun Jonghyun

웹소켓 애플리케이션의 대표적인 사례는 채팅이라고 할 수 있습니다. 하지만 그 외에도 현대 애플리케이션의 여러 웹 서비스 중에서는 특정 조건에 따라 서버에서 클라이언트(사용자)에게 서비스를 제공하기도 합니다. (사용자가 서버에 서비스를 요청하지 않더라도요.) 우리 일상에서 보면 모바일 앱에서 푸시 알림을 떠올려볼 수 있겠죠. 웹 기술로 보면 "pub/sub"을 생각하면 될 것 같습니다. 일정 토픽(주제)에 대해 '구독'설정을 해두면, 서버에서 사용자 방향으로 '발행' 서비스를 수행할 수 있습니다. 자, 이제 Spring.io 의 튜토리얼을 참고해서 Spring Boot 프로젝트를 준비해 보겠습니다. https://spring.io/guides/gs/messaging-stomp-websocket/ Getti..

출처: https://www.baeldung.com/spring-mvc-image-media-data 1. Overview 본 포스트에서는 Spring MVC 프레임워크를 사용하여 이미지 및 기타 미디어를 리턴하는 방법을 살펴봅니다. Message Conversion, Content Negotiation 및 Spring의 리소스 추상화로부터 이점을 얻는 접근 방식으로 이동하는 것보다 HttpServletResponse를 직접 조작하는 것부터 시작하여 여러 접근 방식에 대해 알아보겠습니다. 2. HttpServletResponse 사용하기 이미지 다운로드의 가장 기본적인 접근 방식은 response 객체에 대해 직접 작업하고 순수한 Servlet 구현(implement)을 모방하는 것 입니다. @Reque..

안녕하세요! 신규 프로젝트를 시작할 때 우리 개발자들이 흔히 하게 되는 고민 중에 하나이죠. 새로운 마음으로 이번에는 잘(?) 해보자!! 프로젝트의 폴더(파일) 구조를 잡는 것입니다. 앞 포스트에서는 React의 프로젝트 구조잡기에 대해 살펴봤습니다. Backend로는 스프링 부트를 사용하고 있는데요. 우선 어느 정도 정리는 해서 프로젝트를 진행하고 있습니다. React나 Vue.js 등 프론트엔드에서 프로젝트 구조 잡기할 때 참고하였던 모델은 SPA(Single Page Application)과 PWA(Progressive Web App)이었습니다. 백엔드의 경우는 DDD(Domain Driven Design) 전략을 참고하려고 합니다. MSA(Microservice Architecture)와도 연결되..

출처 : https://stomp.github.io/ STOMP STOMP is a very simple and easy to implement protocol, coming from the HTTP school of design; the server side may be hard to implement well, but it is very easy to write a client to get yourself connected. For example you can use Telnet to login to any STO stomp.github.io What is it? STOMP는 심플(또는 스트리밍) 텍스트 지향 메시징 프로토콜입니다. STOMP는 양방향 네트워크 프로토콜 기반으로 STOMP 클라이언트는..

1. 개요 본 포스트에서는 Spring AMQP 프레임워크를 사용하여 AMQP릉 통한 메시지 기반 통신을 살펴보겠습니다. 2. 메시지 기반 통신 메시징(Messaging)은 애플리케이션 사이에 통신을 위한 기술입니다. 동기적인 요청/응답 기반 아키텍처 대신 비동기 메시지 전달에 의존합니다. 메시지 생산자(Producer)와 소비자(Consumer)는 메시지 브로커라고 하는 중간 메시징 계층에 의해 분리됩니다. 메시지 브로커는 메시지의 퍼시스턴트 스토리지, 메시지 필터링 및 메시지 변환과 같은 기능을 제공합니다. Java로 개발된 애플리케이션 간의 메시징은 일반적으로 JMS(Java Message Service) API가 사용됩니다. 서로 다른 벤더와 플랫폼 간의 상호 운용성을 위해, JMS 클라이언트와 ..

1. 개요 본 포스트에서는 "메시지 큐"와 "Pub/Sub"을 살펴보겠습니다. 이들은 2개 이상의 서비스가 서로 통신하기 위해 분산된 시스템에서 사용되는 일반적인 패턴입니다. 2. 메시지 큐 메시지 큐는 퍼블리싱 서비스와 큐를 거쳐 동신하는 여러 컨슈머 서비스로 구성됩니다. 이 통신은 전형적으로 단방향의 특징을 가집니다. 위 그림에서 퍼블리셔는 'n+1'번째 메시지를 큐에 넣고 있습니다. 그리고 n개의 메시지들이 이미 큐에 존재하고 있고 소비되기를 기다리고 있습니다. 우측에는 큐의 메시지를 기다리는 'A'와 'B' 2개의 consuming 서비스를 가지고 있죠. 다음 상황을 고려해 보겠습니다. 먼저, 퍼블리셔의 메시지가 큐의 마지막에 들어갔습니다. 다음으로, 우측을 살펴보겠습니다. 소비자 'A'가 메시지..