<div id="readability-page-1" class="page"><article id="article-show-container" data-article-id="1142047" data-article-slug="sveltekit-rauting-guseong-si-juyihal-jeom-2cjl" data-author-id="201866" data-author-name="Ukjin Yang" data-author-username="composite" data-co-author-ids="" data-path="/composite/sveltekit-rauting-guseong-si-juyihal-jeom-2cjl" data-pin-path="/stories/feed/pinned_article" data-pinned-article-id="" data-published="true">
        <header id="main-title">

          <div>
                <p><a href="/composite"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--i7tYDRmB--/c_fill,f_auto,fl_progressive,h_50,q_auto,w_50/https://dev-to-uploads.s3.amazonaws.com/uploads/user/profile_image/201866/5014b724-95d6-43af-8561-79a14911a196.png" width="40" height="40" alt="Ukjin Yang"></a>
                </p>
                
              </div>
        </header>

        <div data-article-id="1142047" id="article-body">
            <p>이 이슈는 SvelteKit 라우팅 구성 시에 대한 주의사항과 대응방안을 제시하는 팁이다. 잘 읽고 숙지하기 바란다.<br>
참고로, Next.js 및 Nuxt.js 는 이런 귀찮고 혼란스러운 혼용 라우팅 문제를 미연에 방지하기 위해 아예 <code>api/</code> 폴더에 데이터를 뱉는 끝점을 만들도록 구성되어 있으니 해당 프레임워크로 개발하는 사람들은 그냥 안심하고 갈 길 가면 된다.</p>

<p>SvelteKit 라우팅은 꽤 유연한 방식을 제공하고 있으나,<br>
너무나 유연해서 주의해야 할 게 있는게,<br>
바로 Svelte 파일과 js 및 ts 파일 이름이 같을 경우에 대한 혼용 끝점(Endpoint)이다.<br>
예를 들면,</p>

<blockquote>
<p><code>src/routes/path/to/something.svelte</code><br>
<code>src/routes/path/to/something.js</code></p>
</blockquote>

<p>이럴 경우, 우선 순위가 어떻게 되느냐, 누가 먼저 선점하게 되는 게 아니라,   어떤 응답을 받아도 결국엔 스벨트 컴포넌트를 응답하게 된다.<br>
이 말인 즉슨, <code>.js</code> 끝점의 응답 값을 <code>.svelte</code> 컴포넌트의 속성에 전달한다는 뜻이다. 마치 스프링 등의 MVC 프레임워크 사용 시 컨트롤러가 데이터 바인딩 후 뷰 호출하는 것처럼.<br>
이렇게 되기 때문에, <code>.js</code> 라우팅에서 <code>body</code> 속성을 통해 전달할 수 있는 값은 단 2가지로 한정짓게 된다.</p>

<ul>
<li>원시 객체(JSON)</li>
<li>오류 객체(<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error"><code>Error</code></a>)</li>
</ul>

<p>만약 단독 API 구성 시 아래 유형이 추가로 지원된다.<br>
하지만 위 혼용 문제 해결 방법을 후술할 것이며, 이를 만족할 경우에도 마찬가지.</p>

<ul>
<li>바이트 배열(<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array"><code>UInt8Array</code></a>)</li>
<li>읽기 스트림(<a href="https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream"><code>ReadableStream</code></a>)</li>
</ul>

<p>따라서 텍스트나 다운로드할 이미지 바이트 및 스트림 등등 자유자재 응답이 가능하다.<br>
참고로 스트림은 <code>@sveltejs/kit@1.0.0-next.370</code> 버전부터 지원한다.<br>
(이전 버전에도 구현했지만 <a href="https://github.com/sveltejs/kit/issues/5412">메모리 공격 문제</a>가 발견되어 이를 해결한 최초 버전 기준)</p>

<p>다시 본론으로 가서, 혼용으로 인한 컴포넌트를 타지 않고 단독 API로 운용하고자 한다면 아래 항목 중 하나를 만족시키면 된다.<br>
이는 현재 버전인 <code>@sveltejs/kit@1.0.0-next.377</code> 기준 HTTP METHOD(<code>GET</code>, <code>POST</code> 등)를 달리 호출 시에도 똑같이 적용된다.</p>

<ul>
<li>방금 말했듯이 같은 파일명을 가진 <code>.svelte</code> 파일이 없으면 된다.</li>
<li>
<code>fetch</code> 등의 API 요청 시 <code>accept</code> 헤더 추가
예) <code>{ headers: { accept: 'application/json' } }</code>
</li>
<li>아예 확장자를 추가할 수도 있다. 예) <code>.js</code> 대신 <code>.json.js</code> 로 변경</li>
</ul>

<p>이 중 2번째 방법이 같은 파일명을 가진 컴포넌트와 API 파일 사용 시에 대한 유일한 해결방안이 될 수 있겠다.</p>

