분류 javascript

Jamstack 소개 : 안전한 고성능 사이트 구축

컨텐츠 정보

  • 조회 384 (작성일 )

본문

웹 개발은 종종 더 나은 방향으로 극적인 변화를 가져옵니다. 이 기사에서는 Jamstack이 무엇이고 왜 좋은지 설명하면서 Jamstack을 소개합니다.


https://www.sitepoint.com/learn-jamstack/


과거에는 동적 사이트가 LAMP(Linux; Apache; MySQL / MariaDB, PHP/ Perl 또는 Python) 스택으로 폭발했습니다. 그런 다음 MEAN(Mongo DB, Express JS, Angular, Node JS) 스택은 차세대 웹 앱의 기반을 제공했습니다. 이제 API와 재사용 가능한 구성 요소가 증가하고 있으므로 정적 사이트가 다시 유행합니다. 일종의 "기본으로 돌아 가기"입니다.하지만 정답은 아닙니다.


Jamstack이란 무엇입니까? 


Jamstack logo 

Jamstack은 더 빠르고 안전한 웹 사이트를 위해 최신 웹을 재정의 한 것입니다. 이러한 사이트는 더 잘 확장되고 적절한 도구 집합을 사용하면 개발 및 유지 관리가 훨씬 더 쉽고 재미있어 집니다.


용어를 나누겠습니다.

  • J stands for JavaScript. JS는 1995 년 Netscape에 의해 도입 된 이후로 먼 길을 왔습니다. 반응 형 및 점진적 라이브러리를 사용하면 모바일 앱과 매우 유사하게 작동하는 웹 앱을 설계 할 수 있습니다.
  • A stands for APIs. 모든 기능을 직접 프로그래밍 할 필요는 없지만 엄청난 수의 작업을 위해 타사 처리에 의존 할 수 있습니다.
  • M stands for Markup. 이미 개발 된 구성 요소를 재사용하거나 유지 관리가 훨씬 쉬운 새 구성 요소를 만들 수 있습니다.

그냥 윙윙 거리지 않나요? 


어떤면에서는 그렇습니다. 원래 JAMstack으로 양식화 된 Jamstack이라는 용어는 Netlify에서 "최신 웹 프로젝트를 자동화하기 위한 올인원 플랫폼"을 홍보하는 방법으로 만들어졌습니다. 웹 구성 요소와 API가 꽤 오랫동안 존재 해 왔기 때문에 Jamstack의 기본 원칙은 새로운 것이 아닙니다.


그러나 Ajax (비동기 자바 스크립트 및 XML)라는 용어는 당시 다른 회사 (Adaptive Path)에서 만든 것과 거의 같은 방식으로 Ajax를 가능하게 한 XMLHttpRequest (XHR) API도 한동안 존재했지만 둘 다 Ajax JAMstack은 커뮤니티에서 빠르게 채택 된 합법적인 용도로 아이디어를 새롭게 개편했습니다. 과대 광고는 당연합니다. 이러한 작업 방식은 전 세계의 많은 개발자들에게 계시였습니다.


정적 사이트? 


"정적 사이트"는 "동적 웹 사이트"의 정반대입니다. 그렇다면 일반 HTML 파일로 풍부하고 동적인 상호 작용을 제공하는 방법은 무엇입니까? 글쎄, 자바 스크립트.


JavaScript는 첫 번째 브라우저 전쟁 이후 많은 발전을 이루었으며 Node.js의 출현과 React, AngularVue.js와 같은 라이브러리와 함께 범용 프로그래밍 언어로 통합되었습니다. 고급 사용자 인터페이스 (UI)를 디자인 할 수 있는 가능성은 무한합니다.


물론 자바 스크립트는 은총이 아닙니다. 아마도 데이터 분석이나 AI를 사용하지 않을 것입니다. 하지만 웹 개발의 경우 누군가 이미 마이크로 서비스를 만들었을 가능성이 있기 때문에 자바 스크립트 메서드로 사용할 수 있는 API로 할 수 없는 일은 거의 없습니다.


또한 마크 업이 있는 모든 프로세스를 재사용 가능한 구성 요소로 "캡슐화"할 수 있다면 (특정 기능이 필요할 때마다 거의 드롭 인 할 수 있음) 매번 작업 시간을 잠재적으로 절약 할 수 있습니다.


