Convention

팀 프로젝트를 진행할 때마다 팀원들이 각자 생각하는 API 설계 규칙이 달라서, 매번 새로운 회의를 하고 규칙을 작성하는 것이 번거롭고 시간 낭비가 되었습니다.이런 답답한 상황에서 팀원 모두를 설득할 수 있을 만큼 완벽한 RESTful API 설계 규칙을 만들기 위해 많은 노력을 기울였습니다!!!덕분에 팀원들을 설득하여 프로젝트를 빠르게 진행할 수 있었습니다. 원래 노션에 작성해두었던 이 문서를 다른 사람들에게도 도움이 될까 하여 블로그에 올려보게 되었습니다 :)<h2>1. 자원(리소스) 기반 URI</h2><ul><li>일관된 URI 구조: 모든 자원은 고유한 URI를 가짐. 자원은 간결하고 명확하게 식별되어야 합니다.</li></ul><h3>URL 설계 규칙</h3><ul><li>마지막에 / 포함하지 않기:<ul><li>예: <code spellcheck="false">http://api.test.com/users</code></li></ul></li><li>_(underbar) 대신 -(dash) 사용:<ul><li>예: <code spellcheck="false">http://api.test.com/users/post-comments</code></li></ul></li><li>소문자 사용:<ul><li>예: <code spellcheck="false">http://api.test.com/users/post-comments</code></li></ul></li><li>URL에 행위(method) 포함하지 않기:<ul><li>예: DELETE <code spellcheck="false">http://api.test.com/users/1/posts/1</code></li></ul></li><li>컨트롤 자원을 의미하는 URL에는 동사 허용:<ul><li>예: <code spellcheck="false">http://api.test.com/posts/duplicate</code></li></ul></li></ul><hr><h2>Restful API 설계 모범 사례</h2><img src="https://image.until.blog/thingk0/article/1718791191412" data-width="100%" data-align="center" alt="until-599"><img src="https://image.until.blog/thingk0/article/1718791228436" data-width="100%" data-align="center" alt="until-600"><img src="https://image.until.blog/thingk0/article/1718791344586" data-width="100%" data-align="center" alt="until-601"><img src="https://image.until.blog/thingk0/article/1718791581052" data-width="100%" data-align="center" alt="until-602"><img src="https://image.until.blog/thingk0/article/1718791600715" data-width="100%" data-align="center" alt="until-603"><img src="https://image.until.blog/thingk0/article/1718791633327" data-width="100%" data-align="center" alt="until-604"><img src="https://image.until.blog/thingk0/article/1718791656507" data-width="100%" data-align="center" alt="until-605"><img src="https://image.until.blog/thingk0/article/1718791687549" data-width="100%" data-align="center" alt="until-606"><h3>추가적인 PathVariable 및 QueryString 사용 예시</h3><img src="https://image.until.blog/thingk0/article/1718791707307" data-width="100%" data-align="center" alt="until-607"><h3>PathVariable과 QueryString</h3><hr><h3>PathVariable</h3><ul><li>정의: <code spellcheck="false">PathVariable</code>은 URL의 경로에 포함되는 변수를 의미합니다. 일반적으로 리소스의 식별자나 주요 속성을 나타내는 데 사용됩니다.</li><li>적합한 상황:<ul><li>특정 리소스 식별: 특정 리소스에 직접 접근할 때 사용합니다. 예를 들어, <code spellcheck="false">/users/{id}</code>에서 <code spellcheck="false">{id}</code>는 특정 사용자의 고유 식별자</li></ul></li></ul>입니다.<ul><li>리소스 계층 표현: 부모-자식 관계나 계층적 구조를 표현할 때 유용합니다. 예: <code spellcheck="false">/users/{id}/posts</code>는 특정 사용자의 모든 포스트를 나타냅니다.</li><li>장점:<ul><li>URL 경로의 일부로서 직관적이고 명확하게 특정 리소스를 지목합니다.</li><li>계층적이고 구조적인 URL을 만들 수 있어 API의 가독성이 향상됩니다.</li></ul></li></ul><h3>QueryString</h3><ul><li>정의: <code spellcheck="false">QueryString</code>은 URL의 <code spellcheck="false">?</code> 뒤에 오는 키-값 쌍의 집합입니다. 주로 옵션, 필터링, 정렬 또는 검색 조건 등을 지정하는 데 사용됩니다.</li><li>적합한 상황:<ul><li>데이터 필터링: 특정 기준에 따라 데이터를 필터링할 때 사용합니다. 예: <code spellcheck="false">/products?category=books&amp;price_below=20</code></li><li>정보 정렬: 데이터를 특정 순서로 정렬해야 할 때 사용합니다. 예: <code spellcheck="false">/posts?sort_by=date&amp;order=asc</code></li><li>검색 조건 적용: 키워드나 다양한 파라미터로 데이터를 검색할 때 유용합니다. 예: <code spellcheck="false">/users?name=John</code></li></ul></li><li>장점:<ul><li>URL 경로가 아닌 파라미터를 통해 유연한 데이터 조작과 검색을 할 수 있습니다.</li><li>다양한 파라미터 조합을 통해 복잡한 쿼리와 데이터 요청을 간편하게 처리할 수 있습니다.</li></ul></li></ul><hr><h2>2. HTTP 동사 활용</h2>HTTP 프로토콜은 다양한 동사(메서드)를 제공합니다. RESTful API 설계에서는 이러한 동사를 적절하게 활용하여 API의 의도를 명확하게 전달해야 합니다.<ul><li><code spellcheck="false">GET</code>: 리소스의 정보를 조회하기 위해 사용합니다.</li><li><code spellcheck="false">POST</code>: 리소스를 생성하기 위해 사용합니다.</li><li><code spellcheck="false">PUT</code>: 리소스의 정보를 업데이트하기 위해 사용합니다.</li><li><code spellcheck="false">DELETE</code>: 리소스를 삭제하기 위해 사용합니다.</li><li><code spellcheck="false">PATCH</code>: 리소스의 일부분을 업데이트하기 위해 사용합니다.</li></ul><hr><h2>3. 적절한 상태 코드 반환</h2>HTTP 상태 코드는 API의 응답에 포함되어 클라이언트에게 작업 결과를 알려줍니다. RESTful API 설계에서는 적절한 상태 코드를 반환하여 클라이언트가 요청에 대해 올바르게 대응할 수 있도록 해야 합니다. 일반적으로 사용되는 몇 가지 상태 코드는 다음과 같습니다:<ul><li>200 OK: 성공적인 GET, PUT, PATCH 요청.</li><li>201 Created: 성공적인 POST 요청.</li><li>204 No Content: 성공적인 DELETE 요청.</li><li>400 Bad Request: 잘못된 요청 형식.</li><li>401 Unauthorized: 인증되지 않은 접근.</li><li>403 Forbidden: 권한 없는 접근.</li><li>404 Not Found: 요청한 리소스가 없음.</li><li>500 Internal Server Error: 서버 내부 오류.</li></ul><hr><h2>4. 적절한 데이터 포맷</h2>모든 요청과 응답은 JSON 형태로 주고받습니다.<ul><li>예시 요청/응답 데이터 포맷:<ul><li>요청: <code spellcheck="false">{ "title": "The Great Gatsby" }</code></li><li>응답: <code spellcheck="false">{ "id": 3, "title": "The Great Gatsby" }</code></li></ul></li></ul><hr><h2>5. 적절한 인증과 권한 부여</h2>인증 방식은 API 키, OAuth, JWT 등을 활용합니다.<ul><li>모든 API 요청은 적절한 인증 토큰과 함께 전송되어야 합니다.</li></ul><hr><h3>참고문헌</h3><ul><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://velog.io/@tiger/API-RESTful-API">https://velog.io/@tiger/API-RESTful-API</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://library.gabia.com/contents/8339/">https://library.gabia.com/contents/8339/</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://medium.com/tech-pentasecurity/restful-api-%EB%84%A4%EC%9D%B4%EB%B0%8D-7c81bdb9da63">https://medium.com/tech-pentasecurity/restful-api-네이밍-7c81bdb9da63</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://velog.io/@gun_123/RESTful-API-%EC%84%A4%EA%B3%84-%EC%9B%90%EC%B9%99%EA%B3%BC-%EC%98%88%EC%8B%9C">https://velog.io/@gun_123/RESTful-API-설계-원칙과-예시</a></li></ul>

