django vs flask vs node
Flask와 Django는 Python 기반 웹 개발 프레임 워크입니다. 이 튜토리얼은 Django와 Flask를 자세히 비교합니다. Flask 대 Node도 간략하게 다룹니다.
다음 프로젝트를위한 프레임 워크를 선택하는 문제와 관련하여 항상 만연한 딜레마였습니다. 몇 달마다 사용했던 이전 기술의 약점을 극복하는 새로운 기술과 프레임 워크를 보게됩니다.
프레임 워크는 조용한 문화와 비슷하며 끊임없이 변화하는 기술 세계에서 더 관련성과 생산성을 높이기 위해 따라야하는 일련의 규칙입니다. 상대적으로 웹 개발은 데스크톱 개발보다 훨씬 빠르게 이동합니다.
학습 내용 :
장고 대 플라스크
이 튜토리얼에서는 Django와 Flask를 자세히 비교합니다. Flask와 Django는 Python 기반 웹 개발 프레임 워크입니다. 많은 사람들이 경량 마이크로 프레임 워크로 이동하고 있습니다. 이러한 프레임 워크는 민첩하고 유연하며 작으며 마이크로 서비스 및 서버리스 애플리케이션을 개발하는 데 도움이됩니다.
NodeJS의 인기를 고려하여 Flask vs. Node 섹션에서 Flask와 Node 사이의 천재적 비교도 제공했습니다. 다음 기능에서 Django와 Flask를 평가하면 다른 기능을 선택하는 데 도움이됩니다.
기본 관리자
두 프레임 워크 모두 부트 스트랩 된 관리 애플리케이션을 제공합니다. Django에서는 내장되어 있으며 기본 설치와 함께 제공됩니다. 그러나 Flask의 경우 관리자 인터페이스를 사용하려면 Flask-Appbuilder를 설치해야합니다.
한편, 브라우저를 사용하여 관리자 백엔드에 로그인 할 수 있도록 Django에서 수퍼 유저를 만들고 Flask의 경우 관리자를 만들어야합니다.
데이터베이스 및 ORMS
Django는 Oracle, MySQL, PostgreSQL, SQLite 등과 같은 RDBMS와의 상호 작용을 완전히 지원하는 기본 내장 ORM과 함께 제공됩니다.이 ORM은 마이그레이션 생성 및 관리도 지원합니다. 내장 된 유효성 검사를 사용하여 데이터베이스 모델을 만드는 것이 상대적으로 더 편안합니다.
Flask는 또한 특정 방법을 강요하지 않으며 Django의 경우에 설명 된 것과 유사한 기능을 지원하는 다양한 확장과 함께 사용할 수 있습니다. 시리즈의 자습서 중 하나에서 Flask-SQLAlchemy, Flask-Migrate, Flask-MongoEngine의 예를 제공했습니다.
보기 및 경로
두 프레임 워크에는 메서드 기반 및 클래스 기반 뷰를 선언하는 메커니즘이 있습니다. Django의 경우 경로와 뷰가 별도의 파일에 언급됩니다. 또한 항상 명시 적으로 요청 객체를 전달해야합니다.
반면에 Flask에서는 데코레이터를 사용하여 해당 핸들러의 경로를 언급 할 수 있습니다. Flask의 요청 객체는 전역 적이며 명시적인 전달없이 사용할 수 있습니다. 튜토리얼 중 하나에서 뷰 및 경로 사용에 대한 개념을 자세히 설명했습니다.
양식 및 템플릿
Django Forms는 프레임 워크에 내장되어 있으며 설치할 필요가 없습니다. 양식은 응용 프로그램에 매우 중요하며 Django에서는 양식을 템플릿 태그로 전달할 수 있으며 템플릿에서 렌더링 할 수 있습니다. 그러나 Flask의 경우 Flask-WTF를 사용해야합니다.
또한 Flask-Appbuilder를 사용하여 양식을 만들었습니다. 또한 WTF-Alembic을 사용하여 데이터베이스 모델을 기반으로 HTML 양식을 생성 할 수 있습니다.
두 프레임 워크 모두 Jinja2 템플릿을 지원하며 둘 다 리소스의 URL을 생성하는 기능이 내장 된 정적 파일 제공을 지원하며 요즘 모든 프레임 워크에서 매우 일반적인 패턴입니다.
변수를 전달하고 특정 뷰 메서드에서 템플릿을 렌더링하는 방법은 여러 가지가 있지만 두 프레임 워크 모두 템플릿의 변수에 액세스하는 동일한 구문을 가지고 있습니다.
적응성
Django는 크기와 복잡성 때문에 Flask보다 유연성이 떨어집니다. Flask는 지원하는 수많은 확장 기능을 사용하여 쉽게 확장 할 수 있습니다. 따라서 더 많은 확장을 평가해야하므로 Flask를 설정하는 데 더 많은 시간과 노력이 필요합니다.
어떤 방식 으로든 개발자에게 주어진 자유는 개발 및 제공 속도를 늦 춥니 다. 반면에 Django는 이미 확립 된 일련의 규칙을 따르고 프로젝트 목표 및 목표에서 덜 벗어나는 것을 요구하는 원형을 따릅니다.
학습 곡선
Django와 Flask를 모두 배우려면 거의 같은 시간이 필요합니다. Flask에는 더 작은 API가 있습니다. 따라서 사람들은 핵심 프레임 워크에 관한 한 더 빨리 완료 할 수 있습니다. 확장 기능을 사용할 때도 똑같이 도전이됩니다. 곧 번거로울 수 있습니다.
그러나 모든 것이 하나의 패키지에 포장되어 있지 않기 때문에 Flask 프레임 워크의 경우 관심사 분리를 연습하는 것이 더 쉽습니다.
따라야하는 구문이 아니라 패턴을 배우는 것이 좋습니다. Django와 Flask 모두 훌륭한 문서를 가지고 있습니다. 기능을 개발하는 동안 쉽게 따라갈 수 있습니다.
프로젝트 크기 및 기간
더 큰 팀과 함께 더 큰 프로젝트를 작업 할 때 Django의 성숙도와 광범위한 기여자 지원을 활용하는 것이 좋습니다. 프로젝트가 더 작고 개발자 수가 적은 경우 Flask를 사용하는 것이 좋습니다.
또한 프로젝트가 오래 지속될 경우 Django가 올바른 선택입니다. 그렇지 않으면 Flask를 선택할 수 있습니다.
신청 유형
이전의 Django는 완전한 엔터프라이즈 급 웹 애플리케이션에 대한 요구 사항이있을 때 올바른 선택으로 간주되었습니다. 그러나 오늘날 Flask는 똑같이 성숙하고 동일한 조건에서 잘 사용할 수 있습니다.
그러나 개발자는 소규모 또는 정적 웹 사이트를 개발하거나 RESTful API 웹 서비스를 제공하기 위해 신속하게 구현할 때 Flask를 더 선택하는 경향이 있습니다.
개발자 모집
사용하는 프레임 워크의 규칙에 숙련 된 리소스를 보유하면 효과가 있습니다. 더 빠른 개발, 더 빠른 테스트, 더 빠른 제공 및 더 빠른 문제 수정을 기대할 수 있습니다.
Flask의 경우 새로운 개발자를 찾는 것은 매우 쉽습니다. 그러나 Django에서 숙련 된 리소스를 찾는 것은 어렵습니다. Django 개발자가 고용 할 준비가 된 사람은 많지 않습니다. 더욱이 Django 프레임 워크는 꽤 오래 되었기 때문에 대부분의 신입 직원은 Flask 프레임 워크에 능숙한 사람들과 비교할 때 비용이 많이 듭니다.
새로운 기술 졸업생은 Flask와 같은 가벼운 프레임 워크도 선택하고 있습니다. 업계 트렌드는 분리 된 마이크로 서비스 또는 서버리스 구현 생성을 지원하는 기술을 사용하여 애플리케이션을 만드는 방향이기 때문입니다. Javascript는 사용하기 쉽고 인기있는 프레임 워크와 함께 널리 사용됩니다.
오픈 소스
Flask와 Django는 모두 오픈 소스 프로젝트입니다. Django는 https://github.com/django/django에서, Flask는 https://github.com/pallets/flask에서 찾을 수 있습니다. 이러한 프로젝트를 살펴보면 Django에 기여한 사람의 수는 Flask에 기여한 사람보다 훨씬 더 많습니다.
따라서 해결이 필요한 문제와 쿼리가있는 경우 더 빠르고 더 빠른 지원을 기대할 수 있습니다. 일반적인 가정과 달리 Flask 프로젝트의 사용자 수는 Django의 사용자 수보다 높습니다.
Flask에 대한 한 가지 중요한 사실은 특정 작업에 대한 안정적인 확장이 없을 수 있다는 것입니다. 따라서 가장 좋은 것을 필터링하는 작업은 확장 프로그램의 사용자에게 있습니다.
예를 들면 지난 튜토리얼에서 Twitter의 API로 작업하기 위해 Flask-Twitter-oembedder를 사용했지만이 확장 프로그램에는 Flask-Cache에서 Flask-Caching으로 전환해야하는 문제가있었습니다.
우리는 프로젝트의 requrements.txt 파일에 언급하는 대신 업데이트 된 Github 저장소에서 Flask-twitter-oembedder를 설치하기 위해 사용자 지정 설치 문을 포함해야했습니다.
잦은 유지 관리는 오픈 소스 프로젝트에서 직면하게되는 일반적인 문제입니다. 오픈 소스 프로젝트의 지원 및 관리는 일반적으로 유료 서비스와 관련이 있습니다. 프로젝트 기여자로부터 몇 가지 문제를 해결하려면 오랜 시간을 기다려야 할 수 있습니다.
공연
Flask 프레임 워크는 Django보다 가볍고 특히 I / O 작업을 고려할 때 무시할 수있는 차이로 더 잘 수행됩니다.
아래 제공된 비교를 살펴보십시오. 요청이 증가함에 따라 Flask의 성능은 거의 동일하게 유지됩니다. 그러나 Django는 ORM을 사용하여 데이터를 가져온 후 템플릿을 렌더링하는 데 더 많은 시간이 걸립니다.
Python Flask 대 Django : 테이블 형식 비교
| # | 풍모 | 장고 | 플라스크 |
|---|---|---|---|
| 7 | 템플릿의 가변 보간 | templates / demo.html에서 {{tempvar}} | templates / demo.html에서 {{tempvar}} |
| 1 | 기본 관리자 | 내장 관리 백엔드 | Flask-Appbuilder 설치 |
| 두 | 기본 관리자 활성화 | settings.py에서 관리자가 설치 한 앱의 주석 처리를 제거했는지 확인하십시오. ... # 애플리케이션 정의 INSTALLED_APPS = ( '웹 사이트', 'django.contrib.admin', # 다른 코드 ) ... | flask_appbuilder에서 AppBuilder 및 SQLA를 가져오고 DB를 먼저 초기화 한 다음 Appbuilder를 초기화합니다. 플라스크 가져 오기 플라스크에서 flask_appbuilder에서 가져 오기 AppBuilder, SQLA app = Flask (__ name__) db = SQLA (앱) appbuilder = AppBuilder (앱, db.session) |
| 삼 | 관리자 생성 | python manage.py createsuperuser | 플라스크 팹 생성 관리자 |
| 4 | 데이터베이스 및 ORMS | RDBMS 용 내장 ORM NoSQL 백엔드에 Django-nonrel 사용 | Flask-SQLAlchemy 설치 Flask-MongoEngine과 같은 NoSQL 특정 Flask-Extension |
| 5 | 보기 및 경로 | urls.py의 URLConf django.urls 가져 오기 경로에서 .import보기에서 urlpatterns = ( 경로 ( '/ path', views.handler_method), # 기타 URL 및 핸들러 ) | 뷰에서 @ app.route ( '/ path') 데코레이터를 사용하여 함수로 경로를 매핑합니다. @ app.route ( '/ path') def handler_method () : # 추가 로직이있는 다른 코드 |
| 6 | 렌더 템플릿 | 보기에서 django.shortcuts import render에서 def example_view (요청) : tempvar =”value_for_template” return render ( 의뢰, 'demo.html' { 'Tempvar': tempvar} ) | 보기에서 에서. 앱 가져 오기 플라스크 가져 오기 요청에서 플라스크에서 가져 오기 render_template @ app.route ( '/ path') def 데모 () : tempvar =”value_for_template” return render_template ( 'demo.html' temp_var = temp_var ) |
| 8 | 적응성 | 덜 유연함 | 더 유연함 |
| 9 | 디자인 결정 | 개발자와의 설계 결정 감소. | 개발자에게 더 많은 자유. |
| 10 | 프로젝트 편차 | 프로젝트 목표에서 덜 벗어남. | 개발자에게 주어진 자유로 인한 더 많은 편차. |
| 열한 | 코드베이스의 크기 | 더 큰 코드베이스 | 더 작은 코드베이스 |
| 12 | API 수 | 더 많은 API | 적은 API |
| 13 | 신청 유형 | 완전한 웹 애플리케이션 | 더 작은 애플리케이션 / 마이크로 서비스 |
| 14 | RESTful 애플리케이션 | RESTful 애플리케이션을위한 Django REST 프레임 워크. | RESTful 애플리케이션에 다음 확장을 사용하십시오. 플라스크 휴식 플라스크 -RESTX 로그인 |
| 열 다섯 | 공연 | 요청 수가 많으면 성능이 저하됩니다. | 전체적으로 일관된 성능. |
| 16 | 오픈 소스 기여 | 더 많은 포크, 시계 및 커밋. | 더 적은 수의 포크, 시계 및 커밋. |
| 17 | 개발자 | 숙련 된 개발자가 필요하며 쉽게 채용 할 수 없습니다. | 대부분의 개발자는 경험이 적고 적절한 수로 발견됩니다. |
플라스크 대 노드
웹 개발 스택과 관련하여 웹 개발에는 다양한 기술의 융합이 필요하다는 것이 밝혀졌습니다. 웹 애플리케이션을 프런트 엔드와 백엔드로 분리해야합니다. 애플리케이션의 프런트 엔드 부분은 JavaScript, HTML 및 CSS와 같은 브라우저에서 실행되는 기술에서 가장 잘 개발되었습니다.
일반적으로 백엔드는 서버 측에 적합한 언어로 개발되며 필요한 경우 기본 운영 체제, 연결된 데이터베이스 또는 네트워크와 상호 작용할 수 있습니다.
그러나 NodeJS라는 JavaScript 기반 프레임 워크는 위에 제시된보기를 변경하고 개발자가 웹 애플리케이션의 프런트 엔드 및 백 엔드 개발에서 일관성과 균일 성을 가질 수 있도록했습니다. 개발자는 JavaScript를 사용하여 백엔드 용으로 개발할 수 있습니다.
이 Flask vs Node 섹션에서는 Python 프로그래밍 언어 기반 프레임 워크 인 Flask와 아키텍처, 속도, 커뮤니티 지원 등과 같은 다양한 기준에서 Chrome의 자바 스크립트 런타임을 기반으로하는 Node를 비교합니다.
| # | 기준 | 플라스크 | 마디 |
|---|---|---|---|
| 7 | 디버깅 | 종속성없이 Python 디버거를 사용하여 더 쉽게 디버깅 할 수 있습니다. | 더 많은 노력이 필요합니다. Bluebird / Promise Library를 사용하는 개발 IDE로 더 쉽게. |
| 1 | 언어 런타임 | 파이썬 | Chrome의 V8 자바 스크립트 엔진 |
| 두 | 건축물 | 비 차단 I / O를 사용하려면 gunicorn과 같은 비 차단 웹 서버를 사용해야합니다. Microframework (백엔드) 카테고리. | 비 차단 I / O를 고유하게 제공합니다. 풀 스택 카테고리 |
| 삼 | 패키지 관리자 | 씨 | 해발 |
| 4 | 속도 | 별도의 Python 인터프리터로 인해 더 느립니다. | Just-In-Time 컴파일러로 인해 더 빠릅니다. |
| 5 | 오픈 소스 | 예 | 예 |
| 6 | 커뮤니티 지원 | Github에서 2.3 K 시계 51.4K 별 13.7 K 포크 | Github에서 2.9 K 시계 71.9 K 별 17.6 K 포크 |
| 8 | 유지 | 낮은 유지 보수 | 높은 유지 관리 |
| 9 | 실시간 애플리케이션 | 본질적으로 적합하지 않습니다. 그러나 실시간 사용 사례를 위해 socket.io와 함께 작동 할 수 있습니다. Flask-socketio 확장을 사용합니다. | 이벤트 중심 아키텍처 및 스트리밍 모듈로 인해 적합합니다. 본질적으로 비동기 적입니다. |
| 10 | 도서관 | 더 성숙하고 안정적입니다. | 덜 성숙하고 안정적이지만 활발한 개발 및 수정 릴리스 내에 있습니다. |
| 열한 | 코드 품질 | 백엔드 용으로 만 생성됩니다. | 새로운 프런트 엔드 개발자가 백엔드로 전환하기 때문에 때때로 손상됩니다. |
| 12 | 개발자 팀 구성 | 팀은 일반적으로 백엔드 개발자와 프런트 엔드 개발자로 구성됩니다. 우려 사항은 별개입니다. | 개발자는 역할을 교환하고 프런트 엔드와 백 엔드 모두에 대해 작업 할 수 있습니다. |
| 13 | 기존 시스템 및 애플리케이션과 통합 | 머신 러닝 및 빅 데이터 애플리케이션을위한 Python 에코 시스템을 사용하여 기존의 다른 기존 백엔드 애플리케이션과 더 쉽게 통합 할 수 있습니다. | 상당히 새롭고 다른 기존 응용 프로그램과의 통합을 위해 사용자 지정 또는 새 라이브러리를 만들어야합니다. |
자주 묻는 질문
Q # 1) Django 또는 Flask 중에서 무엇을 먼저 배워야합니까?
대답: 먼저 Flask를 사용하는 것이 좋습니다. 웹 개발에 대한 약간의 경험을 쌓으면 Django를 사용할 수 있습니다. Django는 웹 애플리케이션의 작동 방식을 이미 알고 있고 대부분의 기능을 자체적으로 처리한다고 가정합니다.
Q # 2) Flask 또는 Django가 더 나은가요?
대답: Flask와 Django는 모두 우수하고 목적에 적합합니다. Django는 더 눈에 띄는 엔터프라이즈 급 애플리케이션을 만드는 데 사용됩니다. Flask는 정적이고 작은 응용 프로그램을 만드는 데 사용됩니다. 플라스크는 프로토 타이핑에도 적합합니다. 그러나 Flask 확장을 사용하면 대규모 애플리케이션도 만들 수 있습니다.
Q # 3) 어떤 회사에서 Flask를 사용합니까?
mockito를 사용하여 비공개 메서드를 테스트하는 방법
대답: Flask를 사용하는 회사 중 일부는 Reddit, Mailgun, Netflix, Airbnb 등입니다.
Q # 4) Django를 사용하는 사이트는 무엇입니까?
대답: Django를 사용하는 사이트 중 일부는 Instagram, Spotify, YouTube, Dropbox, Bitbucket, Eventbrite 등입니다.
결론
우리는 오랫동안 하나의 프레임 워크에 집착해서는 안됩니다. 우리는 새로운 기술 세트를 배우고 트렌드 스택을 채택 할 준비가되어 있어야합니다. 우리 중 일부는 상대적으로 즉시 사용 가능한 배터리 포함 방식, 엄격한 릴리스주기, 더 엄격한 하위 호환성 유지 등을 원합니다.
이 그룹에 더 속한다고 생각한다면 Django를 선택해야합니다. 그러나 Flask 프레임 워크의 새로운 기능과 유연성을 따라가는 것도 놀랍습니다. 프런트 엔드와 백엔드 간의 일관성을 유지하려면 NodeJS와 같은 풀 스택 프레임 워크를 선택할 수 있습니다.
프레임 워크를 사용하는 것은 우리가 해결하려는 상황과 문제에 따라 달라지는 선택입니다. 프레임 워크를 선택하는 것은 항상 어렵습니다. 이 튜토리얼에서 필수 검토 사항을 제시하고 하나의 프레임 워크를 완성하는 데 도움이되기를 바랍니다. 그러나 두 프레임 워크를 모두 배우는 것이 좋습니다.
Flask로 시작한 다음 웹 개발 경험을 쌓은 후 Django로 이동하는 것이 더 쉽습니다. 어떤 이유로 개발 작업에 JavaScript 사용이 필요한 경우 NodeJS를 계속 사용할 수 있습니다.
추천 도서
- Python Django 튜토리얼-Django 시작하기
- 웹 애플리케이션을위한 플라스크 디자인 패턴 및 모범 사례
- Flask 템플릿, 양식,보기 및 리디렉션 예제
- 답변이있는 인기있는 Python Flask 인터뷰 질문 31 가지
- Node.js 테스트 프레임 워크 설정 방법 : Node.js 자습서
- TestNG 튜토리얼 : TestNG 프레임 워크 소개
- 예제가있는 셀레늄의 키워드 기반 프레임 워크
- 로봇 프레임 워크 튜토리얼-기능 및 소프트웨어 설치