Netlify Netlify 무료 Netlify 단점 Netlify 백엔드 Netlify 사용법 Netlify 여러개

Netlify 동적사이트 - netlify dongjeogsaiteu

  • 관리
  • 글쓰기
  • 로그인
  • 로그아웃

    Web Client/React

    [배포] 클라이언트 빌드와 배포

    2022. 4. 12.

    클라이언트 빌드

    SSR과 CSR

    • 차이 : 서버에 데이터를 요청했을 때 html파일이 어디서 조작되는가
    • 브라우저의 작동 원리 참고

    1. SSR

    const express = require('express') const app = express() const username = db.findOne({where: {id: 1}} app.get('/', function (req, res) { res.status(200).send(username) })
    • 장점 : 초기 랜딩 속도가 빠르며 검색 엔진 최적화(SEO)가 가능
      웹 사이트가 검색 결과에 더 잘보이도록 최적화하는 과정
    • 단점 : 페이지를 요청할 때마다 새로고침이되며, 요청이 많아지면 서버에 부담

    2. CSR

    function Userinfo (prop) { const [username, setUsername] = useStates('') function getUsername () { axios.get('//localhost:4000') .then(data => { return data.json() }) .then(json => { setUsername(json.username) }) } return ( <div> <span class='username'> {username} </span> </div> ) }
    • 장점 : 초기 요청을 제외하면 페이지 랜딩 속도가 빠르며 서버에 부담이 적고, 사용자 경험이 좋음
    • 단점 : 최초 로딩 속도가 느리며 검색 엔진 최적화(SEO)에 불리

    정적 웹사이트 vs 동적 웹사이트

    정적 웹사이트
    : HTML 파일(코드) 자체로 배포되는 사이트 (CSR, Client Side Rendering)
    : 서버는 미리 만들어진 HTML, JS 파일을 전달하기만 함(서버 자원과 무관)

    동적 웹사이트
    : 서버에 의해 HTML 파일이 동적으로 생성되는 사이트 (SSR, Server Side Rendering)
    : 서버는 늘 HTML 파일을 만들어 응답해주어야 함(서버 자원에 따라 페이지의 형태 바뀜)

    현대의 2-tier Architecture에서는 정적 웹사이트의 사용이 더욱 보편적

    SSR의 장점을 살리기 위해서 다양한 방법으로 동적 웹사이트가 만들어지기도 함

    성능의 향상을 극대화하기 위해 CCR, SSR의 하이브리드 형태로 구성하는 경우도 많음

    1. AJAX 이전

    // node.js를 활용한 동적 웹페이지 예제 const http = require('http'); const server = http.createServer((req, res) => { res.setHeader('Content-Type', 'text/html'); // HTML 문서의 형태로 전달됨 res.end('<h2>동적 웹페이지</h2><p>with 랜덤한 값</p>' + Math.random()); // 서버에 의해서 동적으로 바뀜 }); server.listen(3000);
    • 서버에서 웹페이지를 만드는 기술이 보편화되었고, 이러한 동적 웹사이트를 만드는 기술로는 PHP, JSP, ASP 등이 널리 사용
      *node.js로도 동적 웹페이지를 만드는 것 가능
    • 요청에 따라 결과가 변하는 동적인 웹페이지를 만드려면, 서버가 매번 동적으로 생성하는 수 밖에 없었음
    • 동적 웹사이트를 받아오기 위해서는 서버가 HTML의 형태로 브라우저에 제공해주어야만 했기 때문에, 헤더나 푸터 등의 페이지 구성요소의 중복 요청/응답이 빈번
      *네트워크 상에서 주고받는 패킷의 크기가 다소 컸음

    2. AJAX 기술 보편화

    • 브라우저의 발달과 AJAX 기술이 보편화되면서, 모든 동적인 정보들을 서버가 부담할 필요는 없게 됨
      *필요한 부분만 클라이언트가 요청할 수 있게 되었고, 이로 인해 서버의 부하가 다소 줄어듦
    • 서버는 JSON과 같은 순수한 데이터 포맷만 제공
    • 클라이언트 사이드(웹페이지)는 자바스크립트와 AJAX 기술을 이용한 보다 고도화된 웹 앱, 즉 Single Page Application으로 변모
    • 자바스크립트가 동적인 렌더링을 지원하나, 결국 서버가 웹페이지를 렌더링하지 않으며, HTML/CSS/JS 파일의 소스 코드 그대로 작동하는 특징을 갖고있어 이를 정적 웹사이트라 함

    3. 빌드

    3-1. 정적 웹사이트의 빌드

    React 프로젝트
    내 로컬 컴퓨터에서 자체적으로 실행 : npm start로 개발 서버를 실행
    인터넷 상에 배포 : 정적 파일을 호스팅하는 서비스에 결과물만 업로드

    • SPA(Single Page Application)으로 변모함에 따라 클라이언트 사이드의 규모가 커짐
    • 웹사이트 구성요소를 각 파일로 분리하는 모듈화가 이뤄지게 되었고, React와 같은 클라이언트 기술이 발전하면서 단일 파일로 자바스크립트나 페이지를 만드는 작업은 보다 고도화
    • 번들링(bundling) : 고도화된 클라이언트 웹 앱의 수많은 모듈을 하나로 묶어주는 작업
      *JSX 파일과 같이 브라우저에서 자체적으로 해석이 불가능한 다양한 보조 기술들을 브라우저가 해석할 수 있도록 만들어주는 작업들이 수반
    • 소프트웨어 빌드 : 위 과정을 통칭하는 용어로 소스코드를 실행 가능한 결과물로 변환하는 작업을 의미
    • 다양한 모듈은 정적 파일들로 결과가 만들어져야만 하며, 이러한 빌드 과정은 배포에 필수적
      *Create React App 등으로 생성한 React 프로젝트의 경우에는, npm build 명령어가 package.json 파일에 포함되어 있으며, 이는 모듈을 정적인 파일로 만들어 줌

    3-2. React 프로젝트 생성 툴

    • React 생태계에는 Create React App, Next.js 등 다양한 프로젝트를 생성 툴이 존재
    • Create React App으로 만든 프로젝트의 경우 react-scripts 모듈 사용
    • Next.js의 경우 next 모듈 사용

    3-3. 빌드 툴

    1. webpack : 모듈 번들러
    2. babel : TypeScript, JSX 등과 같이 브라우저가 지원하지 않는 언어를 JavaScript로 바꿔주는 컴파일러
    3. ESLint : 자바스크립트 Code convention 및 문법 검사기
    4. Sass, less : CSS Preprocessor

    • 프로젝트 생성 툴의 구성 : 내부적으로 다양한 툴의 조합
    • 번들러 : 빌드 자동화를 도와주는 도구

    클라이언트 배포

    • 서비스를 공개적으로 알려주는것이 배포의 궁극적인 목표

    1. 클라이언트 웹 앱 배포

    다양한 웹 호스팅 서비스
    Amazon Web Service (AWS) S3
    : Infrastructure 자체를 제공하는, 다소 복잡한 서비스들의 집합
    Vercel
    : 코드 연결과 빌드, 배포까지의 과정을 매우 단순하게 만들어줌
    Google Cloud Storage
    GitHub
    Pages
    Netlify
    Heroku

    • 로컬 환경에서 개발한 코드를 실제 서비스로 만들기 위해선 빌드 과정과 이를 웹에 노출시키는 배포 과정 필요
    • 빌드를 통해 만든 정적 파일이 웹을 통해 제공(serve)되려면 정적 파일을 제공하는 웹 서버가 필요
    • 일반적인 웹 서버 : 웹 서비스를 제공하는 모든 종류의 서버
    • 호스팅 서비스 : 특별히 정적 파일을 제공할 수 있도록 서버의 공간을 대여해주는 서비스로 단순 파일을 웹에서 접근 가능하게 만들어 줌
      *동적 웹사이트나 express 등을 사용한 API 서버를 제공하려면 별도의 클라우드 컴퓨팅 서비스 필요
    • 클라이언트 앱이 아닌 서버 앱(API 서버)의 경우는, 실제로 node.js를 실행할 수 있는 컴퓨터가 필요

    2. Vercel 이용하기

    • Vercel : GitHub와 같은 코드베이스(저장소)를 연결하여, 즉시 빌드를 실행하고, 배포까지 원클릭으로 할 수 있음
      *실제로 배포는 Vercel 서비스 내에서 이루어짐
    • Vercel은 자체 GitHub 앱을 제공하기에 Vercel 앱을 GitHub 플랫폼에 설치하면 앱이 내 repository에 접근할 수 있음
    • React로 작성된 프로젝트 : npm start로 실행가능하며, npm build로 빌드가 가능
    • fork한 Repository가 목록에 표시 : Import 버튼을 눌러, 해당 Git Repository를 배포

    2-1. 프로젝트 설정

    1. 프로젝트 이름을 원하는 대로 작성
    2. fork하고 배포하려는 프로젝트의 Framework 선택
    3. build command는, 빌드에 필요한 CLI 명령어를 의미
      *npm run build가 기본값이며, 기본값 그대로 두어도 빌드는 성공적으로 이뤄짐
    4. npm run build 이후 빌드 결과물이 어떤 디렉토리에 생기는지에 따라 이 값이 변할 수 있음
      *build가 기본값이며, 그대로 두어도 됨
    5. Deploy버튼을 눌러 배포를 시작해봅시다.

    2-2. 자동 빌드 및 배포

    • 배포 전 빌드 과정(npm install, npm build)을 자동으로 수행
    • 이후, 빌드 결과물을 Vercel 플랫폼이 자체적으로 호스팅
      *fork된 Repository에 변경사항을 만들고 푸시하면 자동으로 빌드 및 배포 과정이 진행

    2-3. 배포 성공

    • 빌드가 성공적으로 이뤄지면, Vercel이 제공하는 URL을 통해 내 프로젝트가 호스팅

    2-4. 대시보드

    • 개발환경이 아닌 프로덕션 환경에서의 배포 현황을 프로젝트 별로 볼 수 있음
    1. DOMAIN실제 배포된 URL에 접속 가능
    2. STATE현재 배포 상태에 대한 확인 가능
    3. DEPLOYMENT배포 현황과 관련된 CLI 출력을 볼 수 있음

    관련 게시물

    Toplist

    최신 우편물

    태그