Anthony Campolo와 함께하는 스매싱 팟캐스트 에피소드 25: RedwoodJS란?

우리는 RedwoodJS에 대해 이야기하고 있습니다. 전체 스택 Jamstack 프레임워크가 된다는 것은 정확히 무엇을 의미합니까? 커뮤니티 챔피언인 Anthony Campolo와 이야기를 나누었습니다.

메모 표시

• 레드우드JS
• 트위터의 앤서니
• Anthony의 기사 시리즈 A First Look at RedwoodJS

주간 업데이트

• "프로그래밍 방식으로 Lighthouse 실행 소개"
  저자 케이티 보우먼
• "GreenSock으로 React 컴포넌트 애니메이션하기"
  블레싱 크로페가 작성
• "주의를 끌기 위한 디자인"
  빅터 요코가 쓴
• "Gatsby 웹사이트에서 고급 GraphQL 사용"
  저자 알림 이시아카
• "Next.js의 스타일링 방법 비교"
  글 Adebiyi Adedotun

성적 증명서

Drew McLellan: 그는 Lambda School 학생으로 전체 스택 웹 개발을 공부하고 있으며 RedwoodJS에 기고하고 있습니다. 커뮤니티 챔피언인 그는 최근 프레임워크가 도입한 다양한 개념과 함께 Redwood의 기원과 동기를 설명하는 데 도움이 되는 A First Look at RedwoodJS라는 12부 기사 시리즈를 작성했습니다. 그래서 우리는 그가 RedwoodJS의 전문가라는 것을 알고 있지만 그가 개를 본 적이 없다는 것을 알고 계셨습니까? 내 스매싱 친구, Anthony Campolo를 환영하십시오.

드류: 안녕, 앤서니. 잘 지내고 있나요?

Anthony Campolo: 안녕하세요. 나는 스매싱입니다. 저를 가져 주셔서 정말 감사합니다.

Drew: 저는 오늘 여러분과 이야기를 나누고 싶었습니다. RedwoodJS에 대한 소개를 보면 분명히 알 수 있습니다. 이전에 RedwoodJS에 대해 들어본 적이 없는 사람들을 위해 높은 수준에서 그것이 무엇입니까?

Anthony: 사람들이 어디에서 왔는지에 따라 설명할 수 있는 몇 가지 방법이 있다고 생각합니다. 그러나 정식 정의는 Jamstack을 위한 풀 스택 서버리스 프레임워크라는 것입니다. 그래서 풀스택 웹 개발과 서버리스 AWS Lambda 유형의 물건과 요즘 대세인 Jamstack을 결합합니다.

Drew: 그래서 Jamstack 개발 생태계에 대한 많은 아이디어를 한데 모으려는 전체 스택 프레임워크입니까? 맞나요?

Anthony: 예, Jamstack 애플리케이션의 한계를 뛰어넘고 있습니다. 따라서 이를 전체 스택, Jamstack이라고 하면 프론트 엔드를 넘어 어떻게 하면 동일한 종류의 배포 패러다임을 가질 수 있는지에 대한 것입니다. 전체 코드가 배포되었습니다. 우리는 그것을 어떻게 우리의 백엔드와 함께 얻고 모든 것을 연결합니까?

Drew: 자, 우리가 그것에 대해 너무 깊이 파고들기 전에, 그것이 꽤 노련한 팀에서 나왔다는 말을 듣는 것이 매우 흥미롭다고 생각합니다. 그렇지 않나요? 레드우드 뒤에 있는 사람들은 봄철 닭이 아닙니다. 그들이 늙었다고 말할 수는 없지만 웹 개발 측면에서 블록 주위에 있지 않습니까?

Anthony: 그들은 노련하다. 예, 저는 실제로 프레임워크의 역사와 이를 가능하게 한 아이디어에 대해 글을 쓰는 데 상당한 시간을 투자했습니다. Tom Preston-Werner는 제작자이며 따라서 그는 Jekyll의 제작자로도 알려져 있습니다. 정말 영향력 있는 정적 사이트 생성기입니다. 그는 또한 구성 파일 언어인 TOML을 수행했습니다. 그리고 그는 원래 GitHub의 CEO였습니다. 따라서 Jekyll 및 GitHub 페이지에 대한 그의 작업과 그런 종류의 작업은 실제로 우리가 현재 Jamstack이라고 생각하는 것으로 이어졌습니다. 많은 사람들이 “오, Jamstack의 신제품이군요. 그들은 이것을 영원히 해왔습니다.” 이것이 우리가 이 오래된 아이디어의 확장, 정적 사이트 생성, 그러나 GraphQL 및 서버리스, 그리고 글루 코드와 API를 사용하여 앱을 작동시키는 방법에 대한 아이디어에 대해 이야기한 방법입니다.

Drew: 그렇다면, 이것은 분명히 그 커뮤니티에 깊이 뿌리내리고 있는 사람들에게서 온 것입니까? 내 말은, GitHub의 CEO, 당신은 정말로 오픈 소스 커뮤니티의 종류에 더 깊이 관여하지 않습니다. 따라서 Redwood는 전체 스택 프레임워크이며 프론트 엔드와 백 엔드에서 Redwood 코드가 실행되고 있음을 의미합니다. 맞나요?

Anthony: 네, 제가 Redwood 프로젝트를 보여줄 때 사람들에게 가장 먼저 설명하고 싶은 것은 그것이 모노레포라는 것입니다. 따라서 프론트 엔드와 백엔드가 동일한 리포지토리에 있고 각각은 자체 폴더에 있습니다. 프런트 엔드인 웹 폴더가 있으며 Create React 앱에서 얻을 수 있는 것과 상당히 유사합니다. 그런 다음 백엔드인 API 폴더가 있으며 여기에서 모든 기능이 Netlify를 통해 AWS Lambda에 배포되는 하나의 큰 GraphQL 핸들러에 기본적으로 삽입됩니다.