바로 자바 스크립트, API, 마크 업과 같은 J · A · M 스택입니다.



분리, 헤드리스, 마이크로 서비스, 서버리스… 죄송합니다. 


이 모든 것들은 웹 개발에서 인기 있는 주제이며 밀접하게 관련되어 있지만 완전히 동일하지는 않습니다. 이러한 용어를 많이 듣게 되므로 처음부터 몇 가지 용어를 명확히 하겠습니다.


결합 vs. 분리 vs. 헤드리스 


COUPLED는 웹 사이트의 콘텐츠가 데이터베이스가 있는 사이트 (예 : WordPress 관리자)의 백엔드에서 생성, 관리 및 저장되는 경우입니다. 그런 다음 이 콘텐츠는 백엔드에서 가져 와서 프런트 엔드 인터페이스 (예 : WordPress 템플릿)를 통해 브라우저에 표시됩니다. 어떤 의미에서 "결합 된"애플리케이션은 백엔드와 프런트 엔드가 동일한 앱의 다른 측면 인 전통적인 "풀 스택"입니다.


반대로 DECOUPLED는 백엔드와 프런트 엔드가 별도로 관리되는 경우입니다. 즉, 데이터베이스와 관리 도구는 한 서버에 있고 프런트 엔드는 다른 곳에 있습니다. 당연히 둘 다 연결되는 매체가 있어야 하는데, 보통 API입니다. 게다가 이제 백엔드가 프런트 엔드에서 효과적으로 분리 되었기 때문에 실제로 여러 위치에 여러 프런트 엔드가 있을 수 있습니다. (Shopify와 같이 동일한 엔진을 사용하는 다른 상점을 생각해보십시오.)


간단히 말해서 HEADLESS 소프트웨어에는 프런트 엔드 또는 프레젠테이션 레이어가 없습니다. 예를 들어 헤드리스 CMS는 정적 콘텐츠를 생성하여 모바일 앱, 사물 인터넷 장치, 정적 웹 사이트 등 어디로든 푸시 할 수 있는 CMS입니다. 물론 이것은 "분리 된"상황이지만 여기서는 API가 필요하지 않을 수도 있습니다. 정적 HTML 파일로 제공하기 위해 게시물을 내 보낸 WordPress 엔진을 생각해보십시오. 헤드리스입니다. 실제로 지금 바로 이런 방식으로 생성 된 페이지에 있습니다.


모놀리식 (밀 결합) vs. 마이크로 서비스 (느슨하게 결합) 


간단히 말해 MONOLITHIC은 일체형 소프트웨어로 정의 할 수 있습니다. 예를 들면 모바일 앱, 컴퓨터에 설치할 수 있는 대부분의 애플리케이션, WordPress와 같은 웹 앱이 있습니다. 이러한 앱은 여전히 ​​내부 '모듈'또는 '구성 요소'를 가질 수 있지만, 애플리케이션에서 없어서는 안될 부분이기 때문에 밀접하게 결합되어 있다고 합니다. 그렇지 않으면 애플리케이션이 작동하지 않습니다.


반면에 LOOSELY COUPLED 소프트웨어 구성 요소는 제거하거나 교체 할 수 있는 플러그인처럼 작동하며 기능은 변경되지만 응용 프로그램의 핵심은 계속 작동합니다. 이 원칙은 애플리케이션의 필수 부분이 아닌 보조 기능 (이미지 크기 조정, 로그인, 저장)을 제공하는 타사 API (종종 '마이크로 서비스'라고 함)를 통해 기능의 '아웃소싱'을 가능하게 합니다.


서버리스 vs. 기존 컴퓨팅 


물론 “서버리스”는 잘못된 이름입니다. 어떤 컴퓨팅 벤처에 속해 있든 서버가 관련 될 것입니다. 그러나 서버에 액세스하고 관리하는 방식은 근본적으로 다를 수 있습니다.


TRADITIONAL MODEL에서는 실제 물리적 서버 (때로는 베어 메탈이라고도 함) 또는 물리적 서버에 리소스가 할당 된 가상 사설 서버가 있을 수 있습니다. 리소스는 제한되어 있으며 100 % 사용 여부에 관계없이 사용하는 것처럼 비용을 지불합니다.


