프레임워크의 종류

docs.scrimba.com

프레임워크란 무엇인가에서 다룬 개념은 이렇습니다: 구조와 해결된 기술적 세부사항, 그리고 프레임워크가 당신의 코드를 호출하는 것입니다. 이 장은 실제로 존재하는 것들의 지도입니다: 안심을 주는 투어입니다. 왜냐하면 이 모든 것을 아는 사람은 없기 때문입니다. 일하는 개발자는 한두 가지 계열을 잘 알고 나머지를 인식할 뿐이며, 여기서도 그것이 목표입니다. 계열이 이름보다 중요합니다: 한 멤버를 잘 배우면 그 형제들은 빠르게 따라옵니다.

웹: 프론트엔드와 백엔드

웹 프레임워크는 웹 자체가 나뉘는 선을 따라 나뉩니다. 프론트엔드 프레임워크는 브라우저에서 실행되며 사용자가 보는 것을 관리합니다. 백엔드 프레임워크는 서버에서 실행되며 데이터, 계정 및 백그라운드의 모든 것을 관리합니다. 웹 개발에 들어가면, 양쪽에서 하나씩이 일상적인 도구가 될 것 같으며, 어느 것을 선택할지는 보통 당신이 아닌 당신이 참여한 팀이나 프로젝트에 의해 결정됩니다.

만날 수 있는 프론트엔드 이름들:

• React: 매우 큰 차이로 가장 많이 사용되는, 가장 큰 에코시스템과 일자리 시장을 갖춘 것. 기술적으로 완전한 프레임워크보다는 UI 라이브러리이며, 이 구분은 아래에서 다룬 유용한 핵심을 가지고 있습니다.
• Vue: 부드러운 진입로와 실제로 즐겨 읽는 설명서로 유명합니다. 완전하고 잘 정리된 중간 경로입니다.
• Angular: Google의 배터리 포함 프레임워크로, 모든 것에 대해 의견이 강합니다. 각 작업에 대해 하나의 공식적인 방법을 원하는 큰 조직에서 가장 활용도가 높습니다.
• Svelte: 빌드 시간에 작업을 수행하고 브라우저에 더 적은 코드를 배송합니다. 작은 커뮤니티이지만, 그 안의 사람들로부터 자주 찬사를 받습니다.

그리고 백엔드 이름들은 프레임워크가 보통 언어와 연결되어 있습니다:

• Django (Python): 배터리 포함, 데이터베이스에서 관리 인터페이스까지. 이미 알 수 있는 Python의 자주 사용되는 파트너입니다.
• Rails (Ruby): 설정보다 관례를 대중화한 프레임워크. 그 아이디어는 대부분의 최신 웹 프레임워크, Laravel 포함에 울려 퍼집니다.
• Laravel (PHP): PHP 세계의 현대적 표준으로, 여전히 웹의 매우 큰 부분을 실행합니다.
• Express (JavaScript): 의도적으로 최소한이며, 완전한 프레임워크보다는 툴킷에 더 가깝습니다. 나머지는 직접 조립합니다.
• Spring (Java): 엔터프라이즈 워크호스입니다. 광대하고, 깊이 있게 확립되어 있으며, 큰 회사 어디에나 있습니다.

로고를 넘어 볼 수 있게 되면, 같은 아이디어가 이 모든 것을 통해 반복됩니다. 프론트엔드 프레임워크는 모두 컴포넌트로 수렴했습니다: 자신의 모양과 동작을 소유한 작고 재사용 가능한 인터페이스 조각. 백엔드 프레임워크는 모두 라우팅(어느 URL이 어떤 코드를 실행하는지), 데이터베이스와 통신하는 방법(종종 ORM, 데이터베이스 행을 일반 객체로 작업할 수 있게 함), 그리고 비즈니스 로직을 위한 슬롯을 제공합니다. 한 프레임워크에서 이 아이디어들이 무엇을 위한 것인지 배우면, 다음 프레임워크의 대부분을 이미 배운 것입니다. 프레임워크 간 이동은 주로 같은 개념 위에 새로운 문법과 새로운 폴더 이름입니다.