원래 혼자서만 몰래 보려고 만든 문서였지만, 다른 사람들에게도 도움이 되고자 그동안 제가 나름대로 정리해서 만든 RESTful API 설계 규칙입니다!!

내가 쓰려고 만든 RestfulAPI 설계 규칙 !

요즘 같이 신입들이 설 자리가 굉장히 없는 각박한 시기에, 얼마 전 운이 좋게 신입으로 게임 회사에 면접을 보게 되었습니다 🤣🤣🤣그런데 면접 중 다음과 같은 질문을 받을 수 있었는데, ‘포트폴리오를 확인해 보면 스프링 부트를 주로 사용해 왔는데, 스프링 부트는 보통 내장되어 있는 웹 서버로 Tomcat을 사용하는데도 불구하고 Nginx를 사용한 이유가 있을까요?’이러한 질문을 주셨는데 당시 많이 긴장되어 있는 상황이기도 하였고, 당장 생각나는 것은"저희가 프로젝트 환경상, EC2 한 대에서 프론트엔드와 백엔드를 함께 배포해야 하는 상황이었습니다. 따라서 하나의 도메인으로 모든 요청과 응답이 이루어지는데, 요청이 들어올 때 리버스 프록시 기능을 사용하기 위해 Nginx가 필요하기도 하였고, 보안적인 측면에서도 HTTPS를 사용해야 하기 때문에 Nginx를 사용했습니다."지금은 글로 작성하니까 나름 그럴싸하게 작성했지만, 실제로 대답할 때는 조금 어색하게 표현한 것 같아 후회가 듭니다.😅면접을 볼 때에는 당장 생각나는 것이 이것밖에 없었지만, 뒤늦게 면접관님의 의도를 떠올릴 수 있었습니다. 아마도 Nginx를 사용한 이유, 즉 웹 서버(WS)와 웹 애플리케이션 서버(WAS)의 차이점을 분명하게 이해하고 사용한 것인지를 물어보려고 하셨던 게 아닐까 하는 생각이 들었습니다.그래서 이제는 비슷한 질문을 받더라도 더 이상 실수하지 않게 다시 한 번 학습하고 리마인드를 해보려고 합니다.<hr>웹 서버(Web Server)는 웹 클라이언트(예: 웹 브라우저)로부터 HTTP 요청을 받아 정적 콘텐츠(HTML, CSS, JavaScript, 이미지 등)를 제공하는 소프트웨어입니다.<h2>웹 서버의 주요 역할</h2><h3>주요 기능</h3><ol><li>정적 콘텐츠 제공:<ul><li>HTML, CSS, JavaScript 파일 및 이미지 등과 같은 정적 파일을 클라이언트에 제공합니다. Q. 프론트엔드, 백엔드가 구분되어 사용되는 것이 보통입니다. HTML, CSS, JS 파일은 웹 서버에서 언제 어떤 상황에서 클라이언트에게 제공되는가 ? <ul><li>상황: 사용자가 웹 브라우저를 통해 특정 웹 페이지를 요청하는 경우<ul><li>사용자가 브라우저에서 <code spellcheck="false">http://example.com</code>을 입력하면, 브라우저는 해당 URL에 대한 HTTP 요청을 웹 서버로 보냅니다.</li><li>웹 서버(ex. Nginx)는 요청된 URL을 기반으로 적절한 파일을 찾아 클라이언트에 반환합니다. 여기서 정적 파일 제공이 이루어집니다.</li><li>예를 들어, Nginx와 같은 웹 서버가 <code spellcheck="false">/usr/share/nginx/html</code> 디렉토리에 웹페이지 파일을 저장하고 있다면, 다음과 같은 과정이 진행됩니다:<ul><li>사용자가 <code spellcheck="false">http://example.com/index.html</code>을 요청합니다.</li><li>웹 서버는 요청된 파일 경로를 확인하고, <code spellcheck="false">/var/www/html/index.html</code> 파일을 찾아 응답으로 반환합니다.</li></ul></li><li>HTML 파일 반환: 웹 서버는 <code spellcheck="false">index.html</code> 파일을 클라이언트(브라우저)에 반환합니다. 브라우저는 HTML 파일을 파싱하여 페이지의 기본 구조를 렌더링합니다.</li><li>CSS와 JavaScript 파일 요청: HTML 파일이 로드되면서, 페이지 내에 포함된 CSS 및 JavaScript 파일에 대한 추가 요청이 발생합니다. 예를 들어, HTML 파일에 다음과 같은 링크가 포함되어 있을 수 있습니다:<pre spellcheck="false"><code class="language-html">&lt;link rel="stylesheet" href="styles.css"&gt;
&lt;script src="app.js"&gt;&lt;/script&gt;</code></pre><ul><li>브라우저는 <code spellcheck="false">styles.css</code>와 <code spellcheck="false">app.js</code> 파일을 추가로 요청합니다.</li><li>웹 서버는 동일한 방식으로 이 파일들을 찾아 클라이언트에 반환합니다. </li></ul></li></ul></li><li>구체적인 예시사용자가 <code spellcheck="false">http://example.com</code>에 접속하면 다음과 같은 요청과 응답 흐름이 발생합니다:<ol><li>브라우저 요청: <code spellcheck="false">GET /index.html</code></li><li>웹 서버 응답: <code spellcheck="false">/var/www/html/index.html</code> 파일 반환</li><li>브라우저 요청: <code spellcheck="false">GET /styles.css</code></li><li>웹 서버 응답: <code spellcheck="false">/var/www/html/styles.css</code> 파일 반환</li><li>브라우저 요청: <code spellcheck="false">GET /app.js</code></li><li>웹 서버 응답: <code spellcheck="false">/var/www/html/app.js</code> 파일 반환 </li></ol></li></ul>이 과정을 통해 사용자는 웹 페이지를 볼 수 있게 되며, CSS로 스타일링된 페이지와 JavaScript로 동작하는 기능을 사용할 수 있게 됩니다. </li></ul></li><li>HTTP 요청 처리 및 응답:<ul><li>클라이언트의 HTTP 요청을 처리하고, 적절한 응답을 생성하여 반환합니다. </li></ul></li><li>URL 매핑 및 라우팅:<ul><li>요청 URL을 기반으로 적절한 파일이나 서비스로 요청을 라우팅합니다. 이는 리버스 프록시의 역할로, 클라이언트의 요청을 받아 적합한 백엔드 서버로 전달하고 결과를 다시 클라이언트에게 반환합니다. </li></ul></li><li>로드 밸런싱:<ul><li>여러 서버 간에 트래픽을 분산시켜 고가용성을 유지하고 성능을 향상시킵니다. </li></ul></li><li>보안 기능:<ul><li>SSL/TLS를 통한 데이터 암호화, IP 필터링, 사용자 인증 등 다양한 보안 기능을 제공합니다.</li></ul></li></ol><h3>웹 서버의 예시</h3><ul><li>Apache HTTP Server:<ul><li>오픈 소스 웹 서버로, 다양한 플랫폼에서 사용되며, 매우 널리 사용됩니다.</li></ul></li><li>Nginx:<ul><li>고성능 웹 서버로, 특히 높은 동시 연결 수를 처리할 수 있어 정적 파일 제공 및 리버스 프록시로 자주 사용됩니다.</li></ul></li></ul><hr>웹 애플리케이션 서버(Web Application Server, WAS)는 웹 서버와는 달리, 동적 콘텐츠를 생성하고 웹 애플리케이션의 비즈니스 로직을 처리하는 소프트웨어입니다. WAS는 클라이언트의 요청을 받아들여 데이터베이스와 상호 작용하고, 그 결과를 동적 웹 페이지 형태로 클라이언트에 반환합니다.<h2>웹 애플리케이션 서버의 주요 역할</h2><ol><li>비즈니스 로직 처리:<ul><li>클라이언트 요청을 처리하는 비즈니스 로직을 실행합니다. 예를 들어, 사용자의 로그인, 상품 검색, 주문 처리 등의 작업을 수행합니다. → 서블릿 기반 </li></ul></li><li>동적 콘텐츠 생성:<ul><li>JSP, 서블릿, EJB 등과 같은 기술을 사용하여 동적인 웹 페이지를 생성합니다. 클라이언트의 요청에 따라 실시간으로 콘텐츠를 생성하여 응답합니다. </li></ul></li><li>데이터베이스 연동:<ul><li>데이터베이스와 상호 작용하여 데이터를 조회, 삽입, 업데이트, 삭제하는 작업을 수행합니다. 이를 통해 클라이언트가 요청한 데이터를 처리하고 반환합니다. </li></ul></li><li>세션 관리:<ul><li>사용자 세션을 관리하여 사용자 상태를 유지하고, 인증 및 권한 부여를 처리합니다. 이를 통해 사용자의 로그인 상태를 유지하거나, 사용자별로 다른 콘텐츠를 제공할 수 있습니다. </li></ul></li><li>트랜잭션 관리:<ul><li>데이터베이스 트랜잭션을 관리하여 데이터의 일관성과 무결성을 보장합니다. 여러 작업이 하나의 트랜잭션으로 묶여 일관성 있게 처리되도록 합니다. </li></ul></li></ol><h3>웹 애플리케이션 서버의 예시</h3><ul><li>Apache Tomcat:<ul><li>오픈 소스 서블릿 컨테이너로, 서블릿과 JSP 기반의 웹 애플리케이션을 실행합니다.</li></ul></li></ul><hr><h2>정리</h2><img src="https://image.until.blog/thingk0/article/1716860951310" alt="until-318"><h3>이유 1: 정적 콘텐츠 제공</h3><ul><li>Nginx는 정적 콘텐츠(예: 이미지, CSS, JavaScript 파일 등)를 매우 효율적으로 제공할 수 있습니다. 이를 통해 스프링 부트 애플리케이션이 정적 리소스를 제공하는 부담을 줄이고, 동적 콘텐츠 제공에 집중할 수 있게 합니다.<blockquote>하지만, 보통 프론트엔드와 API 서버 조합으로 많이 사용하기 때문에, 사실상 정적 콘텐츠 제공에는 큰 메리트를 느끼기 어려웠습니다. 그러나 프론트엔드가 SPA일 경우에는 매우 유용하다고 생각합니다.</blockquote></li></ul><h3>이유 2: 리버스 프록시</h3><ul><li>리버스 프록시로서 Nginx는 클라이언트 요청을 스프링 부트 애플리케이션으로 전달합니다. 이를 통해 애플리케이션 서버를 보호하고, 로드 밸런싱 및 SSL 종료(SSL termination) 등의 기능을 제공합니다.<blockquote>실제로 제가 Nginx를 사용하는 가장 주된 이유는, 보통 프로젝트를 진행할 때 서버 인스턴스를 하나만 사용할 수 있는 상황이 많아서, 어쩔 수 없이 서버 안에서 프론트엔드, 인프라, 백엔드를 모두 배포해야 했기 때문입니다.이러한 이유로 Nginx의 리버스 프록시 기능은 매우 유용하고 필요했습니다. 그래서 다행히도 면접에서 가장 먼저 떠올린 리버스 프록시를 답변할 수 있었습니다 !!</blockquote></li></ul><h3>이유 3: 로드 밸런싱</h3><ul><li>로드 밸런싱을 통해 여러 대의 스프링부트 인스턴스에 트래픽을 분산시킬 수 있습니다. 이를 통해 고가용성과 성능을 향상시킬 수 있습니다.<blockquote>면접 중 로드 밸런싱 관련 질문을 받았고, 당연히 Nginx를 통해 로드 밸런싱이 가능하다는 것은 알고 있었습니다.하지만 더 좋은 답변을 위해서는 추후에 블루-그린 배포를 적용하거나 스케일 아웃을 염두에 두었을 때, 로드 밸런싱 기능이 필요하기 때문에 Nginx가 필요하다는 답변을 떠올리지 못했다는 것이 뒤늦은 후회로 남네요..🥲</blockquote></li></ul><h3>이유 4: SSL/TLS 처리</h3><ul><li>SSL/TLS 처리를 Nginx가 담당함으로써 스프링부트 애플리케이션은 암호화된 트래픽을 직접 처리하지 않아도 되므로, 성능과 보안 측면에서 유리합니다.</li></ul><h3>이유 5: 보안</h3><ul><li>보안 설정 및 접근 제어를 Nginx 레벨에서 관리함으로써 애플리케이션의 보안성을 향상시킬 수 있습니다. IP 제한, DDoS 방어, WAF(Web Application Firewall) 등을 설정할 수 있습니다.</li></ul><h3>이유 6: 고성능</h3><ul><li>고성능의 Nginx는 적은 리소스로 많은 요청을 처리할 수 있어, 특히 많은 동시 접속이 발생하는 상황에서 유리합니다.<blockquote>“ Nginx는 비동기 이벤트 기반으로 설계되어, 적은 리소스로도 많은 수의 동시 연결을 효율적으로 처리할 수 있고 다중 워커 프로세스를 통해 병렬로 작업을 수행하여 성능을 극대화하며 메모리를 효율적으로 사용하여 더 많은 요청을 처리할 수 있습니다. "라고도 대답할 수 있다면 아마 만점짜리 답변이겠죠..?</blockquote></li></ul><hr>즉, 저는 리버스 프록시와 보안 부분에서는 어느 정도 정답에 가까운 대답을 했다고 생각해요 ! 하지만 기억을 되돌려보면, 로드 밸런싱 부분에 대해서도 잠깐 질문을 받았는데, 급히 다른 질문으로 넘어갔던 것이 아쉽고... Nginx를 통해 로드 밸런싱, 성능, 그리고 정적 콘텐츠 제공에 대해서도 답변을 할 수 있었다면 더 좋았을 것 같아요.다음에 비슷한 질문을 받는다면, 기존 답변에 보완해서 더욱 멋진 답변을 해보도록 하겠습니다. 😃

