<pre spellcheck="false"><code class="language-javascript">async function picToBase64(src) {
 return new Promise(async (resolve) =&gt; {
 const response = await fetch(src);
 const blob = await response.blob();

 const reader = new FileReader();
 reader.onloadend = () =&gt; resolve(reader.result);
 reader.readAsDataURL(blob);
 });
}</code></pre>src를 받아서, fetch를 통해 리스폰스를 blob으로 받아온다.그 후 FileReader를 이용해서 blob을 dataUrl로 읽어와주면 된다.<pre spellcheck="false"><code class="language-javascript">const base64Result = await picToBase64(url)</code></pre>그러면 다음과 같이 사용할 수 있다.

자바스크립트로 이미지를 String으로 변환해보기!

이미지 url로 base64 string으로 변환하기

State of CSS 2024 설문이 시작되었습니다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://survey.devographics.com/en-US/survey/state-of-css/2024">https://survey.devographics.com/en-US/survey/state-of-css/2024</a>설문은 11개 페이지에 총 소요 시간 약 20분~25분 정도 되는 것 같습니다.최신 기술항목들과 들어보지 못했던 기술들에 대한 정보와 사용사례 등을 엿볼 수 있는 좋은 기회가 되겠죠.설문을 진행하다보면,<img src="https://image.until.blog/ganymedian/article/1724427177172" alt="until-1266">설문항목 박스 우상단에 “+” 아이콘이 있습니다.자세히 알아보고 싶거나 흥미로운 항목일 때, 우상단 아이콘을 클릭하면 해당 기술항목이 차곡차곡 보관되고, 설문 종료시에 이를 모두 모아서 이메일로 받아볼 수 있습니다.이메일에는 모질라 재단의 공식문서 링크가 각각 포함되어 있습니다. 공부해야 할 기술 항목들을 이메일에서 하나씩 클릭해서 학습할 수 있겠죠...설문 결과 발표는 매우 늦습니다. 아예 궁금해 하지 않는 쪽이 정신건강에 이롭습니다.State of […] 설문조사에서는, 매년 일본인 개발자들은 눈에 뜨이지만 한국인 개발자의 참여는 목록에 보여지지도 않고 있는데, 이 점이 기분 안좋아요. 우리도 활발하게 참여해서 내년 부터는 Korean 이 리스트에 보여지면 좋겠다는 생각을 해봅니다...그리고, 설문 종료시에 무슨 의미인지는 잘 모르겠습니다만, 스코어가 뜹니다. 똬~악!!<img src="https://image.until.blog/ganymedian/article/1724427218896" alt="until-1267">상위 74% 라면.. 하위 27% 라는 거죠?? ㅋㅋㅋㅋ 기분 꿀꿀해지는군요.

State of CSS 2024 설문이 시작되었습니다.https://survey.devographics.com/en-US/survey/state-of-css/2024설문은 11개 페이지에 총 소요 시간 약 20분25분 정도 되는 것 같습니다.최신 기술항목들과 들어보지 못했던 기술들에 대한 정보와 사용사례 등을 엿볼 수 있는 좋은 기회가 되겠죠.설문을 진행하

State of CSS 2024 Survey

🍎 Mac

맥북에서 터미널에서 code 커맨드라인을 지정해두고 해당 명령어를 통해 vscode를 실행하는데 실행할 때마다 dock에 vscode가 중복으로 생성되는 문제가 있었다.<img src="https://image.until.blog/morethanmin/article/1715356082565" alt="until-3">한동안 습관적으로 지워주면서 사용하고 있다가 매번 귀찮다는 생각이 들어서 원인을 찾아보았다.vscode 레포에서 동일한 증상을 겪고 있다는 <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/microsoft/vscode/issues/60579">이슈</a>를 발견해서 찾아보니, vscode와 관계없이 실행중인 상태의 애플리케이션을 터미널을 통해 실행하는 경우 발생하는 이슈라는 것을 알게 되었다.해결책은 크게 두가지가 있었다.<h2>Disable "Show suggested and recent apps in Dock"</h2>최근 사용한 앱을 독에 띄워주는 기능 자체를 끄는 것이다.해당 기능 자체를 끄는 것이기에 해당 영역자체가 사라진다.<h2>Edit <code spellcheck="false">code</code> function</h2>기존 code 명령어를 수정함으로써 해결이 가능하다.<code spellcheck="false">vim ~/.zshrc</code> 를 입력해 기존 <code spellcheck="false">code</code> 명령어를 아래와 같이 수정해보자.<pre spellcheck="false"><code class="language-auto">code() {
 if [ -t 1 ] &amp;&amp; [ -t 0 ]; then
 open -a Visual\\ Studio\\ Code.app "$@"
 else
 open -a Visual\\ Studio\\ Code.app -f
 fi
}</code></pre>위 코드를 해석하면 아래와 같다. (채찍피티 인용)<blockquote>ChatGPT 왈: 이 코드는 <code spellcheck="false">~/.zshrc</code> 파일에 작성되어 있는데, 이 파일은 Zsh 셸의 설정 파일입니다. 여기서 정의된 <code spellcheck="false">code()</code> 함수는 주로 Visual Studio Code를 실행하는 데 사용됩니다.이 함수는 두 부분으로 나뉘어 있습니다. 첫 번째는 <code spellcheck="false">if</code> 문으로 시작하여 터미널에서 실행 중인지(<code spellcheck="false">-t 1</code>과 <code spellcheck="false">-t 0</code>를 통해 확인) 확인하고, 그렇다면 주어진 파일이나 디렉토리를 Visual Studio Code로 엽니다. 두 번째 부분은 이와 반대로 터미널이 아닌 상황에서 Visual Studio Code를 엽니다.여기서 <code spellcheck="false">open</code>은 macOS에서 파일을 열거나 애플리케이션을 실행하는 명령입니다. <code spellcheck="false">-a</code> 플래그는 특정 애플리케이션을 지정하여 파일을 열도록 합니다. <code spellcheck="false">Visual\\ Studio\\ Code.app</code>은 Visual Studio Code 애플리케이션의 경로를 나타냅니다. 공백을 포함하는 이름을 사용할 때는 이스케이프 문자(<code spellcheck="false">\\</code>)를 사용하여 공백을 인식하게 합니다.따라서 이 코드는 Zsh 셸에서 <code spellcheck="false">code</code> 명령어를 입력하면, Visual Studio Code가 실행되며, 터미널에서 실행 중인 경우에는 주어진 파일이나 디렉토리를 열도록 하며, 터미널이 아닌 경우에는 그냥 Visual Studio Code를 엽니다.</blockquote><hr>나는 애초에 최근앱 기능을 잘 사용하지 않다보니 첫번째 방법을 사용해서 해결했다.

맥북에서 터미널에서 code 커맨드라인을 지정해두고 해당 명령어를 통해 vscode를 실행하는데 실행할 때마다 dock에 vscode가 중복으로 생성되는 문제가 있었다.한동안 습관적으로 지워주면서 사용하고 있다가 매번 귀찮다는 생각이 들어서 원인을 찾아보았다.vscode 레포에서 동일한 증상을 겪고 있다는 이슈를 발견해서 찾아보니, vscode와 관계없이 

mac dock에 vscode가 중복 생성되는 이슈

<h1>Entity Mapping</h1><h2>@Entity</h2><ul><li>도메인 객체를 관계형 데이터베이스 테이블로 매핑할 때 사용되는 어노테이션이다</li><li>해당 어노테이션만 사용하는 경우 어노테이션이 적용된 클래스의 이름이 테이블 이름이 된다<ul><li>@Table 어노테이션을 사용해 테이블 이름을 명시할 수 있다</li></ul></li><li>기본 생성자 필수</li></ul><h2>@Table</h2><ul><li>스키마를 지정하거나 테이블 이름을 명시할 수 있다</li><li>옵션<ul><li>name : 매핑 테이블 이름 지정(기본값 : 클래스명)</li><li>catalog : DB catalog 매핑 (기능 있는 경우)</li><li>schema : DB schema 매핑 (기능 있는 경우)</li><li>uniqueContraints : DDL 생성 시 unique 제약 조건 생성</li></ul></li></ul><hr><h1>기본키(PK) 매핑 </h1><h2>@Id</h2><ul><li>기본키(PK) 지정한다</li></ul><h2>@GeneratedValue</h2><ul><li>기본키(PK) 값을 자동 생성하기 위한 어노테이션</li><li>여러 옵션을 통해 기본키 생성 전략 적용할 수 있다<ul><li>identity : 기본키 생성 처리를 데이터베이스에 위임</li><li>sequence : 시퀀스를 이용한 기본키 생성</li><li>table : 별도의 기본키 테이블을 이용해 기본키 생성</li><li>auto : 데이터베이스에 따라 기본키 전략 선택</li></ul></li></ul><blockquote><h3>identity</h3><ul><li>새로운 데이터가 생성될 때 PK 값이 부여된다 <ul><li>-&gt; 영속 객체로 올리는 시점 (persist())에 insert가 진행되고 생성된 Id를 반환 받아 1차 캐시에서 관리되는 영속 객체의 Id값으로 저장된다</li></ul></li></ul><h3>sequence</h3><ul><li>데이터베이스의 Sequence 객체를 이용해 기본키를 생성하는 방식이다</li><li>시퀀스를 생성할 경우 @SequenceGenerator 옵션 필요하며 이미 데이터베이스에 존재하는 시퀀스를 이용할 경우 id 필드 위에 선언</li><li>새로운 데이터가 생성될 때 시퀀스 값을 조회한 뒤 해당 값을 Id로 지정하여 데이터가 저장된다<ul><li>-&gt; 영속 객체로 올리는 시점 (persist())에는 시퀀스 조회 쿼리가 발생하고 insert는 commit 시점에 발생한다</li></ul></li><li>allocationSize 옵션을 통해 시퀀스 값을 가져와 캐싱할 수 있다</li></ul></blockquote>

Entity Mapping@Entity도메인 객체를 관계형 데이터베이스 테이블로 매핑할 때 사용되는 어노테이션이다해당 어노테이션만 사용하는 경우 어노테이션이 적용된 클래스의 이름이 테이블 이름이 된다@Table 어노테이션을 사용해 테이블 이름을 명시할 수 있다기본 생성자 필수@Table스키마를 지정하거나 테이블 이름을 명시할 수 있다옵션name : 매핑 테

Entity Mapping

SPARTA

