Chris Coyier와 함께하는 스매싱 팟캐스트 에피소드 22: 서버리스란?
게시 됨: 2022-03-10오늘은 서버리스 아키텍처에 대해 이야기하고 있습니다. 이것이 의미하는 바는 무엇이며 현재 사이트를 구축할 수 있는 방법과 어떻게 다릅니까? 알아보기 위해 Chris Coyier와 이야기했습니다.
메모 표시
- Chris의 마이크로사이트 The Power of Serverless for Front-end Developers
- 트위터의 크리스
- ShopTalk 쇼 팟캐스트
주간 업데이트
- "실제 응용 프로그램에서 사용하기 위해 Redux 설정",
제리 나비 - "오감을 위한 웹사이트를 디자인할 수 있습니까?",
수잔 스카카 - "Sapper와 Strapi로 정적 블로그 만들기",
다니엘 마달리소 피리 - "React 앱의 제품 둘러보기에 대한 실용 가이드"
블레싱 크로페가로 - "스케치로 포르쉐 911을 만드는 방법"
니콜라 라자레비치
성적 증명서
Drew McLellan: 그는 10년 이상 전에 시작한 웹 사이트인 CSS-Tricks에서 알 수 있는 웹 디자이너이자 개발자이며 웹 사이트 구축을 위한 환상적인 학습 리소스로 남아 있습니다. 그는 브라우저 기반 코딩 놀이터이자 전 세계의 프론트 엔드가 자신이 만든 것을 공유하고 팔로우하는 사람들로부터 영감을 찾는 커뮤니티인 CodePen의 공동 설립자입니다. Dave Rupert와 함께 웹사이트 제작에 관한 모든 팟캐스트인 ShopTalk Show의 공동 진행자입니다. 그래서 우리는 그가 웹 개발에 대해 많이 알고 있다는 것을 알고 있지만, 그가 한때 그의 매력만으로 핫도그 먹기 대회에서 우승했다는 것을 알고 있습니까? 내 스매싱 친구, Chris Coyier를 환영하십시오. 안녕 크리스, 잘 지내?
크리스 코이어: 이봐, 난 굉장해.
Drew: 오늘은 CodePen이 아니라 CSS-Tricks에 대해 이야기하고 싶었습니다. CSS-Tricks에 대해 이야기하고 싶은 것은 아닙니다. CSS-Tricks는 모두가 알고 있는 놀라운 리소스 중 하나입니다. 웹 개발 질문에 대한 답변을 찾을 때 검색 결과. 당신의 얼굴이 떠올랐고 당신이나 당신의 게스트 기고자 중 한 명이 작성한 유용한 블로그 게시물이 있습니다.
Chris: 오, 실제로 그렇게 하곤 했습니다. 거기에는… 잘 모르겠지만, 아마도 구글이 그 이상한 소셜 네트워크를 갖고 있던 시절이었을 것입니다. 그게 뭐였지? 구글 플러스?
드류: 아, 게다가 그렇습니다.
Chris: 예, 웹사이트를 Plus 계정과 연결하는 곳입니다. 그래서 내 Plus 계정에는 아바타가 있었고 아바타는 저였기 때문에 검색 결과에 나타납니다. 그런 날들은 가버린 것 같아요. 나는 당신이 ...
드류: 그런 것 같아요, 예-
크리스: 네.
Drew: 하지만 나는 당신의 부차적인 관심사에 대해 이야기하고 싶었습니다. 이것이 바로 서버리스 아키텍처의 개념입니다.
크리스: 음 (긍정적).
Drew: 이것은 당신이 잠시 동안 더 많이 배우고 있는 것입니다. 맞나요?
크리스: 네, 네. 난 그냥 팬이야. 프론트엔드 개발의 진화에 자연스럽게 부합하는 것 같습니다. 프론트엔드 개발은 제가 최소한 어느 정도 전문 지식을 갖고 있다고 느끼는 부분입니다. 나는 나 자신이 백엔드보다 프론트엔드에서 훨씬 더… 훨씬 더 유용하다고 생각합니다. 저는… 나는 약간의 Ruby 코드를 보는 것을 두려워하지 않을 만큼 충분히 오랫동안 주위에 있었습니다. 그건 확실합니다. 하지만 저는 프론트엔드를 선호합니다. 더 공부해봤습니다. 저는 그 수준에서 더 많은 프로젝트에 참여했고, "서버에서 JavaScript 기술을 사용할 수 있습니다."라는 작은 종류의 새로운 패러다임이 나타났습니다. 흥미롭습니다. 알 잖아? 그렇게 생각합니다. 그것보다 훨씬 더 많은 것이 있지만 그것이 내가 신경을 쓰는 이유입니다. 프론트 엔드 개발자가 JavaScript를 너무 깊이 파고든 것처럼 느껴지기 때문입니다. 이제 우리는 동일한 기술 세트를 다른 곳에서도 사용할 수 있습니다. 음, 꽤 멋지군요.
Drew: 완전히 새로운 세계가 열린 것 같습니다. 반면에 당신이 프론트엔드 코더라면… 제 말은, 프론트엔드 코더라면 그렇게 해서는 안 됩니다. 당신이 프론트엔드 코더이고 백엔드 구현을 돕기 위해 동료나 친구와 함께 일하는 데 익숙하다면 갑자기 그것이 열립니다. 또한 전체 스택의 더 많은 부분을 직접 관리할 수 있습니다.
크리스: 네, 네. 그게 다야
드류: 바로 위에 있는 방에 있는 코끼리에게 말을 걸고 있습니다. 우리는 서버리스에 대해 이야기하고 있으며 분명히 이름을 짓는 것은 어렵습니다. 우리 모두 알고 있습니다. 서버리스 아키텍처는 서버가 없다는 것을 의미하지 않습니까?
Chris: 이것이 필수라고 생각합니다. 예를 들어 이것이 여러분이 처음 듣는 팟캐스트이거나 처음... "서버리스"라는 단어를 처음 12번만 듣는다면 필수입니다. 본능적인 반응을 보이며 "아, 하지만 아직 서버가 있습니다." 괜찮아요. 그것이 당신에게 지금 일어나고 있다면, 그것이 이것에서 필요한 단계라는 것을 알아두십시오. 그것은 인생의 다른 어떤 것과도 같습니다. 이해하는 단계가 있습니다. 어떤 것을 처음 들었을 때, 당신은 그것을 약간 거부해야 하고, 그리고 나서 십여 번 정도 또는 그것이 당신에게 약간의 가치가 있다는 것이 입증된 후에야, 당신은 다음 단계로 들어갈 수 있습니까? 여기에서 이해의. 하지만 그 말이 이겼습니다. 따라서 "서버리스"라는 단어에 대해 여전히 싸우고 있다면 기차가 역을 떠났다고 말하고 싶지 않습니다. 이미 성공한 단어입니다. 당신은 이번 대회에서 우승하지 못할 것입니다. 죄송합니다.
Chris: 하지만 흥미로운 것은… 저는 서버리스를 개념으로 고정시킨 것 중 하나가 AWS Lambda라고 생각합니다. 그들은 현장에서 일종의 첫 번째 유형이었습니다. 람다는 AWS에 제공하는 함수와 같습니다. 그러면 이를 마법의 하늘에 올려놓은 다음… URL이 있고, 적중하면 해당 함수를 실행하고 원하는 경우 무언가를 반환합니다. 알 잖아? 그것은 단지 HTTP 또는 무엇이든입니다. 그것이 작동하는 방식입니다. 처음 듣는다면 "왜? 난 상관없어.” 그러나 거기에는 몇 가지 분명한 사실이 있습니다. 다른 사람이 액세스할 수 없는 내 API 키를 알 수 있습니다. 처음부터 백엔드를 실행하는 이유는 클라이언트 측의 JavaScript에 있을 필요가 없는 비밀 항목을 알고 있기 때문입니다. 따라서 데이터베이스와 통신해야 하는 경우 그렇게 할 수 있습니다. API 키를 다른 곳에서 노출하지 않고도 안전하게 수행할 수 있습니다. 또는 해당 데이터가 있는 위치 또는 가져오는 방법에 대해서도…
크리스: 정말 멋지군요. 데이터베이스와 통신하고 일부 데이터를 가져와 반환하는 함수를 작성할 수 있습니다. 멋있는. 따라서 Lambda는 그 자체이지만 AWS가 작동합니다. 지역을 선택해야 합니다. 당신은 "모르겠어. 어디에 있어야 합니까, 버지니아? 오레곤? 호주를 선택해야합니까? 모르겠어요." 20, 30이 있습니다. 요즘은 몇 개나 있는지 모르겠지만 람다에도 영역이 있습니다. 내 생각에 그들은 요즘 Lambda@Edge를 가지고 있습니다. 즉, 모든 지역이 있다는 뜻입니다. 이것은 일종의 멋진 일입니다. 하지만 그들은 처음이었고 이제는 모두가 람다와 같은 것을 갖게 되었습니다. 모든 클라우드 서비스. 그들은 이 세상에서 어떤 종류의 서비스를 원합니다. 그 중 하나가 CloudFlare입니다. CloudFlare에는 작업자가 있습니다. 그들은 AWS보다 훨씬 더 많은 위치를 가지고 있지만 다른 시간에도 실행했습니다. CloudFlare 작업자 방식... Node.js를 실행할 수 있다는 점에서 람다와 비슷합니다. 자바스크립트를 실행할 수 있습니다. 다른 많은 언어도 실행할 수 있지만... 제 생각에는 이 부분에 대해 크게 생각합니다. 가장 흥미로운 언어는 JavaScript가 널리 퍼져 있기 때문입니다.
Chris: 그것은 서버라고 생각하는 CDN 수준에서만 발생하지만 CDN을 서버로 생각하지 않는 경향이 있습니다. 다른 것만큼 분명하지 않습니다. 최근에는 더 서버리스 느낌이 나기 시작했습니다. CDN은 서버입니까? 내 말은, 나는 그것이 어딘가에 컴퓨터라고 생각하지만 훨씬 덜 서버적인 것처럼 느껴집니다.
Drew: 예, CDN은 서버일 수 있지만 가장 최소한의 서버 버전입니다. 원한다면 얇은 서버와 같습니다.
크리스: 네. 확신하는.
드류: 알았어. 유감스럽게도 출처를 기억할 수 없지만 서버리스가 "Uber 또는 Lyft와 같은 차량 공유 서비스를 사용하는 것과 같다"고 설명하는 것을 들었습니다. 자동차가 없고 자동차를 소유하지 않을 수도 있지만 그렇다고 해서 자동차를 절대 사용하지 않는 것은 아닙니다.
Chris: 예, 자동차가 존재하지 않는다는 의미는 아닙니다. 음, 멋지네요.
드류: 필요할 때만 불러야 하지만, 동시에 자동차의 선불 구매 비용을 지불하고 있지는 않습니다. 유지비나 연료비를 내지 않거나-
Chris: 맞아요. 가격도 합리적이죠? 멋지네요. 좋은 비유라고 생각합니다. 그런 다음 CDN 수준에 있기 때문에 이미 발생하고 있는 HTTP 요청을 가로채기 때문에 요청하지 않습니다. 요청을 보내지 않고 다시 요청을 보냅니다. 요청하는 동안 자연스럽게 발생하므로 서버 느낌이 덜합니다. 모르겠어, 흥미롭군. 확실히 흥미롭습니다. 하지만 가격 책정 문제를 제기한 것은 큰 문제입니다. 사용한 만큼만 비용을 지불하면 됩니다. 그것도 중요합니다. 왜냐하면… 예를 들어, 당신은 평생 서버를 회전시키는 데 익숙한 백엔드 개발자이기 때문입니다. 그리고 그들은 비용을 운영합니다. “이런 종류의 메모리와 이런 종류의 CPU와 이런 종류의 사양을 갖춘 서버가 필요합니다. 그리고 이 정도의 비용이 들 것입니다.” 서버리스가 등장하여 그 가격을 크게 낮췄습니다.
Chris: 따라서 백엔드 개발자가 이 기능을 그다지 좋아하지 않고, 좋아하지도 않고, 마치 몇 년 동안 기술이 그대로 유지되는 것처럼 가격을 비교합니다. 그리고 당신은 "뭐? 이전에 지불한 금액의 1%를 지불할 수 있습니까?” 그런 거 신경 안 쓰면 안 돼요, 그렇죠? 당신이 그들이 지불해야 하는 것보다 100배 더 많은 비용을 서비스에 지불하는 이 백엔드 개발자라면 당신은 당신의 직업이 좋지 않은 것입니다. 죄송합니다. 이것은 여러 가지 방법으로 가격을 산산조각 냈습니다. 당신은 그것에 대해 걱정해야합니다. 그리고 다른 누군가가... 보안에 대해 전혀 걱정할 필요가 없지만 서버는 아닙니다. 람다나 클라우드 기능, 작업자 또는 그 밖의 모든 것이 네트워크의 매우 민감한 데이터 바로 옆에 있는 서버에 있지 않습니다. 데이터베이스 바로 옆에 있지 않습니다.
Chris: 누군가가 작업자나 람다 등으로부터 스스로를 꺼내려고 하는 코드를 작성하고 방해가 되는 다른 것들에 접근하려고 하면 얻을 수 있는 것이 없습니다. 따라서 보안도 큰 문제입니다. 다시 말하지만 이것이 서버 관리자의 임무라면 이 문제의 보안을 처리하는 것입니다. 그것을 실행하고 Lambda에서 특정 작업을 실행하면 자연스런 보안을 얻을 수 있습니다. 훌륭합니다. 그래서 훨씬 저렴합니다. 훨씬 더 안전합니다. 이는 좋은 아이디어가 될 수 있는 이러한 작은 모듈식 아키텍처를 권장합니다. 여기는 좋은 아이디어의 도미노에 이어 도미노인 것 같습니다. 주목받는 이유다. 알 잖아?
Drew: 네, 제 말은, 전통적으로 우리가 수십 년 동안 웹에서 실행해 온 서버 기반 아키텍처를 사용하면 직접 실행하는 웹 서버가 있다는 것입니다. 프론트 엔드 코드, 백엔드 코드, 데이터베이스 및 모든 것을 보유합니다. 그런 다음 이를 유지 관리하고 계속 실행하고 청구서를 지불해야 하며 사용하지 않더라도 청구서를 기록하고 있습니다. 사용자는 요청을 하고 데이터베이스에서 모든 HTML 쿼리를 작성하고 모든 것을 브라우저로 보냅니다. 그 과정이 작동합니다. 그것은 많은 것들이 구축되는 방식입니다. 아마도 웹이 구축되는 방식의 대부분일 것입니다. WordPress와 같은 것들이 작동하는 방식입니다. 이것이 정말 우리가 해결해야 할 문제입니까? 제 말은, 우리는 비용에 대해 조금 이야기했습니다. 우리가 해결해야 하고 서버리스가 우리를 도울 수 있는 다른 종류의 문제는 무엇입니까?
Chris: 예, 구식 접근 방식의 문제입니다. 예, 잘 모르겠습니다. 아마 없을 것입니다. 내 말은, 웹 전체가 전체를 바꿔야 한다고 말하는 것이 아닙니다. 하룻밤 사이에 전체를 바꿔야 합니다. 모르겠어요. 실제로는 그렇지 않을 수도 있지만, 저는 그것이 문을 열어준다고 생각합니다. 이렇게 좋은 아이디어가 나오면 웹이 작동하는 방식이 서서히 바뀌는 것 같습니다. 따라서 데이터베이스가 있을 것으로 예상하는 방식으로 구축된 CMS가 있다면 미래의 호스트가 흥미로운 방식으로 이를 활용하기 시작할 것임을 의미합니다. 여전히 전통적인 서버처럼 느껴질 수도 있지만 호스트 자체에서 서버리스 아키텍처로 작동 방식을 확장했습니다. 그래서 당신은 그것이 일어나고 있다는 사실조차 알지 못하지만 서버리스 방식으로 당신이 필요로 하는 것들을 호스팅함으로써 비용을 줄이는 방법을 찾았습니다. 개발자로서 신경 쓸 필요가 없을 수도 있지만 메타 수준에서는 그런 일이 벌어지고 있습니다. 아마도. 모르겠어요.
Chris: 그것은 또한… 데이터베이스가 여전히 존재한다는 것을 의미하지 않습니다. 구조적으로 관계형 데이터베이스를 갖는 것이 해당 데이터를 저장하는 올바른 방법이라는 것이 밝혀지면 좋습니다. 이 서버리스의 세계는 JAMstack과 동시에 성장하고 있기 때문에 언급합니다. 그리고 JAMstack은 "다음을 제외하고는 아무 것도 실행하지 않는 정적 호스트에서 웹사이트를 제공해야 합니다."라는 아키텍처입니다. 그들은 작은 CDN과 같습니다. 그들은 마치 "나는 아무것도 할 수 없습니다. 나는 PHP를 실행하지 않습니다. 나는 루비를 실행하지 않습니다. 나는 아무것도 실행하지 않습니다. 저는 정적 파일만 제공하도록 설계된 아주 작은 웹 서버에서 실행합니다.”
Chris: “그런 다음, 그 이상을 수행해야 하고 관계형 데이터베이스에서 데이터를 가져와야 한다면 서버 시간이 아닌 다른 시간에 수행하십시오. 미리 빌드 프로세스에서 수행하고 데이터베이스에서 해당 항목을 가져오고 정적 파일을 미리 빌드하면 해당 파일을 제공하거나 런타임에 수행할 수 있습니다.” 문서의 이 셸을 가져온 다음 일부 데이터를 가져와서 미리 채우도록 JavaScript 요청을 수행한다는 의미입니다. 따라서 미리 또는 나중에 수행하지만 "관계형 데이터베이스를 사용하지 마십시오"를 의미하지는 않습니다. 그냥 "문서 요청 시 서버에서 생성하지 마세요"라는 의미인데... 그건... 잘 모르겠지만 약간의 패러다임 전환입니다.
Chris: JAMstack 뿐만이 아닙니다. 우리는 또한 JavaScript 프레임워크의 시대에 살고 있습니다. 우리는 JavaScript 응용 프로그램이 부팅되는 방식이 일부 구성 요소를 탑재하고 이러한 구성 요소가 탑재됨에 따라 필요한 데이터를 요청하는 방식이 조금 더 기대되기 시작하는 시대에 살고 있습니다. 따라서 React 웹 사이트와 같은 것이 자연스럽게 적합할 수 있습니다. 본질적으로 일부 JSON API를 사용합니다. 필요한 JSON 데이터를 얻고 해당 데이터로 구성한 다음 페이지에 렌더링합니다." 이제 그것이 웹에 좋든 나쁘든 "모르겠습니다. 너무 나빠. 배가 항해했습니다. 많은 사람들이 사이트를 구축하는 방법입니다.” 클라이언트가 렌더링한 것뿐입니다. 따라서 서버리스와 최신 JavaScript는 함께 사용됩니다.
Drew: 한 아키텍처 또는 다른 아키텍처를 살펴보고 도매할 필요가 없다고 생각합니다. 중간에 인프라의 일부가 더 전통적일 수 있고 일부는 서버리스가 될 수 있는 영역이 있습니다. 제 추측으로는?
크리스: 네. 글쎄, 그들은 어쨌든 당신에게 그것을 말하려고합니다. 아키텍처의 일부를 판매하고자 하는 사람은 “지금 당장 구매할 필요는 없습니다. 조금만 해봐.” 물론 그들은 판매하는 제품에 발가락을 담그기를 원합니다. 일단 발가락을 담그면 수영장에 몸을 튀길 가능성이 훨씬 더 높기 때문입니다. 그래서, 제 생각에는... 거짓말이 아닙니다. 하지만 필연적으로, 운이 조금 덜하다는 것을 발견하더라도... 저는 제 스택이 모든 것의 약간이 되는 것을 원하지 않습니다. 나는 항상 삼키고 싶지 않은 기술적인 죽음이 있다고 생각합니다.
드류: 음(긍정적).
크리스: 하지만 가능합니다. 가장 많이 인용된 것은... 전자 상거래 요소가 있는 사이트가 있다고 가정해 보겠습니다. 즉... 대규모 전자 상거래, 즉 10,000개 제품 또는 그 이상을 가정해 보겠습니다. 이 JAMstack 아키텍처는 정적으로 다시 빌드하는 것이 항상 특히 효율적입니다. 따라서 생각은 "그렇다면 하지 마십시오."가 됩니다. 서버리스 기능을 사용하여 해당 부분이 자연스럽게 수화되도록 하고 필요한 데이터를 얻고 모든 작업을 수행합니다. 그러나 사이트의 나머지 부분은 그렇지 않습니다. 페이지가 많지 않고 데이터가 많지 않습니다. 사전 렌더링이나 무엇이든 할 수 있습니다. 그래서 둘 다 조금.
드류: 물론, 많은 사람들이 레거시 시스템을 다루고 있습니다. 2000년대에 구축된 오래된 데이터베이스로 그 위에 일종의 JSON API 레이어를 붙일 수 있습니다.
크리스: 네.
Drew: … 그리고 더 현대적이고 아마도 서버가 없는 것을 구축한 다음, 이상한 방식으로 완전히 접착하여 레거시 시스템과 여전히 상호 작용합니다.
크리스: 네. 그래도 난 그게 좋아, 그렇지? 아니… 대부분의 웹사이트는 이미 존재합니다. 우리 중 얼마나 많은 사람들이 완전히 친환경적인 웹사이트입니까? 우리 대부분은 어떤 이유로 미래로 끌어야 하는 이미 존재하는 일부 쓰레기에 대해 작업합니다. 왜냐하면 개발자는 더 빨리 작업하기를 원하거나 COBOL에서 더 이상 아무도 고용할 수 없기 때문입니다. 이다. 알 잖아?
Drew: 용어상으로는 JAMstack에 대해 이야기하고 있습니다. JAMstack은 브라우저에서 코드를 실행하고 CDN에서 제공하는 방법론입니다. 따라서 서버에 동적인 것이 없습니다. 그런 다음 서버리스에 대해 이야기할 때 다른 곳에서 서버에서 실행되는 작은 기능에 대해 이야기하고 있습니다. 맞나요? 우리가 이러한 클라우드 기능에 대해 이야기하고 있었던 것은-
Chris: 네, 제 말은, 두 가지 모두 현재 유행하는 아이디어일 뿐입니다. 그래서 하나에 대해 이야기하고 다른 하나에 대해 이야기하는 것이 쉽습니다. 그러나 반드시 함께할 필요는 없습니다. 서버리스와 아무 관련이 없는 JAMstack 사이트를 실행할 수 있습니다. 그냥 하기만 하면 되고, 사이트를 미리 구축하고 실행하기만 하면 JAMstack에 신경 쓸 필요 없이 서버리스를 사용할 수 있습니다. 사실, CodePen은 JAMstack을 전혀 하지 않습니다. 반드시 CodePen에 대해 이야기하고 싶은 것은 아니지만 Ruby on Rails 앱입니다. 전체 AWS EC2 인스턴스 및 다양한 기타 아키텍처에서 실행되어 이를 가능하게 합니다. 하지만 서버리스는 저렴하고 안전하며 좋은 작업 방식이기 때문에 가능한 한 언제든지 서버리스를 사용합니다. 따라서 JAMstack은 전혀 사용되지 않지만 모든 곳에서 서버가 없습니다.
드류: 꽤 흥미롭네요. CodePen에서 어떤 종류의 서버리스 작업을 수행하고 있습니까?
Chris: 글쎄요, 정말 많은 일들이 있습니다. 그 중 하나는, 제 생각에, 제 생각에 매우 분명하기를 바랍니다. CodePen의 요점은 브라우저에서 각 HTML, CSS 및 JavaScript를 작성하고 브라우저에서 이를 렌더링한다는 것입니다. 맞습니까? 그러나 전처리기 언어도 선택할 수 있습니다. 당신이 Sass를 좋아한다고 가정해 봅시다. CSS에서 Sass를 켜고 Sass를 작성합니다. 글쎄요, 뭔가 Sass를 처리해야 합니다. 요즘 Sass는 Dart나 뭐 이런걸로 작성되어 있습니다.
Chris: 이론적으로 클라이언트에서 그렇게 할 수 있습니다. 그러나 사전 처리를 수행하는 이러한 라이브러리는 꽤 큽니다. 나는 그것을 실행하기 위해 전체 Sass 라이브러리를 제공하고 싶지 않다고 생각합니다. 저는 하고 싶지 않습니다... 단지 그렇지 않습니다. 이는 반드시 이에 대한 올바른 아키텍처가 아닙니다. 어쩌면 우리는 오프라인 쓰레기, 야다, 야다, 웹 작업자에 대해 이야기 할 수 있습니다. 우리가 할 수 있는 건축학적 일이 백만 가지가 있습니다. 그러나 이것이 지금 작동하는 방식입니다. 람다가 있습니다. Sass를 처리합니다. 그것은 하나의 작은, 작은, 작은, 작은 작업을 가지고 있습니다.
Chris: Sass의 이 덩어리를 보내면 처리된 CSS, 사이트 맵 등의 내용을 다시 보냅니다. 그것은 하나의 작은 작업을 가지고 있으며 아마도 4센트 정도의 람다 값을 지불할 것입니다. 람다는 믿을 수 없을 정도로 저렴하고 망치질할 수 있기 때문입니다. 규모에 대해 걱정할 필요가 없습니다. 원하는 만큼만 치면 청구서가 놀라울 정도로 저렴할 것입니다. 서버리스가 너무 비싸다는 선을 넘어서기 시작하는 순간이 있습니다. 그게 뭔지 모르겠어, 난 그런 일의 달인이 아니야. 그러나 일반적으로 우리가 하는 모든 서버리스 작업은 기본적으로... 모든 것이 거의 무료로 간주됩니다. 왜냐하면 너무 저렴하기 때문입니다. 그러나 Sass를 위한 것이 있습니다. Less를 위한 것이 있습니다. Babbel을 위한 것이 있습니다. TypeScript용이 있습니다. 하나는... 모두 우리가 실행하는 개별 람다입니다. 여기에 몇 가지 코드가 있습니다. 람다에 전달하면 다시 돌아와서 우리가 하려는 모든 작업을 수행합니다. 그러나 우리는 최근에도 그 이상을 위해 그것을 사용합니다.
크리스: 여기 예가 있습니다. CodePen의 모든 펜에는 스크린샷이 있습니다. 정말 멋지죠? 그래서 사람들은 무언가를 만들고 나서 PNG나 JPEG, 또는 그 중 무언가가 필요합니다. 그래야... 그렇게 해서 트윗할 때 미리보기를 조금 볼 수 있습니다. Slack에서 공유하면 약간의 미리보기가 표시됩니다. 웹 사이트 자체에서 렌더링하는 데 사용합니다. iframe 대신 Pen이 애니메이션되지 않는 것을 감지할 수 있다면 iframe의 이미지가 훨씬 더 가볍기 때문에 이미지를 사용하지 않는 이유는 무엇입니까? 어쨌든 애니메이션이 아닙니다. 그냥 그런 성능 향상. 따라서 각 스크린샷에는 분명히 URL이 있습니다. 그리고 그 URL이 실제로 서버리스 기능이 되도록 설계했습니다. 그것은 노동자입니다. 따라서 해당 URL이 적중되면 이미 해당 스크린샷을 촬영했는지 여부를 빠르게 확인할 수 있습니다.
Chris: CloudFlare 작업자는 서버리스 기능일 뿐만 아니라 데이터 저장소도 가지고 있기 때문에 실제로 CloudFlare 작업자에 의해 활성화됩니다. 그들은 키-값 저장소라는 것을 가지고 있습니다. 그래서 그 ID를 아주 빠르게 확인할 수 있습니다. 그러면 "True or False, 당신은 그것을 가지고 있습니까, 없습니까?"가 될 것입니다. 그것이 있으면 그것을 제공합니다. 그리고 처음부터 매우 빠른 CloudFlare를 통해 서비스를 제공합니다. 그런 다음 이 모든 능력도 제공합니다. 이미지 CDN이기 때문에 "글쎄, 최적의 형식으로 제공하십시오. 이러한 차원으로 제공하십시오.” 그 치수로 이미지를 만들 필요가 없습니다. URL에 치수를 입력하기만 하면 마법처럼 해당 크기로 돌아옵니다. 정말 좋네요. 그것이 없으면 다른 서버리스 기능을 요청하여 정말 빠르게 만듭니다. 그래서 그것은 그것을 만들고 어딘가에 양동이에 넣을 것입니다 ... 이미지의 출처가 있어야하기 때문입니다. 그렇죠? 실제로 일반적으로 어딘가에 호스팅해야합니다. 그래서 우리는 그것을 S3 버킷에 아주 빨리 넣고 그것을 제공합니다.
Chris: 대기열 서버가 없고 아무 것도 없습니다. 서버리스 기능이 이러한 이미지의 생성, 저장 및 제공을 관리하는 것과 같습니다. 그리고 그 중 5000만 또는 8000만 정도가 있습니다. 많기 때문에 스케일로 꽤 잘 처리합니다. 우리는 단지 그것을 만지지도 않습니다. 그것은 단지 발생합니다. 모든 것이 매우 빠르게 진행됩니다. 아주 좋아.
Drew: 제 생각에는… 글쎄, 서버리스 기능은 상황에 대한 지식이 거의 필요하지 않은 작업에 이상적으로 적합할 것입니다. 내 말은, 이미 캐시된 항목이 있는지 여부를 확인하기 위해 키-값 쌍을 저장하는 CloudFlare의 기능에 대해 언급했습니다.
크리스: 네. 그것이 그들이 해결하려고 하는 것입니다. 그 키-값 쌍은... 제 생각에는 전통적으로 사실이었습니다. 당신이 그것에 의존할 수 없기 때문에 그들은 "사물에 있는 상태를 피하십시오"와 같습니다. 그리고 CloudFlare 작업자는 "예, 실제로 상태를 어느 정도 다룰 수 있습니다."라고 말합니다. 그것은 ...만큼 화려하지 않습니다. 잘 모르겠습니다. 그것은 키 값이므로 값의 키입니다. 중첩되고 관계가 있는 멋진 것이 아닙니다. 그래서 거기에는 약간의 한계가 있을 수 있습니다. 그러나 이것은 이것에 대한 아기의 날입니다. 나는 그 물건이 더 강력하게 진화할 것이라고 생각합니다. 그래서 당신은 상태와 같은 일을 할 수 있는 능력이 있습니다.
Drew: 그리고 때때로 한계, 상태를 유지할 수 있는 제한된 능력, 또는 상태가 전혀… 우리는 "Small Pieces Loosely Joined"의 소프트웨어 철학에 대해 이야기하고 있습니다. 그렇지 않습니까?
크리스: 음 (긍정적).
Drew: 각각의 작은 구성 요소가 한 가지 일을 하고 잘 수행하는 곳입니다. 그리고 주변 생태계의 나머지 부분에 대해 잘 모릅니다. 그리고 이것은 서버리스 기능의 이 개념에 실제로 적용되는 것 같습니다. 동의하십니까?
크리스: 네. 그것이 좋은 생각인지 아닌지 철학적인 논쟁을 할 수 있다고 생각합니다. 알 잖아? 어떤 사람들은 모노리스를 그대로 좋아한다고 생각합니다. 제 생각에는 가능하다고 생각합니다. 이것을 과도하게 사용하고 테스트하기 너무 어려운 작은 부품을 너무 많이 만드는 방법이 있습니다. "오, 내 Sass 기능이 작동하는지 궁금합니다. 글쎄요, 일단 약간의 테스트를 작성하고 그것이 맞는지 확인합시다.” 그러나 사용자에게 중요한 것은 그 중 7개의 문자열입니다. 7가지 모두를 함께 테스트하는 방법은 무엇입니까? 이야기가 좀 복잡해지는 것 같아요. 나는 그 모든 것에 대해 매우 지능적으로 말하는 방법을 모르지만, 다른 아키텍처보다 자동으로 더 나은 아키텍처인 모든 서버리스 기능을 사용한다면 반드시 그런 것은 아니라는 것을 압니다. 좋아요. 그것은 나에게 훌륭하게 설명되지만 그것이 모든 아키텍처의 궁극적인 전부인지는 모르겠습니다. 알 잖아?
Drew: 저에게는 웹과 같은 느낌이 듭니다. ... 이것이 바로 HTML이 작동하는 방식입니다, 그렇죠? HTML을 전달하면 브라우저가 이미지를 가져오고 JavaScript를 가져오고 CSS를 가져옵니다. 그것의 확장 인 것 같습니다 -
크리스: 좋네요.
드류: … 일종의 생각입니다. 그러나 우리가 웹에 대해 알고 있는 한 가지는 네트워크가 취약하기 때문에 탄력적으로 설계되었다는 것입니다.
크리스: 음 (긍정적).
Drew: 일종의 서버리스 접근 방식이 얼마나 강력합니까? 만약 어떤 것이... 그 작은 조각 중 하나가 사라지면 어떻게 될까요?
크리스: 그것은 매우 나쁠 것입니다. 알 잖아? 그것은 재앙이 될 것입니다. 사이트가 다운되면 다른 서버와 마찬가지로 사이트도 다운될 것입니다.
Drew: 이를 완화할 수 있는 방법이 있습니까? 특히 -
크리스: 모르겠어.
Drew: ... 이런 접근 방식에 적합하다고 생각하십니까?
크리스: 아마도. 내 말은, 내가 말했듯이 정말 멋진 강력한 것은 다음과 같을 수 있습니다... CodePen을 방문하고 Sass의 JavaScript 구현이 있고 우리는 당신이 상당히 빠른 네트워크에 있고 당신이 유휴 상태라는 것을 알아차렸다고 가정해 봅시다. 지금 바로. 아마도 우리는 그 JavaScript를 가져와서 서비스 워커에 던질 것입니다. 그런 다음, 람다가 실패하거나 무언가가 실패하거나 이미 설치되어 있는 것을 감지하면 람다 대신 서비스 워커를 실행하고 서비스 워커는 오프라인으로 작업할 수 있습니다. 그래서, 그것도 좋은 종류입니다. 그 흥미 롭군요. 내 말은, 그들은 같은 언어-ish입니다. 서비스 워커는 JavaScript이고 많은 클라우드 기능은 JavaScript입니다. 그래서 일부는… 가능성이 있다고 생각합니다. 하지만… 그것은 단지, 그것이 약간의 심각한 기술입니다… 수천 명의 사용자에게 그들이 무엇을 가지고 있고 어떤 버전을 가지고 있는지 반드시 알 필요는 없습니다. 에휴, 하지만 그건 내 자신의 두려움입니다. 나는 몇몇 사람들이 그런 종류의 일을 잘 했다고 확신합니다.
크리스: 사실 잘 모르겠어요. 서버리스의 복원력에 대해 내가 모르는 몇 가지 전략을 알고 있을 수 있습니다.
Drew: 서버리스 함수에서 발생할 수 있는 실패 모드, 실패 스타일이 있는 것 같습니다. 여기서 함수를 한 번 실행하면 실패하고 그 직후에 두 번째로 실행할 수 있습니다. 완전히 다른 서버. 또는 문제가 무엇이든 두 번째 요청에 해당 실행이 없을 수 있습니다. 전체 호스트가 다운되는 문제는 한 가지이지만 아마도 있을 수 있습니다... 컴퓨터에 개별적인 문제가 있습니다. 메모리가 나빠져 많은 오류가 발생하는 특정 서버가 있는데 처음 공격하면 실패할 것입니다. 두 번째로 그 문제는 주변에 뿌리를 두고 있을 수 있습니다.
Chris: 이 기술을 제공하는 경향이 있는 회사는 신뢰할 수 있어야 합니다. 하지만 그들은 또한... 이것이 그들의 자부심인 유형의 회사입니다. 이것이 사람들이 사용하는 이유는 신뢰할 수 있기 때문입니다. 사람들이 과거의 일부 AWS 중단을 지적할 수 있을 거라 확신하지만, 그런 일은 아주 드물지 않고 아주 흔하지 않은 경향이 있습니다. 자신의 쓰레기를 호스팅하는 경우 SLA 백분율 종류 수준에서 이길 수 있습니다. 알 잖아? 따라서 "회복력 있는 방식으로 구축하지 마십시오"는 아니지만 일반적으로 이러한 것들을 제공하는 유형의 회사는 매우 신뢰할 수 있습니다. 해당 기능을 망쳐서 실패할 가능성은 아키텍처가 실패하기 때문에보다 훨씬 높습니다.
Drew: 내 말은, API를 사용하는 곳이나 실패할 수 있는 모든 곳에서와 마찬가지로 그냥 던지는 것보다 그 실패 모드에 대처하고 다음에 일어날 일을 알도록 코드를 구조화하는 것입니다. 사용자에게 오류가 발생하거나 그냥 죽어가거나 하는 것입니다. 이를 인지하고 사용자에게 다시 시도하도록 요청합니다. 또는 스스로 다시 시도하거나 무언가를 시도하십시오.
Chris: 네, 저는 “오 안돼. 불합격. 중단합니다.” “몰라, 거기서 다시 해보는 게 어때, 친구?”
Drew: 제 말은, 일종의 클라우드 기능인 서버리스 기능의 테스트 및 개발과 관련하여 로컬에서 수행할 수 있는 것입니까? 클라우드에서 해야 합니까? 관리할 수 있는 방법이 있습니까?
크리스: 몇 가지 방법이 있다고 생각합니다. 스토리가 그렇게 대단한지 모르겠네요. 아직은 상대적으로 새로운 개념이라 점점 더 좋아지는 것 같아요. 하지만 내가 아는 한, 당신은 상당히 정상적인 Node 함수를 작성하고 있습니다. JavaScript를 사용하여 이 작업을 수행한다고 가정하고 특히 Lambda에서 모든 종류의 항목을 지원한다는 것을 알고 있습니다. 멋진 PHP 클라우드 함수를 작성할 수 있습니다. Ruby Cloud 함수를 작성할 수 있습니다. 그래서 저는 제가 특별히 JavaScript에 대해 이야기하고 있다는 것을 압니다. 왜냐하면 저는 이러한 것들이 대부분 JavaScript라는 느낌을 가지고 있기 때문입니다. 언어가 무엇이든 상관없이 로컬에서 명령줄로 이동하여 실행할 수 있습니다. 그 테스트 중 일부는... 다른 코드와 마찬가지로 테스트합니다. 로컬에서 함수를 호출하고 작동하는지 확인하기만 하면 됩니다.
Chris: HTTP 요청에 대해 이야기할 때는 이야기가 조금 다릅니다. 바로 테스트하려는 것입니다. 요청에 제대로 응답합니까? 그리고 물건을 제대로 돌려주나요? 모르겠어요. 네트워크가 거기에 포함될 수 있습니다. 따라서 해당 수준에서 테스트를 작성하고 싶을 수 있습니다. 괜찮아. 모르겠어요. 거기에 어떤 평범한 이야기가 있습니까? 일종의 로컬 서버나 이를 제공하는 무언가를 가동합니다. Postman을 사용합니다. 잘 모르겠습니다. 하지만... 프레임워크도 도움을 주려고 합니다. 서버리스 ".com"은 매우 혼란스럽습니다. 하지만 말 그대로 Serverless라는 회사가 있으며 배포하는 데 도움이 되는 서버리스 기능을 작성하기 위한 프레임워크를 만듭니다.
Chris: NPM이 서버리스 설치를 좋아한다면 프레임워크를 얻게 됩니다. 그리고 그것은 매우 도움이 되기 때문에 널리 매우 좋은 것으로 간주됩니다. 하지만 그들은 자신의 클라우드나 무엇이든 가지고 있지 않습니다. 이것을 작성하면 실제 람다에 도달하는 데 도움이 됩니다. 또는 여러 클라우드 공급자와 함께 작동할 수도 있습니다. 요즘은 잘 모르겠지만 존재하는 목적은 배포 스토리를 쉽게 만드는 것입니다. 뭔지 모르겠습니다... AWS는 단순성으로 유명하지 않습니다. 알 잖아? AWS를 사용하는 데 도움이 되는 도구의 세계는 모두 있으며 그 중 하나입니다.
Chris: 일종의 유료 제품이 있습니다. 정확히 무엇인지도 모르겠습니다. 제 생각에 그들이 하는 일 중 하나는... 그것들을 사용하는 목적은 테스트용이며, 서버리스 기능을 테스트하기 위한 개발 환경을 갖는 것입니다.
Drew: 네, 제 생각에는 그것이 워크플로의 꽤 큰 부분을 차지하기 때문입니다. 그렇죠? JavaScript 함수를 작성했다면 로컬에서 테스트했으며 작업을 수행할 것임을 알고 있습니다. 실제로 어떤 공급자를 선택하고 해당 서비스에 어떻게 제공합니까? 자, 내 말은, 그게 지뢰밭이지, 그렇지?
크리스: 네. I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it's live now.” That's not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don't hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.
Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that's like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you're using their little Wrangler tool thing to do that. Also, I think the way we did it was… it's also a little dangerous. The second you put it live, it's affecting all your web traffic. It's kind of a big deal. You don't want to screw up a worker. 알 잖아? You can spin up a dev worker that's at a fake subdomain, and because it's CloudFlare, you can… CloudFlare can just make a subdomain anyway. 모르겠어요. It's just kind of a nice way to do a… as you're only affecting sub-domain traffic, not your main traffic yet. But the subdomain's just a mirror of a production anyway, so that's kind of a… that's a testing story there.
Chris: It brings up an interesting thing, though, to me. It's like… imagine you have two websites. One of them is… for us it's like a Ruby on Rails app. 무엇이든. 그것은 일이다. But we don't have a CMS for that. That's just like… it's not a CMS, really. I think there's probably Ruby CMSs, but there's not any renowned ones. 알 잖아? It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you've lived in the CMS market for a long time -
Drew: Absolutely.
Chris: … so you know how this goes. Let's say you want to manage your sites in Perch or whatever, because it's a good CMS and that's the proper thing to use to build the kind of pages you want to build. But you don't want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don't know, there's any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There's an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That's fine, I guess, but now you're in a client side rendered page. It's going to be slow. It's going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It's just a bad story for SEO. It's not very resilient, because who knows what's going to happen in the network. It's not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.
Chris: You could also do it on the server side, though. Let's say you had… Ruby is capable of granting a network request too, but that's even scarier because then if something fails on the network, the whole page could die or something. It's like a nervous thing. I don't love doing that either. But we did this just recently with a worker, in that we… because the worker's JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn't. It all happened at the… on the edge, at the worker level, at the serverless level.
Chris: So it's kind of cool. I think you can imagine a fetch request on the browser probably takes, I don't know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. 그들이하다. Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It's not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it's kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there's a cool future to that.
Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I'm sort of thinking about how to architect things. Say I've got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who's going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?
Chris: Mm (affirmative). That's a fascinating question. I'd probably have an architect function or something. One function would be the one that's in charge of orchestrating the rest of them. It doesn't have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that's somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that's probably generally a good idea-
Drew: Yeah, that sounds smart. 네.
Chris: But I think that's the ultimate thing. You get a bunch of server nerds talking, they'll talk about the different approaches to that exact idea in 10 different ways.
드류: 네. No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you're using APIs where you've got secret information. You've got API keys or something that you don't want to live in the client. Because I don't know, maybe this florist API charges you $100 dollars every time flower bomb someone.
Chris: Easily.
Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That's a viable way to work?
Chris: Yeah, yeah. 그렇게 생각 해요. I mean, secrets are, I don't know, they're interesting. They're a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It's kind of like, you could just put your API key right in the serverless function, because it's just going to a server, right? You don't even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there's probably a source control along the way. It's probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can't put your API key in there, because then it's in the repo, and you don't put your API keys in repos. That's good advice. Now there's stuff. We've just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it's encrypted by the time anybody's looking at that file.
Chris: But only locally they're decrypted, so they're useful. So it's just kind of an interesting idea. I don't know if that helps in this case, but usually, cloud providers of these things have a web interface that's, “Put your API keys here, and we'll make them available at runtime of that function.” Then it kind of locks… it doesn't lock you in forever but it kind of is… it's not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.
Drew: Yeah, I think that's the way that Netlify manage it.
Chris: They all do, you know?
드류: 네. You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.
Chris: Yeah, right. But then you got to leave… I don't know, it's not that big of a deal. I'm not saying they're doing anything nefarious or anything. How do you deal with those secrets? Well, it's a hard problem. So they kind of booted it to, I don't know, “Just put them in this input field and we'll take care of it for you, don't worry about it.”
Drew: Is there anything that you've seen that stands out as an obvious case for things that you can do with serverless, that you just couldn't do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?
Chris: It's probably mostly that. I don't know that it unlocks any possibility that you just absolutely couldn't run it any other way. Yeah, I think that's a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don't know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That's the one I want to use. I think that's kind of cool. 알 잖아? That you can kind of benefit from other people's experience in that way. I think that will happen more and more.
Drew: I guess it's the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.
크리스: 네, 네. 제 생각에는... 웹사이트에 무엇이 적절하고 무엇이 적절하지 않은지 알기 위해 엄청난 기술을 필요로 하지 않는 순간이 있기 때문입니다. 예를 들어, 나는 다른 주에 이 글리치가 사용되는 약간의 튜토리얼을 했습니다. 글리치를 저장하면 그들은 당신이 만든 것에 대한 슬러그를 줍니다. 즉, "위스키, 탱고, 폭스트롯. 1,000.” 그것은 영리한 작은 것과 같습니다. 고유할 가능성은 매우 높습니다. 왜냐하면 그것들이 그것에 숫자를 추가하기도 한다고 생각하기 때문입니다. 그러나 그것들은 결국 이 재미있는 작은 것들이 됩니다. 그들은 그 모든 단어가 들어 있는 라이브러리를 오픈 소스로 제공하지만 이는 마치 수십만 단어에 불과합니다. 파일이 큽니다. 알 잖아? 메가바이트 단위의 단어 사전입니다. 개발 첫해에 "메가바이트 사전 크기의 JavaScript 파일을 제공하지 마십시오."를 배울 것입니다. 배송이 잘 안되는군요. 알 잖아? 하지만 노드는 상관하지 않습니다. 수백 개를 보낼 수 있습니다. 서버의 속도와는 무관합니다.
드류: 네.
Chris: 서버에서는 중요하지 않습니다. 그래서 저는 "음, 그럼 Node에서 할게요."라고 말할 수 있습니다. "단어가 같음에는 단어가 필요합니다."라는 문구가 있고 맨 위에는 "숫자를 무작위로 지정하도록 하십시오."라는 메모가 있습니다. 어레이에서 꺼내서 반환하십시오." 따라서 서버리스 기능은 이 오픈 소스 라이브러리를 가져오는 packages@JSON이 있는 8줄의 코드입니다. 그리고 내 프런트 엔드 코드에는 서버리스 기능에 대한 URL이 있습니다. 그 URL에 도달합니다. URL은 한 단어 또는 단어 그룹 등을 반환합니다. 이를 위한 작은 API를 빌드합니다. 그리고 지금, 저는 정말 멋지고 효율적인 것을 가지고 있습니다. 그 점이 좋았던 점은 너무 간단하다는 것입니다. 나는 그것의 보안에 대해 걱정하지 않는다. 난... 알지?
Chris: 그것은 단지... 매우 평균적이거나 초보적인 JavaScript 개발자가 그것을 해낼 수 있다고 생각합니다. 멋진 일입니다. 그것은 그들에게 이전에는 없었던 가능하게 하는 것입니다. 이전에는 "여기에 2MB의 단어 배열이 있습니다."라고 말했습니다. "아, 클라이언트에게 배송할 수 없습니다." "아, 그럼 그냥 꺼져." 당신은 이 벽에 부딪힐 수 있습니다. 다른 사람에게 그 일을 도와달라고 요청해야 합니다. 아니면 그냥 하지 않거나 더 지루한 슬러그 또는 몇 가지를 골라야 합니다...” 그것은 단지, 당신이 할 수 없기 때문에 당신에게 벽인 다른 길을 가야 합니다. 그리고 지금, 당신은 "오, 글쎄, 난 그냥..."이라고 말합니다. 내 스크립트 슬래시나 내 소스 슬래시 스크립트 폴더에 있는 대신에 내 함수 폴더에 넣겠습니다.
Chris: 당신은 스크립트를 한 폴더에서 다른 폴더로 옮기는 것을 좋아합니다. 그리고 그 대신 서버리스 기능으로 배포됩니다. 얼마나 멋진가요? 알 잖아? 거의 똑같은 기술 세트를 사용하고 있습니다. 여전히 거친 모서리가 있지만 꽤 가깝습니다.
드류: 정말 멋지네요. 당신은 이러한 아이디어에 대한 일종의 작은 마이크로 사이트를 만들었습니다. 그렇지 않습니까?
크리스: 네. 나는 경기에 조금 일찍 갔다. 저는 오늘 작업을 하고 있었습니다. 왜냐하면... 풀 리퀘스트를 받기 때문입니다. 아이디어는… 글쎄, 그것은 serverless.css-tricks.com에 있고… 그런데 CSS-Tricks에 대시가 있습니다. 그래서 CSS-Tricks의 하위 도메인이고 서버리스로도 구축했기 때문에 이것은… CSS-Tricks는 WordPress 사이트와 비슷하지만 이것은 정적 사이트 생성기 사이트입니다. 모든 콘텐츠는 오픈 소스인 GitHub 리포지토리에 있습니다. 따라서 사이트의 콘텐츠를 변경하려는 경우 설문조사 요청을 제출하면 됩니다. 시간이 지남에 따라 수백 건의 설문조사가 있었기 때문에 매우 좋습니다. 하지만 모든 원본 콘텐츠를 구축했습니다.
Drew: 매우 유용한 장소입니다. 목록이 있기 때문입니다... "맞습니다. 서버리스 기능을 시작하고 싶습니다."라고 생각하고 있다면 시도해 볼 수 있는 모든 공급자가 나열되고…
Chris: 거의 모든 것이 기술 목록입니다. 응.
Drew: 훌륭합니다. 그렇지 않으면 인터넷 검색만 하고 무엇을 찾는지 모르기 때문입니다. 예, 이러한 종류의 작업을 수행하는 데 도움이 되는 API 공급자 목록입니다.
Chris: Forms가 그 한 가지 예입니다. 왜냐하면… 선택하는 순간… 예를 들어 JAMstack을 사용하게 된다고 가정해 보겠습니다. 이것이 반드시 핵심은 아니지만 두 가지가 얼마나 밀접한지 알 수 있습니다. . 갑자기, 당신은 PHP 파일이나 그 양식을 처리할 무엇이든 가지고 있지 않습니다. JAMstack 사이트에서 양식을 작성하는 방법은 무엇입니까? 글쎄요, 방법은 얼마든지 있습니다. 모두와 그들의 자매는 분명히 당신이 그 문제를 해결하는 것을 돕고 싶어합니다. 그래서 제가 JAMstack이라는 단어의 발명가라면 자연스럽게 도움을 주려고 노력하지만 굳이 사용할 필요는 없다고 생각합니다.
Chris: 사실, 나는 이 사이트를 통합하는 데 너무 놀랐습니다. 봅시다. 6, 9, 12, 15, 18, 21, 22 서비스가 있습니다. 바로 지금 이 사이트에서 서버를 사용하지 않고 양식을 처리하는 데 도움이 되는 서비스입니다. 23번째가 되고 싶다면 환영합니다. 하지만 거기에는 약간의 경쟁이 있습니다. 그래서 이것의 이면에 있는 아이디어는 말 그대로 양식 요소처럼 HTML로 양식을 작성한다는 것입니다. 그리고 나서 양식의 action 속성은 내부적으로 아무데도 가리킬 수 없습니다. 가리킬 것이 없기 때문입니다. 처리할 수 없으므로 외부를 가리킵니다. 그것은 그들이 당신이 가리키기를 원하는 것을 가리킵니다. 그들은 양식을 처리한 다음 이메일 알림 보내기와 같이 귀하가 기대하는 일을 하는 경향이 있습니다. 또는 Slack을 보내십시오. 또는 Zapier로 보내면 Zapier가 다른 곳으로 보냅니다. 그들은 모두 약간 다른 기능 세트와 가격 책정 및 사물을 가지고 있지만 "자신의 양식을 처리하고 싶지 않습니까? 문제 없어요. 처리해 드리겠습니다.”
Drew: 네, 정말 유용한 자료입니다. 나는 모두가 그것을 확인하는 것이 좋습니다. serverless.css-tricks.com입니다. 그래서 저는 서버리스에 대한 모든 것을 배웠습니다. 최근에 무엇을 배웠습니까, 크리스?
Chris: 글쎄요, 저도 여전히 이 세상에서 많이 살고 있으며 서버리스에 대해 배우고 있습니다. 나는... 오래전에 이 온라인 롤플레잉 게임을 하곤 했었다. 아직 살아있다는 걸 최근에야 알았다. 텍스트 기반의 중세 판타지 게임입니다. 나는 AOL이 일이었을 때 그것을 했습니다. 왜냐하면 AOL은 당신이 그것을 플레이하기 위해 로그인해야 하는 이러한 게임을 원했기 때문입니다. 왜냐하면 그들은 당신이 AOL에 몇 시간을 보내고 그들이 당신에게 이 엄청난 청구서를 보낼 수 있기를 원했기 때문입니다. , 나는 그들이 왜 어느 시점에서 그렇게 잘했다고 확신합니다.
Drew: 그래서 두 번째로 청구합니다. 응.
크리스: 네. 그래서 게임은 그들에게 큰 의미가 있었습니다. 그들이 당신이 거기에 있는 다른 사람들과 게임을 하게 할 수 있다면. 그래서 이 게임은 일종의... 그곳에서 데뷔하지 않았지만 AOL로 옮겼습니다. 왜냐하면 그들이 그것에 대해 매력적인 거래를 했다고 확신하기 때문입니다. 하지만 그것은 너무... 제 말은, 그것은 단지, 아마도 더 괴상할 수 없었을 것입니다. 당신은 드워프 마법사이고 가죽 칼집에서 룬 지팡이를 얻습니다. 그리고 터미널처럼 명령을 입력합니다. 그러면 게임이 응답합니다. 나는 그 게임을 아주 오랫동안 했다. 나는 그것에 매우 빠져 있었다. 나는 그것의 공동체와 그 정신에 들어갔다. 그것은 일종의 ... 혼자 컴퓨터에 혼자 있는 것과 같았지만, 제 인생에서 그 시간을 되돌아보면서 "그때는 내 인생에서 멋진 시간이었습니다."라고 생각합니다. 나는 정말로… 나는 단지 사람과 게임, 그리고 그 모든 것을 좋아했습니다. 하지만 그 후 나는 자라서 게임을 중단했습니다. 인생은 당신에게 발생하기 때문입니다.
Chris: 나는 최근에야 알게 되었습니다. 누군가 팟캐스트에 대해 다시 팟캐스트를 하기 시작했기 때문입니다... 어떻게 알게 되었는지는 모르겠지만 방금 알게 되었습니다. 나는 "이 게임은 오늘날의 세상에 잘 살아있습니다. 농담하는 겁니까? 이 텍스트 기반의 것.” 그리고 다시 활성화하고 이전 캐릭터를 되찾아 플레이할 수 있어 더없이 기뻤습니다. 그러나 이 게임을 위해 다운로드한 클라이언트가 전혀 발전하지 않았다는 사실만 알아내면 됩니다. 그들은 끔찍합니다. 그들은 거의 당신이 Windows를 사용하고 있다고 가정합니다. 이 끔찍하게 치즈 맛이 나는 저조한 렌더링이 있습니다 ... 그리고 그것은 텍스트 기반입니다. 적어도 멋진 타이포그래피가 있다고 생각합니다. 아니요. 그래서 저는 “나도 참여할 수 있어요. 이 게임의 클라이언트를 작성할 수 있습니다. 아름다운 타이포그래피를 넣어보세요.” 그것을 현대화하면 게임의 플레이어가 그것을 높이 평가할 것이라고 생각하지만 나에게는 압도적으로 느껴졌습니다. "내가 어떻게 해?" 하지만 일부 오픈 소스 프로젝트를 찾았습니다. 그 중 하나는… 실제 터미널 창을 통해 게임을 플레이할 수 있고 일부 오픈 소스 라이브러리를 사용하여 터미널 창에서 GUI를 만드는 것과 같습니다.
드류: 정말요?
크리스: 모르겠어. 그래서 좀 멋있었어요. "만약 그들이 그것을 썼다면 게임에 연결하고 모든 것을 작동시키는 방법에 대한 코드가 있어야 합니다. 그래서 최소한 시작 코드가 있습니다.” 저는 "아마도 Flutter나 다른 것으로 할 것"이라는 앱을 따라가려고 했기 때문에 최종 제품 앱이 휴대폰에서 작동하고 "이걸 정말 현대화할 수 있어요."라고 말했습니다. 그러나 나는 압도당했다. 저는 "아, 이건 너무 커서... 할 수 없어요. 나 바빠.” 그러나 나는 같은 생각을 가진 다른 사람을 찾았고 그들은 그것에 훨씬 더 가깝기 때문에 디자인 수준에 기여할 수 있었습니다. 작업하는 것이 정말 재미있었지만 다른 사람의 아기인 프로젝트에 뛰어드는 것은 드물기 때문에 저도 많이 배웠습니다. 내가 선택했을 것보다 기술 선택.
Chris: Electron 앱입니다. 그들은 그것을 선택했습니다. 이것은 제 웹 기술이기 때문에 너무 멋진 방법이기도 합니다. 그래서 저는 너무 이상한 것을 배우지 않고 있으며 크로스 플랫폼입니다. 훌륭합니다. 그래서 저는 Electron에 대해 많이 배웠습니다. 재미있을 것 같아요.
드류: 흥미롭네요. 작은 사이드 프로젝트와 재미로 하는 일이 결국 우리가 때때로 가장 많이 배우는 장소가 되는 것은 항상 놀랍습니다. 그리고 일상 업무에 다시 사용할 수 있는 기술을 배우십시오.
Chris: 그것이 내가 배울 수 있는 유일한 방법입니다. 저는 뭔가에 끌렸습니다... 저는 "그들은 ...이 아닙니다"라고 말했습니다. 이것은 Mithril이라는 JavaScript 라이브러리로 렌더링됩니다. 이것은... 들어본 적이 있는지 모르겠지만 이상합니다. 그것은... JSX 없이 React를 작성하는 것과 거의 같습니다. "요소를 생성"해야 하고 이 모든 작업을 수행해야 합니다. 하지만 이보다 훨씬 더 나은 벤치마크를 제공해야 합니다... 그리고 이 텍스트 기반 게임에서 텍스트는 그냥 날아가기 때문에 실제로 중요합니다. 많은 데이터 조작이 있습니다. 예를 들어… 이 텍스트 기반 게임은 브라우저 창에서 실행하기가 너무 쉬울 것이라고 생각하지만 실제로는 그렇지 않습니다. 데이터 조작이 너무 많이 일어나기 때문에 여러분은 정말로… 렌더링 속도에 대해 양심적이어야 합니다. 알 잖아?
드류: 흥미롭네요-
크리스: 꽤 멋지군.
드류: 네. 청취자 여러분, Chris의 소식을 더 듣고 싶으시다면 Twitter에서 @chriscoyier를 찾아보실 수 있습니다. 물론 CSS-Tricks는 css-tricks.com에서, CodePen은 codepen.io에서 찾을 수 있습니다. 그러나 무엇보다도 Shoptalkshow.com에서 ShopTalk Show 팟캐스트를 아직 구독하지 않았다면 구독하는 것이 좋습니다. 오늘 함께해주셔서 감사합니다, 크리스. 이별의 말이 있나요?
크리스: Smashingpodcast.com. 그것이 실제 URL이길 바랍니다.