최근 게임 회사 면접에서 스프링 부트와 Nginx 사용 이유에 대한 질문을 받았습니다. 이번 포스팅에서는 웹 서버와 웹 애플리케이션 서버의 차이를 명확히 이해하고, Nginx 사용 이유를 깊이 있게 다뤄봅니다.

WAS가 있음에도 불구하고, 웹서버인 Nginx 를 사용하는 이유 - 개발자 면접 리마인드

Frontend

<img src="https://image.until.blog/ninefloor/article/1729926668847.jpeg" data-width="100%" data-align="center" alt="1895"><h1><code spellcheck="false">path alias</code>?</h1><img src="https://image.until.blog/ninefloor/article/1729926632812.png" data-width="75%" data-align="center" alt="1894">상대 경로를 이용하면 프로젝트가 커질수록 <code spellcheck="false">../../src</code> 처럼 복잡하여 구조파악이 어렵고 불편하다. 이를 해결하고 개발 경험을 증진시키는 해결 방법으로 대표되는 것이 path alias이다.path alias는 경로에 별칭을 붙인다는 뜻으로, 상대경로로 인해 복잡해지는 import를 간략하게 만드는 방법이다. 보통 모듈 번들러에서 해당 기능을 지원하며, 번들러마다 적용하는 방법이 약간씩 다르지만 맥락은 대부분 비슷하다. TS를 사용하는 경우 추가로 <code spellcheck="false">tsconfig.json</code>에도 작성해주어야 한다.path alias를 적용하면 해당 컴포넌트가 어디에 속해있는지 쉽게 파악할 수 있고 import 역시 편해진다.<blockquote> CRA의 경우 webpack을 사용하는데, webpack config를 따로 정의할 수 없기 때문에 eject하거나 craco와 같은 오버라이딩 라이브러리를 이용해 설정해야 한다.</blockquote><h1>Path Alias with Vite</h1>번들러 중 하나인 Vite에서도 마찬가지로 지원하는데, <code spellcheck="false">vite.config.js</code> 파일에 아래와 같이 작성하면 된다.<pre spellcheck="false"><code class="language-typescript">import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import path from 'path';