Drew: 좋습니다. 앞에서 언급했듯이 React를 기반으로 합니다. 그 React에 Redwood 코드가 더해진 것입니까, 아니면 그냥 단순한 React입니까? 거기에 균형은 무엇입니까?

Anthony: 그것은 많은 일입니다. 많은 상태 관리 라이브러리를 가져오지 않고 실제로 라우터를 가져오지도 않는다는 점에서 확실히 React입니다. 그들은 자신이 작성한 라우터를 가지고 있으며 GraphQL을 많이 사용합니다. 따라서 사람들이 React, GraphQL 및 친구들에 대해 이야기할 때 여기서 일어나는 일 중 일부는 React가 GraphQL과 대화할 수 있도록 많은 기본 통합을 제공한다는 것입니다. 이제 React를 사용하는 방법에 대해 많은 규칙이 있기 때문에 데이터 가져오기는 여전히 큰 번거로움입니다.

Drew: 따라서 React와 잘 작동하는 여러 도구로 구성된 React가 이 특정 스타일의 작업을 수행할 수 있는 기능적인 생태계를 제공합니다. 그것이 정당한 설명입니까?

Anthony: 예, 아니요, 예, 좋은 표현입니다. Tom이 말한 방식은 현존하는 최고의 솔루션과 우리가 사용할 수 있는 정말 정교한 도구와 기술이 있지만 시작 비용이 너무 많이 들고 배워야 하기 때문에 실제로 활용하기가 정말 어렵다는 것입니다. , 통합하는 방법을 알아내야 합니다. 그래서 그들은 "We do your webpack config for you"라는 태그라인을 붙였습니다.

Drew: 많은 사람들이 클라이언트 측 JavaScript 앱과 웹 팩 구성, 다른 모든 구성, 빌드 프로세스, 단계를 구축합니다. 모든 것을 연결하고 작동시키는 것은 꽤 지뢰밭이 될 수 있습니다. 그렇지 않습니까? 그리고 "Hello, World!"에 도달하려면 아직 멀었습니다. Redwood에서 사전 구성된 모든 것을 제공하고 있습니까?

Anthony: 네, 구성 유형 아이디어에 대한 관례입니다. 왜냐하면... Tom은 Ruby on Rails와 다른 핵심 기여자 중 한 명인 Rob과 함께 GitHub를 구축한 것처럼 영원히 Rails 개발자였습니다. 그들은 Rails의 관점에서 철학적으로 일치하는 많은 아이디어를 가지고 있지만 구성 아이디어, 전체 스택 프레임워크 아이디어보다 이러한 관습을 취하고 현재 우리가 가진 모든 현대 기술로 구현하기를 원합니다.

Drew: 그래서 Redwood가 라우터나 라우터를 제공한다고 말씀하셨는데요. 우리가 연못의 이쪽에서 말했듯이 기본 구성 요소와 React의 그런 종류의 것들이 함께 제공됩니까, 아니면 그냥 그런가요? 모든 것을 스스로 구현하려면?

Anthony: 네, 라우터는 매우 정교합니다. React 라우터에서 얻을 수 있는 대부분의 작업을 수행합니다. 구현 방법에 대한 아이디어가 약간 다릅니다. Next에도 자체 라우터가 있기 때문입니다. 단일 페이지 앱 라우팅이 작동하도록 하고 싶습니다. Suspense 때문에 비동기 항목이 어디에 들어갈 것인지에 대해 이런 종류의 질문이 많이 있습니다. 우리는 Redwood와 함께 세포에 대한 아이디어를 가지고 있으며 이것이 실제로 데이터를 가져오는 것입니다.

드류: 그럼, 조금 더 들어가 볼까요? 레드우드의 관점에서 세포란 무엇입니까?

Anthony: 네, 셀은 GraphQL 쿼리를 작성하는 기본 방법입니다. 그런 다음 기본적으로 데이터를 다시 가져오는지, 오류가 다시 나타나는지, 로드 상태에 있는지 여부, 아니면... 상태가 하나 더 있습니다. 잊어버렸습니다. 하지만 예, 기본적으로 데이터를 가져오는지 여부에 따라 다른 상태를 제공합니다. 그것은 커버 아래 Apollo와 함께 설정됩니다. 따라서 Redwood를 사용하는 경우 Apollo를 GraphQL 클라이언트로 사용하고 있지만 그것에 대해 생각할 필요가 없습니다. Apollo를 작성하거나 그것에 대해 생각할 필요가 없습니다. 모든 것이 내장되어 있습니다. GraphQL 쿼리를 작성할 수 있습니다. 사람들이 GraphQL을 원하는 이유는 프론트 엔드 개발자가 이 간단한 쿼리 언어였기 때문입니다. 사용할 수있다. 하지만 그 다음에는 GraphQL 서버를 설정하는 방법을 알아야 했고, 이 모든 다른 것들을 파악해야 했으며, 이 모든 것을 연결하는 방법을 알아야 했습니다. 따라서 모든 GraphQL 통합을 수행하므로 GraphQL을 작성할 수 있으며 GraphQL을 구현하는 방법에 대해 생각할 필요가 없습니다.

Drew: 그래서, 프레임워크의 고전적인 작업 중 하나는 스스로 작성할 수 있는 모든 상용구 코드를 가져와서 구현하고, 그 상용구를 볼 필요가 없도록 배후에서 방법을 정리하는 것입니다. 다시 한 번, 상황에 고유한 코드를 작성할 수 있습니다. 세포에 무슨 일이 일어나고 있는 것 같습니까? 여기에 혁명적인 것은 없습니다. React 구성 요소를 설정하여 이 모든 다른 상태를 가질 수 있고 Apollo에 연결할 수 있고 이 모든 작업을 직접 수행할 수 있지만 실제로는 꽤 많은 작업이 필요하고 일반적인 패턴입니다. 그래서 Redwood는 생각할 필요 없이 바로 사용할 수 있는 훌륭하고 재사용 가능한 패턴으로 정리했습니다. 좋은 설명인가요?

