diff --git a/docs/hi/docs/alternatives.md b/docs/hi/docs/alternatives.md
new file mode 100644
index 000000000..2f8f18dce
--- /dev/null
+++ b/docs/hi/docs/alternatives.md
@@ -0,0 +1,485 @@
+# विकल्प, प्रेरणा और तुलनाएँ { #alternatives-inspiration-and-comparisons }
+
+**FastAPI** को किसने प्रेरित किया, यह विकल्पों की तुलना में कैसा है और इसने उनसे क्या सीखा।
+
+## परिचय { #intro }
+
+**FastAPI** दूसरों के पिछले काम के बिना अस्तित्व में नहीं आता।
+
+पहले कई टूल्स बनाए गए हैं जिन्होंने इसके निर्माण को प्रेरित करने में मदद की।
+
+मैं कई वर्षों तक एक नया framework बनाने से बचता रहा। पहले मैंने **FastAPI** द्वारा कवर किए गए सभी features को कई अलग-अलग frameworks, plug-ins और tools का उपयोग करके हल करने की कोशिश की।
+
+लेकिन किसी बिंदु पर, ऐसा कुछ बनाने के अलावा कोई विकल्प नहीं बचा जो ये सभी features प्रदान करे, पिछले tools से सर्वश्रेष्ठ ideas ले और उन्हें सबसे अच्छे तरीके से जोड़े, उन language features का उपयोग करते हुए जो पहले उपलब्ध भी नहीं थे (Python 3.6+ type hints)।
+
+## पिछले टूल्स { #previous-tools }
+
+### [Django](https://www.djangoproject.com/) { #django }
+
+यह सबसे लोकप्रिय Python framework है और व्यापक रूप से भरोसेमंद है। इसका उपयोग Instagram जैसे systems बनाने के लिए किया जाता है।
+
+यह relational databases (जैसे MySQL या PostgreSQL) के साथ अपेक्षाकृत tightly coupled है, इसलिए, मुख्य store engine के रूप में NoSQL database (जैसे Couchbase, MongoDB, Cassandra, आदि) रखना बहुत आसान नहीं है।
+
+इसे backend में HTML generate करने के लिए बनाया गया था, न कि modern frontend (जैसे React, Vue.js और Angular) या इसके साथ communicate करने वाले अन्य systems (जैसे IoT devices) द्वारा उपयोग की जाने वाली APIs बनाने के लिए।
+
+### [Django REST Framework](https://www.django-rest-framework.org/) { #django-rest-framework }
+
+Django REST Framework को Django के ऊपर Web APIs बनाने के लिए एक flexible toolkit के रूप में बनाया गया था, ताकि इसकी API capabilities को बेहतर किया जा सके।
+
+इसका उपयोग Mozilla, Red Hat और Eventbrite सहित कई companies करती हैं।
+
+यह **automatic API documentation** के शुरुआती उदाहरणों में से एक था, और यही विशेष रूप से उन पहले ideas में से एक था जिसने **FastAPI** की "खोज" को प्रेरित किया।
+
+/// note | नोट
+
+Django REST Framework को Tom Christie ने बनाया था। वही creator जिन्होंने Starlette और Uvicorn बनाए, जिन पर **FastAPI** आधारित है।
+
+///
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+एक automatic API documentation web user interface रखना।
+
+///
+
+### [Flask](https://flask.palletsprojects.com) { #flask }
+
+Flask एक "microframework" है, इसमें database integrations या Django में default रूप से आने वाली कई चीजें शामिल नहीं हैं।
+
+यह simplicity और flexibility मुख्य data storage system के रूप में NoSQL databases का उपयोग करने जैसी चीजें करने की अनुमति देती है।
+
+क्योंकि यह बहुत सरल है, इसे सीखना अपेक्षाकृत intuitive है, हालांकि documentation कुछ जगहों पर थोड़ा technical हो जाता है।
+
+इसका सामान्य रूप से उन अन्य applications के लिए भी उपयोग किया जाता है जिन्हें जरूरी नहीं कि database, user management, या Django में pre-built आने वाले कई features में से किसी की आवश्यकता हो। हालांकि इनमें से कई features plug-ins के साथ जोड़े जा सकते हैं।
+
+Parts का यह decoupling, और एक ऐसा "microframework" होना जिसे बिल्कुल जरूरत के अनुसार extend किया जा सके, एक key feature था जिसे मैं बनाए रखना चाहता था।
+
+Flask की simplicity को देखते हुए, यह APIs बनाने के लिए एक अच्छा match लगा। अगली चीज़ जो ढूंढनी थी वह Flask के लिए एक "Django REST Framework" था।
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+एक micro-framework होना। जरूरत के tools और parts को mix and match करना आसान बनाना।
+
+एक simple और उपयोग में आसान routing system रखना।
+
+///
+
+### [Requests](https://requests.readthedocs.io) { #requests }
+
+**FastAPI** वास्तव में **Requests** का विकल्प नहीं है। उनका scope बहुत अलग है।
+
+वास्तव में FastAPI application के *अंदर* Requests का उपयोग करना आम बात होगी।
+
+फिर भी, FastAPI ने Requests से काफी प्रेरणा ली।
+
+**Requests** APIs के साथ *interact* करने (client के रूप में) के लिए एक library है, जबकि **FastAPI** APIs *build* करने (server के रूप में) के लिए एक library है।
+
+वे कमोबेश विपरीत छोरों पर हैं, एक-दूसरे को complement करते हुए।
+
+Requests का design बहुत simple और intuitive है, sensible defaults के साथ इसका उपयोग बहुत आसान है। लेकिन साथ ही, यह बहुत powerful और customizable है।
+
+इसीलिए, जैसा कि official website में कहा गया है:
+
+> Requests is one of the most downloaded Python packages of all time
+
+आप इसका उपयोग जिस तरह करते हैं वह बहुत सरल है। उदाहरण के लिए, `GET` request करने के लिए, आप लिखेंगे:
+
+```Python
+response = requests.get("http://example.com/some/url")
+```
+
+FastAPI counterpart API *path operation* कुछ इस तरह दिख सकता है:
+
+```Python hl_lines="1"
+@app.get("/some/url")
+def read_url():
+ return {"message": "Hello World"}
+```
+
+`requests.get(...)` और `@app.get(...)` में समानताएँ देखें।
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+* एक simple और intuitive API रखना।
+* HTTP method names (operations) को सीधे, सरल और intuitive तरीके से उपयोग करना।
+* Sensible defaults रखना, लेकिन powerful customizations के साथ।
+
+///
+
+### [Swagger](https://swagger.io/) / [OpenAPI](https://github.com/OAI/OpenAPI-Specification/) { #swagger-openapi }
+
+Django REST Framework से मुझे जो मुख्य feature चाहिए था वह automatic API documentation था।
+
+फिर मुझे पता चला कि APIs को document करने के लिए एक standard था, JSON (या YAML, जो JSON का extension है) का उपयोग करते हुए, जिसे Swagger कहा जाता था।
+
+और Swagger APIs के लिए एक web user interface पहले से बनाया हुआ था। इसलिए, किसी API के लिए Swagger documentation generate कर पाना इस web user interface को automatically उपयोग करने की अनुमति देता।
+
+किसी समय, Swagger को Linux Foundation को दे दिया गया, ताकि इसका नाम OpenAPI रखा जाए।
+
+इसीलिए version 2.0 के बारे में बात करते समय "Swagger" कहना आम है, और version 3+ के लिए "OpenAPI"।
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+Custom schema के बजाय API specifications के लिए एक open standard अपनाना और उपयोग करना।
+
+और standards-based user interface tools को integrate करना:
+
+* [Swagger UI](https://github.com/swagger-api/swagger-ui)
+* [ReDoc](https://github.com/Rebilly/ReDoc)
+
+इन दोनों को इसलिए चुना गया क्योंकि ये काफी popular और stable थे, लेकिन एक quick search करके, आप OpenAPI के लिए दर्जनों alternative user interfaces पा सकते हैं (जिन्हें आप **FastAPI** के साथ उपयोग कर सकते हैं)।
+
+///
+
+### Flask REST frameworks { #flask-rest-frameworks }
+
+कई Flask REST frameworks हैं, लेकिन उन्हें investigate करने में समय और काम लगाने के बाद, मैंने पाया कि कई discontinued या abandoned हैं, जिनमें कई pending issues थे जो उन्हें अनुपयुक्त बनाते थे।
+
+### [Marshmallow](https://marshmallow.readthedocs.io/en/stable/) { #marshmallow }
+
+API systems के लिए आवश्यक मुख्य features में से एक data "serialization" है, जो code (Python) से data लेकर उसे ऐसी चीज़ में convert करता है जिसे network के माध्यम से भेजा जा सके। उदाहरण के लिए, database से data रखने वाले object को JSON object में convert करना। `datetime` objects को strings में convert करना, आदि।
+
+APIs के लिए आवश्यक एक और बड़ा feature data validation है, यह सुनिश्चित करना कि data कुछ parameters के अनुसार valid है। उदाहरण के लिए, कोई field `int` है, न कि कोई random string। यह incoming data के लिए विशेष रूप से उपयोगी है।
+
+Data validation system के बिना, आपको code में सभी checks हाथ से करने पड़ेंगे।
+
+ये features वही हैं जिन्हें प्रदान करने के लिए Marshmallow बनाया गया था। यह एक बेहतरीन library है, और मैंने पहले इसका बहुत उपयोग किया है।
+
+लेकिन इसे Python type hints के अस्तित्व में आने से पहले बनाया गया था। इसलिए, हर schema define करने के लिए आपको Marshmallow द्वारा प्रदान किए गए specific utils और classes का उपयोग करना पड़ता है।
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+"schemas" define करने के लिए code का उपयोग करना, जो data types और validation automatically प्रदान करते हैं।
+
+///
+
+### [Webargs](https://webargs.readthedocs.io/en/latest/) { #webargs }
+
+APIs के लिए आवश्यक एक और बड़ा feature incoming requests से data की parsing है।
+
+Webargs एक tool है जिसे Flask सहित कई frameworks के ऊपर यह प्रदान करने के लिए बनाया गया था।
+
+यह data validation करने के लिए अंदर से Marshmallow का उपयोग करता है। और इसे उन्हीं developers ने बनाया था।
+
+यह एक बेहतरीन tool है और **FastAPI** से पहले मैंने इसका भी बहुत उपयोग किया है।
+
+/// note | नोट
+
+Webargs को उन्हीं Marshmallow developers ने बनाया था।
+
+///
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+Incoming request data का automatic validation रखना।
+
+///
+
+### [APISpec](https://apispec.readthedocs.io/en/stable/) { #apispec }
+
+Marshmallow और Webargs validation, parsing और serialization को plug-ins के रूप में प्रदान करते हैं।
+
+लेकिन documentation अभी भी missing है। फिर APISpec बनाया गया।
+
+यह कई frameworks के लिए एक plug-in है (और Starlette के लिए भी एक plug-in है)।
+
+यह जिस तरह काम करता है वह यह है कि आप route handle करने वाली प्रत्येक function के docstring के अंदर YAML format का उपयोग करके schema की definition लिखते हैं।
+
+और यह OpenAPI schemas generate करता है।
+
+Flask, Starlette, Responder, आदि में यह इसी तरह काम करता है।
+
+लेकिन फिर, हमारे पास फिर से Python string (एक बड़ा YAML) के अंदर micro-syntax होने की समस्या आती है।
+
+Editor इसमें ज्यादा मदद नहीं कर सकता। और अगर हम parameters या Marshmallow schemas को modify करते हैं और उस YAML docstring को भी modify करना भूल जाते हैं, तो generated schema obsolete हो जाएगा।
+
+/// note | नोट
+
+APISpec को उन्हीं Marshmallow developers ने बनाया था।
+
+///
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+APIs के लिए open standard, OpenAPI को support करना।
+
+///
+
+### [Flask-apispec](https://flask-apispec.readthedocs.io/en/latest/) { #flask-apispec }
+
+यह एक Flask plug-in है, जो Webargs, Marshmallow और APISpec को साथ जोड़ता है।
+
+यह APISpec का उपयोग करके, Webargs और Marshmallow की जानकारी से automatically OpenAPI schemas generate करता है।
+
+यह एक बेहतरीन tool है, बहुत underrated। यह मौजूद कई Flask plug-ins से कहीं अधिक popular होना चाहिए। शायद इसका कारण इसकी documentation का बहुत concise और abstract होना है।
+
+इसने Python docstrings के अंदर YAML (एक और syntax) लिखने की जरूरत को हल कर दिया।
+
+Flask, Flask-apispec के साथ Marshmallow और Webargs का यह combination **FastAPI** बनाने तक मेरा favorite backend stack था।
+
+इसका उपयोग करने से कई Flask full-stack generators बने। ये मुख्य stacks हैं जिनका मैं (और कई external teams) अब तक उपयोग करते रहे हैं:
+
+* [https://github.com/tiangolo/full-stack](https://github.com/tiangolo/full-stack)
+* [https://github.com/tiangolo/full-stack-flask-couchbase](https://github.com/tiangolo/full-stack-flask-couchbase)
+* [https://github.com/tiangolo/full-stack-flask-couchdb](https://github.com/tiangolo/full-stack-flask-couchdb)
+
+और यही full-stack generators [**FastAPI** Project Generators](project-generation.md) का आधार थे।
+
+/// note | नोट
+
+Flask-apispec को उन्हीं Marshmallow developers ने बनाया था।
+
+///
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+OpenAPI schema को automatically generate करना, उसी code से जो serialization और validation define करता है।
+
+///
+
+### [NestJS](https://nestjs.com/) (और [Angular](https://angular.io/)) { #nestjs-and-angular }
+
+यह Python भी नहीं है, NestJS एक JavaScript (TypeScript) NodeJS framework है जो Angular से inspired है।
+
+यह कुछ हद तक वही हासिल करता है जो Flask-apispec के साथ किया जा सकता है।
+
+इसमें Angular 2 से inspired एक integrated dependency injection system है। इसके लिए "injectables" (मेरी जानकारी के सभी अन्य dependency injection systems की तरह) को pre-register करना आवश्यक है, इसलिए यह verbosity और code repetition बढ़ाता है।
+
+क्योंकि parameters को TypeScript types (Python type hints के समान) के साथ describe किया जाता है, editor support काफी अच्छा है।
+
+लेकिन क्योंकि TypeScript data JavaScript में compilation के बाद preserved नहीं रहता, यह validation, serialization और documentation को एक साथ define करने के लिए types पर भरोसा नहीं कर सकता। इसके कारण और कुछ design decisions के कारण, validation, serialization और automatic schema generation पाने के लिए, कई जगह decorators जोड़ना आवश्यक होता है। इसलिए, यह काफी verbose हो जाता है।
+
+यह nested models को बहुत अच्छी तरह handle नहीं कर सकता। इसलिए, अगर request में JSON body एक JSON object है जिसमें inner fields हैं जो बदले में nested JSON objects हैं, तो उसे properly documented और validated नहीं किया जा सकता।
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+बेहतरीन editor support के लिए Python types का उपयोग करना।
+
+एक powerful dependency injection system रखना। Code repetition को minimize करने का तरीका खोजना।
+
+///
+
+### [Sanic](https://sanic.readthedocs.io/en/latest/) { #sanic }
+
+यह `asyncio` पर आधारित पहले बेहद तेज़ Python frameworks में से एक था। इसे Flask के बहुत समान बनाने के लिए बनाया गया था।
+
+/// note | तकनीकी विवरण
+
+इसने default Python `asyncio` loop के बजाय [`uvloop`](https://github.com/MagicStack/uvloop) का उपयोग किया। यही इसे इतना तेज़ बनाता था।
+
+इसने स्पष्ट रूप से Uvicorn और Starlette को प्रेरित किया, जो वर्तमान में open benchmarks में Sanic से तेज़ हैं।
+
+///
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+बेहद शानदार performance पाने का तरीका खोजना।
+
+इसीलिए **FastAPI** Starlette पर आधारित है, क्योंकि यह उपलब्ध सबसे तेज़ framework है (third-party benchmarks द्वारा tested)।
+
+///
+
+### [Falcon](https://falconframework.org/) { #falcon }
+
+Falcon एक और high performance Python framework है, इसे minimal होने और Hug जैसे अन्य frameworks की foundation के रूप में काम करने के लिए design किया गया है।
+
+इसे ऐसी functions रखने के लिए design किया गया है जो दो parameters receive करती हैं, एक "request" और एक "response"। फिर आप request से parts "read" करते हैं, और response में parts "write" करते हैं। इस design के कारण, standard Python type hints के साथ function parameters के रूप में request parameters और bodies declare करना संभव नहीं है।
+
+इसलिए, data validation, serialization और documentation को code में करना पड़ता है, automatically नहीं। या उन्हें Falcon के ऊपर Hug जैसे framework के रूप में implement करना पड़ता है। यही distinction Falcon के design से inspired अन्य frameworks में भी होता है, जिसमें parameters के रूप में एक request object और एक response object होता है।
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+बेहतरीन performance पाने के तरीके खोजना।
+
+Hug के साथ (क्योंकि Hug Falcon पर आधारित है) इसने **FastAPI** को functions में `response` parameter declare करने के लिए प्रेरित किया।
+
+हालांकि FastAPI में यह optional है, और मुख्य रूप से headers, cookies और alternative status codes set करने के लिए उपयोग किया जाता है।
+
+///
+
+### [Molten](https://moltenframework.com/) { #molten }
+
+मैंने **FastAPI** बनाने के शुरुआती stages में Molten खोजा। और इसमें काफी similar ideas हैं:
+
+* Python type hints पर आधारित।
+* इन types से validation और documentation।
+* Dependency Injection system।
+
+यह Pydantic जैसी data validation, serialization और documentation third-party library का उपयोग नहीं करता, इसकी अपनी है। इसलिए, ये data type definitions उतनी आसानी से reusable नहीं होंगी।
+
+इसके लिए थोड़ी अधिक verbose configurations की आवश्यकता होती है। और क्योंकि यह WSGI (ASGI के बजाय) पर आधारित है, इसे Uvicorn, Starlette और Sanic जैसे tools द्वारा प्रदान की जाने वाली high performance का लाभ उठाने के लिए design नहीं किया गया है।
+
+Dependency injection system dependencies की pre-registration की मांग करता है और dependencies declared types के आधार पर solve की जाती हैं। इसलिए, एक निश्चित type प्रदान करने वाले एक से अधिक "component" declare करना संभव नहीं है।
+
+Routes को एक single place में declare किया जाता है, उन functions का उपयोग करते हुए जो अन्य places में declared होती हैं (decorators का उपयोग करने के बजाय जिन्हें endpoint handle करने वाली function के ठीक ऊपर रखा जा सकता है)। यह Flask (और Starlette) के तरीके की तुलना में Django के तरीके के अधिक करीब है। यह code में उन चीज़ों को अलग करता है जो अपेक्षाकृत tightly coupled हैं।
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+Model attributes के "default" value का उपयोग करके data types के लिए extra validations define करना। इससे editor support बेहतर होता है, और यह पहले Pydantic में उपलब्ध नहीं था।
+
+इसने वास्तव में Pydantic के parts को update करने के लिए प्रेरित किया, ताकि वही validation declaration style support की जा सके (यह सारी functionality अब पहले से ही Pydantic में उपलब्ध है)।
+
+///
+
+### [Hug](https://github.com/hugapi/hug) { #hug }
+
+Hug उन पहले frameworks में से एक था जिसने Python type hints का उपयोग करके API parameter types की declaration implement की। यह एक बेहतरीन idea था जिसने अन्य tools को भी ऐसा करने के लिए प्रेरित किया।
+
+इसने अपनी declarations में standard Python types के बजाय custom types का उपयोग किया, लेकिन यह फिर भी एक बहुत बड़ा कदम था।
+
+यह JSON में पूरी API declare करने वाला custom schema generate करने वाले पहले frameworks में से भी एक था।
+
+यह OpenAPI और JSON Schema जैसे standard पर आधारित नहीं था। इसलिए इसे Swagger UI जैसे अन्य tools के साथ integrate करना straightforward नहीं होता। लेकिन फिर भी, यह एक बहुत innovative idea था।
+
+इसमें एक interesting, uncommon feature है: उसी framework का उपयोग करके APIs और CLIs भी बनाना संभव है।
+
+क्योंकि यह synchronous Python web frameworks (WSGI) के पिछले standard पर आधारित है, यह Websockets और अन्य चीज़ों को handle नहीं कर सकता, हालांकि इसका performance भी high है।
+
+/// note | नोट
+
+Hug को Timothy Crosley ने बनाया था, जो [`isort`](https://github.com/timothycrosley/isort) के भी creator हैं, Python files में imports को automatically sort करने का एक बेहतरीन tool।
+
+///
+
+/// tip | **FastAPI** को प्रेरित करने वाले ideas
+
+Hug ने APIStar के parts को प्रेरित किया, और APIStar के साथ-साथ यह उन tools में से एक था जो मुझे सबसे promising लगे।
+
+Hug ने **FastAPI** को parameters declare करने के लिए Python type hints का उपयोग करने, और API को automatically define करने वाला schema generate करने के लिए प्रेरित करने में मदद की।
+
+Hug ने **FastAPI** को headers और cookies set करने के लिए functions में `response` parameter declare करने के लिए प्रेरित किया।
+
+///
+
+### [APIStar](https://github.com/encode/apistar) (<= 0.5) { #apistar-0-5 }
+
+**FastAPI** बनाने का निर्णय लेने से ठीक पहले मुझे **APIStar** server मिला। इसमें लगभग वह सब कुछ था जिसकी मुझे तलाश थी और इसका design बेहतरीन था।
+
+यह उन पहले framework implementations में से एक था जिसे मैंने कभी देखा, जिसमें parameters और requests declare करने के लिए Python type hints का उपयोग किया गया था (NestJS और Molten से पहले)। मुझे यह लगभग Hug के साथ ही मिला। लेकिन APIStar ने OpenAPI standard का उपयोग किया।
+
+इसमें कई जगहों पर उन्हीं type hints के आधार पर automatic data validation, data serialization और OpenAPI schema generation था।
+
+Body schema definitions ने Pydantic जैसी Python type hints का उपयोग नहीं किया, यह Marshmallow के थोड़ा अधिक समान था, इसलिए, editor support उतना अच्छा नहीं होता, लेकिन फिर भी, APIStar सबसे अच्छा उपलब्ध विकल्प था।
+
+उस समय इसके performance benchmarks सबसे अच्छे थे (केवल Starlette से पीछे)।
+
+शुरुआत में, इसमें automatic API documentation web UI नहीं था, लेकिन मुझे पता था कि मैं इसमें Swagger UI जोड़ सकता हूँ।
+
+इसमें dependency injection system था। इसे ऊपर चर्चा किए गए अन्य tools की तरह components की pre-registration की आवश्यकता थी। लेकिन फिर भी, यह एक बेहतरीन feature था।
+
+मैं इसे कभी full project में उपयोग नहीं कर सका, क्योंकि इसमें security integration नहीं था, इसलिए, मैं Flask-apispec पर आधारित full-stack generators के साथ मिलने वाले सभी features को replace नहीं कर सकता था। मेरे projects backlog में वह functionality जोड़ने के लिए एक pull request बनाने का काम था।
+
+लेकिन फिर, project का focus बदल गया।
+
+यह अब API web framework नहीं रहा, क्योंकि creator को Starlette पर focus करने की आवश्यकता थी।
+
+अब APIStar OpenAPI specifications को validate करने के लिए tools का एक set है, web framework नहीं।
+
+/// note | नोट
+
+APIStar को Tom Christie ने बनाया था। वही व्यक्ति जिन्होंने बनाया:
+
+* Django REST Framework
+* Starlette (जिस पर **FastAPI** आधारित है)
+* Uvicorn (Starlette और **FastAPI** द्वारा उपयोग किया जाता है)
+
+///
+
+/// tip | **FastAPI** को यह करने के लिए प्रेरित किया
+
+अस्तित्व में आना।
+
+उसी Python types के साथ कई चीज़ें (data validation, serialization और documentation) declare करने का idea, जो साथ ही बेहतरीन editor support प्रदान करता था, मुझे एक शानदार idea लगा।
+
+और एक similar framework की लंबे समय तक खोज और कई अलग-अलग alternatives test करने के बाद, APIStar सबसे अच्छा उपलब्ध विकल्प था।
+
+फिर APIStar server के रूप में अस्तित्व में नहीं रहा और Starlette बनाया गया, और यह ऐसे system के लिए एक नई बेहतर foundation था। यही **FastAPI** बनाने की अंतिम प्रेरणा थी।
+
+मैं **FastAPI** को APIStar का "spiritual successor" मानता हूँ, जबकि features, typing system और अन्य parts को बेहतर और विस्तृत करता हूँ, इन सभी पिछले tools से मिली सीख के आधार पर।
+
+///
+
+## **FastAPI** द्वारा उपयोग किए गए { #used-by-fastapi }
+
+### [Pydantic](https://docs.pydantic.dev/) { #pydantic }
+
+Pydantic Python type hints के आधार पर data validation, serialization और documentation (JSON Schema का उपयोग करके) define करने के लिए एक library है।
+
+यह इसे बेहद intuitive बनाता है।
+
+यह Marshmallow से comparable है। हालांकि benchmarks में यह Marshmallow से तेज़ है। और क्योंकि यह उन्हीं Python type hints पर आधारित है, editor support बेहतरीन है।
+
+/// tip | **FastAPI** इसका उपयोग यह करने के लिए करता है
+
+सभी data validation, data serialization और automatic model documentation (JSON Schema पर आधारित) को handle करना।
+
+फिर **FastAPI** उस JSON Schema data को लेकर OpenAPI में डालता है, इसके द्वारा की जाने वाली बाकी सभी चीज़ों के अलावा।
+
+///
+
+### [Starlette](https://www.starlette.dev/) { #starlette }
+
+Starlette एक lightweight ASGI framework/toolkit है, जो high-performance asyncio services बनाने के लिए आदर्श है।
+
+यह बहुत simple और intuitive है। इसे आसानी से extensible होने और modular components रखने के लिए design किया गया है।
+
+इसमें है:
+
+* सचमुच प्रभावशाली performance।
+* WebSocket support।
+* In-process background tasks।
+* Startup और shutdown events।
+* HTTPX पर built test client।
+* CORS, GZip, Static Files, Streaming responses।
+* Session और Cookie support।
+* 100% test coverage।
+* 100% type annotated codebase।
+* कम hard dependencies।
+
+Starlette वर्तमान में tested सबसे तेज़ Python framework है। केवल Uvicorn इससे आगे है, जो framework नहीं, बल्कि server है।
+
+Starlette सभी basic web microframework functionality प्रदान करता है।
+
+लेकिन यह automatic data validation, serialization या documentation प्रदान नहीं करता।
+
+यही उन मुख्य चीज़ों में से एक है जो **FastAPI** ऊपर से जोड़ता है, सब Python type hints (Pydantic का उपयोग करके) पर आधारित। इसके साथ dependency injection system, security utilities, OpenAPI schema generation, आदि।
+
+/// note | तकनीकी विवरण
+
+ASGI एक नया "standard" है जिसे Django core team members द्वारा develop किया जा रहा है। यह अभी भी "Python standard" (एक PEP) नहीं है, हालांकि वे ऐसा करने की प्रक्रिया में हैं।
+
+फिर भी, इसे पहले से ही कई tools द्वारा "standard" के रूप में उपयोग किया जा रहा है। इससे interoperability बहुत बेहतर होती है, क्योंकि आप Uvicorn को किसी अन्य ASGI server (जैसे Daphne या Hypercorn) से बदल सकते हैं, या आप `python-socketio` जैसे ASGI compatible tools जोड़ सकते हैं।
+
+///
+
+/// tip | **FastAPI** इसका उपयोग यह करने के लिए करता है
+
+सभी core web parts को handle करना। ऊपर से features जोड़ना।
+
+Class `FastAPI` खुद सीधे class `Starlette` से inherit करती है।
+
+इसलिए, आप Starlette के साथ जो कुछ भी कर सकते हैं, आप उसे सीधे **FastAPI** के साथ कर सकते हैं, क्योंकि यह मूल रूप से steroids पर Starlette है।
+
+///
+
+### [Uvicorn](https://www.uvicorn.dev/) { #uvicorn }
+
+Uvicorn एक lightning-fast ASGI server है, जो uvloop और httptools पर built है।
+
+यह web framework नहीं, बल्कि server है। उदाहरण के लिए, यह paths द्वारा routing के लिए tools प्रदान नहीं करता। यह ऐसी चीज़ है जो Starlette (या **FastAPI**) जैसा framework ऊपर से प्रदान करेगा।
+
+यह Starlette और **FastAPI** के लिए recommended server है।
+
+/// tip | **FastAPI** इसे इस रूप में recommend करता है
+
+**FastAPI** applications चलाने के लिए main web server।
+
+आप asynchronous multi-process server पाने के लिए `--workers` command line option का भी उपयोग कर सकते हैं।
+
+अधिक विवरण [Deployment](deployment/index.md) section में देखें।
+
+///
+
+## Benchmarks और speed { #benchmarks-and-speed }
+
+Uvicorn, Starlette और FastAPI के बीच अंतर समझने, compare करने और देखने के लिए, [Benchmarks](benchmarks.md) के बारे में section देखें।
diff --git a/docs/hi/docs/async.md b/docs/hi/docs/async.md
new file mode 100644
index 000000000..ff599dddd
--- /dev/null
+++ b/docs/hi/docs/async.md
@@ -0,0 +1,444 @@
+# Concurrency और async / await { #concurrency-and-async-await }
+
+*path operation functions* के लिए `async def` syntax और asynchronous code, concurrency, और parallelism के बारे में कुछ पृष्ठभूमि का विवरण।
+
+## जल्दी में हैं? { #in-a-hurry }
+
+TL;DR:
+
+अगर आप third party libraries का उपयोग कर रहे हैं जो आपको उन्हें `await` के साथ call करने को कहती हैं, जैसे:
+
+```Python
+results = await some_library()
+```
+
+तो, अपनी *path operation functions* को `async def` के साथ declare करें, जैसे:
+
+```Python hl_lines="2"
+@app.get('/')
+async def read_results():
+ results = await some_library()
+ return results
+```
+
+/// note | नोट
+
+आप `await` का उपयोग केवल `async def` के साथ बनाए गए functions के अंदर कर सकते हैं।
+
+///
+
+---
+
+अगर आप ऐसी third party library का उपयोग कर रहे हैं जो किसी चीज़ (database, API, file system, आदि) से communicate करती है और `await` के उपयोग के लिए support नहीं रखती, (वर्तमान में अधिकांश database libraries के लिए यही स्थिति है), तो अपनी *path operation functions* को सामान्य रूप से, सिर्फ़ `def` के साथ declare करें, जैसे:
+
+```Python hl_lines="2"
+@app.get('/')
+def results():
+ results = some_library()
+ return results
+```
+
+---
+
+अगर आपके application को (किसी तरह) किसी और चीज़ से communicate करने और उसके response का इंतज़ार करने की ज़रूरत नहीं है, तो `async def` का उपयोग करें, भले ही आपको अंदर `await` का उपयोग करने की आवश्यकता न हो।
+
+---
+
+अगर आपको बस पता नहीं है, तो सामान्य `def` का उपयोग करें।
+
+---
+
+**नोट**: आप अपनी *path operation functions* में `def` और `async def` को जितनी ज़रूरत हो उतना mix कर सकते हैं और हर एक को अपने लिए सबसे अच्छे option से define कर सकते हैं। FastAPI उनके साथ सही काम करेगा।
+
+वैसे भी, ऊपर दिए गए किसी भी case में, FastAPI फिर भी asynchronously काम करेगा और बेहद तेज़ रहेगा।
+
+लेकिन ऊपर दिए गए steps follow करने से, वह कुछ performance optimizations कर पाएगा।
+
+## तकनीकी विवरण { #technical-details }
+
+Python के modern versions में **"asynchronous code"** के लिए support है, जिसमें **`async` और `await`** syntax के साथ **"coroutines"** नाम की चीज़ का उपयोग होता है।
+
+आइए नीचे के sections में इस phrase को हिस्सों में देखें:
+
+* **Asynchronous Code**
+* **`async` और `await`**
+* **Coroutines**
+
+## Asynchronous Code { #asynchronous-code }
+
+Asynchronous code का मतलब बस इतना है कि language 💬 के पास computer / program 🤖 को यह बताने का एक तरीका है कि code में किसी point पर, उसे 🤖 किसी और जगह पर *किसी और चीज़* के पूरा होने का इंतज़ार करना होगा। मान लीजिए कि वह *कोई और चीज़* "slow-file" 📝 कहलाती है।
+
+तो, उस समय के दौरान, computer कोई और काम कर सकता है, जबकि "slow-file" 📝 finish होती है।
+
+फिर computer / program 🤖 हर बार वापस आएगा जब उसके पास मौका होगा क्योंकि वह फिर से इंतज़ार कर रहा है, या जब भी वह 🤖 उस point पर अपने सारे काम finish कर लेगा। और वह 🤖 देखेगा कि जिन tasks का वह इंतज़ार कर रहा था उनमें से कोई पहले ही finish हो चुका है या नहीं, और जो भी करना था वह करेगा।
+
+इसके बाद, वह 🤖 finish होने वाला पहला task लेता है (मान लीजिए, हमारी "slow-file" 📝) और उसके साथ जो भी करना था उसे continue करता है।
+
+वह "किसी और चीज़ का इंतज़ार" आमतौर पर I/O operations को refer करता है जो अपेक्षाकृत "slow" होते हैं (processor और RAM memory की speed की तुलना में), जैसे इंतज़ार करना:
+
+* client से data network के ज़रिए भेजे जाने का
+* आपके program द्वारा भेजे गए data को client द्वारा network के ज़रिए receive किए जाने का
+* disk पर मौजूद file की contents को system द्वारा read करके आपके program को दिए जाने का
+* आपके program द्वारा system को दिए गए contents को disk पर लिखे जाने का
+* किसी remote API operation का
+* database operation के finish होने का
+* database query के results return करने का
+* आदि।
+
+क्योंकि execution time ज़्यादातर I/O operations का इंतज़ार करने में खर्च होता है, उन्हें "I/O bound" operations कहा जाता है।
+
+इसे "asynchronous" इसलिए कहा जाता है क्योंकि computer / program को slow task के साथ "synchronized" होने की ज़रूरत नहीं होती, यानी task finish होने के exact moment का इंतज़ार करते हुए कुछ न करना, ताकि task result लेकर काम continue कर सके।
+
+इसके बजाय, "asynchronous" system होने के कारण, task finish होने के बाद थोड़ी देर (कुछ microseconds) line में इंतज़ार कर सकता है ताकि computer / program जो भी करने गया था उसे finish करे, और फिर वापस आकर results ले और उनके साथ काम continue करे।
+
+"synchronous" ("asynchronous" के विपरीत) के लिए आमतौर पर "sequential" term भी use की जाती है, क्योंकि computer / program किसी दूसरे task पर switch करने से पहले सभी steps को sequence में follow करता है, भले ही उन steps में इंतज़ार शामिल हो।
+
+### Concurrency और Burgers { #concurrency-and-burgers }
+
+ऊपर describe किए गए **asynchronous** code के इस idea को कभी-कभी **"concurrency"** भी कहा जाता है। यह **"parallelism"** से अलग है।
+
+**Concurrency** और **parallelism** दोनों "अलग-अलग चीज़ें लगभग एक ही समय पर हो रही हैं" से संबंधित हैं।
+
+लेकिन *concurrency* और *parallelism* के बीच details काफ़ी अलग हैं।
+
+अंतर देखने के लिए, burgers के बारे में यह कहानी imagine करें:
+
+### Concurrent Burgers { #concurrent-burgers }
+
+आप अपने crush के साथ fast food लेने जाते हैं, आप line में खड़े होते हैं जबकि cashier आपके आगे लोगों के orders ले रहा होता है। 😍
+
+
+
+फिर आपकी बारी आती है, आप अपने crush और अपने लिए 2 बहुत fancy burgers का order देते हैं। 🍔🍔
+
+
+
+cashier kitchen में cook से कुछ कहता है ताकि उन्हें पता हो कि उन्हें आपके burgers prepare करने हैं (हालाँकि वे अभी previous clients के burgers prepare कर रहे हैं)।
+
+
+
+आप pay करते हैं। 💸
+
+cashier आपको आपकी बारी का number देता है।
+
+
+
+जब आप इंतज़ार कर रहे होते हैं, आप अपने crush के साथ एक table चुनते हैं, बैठते हैं और अपने crush से काफ़ी देर तक बात करते हैं (क्योंकि आपके burgers बहुत fancy हैं और उन्हें prepare होने में कुछ समय लगता है)।
+
+जब आप अपने crush के साथ table पर बैठे हैं, burgers का इंतज़ार करते हुए, आप वह समय यह admire करने में बिता सकते हैं कि आपका crush कितना awesome, cute और smart है ✨😍✨।
+
+
+
+इंतज़ार करते हुए और अपने crush से बात करते हुए, आप समय-समय पर counter पर displayed number check करते हैं कि क्या आपकी बारी आ चुकी है।
+
+फिर किसी point पर, आखिरकार आपकी बारी आ जाती है। आप counter पर जाते हैं, अपने burgers लेते हैं और table पर वापस आते हैं।
+
+
+
+आप और आपका crush burgers खाते हैं और अच्छा समय बिताते हैं। ✨
+
+
+
+/// note | नोट
+
+सुंदर illustrations [Ketrina Thompson](https://www.instagram.com/ketrinadrawsalot) द्वारा। 🎨
+
+///
+
+---
+
+Imagine करें कि उस कहानी में आप computer / program 🤖 हैं।
+
+जब आप line में होते हैं, आप बस idle 😴 होते हैं, अपनी बारी का इंतज़ार करते हुए, कोई बहुत "productive" काम नहीं कर रहे होते। लेकिन line तेज़ है क्योंकि cashier सिर्फ़ orders ले रहा है (उन्हें prepare नहीं कर रहा), इसलिए यह ठीक है।
+
+फिर, जब आपकी बारी आती है, आप actual "productive" काम करते हैं, menu process करते हैं, decide करते हैं कि क्या चाहिए, अपने crush की choice लेते हैं, pay करते हैं, check करते हैं कि आपने सही bill या card दिया है, check करते हैं कि आपको correctly charge किया गया है, check करते हैं कि order में सही items हैं, आदि।
+
+लेकिन फिर, भले ही आपके पास अभी burgers नहीं हैं, cashier के साथ आपका काम "on pause" ⏸ है, क्योंकि आपको अपने burgers ready होने का इंतज़ार 🕙 करना है।
+
+लेकिन जब आप counter से दूर जाकर अपनी बारी के number के साथ table पर बैठते हैं, तो आप अपना ध्यान 🔀 अपने crush पर switch कर सकते हैं, और उस पर "work" ⏯ 🤓 कर सकते हैं। फिर आप फिर से कुछ बहुत "productive" कर रहे होते हैं, जैसे अपने crush के साथ flirting 😍।
+
+फिर cashier 💁 आपके number को counter के display पर डालकर कहता है "मैंने burgers बना दिए हैं", लेकिन displayed number आपकी बारी के number में बदलते ही आप तुरंत पागलों की तरह jump नहीं करते। आप जानते हैं कि कोई आपके burgers steal नहीं करेगा क्योंकि आपके पास आपकी बारी का number है, और उनके पास उनका।
+
+तो आप अपने crush के story finish करने का इंतज़ार करते हैं (current work ⏯ / task being processed 🤓 finish करने का), हल्के से smile करते हैं और कहते हैं कि आप burgers लेने जा रहे हैं ⏸।
+
+फिर आप counter 🔀 पर जाते हैं, उस initial task पर जो अब finish हो चुका है ⏯, burgers उठाते हैं, thanks कहते हैं और उन्हें table पर ले जाते हैं। इससे counter के साथ interaction का वह step / task finish हो जाता है ⏹। बदले में, यह "burgers खाने" का एक नया task बनाता है 🔀 ⏯, लेकिन "burgers लेने" वाला previous task finish हो चुका है ⏹।
+
+### Parallel Burgers { #parallel-burgers }
+
+अब imagine करें कि ये "Concurrent Burgers" नहीं, बल्कि "Parallel Burgers" हैं।
+
+आप अपने crush के साथ parallel fast food लेने जाते हैं।
+
+आप line में खड़े होते हैं जबकि कई (मान लें 8) cashiers, जो उसी समय cooks भी हैं, आपके आगे लोगों के orders ले रहे होते हैं।
+
+आपसे पहले सभी लोग counter छोड़ने से पहले अपने burgers ready होने का इंतज़ार कर रहे हैं क्योंकि 8 cashiers में से हर एक next order लेने से पहले तुरंत जाकर burger prepare करता है।
+
+
+
+फिर आखिरकार आपकी बारी आती है, आप अपने crush और अपने लिए 2 बहुत fancy burgers का order देते हैं।
+
+आप pay करते हैं 💸।
+
+
+
+cashier kitchen में जाता है।
+
+आप counter के सामने खड़े होकर इंतज़ार करते हैं 🕙, ताकि आपके लेने से पहले कोई और आपके burgers न ले जाए, क्योंकि turns के लिए कोई numbers नहीं हैं।
+
+
+
+क्योंकि आप और आपका crush इस बात में busy हैं कि कोई आपके आगे न आ जाए और आपके burgers आते ही उन्हें न ले जाए, आप अपने crush पर ध्यान नहीं दे सकते। 😞
+
+यह "synchronous" work है, आप cashier/cook 👨🍳 के साथ "synchronized" हैं। आपको इंतज़ार 🕙 करना है और उस exact moment पर वहाँ होना है जब cashier/cook 👨🍳 burgers finish करके आपको देता है, नहीं तो कोई और उन्हें ले सकता है।
+
+
+
+फिर आपका cashier/cook 👨🍳 लंबे समय तक counter के सामने इंतज़ार 🕙 करने के बाद आखिरकार आपके burgers के साथ वापस आता है।
+
+
+
+आप अपने burgers लेते हैं और अपने crush के साथ table पर जाते हैं।
+
+आप बस उन्हें खाते हैं, और आपका काम हो जाता है। ⏹
+
+
+
+ज़्यादा बात या flirting नहीं हुई क्योंकि ज़्यादातर समय counter के सामने इंतज़ार 🕙 करने में चला गया। 😞
+
+/// note | नोट
+
+सुंदर illustrations [Ketrina Thompson](https://www.instagram.com/ketrinadrawsalot) द्वारा। 🎨
+
+///
+
+---
+
+parallel burgers के इस scenario में, आप दो processors (आप और आपका crush) वाला computer / program 🤖 हैं, दोनों इंतज़ार 🕙 कर रहे हैं और अपना ध्यान ⏯ लंबे समय तक "counter पर इंतज़ार" 🕙 करने में लगा रहे हैं।
+
+fast food store के पास 8 processors (cashiers/cooks) हैं। जबकि concurrent burgers store के पास शायद सिर्फ़ 2 (एक cashier और एक cook) रहे होंगे।
+
+लेकिन फिर भी, final experience सबसे अच्छा नहीं है। 😞
+
+---
+
+यह burgers के लिए parallel equivalent story होगी। 🍔
+
+इसका एक अधिक "real life" example देखने के लिए, एक bank imagine करें।
+
+हाल तक, अधिकांश banks में multiple cashiers 👨💼👨💼👨💼👨💼 और एक बड़ी line 🕙🕙🕙🕙🕙🕙🕙🕙 होती थी।
+
+सभी cashiers एक client के बाद दूसरे client के साथ पूरा काम करते थे 👨💼⏯।
+
+और आपको line में लंबे समय तक इंतज़ार 🕙 करना पड़ता है वरना आपकी बारी चली जाती है।
+
+आप शायद अपने crush 😍 को bank 🏦 में errands करने के लिए अपने साथ नहीं ले जाना चाहेंगे।
+
+### Burger Conclusion { #burger-conclusion }
+
+"अपने crush के साथ fast food burgers" के इस scenario में, क्योंकि बहुत इंतज़ार 🕙 है, concurrent system ⏸🔀⏯ रखना कहीं ज़्यादा meaningful है।
+
+अधिकांश web applications के लिए यही case है।
+
+बहुत सारे users, लेकिन आपका server उनके not-so-good connection से requests भेजने का इंतज़ार 🕙 कर रहा है।
+
+और फिर responses वापस आने का फिर से इंतज़ार 🕙 कर रहा है।
+
+यह "waiting" 🕙 microseconds में measure होती है, लेकिन फिर भी, सब मिलाकर अंत में यह बहुत सारा इंतज़ार बन जाता है।
+
+इसीलिए web APIs के लिए asynchronous ⏸🔀⏯ code use करना बहुत meaningful है।
+
+इसी तरह की asynchronicity ने NodeJS को popular बनाया (हालाँकि NodeJS parallel नहीं है) और यही Go की programming language के रूप में ताकत है।
+
+और यही performance level आपको **FastAPI** के साथ मिलता है।
+
+और क्योंकि आपके पास parallelism और asynchronicity एक ही समय में हो सकते हैं, आपको tested NodeJS frameworks में से अधिकांश से higher performance और Go के बराबर performance मिलती है, जो C के करीब एक compiled language है [(सब Starlette की बदौलत)](https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=query&l=zijmkf-1)।
+
+### क्या concurrency parallelism से बेहतर है? { #is-concurrency-better-than-parallelism }
+
+नहीं! यह कहानी की सीख नहीं है।
+
+Concurrency, parallelism से अलग है। और यह **specific** scenarios में बेहतर है जिनमें बहुत इंतज़ार शामिल होता है। इसी कारण, यह web application development के लिए आम तौर पर parallelism से काफ़ी बेहतर होती है। लेकिन हर चीज़ के लिए नहीं।
+
+तो, इसे balance करने के लिए, यह छोटी कहानी imagine करें:
+
+> आपको एक बड़ा, गंदा घर साफ़ करना है।
+
+*हाँ, यही पूरी कहानी है*।
+
+---
+
+कहीं भी कोई इंतज़ार 🕙 नहीं है, बस घर के कई places में बहुत सारा काम करना है।
+
+आप burgers example की तरह turns रख सकते हैं, पहले living room, फिर kitchen, लेकिन क्योंकि आप किसी भी चीज़ का इंतज़ार 🕙 नहीं कर रहे, बस सफ़ाई पर सफ़ाई कर रहे हैं, turns किसी चीज़ को affect नहीं करेंगे।
+
+Turns (concurrency) के साथ या बिना finish करने में उतना ही time लगेगा और आपने उतना ही work किया होगा।
+
+लेकिन इस case में, अगर आप उन 8 ex-cashier/cooks/now-cleaners को ला सकें, और उनमें से हर एक (आपके साथ) घर का एक zone clean करने के लिए ले सके, तो आप extra help के साथ सारा काम **parallel** में कर सकते हैं, और बहुत जल्दी finish कर सकते हैं।
+
+इस scenario में, cleaners में से हर एक (आप सहित) एक processor होगा, अपने हिस्से का job कर रहा होगा।
+
+और क्योंकि execution time का अधिकांश हिस्सा actual work में जाता है (इंतज़ार के बजाय), और computer में work एक CPU द्वारा किया जाता है, वे इन problems को "CPU bound" कहते हैं।
+
+---
+
+CPU bound operations के common examples ऐसी चीज़ें हैं जिन्हें complex math processing की आवश्यकता होती है।
+
+उदाहरण के लिए:
+
+* **Audio** या **image processing**।
+* **Computer vision**: एक image millions of pixels से बनी होती है, हर pixel में 3 values / colors होते हैं, इसे process करने के लिए आम तौर पर उन pixels पर कुछ compute करना पड़ता है, सब एक ही समय में।
+* **Machine Learning**: इसमें आम तौर पर बहुत सारे "matrix" और "vector" multiplications की आवश्यकता होती है। numbers वाली एक huge spreadsheet की कल्पना करें और उन सबको एक ही समय में आपस में multiply करें।
+* **Deep Learning**: यह Machine Learning का sub-field है, इसलिए वही लागू होता है। बस यह कि multiply करने के लिए numbers की एक single spreadsheet नहीं होती, बल्कि उनका एक huge set होता है, और कई cases में, आप उन models को build और / या use करने के लिए एक special processor use करते हैं।
+
+### Concurrency + Parallelism: Web + Machine Learning { #concurrency-parallelism-web-machine-learning }
+
+**FastAPI** के साथ आप concurrency का advantage ले सकते हैं जो web development में बहुत common है (NodeJS का वही main attraction)।
+
+लेकिन आप Machine Learning systems जैसे **CPU bound** workloads के लिए parallelism और multiprocessing (parallel में चलने वाले multiple processes) के benefits का भी उपयोग कर सकते हैं।
+
+यह, और साथ में यह simple fact कि Python **Data Science**, Machine Learning और खासकर Deep Learning के लिए main language है, FastAPI को Data Science / Machine Learning web APIs और applications (कई अन्य चीज़ों के बीच) के लिए बहुत अच्छा match बनाता है।
+
+Production में यह parallelism कैसे achieve करें, यह देखने के लिए [Deployment](deployment/index.md) वाला section देखें।
+
+## `async` और `await` { #async-and-await }
+
+Python के modern versions में asynchronous code define करने का बहुत intuitive तरीका है। इससे यह बिल्कुल normal "sequential" code जैसा दिखता है और सही moments पर आपके लिए "awaiting" करता है।
+
+जब कोई operation results देने से पहले इंतज़ार की आवश्यकता रखता है और इन नए Python features के लिए support रखता है, तो आप इसे इस तरह code कर सकते हैं:
+
+```Python
+burgers = await get_burgers(2)
+```
+
+यहाँ key `await` है। यह Python को बताता है कि उसे `burgers` में results store करने से पहले `get_burgers(2)` के अपना काम 🕙 finish करने का इंतज़ार ⏸ करना है। इससे, Python जान जाएगा कि इस बीच वह कुछ और 🔀 ⏯ कर सकता है (जैसे कोई और request receive करना)।
+
+`await` के काम करने के लिए, उसे ऐसे function के अंदर होना चाहिए जो इस asynchronicity को support करता हो। ऐसा करने के लिए, आप बस उसे `async def` के साथ declare करते हैं:
+
+```Python hl_lines="1"
+async def get_burgers(number: int):
+ # बर्गर बनाने के लिए कुछ asynchronous काम करें
+ return burgers
+```
+
+...`def` के बजाय:
+
+```Python hl_lines="2"
+# यह asynchronous नहीं है
+def get_sequential_burgers(number: int):
+ # बर्गर बनाने के लिए कुछ sequential काम करें
+ return burgers
+```
+
+`async def` के साथ, Python जानता है कि उस function के अंदर उसे `await` expressions के बारे में aware रहना है, और वह उस function की execution को "pause" ⏸ कर सकता है और वापस आने से पहले कुछ और 🔀 कर सकता है।
+
+जब आप किसी `async def` function को call करना चाहते हैं, तो आपको उसे "await" करना होगा। इसलिए, यह काम नहीं करेगा:
+
+```Python
+# यह काम नहीं करेगा, क्योंकि get_burgers को async def के साथ define किया गया था
+burgers = get_burgers(2)
+```
+
+---
+
+तो, अगर आप ऐसी library use कर रहे हैं जो कहती है कि आप उसे `await` के साथ call कर सकते हैं, तो आपको उसे use करने वाली *path operation functions* को `async def` के साथ create करना होगा, जैसे:
+
+```Python hl_lines="2-3"
+@app.get('/burgers')
+async def read_burgers():
+ burgers = await get_burgers(2)
+ return burgers
+```
+
+### अधिक तकनीकी विवरण { #more-technical-details }
+
+आपने notice किया होगा कि `await` का उपयोग केवल `async def` के साथ define किए गए functions के अंदर किया जा सकता है।
+
+लेकिन साथ ही, `async def` के साथ define किए गए functions को "awaited" होना पड़ता है। इसलिए, `async def` वाले functions को भी केवल `async def` के साथ define किए गए functions के अंदर call किया जा सकता है।
+
+तो, egg और chicken के बारे में, आप पहले `async` function को कैसे call करते हैं?
+
+अगर आप **FastAPI** के साथ काम कर रहे हैं तो आपको इसकी चिंता करने की ज़रूरत नहीं है, क्योंकि वह "first" function आपकी *path operation function* होगी, और FastAPI जानता होगा कि सही काम कैसे करना है।
+
+लेकिन अगर आप FastAPI के बिना `async` / `await` use करना चाहते हैं, तो आप ऐसा भी कर सकते हैं।
+
+### अपना async code लिखें { #write-your-own-async-code }
+
+Starlette (और **FastAPI**) [AnyIO](https://anyio.readthedocs.io/en/stable/) पर based हैं, जो इसे Python की standard library [asyncio](https://docs.python.org/3/library/asyncio-task.html) और [Trio](https://trio.readthedocs.io/en/stable/) दोनों के साथ compatible बनाता है।
+
+विशेष रूप से, आप अपने advanced concurrency use cases के लिए सीधे [AnyIO](https://anyio.readthedocs.io/en/stable/) use कर सकते हैं जिन्हें आपके अपने code में अधिक advanced patterns की आवश्यकता होती है।
+
+और अगर आप FastAPI use नहीं भी कर रहे थे, तो भी आप [AnyIO](https://anyio.readthedocs.io/en/stable/) के साथ अपने async applications लिख सकते थे ताकि वे highly compatible हों और उसके benefits (जैसे *structured concurrency*) मिलें।
+
+मैंने AnyIO के ऊपर एक और library बनाई, एक thin layer के रूप में, ताकि type annotations को थोड़ा improve किया जा सके और बेहतर **autocompletion**, **inline errors**, आदि मिल सकें। इसमें एक friendly introduction और tutorial भी है जो आपको **समझने** और **अपना async code** लिखने में मदद करता है: [Asyncer](https://asyncer.tiangolo.com/)। यह विशेष रूप से useful होगा अगर आपको **async code को regular** (blocking/synchronous) code के साथ **combine** करना हो।
+
+### asynchronous code के अन्य रूप { #other-forms-of-asynchronous-code }
+
+`async` और `await` use करने की यह style language में relatively new है।
+
+लेकिन यह asynchronous code के साथ काम करना बहुत आसान बना देती है।
+
+यही syntax (या लगभग identical) हाल ही में JavaScript के modern versions (Browser और NodeJS में) में भी शामिल किया गया था।
+
+लेकिन उससे पहले, asynchronous code handle करना काफ़ी अधिक complex और difficult था।
+
+Python के previous versions में, आप threads या [Gevent](https://www.gevent.org/) use कर सकते थे। लेकिन code को understand, debug, और reason about करना कहीं ज़्यादा complex है।
+
+NodeJS / Browser JavaScript के previous versions में, आप "callbacks" use करते। जो "callback hell" की ओर ले जाता है।
+
+## Coroutines { #coroutines }
+
+**Coroutine** बस उस चीज़ के लिए एक बहुत fancy term है जो `async def` function return करता है। Python जानता है कि यह function जैसी कोई चीज़ है, जिसे वह start कर सकता है और जो किसी point पर end होगी, लेकिन जब भी उसके अंदर कोई `await` होगा तो वह internally pause ⏸ भी हो सकती है।
+
+लेकिन `async` और `await` के साथ asynchronous code use करने की यह सारी functionality कई बार "coroutines" use करने के रूप में summarize की जाती है। यह Go की main key feature, "Goroutines", से comparable है।
+
+## निष्कर्ष { #conclusion }
+
+आइए ऊपर वाली वही phrase देखें:
+
+> Python के modern versions में **"asynchronous code"** के लिए support है, जिसमें **`async` और `await`** syntax के साथ **"coroutines"** नाम की चीज़ का उपयोग होता है।
+
+अब यह अधिक meaningful होना चाहिए। ✨
+
+यही सब FastAPI को power देता है (Starlette के through) और इसे इतनी impressive performance देता है।
+
+## बहुत तकनीकी विवरण { #very-technical-details }
+
+/// warning | चेतावनी
+
+आप शायद इसे skip कर सकते हैं।
+
+ये **FastAPI** के अंदरूनी काम करने के बहुत technical details हैं।
+
+अगर आपके पास काफ़ी technical knowledge है (coroutines, threads, blocking, आदि) और आप curious हैं कि FastAPI `async def` vs normal `def` को कैसे handle करता है, तो आगे बढ़ें।
+
+///
+
+### Path operation functions { #path-operation-functions }
+
+जब आप *path operation function* को `async def` के बजाय normal `def` के साथ declare करते हैं, तो उसे directly call करने के बजाय (क्योंकि वह server को block कर देगा), एक external threadpool में run किया जाता है जिसे फिर await किया जाता है।
+
+अगर आप किसी दूसरे async framework से आ रहे हैं जो ऊपर बताए गए तरीके से काम नहीं करता और आप trivial compute-only *path operation functions* को plain `def` के साथ define करने के आदी हैं ताकि थोड़ा performance gain (लगभग 100 nanoseconds) मिले, तो कृपया ध्यान दें कि **FastAPI** में effect काफ़ी उल्टा होगा। इन cases में, `async def` use करना बेहतर है जब तक कि आपकी *path operation functions* ऐसा code use न करें जो blocking I/O perform करता हो।
+
+फिर भी, दोनों situations में, संभावना है कि **FastAPI** आपके previous framework से [फिर भी तेज़ होगा](index.md#performance) (या कम से कम comparable होगा)।
+
+### Dependencies { #dependencies }
+
+[dependencies](tutorial/dependencies/index.md) के लिए भी यही लागू होता है। अगर कोई dependency `async def` के बजाय standard `def` function है, तो उसे external threadpool में run किया जाता है।
+
+### Sub-dependencies { #sub-dependencies }
+
+आपके पास multiple dependencies और [sub-dependencies](tutorial/dependencies/sub-dependencies.md) हो सकती हैं जो एक-दूसरे की आवश्यकता रखती हैं (function definitions के parameters के रूप में), उनमें से कुछ `async def` के साथ बनाई गई हो सकती हैं और कुछ normal `def` के साथ। यह फिर भी काम करेगा, और normal `def` के साथ बनाई गई ones को "awaited" किए जाने के बजाय external thread (threadpool से) पर call किया जाएगा।
+
+### अन्य utility functions { #other-utility-functions }
+
+कोई भी अन्य utility function जिसे आप directly call करते हैं, normal `def` या `async def` के साथ बनाया जा सकता है और FastAPI इस बात को affect नहीं करेगा कि आप उसे कैसे call करते हैं।
+
+यह उन functions के contrast में है जिन्हें FastAPI आपके लिए call करता है: *path operation functions* और dependencies।
+
+अगर आपका utility function `def` वाला normal function है, तो वह directly call होगा (जैसे आप अपने code में लिखते हैं), threadpool में नहीं; अगर function `async def` के साथ बनाया गया है तो आपको अपने code में उसे call करते समय उस function को `await` करना चाहिए।
+
+---
+
+फिर से, ये बहुत technical details हैं जो शायद useful हों अगर आप इन्हें खोजते हुए आए हों।
+
+अन्यथा, ऊपर के section की guidelines आपके लिए पर्याप्त होनी चाहिए: जल्दी में हैं?।
diff --git a/docs/hi/docs/benchmarks.md b/docs/hi/docs/benchmarks.md
new file mode 100644
index 000000000..14439efc1
--- /dev/null
+++ b/docs/hi/docs/benchmarks.md
@@ -0,0 +1,34 @@
+# बेंचमार्क { #benchmarks }
+
+स्वतंत्र TechEmpower बेंचमार्क दिखाते हैं कि Uvicorn के तहत चलने वाले **FastAPI** applications [उपलब्ध सबसे तेज़ Python frameworks में से एक](https://www.techempower.com/benchmarks/#section=test&runid=7464e520-0dc2-473d-bd34-dbdfd7e85911&hw=ph&test=query&l=zijzen-7) हैं, केवल Starlette और Uvicorn से नीचे (जिनका उपयोग FastAPI द्वारा अंदरूनी रूप से किया जाता है)।
+
+लेकिन बेंचमार्क और तुलनाएँ देखते समय आपको निम्न बातों को ध्यान में रखना चाहिए।
+
+## बेंचमार्क और गति { #benchmarks-and-speed }
+
+जब आप बेंचमार्क देखते हैं, तो अलग-अलग प्रकार के कई tools को समान मानकर तुलना होते देखना आम है।
+
+विशेष रूप से, Uvicorn, Starlette और FastAPI को साथ में तुलना होते देखना (कई अन्य tools के साथ)।
+
+tool जिस समस्या को जितना सरल हल करता है, उसे उतना ही बेहतर performance मिलेगा। और अधिकांश बेंचमार्क tool द्वारा प्रदान की गई अतिरिक्त features को test नहीं करते।
+
+Hierarchy कुछ इस तरह है:
+
+* **Uvicorn**: एक ASGI server
+ * **Starlette**: (Uvicorn का उपयोग करता है) एक web microframework
+ * **FastAPI**: (Starlette का उपयोग करता है) APIs बनाने के लिए कई अतिरिक्त features वाला एक API microframework, data validation आदि के साथ।
+
+* **Uvicorn**:
+ * इसका performance सबसे अच्छा होगा, क्योंकि इसमें server के अलावा बहुत ज़्यादा extra code नहीं है।
+ * आप सीधे Uvicorn में application नहीं लिखेंगे। इसका मतलब होगा कि आपके code में कमोबेश कम से कम वह सारा code शामिल करना पड़ेगा जो Starlette (या **FastAPI**) प्रदान करता है। और यदि आपने ऐसा किया, तो आपके अंतिम application में framework का उपयोग करने और अपने app code और bugs को कम करने जितना ही overhead होगा।
+ * यदि आप Uvicorn की तुलना कर रहे हैं, तो इसकी तुलना Daphne, Hypercorn, uWSGI आदि से करें। Application servers से।
+* **Starlette**:
+ * Uvicorn के बाद इसका performance अगला सबसे अच्छा होगा। वास्तव में, Starlette चलने के लिए Uvicorn का उपयोग करता है। इसलिए, संभवतः यह केवल अधिक code execute करने के कारण Uvicorn से "धीमा" हो सकता है।
+ * लेकिन यह आपको simple web applications बनाने के लिए tools प्रदान करता है, paths पर आधारित routing आदि के साथ।
+ * यदि आप Starlette की तुलना कर रहे हैं, तो इसकी तुलना Sanic, Flask, Django आदि से करें। Web frameworks (या microframeworks) से।
+* **FastAPI**:
+ * जिस तरह Starlette Uvicorn का उपयोग करता है और उससे तेज़ नहीं हो सकता, उसी तरह **FastAPI** Starlette का उपयोग करता है, इसलिए यह उससे तेज़ नहीं हो सकता।
+ * FastAPI, Starlette के ऊपर और अधिक features प्रदान करता है। ऐसे features जिनकी APIs बनाते समय आपको लगभग हमेशा आवश्यकता होती है, जैसे data validation और serialization। और इसका उपयोग करके, आपको automatic documentation मुफ़्त में मिलती है (automatic documentation running applications में overhead भी नहीं जोड़ती, यह startup पर generate होती है)।
+ * यदि आपने FastAPI का उपयोग नहीं किया और सीधे Starlette का उपयोग किया (या कोई अन्य tool, जैसे Sanic, Flask, Responder आदि), तो आपको सारा data validation और serialization स्वयं implement करना पड़ेगा। इसलिए, आपके अंतिम application में फिर भी उतना ही overhead होगा जितना FastAPI का उपयोग करके बनाए जाने पर होता। और कई मामलों में, यह data validation और serialization applications में लिखे गए code का सबसे बड़ा हिस्सा होता है।
+ * इसलिए, FastAPI का उपयोग करके आप development time, bugs, code की lines बचाते हैं, और संभवतः आपको वही performance (या बेहतर) मिलेगा जो इसे उपयोग न करने पर मिलता (क्योंकि आपको यह सब अपने code में implement करना पड़ता)।
+ * यदि आप FastAPI की तुलना कर रहे हैं, तो इसकी तुलना ऐसे web application framework (या tools के set) से करें जो data validation, serialization और documentation प्रदान करता हो, जैसे Flask-apispec, NestJS, Molten आदि। Integrated automatic data validation, serialization और documentation वाले frameworks से।
diff --git a/docs/hi/docs/editor-support.md b/docs/hi/docs/editor-support.md
new file mode 100644
index 000000000..a7898c015
--- /dev/null
+++ b/docs/hi/docs/editor-support.md
@@ -0,0 +1,23 @@
+# एडिटर समर्थन { #editor-support }
+
+आधिकारिक [FastAPI Extension](https://marketplace.visualstudio.com/items?itemName=FastAPILabs.fastapi-vscode) आपके FastAPI डेवलपमेंट workflow को *path operation* discovery, navigation, साथ ही FastAPI Cloud deployment और live log streaming के साथ बेहतर बनाता है।
+
+Extension के बारे में अधिक जानकारी के लिए, [GitHub repository](https://github.com/fastapi/fastapi-vscode) पर README देखें।
+
+## सेटअप और इंस्टॉलेशन { #setup-and-installation }
+
+**FastAPI Extension** [VS Code](https://code.visualstudio.com/) और [Cursor](https://www.cursor.com/) दोनों के लिए उपलब्ध है। इसे प्रत्येक एडिटर के Extensions panel से सीधे इंस्टॉल किया जा सकता है, "FastAPI" खोजकर और **FastAPI Labs** द्वारा प्रकाशित extension चुनकर। यह extension browser-based editors जैसे [vscode.dev](https://vscode.dev) और [github.dev](https://github.dev) में भी काम करता है।
+
+### एप्लिकेशन डिस्कवरी { #application-discovery }
+
+डिफ़ॉल्ट रूप से, extension आपके workspace में `FastAPI()` instantiate करने वाली files को scan करके FastAPI applications को अपने आप discover करेगा। यदि auto-detection आपके project structure के लिए काम नहीं करता, तो आप `pyproject.toml` में `[tool.fastapi]` के माध्यम से या module notation (जैसे `myapp.main:app`) का उपयोग करके `fastapi.entryPoint` VS Code setting में entrypoint निर्दिष्ट कर सकते हैं।
+
+## सुविधाएँ { #features }
+
+- **Path Operation Explorer** - आपके application में सभी *path operations* का sidebar tree view। किसी भी route या router definition पर जाने के लिए क्लिक करें।
+- **Route Search** - path, method, या name के आधार पर Ctrl + Shift + E (macOS पर: Cmd + Shift + E) से search करें।
+- **CodeLens Navigation** - test client calls (जैसे `client.get('/items')`) के ऊपर clickable links, जो tests और implementation के बीच तेज़ navigation के लिए matching *path operation* पर ले जाते हैं।
+- **Deploy to FastAPI Cloud** - अपनी app को [FastAPI Cloud](https://fastapicloud.com/) पर one-click deployment।
+- **Stream Application Logs** - level filtering और text search के साथ, आपकी FastAPI Cloud-deployed application से real-time log streaming।
+
+यदि आप extension की सुविधाओं से परिचित होना चाहते हैं, तो Command Palette (Ctrl + Shift + P या macOS पर: Cmd + Shift + P) खोलकर और "Welcome: Open walkthrough..." चुनकर, फिर "Get started with FastAPI" walkthrough चुनकर extension walkthrough देख सकते हैं।
diff --git a/docs/hi/docs/fastapi-cli.md b/docs/hi/docs/fastapi-cli.md
new file mode 100644
index 000000000..2ef05a68d
--- /dev/null
+++ b/docs/hi/docs/fastapi-cli.md
@@ -0,0 +1,134 @@
+# FastAPI CLI { #fastapi-cli }
+
+**FastAPI CLI** एक command line program है जिसका उपयोग आप अपनी FastAPI app को serve करने, अपने FastAPI project को manage करने, और भी बहुत कुछ करने के लिए कर सकते हैं।
+
+जब आप FastAPI install करते हैं (जैसे `pip install "fastapi[standard]"` के साथ), तो इसके साथ एक command line program आता है जिसे आप terminal में run कर सकते हैं।
+
+Development के लिए अपनी FastAPI app run करने के लिए, आप `fastapi dev` command का उपयोग कर सकते हैं:
+
+
+ +दूसरों के पिछले काम के बिना **FastAPI** अस्तित्व में नहीं होता। + +इससे पहले कई टूल्स बनाए गए हैं जिन्होंने इसके निर्माण को प्रेरित करने में मदद की है। + +मैं कई वर्षों से एक नया framework बनाने से बचता रहा। पहले मैंने **FastAPI** द्वारा कवर की जाने वाली सभी सुविधाओं को कई अलग-अलग frameworks, plug-ins और tools का उपयोग करके हल करने की कोशिश की। + +लेकिन एक समय ऐसा आया जब ऐसा कुछ बनाने के अलावा कोई विकल्प नहीं था जो ये सभी सुविधाएँ प्रदान करे, पिछले tools से सर्वोत्तम विचार लेकर उन्हें सबसे अच्छे संभव तरीके से जोड़े, और ऐसी भाषा सुविधाओं का उपयोग करे जो पहले उपलब्ध भी नहीं थीं (Python 3.6+ type hints)। + ++ +## जाँच-पड़ताल { #investigation } + +पिछले सभी विकल्पों का उपयोग करके मुझे उन सभी से सीखने, विचार लेने और उन्हें अपने लिए तथा जिन डेवलपर टीमों के साथ मैंने काम किया है उनके लिए सबसे अच्छे तरीके से संयोजित करने का अवसर मिला। + +उदाहरण के लिए, यह स्पष्ट था कि आदर्श रूप से इसे standard Python type hints पर आधारित होना चाहिए। + +साथ ही, सबसे अच्छा तरीका पहले से मौजूद standards का उपयोग करना था। + +इसलिए, **FastAPI** को code करना शुरू करने से पहले ही, मैंने OpenAPI, JSON Schema, OAuth2 आदि की specs का अध्ययन करने में कई महीने बिताए। उनके संबंध, overlap और अंतर को समझा। + +## डिज़ाइन { #design } + +फिर मैंने कुछ समय उस developer "API" को डिज़ाइन करने में बिताया जिसे मैं एक उपयोगकर्ता के रूप में रखना चाहता था (FastAPI का उपयोग करने वाले developer के रूप में)। + +मैंने सबसे लोकप्रिय Python editors में कई विचारों का परीक्षण किया: PyCharm, VS Code, Jedi आधारित editors। + +पिछले [Python Developer Survey](https://www.jetbrains.com/research/python-developers-survey-2018/#development-tools) के अनुसार, यह लगभग 80% उपयोगकर्ताओं को कवर करता है। + +इसका मतलब है कि **FastAPI** को विशेष रूप से उन editors के साथ परीक्षण किया गया था जिन्हें 80% Python developers उपयोग करते हैं। और चूँकि अधिकांश अन्य editors भी समान तरीके से काम करते हैं, इसके सभी लाभ लगभग सभी editors के लिए काम करने चाहिए। + +इस तरह मैं code duplication को जितना संभव हो उतना कम करने, हर जगह completion पाने, type और error checks आदि के सर्वोत्तम तरीके खोज सका। + +सब कुछ इस तरह से किया गया कि सभी developers को सर्वोत्तम development experience मिले। + +## आवश्यकताएँ { #requirements } + +कई विकल्पों का परीक्षण करने के बाद, मैंने निर्णय लिया कि मैं इसके लाभों के लिए [**Pydantic**](https://docs.pydantic.dev/) का उपयोग करूँगा। + +फिर मैंने इसमें योगदान दिया, ताकि यह JSON Schema के साथ पूरी तरह compliant हो, constraint declarations को define करने के अलग-अलग तरीकों का समर्थन करे, और कई editors में किए गए tests के आधार पर editor support (type checks, autocompletion) को बेहतर बनाए। + +Development के दौरान, मैंने [**Starlette**](https://www.starlette.dev/) में भी योगदान दिया, जो दूसरी मुख्य आवश्यकता थी। + +## विकास { #development } + +जब तक मैंने स्वयं **FastAPI** बनाना शुरू किया, तब तक अधिकांश हिस्से पहले से तैयार थे, डिज़ाइन परिभाषित था, requirements और tools तैयार थे, और standards तथा specifications के बारे में ज्ञान स्पष्ट और ताज़ा था। + +## भविष्य { #future } + +इस बिंदु तक, यह पहले से ही स्पष्ट है कि **FastAPI** अपने विचारों के साथ कई लोगों के लिए उपयोगी साबित हो रहा है। + +कई use cases के लिए बेहतर उपयुक्त होने के कारण इसे पिछले विकल्पों की तुलना में चुना जा रहा है। + +कई developers और teams पहले से ही अपने projects के लिए **FastAPI** पर निर्भर हैं (मेरे और मेरी team सहित)। + +लेकिन अभी भी कई सुधार और features आने बाकी हैं। + +**FastAPI** के आगे एक शानदार भविष्य है। + +और [आपकी मदद](help-fastapi.md) की बहुत सराहना की जाती है। diff --git a/docs/hi/docs/project-generation.md b/docs/hi/docs/project-generation.md new file mode 100644 index 000000000..336523fc5 --- /dev/null +++ b/docs/hi/docs/project-generation.md @@ -0,0 +1,28 @@ +# Full Stack FastAPI टेम्पलेट { #full-stack-fastapi-template } + +टेम्पलेट आमतौर पर एक विशिष्ट सेटअप के साथ आते हैं, लेकिन इन्हें लचीला और कस्टमाइज़ करने योग्य बनाया जाता है। इससे आप उन्हें अपने प्रोजेक्ट की आवश्यकताओं के अनुसार बदल और अनुकूलित कर सकते हैं, जिससे वे एक बेहतरीन शुरुआती बिंदु बन जाते हैं। 🏁 + +आप इस टेम्पलेट का उपयोग शुरुआत करने के लिए कर सकते हैं, क्योंकि इसमें शुरुआती सेटअप, सुरक्षा, डेटाबेस और कुछ API endpoints पहले से ही आपके लिए तैयार हैं। + +GitHub Repository: [Full Stack FastAPI टेम्पलेट](https://github.com/tiangolo/full-stack-fastapi-template) + +## Full Stack FastAPI टेम्पलेट - Technology Stack और Features { #full-stack-fastapi-template-technology-stack-and-features } + +- ⚡ Python backend API के लिए [**FastAPI**](https://fastapi.tiangolo.com/hi)। + - 🧰 Python SQL database interactions (ORM) के लिए [SQLModel](https://sqlmodel.tiangolo.com)। + - 🔍 data validation और settings management के लिए [Pydantic](https://docs.pydantic.dev), जिसका उपयोग FastAPI करता है। + - 💾 SQL database के रूप में [PostgreSQL](https://www.postgresql.org)। +- 🚀 frontend के लिए [React](https://react.dev)। + - 💃 TypeScript, hooks, Vite, और modern frontend stack के अन्य हिस्सों का उपयोग। + - 🎨 frontend components के लिए [Tailwind CSS](https://tailwindcss.com) और [shadcn/ui](https://ui.shadcn.com)। + - 🤖 अपने-आप generate किया गया frontend client। + - 🧪 End-to-End testing के लिए [Playwright](https://playwright.dev)। + - 🦇 Dark mode support। +- 🐋 development और production के लिए [Docker Compose](https://www.docker.com)। +- 🔒 default रूप से secure password hashing। +- 🔑 JWT (JSON Web Token) authentication। +- 📫 Email based password recovery। +- ✅ [Pytest](https://pytest.org) के साथ tests। +- 📞 reverse proxy / load balancer के रूप में [Traefik](https://traefik.io)। +- 🚢 Docker Compose का उपयोग करके deployment instructions, जिसमें automatic HTTPS certificates संभालने के लिए frontend Traefik proxy सेट अप करने का तरीका शामिल है। +- 🏭 GitHub Actions पर आधारित CI (continuous integration) और CD (continuous deployment)। diff --git a/docs/hi/docs/python-types.md b/docs/hi/docs/python-types.md new file mode 100644 index 000000000..399c26414 --- /dev/null +++ b/docs/hi/docs/python-types.md @@ -0,0 +1,348 @@ +# Python Types का परिचय { #python-types-intro } + +Python में वैकल्पिक "type hints" (जिन्हें "type annotations" भी कहा जाता है) का सपोर्ट है। + +ये **"type hints"** या annotations एक विशेष syntax हैं जो किसी variable का टाइप घोषित करने की सुविधा देते हैं। + +अपने variables के लिए types घोषित करने से editors और tools आपको बेहतर सहायता दे सकते हैं। + +यह Python type hints के बारे में बस एक **त्वरित tutorial / refresher** है। इसमें केवल उतना ही शामिल है जितना **FastAPI** के साथ उनका उपयोग करने के लिए आवश्यक है... जो वास्तव में बहुत कम है। + +**FastAPI** पूरी तरह से इन type hints पर आधारित है, ये इसे कई फायदे और लाभ देते हैं। + +लेकिन अगर आप कभी **FastAPI** का उपयोग न भी करें, तब भी इनके बारे में थोड़ा सीखने से आपको लाभ होगा। + +/// note | नोट + +यदि आप Python expert हैं, और आप type hints के बारे में सब कुछ पहले से जानते हैं, तो अगले chapter पर जाएँ। + +/// + +## प्रेरणा { #motivation } + +आइए एक सरल उदाहरण से शुरू करें: + +{* ../../docs_src/python_types/tutorial001_py310.py *} + +इस program को call करने पर output मिलता है: + +``` +John Doe +``` + +यह function निम्नलिखित करता है: + +* एक `first_name` और `last_name` लेता है। +* `title()` के साथ प्रत्येक के पहले अक्षर को upper case में बदलता है। +* उन्हें बीच में एक space के साथ जोड़ता है। + +{* ../../docs_src/python_types/tutorial001_py310.py hl[2] *} + +### इसे edit करें { #edit-it } + +यह एक बहुत सरल program है। + +लेकिन अब कल्पना करें कि आप इसे शुरुआत से लिख रहे थे। + +किसी समय आप function define करना शुरू करते हैं, और आपके parameters तैयार हैं... + +लेकिन फिर आपको "वह method जो पहले अक्षर को upper case में बदलता है" call करना होता है। + +क्या वह `upper` था? क्या वह `uppercase` था? `first_uppercase`? `capitalize`? + +फिर, आप programmer के पुराने दोस्त, editor autocompletion, को आज़माते हैं। + +आप function का पहला parameter, `first_name`, type करते हैं, फिर एक dot (`.`) और फिर completion trigger करने के लिए `Ctrl+Space` दबाते हैं। + +लेकिन, दुख की बात है, आपको कुछ भी उपयोगी नहीं मिलता: + +
+
+### Types जोड़ें { #add-types }
+
+आइए पिछले version की एक ही line को modify करें।
+
+हम exactly इस fragment, function के parameters, को बदलेंगे:
+
+```Python
+ first_name, last_name
+```
+
+से:
+
+```Python
+ first_name: str, last_name: str
+```
+
+बस इतना ही।
+
+ये "type hints" हैं:
+
+{* ../../docs_src/python_types/tutorial002_py310.py hl[1] *}
+
+यह default values घोषित करने जैसा नहीं है, जैसा कि इसमें होता:
+
+```Python
+ first_name="john", last_name="doe"
+```
+
+यह एक अलग चीज़ है।
+
+हम colons (`:`) का उपयोग कर रहे हैं, equals (`=`) का नहीं।
+
+और type hints जोड़ने से सामान्यतः यह नहीं बदलता कि उनके बिना जो होता, उससे क्या होगा।
+
+लेकिन अब, कल्पना करें कि आप फिर से वही function बना रहे हैं, लेकिन type hints के साथ।
+
+उसी point पर, आप `Ctrl+Space` के साथ autocomplete trigger करने की कोशिश करते हैं और आप देखते हैं:
+
+
+
+इसके साथ, आप options देखते हुए scroll कर सकते हैं, जब तक आपको वह option न मिल जाए जो "जाना-पहचाना लगे":
+
+
+
+## और प्रेरणा { #more-motivation }
+
+इस function को देखें, इसमें पहले से type hints हैं:
+
+{* ../../docs_src/python_types/tutorial003_py310.py hl[1] *}
+
+क्योंकि editor variables के types जानता है, आपको केवल completion ही नहीं मिलता, बल्कि error checks भी मिलते हैं:
+
+
+
+अब आप जानते हैं कि आपको इसे ठीक करना है, `age` को `str(age)` के साथ string में convert करना है:
+
+{* ../../docs_src/python_types/tutorial004_py310.py hl[2] *}
+
+## Types घोषित करना { #declaring-types }
+
+आपने type hints घोषित करने की मुख्य जगह अभी देखी। Function parameters के रूप में।
+
+यह वही मुख्य जगह भी है जहाँ आप उन्हें **FastAPI** के साथ उपयोग करेंगे।
+
+### Simple types { #simple-types }
+
+आप सभी standard Python types घोषित कर सकते हैं, केवल `str` ही नहीं।
+
+उदाहरण के लिए, आप उपयोग कर सकते हैं:
+
+* `int`
+* `float`
+* `bool`
+* `bytes`
+
+{* ../../docs_src/python_types/tutorial005_py310.py hl[1] *}
+
+### `typing` module { #typing-module }
+
+कुछ अतिरिक्त use cases के लिए, आपको standard library के `typing` module से कुछ चीज़ें import करनी पड़ सकती हैं, उदाहरण के लिए जब आप घोषित करना चाहते हैं कि किसी चीज़ का "कोई भी type" हो सकता है, तो आप `typing` से `Any` उपयोग कर सकते हैं:
+
+```python
+from typing import Any
+
+
+def some_function(data: Any):
+ print(data)
+```
+
+### Generic types { #generic-types }
+
+कुछ types square brackets में "type parameters" ले सकते हैं, ताकि उनके internal types define किए जा सकें, उदाहरण के लिए "strings की list" को `list[str]` घोषित किया जाएगा।
+
+इन types को जो type parameters ले सकते हैं, **Generic types** या **Generics** कहा जाता है।
+
+आप उन्हीं builtin types को generics के रूप में उपयोग कर सकते हैं (square brackets और अंदर types के साथ):
+
+* `list`
+* `tuple`
+* `set`
+* `dict`
+
+#### List { #list }
+
+उदाहरण के लिए, आइए एक variable को `str` की `list` के रूप में define करें।
+
+Variable को उसी colon (`:`) syntax के साथ declare करें।
+
+Type के रूप में, `list` रखें।
+
+क्योंकि list एक ऐसा type है जिसमें कुछ internal types होते हैं, आप उन्हें square brackets में रखते हैं:
+
+{* ../../docs_src/python_types/tutorial006_py310.py hl[1] *}
+
+/// note | नोट
+
+Square brackets में मौजूद उन internal types को "type parameters" कहा जाता है।
+
+इस मामले में, `str` वह type parameter है जो `list` को pass किया गया है।
+
+///
+
+इसका अर्थ है: "variable `items` एक `list` है, और इस list का प्रत्येक item एक `str` है"।
+
+ऐसा करने से, आपका editor list से items process करते समय भी support दे सकता है:
+
+
+
+Types के बिना, यह हासिल करना लगभग असंभव है।
+
+ध्यान दें कि variable `item`, list `items` के elements में से एक है।
+
+और फिर भी, editor जानता है कि यह एक `str` है, और उसके लिए support प्रदान करता है।
+
+#### Tuple और Set { #tuple-and-set }
+
+आप `tuple`s और `set`s घोषित करने के लिए भी यही करेंगे:
+
+{* ../../docs_src/python_types/tutorial007_py310.py hl[1] *}
+
+इसका अर्थ है:
+
+* Variable `items_t` एक `tuple` है जिसमें 3 items हैं, एक `int`, दूसरा `int`, और एक `str`।
+* Variable `items_s` एक `set` है, और उसके प्रत्येक item का type `bytes` है।
+
+#### Dict { #dict }
+
+`dict` define करने के लिए, आप 2 type parameters pass करते हैं, commas से अलग किए हुए।
+
+पहला type parameter `dict` की keys के लिए होता है।
+
+दूसरा type parameter `dict` की values के लिए होता है:
+
+{* ../../docs_src/python_types/tutorial008_py310.py hl[1] *}
+
+इसका अर्थ है:
+
+* Variable `prices` एक `dict` है:
+ * इस `dict` की keys `str` type की हैं (मान लें, प्रत्येक item का नाम)।
+ * इस `dict` की values `float` type की हैं (मान लें, प्रत्येक item की price)।
+
+#### Union { #union }
+
+आप घोषित कर सकते हैं कि कोई variable **कई types** में से कोई भी हो सकता है, उदाहरण के लिए, एक `int` या एक `str`।
+
+इसे define करने के लिए आप दोनों types को अलग करने के लिए vertical bar (`|`) का उपयोग करते हैं।
+
+इसे "union" कहा जाता है, क्योंकि variable उन दो type sets के union में कुछ भी हो सकता है।
+
+```Python hl_lines="1"
+{!> ../../docs_src/python_types/tutorial008b_py310.py!}
+```
+
+इसका अर्थ है कि `item` एक `int` या एक `str` हो सकता है।
+
+#### संभवतः `None` { #possibly-none }
+
+आप घोषित कर सकते हैं कि किसी value का कोई type हो सकता है, जैसे `str`, लेकिन वह `None` भी हो सकती है।
+
+//// tab | Python 3.10+
+
+```Python hl_lines="1"
+{!> ../../docs_src/python_types/tutorial009_py310.py!}
+```
+
+////
+
+सिर्फ `str` के बजाय `str | None` का उपयोग करने से editor आपको ऐसी errors detect करने में मदद करेगा जहाँ आप मान रहे हों कि कोई value हमेशा `str` है, जबकि वह वास्तव में `None` भी हो सकती है।
+
+### Classes को types के रूप में { #classes-as-types }
+
+आप किसी class को variable के type के रूप में भी घोषित कर सकते हैं।
+
+मान लें आपके पास `Person` class है, जिसमें एक name है:
+
+{* ../../docs_src/python_types/tutorial010_py310.py hl[1:3] *}
+
+फिर आप किसी variable को `Person` type का घोषित कर सकते हैं:
+
+{* ../../docs_src/python_types/tutorial010_py310.py hl[6] *}
+
+और फिर, आपको फिर से पूरा editor support मिलता है:
+
+
+
+ध्यान दें कि इसका अर्थ है "`one_person`, `Person` class का एक **instance** है"।
+
+इसका अर्थ यह नहीं है कि "`one_person`, `Person` नाम की **class** है"।
+
+## Pydantic models { #pydantic-models }
+
+[Pydantic](https://docs.pydantic.dev/) data validation करने के लिए एक Python library है।
+
+आप data की "shape" को attributes वाली classes के रूप में declare करते हैं।
+
+और प्रत्येक attribute का एक type होता है।
+
+फिर आप उस class का एक instance कुछ values के साथ बनाते हैं और यह values को validate करेगा, उन्हें उपयुक्त type में convert करेगा (यदि ऐसा मामला हो) और आपको सभी data वाला एक object देगा।
+
+और उस resulting object के साथ आपको पूरा editor support मिलता है।
+
+Official Pydantic docs से एक उदाहरण:
+
+{* ../../docs_src/python_types/tutorial011_py310.py *}
+
+/// note | नोट
+
+अधिक जानने के लिए [Pydantic, इसकी docs देखें](https://docs.pydantic.dev/)।
+
+///
+
+**FastAPI** पूरी तरह से Pydantic पर आधारित है।
+
+आप यह सब व्यवहार में [Tutorial - User Guide](tutorial/index.md) में बहुत अधिक देखेंगे।
+
+## Metadata Annotations के साथ Type Hints { #type-hints-with-metadata-annotations }
+
+Python में एक feature भी है जो `Annotated` का उपयोग करके इन type hints में **अतिरिक्त metadata** डालने की अनुमति देता है।
+
+आप `typing` से `Annotated` import कर सकते हैं।
+
+{* ../../docs_src/python_types/tutorial013_py310.py hl[1,4] *}
+
+Python स्वयं इस `Annotated` के साथ कुछ नहीं करता। और editors तथा अन्य tools के लिए, type अब भी `str` ही है।
+
+लेकिन आप `Annotated` में इस space का उपयोग **FastAPI** को इस बारे में अतिरिक्त metadata देने के लिए कर सकते हैं कि आप अपनी application का व्यवहार कैसा चाहते हैं।
+
+याद रखने वाली महत्वपूर्ण बात यह है कि `Annotated` को आप जो **पहला *type parameter*** pass करते हैं, वही **actual type** है। बाकी सब अन्य tools के लिए metadata है।
+
+अभी के लिए, आपको बस यह जानना है कि `Annotated` मौजूद है, और यह standard Python है। 😎
+
+बाद में आप देखेंगे कि यह कितना **powerful** हो सकता है।
+
+/// tip | सुझाव
+
+यह तथ्य कि यह **standard Python** है, इसका मतलब है कि आपको अपने editor में, अपने code को analyze और refactor करने के लिए उपयोग किए जाने वाले tools आदि के साथ, अब भी **सबसे अच्छा संभव developer experience** मिलेगा। ✨
+
+और यह भी कि आपका code कई अन्य Python tools और libraries के साथ बहुत compatible रहेगा। 🚀
+
+///
+
+## **FastAPI** में Type hints { #type-hints-in-fastapi }
+
+**FastAPI** इन type hints का लाभ उठाकर कई काम करता है।
+
+**FastAPI** के साथ आप parameters को type hints के साथ declare करते हैं और आपको मिलता है:
+
+* **Editor support**।
+* **Type checks**।
+
+...और **FastAPI** उन्हीं declarations का उपयोग करता है:
+
+* **Requirements define** करने के लिए: request path parameters, query parameters, headers, bodies, dependencies, आदि से।
+* **Data convert** करने के लिए: request से required type में।
+* **Data validate** करने के लिए: प्रत्येक request से आने वाला:
+ * Data invalid होने पर client को लौटाई जाने वाली **automatic errors** generate करना।
+* OpenAPI का उपयोग करके API को **Document** करने के लिए:
+ * जिसे फिर automatic interactive documentation user interfaces द्वारा उपयोग किया जाता है।
+
+यह सब abstract लग सकता है। चिंता न करें। आप यह सब [Tutorial - User Guide](tutorial/index.md) में action में देखेंगे।
+
+महत्वपूर्ण बात यह है कि standard Python types का उपयोग करके, एक ही जगह पर (अधिक classes, decorators आदि जोड़ने के बजाय), **FastAPI** आपके लिए बहुत सारा काम कर देगा।
+
+/// note | नोट
+
+यदि आप पहले ही पूरा tutorial पढ़ चुके हैं और types के बारे में और देखने के लिए वापस आए हैं, तो एक अच्छा resource [`mypy` की "cheat sheet"](https://mypy.readthedocs.io/en/latest/cheat_sheet_py3.html) है।
+
+///
diff --git a/docs/hi/docs/virtual-environments.md b/docs/hi/docs/virtual-environments.md
new file mode 100644
index 000000000..e80b90ae3
--- /dev/null
+++ b/docs/hi/docs/virtual-environments.md
@@ -0,0 +1,862 @@
+# वर्चुअल एनवायरनमेंट { #virtual-environments }
+
+जब आप Python प्रोजेक्ट्स पर काम करते हैं, तो आपको शायद हर प्रोजेक्ट के लिए इंस्टॉल किए जाने वाले पैकेजों को अलग-थलग रखने के लिए एक **वर्चुअल एनवायरनमेंट** (या कोई समान तरीका) इस्तेमाल करना चाहिए।
+
+/// note | नोट
+
+अगर आप पहले से वर्चुअल एनवायरनमेंट के बारे में जानते हैं, उन्हें कैसे बनाना और उपयोग करना है, तो आप इस सेक्शन को छोड़ सकते हैं। 🤓
+
+///
+
+/// tip | टिप
+
+एक **वर्चुअल एनवायरनमेंट**, एक **एनवायरनमेंट वैरिएबल** से अलग होता है।
+
+एक **एनवायरनमेंट वैरिएबल** सिस्टम में एक वैरिएबल होता है जिसे प्रोग्राम इस्तेमाल कर सकते हैं।
+
+एक **वर्चुअल एनवायरनमेंट** एक डायरेक्टरी होती है जिसमें कुछ फाइलें होती हैं।
+
+///
+
+/// note | नोट
+
+यह पेज आपको सिखाएगा कि **वर्चुअल एनवायरनमेंट** का उपयोग कैसे करना है और वे कैसे काम करते हैं।
+
+अगर आप एक **ऐसा टूल अपनाने के लिए तैयार हैं जो आपके लिए सब कुछ मैनेज करता है** (Python इंस्टॉल करने सहित), तो [uv](https://github.com/astral-sh/uv) आज़माएँ।
+
+///
+
+## प्रोजेक्ट बनाएँ { #create-a-project }
+
+सबसे पहले, अपने प्रोजेक्ट के लिए एक डायरेक्टरी बनाएँ।
+
+मैं सामान्यतः अपने home/user डायरेक्टरी के अंदर `code` नाम की एक डायरेक्टरी बनाता हूँ।
+
+और उसके अंदर हर प्रोजेक्ट के लिए एक-एक डायरेक्टरी बनाता हूँ।
+
+