서버리스 모델에는 서로 연결되어 있는 많은 서버에서 제공하는 엄청난 리소스 풀이 있습니다. 필요할 때 필요한 것을 가져오고 필요에 따라 확장 (확장 및 축소) 할 수 있습니다. 실제 서버를 자신의 것으로 정확히 지정할 수는 없습니다. 리소스가 어디에서 왔는지에 관계없이 리소스가 있다는 것만 아는 것입니다.


 Traditional model

Serverless model 

 제한된 리소스가 있는 물리적 서버

 무제한 리소스 풀

 오작동이 발생하기 쉽습니다 (예 : 하드 디스크 오류)

 보다 안정적인 아키텍처 *

 제한된 확장성

 무제한 확장성

 유휴 서비스를 포함한 모든 비용 지불

 사용한 만큼 지불 (종량제)

 간단한 사용

 구현을 배워야 함


* 하드 디스크, CPU 및 메모리 칩 오류는 계속 발생합니다. 그러나 리소스가 투명하게 할당되기 때문에 하드웨어가 고장 나서 교체 될 때조차 알 수 없습니다.


Jamstack의 실제 사례 


특히 이러한 아이디어를 처음 접하는 경우에는 많은 작업이 필요했습니다. 이제 이론을 깨고 실제 Jamstack 사용을 살펴 보겠습니다.


사례 연구 1 : 10 배의 속도 향상을 위해 WordPress를 정적 사이트로 전환 


정적인 방법이 있다면 동적 WordPress (WP) 블로그를 정적인 블로그로 만드는 것보다 더 좋은 방법은 무엇일까요? 그렇게 함으로써 페이지 로드 속도와 지연 시간을 최소한 한 가지로 줄이고 보안을 강화하며 SEO를 개선 할 것입니다.


요컨대 프로세스 


  1. 정적 사이트 생성기 (SSG)를 사용하여 WP에서 정적 형식 (텍스트, 마크 다운, HTML)으로 게시물과 페이지를 만듭니다.
  2. 정적 콘텐츠를 GitHub, GitLab 또는 Bitbucket의 저장소와 동기화 합니다.
  3. 배포 파이프 라인을 자동화하여 저장소가 변경 될 때마다 변경 사항이 글로벌 CDN에 즉시 적용되도록 합니다.
  4. 자동화 된 배포를 통해 안전하고 빠른 웹 사이트를 위한 무료 호스팅을 편안하게 즐기십시오. ?

하지만 어떨까요 ... 


물론 이것은 많은 질문을 생성합니다.

  • 관리자는 어떻습니까?
  • 카테고리와 RSS 피드는 어떻습니까?
  • 지금 콘텐츠를 어떻게 관리합니까?
  • 댓글 섹션과 뉴스 레터는 어떻습니까?

이제부터는 SSG로 콘텐츠를 생성하게 되므로 WP Admin에게 작별 인사를 할 수 있습니다. 실제로 Jekyll과 같은 SSG는 블로그 구축을 위해 특별히 설계되었으며 Gatsby.js와 같은 SSG에는 이미 모든 배터리가 포함되어 있습니다.


콘텐츠 관리 (예 : 기존 게시물 수정)는 헤드리스 CMS가 구출되는 곳입니다. 의견 및 뉴스 레터의 경우 Disqus 및 Mailchimp와 같은 외부 API를 이미 사용하고 있지 않습니까?


실제로 어떻게 합니까? 


여기서는 SSG와 헤드리스 CMS에 대한 내용을 다룰 수 없지만 이 시리즈의 향후 편을 기대해주세요. WordPress 사이트 마이그레이션에 대한 단계별 가이드를 제공합니다.


사례 연구 2 : 자동화 된 파이프 라인을 통해 무료로 정적 사이트 호스팅 


"무료"는 Jamstack 커뮤니티에서 많이 들을 수 있는 것입니다. 고맙게도 신용 카드 번호를 무료로 알려 주셔야 하므로 무료가 아닙니다.


요컨대 프로세스 


이 경우 정적 사이트 (예 : 사례 연구 1에서 마이그레이션 한 블로그)를 온라인에 게시합니다.


  1. GitHub, GitLab 또는 Bitbucket 저장소를 설정합니다.
  2. Netlify, GitLab 페이지 또는 GitHub 페이지에 배포합니다.

이 시점에서 저장소의 모든 변경 사항은 문제가 발생하면 매우 우아하게 롤백 할 수 있는 새로운 배포 (웹 후크를 통해)를 자동으로 트리거 합니다.