<h1>Docker에 데이터베이스 이미지 띄우기</h1><ul><li>이번 팀 프로젝트에서 PostgreSQL을 사용하게 됐는데 이전에는 mysql을 활용했었기 때문에 해당 데이터베이스를 설치해야 되는 상황이 됐다</li><li>데이터베이스를 설치하기 귀찮기도 하고 도커를 한번도 사용해 본 적이 없어서 이번 기회에 데이터베이스를 도커에 올려보기로 결정</li><li>유튜브 강의를 보면서 도커란 무엇인지 간단하게 학습하고 (일단 미니 컴퓨터라고 생각하기로 했다..) 여러 명령어를 통해 조작해봤다 (명령어는 따로 정리)</li></ul><h3>Docker volume</h3><ul><li>Docker 컨테이너의 문제점<ul><li>도커는 특정 이미지를 통해 하나의 가상 환경을(컨테이너) 구축할 수 있는 툴인데 해당 컨테이너에서 작업한 데이터 또한 컨테이너에 저장이 된다<ul><li>이미지에서 변경된 파일 시스템이 <code spellcheck="false">Container Layer</code> 에 저장→ 이로 인해 컨테이너를 삭제하게 되면 해당 컨테이너 내부의 데이터도 모두 삭제되는 경우가 발생한다 (DB라고 가정하면 DB의 데이터 같이 삭제됨)→ 즉 Docker Container는 휘발성</li></ul></li></ul></li><li>해당 문제점을 해결하기 위해서는 volume 옵션을 활용한다<ul><li>docker volume이란 ?<ul><li>도커 컨테이너에서 데이터를 영속적으로 저장하기 위한 방법</li><li>volume은 컨테이너 내부 저장 공간을 사용하지 않고 호스트 자체의 저장 공간을 공유해서 사용하는 형태<ul><li>컨테이너 내부의 데이터를 호스트가 지정한 공간과 링크를 걸어주는 기능이라고 한다</li></ul>▪ docker run -v [호스트의 디렉토리 절대경로]:[컨테이너의 디렉토리 절대경로] [이미지명]</li></ul></li></ul></li></ul><hr><h1>프로젝트 기록</h1><h3>value() 어노테이션</h3><ul><li>cannot find symbol method value()<ul><li>ai api 호출에 필요한 api key값을 yml 파일에 작성해뒀는데 읽어오지 못하는 이슈 발생<ul><li>annotation.Value를 임포트 했어야 했는데 lombok.Value를 임포트해서 생긴 이슈였음ㅎ</li></ul></li></ul></li></ul><hr><h1>생각이 필요한 것들</h1><h2>Ai를 하나의 도메인으로 봐야 하는가?</h2><ul><li>Ai가 하나의 서비스처럼 느껴지긴 하지만 메뉴 내에서만 사용이 되고 있다.. 확장성을 고려하더라도 배달 플랫폼에서 Ai가 얼마나 확장이 되려나</li><li>현재는 메뉴 도메인에 포함시키되 로직만 분리하는 방향으로 갈 것 같다</li></ul><h2>Ai api 호출 방식</h2><ul><li>동기 / 비동기에 대해 오늘 제대로 이해하게 된 것 같은데 우선 내일 더 알아보고 이점을 따져서 선택하기 (비동기가 좋을 것 같다는 생각인데 동기를 사용해서 얻을 수 있는 이점이 무엇인지 찾아보기)</li></ul>

Docker에 데이터베이스 이미지 띄우기이번 팀 프로젝트에서 PostgreSQL을 사용하게 됐는데 이전에는 mysql을 활용했었기 때문에 해당 데이터베이스를 설치해야 되는 상황이 됐다데이터베이스를 설치하기 귀찮기도 하고 도커를 한번도 사용해 본 적이 없어서 이번 기회에 데이터베이스를 도커에 올려보기로 결정유튜브 강의를 보면서 도커란 무엇인지 간단하게 학습하

Docker

State of React 2023 Survey 결과가 발표되었습니다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://2023.stateofreact.com/en-US/">https://2023.stateofreact.com/en-US/</a>지난 달에 발표됐던 State of JS 를 진행한 기관과 같은 곳에서 진행하는 Survey 죠.형제 격인 Survey 들이 몇가지 있습니다. JS/ CSS/ HTML/ React/ ...React 개발자들이 이 조사 발표를 기다리는 건, 기술동향에 대한 궁금함도 있겠지만,"어떤" 기술을 사용할 것인지를 결정하는데 중요한 자료가 된다는 것이죠.러닝커브가 도사리고 있는 기술인데, 애써 배워놨더니 쓸모 없어지는 경험은 누구에게나 악몽이 될 수 있으니까요..그런 의미에서, 제 채널에서 진행하고 있는 강좌에서 선택한 기술들이 대체로 높은 스코어를 받고 있다는 건 흡족한 일이네요.개인적으로는 Zustand 가 급상승하기를 기대했지만 이번 결과에서는 그렇지 못했습니다. Zustand 가 관심을 받기 시작한 건 얼마 안됐으니까요.. 그리고 이 조사 발표는 정말 늦습니다.그리고 ' 가장 고통스러웠던 API' 설문에서는 forwardRef 와 memo 가 나란히 선두에 뽑혔군요.React 19 에서는 forwardRef 가 없어질 것이라는 이야기도 돌았죠. 컴파일러가 도입되면 memo 도 설 자리를 잃게 될 테고... 이제 HOC 는 서서히 소멸되어가는 기술이 될 것 같습니다.관심있는 분들에게는 매우 의미있는 시간이 될 것입니다.

State of React 2023 Survey 결과가 발표되었습니다.https://2023.stateofreact.com/en-US/지난 달에 발표됐던 State of JS 를 진행한 기관과 같은 곳에서 진행하는 Survey 죠.형제 격인 Survey 들이 몇가지 있습니다. JS/ CSS/ HTML/ React/ ...React 개발자들이 이 조사 발표를

State of React 2023 Survey 결과 발표

🪟 Window

<img src="https://image.until.blog/morethanmin/article/1716045513650" alt="until-71">항상 맥북만 사용하다가 이번에 데스크탑을 맞추게 되면서 개발환경을 윈도우에서 세팅하게 되었다.<h2>fnm이란?</h2>노드 버전을 관리할 수 있게 해주는 매니저로 nvm과 유사하지만 윈도우에서는 nvm이 지원되지 않기 때문에 fnm를 사용해보려고한다.<h2>winget으로 fnm 설치하기</h2>파워쉘에서 아래와 같이 입력하여 설치할 수 있다.<pre spellcheck="false"><code>winget install Schniz.fnm</code></pre><h3>0x8a15000f 오류가 발생하는 경우</h3>마이크로소프트 스토어에서 앱 설치 관리자를 업데이트 해주면 된다.<img src="https://image.until.blog/morethanmin/article/1716045690970" alt="until-72"><h2>fnm으로 node 설치하기</h2><h3>프로필 설정</h3>우선 <code spellcheck="false">PowerShell</code>프로필에 환경변수를 등록해야한다.<code spellcheck="false">~\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1</code> 경로에 아래와같이 입력 해주면 된다.<pre spellcheck="false"><code>fnm env --use-on-cd | Out-String | Invoke-Expression</code></pre><h3>PowerShell 실행시 PSSecurityException 오류가 발생하는 경우</h3>기본적으로 스크립트 삽입하는 것이 막혀있기 때문에 설정을 바꿔줘야한다.관리자 권한으로 <code spellcheck="false">PowerShell</code> 을 실행해서 아래와 같이 입력한다.<pre spellcheck="false"><code>Set-ExecutionPolicy RemoteSigned</code></pre><h3>node 설치</h3>이제 <code spellcheck="false">PowerShell</code> 을 재부팅하고 아래와 같이 입력해 노드를 설치하면된다.<pre spellcheck="false"><code>fnm use --install-if-missing 20</code></pre><hr>그럼 이제 node를 사용할 수 있다! 근데 PowerShell도 그렇고 여러 이슈들도 그렇고 좀 귀찮은 것 같다. 좀 더 사용해보다가 정 안되면 wsl을 사용해야겠다.

항상 맥북만 사용하다가 이번에 데스크탑을 맞추게 되면서 개발환경을 윈도우에서 세팅하게 되었다.fnm이란?노드 버전을 관리할 수 있게 해주는 매니저로 nvm과 유사하지만 윈도우에서는 nvm이 지원되지 않기 때문에 fnm를 사용해보려고한다.winget으로 fnm 설치하기파워쉘에서 아래와 같이 입력하여 설치할 수 있다.winget install Schniz.fn

윈도우에서 winget으로 fnm 설치하기 (Fast Node Manager)

<h1>연관관계</h1><ul><li>JPA에서 연관관계는 영속 객체 간의 관계를 뜻한다</li><li>영속 객체인 엔티티 간의 연관 관계는 방향성을 가진다 (단방향, 양방향)</li><li>연관 관계는 관계의 다중성에 따라 1:1(일대일), 1:N(일대다), N:M(다대다) 관계로 구분한다</li><li>엔티티가 테이블과 매핑되는 것과 마찬가지로 엔티티 간의 관계는 테이블 간의 관계와 매핑된다</li></ul><h2></h2><blockquote>Student는 하나의 Major를 가진다Major는 여러 Student에 속한다</blockquote><h3>테이블 관계 그대로 엔티티 정의</h3><pre spellcheck="false"><code class="language-java">public class Student { //일부 코드

 @Id
 @GeneratedValue
 private Long studentId;
 private String name;
 private String grade;
 private Long majorId; // 테이블에 저장되는 형태 그대로 정의
}</code></pre><pre spellcheck="false"><code class="language-java"> // 전공 생성
 Major major = new Major("Computer Science", "Engineering");
 em.persist(major);

 // 학생 생성
 Student student = new Student("kim", "3");
 student.setMajorId(major.getMajorId());
 em.persist(student);

 em.flush();
 em.clear();

 // 학생의 전공 찾기
 Student foundStudent = em.find(Student.class, 1);
 Major foundMajor = em.find(Major.class, foundStudent.getMajorId());
 System.out.println(foundStudent);
 System.out.println(foundMajor);

 tx.commit();</code></pre><blockquote>테이블 연관관계 그대로 엔티티(필드 타입)를 구성<ul><li>foundStudent로 찾아온 학생 정보에는 전공의 정보는 포함되지 않고 fk 값이 포함된다</li><li>학생의 전공을 찾기 위해서는 학생 객체의 majorId 필드를 이용해 DB를 한번 더 다녀와야 한다</li><li>majorId 필드를 Long 타입으로 지정하는 건 외래키를 단순히 값으로 처리하는 방식</li><li>즉 객체지향 설계에서 연관관계를 객체 간에 직접 맺어주는 것이 아니라 DB 값만 이용하는 방식으로 실제 객체들 간의 관계를 반영하지 못한다 (두 객체가 서로 연결되었다고 보기 어려움) 또한 지연로딩을 활용할 수 없음 (em.find())</li></ul></blockquote><h3>Student 필드에 FK를 Major 객체로 지정</h3><pre spellcheck="false"><code class="language-java"> @ManyToOne// 관계구성
 @JoinColumn(name = "MAJORID") // 외래키 지정
 private Major major;</code></pre><blockquote>영속 객체 간의 관계는 방향성을 갖는다Student 클래스가 Major 클래스를 참조하여 Student -&gt; Major의 방향성을 갖게 된다Student 객체는 참조하는 major를 통해 Major 인스턴스 객체에 접근할 수 있다Student 클래스는 Major 클래스와 ManyToOne 관계가 된다 (N:1)(반대 경우는 OneToMany)</blockquote><pre spellcheck="false"><code class="language-java"> // 전공 생성
 Major major = new Major("Computer Science", "Engineering");
 em.persist(major);

 // 학생 생성
 Student student = new Student("kim", "3");
 student.setMajor(major);
 em.persist(student);

 em.flush();
 em.clear();

 // 학생의 전공 찾기
 Student foundStudent = em.find(Student.class, 1);
 System.out.println(foundStudent); // 학생 검색 시 major 에 대한 정보 함께 포함