현재의 프론트엔드는 한 겹 더 있습니다. React, Vue, Svelte는 인터페이스를 처리하지만 라우팅, 데이터 로딩, 서버 렌더링은 당신에게 맡기므로, 각각은 **메타 프레임워크**를 키워냈습니다: 그 누락된 조각들을 공급하는 라이브러리 위에 구축된 프레임워크. Next.js는 React을 위해 그 역할을 하고, Nuxt는 Vue를 위해, SvelteKit은 Svelte를 위해 합니다. 실제로 대부분의 새 프로덕션 앱은 단순한 라이브러리보다는 메타 프레임워크를 선택합니다. 이것은 오래된 "React는 프레임워크인가 라이브러리인가" 논쟁을 유용한 방식으로 해결합니다: React 자체는 UI만 렌더링하고 당신의 컴포넌트 이외에는 제어를 역전시키지 않으므로, 지난 장의 정의에 따르면 그것은 라이브러리입니다. Next.js로 감싸면 둘의 조합은 정확히 프레임워크처럼 동작합니다. 라벨은 어느 계층이 어떤 결정을 소유하는지 아는 것이 덜 중요합니다. 왜냐하면 뭔가 작동하지 않을 때 당신이 찾는 곳이 그곳이기 때문입니다.

Juno웹 프레임워크 React와 Vue 같은 프론트엔드 프레임워크는 브라우저에서 실행되고 사람들이 보는 것을 처리합니다. Django와 Rails 같은 백엔드 프레임워크는 서버에서 실행되고 데이터와 계정을 처리합니다. 오늘 완벽한 것을 선택할 필요가 없으며, 확실히 모두 필요하지도 않습니다. 대부분의 사람들은 첫 팀이 사용하는 것을 배우고, 그것이 잘 작동합니다!

Juno웹 프레임워크 웹 이름들은 다르지만, 아이디어는 반복됩니다: 프론트엔드의 컴포넌트, 백엔드의 라우팅, ORM, 비즈니스 로직 슬롯. 한 프레임워크를 통해 아이디어를 배우면 다음 것은 주로 익숙한 모양 위의 새로운 문법입니다. 이 전이가 첫 번째에 "잘못된 것"을 선택하는 것이 사람들이 두려워하는 것보다 훨씬 적은 비용이 드는 이유입니다.

Juno웹 프레임워크 현대적인 프론트엔드 작업은 보통 메타 프레임워크를 의미합니다: React 위의 Next.js, Vue 위의 Nuxt, Svelte 위의 SvelteKit, 기본 라이브러리가 빠진 라우팅과 서버 렌더링을 제공합니다. 어느 계층이 어떤 결정을 소유하는지 명확히 하세요. 그것은 디버깅이 시작하는 곳이기 때문입니다. 그리고 React는 정말로 우리의 정의에 따르면 라이브러리입니다. Next.js가 둘을 프레임워크로 만드는 것입니다.

앱과 게임

모바일 개발은 자신의 프레임워크 이야기를 가지고 있으며, 그것은 한 가지 질문 중심입니다: iPhone과 Android를 위해 별도로 구축하거나 한 번에 둘 다 구축합니까? 두 가지 프레임워크가 한 번 빌드 답변을 지배합니다. Flutter (Google에서, Dart 언어 사용)는 자신의 인터페이스를 픽셀 단위로 그리므로, 앱은 어디서나 동일하게 보입니다. React Native React의 컴포넌트 모델을 모바일에 가져오고 각 플랫폼의 네이티브 인터페이스 조각을 운전합니다. 이것은 이미 React을 알고 있다면 자연스러운 계속입니다.