Anthony: 예, 그들은 이름을 생각해 냈지만 이것이 자주 본 관행이었고 많은 사람들이 직접 코딩하는 것을 보았고 데이터 가져오기를 수행하는 선언적 방법을 원한다는 것을 확실히 인정했습니다. 그래서 이 설정이 있는 이유는 다른 상태를 가질 수 있고 if/then 논리를 수행하여 파악하기 위해 수행할 필요가 없기 때문입니다. 이 경우 이 작업을 수행해야 합니다. 따라서 데이터를 로드할 때 데이터가 있을 수 있는 모든 다른 상태를 선언하는 단일 방법을 사용하는 것입니다.

Drew: React의 특성 중 하나입니다. React가 프로젝트에 대한 아키텍처를 시도하지 않고 제공하지 않는다는 것입니다. 이를 통해 구성할 방법을 결정할 수 있습니다. 그것은 물론 장단점이 있습니다. 그러나 Redwood가 해당 구조의 일부를 사용자에게 부과하여 사용자가 그것에 대해 생각할 필요 없이 배관을 설치하고 React가 중단한 부분을 선택할 수 있도록 하는 것 같습니다. 그런 구조.

Anthony: 네, 그리고 우리가 이 문제에 대한 이 솔루션에 대해 여러 가지 다른 시도를 했다는 것은 정말 흥미로운 일이라고 생각합니다. 왜냐하면 당신은 그것을 영원히 말해 온 사람들이 있기 때문입니다. JavaScript 또는 React용 Rails?” Michael Chan과 Adam Wathan 사이의 훌륭한 Full Stack Radio 인터뷰에서 React is Not Rails 경쟁자가 있습니다. 이것은 다른 프레임워크 중 하나입니다.

Anthony: 다른 것들은 상당한 화제를 모은 BlitzJS이고, Bison은 일종의 새로운 떠오르는 것입니다. 그들은 모두 비슷한 스택을 가지고 있지만 다른 조각을 사용합니다. Apollo 대신 React 쿼리를 사용하거나 Tailwind 대신 Chakra를 사용하게 됩니다. 이 모든 조각을 자신의 스택에 모으는 사람들은 이 모든 스택이 일종의 일종의 싸움을 하고 있습니다. 모두 매우 우호적인 경쟁입니다. 사실, 제가 정말 감사하게 생각하는 한 가지는 실제로 우리 모두가 프레임워크 간에도 협력한다는 것입니다. 거기에는 적의가 없습니다.

Drew: 그래서 우리는 Apollo와 GraphQL을 언급했습니다. Redwood는 GraphQL을 프레임워크의 핵심 부분 중 하나로 상당히 많이 사용하고 있지 않습니까? 우리는 전체 팟캐스트 에피소드를 GraphQL에만 할애할 수 있지만, 익숙하지 않은 사람들을 위해 GraphQL이 여기서 어떤 부분을 하고 있는지, 이 맥락에서 어떤 문제를 해결하고 있습니까?

Anthony: 네, 좋은 질문입니다. Redwood를 잘 시작하기 위해 알아야 할 사항을 사람들에게 말할 때 Create React 앱을 만들고 Netlify 또는 Vercel, 좋은 시작이 될 것입니다. 그런 다음 GraphQL은 매우 중심적이기 때문에 최소한 약간은 알고 있어야 합니다. 따라서 GraphQL은 프론트엔드가 백엔드와 통신하는 방식입니다. 그들은 그것이 API를 위한 쿼리 언어라고 말하는데, 이는 RESTful API 메소드의 대안을 의미하며, RESTful 작업을 수행하는 대신 사용자가 다시 수신하려는 계층적 데이터 구조를 정확히 지정하는 쿼리를 보내고 있다는 것입니다. 데이터베이스. 따라서 GraphQL 서버가 두 부분과 통신하도록 하려면 시작 시간이 조금 더 필요합니다. 그런 다음 일단 거기에 있으면 프런트 엔드 개발자는 훨씬 더 유연한 방식으로 데이터를 가져올 수 있습니다. 백엔드 직원이 계속 만들어야 하는 이러한 다양한 API 엔드포인트가 모두 필요한 것은 아닙니다.

Drew: 따라서 프론트 엔드에서 요구 사항에 변경 사항이 있는 경우 GraphQL 쿼리를 조정할 수 있으며 해당 변경을 위해 백엔드에서 작업하는 누군가의 도움이 필요하지 않습니까?

Anthony: 내 말은, 진정한 꿈은 모바일 클라이언트에 던질 수 있다는 것입니다. 궁극적으로 유연성이 향상되어 여러 클라이언트가 모두 하나의 API와 대화하게 할 수 있다는 것입니다. GraphQL API는 모든 로직이 중앙 집중화되는 진실의 소스가 됩니다. 그런 다음, 이 모든 다른 보기 레이어를 맨 위에 만들 수 있습니다.

Drew: 그래서 GraphQL이 있어 일종의 백엔드를 쿼리할 수 있는 기능을 제공합니다. Redwood에서 백엔드란 무엇입니까?

앤서니: 네. 백엔드를 만드는 몇 가지 다른 방법이 있습니다. 튜토리얼을 통해 바로 사용할 수 있는 방법이 있습니다. Heroku에 배포된 Postgres 데이터베이스를 사용하는 것입니다. 매우 쉽고 간단합니다. 그러면 Redwood 앱이 Prisma와 통신합니다. Prisma에 대해 잘 아시는지 모르겠지만 O/RM과 같습니다. 그들은 구체적으로 O/RM이 아니라 쿼리 빌더라고 말하는데, 이것은 조금 더 낮은 수준입니다. 그러나 사람들에게 설명하기 위해 Prisma는 데이터베이스와 대화할 수 있게 해주는 것입니다. 마이그레이션을 수행하고 테이블을 설정합니다. 모든 SQL 작업을 수행하므로 SQL을 작성할 필요가 없습니다. 나에게 그것은 O/RM처럼 들린다. Redwood를 사용하기 위해 반드시 Prisma를 사용할 필요는 없습니다.