// &lt;https://vitejs.dev/config/&gt;
export default defineConfig({
 plugins: [react()],
 resolve: {
	// find: 해당 경로의 이름. 실제로 import문에 적용된다.
	// replacement: 경로 지정. 이때, path.resolve를 이용한다.
 alias: [
 { find: '@', replacement: path.resolve(__dirname, 'src') },
 {
 find: '@components',
 replacement: path.resolve(__dirname, 'src/components'),
 },
 {
 find: '@assets',
 replacement: path.resolve(__dirname, 'src/assets'),
 },
 {
 find: '@page',
 replacement: path.resolve(__dirname, 'src/page'),
 },
 {
 find: '@util',
 replacement: path.resolve(__dirname, 'src/util'),
 },
 {
 find: '@recoil',
 replacement: path.resolve(__dirname, 'src/recoil'),
 },
 ],
 },
});
</code></pre><h3>VScode 자동완성 설정 (w/ JavaScript)</h3>단, 해당 설정을 하고 나면 VSCode는 이를 인지하지 못해 자동완성이 안된다. 이 때는 <code spellcheck="false">jsconfig.json</code>에 아래와 같이 path alias를 정의해주면 정상적으로 자동완성이 동작한다. (TS의 경우 <code spellcheck="false">tsconfig.json</code>)<pre spellcheck="false"><code class="language-jsx">{
 "compilerOptions": {
 "baseUrl": ".",
 "paths": {
 "@/*": ["./src/*"]
 }
 }
}
</code></pre>