</code></pre><h3>지연로딩 설정</h3><pre spellcheck="false"><code class="language-java"> @ManyToOne(fetch = FetchType.LAZY)// 관계구성
 @JoinColumn(name = "MAJORID") // 외래키 지정
 private Major major;</code></pre><pre spellcheck="false"><code class="language-java"> // 전공 생성
 Major major = new Major("Computer Science", "Engineering");
 em.persist(major);

 // 학생 생성
 Student student = new Student("kim", "3");
 student.setMajor(major);
 em.persist(student);

 em.flush();
 em.clear();

 // 학생의 전공 찾기
 Student foundStudent = em.find(Student.class, 1);
 foundStudent.getName(); // Student 에 대한 select 발생
 System.out.println(foundStudent.getMajor().getCategory()); // Major 에 대한 select 밠생
</code></pre><blockquote><h3>Student 필드에 FK를 Major 객체로 저장</h3>Student 객체에 Major 객체 자체가 포함이 된다학생의 전공을 찾기 위해 불필요한 find를 하지 않아도 되며 실제 객체의 관계가 반영되었음을 알 수 있다<h3>지연로딩 설정</h3>fetch = FetchType.LAZY를 적용한 뒤에 똑같이 student를 find할 때 Student에 대한 조회 쿼리가 발생하고 이후 Major를 확인할 때 Major 조회 쿼리가 발생한다지연로딩을 적용하면 해당 객체가 필요한 순간에 쿼리를 발생한다 (불필요한 쿼리는 보내지 않을 수 있다) 반대로 EAGER 옵션을 통해 즉시로딩도 설정할 수 있다</blockquote>

연관관계JPA에서 연관관계는 영속 객체 간의 관계를 뜻한다영속 객체인 엔티티 간의 연관 관계는 방향성을 가진다 (단방향, 양방향)연관 관계는 관계의 다중성에 따라 1:1(일대일), 1:N(일대다), N:M(다대다) 관계로 구분한다엔티티가 테이블과 매핑되는 것과 마찬가지로 엔티티 간의 관계는 테이블 간의 관계와 매핑된다Student는 하나의 Major를 가진

관계 Mapping

🖥 백엔드

<h1>들어가기 전에</h1>Nest.js는 Node.js 진영에서 널리 쓰이고 있는 서버 프레임워크이다.그리고 이런 서버를 클라우드 환경에 배포하기 위해서는 AWS EC2, Oracle Cloud 등의 컴퓨팅 인스턴스 위에 올리는 방법이 정석이겠다.&nbsp;하지만 Nest.js는 서버리스를 지원하고, Vercel은 서버리스를 지원한다. 이를 이용해서 무료로 간단히 Vercel에 서버를 배포할 수 있다.<h1>방법</h1>방법 자체는 간단하다. 프로젝트 최상단에&nbsp;<code spellcheck="false">vercel.json</code>을 만들고 다음과 같이 작성한다.<pre spellcheck="false"><code class="language-json">{
 "version": 2,
 "builds": [
 {
 "src": "src/main.ts",
 "use": "@vercel/node"
 }
 ],
 "routes": [
 {
 "src": "/(.*)",
 "dest": "src/main.ts",
 "methods": [
 "GET",
 "POST",
 "PUT",
 "DELETE"
 ]
 }
 ]
}</code></pre>그 후 <code spellcheck="false">npm install -g vercel</code> 을 실행한 후, 프로젝트 최상단 경로에서 <code spellcheck="false">vercel .</code>를 실행하면 완성된다.<h1>트러블 슈팅</h1><h2>Cannot find module</h2><img src="https://image.until.blog/octoping/article/1730787106060.png" data-width="75%" data-align="center" alt="1972">배포를 했지만 다음과 같은 오류가 떠서 처음에 큰 고생을 했다.Vercel에서 로그를 확인해보니 아래와 같은 에러 로그가 있었다.<pre spellcheck="false"><code class="language-log">2023-08-18T17:52:14.322Z	undefined	ERROR	Cannot find module 'src/infra/prisma/PrismaService'
Require stack:
- /var/task/src/feed/feed.module.js
- /var/task/src/app.module.js
- /var/task/src/main.js
2023-08-18T17:52:14.323Z	undefined	ERROR	Did you forget to add it to "dependencies" in `package.json`?
RequestId: 059dec36-4319-4851-9c23-3ecf01978f18 Error: Runtime exited with error: exit status 1
Runtime.ExitError</code></pre><img src="https://image.until.blog/octoping/article/1730787132600.png" data-width="100%" data-align="center" alt="1974">분명 잘 존재하는 모듈을 발견하지 못하고 있다고 에러가 떴다.왜;;인지 도저히 알기가 어려워 많이 헤맸는데, 문제는 내 import 문에 있었다.<pre spellcheck="false"><code class="language-typescript">import { PrismaService } from '@/infra/prisma/PrismaService';</code></pre>다음과 같이 path alias를 사용해서 절대 경로로 import 하는 경우 Vercel이 경로를 인식을 못하는 이슈였다.<code spellcheck="false">src/infra/prisma/PrismaService</code>&nbsp;처럼 @를 안 쓰고 절대경로로 쓰더라도 마찬가지였다. 상대경로로 작성해야 한다!<h2>Swagger 페이지 404 에러 (검증 못 해봄)</h2>다른 페이지는 잘 나오지만 Swagger 페이지만 아무것도 안 나오는 이슈 (404 에러)가 발생한다.<pre spellcheck="false"><code>Uncaught ReferenceError: SwaggerUIBundle is not defined
 at window.onload</code></pre>개발자 도구를 켜보면 이런 로그가 나온다.C# 쪽 스웨거에서도 한번 제보된 문제이긴 하다. swagger ui 파일이 서버리스에 올라가기에는 너무 크다는 이슈다.<a data-type="bookmark" href="https://stackoverflow.com/questions/63363123/swagger-ui-bundle-js-too-large-for-aws-lambda-and-alb" target="_blank"><div class="content"><div><div class="title">swagger-ui-bundle.js too large for AWS Lambda and ALB</div><div class="description">Updated to .NET Core 3.1 and the latest version of Swashbuckle but found the swagger UI wasn't working correctly. The swagger-ui-bundle.js was failing to load with a 502. Tracked this down to a A...</div></div><div class="href">https://stackoverflow.com/questions/63363123/swagger-ui-bundle-js-too-large-for-aws-lambda-and-alb</div></div><img src="https://cdn.sstatic.net/Sites/stackoverflow/Img/apple-touch-icon@2.png?v=73d79a89bded"></a>따로 CDN에 swagger js나 css를 올려놓고, 서버리스에 올리는 대신 받아오는 방식으로 사용해볼 수 있겠다는 생각인데.<pre spellcheck="false"><code class="language-typescript">const CSS_URL = "cdnjs.cloudflare.com/ajax/libs/swagger-ui/4.1.0/swagger-ui.min.css";
swaggerUI.setup(specs, { customCssUrl: CSS_URL })</code></pre>이런 방식으로 사용해볼 수 있다는 듯 하다.<a data-type="bookmark" href="https://github.com/swagger-api/swagger-ui/issues/8461#issuecomment-1497927943" target="_blank"><div class="content"><div><div class="title">When deploying swagger on vercel on nodejs it does not show UI · Issue #8461 · swagger-api/swagger-ui</div><div class="description">This is How it does look like this and I do not know how to fix this issue. Q&amp;A (please complete the following information) OS: M1 Pro Browser" Chrome, Safari Version: 22 Method of installation: np...</div></div><div class="href">https://github.com/swagger-api/swagger-ui/issues/8461#issuecomment-1497927943</div></div><img src="https://opengraph.githubassets.com/3d796af99bd52776acde541aa8b0f43379af9c671dc58fe420ea1314dd1a51a4/swagger-api/swagger-ui/issues/8461"></a><h1>TMI</h1>실제로 until을 처음 개발할 당시에 서버비를 줄이기 위해 다음 방법으로 한동안 개발했었다..지금은 AWS + Kotlin Spring으로 넘어갔지만, 그래도 당시에 고려했던 점들을 몇 가지 적어본다.<ol><li>NestJS의 경우 서버 실행 초기에 bootstrap하는 과정을 거치는데, 이걸 api가 들어올 때마다 해야한다면 꽤 무거운 작업일 수밖에?</li><li>서버리스로 구성할 경우 api가 들어올 때마다 함수가 실행되는 꼴이므로, 트래픽이 몰리는 경우 DB의 커넥션 풀을 굉장히 잡아먹을 가능성이 높다. 이는 서버리스의 고질적 문제이긴 하다.<ul><li>프로젝트의 persistence 라이브러리로 채택한 Prisma의 경우 이런 문제를 해결해준다고 공식 사이트에 적혀는 있다. 하지만 좀 걱정된다<img src="https://image.until.blog/octoping/article/1730788287259.png" data-width="100%" data-align="center" alt="1976"></li></ul></li></ol>