게임 엔진은 가장 총괄적인 프레임워크입니다: 그들은 초당 60번 실행되는 루프를 소유하고, 당신의 코드는 그 안에서 각 객체가 무엇을 하는지 채웁니다. Unity (C#)는 인디와 중견 게임, 모바일 게임의 많은 부분의 기본값입니다. Unreal (C++)은 큰 예산의 게임에서 영화 제작까지 시각적 충실도가 요점인 곳에서 주도합니다. **Godot는 무료, 오픈소스 엔진으로 커뮤니티가 빠르게 성장했으며, 시작하기 좋은 친절한 곳입니다.

크로스 플랫폼 트레이드는 그 가격 태그를 크게 읽을 자격이 있습니다. 하나의 코드베이스는 절반의 작업과 하나의 팀을 의미하며, 이것이 비즈니스가 그것을 사랑하는 이유입니다. 비용은 당신과 플랫폼 사이의 계층입니다: 완전히 새로운 iPhone 기능이 출시될 때, 프레임워크가 그것을 편하게 사용하기 전에 지원해야 하며, 완전히 네이티브 느낌을 짜내는 것은 추가 주의가 필요합니다. 모든 네이티브 세부사항이 필요한 팀은 여전히 각 플랫폼의 고유한 키트로 별도로 구축합니다. 둘 다에 작은 크루로 배송해야 하는 팀은 Flutter나 React Native를 선택하고 거의 후회하지 않습니다.

게임 엔진은 제어의 역전을 극단까지 밀어붙이므로, 그들은 명확하게 하는 극단적인 사례입니다. 엔진은 시간 자체를 소유합니다: 매 프레임마다 당신의 스크립트를 호출하고, 당신의 콜백 사이에서 물리를 실행하고, 당신의 객체가 존재할 때조차 결정합니다. 또한 당신은 주로 엔진 "안에서" 코드를 쓰지 않습니다. 당신은 그 편집기 안에서 작업하고, 스크립트는 장면, 재료, 프리팹 중 하나의 자산일 뿐입니다. 그 총괄적 소유권은 정확히 엔진이 존재하는 이유입니다: 렌더링, 물리학, 자산 파이프라인은 어떤 게임 팀도 다시 구축하고 싶지 않은 수년의 전문가 작업입니다. 같은 논리는 축소됩니다: 배관이 제품을 왜곡할 때마다, 프레임워크는 편의에서 멈추고 유일한 합리적인 경로가 됩니다.

Juno앱과 게임 Flutter와 React Native는 하나의 코드베이스가 iPhone과 Android 앱이 되도록 합니다. 이것이 많은 팀이 그것을 사용하는 이유입니다. 게임에는 Unity, Unreal, Godot와 같은 엔진이 있으며, 그래픽과 물리학을 처리하는 동안 당신의 코드는 각 객체가 무엇을 하는지 말합니다. 웹과 같은 프레임워크 아이디어이지만 다른 옷을 입고 있습니다.

Juno앱과 게임 크로스 플랫폼 모바일은 약간의 네이티브 광택을 절반의 작업으로 교환합니다. 대부분의 팀이 기꺼이 받는 거래이고, 완전히 네이티브한 키트는 플랫폼 느낌이 모든 것일 때 답변으로 남습니다. 게임 엔진은 완전한 강도의 프레임워크 아이디어입니다: 그들은 초당 60번 쇼를 실행하고 당신의 스크립트는 행동을 채웁니다.

Juno앱과 게임 엔진은 규칙을 설명하는 극단입니다: 배관(렌더링, 물리학, 자산 파이프라인)이 수년의 작업이고 당신의 실제 게임을 왜곡할 때, 제어를 포기하는 것은 유일한 합리적인 거래입니다. 그 비율을 당신의 머리에 유지하세요. 배관 대 제품, 그리고 어떤 분야의 대부분의 프레임워크 결정은 더 쉬워집니다.

조용한 것들: 테스팅과 데이터

모든 프레임워크가 제품 구축에 대한 것은 아닙니다. 어떤 것들은 그 주변의 작업을 구성합니다. 테스팅 프레임워크가 가장 명확한 경우이고, 지난 장의 정의의 가장 순수한 예입니다: pytest (Python), Jest (JavaScript), JUnit (Java)은 각각 당신의 테스트 함수를 찾고, 실행하고, 보고합니다. 당신은 당신의 자신의 테스트를 호출하는 프로그램을 작성하지 않습니다. 거의 모든 전문 코드베이스에서 하나를 만날 것입니다. 보통 프로젝트의 언어와 일치하는 것입니다.

데이터와 머신 러닝도 프레임워크를 가지고 있습니다. **PyTorch**는 연구에서 점점 더 프로덕션에서 지배합니다. **TensorFlow**는 Google의 깊은 프로덕션 도구를 갖춘 에코시스템입니다. 둘 다 모델 교육의 수학적 기계를 처리하므로 당신의 코드는 계산법이 아닌 모델을 설명합니다. AI 작동 방식 트랙이 당신에게 관심을 준다면, 이들이 그 세계가 구축하는 도구들입니다.

테스트 러너는 제어의 역전을 축소판으로 나타내며, 그 이유 때문에 1분간 감상할 가치가 있습니다. test_something 이름의 함수를 쓰고, 프레임워크는 이름으로 그것들을 발견하고, 각각을 신선한 설정에서 실행하고, 나머지를 멈추지 않고 실패를 잡고, 요약을 인쇄합니다. 아무도 그 조율을 프로젝트당 작성하지 않습니다. 이것이 가장 작고 가장 덜 논쟁적인 프레임워크 가치 제안입니다: 원칙상 제품 프레임워크를 회피하는 개발자도 기꺼이 테스트 프레임워크를 사용합니다.

ML 쌍은 라이브러리 대 프레임워크 선이 유용하게 흐릿해지는 곳입니다. PyTorch에서 맞춤 교육 루프를 작성하는 것은 라이브러리를 사용하는 것처럼 느껴집니다: 당신의 코드는 방향을 지정하고, 그것은 빠른 수학을 공급합니다. 더 높은 수준의 계층, 트레이너, 콜백을 사용하면 그것을 다시 프레임워크 모양으로 뒤집으므로, 당신의 코드는 도구가 소유한 루프에 슬롯됩니다. 경계는 당신이 도구를 운전하는 어느 계층에 달려 있습니다. 그 프레이밍은 ML을 훨씬 넘어 이동합니다: 많은 큰 도구는 한 고도에서는 라이브러리이고 다른 고도에서는 프레임워크이며, 당신이 어느 고도를 날고 있는지 아는 것은 누가 오늘 제어 흐름을 소유하는지 말해줍니다.

Juno테스팅과 데이터 프레임워크 pytest와 Jest 같은 테스팅 프레임워크는 당신의 테스트 함수를 찾고 당신을 위해 실행합니다. 프레임워크가 당신의 코드를 호출하는 작은 일상적 예입니다. 머신 러닝에서, PyTorch와 TensorFlow는 모델 교육의 무거운 수학을 처리합니다. 프레임워크는 모든 종류의 프로그래밍 작업을 구성하고, 앱 구축을 훨씬 넘어갑니다.

Juno테스팅과 데이터 프레임워크 테스트 러너는 가장 덜 논쟁적인 프레임워크 아이디어입니다: 발견, 격리, 그리고 아무도 프로젝트당 다시 구축해야 하는 보고. 프레임워크에 회의적인 개발자도 불평 없이 하나를 사용한다는 것을 주목하세요. 거래는 작지만 보상은 일정합니다. 그 불균형은 어떤 프레임워크를 판단하기 위한 좋은 렌즈입니다.

Juno테스팅과 데이터 프레임워크 PyTorch는 당신이 교육 루프를 작성할 때 라이브러리이고 그 트레이너가 당신을 실행할 때 프레임워크이며, 그것이 일반적인 교훈입니다: 큰 도구는 어느 계층을 운전하느냐에 따라 범주를 변경합니다. 당신이 작업하는 고도에서 누가 제어 흐름을 소유하는지 물어보세요. 그러면 라이브러리인지 프레임워크인지의 질문이 답합니다.

여기서 다음은 어디로

이것이 지도입니다: 와이어의 양쪽에 웹, 모바일, 게임, 테스팅, 데이터. 모두 다른 유니폼을 입은 같은 아이디어입니다. 남은 질문은 실무적인 것이며, 두 가지 반쪽을 가지고 있습니다: 어느 것, 그리고 하나도 아니냐. 프레임워크 선택 및 배우기는 둘 다 정면으로 마주합니다. 여기서의 정의가 불안정해 보인다면, 프레임워크란 무엇인가는 짧은 읽을거리입니다.