쩜쩜슬래시 지옥을 벗어나보자

Path Alias with Vite (+ 자동완성 설정)

백엔드와 관련된 자료들을 올립니다.

🖥 백엔드

잘봤습니다!! 서버 구성이 이쁘네요
혹시 API Gateway 를 사용하지 않은 이유가 궁금합니다! 메시지큐.. 때문인가요?

아주 흥미로운 글이네요 :) 최고!

감사합니다! DB에 로직 빼는게 참 힘들죠.. 저도 api 하나 만들 때마다 레포지토리에 함수 하나씩 생기는 것 같아 가슴이 참 아픈데.. 열심히 고민하고 노력해봅시다

잘봤습니다! DB단에 최대한 로직을 뺴려고 노력하는데 애매한 부분들이 참 많은거같아요

설계할때부터 잘못되었나? 이런 생각도 많이 들더라구요

오.. SpEL에 대해서 알고는 있었지만 잘 몰라서 활용을 잘 못했었거든요 ㅠ 디폴트 값도 조금 야매로 처리를 했었는데 SpEL이 생각보다 좋은 녀석이었군요.. 바로 활용해봐야겠네요!! 잘 읽었습니다 :)

- 뚱땅뚱땅 평화로운(?) 푸시알림 기능 개발 시간 -예약 발송 기능이 필요해 방법을 알아보고 있었다.어찌저찌 구글링을 통해 NestJS Task Scheduling - Dynamic timeouts에 대해 알게 되었다 !스케줄러는 이미 사용해본 경험이 있었는데(매일 @@시 ##분 마다 동작 등), 동적으로 필요에 따라 생성했다 없앴다 할 수도 있었다니 ! (문서를 끝까지 읽어본 적이 없는 사람)사용 방법은 어렵지 않아서 내가 원하는 타이밍에 푸시알림을 발송할 수 있게 되었다. 너무너무 단순하다! <a target="_blank" rel="noopener noreferrer nofollow" href="https://docs.nestjs.com/techniques/task-scheduling#dynamic-timeouts">진짜로</a>즉시 발송과 예약 발송 모두 잘 작동하는 것을 확인하고 필요한 곳 마다(6~7군데 정도) 알림 발송 코드를 때려 박았는데, 막상 이렇게 해놓고 나니 나중에 수정이 필요하거나 또 푸시알림이 필요한 곳이 생기면 같은 작업을 반복해야한다고 생각하니 좀 간지가 안나는 것 같아서 정리를 좀 하기로 했다.일단 내가 원하는 것이 무엇인가 정리<ul class="tight" data-tight="true"><li>"특정 상황"에 유저에게 푸시알림을 보내야함 (FCM 사용)</li><li>즉시발송/예약발송</li><li>현재는 6~7가지 상황이 있지만 점점 늘어날 수 있음</li><li>특별한 경우를 제외하고 어드민 페이지에서 푸시알림을 관리하고 싶음<ul class="tight" data-tight="true"><li>발송상황, 발송타이밍, 메시지 내용 관리 / 발송 내역 관리 등</li></ul></li><li>위 내용은 단일 대상에게 자동으로 보내는 알림. 다수에게 보내는 수동 알림은 따로 처리</li></ul>필요한 api 마다 푸시알림을 쏘는 코드를 심는 것 보다는 한 지점(?)에서 처리하고 싶었는데 그러기 위해선 어떤 요청이 들어왔는지 구분하고 푸시알림이 필요한 요청 및 상황인지 판단, 알맞은 대상 및 내용 구성을 할 수 있어야 했다.어떤 요청인지("특정 상황")는 요청 end point로 구분할 수 있다.발송 대상은 요청에 jwt 토큰도 있고 앱에서 오는 요청이 아닌 경우(서비스 특성 상 서버가 임베디드와도 통신 중) 식별 가능한 데이터가 함께 담겨 있어 어렵지 않았다.내용 역시 왔다갔다하는 데이터들로 충분히 구성할 수 있다.즉시발송/예약발송은 0초 뒤 발송, n초 뒤 발송 으로 설정이 가능하다.이런 점들을 바탕으로 DB를 꾸려보았다. 푸시알림을 보내길 원하는 상황과 내용을 미리 등록해둘 수 있도록.<pre spellcheck="false"><code class="language-typescript">{
 알림발송상황: "유저가 ~~한 상황";
 endPoint: "/request/endpoint";
 n밀리초뒤발송: 300000;
 푸시알림제목: "이것은";
 푸시알림내용: "name씨에게 보내는 푸시알림";
 내용에들어가는변수이름: ["name"];
 클릭시이동url: "어디어디";
}</code></pre>문제는 한 곳에서 처리하려면 과연 그 한 곳은 어디로 해야 좋을까 였다. 미들웨어, 인터셉터 등 뭔가 이것저것 알긴 아는데 정확한 작동 방식이나 그런 것을 아직 완전히 깨우치지 못한 상태라 GPT씨에게 상담 요청을 했다.위 상황들을 죽 설명하고 어쩌면 좋을지 물어보니 그(?)(그녀?) 역시 미들웨어나 인터셉터에 심을 것을 추천해주었는데, 간단한 테스트와 모든 데이터를 처리한 뒤 응답을 보내기 직전에 푸시알림을 쏘고 싶다는 추가 질문으로 인터셉터를 활용하는 것으로 확정을 지었다.이렇게 내가 원하던 대로 '한 곳' 까지 정해졌다.- 뚱땅뚱땅 코딩 타임 -그렇게 뚱땅뚱땅 코드를 작성해놓고 테스트를 하다보니 문제점들이 발견되었다.<ul class="tight" data-tight="true"><li>n시간 뒤 어떤 사람에게 발송하도록 예약해둔 메시지를 만약 그 사람이 특정 조건을 만족한 경우 예약을 취소해야 함</li><li>예약을 해둔 메시지들이 만약 서버가 재시작되면 스케줄러가 초기화되면서 사라짐</li></ul>여러 고민과 GPT씨와의 상담 끝에 두 가지 문제점 모두 스케줄러와 DB를 함께 활용해 해결할 수 있다는 결론을 내렸다.첫번째 문제는 고유한 예약 번호와 함께 푸시알림 내역을 저장해뒀다가 원하는 상황에 예약을 취소할 수 있도록 했다. 예약을 취소하게 되는 상황은 당장에는 한가지 상황 뿐이라 중앙처리 말고 해당 api에서 하도록 했다.나중에 조금 더 발전시킬 필요가 있을 것 같다.두번째 문제는 발송 상태[발송완료/발송예약/발송취소]를 함께 저장해뒀다가 <a target="_blank" rel="noopener noreferrer nofollow" href="https://docs.nestjs.com/fundamentals/lifecycle-events">OnApplicationBootstrap</a>을 사용해 서버가 재시작될 때 발송예약 상태인 메시지들을 다시 스케줄러에 집어넣어주도록 했다.어차피 발송 내역을 저장하기로 해서 DB도 이미 구성해뒀기 때문에 몇 개의 필드만 더 추가하면서 사건을 해결할 수 있었다.대략적인 형태<pre spellcheck="false"><code class="language-typescript">import { Injectable, OnApplicationBootstrap } from '@nestjs/common';
import { firebaseAdmin } from 'src/config/firebase.config';
import { SchedulerRegistry } from '@nestjs/schedule';
@Injectable()
export class PushMessageService implements OnApplicationBootstrap {
	constructor(private readonly schedulerRegistry: SchedulerRegistry) {}
async onApplicationBootstrap() {
	// 발송예약 상태인 메시지들을 다시 스케줄러에 등록
}

async fcmSendMessage(message, sendAfterMilliSeconds, timeoutName, history) {
	const timeout = setTimeout(async () =&amp;gt; {
		await firebaseAdmin
			.messaging()
			.sendEachForMulticast(message)
			.then((res) =&amp;gt; {
				console.log('success: ', res);
		})
		.catch((err) =&amp;gt; {
			console.log('error: ', err);
		}); 
 	// history(발송내역)를 사용해 에약발송인 경우 발송예약 &amp;amp;gt; 발송완료로 업데이트
 	// ~ code ~
	
 	// 발송한 뒤에 스케줄러에서 삭제
		this.schedulerRegistry.deleteTimeout(timeoutName);
		}, sendAfterMilliSeconds);
	this.schedulerRegistry.addTimeout(timeoutName, timeout);
}

async sendAutoPushMessage(endPoint) {
	// 인터셉터에서 호출해 사용
	// 푸시알림 보낼지 말지 판단 후 내용 구성해 발송 예약
}}</code></pre>이런식으로 구현을 해놓았지만 솔직히 지금도 마음에 썩 들지는 않아서 계속 고민 중이다. 조금 더 깔끔하게 할 수 있을 것 같은데 막 아이디어가 떠오르지는 않아서 다른거 할 거 하면서 계속 지켜보는 중이다..

이전 블로그 주소

깃허브