Anthony: 저는 실제로 FaunaDB를 대신 사용하는 개념 증명 앱을 만들었습니다. FaunaDB에는 자체 GraphQL API가 있으므로 GraphQL API를 Fauna에 직접 보낸 다음 데이터베이스 변형을 수행할 수 있습니다. Prisma CLI의 많은 기능을 잃게 되지만 Prisma는 실제로 관계형 데이터베이스와 함께 매우 쉽게 작업할 수 있는 편리한 요소입니다. 하지만 실제로, 생각할 수 있는 모든 것, Redwood와 연결하는 방법을 알아낼 수 있다는 것은 GraphQL을 기반으로 구축되었으며 요점은 이러한 모든 다른 부분과 대화할 수 있다는 것입니다.

Drew: Prisma는 본질적으로 Prisma가 지원하는 것으로 추정되는 사용 중인 데이터 저장소와 코드 사이의 일종의 추상화 계층입니다. 그게… 아니면 그보다 더 지능적인 일을 하고 있습니까?

Anthony: 예, 스키마를 작성하여 schema.Prisma 파일을 생성합니다. 그러면 모델 포스트가 있을 것이고 id와 정수 및 자동 증분을 가질 것입니다. 예를 들어 날짜, 시간에 생성된 제목 문자열, 본문 문자열과 같은 . 따라서 기본적으로 유형을 사용하여 데이터베이스에 원하는 것을 만들고 데이터베이스 작업을 수행하므로 데이터베이스와 상호 작용할 필요가 없습니다.

Drew: 그래서 Prisma를 사용하여 어떤 종류의 데이터베이스 또는 어떤 종류의 데이터 저장소에 대해 이야기하고 있는지 정의합니다. 그런 다음 거기에서 해당 용어를 사용하기 위해 다른 mvc 모델을 배치합니다. 그러면 애플리케이션이 데이터 저장소와 통신할 때 일종의 Prisma 클라이언트 인스턴스를 사용하는 것과 같죠? 그게 무슨 일이야?

앤서니: 네. 네, 바로 그것입니다. 따라서 백엔드의 API 폴더에는 db.js가 있는 lib 폴더가 있고 기본적으로 Prisma 클라이언트가 설정되어 있습니다. 상자에서 꺼낸 것은 이것이 전부입니다. 말씀하신 것처럼 Prisma는 다른 데이터베이스와 함께 작동할 수 있습니다. 개발용 SQLite와 프로덕션용 Postgres 간에 전환할 수 있습니다. 지금은 대부분 관계형이지만 로드맵에는 Mongo 및 Fauna와 같은 항목이 있습니다.

Drew: 따라서 로컬 개발 환경에서 SQLite를 설정하고 사용하여 작업을 시작하고 실행할 수 있고 그런 다음 MySQL과 같은 것으로 프로덕션에 들어갈 수 있다면 매우 유용합니다.

Anthony: 이것이 바로 튜토리얼이 설정되는 방식이며, 이것이 바로 워크플로를 보여줍니다.

Drew: 프레임워크에 대한 매우 현대적인 접근 방식을 보고 MySQL과 같은 좀 더 전통적인 데이터베이스로 대체하는 것을 보는 것은 매우 흥미롭습니다. 나는 MySQL에 매우 익숙하다. 나는 안정성 때문에 그것을 사랑하고 데이터를 저장하는 관계형 방식을 좋아합니다. 많은 일에 효과가 좋은 것 같아요. 새로운 유형의 데이터 저장소와 관련하여 목욕물이었던 아기가 버려지는 것을 종종 보게 되므로 Redwood가 이러한 좋은 오래된 관계형 데이터베이스를 기본적으로 지원하는 것을 보는 것은 매우 흥미로울 것입니다.

Anthony: 예, 아니요, 정말 좋은 지적입니다. Redwood가 함께 결합한 모든 새로운 제품에 대해 실제로 오래되고 시도되고 진정한 방법이 실제로 최고라고 말하는 몇 가지 사항이 있기 때문입니다. 따라서 그들은 관계형 데이터베이스에서 정말 큰 역할을 합니다. 이것은 Rails를 사용하고 관계형 백엔드를 보유한 Tom의 경험에서 비롯됩니다. Active Record는 Prisma가 근사화하려는 O/RM 레이어였습니다.

Drew: 여기 Redwood와 서버리스 아키텍처에 대해 이야기하고 있고 Chris Coyier와 2~3회에 걸쳐 이야기를 나눈 것 같습니다. API와 클라우드 기능을 사용하는 서버리스에 관한 모든 것입니다. 따라서 한 걸음 물러서서 Ruby on Rails나 PHP 세계에서 Laravel과 같은 것을 언급한 것처럼 서버 기반 프레임워크의 관점에서 생각하면 됩니다. React 프론트 엔드를 사용하더라도 API 요청은 Rails 코드 또는 Laravel 코드와 함께 사용자 코드 및 구성인 코드를 실행합니다. 레드우드도 마찬가지인가요? 실행되는 실제 Redwood 서버 코드가 있습니까? 아니면 사용자가 직접 구현할 수 있도록 하는 추가 도구와 구조 및 접착제입니까?

Anthony: 예, 백엔드에는 특별히 SDL을 가져오는 방법인 파일이 있습니다. 따라서 스키마 정의 언어가 있고 서비스라고 하는 것이 있습니다. 백엔드. 그런 다음 이 모든 것이 단일 Lambda 함수에 배포되는 GraphQL 핸들러로 함께 연결됩니다. 따라서 특히 Lambda에 최적화되어 있습니다. 실제로 최근에 누군가가 서버리스 프레임워크로 작업을 수행하도록 했으며 일부 사람들은 Azure 및 Google Cloud에서 작업하고 있습니다. Google Cloud 기능이 아니라 그 위에 구축된 기능입니다. 하지만 예, 이제 기본적으로 AWS Lambda에서 GraphQL 함수로 백엔드를 배포하는 데 최적화되었습니다. 이것은 내가 이해할 수 없는 코드에서 일어나는 모든 마법 같은 일이지만, 그것은 높은 수준의 설명입니다.

