diff --git a/docs/hi/docs/alternatives.md b/docs/hi/docs/alternatives.md
new file mode 100644
index 0000000000..8e024ba0b1
--- /dev/null
+++ b/docs/hi/docs/alternatives.md
@@ -0,0 +1,485 @@
+# विकल्प, प्रेरणा और तुलनाएँ { #alternatives-inspiration-and-comparisons }
+
+**FastAPI** को किससे प्रेरणा मिली, यह विकल्पों की तुलना में कैसा है और उनसे इसने क्या सीखा।
+
+## परिचय { #intro }
+
+दूसरों के पिछले काम के बिना **FastAPI** अस्तित्व में नहीं होता।
+
+इससे पहले कई टूल बनाए गए हैं जिन्होंने इसके निर्माण को प्रेरित करने में मदद की।
+
+मैं कई वर्षों तक एक नया framework बनाने से बचता रहा। पहले मैंने **FastAPI** द्वारा कवर की गई सभी विशेषताओं को कई अलग-अलग frameworks, plug-ins और tools का उपयोग करके हल करने की कोशिश की।
+
+लेकिन एक समय ऐसा आया जब ऐसा कुछ बनाने के अलावा कोई विकल्प नहीं था जो ये सभी सुविधाएँ प्रदान करे, पिछले tools से सर्वोत्तम विचारों को लेकर, और उन्हें सबसे अच्छे तरीके से मिलाकर, उन language features का उपयोग करते हुए जो पहले उपलब्ध भी नहीं थे (Python 3.6+ type hints)।
+
+## पिछले tools { #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) या इसके साथ संचार करने वाले अन्य 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 क्षमताओं में सुधार हो सके।
+
+इसका उपयोग Mozilla, Red Hat और Eventbrite सहित कई कंपनियाँ करती हैं।
+
+यह **automatic API documentation** के पहले उदाहरणों में से एक था, और यह विशेष रूप से उन पहले विचारों में से एक था जिसने **FastAPI** की "खोज" को प्रेरित किया।
+
+/// note | नोट
+
+Django REST Framework को Tom Christie ने बनाया था। वही Starlette और Uvicorn के creator हैं, जिन पर **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 का उपयोग करने जैसी चीज़ें करने की अनुमति देती है।
+
+क्योंकि यह बहुत सरल है, इसे सीखना अपेक्षाकृत सहज है, हालांकि documentation कुछ बिंदुओं पर थोड़ा technical हो जाता है।
+
+इसका उपयोग आमतौर पर उन अन्य applications के लिए भी किया जाता है जिन्हें जरूरी नहीं कि database, user management, या Django में पहले से built-in आने वाली कई 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 *बनाने* के लिए (server के रूप में) एक library है।
+
+वे कमोबेश विपरीत सिरों पर हैं, एक-दूसरे को पूरक करते हुए।
+
+Requests का design बहुत simple और intuitive है, sensible defaults के साथ इसका उपयोग करना बहुत आसान है। लेकिन साथ ही, यह बहुत powerful और customizable है।
+
+इसीलिए, जैसा कि official website में कहा गया है:
+
+> Requests अब तक के सबसे अधिक downloaded Python packages में से एक है
+
+आप इसे जिस तरह उपयोग करते हैं वह बहुत सरल है। उदाहरण के लिए, `GET` request करने के लिए, आप लिखेंगे:
+
+```Python
+response = requests.get("http://example.com/some/url")
+```
+
+FastAPI में इसके समकक्ष 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) को सीधे, straightforward और 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 करने के लिए JSON (या YAML, JSON का एक extension) का उपयोग करने वाला एक standard था, जिसे 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 हैं, लेकिन उनकी जाँच में समय और काम लगाने के बाद, मैंने पाया कि कई discontinue या abandon हो चुके हैं, और उनमें कई unresolved issues हैं जिन्होंने उन्हें अनुपयुक्त बना दिया।
+
+### [Marshmallow](https://marshmallow.readthedocs.io/en/stable/) { #marshmallow }
+
+API systems द्वारा आवश्यक मुख्य features में से एक data "serialization" है, जिसमें code (Python) से data लेकर उसे ऐसी चीज़ में बदला जाता है जिसे network के माध्यम से भेजा जा सके। उदाहरण के लिए, database से data रखने वाले object को JSON object में बदलना। `datetime` objects को strings में बदलना, आदि।
+
+APIs द्वारा आवश्यक एक और बड़ा feature data validation है, यह सुनिश्चित करना कि data निश्चित parameters के अनुसार valid है। उदाहरण के लिए, कोई field `int` है, कोई random string नहीं। यह incoming data के लिए विशेष रूप से उपयोगी है।
+
+Data validation system के बिना, आपको सभी checks हाथ से, code में करने पड़ते।
+
+ये 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 plug-ins के रूप में validation, parsing और serialization प्रदान करते हैं।
+
+लेकिन 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 का उपयोग करके OpenAPI schemas automatically generate करने के लिए Webargs और Marshmallow की जानकारी का उपयोग करता है।
+
+यह एक बेहतरीन tool है, बहुत underrated। इसे वहाँ मौजूद कई Flask plug-ins से कहीं अधिक popular होना चाहिए। यह शायद इसकी documentation के बहुत concise और abstract होने के कारण हो सकता है।
+
+इसने Python docstrings के अंदर YAML (एक और syntax) लिखने की आवश्यकता को हल कर दिया।
+
+Flask, Flask-apispec को Marshmallow और Webargs के साथ मिलाकर यह combination **FastAPI** बनाने तक मेरा पसंदीदा backend stack था।
+
+इसका उपयोग करने से कई Flask full-stack generators बने। ये वे main 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) का base थे।
+
+/// 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 Angular से प्रेरित एक JavaScript (TypeScript) NodeJS framework है।
+
+यह कुछ ऐसा हासिल करता है जो Flask-apispec के साथ किए जा सकने वाले काम जैसा है।
+
+इसमें Angular 2 से प्रेरित एक integrated dependency injection system है। इसमें "injectables" को pre-register करना आवश्यक है (जैसे मुझे ज्ञात सभी अन्य dependency injection systems में), इसलिए, यह verbosity और code repetition बढ़ाता है।
+
+क्योंकि parameters को TypeScript types (Python type hints के समान) के साथ describe किया जाता है, editor support काफी अच्छा है।
+
+लेकिन क्योंकि TypeScript data compilation के बाद JavaScript में preserve नहीं रहता, यह 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 हैं, तो इसे ठीक से document और validate नहीं किया जा सकता।
+
+/// 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 के ऊपर एक framework के रूप में implement करना पड़ता है, जैसे Hug। यही अंतर उन अन्य frameworks में भी होता है जो Falcon के design से प्रेरित हैं, जहाँ 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** बनाने के शुरुआती चरणों में Molten खोजा। और इसमें काफी समान विचार हैं:
+
+* Python type hints पर आधारित।
+* इन types से validation और documentation।
+* Dependency Injection system।
+
+यह Pydantic जैसी data validation, serialization और documentation third-party library का उपयोग नहीं करता, इसकी अपनी 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 को provide करने वाले एक से अधिक "component" declare करना संभव नहीं है।
+
+Routes एक ही जगह declare किए जाते हैं, दूसरी जगहों पर declared functions का उपयोग करके (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 की। यह एक बेहतरीन विचार था जिसने अन्य tools को भी ऐसा ही करने के लिए प्रेरित किया।
+
+इसने अपनी declarations में standard Python types के बजाय custom types का उपयोग किया, लेकिन फिर भी यह एक बहुत बड़ा कदम आगे था।
+
+यह पूरे API को JSON में declare करने वाला custom schema generate करने वाले पहले frameworks में से भी एक था।
+
+यह OpenAPI और JSON Schema जैसे standard पर आधारित नहीं था। इसलिए इसे Swagger UI जैसे अन्य tools के साथ integrate करना straightforward नहीं होता। लेकिन फिर भी, यह एक बहुत innovative idea था।
+
+इसमें एक दिलचस्प, 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** को प्रेरित करने वाले विचार
+
+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 बेहतरीन था।
+
+यह उन पहले implementations में से एक था जो मैंने कभी देखे, जिसमें parameters और requests declare करने के लिए Python type hints का उपयोग करने वाला framework था (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 ने surpass किया था)।
+
+शुरुआत में, इसमें 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 shift हो गया।
+
+यह अब 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 करने का विचार, जो साथ ही बेहतरीन editor support भी देता था, मुझे एक शानदार विचार लगा।
+
+और लंबे समय तक समान framework की खोज करने और कई अलग-अलग alternatives को test करने के बाद, APIStar उपलब्ध सबसे अच्छा विकल्प था।
+
+फिर APIStar ने server के रूप में अस्तित्व में रहना बंद कर दिया और Starlette बनाया गया, और यह ऐसे system के लिए एक नई बेहतर foundation था। यही **FastAPI** बनाने की अंतिम प्रेरणा थी।
+
+मैं **FastAPI** को APIStar का "spiritual successor" मानता हूँ, जो इन सभी पिछले tools से मिली सीख के आधार पर features, typing system, और अन्य parts को improve और increase करता है।
+
+///
+
+## **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 बनाने के लिए ideal है।
+
+यह बहुत simple और intuitive है। इसे आसानी से extensible होने और modular components रखने के लिए design किया गया है।
+
+इसमें है:
+
+* Seriously impressive 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.
+* Few hard dependencies.
+
+Starlette वर्तमान में tested सबसे तेज़ Python framework है। केवल Uvicorn ने इसे surpass किया है, जो 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) से switch कर सकते हैं, या आप ASGI compatible tools, जैसे `python-socketio`, जोड़ सकते हैं।
+
+///
+
+/// 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 पर बना है।
+
+यह web framework नहीं, बल्कि server है। उदाहरण के लिए, यह paths द्वारा routing के लिए tools प्रदान नहीं करता। यह ऐसी चीज़ है जो Starlette (या **FastAPI**) जैसा framework ऊपर से प्रदान करेगा।
+
+यह Starlette और **FastAPI** के लिए recommended server है।
+
+/// tip | **FastAPI** इसे इस रूप में अनुशंसित करता है
+
+**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 के बीच समझने, तुलना करने, और अंतर देखने के लिए, [Benchmarks](benchmarks.md) के बारे में section देखें।
diff --git a/docs/hi/docs/async.md b/docs/hi/docs/async.md
new file mode 100644
index 0000000000..4112f907ce
--- /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 के आधुनिक versions **"asynchronous code"** का support करते हैं, जो **"coroutines"** नाम की चीज़ का उपयोग करता है, **`async` और `await`** syntax के साथ।
+
+आइए नीचे के sections में इस phrase को हिस्सों में देखते हैं:
+
+* **Asynchronous Code**
+* **`async` और `await`**
+* **Coroutines**
+
+## Asynchronous Code { #asynchronous-code }
+
+Asynchronous code का मतलब बस यह है कि language 💬 के पास computer / program 🤖 को यह बताने का एक तरीका होता है कि code में किसी point पर, उसे 🤖 कहीं और *किसी और चीज़* के finish होने का इंतज़ार करना होगा। मान लें कि उस *किसी और चीज़* को "slow-file" 📝 कहा जाता है।
+
+तो, उस समय के दौरान, computer कोई और काम कर सकता है, जबकि "slow-file" 📝 finish हो रही होती है।
+
+फिर computer / program 🤖 हर बार वापस आएगा जब उसे मौका मिलेगा क्योंकि वह फिर से इंतज़ार कर रहा होगा, या जब भी वह 🤖 उस point पर अपना सारा काम finish कर लेगा। और वह 🤖 देखेगा कि जिन tasks का वह इंतज़ार कर रहा था, उनमें से कोई पहले ही finish हो चुका है या नहीं, फिर वह जो भी करना था करेगा।
+
+इसके बाद, वह 🤖 finish होने वाला पहला task लेता है (मान लें, हमारी "slow-file" 📝) और उसके साथ जो भी करना था उसे जारी रखता है।
+
+वह "किसी और चीज़ का इंतज़ार" आम तौर पर I/O operations को refer करता है जो अपेक्षाकृत "slow" होते हैं (processor और RAM memory की speed की तुलना में), जैसे इंतज़ार करना:
+
+* client से data network के माध्यम से भेजे जाने का
+* आपके program द्वारा भेजा गया data client द्वारा network के माध्यम से receive किए जाने का
+* disk पर किसी file की contents system द्वारा पढ़े जाने और आपके program को दिए जाने का
+* आपके program द्वारा system को दी गई contents disk पर लिखे जाने का
+* किसी remote API operation का
+* किसी database operation के finish होने का
+* किसी database query द्वारा results return किए जाने का
+* आदि।
+
+क्योंकि execution time ज़्यादातर I/O operations का इंतज़ार करने में consume होता है, उन्हें "I/O bound" operations कहा जाता है।
+
+इसे "asynchronous" इसलिए कहा जाता है क्योंकि computer / program को slow task के साथ "synchronized" होने की ज़रूरत नहीं होती, task के finish होने के exact moment का इंतज़ार करते हुए, कुछ भी न करते हुए, ताकि वह task result ले सके और काम जारी रख सके।
+
+इसके बजाय, "asynchronous" system होने के कारण, task finish होने के बाद, computer / program के वापस आने तक थोड़ा सा line में wait कर सकता है (कुछ microseconds), ताकि computer / program जो काम करने गया था उसे finish करे, और फिर वापस आकर results ले और उनके साथ काम जारी रखे।
+
+"Synchronous" ("asynchronous" के विपरीत) के लिए वे आमतौर पर "sequential" term भी use करते हैं, क्योंकि computer / program किसी अलग task पर switch करने से पहले sequence में सभी steps follow करता है, भले ही उन steps में इंतज़ार शामिल हो।
+
+### Concurrency और Burgers { #concurrency-and-burgers }
+
+ऊपर describe किए गए **asynchronous** code के इस idea को कभी-कभी **"concurrency"** भी कहा जाता है। यह **"parallelism"** से अलग है।
+
+**Concurrency** और **parallelism** दोनों "अलग-अलग चीज़ें लगभग एक ही समय पर हो रही हैं" से related हैं।
+
+लेकिन *concurrency* और *parallelism* के बीच के details काफी अलग हैं।
+
+अंतर देखने के लिए, burgers के बारे में निम्न story imagine करें:
+
+### Concurrent Burgers { #concurrent-burgers }
+
+आप अपनी crush के साथ fast food लेने जाते हैं, आप line में खड़े होते हैं जबकि cashier आपके आगे के लोगों से orders ले रहा होता है। 😍
+
+
+
+फिर आपकी बारी आती है, आप अपनी crush और अपने लिए 2 बहुत fancy burgers का order देते हैं। 🍔🍔
+
+
+
+Cashier kitchen में cook से कुछ कहता है ताकि उन्हें पता हो कि उन्हें आपके burgers prepare करने हैं (भले ही वे currently previous clients के burgers prepare कर रहे हों)।
+
+
+
+आप pay करते हैं। 💸
+
+Cashier आपको आपकी turn का number देता है।
+
+
+
+जब आप wait कर रहे होते हैं, आप अपनी crush के साथ एक table चुनते हैं, बैठते हैं और अपनी crush से लंबे समय तक बात करते हैं (क्योंकि आपके burgers बहुत fancy हैं और prepare होने में कुछ समय लेते हैं)।
+
+जब आप अपनी crush के साथ table पर बैठे होते हैं, burgers का इंतज़ार करते हुए, आप उस समय को यह admire करने में spend कर सकते हैं कि आपकी crush कितनी awesome, cute और smart है ✨😍✨।
+
+
+
+Wait करते हुए और अपनी crush से बात करते हुए, time to time, आप counter पर displayed number check करते हैं कि क्या आपकी turn आ गई है।
+
+फिर किसी point पर, आखिरकार आपकी turn आ जाती है। आप counter पर जाते हैं, अपने burgers लेते हैं और table पर वापस आते हैं।
+
+
+
+आप और आपकी crush burgers खाते हैं और अच्छा समय बिताते हैं। ✨
+
+
+
+/// note | नोट
+
+सुंदर illustrations [Ketrina Thompson](https://www.instagram.com/ketrinadrawsalot) द्वारा। 🎨
+
+///
+
+---
+
+कल्पना करें कि उस story में आप computer / program 🤖 हैं।
+
+जब आप line में होते हैं, आप बस idle 😴 होते हैं, अपनी turn का इंतज़ार करते हुए, कुछ बहुत "productive" नहीं कर रहे होते। लेकिन line fast है क्योंकि cashier केवल orders ले रहा है (उन्हें prepare नहीं कर रहा), इसलिए यह ठीक है।
+
+फिर, जब आपकी turn आती है, आप actual "productive" work करते हैं, menu process करते हैं, decide करते हैं कि आपको क्या चाहिए, अपनी crush की choice लेते हैं, pay करते हैं, check करते हैं कि आप correct bill या card दे रहे हैं, check करते हैं कि आपसे सही charge किया गया है, check करते हैं कि order में correct items हैं, आदि।
+
+लेकिन फिर, भले ही आपके पास अभी burgers नहीं हैं, cashier के साथ आपका work "on pause" ⏸ है, क्योंकि आपको अपने burgers ready होने का wait 🕙 करना है।
+
+लेकिन जब आप counter से दूर जाते हैं और अपनी turn के number के साथ table पर बैठते हैं, आप अपना attention अपनी crush पर switch 🔀 कर सकते हैं, और उस पर "work" ⏯ 🤓 कर सकते हैं। फिर आप दोबारा कुछ बहुत "productive" कर रहे होते हैं, जैसे अपनी crush 😍 के साथ flirting।
+
+फिर cashier 💁 counter के display पर आपका number डालकर कहता है "मैंने burgers बना लिए हैं", लेकिन displayed number आपकी turn number में बदलते ही आप तुरंत पागलों की तरह jump नहीं करते। आपको पता है कि कोई आपके burgers नहीं चुराएगा क्योंकि आपके पास आपकी turn का number है, और उनके पास उनका।
+
+तो आप अपनी crush के story finish करने का इंतज़ार करते हैं (current work ⏯ / process हो रहा task 🤓 finish होना), gentle smile करते हैं और कहते हैं कि आप burgers लेने जा रहे हैं ⏸।
+
+फिर आप counter 🔀 पर जाते हैं, उस initial task पर जो अब finish हो चुका है ⏯, burgers उठाते हैं, thanks कहते हैं और उन्हें table पर ले जाते हैं। इससे counter के साथ interaction का वह step / task finish हो जाता है ⏹। यह बदले में, "eating burgers" 🔀 ⏯ का एक नया task create करता है, लेकिन "getting 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 होने का wait कर रहा है क्योंकि 8 cashiers में से हर एक next order लेने से पहले तुरंत जाकर burger prepare करता है।
+
+
+
+फिर आखिरकार आपकी turn आती है, आप अपनी crush और अपने लिए 2 बहुत fancy burgers का order देते हैं।
+
+आप pay करते हैं 💸।
+
+
+
+Cashier kitchen में जाता है।
+
+आप counter 🕙 के सामने खड़े होकर wait करते हैं, ताकि आपसे पहले कोई और आपके burgers न ले जाए, क्योंकि turns के लिए कोई numbers नहीं हैं।
+
+
+
+क्योंकि आप और आपकी crush इस बात में busy हैं कि कोई आपके आगे न आ जाए और आपके burgers आते ही उन्हें न ले जाए, आप अपनी crush पर attention नहीं दे सकते। 😞
+
+यह "synchronous" work है, आप cashier/cook 👨🍳 के साथ "synchronized" हैं। आपको wait 🕙 करना है और exact moment पर वहाँ होना है जब cashier/cook 👨🍳 burgers finish करता है और आपको देता है, नहीं तो कोई और उन्हें ले सकता है।
+
+
+
+फिर आपका cashier/cook 👨🍳 लंबे समय तक counter के सामने wait 🕙 कराने के बाद आखिरकार आपके burgers लेकर वापस आता है।
+
+
+
+आप अपने burgers लेते हैं और अपनी crush के साथ table पर जाते हैं।
+
+आप बस उन्हें खाते हैं, और आपका काम हो जाता है। ⏹
+
+
+
+ज़्यादा बात या flirting नहीं हुई क्योंकि अधिकतर समय counter के सामने wait 🕙 करने में spend हुआ। 😞
+
+/// note | नोट
+
+सुंदर illustrations [Ketrina Thompson](https://www.instagram.com/ketrinadrawsalot) द्वारा। 🎨
+
+///
+
+---
+
+Parallel burgers के इस scenario में, आप एक computer / program 🤖 हैं जिसमें दो processors हैं (आप और आपकी crush), दोनों wait 🕙 कर रहे हैं और लंबे समय तक "counter पर waiting" 🕙 में अपना attention ⏯ dedicate कर रहे हैं।
+
+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 में लंबे समय तक wait 🕙 करना पड़ता है या आप अपनी turn खो देते हैं।
+
+आप शायद अपनी crush 😍 को bank 🏦 में errands करने के लिए अपने साथ नहीं ले जाना चाहेंगे।
+
+### Burger निष्कर्ष { #burger-conclusion }
+
+"अपनी crush के साथ fast food burgers" के इस scenario में, क्योंकि बहुत waiting 🕙 है, concurrent system ⏸🔀⏯ रखना कहीं अधिक sensible है।
+
+अधिकांश web applications के लिए यही case है।
+
+बहुत, बहुत सारे users, लेकिन आपका server उनकी not-so-good connection द्वारा उनकी requests भेजने का wait 🕙 कर रहा है।
+
+और फिर responses वापस आने का फिर से wait 🕙 कर रहा है।
+
+यह "waiting" 🕙 microseconds में measure की जाती है, लेकिन फिर भी, सबको जोड़ने पर, अंत में काफी waiting हो जाती है।
+
+इसीलिए web APIs के लिए asynchronous ⏸🔀⏯ code use करना बहुत sensible है।
+
+इसी तरह की asynchronicity ने NodeJS को popular बनाया (भले ही NodeJS parallel नहीं है) और यही Go की programming language के रूप में strength है।
+
+और यही same level की performance आपको **FastAPI** के साथ मिलती है।
+
+और क्योंकि आपके पास parallelism और asynchronicity एक ही समय पर हो सकते हैं, आपको tested NodeJS frameworks में से अधिकांश से higher performance मिलती है और Go के बराबर, जो 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 }
+
+नहीं! यह story की moral नहीं है।
+
+Concurrency, parallelism से अलग है। और यह उन **specific** scenarios में बेहतर है जिनमें बहुत waiting शामिल होती है। इसी कारण, web application development के लिए यह आम तौर पर parallelism से बहुत बेहतर है। लेकिन हर चीज़ के लिए नहीं।
+
+तो, इसे balance करने के लिए, निम्न short story imagine करें:
+
+> आपको एक बड़ा, गंदा house clean करना है।
+
+*हाँ, यही पूरी story है*।
+
+---
+
+कहीं भी कोई waiting 🕙 नहीं है, बस बहुत सारा काम करना है, house के multiple places में।
+
+आप burgers example की तरह turns रख सकते थे, पहले living room, फिर kitchen, लेकिन क्योंकि आप किसी चीज़ का wait 🕙 नहीं कर रहे, बस cleaning and cleaning कर रहे हैं, turns किसी चीज़ को affect नहीं करेंगे।
+
+Turns (concurrency) के साथ या बिना finish करने में उतना ही time लगेगा और आपने उतना ही काम किया होगा।
+
+लेकिन इस case में, अगर आप 8 ex-cashier/cooks/now-cleaners ला सकें, और उनमें से हर एक (plus आप) house का एक zone clean करने के लिए ले सके, तो आप extra help के साथ सारा काम **parallel** में कर सकते हैं, और बहुत जल्दी finish कर सकते हैं।
+
+इस scenario में, cleaners में से हर एक (आप सहित) एक processor होगा, job का अपना part कर रहा होगा।
+
+और क्योंकि execution time का अधिकतर हिस्सा actual work (waiting के बजाय) में लगता है, और computer में work CPU द्वारा किया जाता है, वे इन problems को "CPU bound" कहते हैं।
+
+---
+
+CPU bound operations के common examples ऐसी चीज़ें हैं जिन्हें complex math processing की ज़रूरत होती है।
+
+उदाहरण के लिए:
+
+* **Audio** या **image processing**।
+* **Computer vision**: एक image millions of pixels से composed होती है, हर 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 का उपयोग करते हैं।
+
+### 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 (multiple processes parallel में चलाना) के benefits का भी exploit कर सकते हैं।
+
+वह, साथ ही यह 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 के आधुनिक versions में asynchronous code define करने का बहुत intuitive तरीका है। इससे यह सामान्य "sequential" code जैसा दिखता है और सही moments पर आपके लिए "awaiting" करता है।
+
+जब कोई operation results देने से पहले waiting require करेगा और इन नए Python features का support रखता है, तो आप उसे ऐसे code कर सकते हैं:
+
+```Python
+burgers = await get_burgers(2)
+```
+
+यहाँ key `await` है। यह Python को बताता है कि `burgers` में results store करने से पहले उसे `get_burgers(2)` के अपना काम 🕙 finish करने का wait ⏸ करना है। इससे, Python जान जाएगा कि वह meanwhile कुछ और 🔀 ⏯ कर सकता है (जैसे कोई दूसरी request receive करना)।
+
+`await` के work करने के लिए, इसे ऐसे function के अंदर होना चाहिए जो इस asynchronicity को support करता हो। ऐसा करने के लिए, आप बस इसे `async def` के साथ declare करते हैं:
+
+```Python hl_lines="1"
+async def get_burgers(number: int):
+ # Burgers बनाने के लिए कुछ asynchronous काम करें
+ return burgers
+```
+
+...`def` के बजाय:
+
+```Python hl_lines="2"
+# यह asynchronous नहीं है
+def get_sequential_burgers(number: int):
+ # Burgers बनाने के लिए कुछ 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 कर सकते हैं, तो आपको उसका उपयोग करने वाले *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` के साथ defined functions के अंदर ही use किया जा सकता है।
+
+लेकिन उसी समय, `async def` के साथ defined functions को "awaited" होना पड़ता है। इसलिए, `async def` वाले functions केवल `async def` के साथ defined functions के अंदर ही call किए जा सकते हैं।
+
+तो, egg और chicken के बारे में, आप first `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 नहीं कर रहे हों, आप high compatibility और इसके benefits (जैसे *structured concurrency*) पाने के लिए [AnyIO](https://anyio.readthedocs.io/en/stable/) के साथ अपने खुद के async applications भी लिख सकते हैं।
+
+मैंने 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 के अन्य forms { #other-forms-of-asynchronous-code }
+
+`async` और `await` use करने की यह style language में relatively new है।
+
+लेकिन यह asynchronous code के साथ काम करना बहुत आसान बनाती है।
+
+यही same syntax (या लगभग identical) हाल ही में JavaScript के modern versions (Browser और NodeJS में) में भी शामिल किया गया था।
+
+लेकिन उससे पहले, asynchronous code handle करना कहीं अधिक complex और difficult था।
+
+Python के previous versions में, आप threads या [Gevent](https://www.gevent.org/) use कर सकते थे। लेकिन code समझने, debug करने और उसके बारे में सोचने के लिए कहीं अधिक complex होता है।
+
+NodeJS / Browser JavaScript के previous versions में, आप "callbacks" use करते। जो "callback hell" तक ले जाता है।
+
+## Coroutines { #coroutines }
+
+**Coroutine** बस उस चीज़ के लिए बहुत fancy term है जो किसी `async def` function द्वारा return की जाती है। Python जानता है कि यह function जैसी कोई चीज़ है, जिसे वह start कर सकता है और जो किसी point पर end होगी, लेकिन यह internally pause ⏸ भी हो सकती है, जब भी इसके अंदर कोई `await` हो।
+
+लेकिन asynchronous code को `async` और `await` के साथ use करने की यह सारी functionality कई बार "coroutines" use करने के रूप में summarize की जाती है। यह Go की main key feature, "Goroutines" से comparable है।
+
+## निष्कर्ष { #conclusion }
+
+आइए ऊपर वाला वही phrase देखें:
+
+> Python के आधुनिक versions **"asynchronous code"** का support करते हैं, जो **"coroutines"** नाम की चीज़ का उपयोग करता है, **`async` और `await`** syntax के साथ।
+
+अब यह अधिक sense बनाना चाहिए। ✨
+
+यह सब FastAPI (Starlette के माध्यम से) को power करता है और इसे इतनी impressive performance देता है।
+
+## बहुत तकनीकी विवरण { #very-technical-details }
+
+/// warning | चेतावनी
+
+आप शायद इसे skip कर सकते हैं।
+
+ये **FastAPI** अंदर से कैसे काम करता है, इसके बहुत technical details हैं।
+
+अगर आपके पास काफी technical knowledge (coroutines, threads, blocking, आदि) है और आप curious हैं कि FastAPI `async def` बनाम normal `def` को कैसे handle करता है, तो आगे बढ़ें।
+
+///
+
+### Path operation functions { #path-operation-functions }
+
+जब आप किसी *path operation function* को `async def` के बजाय normal `def` के साथ declare करते हैं, तो इसे directly call करने के बजाय (क्योंकि यह server को block करेगा), एक external threadpool में run किया जाता है जिसे फिर awaited किया जाता है।
+
+अगर आप किसी दूसरे async framework से आ रहे हैं जो ऊपर described तरीके से काम नहीं करता और आप tiny performance gain (लगभग 100 nanoseconds) के लिए trivial compute-only *path operation functions* को plain `def` के साथ define करने के आदी हैं, तो कृपया ध्यान दें कि **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) हो सकती हैं जो एक-दूसरे को require करती हैं (function definitions के parameters के रूप में), उनमें से कुछ `async def` के साथ created हो सकती हैं और कुछ normal `def` के साथ। यह फिर भी work करेगा, और normal `def` के साथ created ones को "awaited" होने के बजाय external thread (threadpool से) पर call किया जाएगा।
+
+### अन्य utility functions { #other-utility-functions }
+
+कोई भी अन्य utility function जिसे आप directly call करते हैं, normal `def` या `async def` के साथ created हो सकता है और FastAPI आपके उसे call करने के तरीके को affect नहीं करेगा।
+
+यह उन functions के contrast में है जिन्हें FastAPI आपके लिए call करता है: *path operation functions* और dependencies।
+
+अगर आपका utility function `def` वाला normal function है, तो उसे directly call किया जाएगा (जैसा आप अपने code में लिखते हैं), threadpool में नहीं; अगर function `async def` के साथ created है तो आपको अपने code में उसे call करते समय उस function को `await` करना चाहिए।
+
+---
+
+फिर से, ये बहुत technical details हैं जो शायद useful होंगे अगर आप इन्हें search करते हुए आए हैं।
+
+अन्यथा, आपको ऊपर के section की guidelines के साथ ठीक होना चाहिए: जल्दी में हैं?।
diff --git a/docs/hi/docs/benchmarks.md b/docs/hi/docs/benchmarks.md
new file mode 100644
index 0000000000..11a22bcb8e
--- /dev/null
+++ b/docs/hi/docs/benchmarks.md
@@ -0,0 +1,34 @@
+# Benchmarks { #benchmarks }
+
+स्वतंत्र TechEmpower benchmarks दिखाते हैं कि 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 द्वारा internally किया जाता है)।
+
+लेकिन benchmarks और comparisons देखते समय आपको निम्न बातों को ध्यान में रखना चाहिए।
+
+## Benchmarks और speed { #benchmarks-and-speed }
+
+जब आप benchmarks देखते हैं, तो अलग-अलग प्रकार के कई tools को equivalent मानकर compare होते देखना आम बात है।
+
+विशेष रूप से, Uvicorn, Starlette और FastAPI को एक साथ compare होते देखना (कई अन्य tools के साथ)।
+
+Tool जितनी सरल समस्या हल करता है, उसे उतनी ही बेहतर performance मिलेगी। और अधिकांश benchmarks, 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 में कमोबेश, कम से कम, Starlette (या **FastAPI**) द्वारा प्रदान किया गया सारा code शामिल करना पड़ेगा। और यदि आपने ऐसा किया, तो आपके final 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 करने पड़ेंगे। इसलिए, आपके final application में फिर भी उतना ही overhead होगा जितना FastAPI का उपयोग करके बनाए जाने पर होता। और कई मामलों में, यह data validation और serialization applications में लिखे गए code का सबसे बड़ा हिस्सा होता है।
+ * इसलिए, FastAPI का उपयोग करके आप development time, bugs और lines of code बचाते हैं, और संभवतः आपको वही performance (या बेहतर) मिलेगी जो आपको इसे उपयोग न करने पर मिलती (क्योंकि तब आपको यह सब अपने code में implement करना पड़ता)।
+ * यदि आप FastAPI की तुलना कर रहे हैं, तो इसकी तुलना ऐसे web application framework (या tools के set) से करें जो data validation, serialization और documentation प्रदान करता हो, जैसे Flask-apispec, NestJS, Molten आदि। ऐसे frameworks जिनमें integrated automatic data validation, serialization और documentation हो।
diff --git a/docs/hi/docs/editor-support.md b/docs/hi/docs/editor-support.md
new file mode 100644
index 0000000000..9a9992e8c7
--- /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 development workflow को *पाथ ऑपरेशन* 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/) दोनों के लिए उपलब्ध है। इसे हर editor के Extensions panel से सीधे "FastAPI" खोजकर और **FastAPI Labs** द्वारा प्रकाशित extension चुनकर install किया जा सकता है। यह extension browser-based editors जैसे [vscode.dev](https://vscode.dev) और [github.dev](https://github.dev) में भी काम करता है।
+
+### एप्लिकेशन डिस्कवरी { #application-discovery }
+
+Default रूप से, 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 specify कर सकते हैं।
+
+## फीचर्स { #features }
+
+- **Path Operation Explorer** - आपके application में सभी *पाथ ऑपरेशन्स* का sidebar tree view। किसी भी route या router definition पर जाने के लिए click करें।
+- **Route Search** - Ctrl + Shift + E (macOS पर: Cmd + Shift + E) के साथ path, method, या name के आधार पर search करें।
+- **CodeLens Navigation** - test client calls (जैसे `client.get('/items')`) के ऊपर clickable links, जो tests और implementation के बीच quick navigation के लिए matching *पाथ ऑपरेशन* पर ले जाते हैं।
+- **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 के features से परिचित होना चाहते हैं, तो 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 0000000000..268a5cd783
--- /dev/null
+++ b/docs/hi/docs/fastapi-cli.md
@@ -0,0 +1,134 @@
+# FastAPI CLI { #fastapi-cli }
+
+**FastAPI CLI** एक command line प्रोग्राम है जिसका उपयोग आप अपने FastAPI ऐप को serve करने, अपने FastAPI प्रोजेक्ट को manage करने, और भी बहुत कुछ करने के लिए कर सकते हैं।
+
+जब आप FastAPI इंस्टॉल करते हैं (जैसे `pip install "fastapi[standard]"` के साथ), तो इसके साथ एक command line प्रोग्राम आता है जिसे आप terminal में चला सकते हैं।
+
+डेवलपमेंट के लिए अपना FastAPI ऐप चलाने के लिए, आप `fastapi dev` command का उपयोग कर सकते हैं:
+
+
+ +दूसरों के पिछले काम के बिना **FastAPI** मौजूद नहीं होता। + +इससे पहले कई टूल बनाए गए हैं जिन्होंने इसके निर्माण को प्रेरित करने में मदद की है। + +मैं कई वर्षों से एक नया framework बनाने से बचता रहा। पहले मैंने **FastAPI** द्वारा कवर किए गए सभी features को कई अलग-अलग frameworks, plug-ins और tools का उपयोग करके हल करने की कोशिश की। + +लेकिन किसी बिंदु पर, ऐसा कुछ बनाने के अलावा कोई विकल्प नहीं बचा था जो ये सभी features प्रदान करे, पिछले tools से सर्वोत्तम ideas ले और उन्हें सर्वोत्तम संभव तरीके से जोड़े, साथ ही ऐसी language features का उपयोग करे जो पहले उपलब्ध भी नहीं थीं (Python 3.6+ type hints)। + ++ +## जाँच-पड़ताल { #investigation } + +सभी पिछले विकल्पों का उपयोग करके मुझे उन सभी से सीखने, ideas लेने, और उन्हें अपने तथा जिन डेवलपर टीमों के साथ मैंने काम किया है उनके लिए सबसे अच्छे तरीके से मिलाने का अवसर मिला। + +उदाहरण के लिए, यह स्पष्ट था कि आदर्श रूप से इसे standard Python type hints पर आधारित होना चाहिए। + +साथ ही, सबसे अच्छा तरीका पहले से मौजूद standards का उपयोग करना था। + +इसलिए, **FastAPI** की coding शुरू करने से पहले ही, मैंने OpenAPI, JSON Schema, OAuth2 आदि के specs का अध्ययन करने में कई महीने बिताए। उनके संबंध, overlap और differences को समझा। + +## डिज़ाइन { #design } + +फिर मैंने उस developer "API" को डिज़ाइन करने में कुछ समय लगाया जिसे मैं एक user के रूप में पाना चाहता था (FastAPI का उपयोग करने वाले developer के रूप में)। + +मैंने सबसे लोकप्रिय Python editors में कई ideas का परीक्षण किया: PyCharm, VS Code, Jedi आधारित editors। + +पिछले [Python Developer Survey](https://www.jetbrains.com/research/python-developers-survey-2018/#development-tools) के अनुसार, यह लगभग 80% users को कवर करता है। + +इसका मतलब है कि **FastAPI** को विशेष रूप से उन editors के साथ test किया गया था जिनका उपयोग 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 { #development } + +जब तक मैंने **FastAPI** खुद बनाना शुरू किया, तब तक अधिकांश हिस्से पहले से तैयार थे, design तय हो चुका था, requirements और tools तैयार थे, और standards तथा specifications के बारे में ज्ञान स्पष्ट और ताज़ा था। + +## भविष्य { #future } + +इस बिंदु तक, यह पहले से ही स्पष्ट है कि **FastAPI** अपने ideas के साथ कई लोगों के लिए उपयोगी साबित हो रहा है। + +इसे कई use cases के लिए बेहतर उपयुक्त होने के कारण पिछले विकल्पों पर चुना जा रहा है। + +कई developers और teams अपने projects के लिए पहले से ही **FastAPI** पर निर्भर हैं (मेरे और मेरी team सहित)। + +लेकिन फिर भी, अभी कई improvements और 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 0000000000..747e4da538 --- /dev/null +++ b/docs/hi/docs/project-generation.md @@ -0,0 +1,28 @@ +# Full Stack FastAPI Template { #full-stack-fastapi-template } + +Templates आम तौर पर एक विशिष्ट setup के साथ आते हैं, लेकिन उन्हें flexible और customizable होने के लिए डिज़ाइन किया जाता है। इससे आप उन्हें अपने project की आवश्यकताओं के अनुसार modify और adapt कर सकते हैं, जिससे वे एक बेहतरीन starting point बन जाते हैं। 🏁 + +आप शुरू करने के लिए इस template का उपयोग कर सकते हैं, क्योंकि इसमें आपके लिए बहुत सा initial setup, security, database और कुछ API endpoints पहले से तैयार हैं। + +GitHub Repository: [Full Stack FastAPI Template](https://github.com/tiangolo/full-stack-fastapi-template) + +## Full Stack FastAPI Template - 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 के अन्य parts का उपयोग। + - 🎨 frontend components के लिए [Tailwind CSS](https://tailwindcss.com) और [shadcn/ui](https://ui.shadcn.com)। + - 🤖 एक automatically generated 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 आधारित password recovery। +- ✅ [Pytest](https://pytest.org) के साथ tests। +- 📞 reverse proxy / load balancer के रूप में [Traefik](https://traefik.io)। +- 🚢 Docker Compose का उपयोग करके deployment instructions, जिसमें automatic HTTPS certificates handle करने के लिए frontend Traefik proxy setup करना शामिल है। +- 🏭 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 0000000000..09bb5a3dce --- /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 का type घोषित करने की अनुमति देते हैं। + +अपने variables के लिए types घोषित करके, editors और tools आपको बेहतर support दे सकते हैं। + +यह 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 के साथ Concatenate करता है। + +{* ../../docs_src/python_types/tutorial001_py310.py hl[2] *} + +### इसे edit करें { #edit-it } + +यह एक बहुत सरल program है। + +लेकिन अब कल्पना करें कि आप इसे scratch से लिख रहे थे। + +किसी point पर आप function define करना शुरू करते हैं, और आपके parameters तैयार हैं... + +लेकिन फिर आपको "वह method जो पहले अक्षर को upper case में बदलता है" call करना है। + +क्या वह `upper` था? क्या वह `uppercase` था? `first_uppercase`? `capitalize`? + +फिर, आप programmer के पुराने दोस्त, editor autocompletion के साथ कोशिश करते हैं। + +आप function का पहला parameter, `first_name`, फिर एक dot (`.`) type करते हैं और फिर completion trigger करने के लिए `Ctrl+Space` दबाते हैं। + +लेकिन, दुख की बात है, आपको कुछ भी उपयोगी नहीं मिलता: + +
+
+### Types जोड़ें { #add-types }
+
+आइए पिछले version की एक single line बदलते हैं।
+
+हम ठीक इस 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 declare करने जैसा नहीं है, जैसा कि इसमें होता:
+
+```Python
+ first_name="john", last_name="doe"
+```
+
+यह एक अलग चीज़ है।
+
+हम colons (`:`) का उपयोग कर रहे हैं, equals (`=`) का नहीं।
+
+और type hints जोड़ने से सामान्यतः यह नहीं बदलता कि बिना उनके जो होता, वह कैसे होता।
+
+लेकिन अब, कल्पना करें कि आप फिर से उस function को बनाने के बीच में हैं, लेकिन type hints के साथ।
+
+उसी point पर, आप `Ctrl+Space` के साथ autocomplete trigger करने की कोशिश करते हैं और आप देखते हैं:
+
+
+
+इसके साथ, आप options देखते हुए scroll कर सकते हैं, जब तक आपको वह न मिल जाए जो "पहचाना हुआ लगे":
+
+
+
+## और प्रेरणा { #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 declare करना { #declaring-types }
+
+आपने अभी type hints declare करने की मुख्य जगह देखी। Function parameters के रूप में।
+
+यही वह मुख्य जगह भी है जहाँ आप उन्हें **FastAPI** के साथ उपयोग करेंगे।
+
+### Simple types { #simple-types }
+
+आप सभी standard Python types declare कर सकते हैं, केवल `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 करने की आवश्यकता हो सकती है, उदाहरण के लिए जब आप declare करना चाहते हैं कि किसी चीज़ का "कोई भी 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]` declare किया जाएगा।
+
+जो 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" कहा जाता है।
+
+इस case में, `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 declare करने के लिए भी ऐसा ही करेंगे:
+
+{* ../../docs_src/python_types/tutorial007_py310.py hl[1] *}
+
+इसका मतलब है:
+
+* Variable `items_t` 3 items वाला एक `tuple` है, एक `int`, दूसरा `int`, और एक `str`।
+* Variable `items_s` एक `set` है, और इसके प्रत्येक item का type `bytes` है।
+
+#### Dict { #dict }
+
+`dict` define करने के लिए, आप 2 type parameters pass करते हैं, commas से separated।
+
+पहला 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 }
+
+आप declare कर सकते हैं कि कोई variable **कई types** में से कोई भी हो सकता है, उदाहरण के लिए, एक `int` या एक `str`।
+
+इसे define करने के लिए आप दोनों types को separate करने के लिए vertical bar (`|`) का उपयोग करते हैं।
+
+इसे "union" कहा जाता है, क्योंकि variable उन दो type sets के union में कुछ भी हो सकता है।
+
+```Python hl_lines="1"
+{!> ../../docs_src/python_types/tutorial008b_py310.py!}
+```
+
+इसका मतलब है कि `item` एक `int` या एक `str` हो सकता है।
+
+#### संभवतः `None` { #possibly-none }
+
+आप declare कर सकते हैं कि किसी 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 के रूप में declare कर सकते हैं।
+
+मान लें आपके पास एक class `Person` है, जिसमें एक name है:
+
+{* ../../docs_src/python_types/tutorial010_py310.py hl[1:3] *}
+
+फिर आप किसी variable को `Person` type का declare कर सकते हैं:
+
+{* ../../docs_src/python_types/tutorial010_py310.py hl[6] *}
+
+और फिर, फिर से, आपको पूरा editor support मिलता है:
+
+
+
+ध्यान दें कि इसका मतलब है "`one_person`, class `Person` का एक **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 होता है।
+
+फिर आप कुछ values के साथ उस class का एक instance create करते हैं और यह values को validate करेगा, उन्हें appropriate type में convert करेगा (अगर ऐसा case है) और आपको पूरे 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 पर आधारित है।
+
+आप यह सब practice में [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` में इस जगह का उपयोग **FastAPI** को अतिरिक्त metadata देने के लिए कर सकते हैं कि आप अपनी application को कैसे behave कराना चाहते हैं।
+
+याद रखने वाली महत्वपूर्ण बात यह है कि `Annotated` को pass किया गया **पहला *type parameter*** ही **actual type** होता है। बाकी सब, अन्य tools के लिए केवल metadata है।
+
+अभी के लिए, आपको बस यह जानना है कि `Annotated` मौजूद है, और यह standard Python है। 😎
+
+बाद में आप देखेंगे कि यह कितना **powerful** हो सकता है।
+
+/// tip | सुझाव
+
+यह तथ्य कि यह **standard Python** है, इसका मतलब है कि आपको अपने editor में, अपने code को analyze और refactor करने वाले tools के साथ, आदि, अभी भी **सबसे अच्छा possible developer experience** मिलेगा। ✨
+
+और यह भी कि आपका code कई अन्य Python tools और libraries के साथ बहुत compatible होगा। 🚀
+
+///
+
+## **FastAPI** में Type hints { #type-hints-in-fastapi }
+
+**FastAPI** इन type hints का लाभ उठाकर कई चीज़ें करता है।
+
+**FastAPI** के साथ आप type hints के साथ parameters 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 को:
+ * Data invalid होने पर client को लौटाए जाने वाले **automatic errors** generate करना।
+* OpenAPI का उपयोग करके API को **document** करने के लिए:
+ * जिसका उपयोग फिर automatic interactive documentation user interfaces द्वारा किया जाता है।
+
+यह सब abstract लग सकता है। चिंता न करें। आप यह सब action में [Tutorial - User Guide](tutorial/index.md) में देखेंगे।
+
+महत्वपूर्ण बात यह है कि 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 0000000000..0c143f726c
--- /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` नाम की एक डायरेक्टरी बनाता हूँ।
+
+और उसके अंदर हर प्रोजेक्ट के लिए एक डायरेक्टरी बनाता हूँ।
+
+