이 이슈는 SvelteKit 라우팅 구성 시에 대한 주의사항과 대응방안을 제시하는 팁이다. 잘 읽고 숙지하기 바란다.
참고로, Next.js 및 Nuxt.js 는 이런 귀찮고 혼란스러운 혼용 라우팅 문제를 미연에 방지하기 위해 아예 api/ 폴더에 데이터를 뱉는 끝점을 만들도록 구성되어 있으니 해당 프레임워크로 개발하는 사람들은 그냥 안심하고 갈 길 가면 된다.
SvelteKit 라우팅은 꽤 유연한 방식을 제공하고 있으나,
너무나 유연해서 주의해야 할 게 있는게,
바로 Svelte 파일과 js 및 ts 파일 이름이 같을 경우에 대한 혼용 끝점(Endpoint)이다.
예를 들면,
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 쓰기 바란다.
참고로 스트림 응답은 위 두 개는 아직 서버리스 기준으로 아직 지원 안 한다. 물론 지원 예정이니 걱정 마시라. 아니면 node.js 단독 서버인 경우 스트림 그냥 되니 쓰면 된다. SvelteKit 가 SSR 패키지 중에는 유이하다고 하겠다. 다른 하나는 Deno의 Fresh.
실무에 사이드 프로젝트 및 쇼케이스, 프로토타이핑, 연구 및 해당 과제를 위한 프로그램 목적 외에 상용으로 SvelteKit 를 사용하지 않는 것을 추천한다.
차라리 그냥 스벨트를 쓰길 바란다. 걔는 안정적으로 이미 오라클, 이케아, IBM까지 굵직한 대기업에서 신뢰하면서 쓰고 있다.
끗.
Top comments (0)