분류 전체보기

CEOS 에서 진행하는 프로젝트를 이제 곧 시작하게 된다. 우리는 고민 끝에 Next 도입의 필요성을 느꼈고, Next와 이에 최적화 되어있는 TailwindCSS를 사용하기로 하였다. 왜 Next를 선택하였나? Next는 기본적으로 SSR(Server Side Rendering)에 최적화 되어있는 프레임워크라고 잘 알려져있다. CSR(Client Side Rendering) CSR은 우리가 흔히 알고있는 create-react-app 으로 쉽게 세팅할 수 있다. 위 사진은 CSR의 동작 방식을 나타낸다. 사용자가 페이지에 접속하면 클라이언트(브라우저)가 이를 인지하여 서버에 해당 데이터들(HTML, JS코드 등)을 요청한다. 브라우저가 데이터를 받게 되면 JS파일을 다운로드한 후 페이지를 보여준다. 모..

이전 포스팅에서 Vite와 Yarn berry 세팅을 마쳤다. 해당 세팅으로 인해 당연히 배포 방법도 달라질 것이다. 그래도 크게 변하는 건 없어서 이번 포스팅을 통해 해당 세팅 시 배포 방법을 정리하려고 한다. 기본적인 리액트 프로젝트 배포 방법 https://doyourbestcode.tistory.com/124 https://doyourbestcode.tistory.com/125 https://doyourbestcode.tistory.com/126 ✅ 윈도우(Windows) ✅ React(Create React App + Typescript) ✅ Vite + Yarn berry(Zero-installs) Dockerfile 작성 FROM node:18 AS builder # set working d..

우리는 지금까지 NPM 패키지 매니저를 사용해왔다. 그러나 NPM 패키지 매니저에 관해서 항상 많은 문제점들이 제기되어 왔다. https://toss.tech/article/node-modules-and-yarn-berry 해당 블로그에 정리가 매우 잘 되어있다. 다시 복기하는 겸 내 블로그에 작성하며 공부해보기로 했다. 비효율적인 의존성 검색 NPM 프로젝트에서 node에 진입 후 react 패키지를 찾는 상황을 연출해보자. 위에서 볼 수 있듯이 npm은 패키지를 찾기 위해 상위 디렉토리의 node_modules 폴더를 탐색하게 되고, 바로 찾지 못할 수록 느린 I/O 호출이 반복되게 된다고 한다(실패하기도 함). 환경에 따라 달라지는 동작 위에서 보았듯이 NPM은 패키지를 찾지 못하면 상위 디렉토리의..

브라우저에서 ESM(ES Modules)을 지원하기 전까지, JavaScript 모듈화를 네이티브 레벨에서 진행할 수 없었다. 그래서 소스 모듈을 브라우저에서 실행할 수 있는 파일로 크롤링, 처리 및 연결하는 "번들링(Bundling)"이라는 해결 방법을 사용해야 했다. 보통 리액트 등의 프론트 프로젝트를 시작 시 웹펙(webpack) 으로 번들링을 진행한다. 콜드 스타트 방식으로 개발 서버를 구동할 때, 번들러 기반의 도구의 경우 애플리케이션 내 모든 소스 코드에 대해 크롤링 및 빌드 작업을 마쳐야지만이 실제 페이지를 제공할 수 있다. * 콜드 스타트(Cold Start): 최초로 실행되어 이전에 캐싱한 데이터가 없는 경우를 의미 위의 그림처럼 번들링 후에야 개발 서버를 구동할 수 있으므로 개발 서버를..

프론트 프로젝트 배포에 성공하여 안도하던 찰나, 큰일이 발생하였다. 우리는 사용자의 목소리를 분석하여 노래를 추천해주는 서비스를 구현해 보았는데, 이를 위해서는 목소리 녹음 기능이 필수적이였다. 우리는 사용자 PC에서 미디어의 스트림을 얻어내는 MediaStream의 API인 getUserMedia를 사용하였다. 문제는 이 기능이 로컬에서는 잘 동작하였는데, http로 배포한 주소에서는 오류가 발생하였다. 원인을 찾아보니 getUserMedia는 https에서만 동작한다는 설명이 있었다. 이를 해결하기 위해 백 프론트 모두 인스턴스에 https를 적용하기로 하였다. HTTP HTTP (HyperText Transfer Protocol)​​는 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있..

이전 포스팅에서 Docker와 AWS EC2를 활용하여 http 배포에 성공하였다. 그런데 만약 코드에서 수정사항을 배포된 주소에 반영하려면 다시 재배포 해야하는데, 이를 수동으로 하려면 생각만하도 너무 귀찮다. 이런 상황을 위해 Github Actions를 활용하여 CI/CD를 적용해보자. 최종 배포될 브랜치는 main 브랜치이므로 main 브랜치에 push가 감지되면 실행할 작업(Workflow)를 설정해야 한다. github 레포로 가서 루트 경로의 .github/workflows 위치에 yml 파일을 생성해준다. 나는 prod.yml 파일을 해당 경로에 생성해 주었다. name: Docker on: push: branches: [main] jobs: build: runs-on: ubuntu-lat..