Drew: 그래서, 여러분이 작성한 모든 코드를 가져와 클라우드에서 실행할 수 있는 일종의 마법의 코드 공으로 모아서 AWS에 올려놓는 배포 도구가 있습니다. 아직도 그 과정을 스스로 관리해야 합니까?

Anthony: 네, 튜토리얼을 따라하면 Netlify를 통해 모두 완료됩니다. 어떤 종류의 서버리스 기능도 직접 사용하지 않아도 됩니다. 백엔드를 함께 연결하여 AWS Lambda에 밀어넣는 작업이 모두 처리되므로 해당 코드를 건드릴 필요가 없습니다. 이는 모두 구성에 대한 규칙에 따라 즉시 생성되므로 서버리스로 만드는 방법에 대해 너무 많이 생각할 필요가 없습니다. 기본적으로 서버리스입니다. 머리를 감는다는 것은 정말 어려운 일입니다. 내 머리를 감싸는 데 시간이 걸렸습니다.

Drew: 네, 중요한 포인트이기 때문에 여기에서 추적하고 있는 몇 가지 다른 영역이 실제로 있기 때문이 아닙니다. 세 가지 다른 영역이 있다고 생각합니다. 브라우저에서 실행되는 프론트 엔드 React 앱이 있고 클라우드 기능으로 실행되는 GraphQL 기반 API가 있으며 쿼리에 응답하지만 데이터 저장소와 상호 작용합니다. 프리즈마를 사용합니다. 그리고 그 데이터 저장소는 Netlify에서 MySQL 서버를 실행할 수 없기 때문에 이 안에 무엇이 있고 어디에 있습니까?

Anthony: 예, Heroku가 등장하는 곳입니다. 따라서 튜토리얼의 마지막 부분에서 Netlify에 프론트 엔드를 배포한 다음 Heroku Postgres에 백엔드를 배포하고 Heroku에서 구성 변수를 가져와 연결합니다. Netlify에. Netlify 프론트 엔드가 Postgres 백엔드와 통신하도록 하는 것은 정말 간단합니다. 그들은 누구나 쉽게 성공할 수 있는 방법을 원했지만 여전히 안정적이고 전투 테스트를 거친 기술을 보유하고 있습니다. 결국 지침을 따르는 것만으로도 상자에서 얻을 수 있는 것은 정말 놀랍습니다.

Drew: Jamstack 매니아는 데이터 저장소를 API로 제공하는 FaunaDB, AWS에 DynamoDB, Google에 Cloud SQL 등의 서비스에 익숙할 것입니다. Redwood가 통합을 검토하고 있다고 언급했습니까? 아니면 Prisma가 이러한 종류의 서비스와의 통합을 고려 중인 구성 요소인 것 같습니까?

Anthony: 네, 좋은 질문입니다. 이것은 제가 실제로 Prisma의 Ryan Chenkie와 일종의 도움에 대해 이야기하고 있는 것입니다. Prisma와 반드시 작동하지 않는 것에 대한 Redwood의 데이터베이스 이야기는 무엇입니까? 내가 Fauna에서 했던 것처럼 Redwood에서 직접 작업하도록 하는 방법을 찾는 것이 더 나을까요? 아니면 Prisma용 드라이버를 구현하는 것이 더 합리적일까요? 따라서 접근하는 방법이 다릅니다. 모두가 사용하기를 원하는 백만 개의 다른 데이터베이스가 분명히 있으므로 데이터 저장소를 가져오려는 동기가 중요합니다. 거기에 많은 커뮤니티 기부가 있습니다.

Drew: Prisma는 모델을 이해하고 쿼리하는 방법을 알고 있기 때문에 데이터베이스 설정에 도움이 되는 일종의 마이그레이션이나 이와 유사한 것을 생성할 수 있습니까?

Anthony: Prisma를 꺼내서 데이터를 가져와야 할 때 잃어버리는 것은 바로 모든 마이그레이션 기능을 잃는다는 것입니다. 많은 작업을 수행하는 정말 고급 CLI가 있으므로 전체 Redwood 자습서를 살펴보고 Prisma 명령을 입력할 수 있으며 무엇을 하는지 알 필요가 없습니다. 그냥 작동합니다. 그것은 당신이 옳고 그른지 확인하고 싶은 모든 종류의 데이터베이스 유형 작업을 수행하기 위한 정말 훌륭한 도구입니다.

Drew: 프레임워크에 대해 정말 좋은 도구를 사용하는 것은 상당히 현대적인 추세인 것 같습니다. 그렇지 않나요? 단순히 "이 프레임워크가 할 수 있는 모든 작업은 다음과 같습니다. 하지만 여기에 모든 작업을 수행할 몇 가지 CLI 도구가 있습니다." Redwood에는 CLI 생성기와 같은 도구를 사용하여 신속하게 시작하고 실행할 수 있습니까?

Anthony: 이것은 아마도 Redwood에서 얻을 수 있는 가장 큰 핵심 기능일 것입니다. 매우 정교한 발전기 세트를 얻을 수 있다는 것입니다. DHH가 제공한 원래의 Ruby on Rails 데모를 본 사람이라면 누구나 15분 만에 블로그를 만들고 Rails로 모든 작업을 수행하고 사람들은 "와, 이거 굉장합니다."라고 말합니다. 이것이 바로 Redwood가 진행하는 효과입니다. 그들은 당신이 페이지를 생성할 수 있고, 레이아웃을 생성할 수 있고, 내가 말한 셀을 생성할 수 있고, 전체를 생성할 스캐폴드 명령을 수행할 수 있도록 모든 것을 정말 빠르게 회전시킬 수 있기를 원합니다. CRUD 인터페이스. 블로그 시리즈의 4부 전체 섹션이 있습니다. 스캐폴드가 제공하는 모든 코드를 설명합니다. 그것은 당신에게 많은 코드를 제공합니다. 오프 제너레이터가 있으며, 귀하를 위해 순풍을 구성하는 Tailwind 제너레이터도 있습니다.