NestJS를 서버리스로 배포해서 무료로 사용해봅시다

NestJS 서버를 서버리스로 Vercel에 배포하기

Workthrough for prev. projectForm Basics : Controlled Input &amp; UnControlled InputReact &amp; FormsReact-Hook-FormZod + ResolverForm Component &amp; UI Componentfourth project : React-Hook-Form Proj

#4. Form handling in React

<h1>영속성 컨텍스트</h1><ul><li>고유 ID를 갖는 모든 영속 객체 인스턴스에 대한 집합</li><li>영속성 컨텍스트 내에서 영속 객체에 대한 생명주기가 관리된다<ul><li>EntityManager의 메서드를 이용</li></ul></li><li>영속성 컨텍스트는 어플리케이션과 DB 사이에 위치</li><li>영속 객체에 대한 정보(데이터)는 영속성 컨텍스트 내부의 1차 캐시에서 관리된다</li></ul><blockquote>트랜잭션이 시작되고 EntityManager를 통해 영속성 컨텍스트에 객체가 올라가면1차 캐시에 해당 영속 객체가 등록이된다 (영속 객체의 고유 ID / 엔티티 객체 / 스냅샷)영속 객체가 올라간 상태는 아직 insert 작업이 처리된 것은 아니다</blockquote><pre spellcheck="false"><code class="language-java">// EntityManager를 통해 가져온 트랜잭션을 시작
tx.begin();

try { // persist, commit 과정에서 예외가 발생하면 rollback
 em.persist(Customer.sample()); // 영속성 컨텍스트에 객체를 등록

 tx.commit();

} catch (Exception e) {
 tx.rollback();

} finally {
 em.close();
}

/*
persist() 엔티티 객체를 영속성 컨텍스트에 저장한다
해당 엔티티 객체는 영속 상태로 전환된다
영속 상태로 전환된 엔티티 객체는 1차 캐시에 저장되고 트랜잭션이 커밋되면 데이터베이스에 동기화된다
persist()는 객체를 "JPA 관리 상태"로 만드는 중요한 메서드
*/

tx.begin();
try { // persist, commit 과정에서 예외가 발생하면 rollback
 Customer customer = new Customer("ID0002", "kim");
 em.persist(customer); // insert 실행되지 않고 1차 캐시에 저장된다
 em.persist(customer);

 tx.commit(); // insert 실행된다
} catch (Exception e) {
 tx.rollback();
} finally {
 em.close();
}

/*
persist()를 호출한다고 해서 바로 삽입 쿼리가 발생하지 않고 
우선 영속성 컨텍스트 내부의 1차 캐시에 등록된다
commit 시점에 발생한다
즉 최종적으로 insert는 하나의 행에 대해서만 발생한다
*/</code></pre><pre spellcheck="false"><code class="language-java">// EntityManager를 통해 가져온 트랜잭션을 시작
tx.begin();

try { // persist, commit 과정에서 예외가 발생하면 rollback
 em.persist(Customer.sample());
 Customer foundCustomer = em.find(Customer.class, "ID0001");
 foundCustomer.setName("choi");

 tx.commit();
} catch (Exception e) {
 tx.rollback();
} finally {
 em.close();
}

/*
이미 영속 상태로 전환된 영속 객체가 1차 캐시에 올라가 있는 상태이기 때문에
조회 쿼리는 발생하지 않음
그리고 트랜잭션 내에서 해당 영속 객체의 변화를 감지하고 commit 시점에 수정 쿼리를 날림
*/</code></pre><pre spellcheck="false"><code class="language-java">tx.begin();
try { // persist, commit 과정에서 예외가 발생하면 rollback
 Customer customer = new Customer("ID0002", "kim");
 em.persist(customer); // insert 실행되지 않고 1차 캐시에 저장된다

 Customer foundCustomer = em.find(Customer.class, "ID0002"); 
 // 위 코드를 통해 캐시에 올라간 영속 객체를 반환해준다
 

 tx.commit(); // insert 실행된다
} catch (Exception e) {
 tx.rollback();
} finally {
 em.close();
}

/*
persist()를 통해 캐시에 올린 객체를 find()로 호출을 하면 조회 쿼리가 발생하지 않는다
이미 캐시에 올라갔기 때문에 캐시에 저장된 영속 객체를 반환해주기 때문
(찾고자 하는 영속 객체가 1차 캐시에 등록되어 있다면 해당 영속 객체를 반환하고 없다면 조회 쿼리)
*/</code></pre>

영속성 컨텍스트고유 ID를 갖는 모든 영속 객체 인스턴스에 대한 집합영속성 컨텍스트 내에서 영속 객체에 대한 생명주기가 관리된다EntityManager의 메서드를 이용영속성 컨텍스트는 어플리케이션과 DB 사이에 위치영속 객체에 대한 정보(데이터)는 영속성 컨텍스트 내부의 1차 캐시에서 관리된다트랜잭션이 시작되고 EntityManager를 통해 영속성 컨텍스

JPA - 영속성 컨텍스트 1

<h2>도메인이 뭐냐면..</h2><blockquote>개발을 할때도 도메인, 데이터베이스 구조를 설계할 때도 도메인, 프로젝트 기획할때도 도메인, 여기저기서 다 도메인이라는 단어를 쓰는데 개념이 명확하지 않아 헷갈려서 정리해봤슴다</blockquote><h3>1. 프로젝트 구조(Architecture):</h3><ul class="tight" data-tight="true"><li>프로젝트 구조에서 도메인은 주요 <code spellcheck="false">비즈니스 개체</code>를 나타냅니다. 일반적으로 소프트웨어 시스템에서 도메인은 해당 시스템이 다루는 <code spellcheck="false">중요한 주제 영역</code>을 반영합니다. 도메인은 프로젝트의 핵심 부분이며, <code spellcheck="false">이를 기반으로 비즈니스 로직을 구현</code>하게 됩니다. 예를 들어, 전자상거래 웹 애플리케이션의 도메인은 상품, 주문, 사용자 등과 같은 주요 개체들로 구성될 수 있습니다.</li></ul><h3>2. 스프링(Spring):</h3><ul class="tight" data-tight="true"><li>스프링에서의 도메인은 주로 <code spellcheck="false">엔티티 클래스</code>로 표현됩니다. 엔티티 클래스는 데이터베이스의 테이블과 매핑되는 객체를 나타냅니다. 스프링 애플리케이션에서 도메인 클래스는 주로 비즈니스 로직을 구현하고, <code spellcheck="false">데이터베이스와의 상호 작용</code>을 담당합니다. 스프링의 ORM(Object-Relational Mapping) 기술인 Hibernate를 사용하면 도메인 객체와 데이터베이스 테이블 간의 매핑을 쉽게 구현할 수 있습니다.</li></ul><h3>3. 데이터베이스(Database):</h3><ul class="tight" data-tight="true"><li>데이터베이스에서의 도메인은 해당 <code spellcheck="false">데이터베이스가 다루는 데이터의 유형</code>을 정의합니다. 도메인은 데이터의 <code spellcheck="false">속성과 제약 조건을 정의</code>하는 데 사용됩니다. 예를 들어, 사용자 이름이나 이메일 주소와 같은 속성은 데이터베이스에서의 도메인에 해당할 수 있습니다. 또한 데이터의 유효성을 검사하기 위한 제약 조건(예: NOT NULL, UNIQUE)도 도메인에서 정의됩니다.</li></ul><h3>4. 기타 도메인 개념들:</h3><ol class="tight" data-tight="true"><li>도메인 주도 설계(Domain-Driven Design, DDD): 소프트웨어 개발 방법론 중 하나로, 비즈니스 도메인을 중심으로 설계하는 방법론입니다. 도메인 주도 설계는 비즈니스 요구 사항을 반영하고 복잡성을 줄이기 위해 도메인 모델을 사용합니다.</li><li>도메인 객체: 소프트웨어에서 특정 도메인을 나타내는 객체를 의미합니다. 도메인 객체는 비즈니스 로직을 포함하고 해당 도메인에 특화된 행위를 수행합니다.</li><li>도메인 서비스: 특정 도메인과 관련된 비즈니스 로직을 제공하는 서비스입니다. 도메인 서비스는 도메인 객체와는 달리 특정 개체에 속하지 않는 독립적인 로직을 수행합니다.</li><li>도메인 이벤트: 도메인에서 발생하는 중요한 사건을 나타내는 이벤트입니다. 도메인 이벤트는 비즈니스 로직의 흐름을 추적하고 기록하는 데 사용될 수 있습니다.</li></ol><blockquote>혹시 틀린 부분이 있다면 댓글 부탁드립니다.</blockquote>

도메인이 뭐냐면..개발을 할때도 도메인, 데이터베이스 구조를 설계할 때도 도메인, 프로젝트 기획할때도 도메인, 여기저기서 다 도메인이라는 단어를 쓰는데 개념이 명확하지 않아 헷갈려서 정리해봤슴다1. 프로젝트 구조(Architecture):프로젝트 구조에서 도메인은 주요 비즈니스 개체를 나타냅니다. 일반적으로 소프트웨어 시스템에서 도메인은 해당 시스템이 다루

도메인이 뭔가요?

<h1>NextJS 15 ‘use cache’</h1>NextJS 15 에서, fetch 를 이전 버전처럼 사용하면 에러가 발생하는데요..NextJS 15 버전 부터는 fetch 의 캐시 정책을 명시적으로 표현해줘야만 합니다.이 때 <code spellcheck="false">‘use cache’</code> 가 사용됩니다..fetch 모듈에 대해서, 데이터를 캐싱 할 것인가 아닌가에 따라 두가지 구현 방식으로 갈라집니다.<ol><li>fresh data for every request : <code spellcheck="false">&lt;Suspense&gt;</code></li><li>cached data : <code spellcheck="false">'use cache'</code></li></ol>..<h2>Fresh Data for every request</h2>모든 요청에서 fresh data 를 받아와야 할 때는, 해당 컴포넌트를 <code spellcheck="false">Suspense</code> 로 감싸줍니다.<pre spellcheck="false"><code class="language-tsx">// fresh data for EVERY requests..
// 이제 Next 가 자체적으로 캐시를 오버라이드하지 않는다. fetch 는 캐시되지 않는다.
export function Notice() {
 const data = fetch(...)
 return (...data)
}