왜 기업들이 무료로 이것을 합니까? 


HTML 파일을 이미 배포 된 CDN에 놓는 오버 헤드는 최소화됩니다. 실제 컴퓨팅과 PHP 렌더링이 없다는 것을 기억하십시오. 대역폭을 많이 차지하는 매우 인기 있는 사이트를 호스팅 하지 않는 한 기업은 호스팅을 제공하는 것을 꺼리지 않습니다. 그렇게 하는 것은 그들에게 좋은 홍보가 될 수 있습니다.


많은 공짜를 제공함으로써 회사도 여러분을 가두게 됩니다. 프리미엄 서비스가 필요할 때 (비즈니스가 성장하면 그렇게 될 것입니다) 이미 그들과 함께합니다. 이는 공정한 일입니다. 게다가 그 시점에서 이미 문제에 대한 임시 솔루션을 개발하거나 어쨌든 서비스 비용을 지불해야 했습니다.


실제로 어떻게 합니까? 


Netlify 또는 GitHub / GitLab 두 경우 모두 매우 간단하며 최소한의 노력만 필요합니다. (하지만 다음 기사에서 프로세스를 자세히 다룰 것입니다.)



Jamstack이 풀 스택 개발과 비교하는 방법 


이 새로운 접근 방식이 LAMP 또는 MEAN 스택과 어떻게 비교되는지 살펴 보겠습니다.


 LAMP/MEAN stack

 Jamstack

 사이트를 실행하는 웹 서버

 CDN에 대한 글로벌 배포

 FTP / SSH 업로드, 서버 재시작

 자동화 된 파이프 라인

 런타임에 렌더링 된 페이지

 속도를 위해 미리 렌더링 된 페이지

 모놀리식 앱 (예 : WordPress)

 API 및 마이크로 서비스 (프런트 / 백 엔드 분리됨)

 풀 스택 (프런트 및 백엔드 언어)

 단일 스택 ( "모든 곳의 JavaScript")


Jamstack으로 다른 무엇을 할 수 있습니까? 


이 시점에서 사이트 제작의 이점을 이해 하셨기를 바랍니다. 하지만 사용자 로그인, 관계형 데이터베이스 (RDBMS)없이 동적 콘텐츠를 관리 또는 저장하는 것과 같이 백엔드 처리 없이 가장 기본적인 작업을 수행하는 방법에 대해 여전히 회의적일 수 있습니다.


다음은 Jamstack으로 수행 할 수 있는 작업의 몇 가지 예입니다.


  • 정적 사이트로 서버리스 데이터베이스 구현
  • IDaaS (Identity as a Service) : 상태 비 저장 인증
  • 헤드리스 콘텐츠 관리 시스템
  • 정적 사이트에서 서버리스 기능 사용
  • 다목적 양식 관리
  • 다중 플랫폼 알림 처리
  • 헤드리스 쇼핑 카트
  • 반응형 검색

결론 


특히 IT 분야에서 상황이 진화하는 것은 불가피합니다. LAMP 스택 이전에는 MEAN 스택이었습니다. 이제 Jamstack이 되고 5 년에서 10 년 후에는 다른 것이 될 것입니다. 이러한 변화를 수용하고 우리의 것으로 만드는 것이 가장 좋습니다!


새로운 일을 하는 방법을 배우는 것은 번거로울 수 있지만 개발에 대한 흥미를 다시 불러 일으킬 수도 있습니다. 서버를 유지 관리하고 보안 문제에 대해 걱정하는 데 소요되는 시간이 줄어들 수 있습니다. 개발에 더 적은 노력이 필요하고 고객이 더 행복하다는 것을 알 수 있습니다. 그리고 결과적으로 더 경쟁력을 갖게 될 수도 있습니다 (그리고 인상을 요청할 수도 있습니다). ?


Jamstack 기초 


이 주제에 대한 더 많은 기사를 주시하십시오. 수년에 걸쳐 Jamstack을 다루었지만, 그 자체로 규율이자 관행이 되었습니다. Jamstack 전문가가 되기 위해 필요한 자습서를 제공하고 이 페이지의 여기에서 색인을 업데이트합니다. RSS 피드 또는 소셜 미디어를 통해 최신 정보를 유지할 수도 있습니다.


Jamstack 기초 


Jamstack 도구