드류: 놀랍네요. DHH의 Rails 데모를 본 기억이 있습니다. 제 말은, 아마도 15년 전 그가 처음으로 그 비계를 만들고 여러분에게 보여주었을 때였습니다. 그러면 기본적으로 새 항목을 만들고, 편집하고, 삭제할 수 있도록 하는 상당히 기초적이지만 기능적인 제어판이 나타납니다. . 이는 프로젝트에서 매우 중요할 수 있습니다. 특히 일종의 동적 환경에서 작업하는 경우에는 향후 해당 콘텐츠를 편집하기 위해 더 나은 도구를 구현하게 될 것입니다. 테스트 데이터를 입력하거나 프론트 엔드에서 작업하는 동안 작업을 시작할 수 있는 콘텐츠 팀에 전달할 수 있으므로 정말 유용합니다.

Drew: 배포만 하고 프로덕션 환경에서 사용하고 싶다면 프론트 엔드 코드와 함께 배포할 수 있을 것입니다. 하지만 해당 측면, 즉 애플리케이션의 루트를 보호할 방법이 필요합니다.

Anthony: 네, 인증을 위한 몇 가지 다른 옵션이 있습니다. Netlify ID를 사용할 수 있습니다. 튜토리얼에 들어가면 이것이 기본값이고 Auth0을 사용할 수도 있고 그 다음에는 내가 익숙하지 않은 Magic.Link라는 것을 사용할 수 있으며 앞으로 몇 가지 추가 기능이 추가될 것입니다. 하지만 네, 그래서 거기에 이미 몇 가지 내장 솔루션이 있습니다. 그리고 그것이 여러분이 하는 가장 마지막 일이기 때문에 제 전체 12부작 블로그 시리즈의 맨 마지막 부분이 인증입니다. 나는 Redwood를 사용하기 전에 Auth를 알아낸 적이 없다고 생각합니다. 그것은 어렵고 그들은 확실히 그것을 잘 해냈습니다.

Drew: 경로 수준에서 통합합니까, 아니면 경로 수준에서 통합합니까? 죄송합니다. 어떻게 보안을 유지합니까?

Anthony: 예, 자체 라우터가 있는 방식의 일부는 또한... 개인 경로를 수행할 수 있으므로 개인 경로 구성 요소가 있습니다. 그런 다음 실제 로그인 양식은 Netlify ID에서 얻은 것이므로 실제로 양식을 만들고 이를 사용하여 상태 관리를 수행할 필요가 없습니다. 여기서 많은 문제가 발생합니다. 정말 중요한 부분을 제거하면 역할 기반 액세스를 구현할 수 있습니다. David T가 지난 몇 주 동안 수행한 역할 기반 액세스 제어 추가 기능이 있습니다. 따라서 이를 수행하는 다른 방법을 만들기 위해 많은 작업이 진행되고 있지만 현재 얻은 것은 이미… 작동합니다. 기능을 제공합니다.

Drew: 사람들은 항상 보안 알고리즘 해싱 암호화에 대해 말하는데, 절대 자신의 것을 작성해서는 안 된다고 합니다. 점점 더 높은 수준의 인증도 마찬가지라고 생각합니다. 인증은 요즘 사람들이 고유한 자격 증명으로 사이트에 로그인하기를 원할 뿐만 아니라 Google을 사용하여 인증하거나 Apple 장치를 사용하여 인증하거나 2단계 인증을 원할 수 있기 때문에 인증이 매우 복잡한 영역입니다. , 또는 기업에서 사용 중인 단일 사인온 서비스와 통합하기를 원할 수 있습니다. 이 모든 것은 스스로 구현하려고 하면 골치 아픈 일이며, 애플리케이션에서 잘못된 것을 얻고 보안 허점을 드러낼 수 있는 기회가 너무 많아 인증 서비스를 사용하는 것이 현시점에서 생각할 필요가 없는 것처럼 보입니다. 따라서 본질적으로 몇 줄의 코드로 무언가를 입력하고 가동할 수 있다는 것은 작업을 수행하고 작업을 안전하게 유지하는 정말 생산적인 방법처럼 들립니다.

Drew: 서버리스 기능인 프런트 엔드와 서버 측면을 모두 배포하는 것은 Netlify에 배포하는 데 자연스럽게 적합합니다. Redwood와 관련이 있습니까? 내 말은, 우리는 Tom Preston-Werner가 이 프레임워크의 주요 지지자 중 한 명이며 Netlify의 이사회에도 있다고 언급했습니다. Redwood를 프로젝트의 기초로 선택했다면 연결이 너무 빡빡할 가능성이 있다고 생각하십니까?

Anthony: 네, 이것은 Tom이 확실히 의식하고 있는 것입니다. 그는 떠돌아다니는 많은 회사에 투자했습니다. 그는 Prisma와 Fauna에 투자했습니다. 그는 자신이 사용하고 싶은 도구를 만들고 싶어합니다. Netlify가 구축한 것이 최선의 선택이라고 생각하는 만큼 당신을 이 일에 가두려는 것이 아닙니다. 그래서 Netlify가 그것을 중심으로 구축한 것입니다. 그러나 그들은 그것이 하나의 배포 대상에 고정되는 것을 원하지 않으며 이것이 우리가 서버리스 프레임워크와 같은 작업을 수행하고 있고 일부 사람들이 Begin에 대해 이야기한 이유입니다. 우리는 실용적이고 누군가의 사용 사례가 무엇이든 간에 작동하기를 원합니다. 따라서 90%의 작업을 수행한 다음 선택한 서버와 작동하도록 마지막 몇 가지만 연결하면 됩니다.

Drew: Netlify도 서버 기능에 AWS Lambda를 사용하고 있는 것 같아요. 그래서 실제로 배포 부분은 Redwood에서 처리하고 실제로는 Lambda에 직접 배포할 수도 있습니다. 프론트 엔드를 게시하는 것은 파일일 뿐이며 나머지는 CDN 기반입니까? 따라서 너무 얽매이지 않고도 상당한 유연성이 있습니다.