// 이제는 Suspense 가 없으면 에러를 뱉는다.
export default function Page() {
 return(
 &lt;Suspense fallback={...loading}&gt;
 &lt;Notice /&gt;
 {... some other Data}
 &lt;/Suspense&gt;
 )
}
</code></pre>..<h2>Cached Data</h2>Cache 와 Static Yuji 가 필요할 때, <code spellcheck="false">'use cache'</code> 를 선언주고 <code spellcheck="false">Suspense</code> 를 제거합니다.<pre spellcheck="false"><code class="language-tsx">// Cache 해야 할 때
'use cache'

// 'use cache' 디렉티브에 따라 cache 는 캐싱된다. 
export function Notice() {
 const data = fetch(...)
 return (...)
}

// Notice 컴포넌트가 SSG 가 되는지는 아직 확인하지 못했다. 
export default function Page() {
 return(
 &lt;Notice /&gt;
 (...other Data)
 )
}
</code></pre>SSG 같은 컴포넌트 단위의 Static-Component-Generation 과 'use cache' 의 관계와 차이를 아직 분명히 확인하지 못했습니다.사이트 내에서 100만개의 캐시가 발생할 수도 있기 때문에, 관리를 위해선 Static Component 가 될 것 같지만, 펑션 단위의 ‘use cache’ 도 허용되는 것을 봐선 그렇지 않을 것 같기도 합니다. 때가 되면 저절로 알게 되겠죠...<h2>Cache Handling for Route Segments</h2>Route Segment 들은, use cache 와 Suspense 가 믹스되는 방식으로 중첩구조를 이루게 되는데, 특히 layout.tsx 에서는 use cache - Static 이 유용합니다.<pre spellcheck="false"><code class="language-tsx">// 이제 layout 은 캐싱 되고, children 에 대해 각각의 cache segment 가 할당된다.
// ContextProvider 들과 NavBar, Footer 는 Static 고정되고, 
// Navigation 은 children 내에서만 각각의 Route Segment 정책에 따라 이동하고 캐싱된다.
'use cache'
export default function RootLayout({
 children
}: Readonly&lt;{
 children: React.ReactNode
}&gt;) {
 return (
 &lt;html
 lang="en"
 suppressHydrationWarning={true}&gt;
 &lt;body
 className={inter.className}
 suppressHydrationWarning={true}
 suppressContentEditableWarning={true}&gt;
 &lt;AuthProvider&gt;
 &lt;NavigationGuardContextProvider&gt;
 &lt;ThemeProvider
 defaultTheme="dark"
 storageKey="ganymedian-ui-theme"&gt;
 &lt;RootFrame&gt;
 &lt;NavBar /&gt;
 &lt;MainFrame&gt;{children}&lt;/MainFrame&gt;
 &lt;Footer /&gt;
 &lt;/RootFrame&gt;
 &lt;Toaster /&gt;
 &lt;/ThemeProvider&gt;
 &lt;/NavigationGuardContextProvider&gt;
 &lt;/AuthProvider&gt;
 &lt;/body&gt;
 &lt;/html&gt;
 )
}**
</code></pre>..<h2>Cache Stale &amp; Revalidate</h2>이건 아직 unstable 버전이라고 합니다… Next Conf 에 납품 기일을 못 맞춘 팀이 있었나본데.. 감정이입이 되는군요.<pre spellcheck="false"><code class="language-tsx">// cacheTag : Cache Id 
// cacheLife: Cache Life for Cache Id
import { unstable_cacheTag as cacheTag, unstable-cacheLife as cacheLife } from 'next/cache'

async function getNotice() {
 'use cache'
 const data = fetch(...)

 cacheTag('cache-control-' + data.id)
 cacheLife({
 revalidate: 60,
 expire: 3600,
 stale: 10,
 })

 return ({...data})
}

export default function Page() {
 return(
 &lt;div&gt;
 {await getNotice()}
 (...other Data)
 &lt;/div&gt;
 )
}
</code></pre>..세줄 요약<ol><li>NextJS.15 에서 fetch 가 사용될 때, ‘use cache’ 를 명시적으로 표현해줘야 한다.</li><li>Cache 하지 않을 때 : <code spellcheck="false">&lt;Suspense&gt;</code></li><li>Cache 할 때 : <code spellcheck="false">'use cache'</code></li></ol><code spellcheck="false">'use client'</code> , <code spellcheck="false">'use server'</code> 못지 않게 <code spellcheck="false">'use cache'</code> 도, 중요한 디렉티브 키워드가 되었습니다..-끗-.

NextJS 15 ‘use cache’NextJS 15 에서, fetch 를 이전 버전처럼 사용하면 에러가 발생하는데요..NextJS 15 버전 부터는 fetch 의 캐시 정책을 명시적으로 표현해줘야만 합니다.이 때 ‘use cache’ 가 사용됩니다..fetch 모듈에 대해서, 데이터를 캐싱 할 것인가 아닌가에 따라 두가지 구현 방식으로 갈라집니다.fre

NextJS 15 ‘use cache’

<h1>API Gateway란</h1><ul><li>클라이언트와 백엔드 서비스 사이에 위치한 진입점(중간계층)이다</li><li>클라이언트가 개별 서비스와 직접 통신하지 않고 API 게이트웨이를 통해 요청을 전송한다</li><li>게이트웨이가 요청을 적절한 서비스로 전달하거나 추가 작업(필터링, 인증 등)을 진행한다</li></ul><h2>API Gateway 주요 기능</h2><ol><li>라우팅 : 클라이언트 요청을 적절한 마이크로 서비스로 전달한다</li><li>필터링 : 요청 및 응답을 변환하거나 검사하는 기능이다</li><li>보안 : 인증, 권한 부여, 요청 검증 등을 수행한다</li><li>로드밸런싱 : 여러 인스턴스에 요청을 분산시킨다</li><li>모니터링 및 로깅 : 요청 / 응답 데이터를 로깅하고 모니터링할 수 있다</li><li>속도제한 및 트래픽 제어 : 특정 클라이언트 또는 IP의 요청을 제한할 수 있다</li></ol><h1>Spring Cloud Gateway란</h1><ul><li>Spring Frame work 기반으로 개발된 API 게이트웨이 솔루션<ul><li>API 게이트웨이를 구현하기 위한 프레임워크</li></ul></li><li>스프링의 유연성과 생산성을 활용하여 API 게이트웨이의 주요 기능을 쉽게 구현할 수 있도록 돕는다</li></ul><h2>특징</h2><ul><li>비동기 네트워크 처리 : Netty와 Reactor 기반으로 고성능 비동기 요청 처리가 가능하다</li><li>Spring Boot 통합 : 간단한 설정으로 API 게이트웨이를 구축할 수 있다</li><li>유연한 요청 필터링 및 라우팅 : Filter와 Predicate를 사용하여 세부 동작을 설정할 수 있다</li><li>Spring Cloud 생태계와의 통합 : Eureka, Config Server, Resilience4j 등과 쉽게 연동할 수 있다</li></ul><h2>Spring Cloud Gateway의 주요 구성 요소</h2><ol><li>Routes (라우트)<ul><li>요청이 전달되는 경로를 정의한다</li><li>각 라우트는 Predicate (조건) 와 Filter (처리) 로 구성된다</li><li>구성<ul><li>id : 라우트 식별자</li><li>uri : 요청이 전달될 백엔드 서비스 주소</li><li>predicates : 라우팅 조건</li><li>filters : 요청 / 응답을 반환하거나 수정하는 로직</li></ul></li></ul></li><li>Predicates (조건)<ul><li>요청을 특정 서비스로 라우팅할지 여부를 결정하는 조건</li></ul></li><li>Filters (필터)<ul><li>요청이나 응답을 수정하거나 추가 동작을 수행</li></ul></li><li>Global Filters<ul><li>모든 요청에 공통으로 적용되는 필터</li></ul></li></ol><h1>Spring Cloud Gateway 동작 흐름</h1><ol><li>클라이언트 요청 : 클라이언트가 API 게이트웨이로 요청을 보낸다</li><li>Predicate : 요청이 특정 라우트와 일치하는지 조건을 확인한다</li><li>Filter 처리 : 요청 / 응답에 대한 추가 작업을 진행한다</li><li>백엔드 호출 : 필터링 후 해당 요청을 적절한 백엔드로 전달한다</li><li>응답 반환 : 백엔드에서 응답을 받아 클라이언트로 반환한다</li></ol><h1>Spring Cloud Gateway 필터</h1><ol><li>yml에 설정하는 필터<ul><li>Spring Cloud Gateway의 라우트 설정에 사용하는 필터</li><li>간단한 사전 정의 필터를 조합해서 사용<ul><li>ex: AddRequestHeader (응답 헤더 추가), RewritePath (요청 경로 재작성), StripPrefix(경로의 일부 제거) 등</li></ul></li><li>특정 라우트에만 적용된다</li></ul></li><li>Java 코드로 구현하는 필터 (커스텀 필터)<ul><li>GlobalFilter 또는 GateWayFilter 인터페이스를 구현한다</li><li>모든 라우트에 적용하거나 특정 조건에서 동작한다</li><li>Pre / Post 필터로 나눠 요청과 응답에 대한 맞춤형 처리가 가능하다</li><li>@Component로 스프링 빈 등록 필요</li></ul></li></ol>

API Gateway란클라이언트와 백엔드 서비스 사이에 위치한 진입점(중간계층)이다클라이언트가 개별 서비스와 직접 통신하지 않고 API 게이트웨이를 통해 요청을 전송한다게이트웨이가 요청을 적절한 서비스로 전달하거나 추가 작업(필터링, 인증 등)을 진행한다API Gateway 주요 기능라우팅 : 클라이언트 요청을 적절한 마이크로 서비스로 전달한다필터링 : 요

API Gateway(Spring Cloud Gateway)

