본문 바로가기
카테고리 없음

TIL (2023/9/23) Saturday

by 0to1ton 2023. 9. 23.
  • 팀원들과의 trello clone 을 merge하는 날이었다
  • frontend 도 오늘 꽤 작업을 해봤는데 나름 재밌다
  •  
 

join과 resolve의 차이점

path.join([...paths])

  • **path.join**은 인자로 전달된 모든 경로 조각을 합칩니다.
  • 결과 경로는 상대 경로일 수도 있고, 절대 경로일 수도 있습니다.
  • 예를 들어, **join('/foo', 'bar', 'baz/asdf')**는 **/foo/bar/baz/asdf**를 반환합니다.

path.resolve([...paths])

  • **path.resolve**는 인자로 전달된 경로 조각을 합친 후, 절대 경로로 변환합니다.
  • 만약 상대 경로가 전달되면, 현재 작업 디렉토리를 기반으로 절대 경로를 생성합니다.
  • 예를 들어, 현재 작업 디렉토리가 **/home/user**이고 **resolve('..', 'public')**을 호출하면 **/home/public**을 반환합니다.

왜 resolve가 작동하고 join이 작동하지 않는가?

  • **resolve**는 현재 작업 디렉토리를 기반으로 절대 경로를 생성하기 때문에, 상대 경로가 문제를 일으킬 여지가 적습니다.
  • **join**은 단순히 문자열을 합치기 때문에, 상대 경로나 절대 경로를 정확히 지정해야 합니다.
  • **__dirname**은 현재 실행 중인 스크립트의 디렉토리를 나타내므로, 이를 사용하면 보통은 문제가 없어야 합니다. 하지만 이 경우에는 **__dirname**을 사용하는 것이 문제를 일으킨 것 같습니다.

Server Side Template Engine

hbs (Handlebars)와 ejs (Embedded JavaScript)는 둘 다 서버 사이드 템플릿 엔진입니다. 어떤 것을 사용할지 결정하기 위해 몇 가지 고려사항이 있습니다:

EJS

  1. 간단하고 직관적: EJS는 JavaScript 문법을 그대로 사용하기 때문에 JS에 익숙하다면 더 쉽게 접근할 수 있습니다.
  2. 문법: <%= %> 또는 **<%- %>**와 같은 태그를 사용하여 데이터를 삽입합니다.
  3. 커스터마이징: JavaScript 함수를 사용하여 로직을 삽입할 수 있습니다.
  4. 커뮤니티 지원: 광범위한 커뮤니티 지원과 문서가 있습니다.

HBS (Handlebars)

  1. 논리 분리: Handlebars는 논리와 템플릿을 분리하는 데 더 중점을 둡니다. 이로 인해 템플릿이 더 깔끔해질 수 있습니다.
  2. 문법: **{{ }}**를 사용하여 데이터를 삽입합니다.
  3. 헬퍼 함수: 사용자 정의 헬퍼 함수를 쉽게 추가할 수 있어, 템플릿 내에서 복잡한 로직을 처리할 수 있습니다.
  4. 재사용성: 템플릿을 부분적으로 재사용하기 쉽습니다.

결정 요소

  • 프로젝트의 복잡성: 복잡한 논리가 필요하다면 EJS가 더 나을 수 있습니다. 간단하고 깔끔한 템플릿을 원한다면 Handlebars가 더 적합할 수 있습니다.
  • 개인적인 취향: 어떤 문법이 더 편한지도 중요한 요소입니다.
  • 커뮤니티와 지원: 둘 다 널리 사용되고 있지만, 필요한 특정 플러그인이나 라이브러리가 있는 경우 해당 엔진을 선택할 수 있습니다.

둘 중 어느 것도 나쁜 선택이 아니며, 프로젝트의 요구 사항과 개인적인 취향에 따라 결정하면 됩니다.

SSG / SSR 이랑 MVC 비교해줘

SSG(SSG), SSR(Server-Side Rendering), 그리고 MVC(Model-View-Controller)는 웹 개발에서 자주 사용되는 패턴이나 접근 방식입니다. 각각의 특징과 차이점을 알아보겠습니다.

SSG (Static Site Generation)

  • 특징: 빌드 타임에 모든 페이지를 미리 생성합니다.
  • 장점: 빠른 로딩 속도, SEO 최적화, 서버 부하 감소.
  • 단점: 동적 데이터를 다루기 어렵습니다. 새로운 데이터가 있을 때마다 빌드를 다시 해야 합니다.
  • 적합한 케이스: 블로그, 문서 사이트, 소개 페이지 등 정적인 콘텐츠가 많은 사이트.

SSR (Server-Side Rendering)

  • 특징: 클라이언트의 요청이 있을 때마다 서버에서 페이지를 생성합니다.
  • 장점: 동적 데이터를 쉽게 다룰 수 있고, SEO가 잘 지원됩니다.
  • 단점: 서버 부하가 늘어날 수 있고, 초기 로딩 속도가 느릴 수 있습니다.
  • 적합한 케이스: 동적인 데이터가 많고, 사용자 인터랙션이 많은 웹 애플리케이션.

MVC (Model-View-Controller)

  • 특징: 애플리케이션을 Model, View, Controller 세 부분으로 나누어 개발합니다.
  • 장점: 유지보수가 쉽고, 테스트하기 좋습니다. 개발자 간의 협업이 쉽습니다.
  • 단점: 설계 초기에 구조를 잘 잡아야 하며, 복잡한 프로젝트에서는 관리가 어려울 수 있습니다.
  • 적합한 케이스: 규모가 크고 복잡한 웹 애플리케이션, 여러 개발자가 함께 작업할 때.

비교

  • SSG와 SSR은 주로 페이지의 렌더링 방식과 관련이 있습니다.
  • MVC는 애플리케이션의 전체 아키텍처와 관련이 있습니다.
  • SSR은 주로 MVC 패턴과 함께 사용될 수 있으며, 서버에서 뷰를 생성하는 부분이 SSR에 해당됩니다.
  • SSG는 일반적으로 MVC와는 별개로 동작하지만, 빌드 타임에 **Model**에서 데이터를 가져와 **View**를 생성할 수 있습니다.

각 방식은 특정한 문제를 해결하기 위해 설계되었으므로, 프로젝트의 요구 사항에 따라 적절한 방식을 선택하면 됩니다.

티스토리툴바