Anthony: 예, 실제로 Tom이 Redwood의 핵심 철학적 아이디어로 말하는 용어가 있습니다. 바로 범용 배포 시스템에 도달하려는 것입니다. 그것은 일종의 t 아이디어입니다. 그냥 배포할 수 있고 그것에 대해 전혀 생각할 필요가 없다는 것입니다. 그는 이 아이디어에 대해 몇 년, 몇 년, 그리고 몇 년 동안 이야기해 왔으며 이것이 바로 지킬이 예전에 했던 것이기도 합니다. 지금 들으면 "아, Netlify 같은 말씀이신가요?" 기본적으로 Netlify는 프런트 엔드에서 작업하는 대부분의 사람들에게 있습니다. 그들은 더 이상 배포에 대해 생각조차 하지 않으며 생각조차 하지 않습니다.

Drew: 여기 Git Repo에 있는 내 애플리케이션이 있습니다. 이 디렉토리는 프론트 엔드, 이 디렉토리는 백엔드, 여기에 내 데이터베이스가 있습니다. 그리고 그것은 아마도 어떤 서비스가 그것을 가져오고 빌드하는 데 필요한 만큼의 구성입니다. 호스팅합니다.

Anthony: 예, 그리고 한 가지 지적해야 할 점은 저희가 Vercel Redwood 기본 배포 설정을 아주 최근에 설정했기 때문에 서버 측 앱에 배포할 때 "오, Gatsby 앱이 있습니다."라고 말할 수 있다는 것입니다. Gatsby 앱과 NextApp을 빌드하는 방법을 정확히 알고 있습니다. 이제 Vercel에 대한 정보가 있습니다. 따라서 Netlify가 아닌 정말 좋은 옵션도 있습니다.

Drew: 그래서, 내가 앱을 시작하고 빌드하고 이번 주에 프로덕션에 적용하고 싶다면 Redwood는 이에 대한 준비가 되어 있습니까? 성숙한가요?

Anthony: 예, 현재 프로덕션 단계에 있는 약 6개의 앱이 있습니다. 첫 번째는 3월에 나온 Predict COVID라는 이름으로 실시간 데이터 시각화 응용 프로그램과 같습니다. 그런 다음 Rob이 수행한 repeater.dev가 있습니다. Jamstack의 경우 cron 작업과 같습니다. 그런 다음 Tape.sh가 있습니다. Duoflag는 또 다른 것이라고 생각합니다. 그래서, 적어도 소수가 있습니다. 멋진 Redwood repo에 가면 모든 목록을 볼 수 있습니다. 커뮤니티 포럼에 가면 이런 글도 찾을 수 있습니다. 사람들이 이것을 생산에 투입하고 어떻게 진행되었는지 이야기했기 때문입니다. 지금까지 그들은 모두 성공했고 아무도 "나는 이것을 다시는 사용하지 않을 것입니다"라고 말하지 않았습니다.

Drew: 하지만, 그것은 매우 새로운 것입니다. 나는 그것을 피할 수 없다고 생각하지만 성숙도 측면에서 Redwood는 꽤 새롭습니다. 좋은 추종자를 얻고 있습니다.

Anthony: 글쎄요, 재미있습니다. 그렇긴 하지만 그렇지 않습니다. 3월에 발표했습니다. 그 시점에서 Tom과 Peter가 약 1년 동안 작업했습니다. So, they'd already put a ton of upfront work into this, so it wasn't like I'm going to announce this project with a Read Me and then start building it. By the time they announced it, it wasn't… It's not a 1.0 now, but it's pretty dang close in terms of what people would expect out of a 1.0. But, Tom is very against what we call type driven development so he always errs on the say it's not ready. So, we say it's not ready for production even though it's in production.

Drew: I think one thing that people sometimes get burned on using frameworks is that they'll build a project around the framework and then that framework will very quickly go to another major version that had backwards incompatibilities, and they're then left with a big project to update everything onto the new version of the framework. Is that something that's likely to happen with Redwood? I mean, none of us has got a crystal ball, but just with the technologies that are involved and the way it's structured, do you think that's a big danger or a little danger?

Anthony: Yeah, it's a super valid concern and definitely something the team has thought about. The CLI has an upgrade command, so you can basically every time there's a version bump, you just do a command and it bumps you up the version. I've been dealing with this a little bit just because of the series I wrote, I started it when it was on version 11 or 0.11, it's like 0.17 or something now. So, I've been slowly iterating on it as it's gone but nothing breaks. It's all, you get slowly things, or like “Oh, this is kind of a nice little touch you've got here,” but it's pretty much set in stone architecturally. Redwood as it's structured, the front or the back end is not going to change at all. It was very well thought out in terms of what they want architecturally. That's why they built it, so they could get something that's structured like this thing.

Drew: I guess with modern web development, there is a certain point where you're just never going to get away from being reliant on dependencies updating themselves and changing. I mean, even using React, React goes through as many different changes as anything else.

Anthony: That's exactly why Tom inventing semantic versioning.

Drew: I guess from the other side of that coin, if Redwood did happen to go away, which is always something we consider when picking a framework, if development stopped somehow, I guess the impact on a particular app might not be too great because it is just so heavily built on existing other projects around. Is that-

Anthony: Well, some would say that a Redwood tree can survive a lot, it survives for a very long time. That may have been why it's called that, is that you can just make a site and deploy it and it's not going to break, it's just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that's huge. Being built by people who tried to scale Rails apps, I imagine they've thought a lot about that. But in terms of the going away part, that's always going to be a danger with any open source project, so I think what you have to look for is how enthusiastic is the community to continue it without the team if that ever happens. I don't think you even need to worry about that because Tom's a billionaire and he has a venture funding thing that is funding some of the development. It is an open source project that is well funded actually. It has four full time members, Tom, Rob, David, and Peter. You just go to the forums, you can see the activity that's going on, so I wouldn't worry about that too much-

드류: 물론이죠.