Wes Boss 선생이 한 달 쯤 전에 작은 돌 하나를 던졌습니다.State of JS 설문에서 영향력있는 인물로 상위권에서 늘 빠지지 않는 선생님이죠.그가 한 레거시 웹사이트를 소개하는 영상을 유튜브에 올렸습니다...<h2>How is this website so fast?</h2><a target="_blank" rel="noopener noreferrer nofollow" href="https://www.youtube.com/watch?v=-Ln-8QM8KhQ&amp;ab_channel=WesBos">https://www.youtube.com/watch?v=-Ln-8QM8KhQ&amp;ab_channel=WesBos</a>어느 오래된 .asp 기반의 하드웨어 부품 이커머스 사이트의 말도 안되는 응답속도를 분석하고 소개하는 영상이었는데요.<a target="_blank" rel="noopener noreferrer nofollow" href="https://www.mcmaster.com/">https://www.mcmaster.com/</a>지금도 멀쩡히 운영되고 있는 이커머스 웹사이트입니다.링크를 붙이기가 사이트 운영자에게 조금 죄송한 생각이 들지만, 정말로 말도 안되는 응답속도를 보여주고 있습니다.Wes Boss 선생의 소개가 알려진 다음부터, 어느날 갑자기 개발자들의 성지가 되어버린 곳이랄까요.. 암튼, 커스토머는 아닌 개발자들이 반갑지 않은 트래픽을 발생시키고 있는 곳입니다. (지금은 일부 pre-fetch 기능을 꺼버린 것 같습니다. 개발자들의 의도치 않은 ddos 이펙트? 때문인 것 같아요.)McMaster 의 놀라운 응답속도의 비밀은,Aggressive Pre-RenderingAggressive Pre-Fetch로 Wes Boss 선생은 분석하고 있습니다.mouseOver 이벤트에, 타겟 페이지의 프리렌더링 된 Dom 을 먼저 prefetch 해오는 것이지요.비록 20년 묵은 .asp 기술로 만들어진 레거시 웹이지만, 사용자 경험 UX 측면에서는 지금보다 앞선 접근이라고 소개할 수 있겠습니다..그런데, 이 재미난 떡밥을 그냥 놔둘 개발자들이 아니죠.놀이감을 발견한 몇몇 개발자들이 <a target="_blank" rel="noopener noreferrer nofollow" href="http://McMaster.com">McMaster.com</a> 의 기본 컨셉을 승계한 NextJS 기반의 오픈소스 프로젝트를 만들었습니다.두둥!!..<h2>NextFaster Project</h2>오픈소스 프로젝트 NextFaster<a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/ethanniser/NextFaster">https://github.com/ethanniser/NextFaster</a>버슬에 라이브 데모도 올려져 있습니다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://next-faster.vercel.app/">https://next-faster.vercel.app/</a>엄청난 반응속도에 헛웃음만 나오게 되는데요..ㅋㅋㅋㅋㅋ반응속도가 정말로 웃깁니다.ㅋㅋㅋㅋlighthouse 의 평점은 모든 항목에서 100점이군요.ㅋㅋㅋㅋ.NextFaster 프로젝트에서 UX 를 향상시킨 비밀은 아래 네가지로 소개하고 있습니다.<ul><li>Partial Pre-Rendering</li><li>Aggressive Pre-Fetching</li><li>Aggressive Caching</li><li>Avoid database joins</li></ul>물론, 이 놀라운 반응속도를 제공하기 위해서는 서버 인프라가 더 많은 땀을 흘리는 댓가를 지불해야 하겠죠.그러나, 매우 의미있는, 재미있는 오픈소스 프로젝트인 것 같습니다.React - NextJS 진영의 한 사람으로써, 자부심과 긍지가 느껴지는 경험이었던 것 같습니다.엣헴.

Wes Boss 선생이 한 달 쯤 전에 작은 돌 하나를 던졌습니다.State of JS 설문에서 영향력있는 인물로 상위권에서 늘 빠지지 않는 선생님이죠.그가 한 레거시 웹사이트를 소개하는 영상을 유튜브에 올렸습니다...How is this website so fast?https://www.youtube.com/watch?v=-Ln-8QM8KhQ&amp;ab

NextFast Project

<h1>로드 밸런싱</h1><ul><li>네트워크 트래픽이나 작업 부하를 여러 서버 또는 리소스에 고르게 분배하는 기술이다<ul><li>시스템의 성능, 가용성, 확장성을 향상 시키고 특정 서버에 부하가 집중되는 것을 방지한다</li></ul></li></ul><h1>클라이언트 사이드 로드 밸런싱</h1><ul><li>클라이언트가 서버 요청을 보낼 때 서버의 위치를 직접 선택하여 트래픽을 분산하는 방식이다<ul><li>클라이언트가 직접 서버 인스턴스 목록을 관리하고 요청을 보낼 인스턴스를 선택한다</li></ul></li></ul><h1>Feign Client</h1><ul><li>Spring Cloud에서 제공하는 HTTP 클라이언트이다<ul><li>선언형 HTTP 클라이언트로 인터페이스와 어노테이션 기반으로 다른 서비스와의 통신을 설정할 수 있다<ul><li>이로 인해 REST API 호출 코드를 간단하게 작성할 수 있다</li><li>서비스 간의 통신 코드를 단순화하며, 서비스 이름으로 요청을 보낸다</li></ul></li></ul></li></ul><h1>Ribbon</h1><ul><li>클라이언트 측 로드 밸런싱 라이브러리이며 클라이언트 요청을 여러 서버 인스턴스에 분산시킨다</li><li>서비스 목록을 기반으로 라운드 로빈, 최소 연결 등의 다양한 알고리즘을 지원한다<ul><li>현재는 <code spellcheck="false">Spring Cloud LoadBalancer</code>로 대체되고 있다고 함</li></ul></li></ul>

로드 밸런싱네트워크 트래픽이나 작업 부하를 여러 서버 또는 리소스에 고르게 분배하는 기술이다시스템의 성능, 가용성, 확장성을 향상 시키고 특정 서버에 부하가 집중되는 것을 방지한다클라이언트 사이드 로드 밸런싱클라이언트가 서버 요청을 보낼 때 서버의 위치를 직접 선택하여 트래픽을 분산하는 방식이다클라이언트가 직접 서버 인스턴스 목록을 관리하고 요청을 보낼 인

Load Balancing

#3. more hooks &amp; custom hooksWork through for prev. projectuseRefuseMemo, useCallback, useIduseReduceruseContextzustandCustom Hook #1. useLocalStorageCustom Hook #2. useAxiosFetchsecond project : 

#3. more hooks & custom hooks

.....이 주제는, Javascript 에 대한 사전 지식을 필요로 합니다......<h2>React 는, Javascript 프레임워크입니다.</h2>고도화 된 프레임웍 은 독립된 랭귀지 수준의 고유의 개발방식과 생태계를 갖게 되기도 하는데, 바로 리액트가 그러합니다.비슷한 시기에 태어난 Angular, Vue 등도 아직 건재합니다만, React 의 입지는 갈수록 탄탄해지고 있는 느낌이죠. 생태계의 규모도 워낙 압도적입니다.왜 React 인가.. 라는 질문은 이제 굳이 할 필요 없을 것 같습니다. 여기에서는, 어떻게 하면 React 를 빠르게 이해햘 수 있는가 라는 문제에 집중해 보려고 합니다...<h2>이 프로젝트는, 리액트 초급 용으로 기획되었습니다.</h2>이 프로젝트의 최종 단계에서 우리는,<ul class="tight" data-tight="true"><li>React-Router with dynamic Routing</li><li>React-Hook-Form and Zod Form Validation</li><li>Zustand 를 이용한 전역상태관리</li><li>Suspense</li></ul>까지 이해하는 것을 목표로 합니다. (NextJS 까지 다루지는 않습니다.) zustand 와 suspense 를 초급단계에서 핸들 되는 주제라고 말하기는 어렵겠지만, 본 프로젝트를 충실히 수행한 이후에는, ‘초급’ 이라는 수식어를 자신있게 떼어낼 수 있겠다는 의미로 받아들이시면 좋겠습니다...<h2>이 프로젝트는, 총 6 개의 연속 아티클로 기획되었습니다.</h2>#1. 리액트를 배우기 위한 사전 준비#2. npm create vite@latest &amp; first hooks#3. more hooks &amp; custom hooks#4. Form handling in React#5. React-Router-Dom#6. Suspense and Next..<h2>전체 목차</h2>,.<h1>#1. 리액트를 배우기 위한 사전 준비</h1><ol class="tight" data-tight="true"><li>JSX 구문</li><li>Imperative &amp; Declarative</li><li>v = f ( s )</li><li>ES5/ ES6 functions and literals</li></ol><h1>#2. npm create vite@latest &amp; first hooks</h1><ol class="tight" data-tight="true"><li>npm create vite@latest</li><li>Hello World React</li><li>basic hooks : useState</li><li>basic hooks : useEffect</li><li>Virtual DOM &amp; StrictMode</li><li>Components &amp; Props</li><li>React Dev-Tools</li><li>first project : your_name</li></ol><h1>#3. more hooks &amp; custom hooks</h1><ol class="tight" data-tight="true"><li>Workthrough for prev. project</li><li>useRef</li><li>useMemo, useCallback, useId</li><li>useReducer</li><li>useContext</li><li>zustand</li><li>Custom Hook #1. useLocalStorage</li><li>Custom Hook #2. useAxiosFetch</li><li>second project : not yet fixed</li></ol><h1>#4. Form handling in React</h1><ol class="tight" data-tight="true"><li>Workthrough for prev. project</li><li>Form Basics : Controlled Input &amp; UnControlled Input</li><li>React-Hook-Form</li><li>Zod + Resolver</li><li>fourth project : React-Hook-Form Project</li></ol><h1>#5. React-Router-Dom</h1><ol class="tight" data-tight="true"><li>Workthrough for prev. project</li><li>Routing in React</li><li>React-Router-Dom Basic</li><li>Nested Route</li><li>Dynamic Route</li><li>Error Handling and Fallback</li><li>Action handling</li><li>fifth project : not yet fixed</li></ol><h1>#6. Suspense and Next</h1><ol class="tight" data-tight="true"><li>Workthrough for prev. project</li><li>Portals</li><li>Suspense</li><li>Lazy</li><li>Async React Router</li><li>final project : not yet fixed</li></ol>

.....이 주제는, Javascript 에 대한 사전 지식을 필요로 합니다......React 는, Javascript 프레임워크입니다.고도화 된 프레임웍 은 독립된 랭귀지 수준의 고유의 개발방식과 생태계를 갖게 되기도 하는데, 바로 리액트가 그러합니다.비슷한 시기에 태어난 Angular, Vue 등도 아직 건재합니다만, React 의 입지는 갈수록 탄탄

React 를 배워봅시다. #0