<p>더 무서운 점은 이런 파일 기반 라우팅에 대한 구조도가 아직도 <a href="https://github.com/sveltejs/kit/discussions/5037">현재진행형</a> 이라는 것이다. 아직 베타 버전이고, 심지어 RC 단계도 아니기 때문에. 확정 안 됐다. 언제든 구조가 바뀔 수도 있기 때문에 언제든 대응할 수 있도록 준비해야 할 것이다.</p>

<p>그래서 만약 안정적인 SSR 프레임워크 사용을 꾀한다면... 거의 완제품이나 다름없는 그냥 Next.js 및 Nuxt.js 쓰기 바란다.<br>
참고로 스트림 응답은 위 두 개는 아직 서버리스 기준으로 아직 지원 안 한다. 물론 지원 예정이니 걱정 마시라. 아니면 node.js 단독 서버인 경우 스트림 그냥 되니 쓰면 된다. SvelteKit 가 SSR 패키지 중에는 유이하다고 하겠다. 다른 하나는 Deno의 <a href="https://fresh.deno.dev/">Fresh</a>.<br>
실무에 사이드 프로젝트 및 쇼케이스, 프로토타이핑, 연구 및 해당 과제를 위한 프로그램 목적 외에 상용으로 SvelteKit 를 사용하지 않는 것을 추천한다.<br>
<strong>차라리 그냥 스벨트를 쓰길 바란다. 걔는 안정적으로 이미 오라클, 이케아, IBM까지 굵직한 대기업에서 신뢰하면서 쓰고 있다.</strong></p>

<p>끗.</p>


          </div>
          
  



      </article></div>

Ukjin Yang

이 이슈는 SvelteKit 라우팅 구성 시에 대한 주의사항과 대응방안을 제시하는 팁이다. 잘 읽고 숙지하기 바란다.
api/ 폴더에 데이터를 뱉는 끝점을 만들도록 구성되어 있으니 해당 프레임워크로 개발하는 사람들은 그냥 안심하고 갈 길 가면 된다.
SvelteKit 라우팅은 꽤 유연한 방식을 제공하고 있으나,
src/routes/path/to/something.svelte
src/routes/path/to/something.js
이럴 경우, 우선 순위가 어떻게 되느냐, 누가 먼저 선점하게 되는 게 아니라,   어떤 응답을 받아도 결국엔 스벨트 컴포넌트를 응답하게 된다.
.js 끝점의 응답 값을 .svelte 컴포넌트의 속성에 전달한다는 뜻이다. 마치 스프링 등의 MVC 프레임워크 사용 시 컨트롤러가 데이터 바인딩 후 뷰 호출하는 것처럼.
.js 라우팅에서 body 속성을 통해 전달할 수 있는 값은 단 2가지로 한정짓게 된다.
원시 객체(JSON)
오류 객체(Error)
만약 단독 API 구성 시 아래 유형이 추가로 지원된다.
바이트 배열(UInt8Array)
읽기 스트림(ReadableStream)
따라서 텍스트나 다운로드할 이미지 바이트 및 스트림 등등 자유자재 응답이 가능하다.
@sveltejs/kit@1.0.0-next.370 버전부터 지원한다.
메모리 공격 문제가 발견되어 이를 해결한 최초 버전 기준)
다시 본론으로 가서, 혼용으로 인한 컴포넌트를 타지 않고 단독 API로 운용하고자 한다면 아래 항목 중 하나를 만족시키면 된다.
@sveltejs/kit@1.0.0-next.377 기준 HTTP METHOD(GET, POST 등)를 달리 호출 시에도 똑같이 적용된다.
방금 말했듯이 같은 파일명을 가진 .svelte 파일이 없으면 된다.
fetch 등의 API 요청 시 accept 헤더 추가
예) { headers: { accept: 'application/json' } }
아예 확장자를 추가할 수도 있다. 예) .js 대신 .json.js 로 변경
이 중 2번째 방법이 같은 파일명을 가진 컴포넌트와 API 파일 사용 시에 대한 유일한 해결방안이 될 수 있겠다.
더 무서운 점은 이런 파일 기반 라우팅에 대한 구조도가 아직도 현재진행형 이라는 것이다. 아직 베타 버전이고, 심지어 RC 단계도 아니기 때문에. 확정 안 됐다. 언제든 구조가 바뀔 수도 있기 때문에 언제든 대응할 수 있도록 준비해야 할 것이다.
그래서 만약 안정적인 SSR 프레임워크 사용을 꾀한다면... 거의 완제품이나 다름없는 그냥 Next.js 및 Nuxt.js 쓰기 바란다.
Fresh.
차라리 그냥 스벨트를 쓰길 바란다. 걔는 안정적으로 이미 오라클, 이케아, IBM까지 굵직한 대기업에서 신뢰하면서 쓰고 있다.
끗.

SvelteKit 라우팅 구성 시 주의할 점

댓글