Anthony: Beyond normal open source worries that come along with that stuff.

Drew: What is the community like? You mentioned the community, are there lots of people using it and contributing to the code base or is it mainly the core team who are doing the development?

Anthony: Yeah, it's very much structured to be a community thing. They want to get as much buy in from the community as possible, and this comes from the lineage like you said. There's few people with more open source cred than Tom, so he's done a really great job of bringing people into the fold. I think just my story in general is a big win for the community because I came in, I'm a boot camp student, I'm learning all this stuff as I go. I'm not pushing code to the repo, I'm making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value. Yeah, there's really a lot of things about how they approach community building that I have a lot of respect for, and that is why I've been so invested in it and putting so much of myself into it.

Drew: Some frameworks have got this sort of natural bent for certain types of projects. 예를 들어. The Python framework, Django came out of online news publishing, and so it's a really good fit if you want to rapidly publish content like you would in a news organization. Does Redwood lean in any particular direction when it comes to the type of projects? Is it suited for content publishing or building web applications or-

Anthony: It's made to be fairly agnostic to that. It wants to be a tool that you use for a lot of stuff. First, before it was called Redwood, it was called Hammer, the idea being that you do a lot of stuff with a hammer. But, there definitely is a kind of sweet spot, which I think is the multi client type applications. So, if you know that you're starting with a web front end but you're pretty sure you're going to end up with a mobile client as well, then it's a really good fit for that because it starts you off in a way that you're going to be able to extend into having multiple clients with GraphQL, which we kind of talked about a little bit. So, I'd say that'd probably be the first thing that I would say is its sweet spot. But, it's meant to work for as many things as possible.

Drew: Does Redwood have a published roadmap of where it's going? What can we expect to be coming in the near future?

Anthony: Glad you asked. We just put out a roadmap to 1.0 less than a month ago, it was probably like two or three weeks ago. It kind of itemizes things that we're working on, things we think we're kind of close on, things we think we still have a long ways to go on. That kind of helps the community see where can I help contribute. That's one of the things we're really great about is showing here are the things that still need to be worked on. They're aiming for 1.0 by the end of the year. We'll see where we get with that, but that's the trajectory we're currently on.

Drew: One of the beauties of a Jamstack and a serverless approach I always think is that it's this idea of lots of pieces loosely joined that has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces. Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? Could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

Anthony: Yeah, this is something I think about a lot because as I learned web development, I was taking… I'm in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We're essentially learning the PERN stack, but you learn React, and then we learned Express. We never talked about how it actually works together. So, I do think that there is definitely a danger of not being able to comprehend in your project because of how it's all wired up. So, what I really liked about Redwood is that it just made sense. It was a mental model of how to think about my entire app and all the pieces and how they fit together in a way that really made sense to me. But, what I was surprised to find doing the Fauna project is that it's much more modular than you would think based on… You talk about it, and like you said, it sounds like it's a monolith thing, but you can rip pieces out and replace them with other pieces and they can still work. So, it's made to be a fully integrated solution, but not a solution that is tightly coupled just because this is a good way to integrate all these technologies doesn't mean you need to tightly couple them to integrate them well.

Drew: Yeah, that sounds a very promising way of structuring things, and it's going to be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven't talked about?

Anthony: No. I mean, I would say if you're interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they call tutorial driven development, which is kind of a play on Read Me driven development, which is another thing Tom coined, that you should start with a Read Me, and then create your code to make sense with what your Read Me was. This is the idea of you create a tutorial and then you write your framework to make the tutorial work. So, that's why it's a really easy way to get spun up with it because it was made to make sense of going through the process of learning it. They've really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech. They progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially built the same project, but I write my own stuff as I go, and reference the docs. So, if you're interested in just learning Redwood, start with the actual tutorial and then check out my series.

Drew: So, I've been learning all about Redwood, what have you been learning about?

Anthony: Yeah, so I've been learning about CMSs, and I was actually really curious to get your thoughts on this because I imagine you've been around the block, you know a lot of CMSs. Obviously, you know you've got your WordPress's, your Drupal, but what's really interesting with something like Redwood is since you have this GraphQL stuff baked in, it has the CMS, it's just such a natural fit. So, I'm trying to figure out, what are interesting headless CMSs to check out? Which ones have GraphQL integration? Which ones have different sweet spots? If I wanted to take a CMS to build an app with RedwoodJS, what would you recommend?

Drew: That is a good question, and I'm not sure I have an immediate answer. I have looked at lots of different CMSs, not particularly with a view to GraphQL. I've not worked with GraphQL myself yet, and so that was not-

Anthony: Oh man, you've got to join the club, dude.

Drew: Yeah, no, I'm definitely getting onboard. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL, so it's certainly one of the things that I need to be learning.

Anthony: I actually learned GraphQL through Redwood. I didn't really know GraphQL, and I'd say you should know a little bit before going into it, and I had a very, very tiny basic knowledge. You can actually learn what a schema definition language is, and that GraphQL kind of jargon. You'll learn a lot and you'll pick it up as you go with Redwood.

Drew: Yeah, I should definitely get onboard and maybe doing some Redwood is the way to do it. Perhaps I need to pick up a project and start going with Redwood and see where it takes me.

Anthony: Yeah, at the very least I would say just check it out, just because it's interesting. I find it to be just a really fascinating thought experiment of how do we do modern web application development differently and more coherently.

Drew: If you, dear listener, would like to hear more from Anthony, you can find him on Twitter at ajcwebdev. His comprehensive series of articles about getting started with Redwood are on the Redwood community site, which we'll link to from the show notes. Of course, you can find all about Redwood and get started at RedwoodJS.com. Thanks for joining us today, Anthony. 이별의 말이 있나요?

Anthony: 이 항목에 관심이 있으시면 언제든지 연락해 주세요. 제 DM은 항상 열려있습니다. 커뮤니티는 일반적으로 매우 개방적입니다. 진행하기 위해 알아야 할 사항을 기꺼이 설명하거나 안내하거나 설정해 드리겠습니다.