팬텀 타입(Phantom Type)은 Haskell, Rust와 같은 언어에서 사용하는 기술이다. 팬텀 타입은 타입 매개변수(Generics)의 역할을 하는데, 실제 런타임에는 사용되지 않는 타입을 의미한다. 코드에서 타입 안전성을 강화하기 위해 사용된다......위와 같은 내용의 글들을 많이 읽었다. Typescript 사용자로써, 팬텀 타입에 대해 공부하려고 할 때마다 이게 무슨 뜻인지 이해가 잘 안 갔었는데, 공부하고 정리해본 내용을 이해하기 쉽게 예시와 함께 소개해보려고 한다.<h1>TypeScript는 구조적 타이핑을 하는 언어다</h1>구조적 타이핑이 무엇인지 알지 못하는 타 언어 사용자를 위해 짧은 설명을 하고 넘어가자. 구조적 타이핑은 클래스의 이름 따위가 아니라, '객체의 형태와 구조'를 타입의 중요한 요소로 여기는 방식을 의미한다.<pre spellcheck="false"><code class="language-typescript">class Human {
 name: string;
 age: number;
}

class Animal {
 name: string;
 age: number;
}

const member = {
 name: "Octoping",
 age: 25,
};

// 이 세 가지 객체 or 클래스의 타입은 사실상 전부 같다

function sayName(x: Human) {
 console.log(x.name);
}

// 전부 타입 문제 없이 작동한다
sayName(new Human("Octoping", 25));
sayName(new Animal("Pig", 3));
sayName(member);</code></pre>다음은 자바 같은 언어라면 생각도 못할 일이다. Human 클래스도, Animal 클래스도, member라는 변수도 <code spellcheck="false">string</code> 타입의 name과 <code spellcheck="false">number</code> 타입의 age를 가지므로 전부 같은 타입으로 인지하는 것이다.물론 객체를 클래스를 사용하지 않고도 바로 만들 수 있다는 자바스크립트의 특징 때문에 어쩌면 당연할 수 밖에 없다. 그리고 이 특성으로 인해 Typescript는 큰 생산성을 얻게 되면서 동시에 한 가지 단점을 얻게 되는데.<h2>문제 제기</h2>구조적 타이핑으로 인해 조금 불편을 겪을 수 있는 에피소드를 소개해보고자 한다.<pre spellcheck="false"><code class="language-typescript">type Dollar = number;
type Won = number;

// 십만원을 가진 나
const octopingMoney: Won = 100000;
const friendMoney: Won = 50000;

// 달러를 더하는 함수
function addDollar(a: Dollar, b: Dollar): Dollar {
 return a + b;
}

// 🥵
const result = addDollar(octopingMoney, friendMoney);</code></pre><code spellcheck="false">Dollar</code> 와 <code spellcheck="false">Won</code>은 둘 다 숫자지만, 단위가 다르므로 서로 더하면 안된다. 하지만 구조적 타이핑 덕분에 이런 놀라운 일이 가능해진다.이런 불편함을 어떻게 하면 좋을까?도메인 주도 개발에서 이야기하는 값 객체라는 걸 이용해보면 좋을 것 같다.<h2>값 객체를 다루기 어렵다</h2><pre spellcheck="false"><code class="language-java">class Member {
 private Email email;
 private Password password;
 // ...
}

class Email {
 private String value;

 public Email(String value) {
 if (!value.contains("@")) {
 throw new IllegalArgumentException("이메일 주소가 올바르지 않아요");
 }
 
 this.value = value;
 }
}

class Password {
 private String value;

 public Password(String value) {
 if (value.length() &lt; 8) {
 throw new IllegalArgumentException("비밀번호가 너무 짧아요");
 }

 this.value = value;
 }
}</code></pre>다음은 Java를 이용해서 값 객체 (VO)를 사용한 예제다. <code spellcheck="false">Member</code>에 이메일과 비밀번호를 그냥 String으로 저장하는 대신, 각각을 클래스로 묶어서 자기 자신이 값을 지님과 동시에 유효성 검사를 할 수 있도록 했다. 자신이 자기 자신을 그 자체로 소개할 수 있도록 하는 것. 그것이 도메인 주도 개발에서 이야기하는 값 객체이다.<pre spellcheck="false"><code class="language-typescript">class Member {
 constructor(
 private readonly email: Email,
 private readonly password: Password
 ) {}
}

class Email {
 value: string;

 constructor(value: string) {
 if (!value.includes("@")) {
 throw new Error("이메일 주소가 올바르지 않아요");
 }

 this.value = value;
 }
}

class Password {
 value: string;

 constructor(value: string) {
 if (value.length &lt; 8) {
 throw new Error("비밀번호가 너무 짧아요");
 }

 this.value = value;
 }
}

// 순서가 틀렸지만 당연히 에러가 나지 않는다!
const member = new Member(new Password("email"), new Email("password"));</code></pre>그런데 아뿔싸! 다음과 같은 코드를 Typescript에서 작성한다면 조금의 문제가 생겨버린다. 바로 <code spellcheck="false">Email</code>과 <code spellcheck="false">Password</code>의 시그니처가 똑같다는 것. 멤버 변수 타입 똑같고.. 메소드가 없는 것도 똑같은 것 같다. 당연히 에러가 나지 않겠지?<blockquote>이 문제에 대해서 진지하게 이야기해보면. 일단 첫 번째: 두 객체의 멤버 변수 값을 다르게 하면 된다. 그것이 구조적 타이핑이니까.. 하지만 서로 다른 두 클래스가 각자의 멤버 변수 이름에 강결합되는 프로그래밍을 유도하게 되는 것 같다. 두 번째: value를 private으로 만들면 된다.</blockquote><h2>문제 갈무리</h2>정리해보자. <code spellcheck="false">Dollar</code>와 <code spellcheck="false">Won</code>을 그냥 number로써 동일하게 표현하면 타입스크립트는 이 둘을 완전히 같은 타입으로 인지하여 똑같이 다뤄버리게 된다.이를 위해 값 객체를 사용해보려 하니 이 또한 멤버 변수의 이름을 신경써야 하니 나름의 어려움이 있다.마지막으로, 그냥 타입을 number로 쓸 때에 비해 객체를 생성해야 하니 메모리도 더 잡아먹게 된다. 객체지향이 원래 그런 것이다만은..<img src="https://image.until.blog/octoping/article/1723552083845" alt="until-1228">이런 상황을 어떻게 하면 좋을까?<h1>Phantom Type</h1>서론이 길었다. 팬텀 타입을 이용해보면 이런 문제를 해결해볼만한 실마리를 잡을 수 있을지도 모른다. 팬텀 타입을 내 나름대로 간단히 설명해보면 이렇다.<blockquote>형태는 같지만 실제로는 서로 다른 타입을 구분하기 위해, 실제로는 존재하지 않는 타입을 이용하는 것</blockquote><h2>코드로 살펴보기</h2><pre spellcheck="false"><code class="language-typescript">type Dollar = number &amp; { __unit: "Dollar" };
type Won = number &amp; { __unit: "Won" };

const myDollar = 2 as Dollar;
const myWon = 1000 as Won;</code></pre>달러와 원을 그냥 number가 아니라, <code spellcheck="false">number</code>이면서 <code spellcheck="false">{ __unit: string }</code> 인 녀석으로 정의하는 것이다.물론 이 뒷 부분은 실제 런타임에는 전혀 존재하지 않는 녀석이다. (타입스크립트에서 타입은 컴파일 단계에서 사라지므로 런타임에는 더더욱 존재하지 않게 된다)하지만 타입스크립트에게 억지로 이것이 존재한다고 함으로써 이 둘을 마냥 서로 같은 <code spellcheck="false">number</code>가 아니도록 만드는 것이다.<pre spellcheck="false"><code class="language-typescript">type Dollar = number &amp; { __unit: "Dollar" };
type Won = number &amp; { __unit: "Won" };


function addDollar(a: Dollar, b: Dollar): Dollar {
 return (a + b) as Dollar;
}

function dollarToWon(dollar: Dollar): Won {
 return (dollar * 1300) as Won;
}


const myDollar = 2 as Dollar;
const myWon = 1000 as Won;


const addedDollar = addDollar(myDollar, myDollar);
const convertedWon = dollarToWon(myDollar);

// 에러!
addedDollar(myWon, myWon);

// 에러!
convertedWon(myDollar);</code></pre>그렇다면 이렇게, 사실은 서로 같은 number를 서로 다른 타입처럼 사용할 수 있다.<h2>실생활 예제</h2>그럼 이걸 실생활에 어디다 어떻게 쓰라고? 팬텀 타입에 대해 다부지게 설명해주신 이 글에서 소개해준 예제를 조금 가공해서 빌려와볼까 싶다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://dev.to/busypeoples/notes-on-typescript-phantom-types-kg9">https://dev.to/busypeoples/notes-on-typescript-phantom-types-kg9</a><pre spellcheck="false"><code class="language-typescript">type MemberJoinPayload = {
 name: string;
 age: number;
};

export const onSubmit = (e: FormEvent&lt;HTMLFormElement&gt;) =&gt; {
 const payload: MemberJoinPayload = {
 name: e.currentTarget.name,
 age: e.currentTarget.age,
 };
 
 // validate를 해야 하지만 깜빡했다~~!!!!

 callApi(payload);
};

function validateData(data: MemberJoinPayload) {
 if (data.age &lt; 0) {
 throw new Error("나이가 음수에요");
 }
}

async function callApi(data: MemberJoinPayload) {
 // 대충 api 호출하는 코드
}
</code></pre>회원가입 폼에서 입력 받은 내용을 validate를 거친 후, 성공했다면 회원가입 api 호출 함수를 쏘는 로직을 떠올려보자.여기서 validate를 까먹어서 검증을 안 거치고 api를 호출하도록 코드를 작성하더라도 타입 상으로는 아무~ 문제가 없이 작동하기 때문에 내가 뭘 잘못했는지 생각 못하고 넘어갈 수 있다.여기서 팬텀 타입을 적용해보자.<pre spellcheck="false"><code class="language-typescript">type MemberJoinPayload = {
 name: string;
 age: number;
};

type UnvalidatedData = MemberJoinPayload &amp; { _type: "Unvalidated" };
type ValidatedData = MemberJoinPayload &amp; { _type: "Validated" };


export const onSubmit = (e: FormEvent&lt;HTMLFormElement&gt;) =&gt; {
 const payload = {
 name: e.currentTarget.name,
 age: e.currentTarget.age,
 } as UnvalidatedData;

 const validatedData: ValidatedData = validateData(payload);
 
 callApi(validatedData);
};

function validateData(data: UnvalidatedData): ValidatedData {
 if (data.age &lt; 0) {
 throw new Error("나이가 음수에요");
 }

 return { name: data.name, age: data.age } as ValidatedData;
 // return data as unknown as ValidatedData; 사실 이게 더 깔끔할지도
}

async function callApi(data: ValidatedData) {
 // 대충 api 호출하는 코드
}</code></pre>폼을 입력 받아 실행되는 <code spellcheck="false">onSubmit</code>에서 <code spellcheck="false">UnvalidatedData</code> 타입의 payload를 생성한다. 물론 이 변수로는 <code spellcheck="false">callApi</code> 함수를 실행할 수 없다.따라서 그 후 validate를 실행하면 <code spellcheck="false">ValidatedData</code> 타입의 결과를 받게 되니 이제서야 api를 호출할 수 있게 되는 것이다.실제 객체의 값은 전혀 변하지 않았고, <code spellcheck="false">__type</code>이니 뭐니 하는 것은 그 어디에도 존재하지 않았지만, 있는 타입이라고 타입스크립트에게 공갈을 하여 똑같은 타입의 서브 타입을 두 개를 만들어낸 것이다.<h2>팬텀 타입 추상화하기</h2>이 쯤 봤으면 팬텀 타입을 공용적으로 쓸 수 있게 추상화해볼 수 있겠다는 생각이 들 것이다. <code spellcheck="false">type Data = OriginalType &amp; { __value: string }</code> 대충 이런 형태이니..<pre spellcheck="false"><code class="language-typescript">type PhantomType&lt;Data, Type = never&gt; = Data &amp; { _type: Type };</code></pre>짜잔!그럼 이걸 이용해서 다양한 팬텀 타입을 원하는 대로 만들어보자.<pre spellcheck="false"><code class="language-typescript">type MemberJoinPayload = {
 name: string;
 age: number;
};

type UnvalidatedData = PhantomType&lt;MemberJoinPayload, "Unvalidated"&gt;;
type ValidatedData = PhantomType&lt;MemberJoinPayload, "Validated"&gt;;</code></pre><pre spellcheck="false"><code class="language-typescript">type Dollar = PhantomType&lt;number, "Dollar"&gt;;
type Euro = PhantomType&lt;number, "Euro"&gt;;
type Won = PhantomType&lt;number, "Won"&gt;;</code></pre><h2>ChatGPT가 추천하는 팬텀 타입 유망 직종</h2>다음은 ChatGPT에게 직접 팬텀 타입을 어디에 써보면 좋겠을지 물어보아 나온 결과인데 공유해본다.<ul><li>데이터베이스 ID 타입 구분<ul><li>서로 다른 테이블에서 사용되는 ID 값을 혼동하지 않도록 팬텀 타입을 사용할 수 있습니다</li></ul></li></ul><pre spellcheck="false"><code class="language-typescript">type UserId = PhantomType&lt;number, "User"&gt;;
type OrderId = PhantomType&lt;number, "Order"&gt;;

function getUserById(userId: UserId) {
 // 사용자 조회 로직
}

function getOrderById(orderId: OrderId) {
 // 주문 조회 로직
}

const userId: UserId = 1 as UserId;
const orderId: OrderId = 1 as OrderId;

// 올바른 사용
getUserById(userId);
getOrderById(orderId);

// 잘못된 사용 방지
// getUserById(orderId);</code></pre><ul><li>도메인 모델의 상태 구분<ul><li>상태 변화에 따른 도메인 모델의 상태를 팬텀 타입으로 구분하여, 잘못된 상태에서 발생할 수 있는 동작을 방지할 수 있습니다.</li></ul></li></ul><pre spellcheck="false"><code class="language-typescript">type Draft = { __status: 'Draft' };
type Published = { __status: 'Published' };

type Document&lt;Status&gt; = {
 content: string;
 status: Status;
};

function publish(doc: Document&lt;Draft&gt;): Document&lt;Published&gt; {
 return { ...doc, status: { __status: 'Published' } };
}

const draftDoc: Document&lt;Draft&gt; = {
 content: 'Draft content',
 status: { __status: 'Draft' }
};

// 올바른 상태 전환
const publishedDoc = publish(draftDoc);

// 잘못된 상태 전환 방지
// publish(publishedDoc); // 이미 게시된 문서는 다시 게시할 수 없음</code></pre>개인적으로 이건 비즈니스 로직에 관련된 건데 그냥 진짜 타입으로 관리해야 좋을 것 같다는 생각이다.<ul><li>서로 다른 API 엔드포인트에 안전하게 호출<ul><li>API 요청 시, 서로 다른 API 엔드포인트에 같은 데이터 타입을 사용하더라도, 요청 경로를 팬텀 타입으로 구분하여 잘못된 경로로 요청을 보내는 실수를 방지할 수 있습니다.</li></ul></li></ul><pre spellcheck="false"><code class="language-typescript">type PhantomType&lt;Data, Type = never&gt; = Data &amp; { _type: Type };

type ApiUri = string;
type OrderServerUri = PhantomType&lt;ApiUri, "주문"&gt;;
type UserServerUri = PhantomType&lt;ApiUri, "유저"&gt;;

async function fetchOrderList(uri: OrderServerUri, payload: any) {
 return fetch(uri, payload);
}

fetchOrderList("/api/order" as OrderServerUri, { userId: 1 });
fetchOrderList("/api/order" as UserServerUri, { userId: 1 }); // Error</code></pre>

Phantom Type 기초부터 알아보자

<h2>ServerWebExchange / GatewayFilterChain</h2><h3>1. 필터 실행 흐름</h3><blockquote><ul><li>스프링 클라우드 게이트웨이는 요청을 처리할 때 필터를 사용한다<ul><li>필터는 요청이 들어올 때 실행되며 요청을 수정하거나 검사하고, 응답을 수정하는 등의 역할을 한다</li></ul></li></ul></blockquote><h3>2. 메서드의 매개변수 개념</h3><blockquote><ul><li>필터의 filter() 메서드에서 두개의 매개변수(ServerWebExchange / GatewayFilterChain)가 전달된다</li></ul></blockquote><h3>3. ServerWebExchange</h3><blockquote><ul><li>해당 객체는 HTTP 요청과 응답을 담고 있다<ul><li>요청이 들어왔을 때 해당 요청과 응답에 관련된 모든 정보를 다룰 수 있게 해주는 객체</li></ul></li><li>요청 정보 : 요청 경로, 헤더, 쿼리 파라미터, HTTP 메서드 등</li><li>응답 정보 : 응답 상태 코드, 헤더, 응답 바디 등</li></ul></blockquote><h3>4. GatewayFilterChain</h3><blockquote><ul><li>해당 객체는 여러 개의 필터가 순차적으로 실행되도록 해준다<ul><li>다음 필터로 요청을 넘기는 역할</li></ul></li></ul></blockquote><h3>5. 흐름</h3><blockquote><ol><li>요청이 들어오면 ServerWebExchange로 요청을 다룬다<ul><li>exchange.getRequest() 를 사용해 요청 데이터를 가져올 수 있다 (Request를 가져올 수 있음)<ul><li>request.getURI() 로 요청의 경로를 가져올 수 있다 (Request 정보를 하나하나 가져올 수 있음)</li></ul></li></ul></li><li>필터 체인에 요청을 넘긴다<ul><li>chain.filter(exchange) 로 다음 필터로 요청을 넘긴다 (exchange가 해당 요청의 요청과 응답의 객체)<ul><li>다음 필터가 없으면 백엔드 서비스로 전달한다</li></ul></li></ul></li><li>후속 작업<ul><li>chain.filter(exchange) 가 끝나면 응답을 수정하는 후속 작업을 한다<ul><li>chain.filter(exchange)로 다음 Post 필터로 넘기고 만일 다음 필터가 없으면 클라이언트로 응답한다</li><li>.then() 을 이용해 응답이 처리된 후에 추가적인 작업을 할 수 있다</li></ul></li></ul></li></ol></blockquote><h3>핵심 내용</h3><blockquote><ul><li>ServerWebExchange : 요청과 응답을 처리하는 객체<ul><li>요청 정보 : exchange.getRequest()</li><li>응답 정보 : exchange.getResponse()</li></ul></li><li>GatewayFilterChain : 여러 필터가 순차적으로 실행되도록 한다<ul><li>chain.filter(exchange) → 요청을 다음 필터로 전달한다</li></ul></li></ul></blockquote>

ServerWebExchange / GatewayFilterChain1. 필터 실행 흐름스프링 클라우드 게이트웨이는 요청을 처리할 때 필터를 사용한다필터는 요청이 들어올 때 실행되며 요청을 수정하거나 검사하고, 응답을 수정하는 등의 역할을 한다2. 메서드의 매개변수 개념필터의 filter() 메서드에서 두개의 매개변수(ServerWebExchange / G

게이트웨이 필터

<h1>Chapter 1. AI 검증 비즈니스 프로젝트를 끝내며</h1><h2>개선할 것</h2><ul><li>구현해야 하는 기능들은 어려운 부분이 없었다고 생각이 들지만 최초에 설계를 잘해두면 구현할 때 이슈가 덜 발생할 것 같다<ul><li>예전에 API 명세서 외에 예상 시나리오 명세서를 작성하면서 설계를 보완했던 기억이 있는데 할 때는 귀찮고 번거로운 작업이더라도 기능 구현을 시작하기 전에 바로 잡을 수 있어 훨씬 효율적인 것 같다 -&gt; 그리고 프로젝트 서비스에 대해 전체적인 흐름과 각 도메인의 특징? 같은 걸 전체적으로 이해할 수 있을 것 같다</li></ul></li><li>인프라에 대해서도 고민해보고 시도해보면 좋을 것 같다<ul><li>해보지 않은 것, 부족한 부분에 대해서 도전하고 시도하는 자세를 가지기</li></ul></li></ul><h2>다른 팀의 발표를 보고 느낀점</h2><ul><li>같은 주제로 프로젝트를 진행했는데도 사용되는 기술들이 다양하다는 것이 놀라웠고 여러 기술을 도입해서 다양한 시도를 했다는 것에 멋지다는 생각이 들었다<ul><li>고정관념을 버릴 것..</li></ul></li></ul>

Chapter 1. AI 검증 비즈니스 프로젝트를 끝내며개선할 것구현해야 하는 기능들은 어려운 부분이 없었다고 생각이 들지만 최초에 설계를 잘해두면 구현할 때 이슈가 덜 발생할 것 같다예전에 API 명세서 외에 예상 시나리오 명세서를 작성하면서 설계를 보완했던 기억이 있는데 할 때는 귀찮고 번거로운 작업이더라도 기능 구현을 시작하기 전에 바로 잡을 수 있어

Chapter 1. 회고

Chapter 1. AI 검증 비즈니스 프로젝트를 끝내며

개선할 것

다른 팀의 발표를 보고 느낀점