Sync fastapi docs from b5ca1324 on 2025-12-07
Issue Manager / issue-manager (push) Has been cancelled
Build Docs / changes (push) Has been cancelled
Build Docs / langs (push) Has been cancelled
Build Docs / build-docs (push) Has been cancelled
Build Docs / docs-all-green (push) Has been cancelled
Conflict detector / main (push) Has been cancelled
Test Redistribute / test-redistribute (fastapi) (push) Has been cancelled
Test Redistribute / test-redistribute (fastapi-slim) (push) Has been cancelled
Test Redistribute / test-redistribute-alls-green (push) Has been cancelled
Test / lint (push) Has been cancelled
Test / test (pydantic-v1, 3.10) (push) Has been cancelled
Test / test (pydantic-v1, 3.11) (push) Has been cancelled
Test / test (pydantic-v1, 3.13) (push) Has been cancelled
Test / test (pydantic-v1, 3.8) (push) Has been cancelled
Test / test (pydantic-v1, 3.9) (push) Has been cancelled
Test / test (pydantic-v2, 3.10) (push) Has been cancelled
Test / test (pydantic-v2, 3.11) (push) Has been cancelled
Test / test (pydantic-v2, 3.12) (push) Has been cancelled
Test / test (pydantic-v2, 3.13) (push) Has been cancelled
Test / test (pydantic-v2, 3.14) (push) Has been cancelled
Test / test (pydantic-v2, 3.8) (push) Has been cancelled
Test / test (pydantic-v2, 3.9) (push) Has been cancelled
Test / coverage-combine (push) Has been cancelled
Test / check (push) Has been cancelled
Label Approved / label-approved (push) Has been cancelled
FastAPI People Contributors / job (push) Has been cancelled
FastAPI People Sponsors / job (push) Has been cancelled
Update Topic Repos / topic-repos (push) Has been cancelled
FastAPI People / job (push) Has been cancelled
Test / test (pydantic-v1, 3.12) (push) Has been cancelled
Issue Manager / issue-manager (push) Has been cancelled
Build Docs / changes (push) Has been cancelled
Build Docs / langs (push) Has been cancelled
Build Docs / build-docs (push) Has been cancelled
Build Docs / docs-all-green (push) Has been cancelled
Conflict detector / main (push) Has been cancelled
Test Redistribute / test-redistribute (fastapi) (push) Has been cancelled
Test Redistribute / test-redistribute (fastapi-slim) (push) Has been cancelled
Test Redistribute / test-redistribute-alls-green (push) Has been cancelled
Test / lint (push) Has been cancelled
Test / test (pydantic-v1, 3.10) (push) Has been cancelled
Test / test (pydantic-v1, 3.11) (push) Has been cancelled
Test / test (pydantic-v1, 3.13) (push) Has been cancelled
Test / test (pydantic-v1, 3.8) (push) Has been cancelled
Test / test (pydantic-v1, 3.9) (push) Has been cancelled
Test / test (pydantic-v2, 3.10) (push) Has been cancelled
Test / test (pydantic-v2, 3.11) (push) Has been cancelled
Test / test (pydantic-v2, 3.12) (push) Has been cancelled
Test / test (pydantic-v2, 3.13) (push) Has been cancelled
Test / test (pydantic-v2, 3.14) (push) Has been cancelled
Test / test (pydantic-v2, 3.8) (push) Has been cancelled
Test / test (pydantic-v2, 3.9) (push) Has been cancelled
Test / coverage-combine (push) Has been cancelled
Test / check (push) Has been cancelled
Label Approved / label-approved (push) Has been cancelled
FastAPI People Contributors / job (push) Has been cancelled
FastAPI People Sponsors / job (push) Has been cancelled
Update Topic Repos / topic-repos (push) Has been cancelled
FastAPI People / job (push) Has been cancelled
Test / test (pydantic-v1, 3.12) (push) Has been cancelled
This commit is contained in:
The Scheduler
@@ -0,0 +1,570 @@
|
||||
tiangolo:
|
||||
login: tiangolo
|
||||
count: 808
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1326112?u=cb5d06e73a9e1998141b1641aa88e443c6717651&v=4
|
||||
url: https://github.com/tiangolo
|
||||
dependabot:
|
||||
login: dependabot
|
||||
count: 130
|
||||
avatarUrl: https://avatars.githubusercontent.com/in/29110?v=4
|
||||
url: https://github.com/apps/dependabot
|
||||
alejsdev:
|
||||
login: alejsdev
|
||||
count: 52
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/90076947?u=85ceac49fb87138aebe8d663912e359447329090&v=4
|
||||
url: https://github.com/alejsdev
|
||||
pre-commit-ci:
|
||||
login: pre-commit-ci
|
||||
count: 50
|
||||
avatarUrl: https://avatars.githubusercontent.com/in/68672?v=4
|
||||
url: https://github.com/apps/pre-commit-ci
|
||||
github-actions:
|
||||
login: github-actions
|
||||
count: 26
|
||||
avatarUrl: https://avatars.githubusercontent.com/in/15368?v=4
|
||||
url: https://github.com/apps/github-actions
|
||||
Kludex:
|
||||
login: Kludex
|
||||
count: 25
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7353520?u=df8a3f06ba8f55ae1967a3e2d5ed882903a4e330&v=4
|
||||
url: https://github.com/Kludex
|
||||
YuriiMotov:
|
||||
login: YuriiMotov
|
||||
count: 20
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/109919500?u=b9b13d598dddfab529a52d264df80a900bfe7060&v=4
|
||||
url: https://github.com/YuriiMotov
|
||||
dmontagu:
|
||||
login: dmontagu
|
||||
count: 17
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/35119617?u=540f30c937a6450812628b9592a1dfe91bbe148e&v=4
|
||||
url: https://github.com/dmontagu
|
||||
nilslindemann:
|
||||
login: nilslindemann
|
||||
count: 15
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6892179?u=1dca6a22195d6cd1ab20737c0e19a4c55d639472&v=4
|
||||
url: https://github.com/nilslindemann
|
||||
svlandeg:
|
||||
login: svlandeg
|
||||
count: 14
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/8796347?u=556c97650c27021911b0b9447ec55e75987b0e8a&v=4
|
||||
url: https://github.com/svlandeg
|
||||
euri10:
|
||||
login: euri10
|
||||
count: 13
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1104190?u=321a2e953e6645a7d09b732786c7a8061e0f8a8b&v=4
|
||||
url: https://github.com/euri10
|
||||
kantandane:
|
||||
login: kantandane
|
||||
count: 13
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3978368?u=cccc199291f991a73b1ebba5abc735a948e0bd16&v=4
|
||||
url: https://github.com/kantandane
|
||||
zhaohan-dong:
|
||||
login: zhaohan-dong
|
||||
count: 11
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/65422392?u=8260f8781f50248410ebfa4c9bf70e143fe5c9f2&v=4
|
||||
url: https://github.com/zhaohan-dong
|
||||
mariacamilagl:
|
||||
login: mariacamilagl
|
||||
count: 9
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/11489395?u=4adb6986bf3debfc2b8216ae701f2bd47d73da7d&v=4
|
||||
url: https://github.com/mariacamilagl
|
||||
handabaldeep:
|
||||
login: handabaldeep
|
||||
count: 9
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12239103?u=6c39ef15d14c6d5211f5dd775cc4842f8d7f2f3a&v=4
|
||||
url: https://github.com/handabaldeep
|
||||
vishnuvskvkl:
|
||||
login: vishnuvskvkl
|
||||
count: 8
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/84698110?u=8af5de0520dd4fa195f53c2850a26f57c0f6bc64&v=4
|
||||
url: https://github.com/vishnuvskvkl
|
||||
alissadb:
|
||||
login: alissadb
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/96190409?u=be42d85938c241be781505a5a872575be28b2906&v=4
|
||||
url: https://github.com/alissadb
|
||||
alv2017:
|
||||
login: alv2017
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31544722?v=4
|
||||
url: https://github.com/alv2017
|
||||
wshayes:
|
||||
login: wshayes
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/365303?u=07ca03c5ee811eb0920e633cc3c3db73dbec1aa5&v=4
|
||||
url: https://github.com/wshayes
|
||||
samuelcolvin:
|
||||
login: samuelcolvin
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4039449?u=42eb3b833047c8c4b4f647a031eaef148c16d93f&v=4
|
||||
url: https://github.com/samuelcolvin
|
||||
waynerv:
|
||||
login: waynerv
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/39515546?u=ec35139777597cdbbbddda29bf8b9d4396b429a9&v=4
|
||||
url: https://github.com/waynerv
|
||||
musicinmybrain:
|
||||
login: musicinmybrain
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6898909?u=9010312053e7141383b9bdf538036c7f37fbaba0&v=4
|
||||
url: https://github.com/musicinmybrain
|
||||
krishnamadhavan:
|
||||
login: krishnamadhavan
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31798870?u=950693b28f3ae01105fd545c046e46ca3d31ab06&v=4
|
||||
url: https://github.com/krishnamadhavan
|
||||
jekirl:
|
||||
login: jekirl
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/2546697?u=a027452387d85bd4a14834e19d716c99255fb3b7&v=4
|
||||
url: https://github.com/jekirl
|
||||
hitrust:
|
||||
login: hitrust
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3360631?u=5fa1f475ad784d64eb9666bdd43cc4d285dcc773&v=4
|
||||
url: https://github.com/hitrust
|
||||
ShahriyarR:
|
||||
login: ShahriyarR
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3852029?u=631b2ae59360ab380c524b32bc3d245aff1165af&v=4
|
||||
url: https://github.com/ShahriyarR
|
||||
adriangb:
|
||||
login: adriangb
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1755071?u=612704256e38d6ac9cbed24f10e4b6ac2da74ecb&v=4
|
||||
url: https://github.com/adriangb
|
||||
iudeen:
|
||||
login: iudeen
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10519440?u=f09cdd745e5bf16138f29b42732dd57c7f02bee1&v=4
|
||||
url: https://github.com/iudeen
|
||||
philipokiokio:
|
||||
login: philipokiokio
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/55271518?u=d30994d339aaaf1f6bf1b8fc810132016fbd4fdc&v=4
|
||||
url: https://github.com/philipokiokio
|
||||
AlexWendland:
|
||||
login: AlexWendland
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3949212?u=c4c0c615e0ea33d00bfe16b779cf6ebc0f58071c&v=4
|
||||
url: https://github.com/AlexWendland
|
||||
divums:
|
||||
login: divums
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1397556?v=4
|
||||
url: https://github.com/divums
|
||||
prostomarkeloff:
|
||||
login: prostomarkeloff
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/28061158?u=6918e39a1224194ba636e897461a02a20126d7ad&v=4
|
||||
url: https://github.com/prostomarkeloff
|
||||
frankie567:
|
||||
login: frankie567
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1144727?u=f3e79acfe4ed207e15c2145161a8a9759925fcd2&v=4
|
||||
url: https://github.com/frankie567
|
||||
nsidnev:
|
||||
login: nsidnev
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/22559461?u=a9cc3238217e21dc8796a1a500f01b722adb082c&v=4
|
||||
url: https://github.com/nsidnev
|
||||
pawamoy:
|
||||
login: pawamoy
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3999221?u=b030e4c89df2f3a36bc4710b925bdeb6745c9856&v=4
|
||||
url: https://github.com/pawamoy
|
||||
patrickmckenna:
|
||||
login: patrickmckenna
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3589536?u=53aef07250d226d35e526768e26891964907b41a&v=4
|
||||
url: https://github.com/patrickmckenna
|
||||
hukkin:
|
||||
login: hukkin
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3275109?u=77bb83759127965eacbfe67e2ca983066e964fde&v=4
|
||||
url: https://github.com/hukkin
|
||||
marcosmmb:
|
||||
login: marcosmmb
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6181089?u=03c50eec631857d84df5232890780d00a3f76903&v=4
|
||||
url: https://github.com/marcosmmb
|
||||
Serrones:
|
||||
login: Serrones
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/22691749?u=4795b880e13ca33a73e52fc0ef7dc9c60c8fce47&v=4
|
||||
url: https://github.com/Serrones
|
||||
uriyyo:
|
||||
login: uriyyo
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/32038156?u=c26ca9b821fcf6499b84db75f553d4980bf8d023&v=4
|
||||
url: https://github.com/uriyyo
|
||||
andrew222651:
|
||||
login: andrew222651
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/889657?u=d70187989940b085bcbfa3bedad8dbc5f3ab1fe7&v=4
|
||||
url: https://github.com/andrew222651
|
||||
rkbeatss:
|
||||
login: rkbeatss
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/23391143?u=56ab6bff50be950fa8cae5cf736f2ae66e319ff3&v=4
|
||||
url: https://github.com/rkbeatss
|
||||
asheux:
|
||||
login: asheux
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/22955146?u=4553ebf5b5a7c7fe031a46182083aa224faba2e1&v=4
|
||||
url: https://github.com/asheux
|
||||
blkst8:
|
||||
login: blkst8
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/49960770?u=7d8a6d5f0a75a5e9a865a2527edfd48895ea27ae&v=4
|
||||
url: https://github.com/blkst8
|
||||
ghandic:
|
||||
login: ghandic
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/23500353?u=e2e1d736f924d9be81e8bfc565b6d8836ba99773&v=4
|
||||
url: https://github.com/ghandic
|
||||
TeoZosa:
|
||||
login: TeoZosa
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13070236?u=96fdae85800ef85dcfcc4b5f8281dc8778c8cb7d&v=4
|
||||
url: https://github.com/TeoZosa
|
||||
graingert:
|
||||
login: graingert
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/413772?v=4
|
||||
url: https://github.com/graingert
|
||||
jaystone776:
|
||||
login: jaystone776
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/11191137?u=299205a95e9b6817a43144a48b643346a5aac5cc&v=4
|
||||
url: https://github.com/jaystone776
|
||||
zanieb:
|
||||
login: zanieb
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/2586601?u=e5c86f7ff3b859e7e183187ac2b17fd6ee32b3ab&v=4
|
||||
url: https://github.com/zanieb
|
||||
MicaelJarniac:
|
||||
login: MicaelJarniac
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/19514231?u=158c91874ea98d6e9e6f0c6db37ee2ce60c55ff2&v=4
|
||||
url: https://github.com/MicaelJarniac
|
||||
papb:
|
||||
login: papb
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/20914054?u=890511fae7ea90d887e2a65ce44a1775abba38d5&v=4
|
||||
url: https://github.com/papb
|
||||
tamird:
|
||||
login: tamird
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1535036?v=4
|
||||
url: https://github.com/tamird
|
||||
Nimitha-jagadeesha:
|
||||
login: Nimitha-jagadeesha
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/58389915?v=4
|
||||
url: https://github.com/Nimitha-jagadeesha
|
||||
lucaromagnoli:
|
||||
login: lucaromagnoli
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/38782977?u=15df02e806a2293af40ac619fba11dbe3c0c4fd4&v=4
|
||||
url: https://github.com/lucaromagnoli
|
||||
salmantec:
|
||||
login: salmantec
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/41512228?u=443551b893ff2425c59d5d021644f098cf7c68d5&v=4
|
||||
url: https://github.com/salmantec
|
||||
OCE1960:
|
||||
login: OCE1960
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/45076670?u=0e9a44712b92ffa89ddfbaa83c112f3f8e1d68e2&v=4
|
||||
url: https://github.com/OCE1960
|
||||
hamidrasti:
|
||||
login: hamidrasti
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/43915620?v=4
|
||||
url: https://github.com/hamidrasti
|
||||
valentinDruzhinin:
|
||||
login: valentinDruzhinin
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12831905?u=aae1ebc675c91e8fa582df4fcc4fc4128106344d&v=4
|
||||
url: https://github.com/valentinDruzhinin
|
||||
kkinder:
|
||||
login: kkinder
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1115018?u=c5e90284a9f5c5049eae1bb029e3655c7dc913ed&v=4
|
||||
url: https://github.com/kkinder
|
||||
kabirkhan:
|
||||
login: kabirkhan
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13891834?u=e0eabf792376443ac853e7dca6f550db4166fe35&v=4
|
||||
url: https://github.com/kabirkhan
|
||||
zamiramir:
|
||||
login: zamiramir
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/40475662?v=4
|
||||
url: https://github.com/zamiramir
|
||||
trim21:
|
||||
login: trim21
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13553903?u=3cadf0f02095c9621aa29df6875f53a80ca4fbfb&v=4
|
||||
url: https://github.com/trim21
|
||||
koxudaxi:
|
||||
login: koxudaxi
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/630670?u=507d8577b4b3670546b449c4c2ccbc5af40d72f7&v=4
|
||||
url: https://github.com/koxudaxi
|
||||
pablogamboa:
|
||||
login: pablogamboa
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12892536?u=326a57059ee0c40c4eb1b38413957236841c631b&v=4
|
||||
url: https://github.com/pablogamboa
|
||||
dconathan:
|
||||
login: dconathan
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/15098095?v=4
|
||||
url: https://github.com/dconathan
|
||||
Jamim:
|
||||
login: Jamim
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/5607572?u=9ce0b6a6d1a5124e28b3c04d8d26827ca328713a&v=4
|
||||
url: https://github.com/Jamim
|
||||
svalouch:
|
||||
login: svalouch
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/54674660?v=4
|
||||
url: https://github.com/svalouch
|
||||
marier-nico:
|
||||
login: marier-nico
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/30477068?u=c7df6af853c8f4163d1517814f3e9a0715c82713&v=4
|
||||
url: https://github.com/marier-nico
|
||||
Dustyposa:
|
||||
login: Dustyposa
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/27180793?u=5cf2877f50b3eb2bc55086089a78a36f07042889&v=4
|
||||
url: https://github.com/Dustyposa
|
||||
aviramha:
|
||||
login: aviramha
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/41201924?u=ce5d3ea7037c2e6b3f82eff87e2217d4fb63214b&v=4
|
||||
url: https://github.com/aviramha
|
||||
iwpnd:
|
||||
login: iwpnd
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6152183?u=ec59396e9437fff488791c5ecdf6d23f1f1ebf3a&v=4
|
||||
url: https://github.com/iwpnd
|
||||
raphaelauv:
|
||||
login: raphaelauv
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10202690?u=e6f86f5c0c3026a15d6b51792fa3e532b12f1371&v=4
|
||||
url: https://github.com/raphaelauv
|
||||
windson:
|
||||
login: windson
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1826682?u=8b28dcd716c46289f191f8828e01d74edd058bef&v=4
|
||||
url: https://github.com/windson
|
||||
sm-Fifteen:
|
||||
login: sm-Fifteen
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/516999?u=437c0c5038558c67e887ccd863c1ba0f846c03da&v=4
|
||||
url: https://github.com/sm-Fifteen
|
||||
sattosan:
|
||||
login: sattosan
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/20574756?u=b0d8474d2938189c6954423ae8d81d91013f80a8&v=4
|
||||
url: https://github.com/sattosan
|
||||
michaeloliverx:
|
||||
login: michaeloliverx
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/55017335?u=efb0cb6e261ff64d862fafb91ee80fc2e1f8a2ed&v=4
|
||||
url: https://github.com/michaeloliverx
|
||||
voegtlel:
|
||||
login: voegtlel
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/5764745?u=db8df3d70d427928ab6d7dbfc395a4a7109c1d1b&v=4
|
||||
url: https://github.com/voegtlel
|
||||
HarshaLaxman:
|
||||
login: HarshaLaxman
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/19939186?u=a112f38b0f6b4d4402dc8b51978b5a0b2e5c5970&v=4
|
||||
url: https://github.com/HarshaLaxman
|
||||
RunningIkkyu:
|
||||
login: RunningIkkyu
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31848542?u=494ecc298e3f26197495bb357ad0f57cfd5f7a32&v=4
|
||||
url: https://github.com/RunningIkkyu
|
||||
cassiobotaro:
|
||||
login: cassiobotaro
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3127847?u=a08022b191ddbd0a6159b2981d9d878b6d5bb71f&v=4
|
||||
url: https://github.com/cassiobotaro
|
||||
chenl:
|
||||
login: chenl
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1677651?u=c618508eaad6d596cea36c8ea784b424288f6857&v=4
|
||||
url: https://github.com/chenl
|
||||
retnikt:
|
||||
login: retnikt
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/24581770?v=4
|
||||
url: https://github.com/retnikt
|
||||
yankeexe:
|
||||
login: yankeexe
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13623913?u=f970e66421775a8d3cdab89c0c752eaead186f6d&v=4
|
||||
url: https://github.com/yankeexe
|
||||
patrickkwang:
|
||||
login: patrickkwang
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1263870?u=4bf74020e15be490f19ef8322a76eec882220b96&v=4
|
||||
url: https://github.com/patrickkwang
|
||||
victorphoenix3:
|
||||
login: victorphoenix3
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/48182195?u=e4875bd088623cb4ddeb7be194ec54b453aff035&v=4
|
||||
url: https://github.com/victorphoenix3
|
||||
davidefiocco:
|
||||
login: davidefiocco
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4547987?v=4
|
||||
url: https://github.com/davidefiocco
|
||||
adriencaccia:
|
||||
login: adriencaccia
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/19605940?u=9a59081f46bfc9d839886a49d5092cf572879049&v=4
|
||||
url: https://github.com/adriencaccia
|
||||
jamescurtin:
|
||||
login: jamescurtin
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10189269?u=0b491fc600ca51f41cf1d95b49fa32a3eba1de57&v=4
|
||||
url: https://github.com/jamescurtin
|
||||
jmriebold:
|
||||
login: jmriebold
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6983392?u=4efdc97bf2422dcc7e9ff65b9ff80087c8eb2a20&v=4
|
||||
url: https://github.com/jmriebold
|
||||
nukopy:
|
||||
login: nukopy
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/42367320?u=6061be0bd060506f6d564a8df3ae73fab048cdfe&v=4
|
||||
url: https://github.com/nukopy
|
||||
imba-tjd:
|
||||
login: imba-tjd
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/24759802?u=01e901a4fe004b4b126549d3ff1c4000fe3720b5&v=4
|
||||
url: https://github.com/imba-tjd
|
||||
johnthagen:
|
||||
login: johnthagen
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10340167?u=47147fc4e4db1f573bee3fe428deeacb3197bc5f&v=4
|
||||
url: https://github.com/johnthagen
|
||||
paxcodes:
|
||||
login: paxcodes
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13646646?u=e7429cc7ab11211ef762f4cd3efea7db6d9ef036&v=4
|
||||
url: https://github.com/paxcodes
|
||||
kaustubhgupta:
|
||||
login: kaustubhgupta
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/43691873?u=8dd738718ac7ffad4ef31e86b5d780a1141c695d&v=4
|
||||
url: https://github.com/kaustubhgupta
|
||||
kinuax:
|
||||
login: kinuax
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13321374?u=22dc9873d6d9f2c7e4fc44c6480c3505efb1531f&v=4
|
||||
url: https://github.com/kinuax
|
||||
wakabame:
|
||||
login: wakabame
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/35513518?u=41ef6b0a55076e5c540620d68fb006e386c2ddb0&v=4
|
||||
url: https://github.com/wakabame
|
||||
nzig:
|
||||
login: nzig
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7372858?u=e769add36ed73c778cdb136eb10bf96b1e119671&v=4
|
||||
url: https://github.com/nzig
|
||||
kristjanvalur:
|
||||
login: kristjanvalur
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6009543?u=1419f20bbfff8f031be8cb470962e7e62de2595e&v=4
|
||||
url: https://github.com/kristjanvalur
|
||||
yezz123:
|
||||
login: yezz123
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/52716203?u=21b53ce4115062b1e20cb513e64ca0000c2ef127&v=4
|
||||
url: https://github.com/yezz123
|
||||
softwarebloat:
|
||||
login: softwarebloat
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/16540684?v=4
|
||||
url: https://github.com/softwarebloat
|
||||
Lancetnik:
|
||||
login: Lancetnik
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/44573917?u=6eaa0cdd35259fba40a76b82e4903440cba03fa9&v=4
|
||||
url: https://github.com/Lancetnik
|
||||
joakimnordling:
|
||||
login: joakimnordling
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6637576?u=df5d99db9b899b399effd429f4358baaa6f7199c&v=4
|
||||
url: https://github.com/joakimnordling
|
||||
yogabonito:
|
||||
login: yogabonito
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7026269?v=4
|
||||
url: https://github.com/yogabonito
|
||||
s111d:
|
||||
login: s111d
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4954856?v=4
|
||||
url: https://github.com/s111d
|
||||
estebanx64:
|
||||
login: estebanx64
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10840422?u=1900887aeed268699e5ea6f3fb7db614f7b77cd3&v=4
|
||||
url: https://github.com/estebanx64
|
||||
ndimares:
|
||||
login: ndimares
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6267663?u=cfb27efde7a7212be8142abb6c058a1aeadb41b1&v=4
|
||||
url: https://github.com/ndimares
|
||||
rabinlamadong:
|
||||
login: rabinlamadong
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/170439781?v=4
|
||||
url: https://github.com/rabinlamadong
|
||||
AyushSinghal1794:
|
||||
login: AyushSinghal1794
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/89984761?v=4
|
||||
url: https://github.com/AyushSinghal1794
|
||||
gsheni:
|
||||
login: gsheni
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/8726321?u=ee3bd9ff6320f4715d1dd9671a3d55cccb65b984&v=4
|
||||
url: https://github.com/gsheni
|
||||
chailandau:
|
||||
login: chailandau
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/112015853?u=2e6aaf2b1647db43834aabeae8d8282b4ec01873&v=4
|
||||
url: https://github.com/chailandau
|
||||
DanielKusyDev:
|
||||
login: DanielKusyDev
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/36250676?u=2ea6114ff751fc48b55f231987a0e2582c6b1bd2&v=4
|
||||
url: https://github.com/DanielKusyDev
|
||||
DanielYang59:
|
||||
login: DanielYang59
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/80093591?u=63873f701c7c74aac83c906800a1dddc0bc8c92f&v=4
|
||||
url: https://github.com/DanielYang59
|
||||
blueswen:
|
||||
login: blueswen
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1564148?u=6d6b8cc8f2b5cef715e68d6175154a8a94d518ee&v=4
|
||||
url: https://github.com/blueswen
|
||||
Taoup:
|
||||
login: Taoup
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/22348542?v=4
|
||||
url: https://github.com/Taoup
|
||||
@@ -0,0 +1,430 @@
|
||||
Articles:
|
||||
English:
|
||||
- author: Apitally
|
||||
author_link: https://apitally.io
|
||||
link: https://apitally.io/blog/getting-started-with-logging-in-fastapi
|
||||
title: Getting started with logging in FastAPI
|
||||
- author: Balthazar Rouberol
|
||||
author_link: https://balthazar-rouberol.com
|
||||
link: https://blog.balthazar-rouberol.com/how-to-profile-a-fastapi-asynchronous-request
|
||||
title: How to profile a FastAPI asynchronous request
|
||||
- author: Stephen Siegert - Neon
|
||||
link: https://neon.tech/blog/deploy-a-serverless-fastapi-app-with-neon-postgres-and-aws-app-runner-at-any-scale
|
||||
title: Deploy a Serverless FastAPI App with Neon Postgres and AWS App Runner at any scale
|
||||
- author: Kurtis Pykes - NVIDIA
|
||||
link: https://developer.nvidia.com/blog/building-a-machine-learning-microservice-with-fastapi/
|
||||
title: Building a Machine Learning Microservice with FastAPI
|
||||
- author: Ravgeet Dhillon - Twilio
|
||||
link: https://www.twilio.com/en-us/blog/booking-appointments-twilio-notion-fastapi
|
||||
title: Booking Appointments with Twilio, Notion, and FastAPI
|
||||
- author: Abhinav Tripathi - Microsoft Blogs
|
||||
link: https://devblogs.microsoft.com/cosmosdb/azure-cosmos-db-python-and-fastapi/
|
||||
title: Write a Python data layer with Azure Cosmos DB and FastAPI
|
||||
- author: Donny Peeters
|
||||
author_link: https://github.com/Donnype
|
||||
link: https://bitestreams.com/blog/fastapi-sqlalchemy/
|
||||
title: 10 Tips for adding SQLAlchemy to FastAPI
|
||||
- author: Jessica Temporal
|
||||
author_link: https://jtemporal.com/socials
|
||||
link: https://jtemporal.com/tips-on-migrating-from-flask-to-fastapi-and-vice-versa/
|
||||
title: Tips on migrating from Flask to FastAPI and vice-versa
|
||||
- author: Ankit Anchlia
|
||||
author_link: https://linkedin.com/in/aanchlia21
|
||||
link: https://hackernoon.com/explore-how-to-effectively-use-jwt-with-fastapi
|
||||
title: Explore How to Effectively Use JWT With FastAPI
|
||||
- author: Nicoló Lino
|
||||
author_link: https://www.nlino.com
|
||||
link: https://github.com/softwarebloat/python-tracing-demo
|
||||
title: Instrument FastAPI with OpenTelemetry tracing and visualize traces in Grafana Tempo.
|
||||
- author: Mikhail Rozhkov, Elena Samuylova
|
||||
author_link: https://www.linkedin.com/in/mnrozhkov/
|
||||
link: https://www.evidentlyai.com/blog/fastapi-tutorial
|
||||
title: ML serving and monitoring with FastAPI and Evidently
|
||||
- author: Visual Studio Code Team
|
||||
author_link: https://code.visualstudio.com/
|
||||
link: https://code.visualstudio.com/docs/python/tutorial-fastapi
|
||||
title: FastAPI Tutorial in Visual Studio Code
|
||||
- author: Apitally
|
||||
author_link: https://apitally.io
|
||||
link: https://blog.apitally.io/fastapi-application-monitoring-made-easy
|
||||
title: FastAPI application monitoring made easy
|
||||
- author: John Philip
|
||||
author_link: https://medium.com/@amjohnphilip
|
||||
link: https://python.plainenglish.io/building-a-restful-api-with-fastapi-secure-signup-and-login-functionality-included-45cdbcb36106
|
||||
title: "Building a RESTful API with FastAPI: Secure Signup and Login Functionality Included"
|
||||
- author: Keshav Malik
|
||||
author_link: https://theinfosecguy.xyz/
|
||||
link: https://blog.theinfosecguy.xyz/building-a-crud-api-with-fastapi-and-supabase-a-step-by-step-guide
|
||||
title: Building a CRUD API with FastAPI and Supabase
|
||||
- author: Adejumo Ridwan Suleiman
|
||||
author_link: https://www.linkedin.com/in/adejumoridwan/
|
||||
link: https://medium.com/python-in-plain-english/build-an-sms-spam-classifier-serverless-database-with-faunadb-and-fastapi-23dbb275bc5b
|
||||
title: Build an SMS Spam Classifier Serverless Database with FaunaDB and FastAPI
|
||||
- author: Raf Rasenberg
|
||||
author_link: https://rafrasenberg.com/about/
|
||||
link: https://rafrasenberg.com/fastapi-lambda/
|
||||
title: 'FastAPI lambda container: serverless simplified'
|
||||
- author: Teresa N. Fontanella De Santis
|
||||
author_link: https://dev.to/
|
||||
link: https://dev.to/teresafds/authorization-on-fastapi-with-casbin-41og
|
||||
title: Authorization on FastAPI with Casbin
|
||||
- author: New Relic
|
||||
author_link: https://newrelic.com
|
||||
link: https://newrelic.com/instant-observability/fastapi/e559ec64-f765-4470-a15f-1901fcebb468
|
||||
title: How to monitor FastAPI application performance using Python agent
|
||||
- author: Jean-Baptiste Rocher
|
||||
author_link: https://hashnode.com/@jibrocher
|
||||
link: https://dev.indooroutdoor.io/series/fastapi-react-poll-app
|
||||
title: Building the Poll App From Django Tutorial With FastAPI And React
|
||||
- author: Silvan Melchior
|
||||
author_link: https://github.com/silvanmelchior
|
||||
link: https://blog.devgenius.io/seamless-fastapi-configuration-with-confz-90949c14ea12
|
||||
title: Seamless FastAPI Configuration with ConfZ
|
||||
- author: Kaustubh Gupta
|
||||
author_link: https://medium.com/@kaustubhgupta1828/
|
||||
link: https://levelup.gitconnected.com/5-advance-features-of-fastapi-you-should-try-7c0ac7eebb3e
|
||||
title: 5 Advanced Features of FastAPI You Should Try
|
||||
- author: Kaustubh Gupta
|
||||
author_link: https://medium.com/@kaustubhgupta1828/
|
||||
link: https://www.analyticsvidhya.com/blog/2021/06/deploying-ml-models-as-api-using-fastapi-and-heroku/
|
||||
title: Deploying ML Models as API Using FastAPI and Heroku
|
||||
- link: https://jarmos.netlify.app/posts/using-github-actions-to-deploy-a-fastapi-project-to-heroku/
|
||||
title: Using GitHub Actions to Deploy a FastAPI Project to Heroku
|
||||
author_link: https://jarmos.netlify.app/
|
||||
author: Somraj Saha
|
||||
- author: "@pystar"
|
||||
author_link: https://pystar.substack.com/
|
||||
link: https://pystar.substack.com/p/how-to-create-a-fake-certificate
|
||||
title: How to Create A Fake Certificate Authority And Generate TLS Certs for FastAPI
|
||||
- author: Ben Gamble
|
||||
author_link: https://uk.linkedin.com/in/bengamble7
|
||||
link: https://ably.com/blog/realtime-ticket-booking-solution-kafka-fastapi-ably
|
||||
title: Building a realtime ticket booking solution with Kafka, FastAPI, and Ably
|
||||
- author: Shahriyar(Shako) Rzayev
|
||||
author_link: https://www.linkedin.com/in/shahriyar-rzayev/
|
||||
link: https://www.azepug.az/posts/fastapi/#building-simple-e-commerce-with-nuxtjs-and-fastapi-series
|
||||
title: Building simple E-Commerce with NuxtJS and FastAPI
|
||||
- author: Rodrigo Arenas
|
||||
author_link: https://rodrigo-arenas.medium.com/
|
||||
link: https://medium.com/analytics-vidhya/serve-a-machine-learning-model-using-sklearn-fastapi-and-docker-85aabf96729b
|
||||
title: "Serve a machine learning model using Sklearn, FastAPI and Docker"
|
||||
- author: Yashasvi Singh
|
||||
author_link: https://hashnode.com/@aUnicornDev
|
||||
link: https://aunicorndev.hashnode.dev/series/supafast-api
|
||||
title: "Building an API with FastAPI and Supabase and Deploying on Deta"
|
||||
- author: Navule Pavan Kumar Rao
|
||||
author_link: https://www.linkedin.com/in/navule/
|
||||
link: https://www.tutlinks.com/deploy-fastapi-on-ubuntu-gunicorn-caddy-2/
|
||||
title: Deploy FastAPI on Ubuntu and Serve using Caddy 2 Web Server
|
||||
- author: Patrick Ladon
|
||||
author_link: https://dev.to/factorlive
|
||||
link: https://dev.to/factorlive/python-facebook-messenger-webhook-with-fastapi-on-glitch-4n90
|
||||
title: Python Facebook messenger webhook with FastAPI on Glitch
|
||||
- author: Valon Januzaj
|
||||
author_link: https://www.linkedin.com/in/valon-januzaj-b02692187/
|
||||
link: https://valonjanuzaj.medium.com/deploy-a-dockerized-fastapi-application-to-aws-cc757830ba1b
|
||||
title: Deploy a dockerized FastAPI application to AWS
|
||||
- author: Amit Chaudhary
|
||||
author_link: https://x.com/amitness
|
||||
link: https://amitness.com/2020/06/fastapi-vs-flask/
|
||||
title: FastAPI for Flask Users
|
||||
- author: Louis Guitton
|
||||
author_link: https://x.com/louis_guitton
|
||||
link: https://guitton.co/posts/fastapi-monitoring/
|
||||
title: How to monitor your FastAPI service
|
||||
- author: Precious Ndubueze
|
||||
author_link: https://medium.com/@gabbyprecious2000
|
||||
link: https://medium.com/@gabbyprecious2000/creating-a-crud-app-with-fastapi-part-one-7c049292ad37
|
||||
title: Creating a CRUD App with FastAPI (Part one)
|
||||
- author: Farhad Malik
|
||||
author_link: https://medium.com/@farhadmalik
|
||||
link: https://towardsdatascience.com/build-and-host-fast-data-science-applications-using-fastapi-823be8a1d6a0
|
||||
title: Build And Host Fast Data Science Applications Using FastAPI
|
||||
- author: Navule Pavan Kumar Rao
|
||||
author_link: https://www.linkedin.com/in/navule/
|
||||
link: https://www.tutlinks.com/deploy-fastapi-on-azure/
|
||||
title: Deploy FastAPI on Azure App Service
|
||||
- author: Davide Fiocco
|
||||
author_link: https://github.com/davidefiocco
|
||||
link: https://davidefiocco.github.io/streamlit-fastapi-ml-serving/
|
||||
title: Machine learning model serving in Python using FastAPI and streamlit
|
||||
- author: Netflix
|
||||
author_link: https://netflixtechblog.com/
|
||||
link: https://netflixtechblog.com/introducing-dispatch-da4b8a2a8072
|
||||
title: Introducing Dispatch
|
||||
- author: Stavros Korokithakis
|
||||
author_link: https://x.com/Stavros
|
||||
link: https://www.stavros.io/posts/fastapi-with-django/
|
||||
title: Using FastAPI with Django
|
||||
- author: Twilio
|
||||
author_link: https://www.twilio.com
|
||||
link: https://www.twilio.com/blog/build-secure-twilio-webhook-python-fastapi
|
||||
title: Build a Secure Twilio Webhook with Python and FastAPI
|
||||
- author: Sebastián Ramírez (tiangolo)
|
||||
author_link: https://x.com/tiangolo
|
||||
link: https://dev.to/tiangolo/build-a-web-api-from-scratch-with-fastapi-the-workshop-2ehe
|
||||
title: Build a web API from scratch with FastAPI - the workshop
|
||||
- author: Paul Sec
|
||||
author_link: https://x.com/PaulWebSec
|
||||
link: https://paulsec.github.io/posts/fastapi_plus_zeit_serverless_fu/
|
||||
title: FastAPI + Zeit.co = 🚀
|
||||
- author: cuongld2
|
||||
author_link: https://dev.to/cuongld2
|
||||
link: https://dev.to/cuongld2/build-simple-api-service-with-python-fastapi-part-1-581o
|
||||
title: Build simple API service with Python FastAPI — Part 1
|
||||
- author: Paurakh Sharma Humagain
|
||||
author_link: https://x.com/PaurakhSharma
|
||||
link: https://dev.to/paurakhsharma/microservice-in-python-using-fastapi-24cc
|
||||
title: Microservice in Python using FastAPI
|
||||
- author: Guillermo Cruz
|
||||
author_link: https://wuilly.com/
|
||||
link: https://wuilly.com/2019/10/real-time-notifications-with-python-and-postgres/
|
||||
title: Real-time Notifications with Python and Postgres
|
||||
- author: Navule Pavan Kumar Rao
|
||||
author_link: https://www.linkedin.com/in/navule/
|
||||
link: https://www.tutlinks.com/create-and-deploy-fastapi-app-to-heroku/
|
||||
title: Create and Deploy FastAPI app to Heroku without using Docker
|
||||
- author: Arthur Henrique
|
||||
author_link: https://x.com/arthurheinrique
|
||||
link: https://medium.com/@arthur393/another-boilerplate-to-fastapi-azure-pipeline-ci-pytest-3c8d9a4be0bb
|
||||
title: 'Another Boilerplate to FastAPI: Azure Pipeline CI + Pytest'
|
||||
- author: Shane Soh
|
||||
author_link: https://medium.com/@shane.soh
|
||||
link: https://medium.com/analytics-vidhya/deploy-machine-learning-models-with-keras-fastapi-redis-and-docker-4940df614ece
|
||||
title: Deploy Machine Learning Models with Keras, FastAPI, Redis and Docker
|
||||
- author: Mandy Gu
|
||||
author_link: https://towardsdatascience.com/@mandygu
|
||||
link: https://towardsdatascience.com/deploying-iris-classifications-with-fastapi-and-docker-7c9b83fdec3a
|
||||
title: 'Towards Data Science: Deploying Iris Classifications with FastAPI and Docker'
|
||||
- author: Michael Herman
|
||||
author_link: https://testdriven.io/authors/herman
|
||||
link: https://testdriven.io/blog/fastapi-crud/
|
||||
title: 'TestDriven.io: Developing and Testing an Asynchronous API with FastAPI and Pytest'
|
||||
- author: Bernard Brenyah
|
||||
author_link: https://medium.com/@bbrenyah
|
||||
link: https://medium.com/python-data/how-to-deploy-tensorflow-2-0-models-as-an-api-service-with-fastapi-docker-128b177e81f3
|
||||
title: How To Deploy Tensorflow 2.0 Models As An API Service With FastAPI & Docker
|
||||
- author: Dylan Anthony
|
||||
author_link: https://dev.to/dbanty
|
||||
link: https://dev.to/dbanty/why-i-m-leaving-flask-3ki6
|
||||
title: Why I'm Leaving Flask
|
||||
- author: Mike Moritz
|
||||
author_link: https://medium.com/@mike.p.moritz
|
||||
link: https://medium.com/@mike.p.moritz/using-docker-compose-to-deploy-a-lightweight-python-rest-api-with-a-job-queue-37e6072a209b
|
||||
title: Using Docker Compose to deploy a lightweight Python REST API with a job queue
|
||||
- author: '@euri10'
|
||||
author_link: https://gitlab.com/euri10
|
||||
link: https://gitlab.com/euri10/fastapi_cheatsheet
|
||||
title: A FastAPI and Swagger UI visual cheatsheet
|
||||
- author: Uber Engineering
|
||||
author_link: https://eng.uber.com
|
||||
link: https://eng.uber.com/ludwig-v0-2/
|
||||
title: 'Uber: Ludwig v0.2 Adds New Features and Other Improvements to its Deep Learning Toolbox [including a FastAPI server]'
|
||||
- author: Maarten Grootendorst
|
||||
author_link: https://www.linkedin.com/in/mgrootendorst/
|
||||
link: https://towardsdatascience.com/how-to-deploy-a-machine-learning-model-dc51200fe8cf
|
||||
title: How to Deploy a Machine Learning Model
|
||||
- author: Johannes Gontrum
|
||||
author_link: https://x.com/gntrm
|
||||
link: https://medium.com/@gntrm/jwt-authentication-with-fastapi-and-aws-cognito-1333f7f2729e
|
||||
title: JWT Authentication with FastAPI and AWS Cognito
|
||||
- author: Ankush Thakur
|
||||
author_link: https://geekflare.com/author/ankush/
|
||||
link: https://geekflare.com/python-asynchronous-web-frameworks/
|
||||
title: Top 5 Asynchronous Web Frameworks for Python
|
||||
- author: Nico Axtmann
|
||||
author_link: https://www.linkedin.com/in/nico-axtmann
|
||||
link: https://medium.com/@nico.axtmann95/deploying-a-scikit-learn-model-with-onnx-und-fastapi-1af398268915
|
||||
title: Deploying a scikit-learn model with ONNX and FastAPI
|
||||
- author: Nils de Bruin
|
||||
author_link: https://medium.com/@nilsdebruin
|
||||
link: https://medium.com/data-rebels/fastapi-authentication-revisited-enabling-api-key-authentication-122dc5975680
|
||||
title: 'FastAPI authentication revisited: Enabling API key authentication'
|
||||
- author: Nick Cortale
|
||||
author_link: https://nickc1.github.io/
|
||||
link: https://nickc1.github.io/api,/scikit-learn/2019/01/10/scikit-fastapi.html
|
||||
title: 'FastAPI and Scikit-Learn: Easily Deploy Models'
|
||||
- author: Errieta Kostala
|
||||
author_link: https://dev.to/errietta
|
||||
link: https://dev.to/errietta/introduction-to-the-fastapi-python-framework-2n10
|
||||
title: Introduction to the fastapi python framework
|
||||
- author: Nils de Bruin
|
||||
author_link: https://medium.com/@nilsdebruin
|
||||
link: https://medium.com/data-rebels/fastapi-how-to-add-basic-and-cookie-authentication-a45c85ef47d3
|
||||
title: FastAPI — How to add basic and cookie authentication
|
||||
- author: Nils de Bruin
|
||||
author_link: https://medium.com/@nilsdebruin
|
||||
link: https://medium.com/data-rebels/fastapi-google-as-an-external-authentication-provider-3a527672cf33
|
||||
title: FastAPI — Google as an external authentication provider
|
||||
- author: William Hayes
|
||||
author_link: https://medium.com/@williamhayes
|
||||
link: https://medium.com/@williamhayes/fastapi-starlette-debug-vs-prod-5f7561db3a59
|
||||
title: FastAPI/Starlette debug vs prod
|
||||
- author: Mukul Mantosh
|
||||
author_link: https://x.com/MantoshMukul
|
||||
link: https://www.jetbrains.com/pycharm/guide/tutorials/fastapi-aws-kubernetes/
|
||||
title: Developing FastAPI Application using K8s & AWS
|
||||
- author: KrishNa
|
||||
author_link: https://medium.com/@krishnardt365
|
||||
link: https://medium.com/@krishnardt365/fastapi-docker-and-postgres-91943e71be92
|
||||
title: Fastapi, Docker(Docker compose) and Postgres
|
||||
- author: Devon Ray
|
||||
author_link: https://devonray.com
|
||||
link: https://devonray.com/blog/deploying-a-fastapi-project-using-aws-lambda-aurora-cdk
|
||||
title: Deployment using Docker, Lambda, Aurora, CDK & GH Actions
|
||||
- author: Shubhendra Kushwaha
|
||||
author_link: https://www.linkedin.com/in/theshubhendra/
|
||||
link: https://theshubhendra.medium.com/mastering-soft-delete-advanced-sqlalchemy-techniques-4678f4738947
|
||||
title: 'Mastering Soft Delete: Advanced SQLAlchemy Techniques'
|
||||
- author: Shubhendra Kushwaha
|
||||
author_link: https://www.linkedin.com/in/theshubhendra/
|
||||
link: https://theshubhendra.medium.com/role-based-row-filtering-advanced-sqlalchemy-techniques-733e6b1328f6
|
||||
title: 'Role based row filtering: Advanced SQLAlchemy Techniques'
|
||||
German:
|
||||
- author: Marcel Sander (actidoo)
|
||||
author_link: https://www.actidoo.com
|
||||
link: https://www.actidoo.com/de/blog/python-fastapi-domain-driven-design
|
||||
title: Domain-driven Design mit Python und FastAPI
|
||||
- author: Nico Axtmann
|
||||
author_link: https://x.com/_nicoax
|
||||
link: https://blog.codecentric.de/2019/08/inbetriebnahme-eines-scikit-learn-modells-mit-onnx-und-fastapi/
|
||||
title: Inbetriebnahme eines scikit-learn-Modells mit ONNX und FastAPI
|
||||
- author: Felix Schürmeyer
|
||||
author_link: https://hellocoding.de/autor/felix-schuermeyer/
|
||||
link: https://hellocoding.de/blog/coding-language/python/fastapi
|
||||
title: REST-API Programmieren mittels Python und dem FastAPI Modul
|
||||
Japanese:
|
||||
- author: '@bee2'
|
||||
author_link: https://qiita.com/bee2
|
||||
link: https://qiita.com/bee2/items/75d9c0d7ba20e7a4a0e9
|
||||
title: '[FastAPI] Python製のASGI Web フレームワーク FastAPIに入門する'
|
||||
- author: '@bee2'
|
||||
author_link: https://qiita.com/bee2
|
||||
link: https://qiita.com/bee2/items/0ad260ab9835a2087dae
|
||||
title: PythonのWeb frameworkのパフォーマンス比較 (Django, Flask, responder, FastAPI, japronto)
|
||||
- author: ライトコードメディア編集部
|
||||
author_link: https://rightcode.co.jp/author/jun
|
||||
link: https://rightcode.co.jp/blog/information-technology/fastapi-tutorial-todo-apps-admin-page-improvement
|
||||
title: '【第4回】FastAPIチュートリアル: toDoアプリを作ってみよう【管理者ページ改良編】'
|
||||
- author: ライトコードメディア編集部
|
||||
author_link: https://rightcode.co.jp/author/jun
|
||||
link: https://rightcode.co.jp/blog/information-technology/fastapi-tutorial-todo-apps-authentication-user-registration
|
||||
title: '【第3回】FastAPIチュートリアル: toDoアプリを作ってみよう【認証・ユーザ登録編】'
|
||||
- author: ライトコードメディア編集部
|
||||
author_link: https://rightcode.co.jp/author/jun
|
||||
link: https://rightcode.co.jp/blog/information-technology/fastapi-tutorial-todo-apps-model-building
|
||||
title: '【第2回】FastAPIチュートリアル: ToDoアプリを作ってみよう【モデル構築編】'
|
||||
- author: ライトコードメディア編集部
|
||||
author_link: https://rightcode.co.jp/author/jun
|
||||
link: https://rightcode.co.jp/blog/information-technology/fastapi-tutorial-todo-apps-environment
|
||||
title: '【第1回】FastAPIチュートリアル: ToDoアプリを作ってみよう【環境構築編】'
|
||||
- author: Hikaru Takahashi
|
||||
author_link: https://qiita.com/hikarut
|
||||
link: https://qiita.com/hikarut/items/b178af2e2440c67c6ac4
|
||||
title: フロントエンド開発者向けのDockerによるPython開発環境構築
|
||||
- author: '@angel_katayoku'
|
||||
author_link: https://qiita.com/angel_katayoku
|
||||
link: https://qiita.com/angel_katayoku/items/8a458a8952f50b73f420
|
||||
title: FastAPIでPOSTされたJSONのレスポンスbodyを受け取る
|
||||
- author: '@angel_katayoku'
|
||||
author_link: https://qiita.com/angel_katayoku
|
||||
link: https://qiita.com/angel_katayoku/items/4fbc1a4e2b33fa2237d2
|
||||
title: FastAPIをMySQLと接続してDockerで管理してみる
|
||||
- author: '@angel_katayoku'
|
||||
author_link: https://qiita.com/angel_katayoku
|
||||
link: https://qiita.com/angel_katayoku/items/0e1f5dbbe62efc612a78
|
||||
title: FastAPIでCORSを回避
|
||||
- author: '@ryoryomaru'
|
||||
author_link: https://qiita.com/ryoryomaru
|
||||
link: https://qiita.com/ryoryomaru/items/59958ed385b3571d50de
|
||||
title: python製の最新APIフレームワーク FastAPI を触ってみた
|
||||
- author: '@mtitg'
|
||||
author_link: https://qiita.com/mtitg
|
||||
link: https://qiita.com/mtitg/items/47770e9a562dd150631d
|
||||
title: FastAPI｜DB接続してCRUDするPython製APIサーバーを構築
|
||||
Portuguese:
|
||||
- author: Eduardo Mendes
|
||||
author_link: https://bolha.us/@dunossauro
|
||||
link: https://fastapidozero.dunossauro.com/
|
||||
title: FastAPI do ZERO
|
||||
- author: Jessica Temporal
|
||||
author_link: https://jtemporal.com/socials
|
||||
link: https://jtemporal.com/dicas-para-migrar-de-flask-para-fastapi-e-vice-versa/
|
||||
title: Dicas para migrar uma aplicação de Flask para FastAPI e vice-versa
|
||||
Russian:
|
||||
- author: Troy Köhler
|
||||
author_link: https://www.linkedin.com/in/trkohler/
|
||||
link: https://trkohler.com/fast-api-introduction-to-framework
|
||||
title: 'FastAPI: знакомимся с фреймворком'
|
||||
- author: prostomarkeloff
|
||||
author_link: https://github.com/prostomarkeloff
|
||||
link: https://habr.com/ru/post/478620/
|
||||
title: Почему Вы должны попробовать FastAPI?
|
||||
- author: Andrey Korchak
|
||||
author_link: https://habr.com/ru/users/57uff3r/
|
||||
link: https://habr.com/ru/post/454440/
|
||||
title: 'Мелкая питонячая радость #2: Starlette - Солидная примочка – FastAPI'
|
||||
Vietnamese:
|
||||
- author: Nguyễn Nhân
|
||||
author_link: https://fullstackstation.com/author/figonking/
|
||||
link: https://fullstackstation.com/fastapi-trien-khai-bang-docker/
|
||||
title: 'FASTAPI: TRIỂN KHAI BẰNG DOCKER'
|
||||
Taiwanese:
|
||||
- author: Leon
|
||||
author_link: http://editor.leonh.space/
|
||||
link: https://editor.leonh.space/2022/tortoise/
|
||||
title: 'Tortoise ORM / FastAPI 整合快速筆記'
|
||||
Spanish:
|
||||
- author: Eduardo Zepeda
|
||||
author_link: https://coffeebytes.dev/en/authors/eduardo-zepeda/
|
||||
link: https://coffeebytes.dev/es/python-fastapi-el-mejor-framework-de-python/
|
||||
title: 'Tutorial de FastAPI, ¿el mejor framework de Python?'
|
||||
Podcasts:
|
||||
English:
|
||||
- author: Behind the Commit
|
||||
author_link: https://www.youtube.com/@BehindtheCommit
|
||||
link: https://youtu.be/iaDRYUQ0OMM
|
||||
title: Why FastAPI Became Python’s Fastest‑Growing Framework – Chat with Sebastián Ramírez
|
||||
- author: Real Python
|
||||
author_link: https://realpython.com/
|
||||
link: https://realpython.com/podcasts/rpp/72/
|
||||
title: Starting With FastAPI and Examining Python's Import System - Episode 72
|
||||
- author: Python Bytes FM
|
||||
author_link: https://pythonbytes.fm/
|
||||
link: https://www.pythonpodcast.com/fastapi-web-application-framework-episode-259/
|
||||
title: 'Do you dare to press "."? - Episode 247 - Dan #6: SQLModel - use the same models for SQL and FastAPI'
|
||||
- author: Podcast.`__init__`
|
||||
author_link: https://www.pythonpodcast.com/
|
||||
link: https://www.pythonpodcast.com/fastapi-web-application-framework-episode-259/
|
||||
title: Build The Next Generation Of Python Web Applications With FastAPI - Episode 259 - interview to Sebastían Ramírez (tiangolo)
|
||||
- author: Python Bytes FM
|
||||
author_link: https://pythonbytes.fm/
|
||||
link: https://pythonbytes.fm/episodes/show/123/time-to-right-the-py-wrongs?time_in_sec=855
|
||||
title: FastAPI on PythonBytes
|
||||
Talks:
|
||||
English:
|
||||
- author: Sebastián Ramírez (tiangolo)
|
||||
author_link: https://x.com/tiangolo
|
||||
link: https://www.youtube.com/watch?v=mwvmfl8nN_U
|
||||
title: 'Keynote: Behind the scenes of FastAPI and friends for developers and builders — Sebastián Ramírez'
|
||||
- author: Jeny Sadadia
|
||||
author_link: https://github.com/JenySadadia
|
||||
link: https://www.youtube.com/watch?v=uZdTe8_Z6BQ
|
||||
title: 'PyCon AU 2023: Testing asynchronous applications with FastAPI and pytest'
|
||||
- author: Sebastián Ramírez (tiangolo)
|
||||
author_link: https://x.com/tiangolo
|
||||
link: https://www.youtube.com/watch?v=PnpTY1f4k2U
|
||||
title: '[VIRTUAL] Py.Amsterdam''s flying Software Circus: Intro to FastAPI'
|
||||
- author: Sebastián Ramírez (tiangolo)
|
||||
author_link: https://x.com/tiangolo
|
||||
link: https://www.youtube.com/watch?v=z9K5pwb0rt8
|
||||
title: 'PyConBY 2020: Serve ML models easily with FastAPI'
|
||||
- author: Chris Withers
|
||||
author_link: https://x.com/chriswithers13
|
||||
link: https://www.youtube.com/watch?v=3DLwPcrE5mA
|
||||
title: 'PyCon UK 2019: FastAPI from the ground up'
|
||||
Taiwanese:
|
||||
- author: Blueswen
|
||||
author_link: https://github.com/blueswen
|
||||
link: https://www.youtube.com/watch?v=y3sumuoDq4w
|
||||
title: 'PyCon TW 2024: 全方位強化 Python 服務可觀測性：以 FastAPI 和 Grafana Stack 為例'
|
||||
@@ -0,0 +1,397 @@
|
||||
sponsors:
|
||||
- - login: renderinc
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/36424661?v=4
|
||||
url: https://github.com/renderinc
|
||||
- login: andrew-propelauth
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/89474256?u=c98993dec8553c09d424ede67bbe86e5c35f48c9&v=4
|
||||
url: https://github.com/andrew-propelauth
|
||||
- login: blockbee-io
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/115143449?u=1b8620c2d6567c4df2111a371b85a51f448f9b85&v=4
|
||||
url: https://github.com/blockbee-io
|
||||
- login: zuplo
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/85497839?v=4
|
||||
url: https://github.com/zuplo
|
||||
- login: coderabbitai
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/132028505?v=4
|
||||
url: https://github.com/coderabbitai
|
||||
- login: greptileai
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/140149887?v=4
|
||||
url: https://github.com/greptileai
|
||||
- login: subtotal
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/176449348?v=4
|
||||
url: https://github.com/subtotal
|
||||
- login: railwayapp
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/66716858?v=4
|
||||
url: https://github.com/railwayapp
|
||||
- - login: dribia
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/41189616?v=4
|
||||
url: https://github.com/dribia
|
||||
- login: svix
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/80175132?v=4
|
||||
url: https://github.com/svix
|
||||
- login: stainless-api
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/88061651?v=4
|
||||
url: https://github.com/stainless-api
|
||||
- login: speakeasy-api
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/91446104?v=4
|
||||
url: https://github.com/speakeasy-api
|
||||
- login: databento
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/64141749?v=4
|
||||
url: https://github.com/databento
|
||||
- login: permitio
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/71775833?v=4
|
||||
url: https://github.com/permitio
|
||||
- - login: Ponte-Energy-Partners
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/114745848?v=4
|
||||
url: https://github.com/Ponte-Energy-Partners
|
||||
- login: LambdaTest-Inc
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/171592363?u=96606606a45fa170427206199014f2a5a2a4920b&v=4
|
||||
url: https://github.com/LambdaTest-Inc
|
||||
- login: BoostryJP
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/57932412?v=4
|
||||
url: https://github.com/BoostryJP
|
||||
- login: requestly
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12287519?v=4
|
||||
url: https://github.com/requestly
|
||||
- login: acsone
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7601056?v=4
|
||||
url: https://github.com/acsone
|
||||
- - login: scalar
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/301879?v=4
|
||||
url: https://github.com/scalar
|
||||
- login: Trivie
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/8161763?v=4
|
||||
url: https://github.com/Trivie
|
||||
- - login: takashi-yoneya
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/33813153?u=2d0522bceba0b8b69adf1f2db866503bd96f944e&v=4
|
||||
url: https://github.com/takashi-yoneya
|
||||
- login: Doist
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/2565372?v=4
|
||||
url: https://github.com/Doist
|
||||
- login: bholagabbar
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/11693595?v=4
|
||||
url: https://github.com/bholagabbar
|
||||
- - login: mainframeindustries
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/55092103?v=4
|
||||
url: https://github.com/mainframeindustries
|
||||
- - login: alixlahuec
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/29543316?u=44357eb2a93bccf30fb9d389b8befe94a3d00985&v=4
|
||||
url: https://github.com/alixlahuec
|
||||
- - login: primer-io
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/62146168?v=4
|
||||
url: https://github.com/primer-io
|
||||
- - login: upciti
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/43346262?v=4
|
||||
url: https://github.com/upciti
|
||||
- login: ChargeStorm
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/26000165?v=4
|
||||
url: https://github.com/ChargeStorm
|
||||
- login: nilslindemann
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6892179?u=1dca6a22195d6cd1ab20737c0e19a4c55d639472&v=4
|
||||
url: https://github.com/nilslindemann
|
||||
- - login: samuelcolvin
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4039449?u=42eb3b833047c8c4b4f647a031eaef148c16d93f&v=4
|
||||
url: https://github.com/samuelcolvin
|
||||
- login: otosky
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/42260747?u=69d089387c743d89427aa4ad8740cfb34045a9e0&v=4
|
||||
url: https://github.com/otosky
|
||||
- login: ramonalmeidam
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/45269580?u=3358750b3a5854d7c3ed77aaca7dd20a0f529d32&v=4
|
||||
url: https://github.com/ramonalmeidam
|
||||
- login: roboflow
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/53104118?v=4
|
||||
url: https://github.com/roboflow
|
||||
- login: dudikbender
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/53487583?u=3a57542938ebfd57579a0111db2b297e606d9681&v=4
|
||||
url: https://github.com/dudikbender
|
||||
- login: ehaca
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/25950317?u=cec1a3e0643b785288ae8260cc295a85ab344995&v=4
|
||||
url: https://github.com/ehaca
|
||||
- login: raphaellaude
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/28026311?u=91e1c00d9ac4f8045527e13de8050d504531cbc0&v=4
|
||||
url: https://github.com/raphaellaude
|
||||
- login: timlrx
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/28362229?u=9a745ca31372ee324af682715ae88ce8522f9094&v=4
|
||||
url: https://github.com/timlrx
|
||||
- login: Leay15
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/32212558?u=c4aa9c1737e515959382a5515381757b1fd86c53&v=4
|
||||
url: https://github.com/Leay15
|
||||
- login: Karine-Bauch
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/90465103?u=7feb1018abb1a5631cfd9a91fea723d1ceb5f49b&v=4
|
||||
url: https://github.com/Karine-Bauch
|
||||
- login: jugeeem
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/116043716?u=ae590d79c38ac79c91b9c5caa6887d061e865a3d&v=4
|
||||
url: https://github.com/jugeeem
|
||||
- login: patsatsia
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/61111267?u=3271b85f7a37b479c8d0ae0a235182e83c166edf&v=4
|
||||
url: https://github.com/patsatsia
|
||||
- login: anthonycepeda
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/72019805?u=60bdf46240cff8fca482ff0fc07d963fd5e1a27c&v=4
|
||||
url: https://github.com/anthonycepeda
|
||||
- login: patricioperezv
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/73832292?u=5f471f156e19ee7920e62ae0f4a47b95580e61cf&v=4
|
||||
url: https://github.com/patricioperezv
|
||||
- login: chickenandstats
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/79477966?u=ae2b894aa954070db1d7830dab99b49eba4e4567&v=4
|
||||
url: https://github.com/chickenandstats
|
||||
- login: kaoru0310
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/80977929?u=1b61d10142b490e56af932ddf08a390fae8ee94f&v=4
|
||||
url: https://github.com/kaoru0310
|
||||
- login: jstanden
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/63288?u=c3658d57d2862c607a0e19c2101c3c51876e36ad&v=4
|
||||
url: https://github.com/jstanden
|
||||
- login: knallgelb
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/2358812?u=c48cb6362b309d74cbf144bd6ad3aed3eb443e82&v=4
|
||||
url: https://github.com/knallgelb
|
||||
- login: dblackrun
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3528486?v=4
|
||||
url: https://github.com/dblackrun
|
||||
- login: zsinx6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3532625?u=ba75a5dc744d1116ccfeaaf30d41cb2fe81fe8dd&v=4
|
||||
url: https://github.com/zsinx6
|
||||
- login: kennywakeland
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3631417?u=7c8f743f1ae325dfadea7c62bbf1abd6a824fc55&v=4
|
||||
url: https://github.com/kennywakeland
|
||||
- login: aacayaco
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3634801?u=eaadda178c964178fcb64886f6c732172c8f8219&v=4
|
||||
url: https://github.com/aacayaco
|
||||
- login: anomaly
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3654837?v=4
|
||||
url: https://github.com/anomaly
|
||||
- login: mj0331
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3890353?u=1c627ac1a024515b4871de5c3ebbfaa1a57f65d4&v=4
|
||||
url: https://github.com/mj0331
|
||||
- login: gorhack
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4141690?u=ec119ebc4bdf00a7bc84657a71aa17834f4f27f3&v=4
|
||||
url: https://github.com/gorhack
|
||||
- login: Ryandaydev
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4292423?u=679ff84cb7b988c5795a5fa583857f574a055763&v=4
|
||||
url: https://github.com/Ryandaydev
|
||||
- login: jaredtrog
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4381365?v=4
|
||||
url: https://github.com/jaredtrog
|
||||
- login: oliverxchen
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4471774?u=534191f25e32eeaadda22dfab4b0a428733d5489&v=4
|
||||
url: https://github.com/oliverxchen
|
||||
- login: paulcwatts
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/150269?u=1819e145d573b44f0ad74b87206d21cd60331d4e&v=4
|
||||
url: https://github.com/paulcwatts
|
||||
- login: robintw
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/296686?v=4
|
||||
url: https://github.com/robintw
|
||||
- login: pamelafox
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/297042?v=4
|
||||
url: https://github.com/pamelafox
|
||||
- login: wshayes
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/365303?u=07ca03c5ee811eb0920e633cc3c3db73dbec1aa5&v=4
|
||||
url: https://github.com/wshayes
|
||||
- login: koxudaxi
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/630670?u=507d8577b4b3670546b449c4c2ccbc5af40d72f7&v=4
|
||||
url: https://github.com/koxudaxi
|
||||
- login: falkben
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/653031?u=ad9838e089058c9e5a0bab94c0eec7cc181e0cd0&v=4
|
||||
url: https://github.com/falkben
|
||||
- login: mintuhouse
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/769950?u=ecfbd79a97d33177e0d093ddb088283cf7fe8444&v=4
|
||||
url: https://github.com/mintuhouse
|
||||
- login: dodo5522
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1362607?u=9bf1e0e520cccc547c046610c468ce6115bbcf9f&v=4
|
||||
url: https://github.com/dodo5522
|
||||
- login: wdwinslow
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/11562137?u=371272f2c69e680e0559a7b0a57385e83a5dc728&v=4
|
||||
url: https://github.com/wdwinslow
|
||||
- login: jsoques
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12414216?u=620921d94196546cc8b9eae2cc4cbc3f95bab42f&v=4
|
||||
url: https://github.com/jsoques
|
||||
- login: dannywade
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13680237?u=418ee985bd41577b20fde81417fb2d901e875e8a&v=4
|
||||
url: https://github.com/dannywade
|
||||
- login: khadrawy
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13686061?u=59f25ef42ecf04c22657aac4238ce0e2d3d30304&v=4
|
||||
url: https://github.com/khadrawy
|
||||
- login: mjohnsey
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/16784016?u=38fad2e6b411244560b3af99c5f5a4751bc81865&v=4
|
||||
url: https://github.com/mjohnsey
|
||||
- login: ashi-agrawal
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/17105294?u=99c7a854035e5398d8e7b674f2d42baae6c957f8&v=4
|
||||
url: https://github.com/ashi-agrawal
|
||||
- login: RaamEEIL
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/20320552?v=4
|
||||
url: https://github.com/RaamEEIL
|
||||
- login: ternaus
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/5481618?u=513a26b02a39e7a28d587cd37c6cc877ea368e6e&v=4
|
||||
url: https://github.com/ternaus
|
||||
- login: eseglem
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/5920492?u=208d419cf667b8ac594c82a8db01932c7e50d057&v=4
|
||||
url: https://github.com/eseglem
|
||||
- login: FernandoCelmer
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6262214?u=58ba6d5888fa7f355934e52db19f950e20b38162&v=4
|
||||
url: https://github.com/FernandoCelmer
|
||||
- login: Rehket
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7015688?u=3afb0ba200feebbc7f958950e92db34df2a3c172&v=4
|
||||
url: https://github.com/Rehket
|
||||
- login: hiancdtrsnm
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7343177?v=4
|
||||
url: https://github.com/hiancdtrsnm
|
||||
- - login: manoelpqueiroz
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/23669137?u=b12e84b28a84369ab5b30bd5a79e5788df5a0756&v=4
|
||||
url: https://github.com/manoelpqueiroz
|
||||
- - login: pawamoy
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3999221?u=b030e4c89df2f3a36bc4710b925bdeb6745c9856&v=4
|
||||
url: https://github.com/pawamoy
|
||||
- login: siavashyj
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/43583410?u=562005ddc7901cd27a1219a118a2363817b14977&v=4
|
||||
url: https://github.com/siavashyj
|
||||
- login: mobyw
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/44370805?v=4
|
||||
url: https://github.com/mobyw
|
||||
- login: ArtyomVancyan
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/44609997?v=4
|
||||
url: https://github.com/ArtyomVancyan
|
||||
- login: caviri
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/45425937?u=5f3d66ea5edea94c028c51ebf1c0f3b37e6c3db5&v=4
|
||||
url: https://github.com/caviri
|
||||
- login: hgalytoby
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/50397689?u=6cc9028f3db63f8f60ad21c17b1ce4b88c4e2e60&v=4
|
||||
url: https://github.com/hgalytoby
|
||||
- login: nisutec
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/25281462?u=e562484c451fdfc59053163f64405f8eb262b8b0&v=4
|
||||
url: https://github.com/nisutec
|
||||
- login: hoenie-ams
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/25708487?u=cda07434f0509ac728d9edf5e681117c0f6b818b&v=4
|
||||
url: https://github.com/hoenie-ams
|
||||
- login: joerambo
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/26282974?v=4
|
||||
url: https://github.com/joerambo
|
||||
- login: engineerjoe440
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/33275230?u=eb223cad27017bb1e936ee9b429b450d092d0236&v=4
|
||||
url: https://github.com/engineerjoe440
|
||||
- login: bnkc
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/34930566?u=db5e6f4f87836cad26c2aa90ce390ce49041c5a9&v=4
|
||||
url: https://github.com/bnkc
|
||||
- login: petercool
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/37613029?u=75aa8c6729e6e8f85a300561c4dbeef9d65c8797&v=4
|
||||
url: https://github.com/petercool
|
||||
- login: johnl28
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/54412955?u=47dd06082d1c39caa90c752eb55566e4f3813957&v=4
|
||||
url: https://github.com/johnl28
|
||||
- login: PunRabbit
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/70463212?u=1a835cfbc99295a60c8282f6aa6199d1b42241a5&v=4
|
||||
url: https://github.com/PunRabbit
|
||||
- login: PelicanQ
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/77930606?v=4
|
||||
url: https://github.com/PelicanQ
|
||||
- login: WillHogan
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1661551?u=8a80356e3e7d5a417157aba7ea565dabc8678327&v=4
|
||||
url: https://github.com/WillHogan
|
||||
- login: my3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1825270?v=4
|
||||
url: https://github.com/my3
|
||||
- login: danielunderwood
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4472301?v=4
|
||||
url: https://github.com/danielunderwood
|
||||
- login: ddanier
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/113563?u=ed1dc79de72f93bd78581f88ebc6952b62f472da&v=4
|
||||
url: https://github.com/ddanier
|
||||
- login: bryanculbertson
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/144028?u=defda4f90e93429221cc667500944abde60ebe4a&v=4
|
||||
url: https://github.com/bryanculbertson
|
||||
- login: slafs
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/210173?v=4
|
||||
url: https://github.com/slafs
|
||||
- login: ceb10n
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/235213?u=edcce471814a1eba9f0cdaa4cd0de18921a940a6&v=4
|
||||
url: https://github.com/ceb10n
|
||||
- login: tochikuji
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/851759?v=4
|
||||
url: https://github.com/tochikuji
|
||||
- login: miguelgr
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1484589?u=54556072b8136efa12ae3b6902032ea2a39ace4b&v=4
|
||||
url: https://github.com/miguelgr
|
||||
- login: xncbf
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/9462045?u=a80a7bb349555b277645632ed66639ff43400614&v=4
|
||||
url: https://github.com/xncbf
|
||||
- login: DMantis
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/9536869?u=652dd0d49717803c0cbcbf44f7740e53cf2d4892&v=4
|
||||
url: https://github.com/DMantis
|
||||
- login: hard-coders
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/9651103?u=95db33927bbff1ed1c07efddeb97ac2ff33068ed&v=4
|
||||
url: https://github.com/hard-coders
|
||||
- login: mntolia
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10390224?v=4
|
||||
url: https://github.com/mntolia
|
||||
- login: Zuzah
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10934846?u=1ef43e075ddc87bd1178372bf4d95ee6175cae27&v=4
|
||||
url: https://github.com/Zuzah
|
||||
- login: TheR1D
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/16740832?u=b0dfdbdb27b79729430c71c6128962f77b7b53f7&v=4
|
||||
url: https://github.com/TheR1D
|
||||
- login: joshuatz
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/17817563?u=f1bf05b690d1fc164218f0b420cdd3acb7913e21&v=4
|
||||
url: https://github.com/joshuatz
|
||||
- login: rangulvers
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/5235430?u=e254d4af4ace5a05fa58372ae677c7d26f0d5a53&v=4
|
||||
url: https://github.com/rangulvers
|
||||
- login: sdevkota
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/5250987?u=4ed9a120c89805a8aefda1cbdc0cf6512e64d1b4&v=4
|
||||
url: https://github.com/sdevkota
|
||||
- login: Baghdady92
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/5708590?v=4
|
||||
url: https://github.com/Baghdady92
|
||||
- login: KentShikama
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6329898?u=8b236810db9b96333230430837e1f021f9246da1&v=4
|
||||
url: https://github.com/KentShikama
|
||||
- login: katnoria
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7674948?u=09767eb13e07e09496c5fee4e5ce21d9eac34a56&v=4
|
||||
url: https://github.com/katnoria
|
||||
- login: harsh183
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7780198?v=4
|
||||
url: https://github.com/harsh183
|
||||
- login: moonape1226
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/8532038?u=d9f8b855a429fff9397c3833c2ff83849ebf989d&v=4
|
||||
url: https://github.com/moonape1226
|
||||
- - login: andrecorumba
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/37807517?u=9b9be3b41da9bda60957da9ef37b50dbf65baa61&v=4
|
||||
url: https://github.com/andrecorumba
|
||||
- login: KOZ39
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/38822500?u=9dfc0a697df1c9628f08e20dc3fb17b1afc4e5a7&v=4
|
||||
url: https://github.com/KOZ39
|
||||
- login: rwxd
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/40308458?u=cd04a39e3655923be4f25c2ba8a5a07b3da3230a&v=4
|
||||
url: https://github.com/rwxd
|
||||
- login: morzan1001
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/47593005?u=c30ab7230f82a12a9b938dcb54f84a996931409a&v=4
|
||||
url: https://github.com/morzan1001
|
||||
- login: Olegt0rr
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/25399456?u=3e87b5239a2f4600975ba13be73054f8567c6060&v=4
|
||||
url: https://github.com/Olegt0rr
|
||||
- login: dinoz0rg
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/32940067?u=739cda1eb123a2dd5e1db45c361396f239e23f8b&v=4
|
||||
url: https://github.com/dinoz0rg
|
||||
- login: larsyngvelundin
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/34173819?u=74958599695bf83ac9f1addd935a51548a10c6b0&v=4
|
||||
url: https://github.com/larsyngvelundin
|
||||
- login: hippoley
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/135493401?u=1164ef48a645a7c12664fabc1638fbb7e1c459b0&v=4
|
||||
url: https://github.com/hippoley
|
||||
- login: 4anklee
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/144109238?u=a79c0d581b2a3d8f3897e7ef4c012640a6c1eb3a&v=4
|
||||
url: https://github.com/4anklee
|
||||
- login: CoderDeltaLAN
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/152043745?u=4ff541efffb7d134e60c5fcf2dd1e343f90bb782&v=4
|
||||
url: https://github.com/CoderDeltaLAN
|
||||
- login: onestn
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/62360849?u=746dd21c34e7e06eefb11b03e8bb01aaae3c2a4f&v=4
|
||||
url: https://github.com/onestn
|
||||
- login: nayasinghania
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/74111380?u=752e99a5e139389fdc0a0677122adc08438eb076&v=4
|
||||
url: https://github.com/nayasinghania
|
||||
- login: Toothwitch
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1710406?u=5eebb23b46cd26e48643b9e5179536cad491c17a&v=4
|
||||
url: https://github.com/Toothwitch
|
||||
- login: andreagrandi
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/636391?u=13d90cb8ec313593a5b71fbd4e33b78d6da736f5&v=4
|
||||
url: https://github.com/andreagrandi
|
||||
- login: msserpa
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6334934?u=82c4489eb1559d88d2990d60001901b14f722bbb&v=4
|
||||
url: https://github.com/msserpa
|
||||
@@ -0,0 +1,22 @@
|
||||
members:
|
||||
- login: tiangolo
|
||||
avatar_url: https://avatars.githubusercontent.com/u/1326112
|
||||
url: https://github.com/tiangolo
|
||||
- login: Kludex
|
||||
avatar_url: https://avatars.githubusercontent.com/u/7353520
|
||||
url: https://github.com/Kludex
|
||||
- login: alejsdev
|
||||
avatar_url: https://avatars.githubusercontent.com/u/90076947
|
||||
url: https://github.com/alejsdev
|
||||
- login: svlandeg
|
||||
avatar_url: https://avatars.githubusercontent.com/u/8796347
|
||||
url: https://github.com/svlandeg
|
||||
- login: YuriiMotov
|
||||
avatar_url: https://avatars.githubusercontent.com/u/109919500
|
||||
url: https://github.com/YuriiMotov
|
||||
- login: patrick91
|
||||
avatar_url: https://avatars.githubusercontent.com/u/667029
|
||||
url: https://github.com/patrick91
|
||||
- login: luzzodev
|
||||
avatar_url: https://avatars.githubusercontent.com/u/27291415
|
||||
url: https://github.com/luzzodev
|
||||
@@ -0,0 +1,702 @@
|
||||
maintainers:
|
||||
- login: tiangolo
|
||||
answers: 1900
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1326112?u=cb5d06e73a9e1998141b1641aa88e443c6717651&v=4
|
||||
url: https://github.com/tiangolo
|
||||
experts:
|
||||
- login: tiangolo
|
||||
count: 1900
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1326112?u=cb5d06e73a9e1998141b1641aa88e443c6717651&v=4
|
||||
url: https://github.com/tiangolo
|
||||
- login: YuriiMotov
|
||||
count: 971
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/109919500?u=b9b13d598dddfab529a52d264df80a900bfe7060&v=4
|
||||
url: https://github.com/YuriiMotov
|
||||
- login: github-actions
|
||||
count: 769
|
||||
avatarUrl: https://avatars.githubusercontent.com/in/15368?v=4
|
||||
url: https://github.com/apps/github-actions
|
||||
- login: Kludex
|
||||
count: 654
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7353520?u=df8a3f06ba8f55ae1967a3e2d5ed882903a4e330&v=4
|
||||
url: https://github.com/Kludex
|
||||
- login: jgould22
|
||||
count: 263
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4335847?u=ed77f67e0bb069084639b24d812dbb2a2b1dc554&v=4
|
||||
url: https://github.com/jgould22
|
||||
- login: dmontagu
|
||||
count: 240
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/35119617?u=540f30c937a6450812628b9592a1dfe91bbe148e&v=4
|
||||
url: https://github.com/dmontagu
|
||||
- login: Mause
|
||||
count: 219
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1405026?v=4
|
||||
url: https://github.com/Mause
|
||||
- login: ycd
|
||||
count: 216
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/62724709?u=f1e7bae394a315da950912c92dc861a8eaf95d4c&v=4
|
||||
url: https://github.com/ycd
|
||||
- login: JarroVGIT
|
||||
count: 190
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13659033?u=e8bea32d07a5ef72f7dde3b2079ceb714923ca05&v=4
|
||||
url: https://github.com/JarroVGIT
|
||||
- login: euri10
|
||||
count: 153
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1104190?u=321a2e953e6645a7d09b732786c7a8061e0f8a8b&v=4
|
||||
url: https://github.com/euri10
|
||||
- login: iudeen
|
||||
count: 128
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10519440?u=f09cdd745e5bf16138f29b42732dd57c7f02bee1&v=4
|
||||
url: https://github.com/iudeen
|
||||
- login: phy25
|
||||
count: 126
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/331403?v=4
|
||||
url: https://github.com/phy25
|
||||
- login: JavierSanchezCastro
|
||||
count: 94
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/72013291?u=ae5679e6bd971d9d98cd5e76e8683f83642ba950&v=4
|
||||
url: https://github.com/JavierSanchezCastro
|
||||
- login: luzzodev
|
||||
count: 89
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/27291415?u=5607ae1ce75c5f54f09500ca854227f7bfd2033b&v=4
|
||||
url: https://github.com/luzzodev
|
||||
- login: raphaelauv
|
||||
count: 83
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10202690?u=e6f86f5c0c3026a15d6b51792fa3e532b12f1371&v=4
|
||||
url: https://github.com/raphaelauv
|
||||
- login: ArcLightSlavik
|
||||
count: 71
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31127044?u=b0f2c37142f4b762e41ad65dc49581813422bd71&v=4
|
||||
url: https://github.com/ArcLightSlavik
|
||||
- login: ghandic
|
||||
count: 71
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/23500353?u=e2e1d736f924d9be81e8bfc565b6d8836ba99773&v=4
|
||||
url: https://github.com/ghandic
|
||||
- login: n8sty
|
||||
count: 67
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/2964996?v=4
|
||||
url: https://github.com/n8sty
|
||||
- login: falkben
|
||||
count: 59
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/653031?u=ad9838e089058c9e5a0bab94c0eec7cc181e0cd0&v=4
|
||||
url: https://github.com/falkben
|
||||
- login: yinziyan1206
|
||||
count: 54
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/37829370?u=da44ca53aefd5c23f346fab8e9fd2e108294c179&v=4
|
||||
url: https://github.com/yinziyan1206
|
||||
- login: sm-Fifteen
|
||||
count: 49
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/516999?u=437c0c5038558c67e887ccd863c1ba0f846c03da&v=4
|
||||
url: https://github.com/sm-Fifteen
|
||||
- login: acidjunk
|
||||
count: 49
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/685002?u=b5094ab4527fc84b006c0ac9ff54367bdebb2267&v=4
|
||||
url: https://github.com/acidjunk
|
||||
- login: adriangb
|
||||
count: 46
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1755071?u=612704256e38d6ac9cbed24f10e4b6ac2da74ecb&v=4
|
||||
url: https://github.com/adriangb
|
||||
- login: Dustyposa
|
||||
count: 45
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/27180793?u=5cf2877f50b3eb2bc55086089a78a36f07042889&v=4
|
||||
url: https://github.com/Dustyposa
|
||||
- login: insomnes
|
||||
count: 45
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/16958893?u=f8be7088d5076d963984a21f95f44e559192d912&v=4
|
||||
url: https://github.com/insomnes
|
||||
- login: frankie567
|
||||
count: 43
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1144727?u=c159fe047727aedecbbeeaa96a1b03ceb9d39add&v=4
|
||||
url: https://github.com/frankie567
|
||||
- login: odiseo0
|
||||
count: 43
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/87550035?u=241a71f6b7068738b81af3e57f45ffd723538401&v=4
|
||||
url: https://github.com/odiseo0
|
||||
- login: sinisaos
|
||||
count: 41
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/30960668?v=4
|
||||
url: https://github.com/sinisaos
|
||||
- login: includeamin
|
||||
count: 40
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/11836741?u=8bd5ef7e62fe6a82055e33c4c0e0a7879ff8cfb6&v=4
|
||||
url: https://github.com/includeamin
|
||||
- login: STeveShary
|
||||
count: 37
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/5167622?u=de8f597c81d6336fcebc37b32dfd61a3f877160c&v=4
|
||||
url: https://github.com/STeveShary
|
||||
- login: chbndrhnns
|
||||
count: 37
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7534547?v=4
|
||||
url: https://github.com/chbndrhnns
|
||||
- login: krishnardt
|
||||
count: 35
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31960541?u=47f4829c77f4962ab437ffb7995951e41eeebe9b&v=4
|
||||
url: https://github.com/krishnardt
|
||||
- login: panla
|
||||
count: 32
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/41326348?u=ba2fda6b30110411ecbf406d187907e2b420ac19&v=4
|
||||
url: https://github.com/panla
|
||||
- login: prostomarkeloff
|
||||
count: 28
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/28061158?u=6918e39a1224194ba636e897461a02a20126d7ad&v=4
|
||||
url: https://github.com/prostomarkeloff
|
||||
- login: hasansezertasan
|
||||
count: 27
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13135006?u=99f0b0f0fc47e88e8abb337b4447357939ef93e7&v=4
|
||||
url: https://github.com/hasansezertasan
|
||||
- login: alv2017
|
||||
count: 26
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31544722?v=4
|
||||
url: https://github.com/alv2017
|
||||
- login: dbanty
|
||||
count: 26
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/43723790?u=9d726785d08e50b1e1cd96505800c8ea8405bce2&v=4
|
||||
url: https://github.com/dbanty
|
||||
- login: wshayes
|
||||
count: 25
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/365303?u=07ca03c5ee811eb0920e633cc3c3db73dbec1aa5&v=4
|
||||
url: https://github.com/wshayes
|
||||
- login: valentinDruzhinin
|
||||
count: 24
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12831905?u=aae1ebc675c91e8fa582df4fcc4fc4128106344d&v=4
|
||||
url: https://github.com/valentinDruzhinin
|
||||
- login: SirTelemak
|
||||
count: 23
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/9435877?u=719327b7d2c4c62212456d771bfa7c6b8dbb9eac&v=4
|
||||
url: https://github.com/SirTelemak
|
||||
- login: connebs
|
||||
count: 22
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/9054108?u=e151d5f545a3395136d711c227c22032fda67cfa&v=4
|
||||
url: https://github.com/connebs
|
||||
- login: nymous
|
||||
count: 22
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4216559?u=360a36fb602cded27273cbfc0afc296eece90662&v=4
|
||||
url: https://github.com/nymous
|
||||
- login: chrisK824
|
||||
count: 22
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/79946379?u=03d85b22d696a58a9603e55fbbbe2de6b0f4face&v=4
|
||||
url: https://github.com/chrisK824
|
||||
- login: rafsaf
|
||||
count: 21
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/51059348?u=5fe59a56e1f2f9ccd8005d71752a8276f133ae1a&v=4
|
||||
url: https://github.com/rafsaf
|
||||
- login: nsidnev
|
||||
count: 20
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/22559461?u=a9cc3238217e21dc8796a1a500f01b722adb082c&v=4
|
||||
url: https://github.com/nsidnev
|
||||
- login: chris-allnutt
|
||||
count: 20
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/565544?v=4
|
||||
url: https://github.com/chris-allnutt
|
||||
- login: ebottos94
|
||||
count: 20
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/100039558?u=8b91053b3abe4a9209375e3651e1c1ef192d884b&v=4
|
||||
url: https://github.com/ebottos94
|
||||
- login: estebanx64
|
||||
count: 19
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10840422?u=1900887aeed268699e5ea6f3fb7db614f7b77cd3&v=4
|
||||
url: https://github.com/estebanx64
|
||||
- login: sehraramiz
|
||||
count: 18
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/14166324?u=8fac65e84dfff24245d304a5b5b09f7b5bd69dc9&v=4
|
||||
url: https://github.com/sehraramiz
|
||||
- login: retnikt
|
||||
count: 18
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/24581770?v=4
|
||||
url: https://github.com/retnikt
|
||||
- login: zoliknemet
|
||||
count: 18
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/22326718?u=31ba446ac290e23e56eea8e4f0c558aaf0b40779&v=4
|
||||
url: https://github.com/zoliknemet
|
||||
- login: caeser1996
|
||||
count: 17
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/16540232?u=05d2beb8e034d584d0a374b99d8826327bd7f614&v=4
|
||||
url: https://github.com/caeser1996
|
||||
- login: Hultner
|
||||
count: 17
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/2669034?u=115e53df959309898ad8dc9443fbb35fee71df07&v=4
|
||||
url: https://github.com/Hultner
|
||||
- login: harunyasar
|
||||
count: 17
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1765494?u=5b1ab7c582db4b4016fa31affe977d10af108ad4&v=4
|
||||
url: https://github.com/harunyasar
|
||||
- login: nkhitrov
|
||||
count: 17
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/28262306?u=e19427d8dc296d6950e9c424adacc92d37496fe9&v=4
|
||||
url: https://github.com/nkhitrov
|
||||
- login: dstlny
|
||||
count: 16
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/41964673?u=9f2174f9d61c15c6e3a4c9e3aeee66f711ce311f&v=4
|
||||
url: https://github.com/dstlny
|
||||
- login: pythonweb2
|
||||
count: 16
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/32141163?v=4
|
||||
url: https://github.com/pythonweb2
|
||||
- login: jonatasoli
|
||||
count: 16
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/26334101?u=f601c3f111f2148bd9244c2cb3ebbd57b592e674&v=4
|
||||
url: https://github.com/jonatasoli
|
||||
- login: ghost
|
||||
count: 15
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10137?u=b1951d34a583cf12ec0d3b0781ba19be97726318&v=4
|
||||
url: https://github.com/ghost
|
||||
- login: abhint
|
||||
count: 15
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/25699289?u=b5d219277b4d001ac26fb8be357fddd88c29d51b&v=4
|
||||
url: https://github.com/abhint
|
||||
last_month_experts:
|
||||
- login: YuriiMotov
|
||||
count: 17
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/109919500?u=b9b13d598dddfab529a52d264df80a900bfe7060&v=4
|
||||
url: https://github.com/YuriiMotov
|
||||
- login: valentinDruzhinin
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12831905?u=aae1ebc675c91e8fa582df4fcc4fc4128106344d&v=4
|
||||
url: https://github.com/valentinDruzhinin
|
||||
- login: yinziyan1206
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/37829370?u=da44ca53aefd5c23f346fab8e9fd2e108294c179&v=4
|
||||
url: https://github.com/yinziyan1206
|
||||
- login: tiangolo
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1326112?u=cb5d06e73a9e1998141b1641aa88e443c6717651&v=4
|
||||
url: https://github.com/tiangolo
|
||||
- login: luzzodev
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/27291415?u=5607ae1ce75c5f54f09500ca854227f7bfd2033b&v=4
|
||||
url: https://github.com/luzzodev
|
||||
three_months_experts:
|
||||
- login: YuriiMotov
|
||||
count: 397
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/109919500?u=b9b13d598dddfab529a52d264df80a900bfe7060&v=4
|
||||
url: https://github.com/YuriiMotov
|
||||
- login: valentinDruzhinin
|
||||
count: 24
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12831905?u=aae1ebc675c91e8fa582df4fcc4fc4128106344d&v=4
|
||||
url: https://github.com/valentinDruzhinin
|
||||
- login: luzzodev
|
||||
count: 17
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/27291415?u=5607ae1ce75c5f54f09500ca854227f7bfd2033b&v=4
|
||||
url: https://github.com/luzzodev
|
||||
- login: raceychan
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/75417963?u=060c62870ec5a791765e63ac20d8885d11143786&v=4
|
||||
url: https://github.com/raceychan
|
||||
- login: yinziyan1206
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/37829370?u=da44ca53aefd5c23f346fab8e9fd2e108294c179&v=4
|
||||
url: https://github.com/yinziyan1206
|
||||
- login: DoctorJohn
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/14076775?u=2913e70a6142772847e91e2aaa5b9152391715e9&v=4
|
||||
url: https://github.com/DoctorJohn
|
||||
- login: tiangolo
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1326112?u=cb5d06e73a9e1998141b1641aa88e443c6717651&v=4
|
||||
url: https://github.com/tiangolo
|
||||
- login: sachinh35
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/21972708?u=8560b97b8b41e175f476270b56de8a493b84f302&v=4
|
||||
url: https://github.com/sachinh35
|
||||
- login: eqsdxr
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/157279130?u=58fddf77ed76966eaa8c73eea9bea4bb0c53b673&v=4
|
||||
url: https://github.com/eqsdxr
|
||||
- login: Jelle-tenB
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/210023470?u=c25d66addf36a747bd9fab773c4a6e7b238f45d4&v=4
|
||||
url: https://github.com/Jelle-tenB
|
||||
- login: pythonweb2
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/32141163?v=4
|
||||
url: https://github.com/pythonweb2
|
||||
- login: WilliamDEdwards
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12184311?u=9b29d5d1d71f5f1a7ef9e439963ad3529e3b33a4&v=4
|
||||
url: https://github.com/WilliamDEdwards
|
||||
- login: Brikas
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/80290187?v=4
|
||||
url: https://github.com/Brikas
|
||||
- login: purepani
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7587353?v=4
|
||||
url: https://github.com/purepani
|
||||
- login: JavierSanchezCastro
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/72013291?u=ae5679e6bd971d9d98cd5e76e8683f83642ba950&v=4
|
||||
url: https://github.com/JavierSanchezCastro
|
||||
- login: TaigoFr
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/17792131?u=372b27056ec82f1ae03d8b3f37ef55b04a7cfdd1&v=4
|
||||
url: https://github.com/TaigoFr
|
||||
- login: Garrett-R
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6614695?u=c128fd775002882f6e391bda5a89d1bdc5bdf45f&v=4
|
||||
url: https://github.com/Garrett-R
|
||||
- login: jymchng
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/27895426?u=fb88c47775147d62a395fdb895d1af4148c7b566&v=4
|
||||
url: https://github.com/jymchng
|
||||
- login: davidhuser
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4357648?u=6ed702f8f6d49a8b2a0ed33cbd8ab59c2d7db7f7&v=4
|
||||
url: https://github.com/davidhuser
|
||||
six_months_experts:
|
||||
- login: YuriiMotov
|
||||
count: 763
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/109919500?u=b9b13d598dddfab529a52d264df80a900bfe7060&v=4
|
||||
url: https://github.com/YuriiMotov
|
||||
- login: luzzodev
|
||||
count: 45
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/27291415?u=5607ae1ce75c5f54f09500ca854227f7bfd2033b&v=4
|
||||
url: https://github.com/luzzodev
|
||||
- login: valentinDruzhinin
|
||||
count: 24
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12831905?u=aae1ebc675c91e8fa582df4fcc4fc4128106344d&v=4
|
||||
url: https://github.com/valentinDruzhinin
|
||||
- login: alv2017
|
||||
count: 16
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31544722?v=4
|
||||
url: https://github.com/alv2017
|
||||
- login: sachinh35
|
||||
count: 9
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/21972708?u=8560b97b8b41e175f476270b56de8a493b84f302&v=4
|
||||
url: https://github.com/sachinh35
|
||||
- login: yauhen-sobaleu
|
||||
count: 9
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/51629535?u=fc1817060daf2df438bfca86c44f33da5cd667db&v=4
|
||||
url: https://github.com/yauhen-sobaleu
|
||||
- login: tiangolo
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1326112?u=cb5d06e73a9e1998141b1641aa88e443c6717651&v=4
|
||||
url: https://github.com/tiangolo
|
||||
- login: JavierSanchezCastro
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/72013291?u=ae5679e6bd971d9d98cd5e76e8683f83642ba950&v=4
|
||||
url: https://github.com/JavierSanchezCastro
|
||||
- login: raceychan
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/75417963?u=060c62870ec5a791765e63ac20d8885d11143786&v=4
|
||||
url: https://github.com/raceychan
|
||||
- login: yinziyan1206
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/37829370?u=da44ca53aefd5c23f346fab8e9fd2e108294c179&v=4
|
||||
url: https://github.com/yinziyan1206
|
||||
- login: DoctorJohn
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/14076775?u=2913e70a6142772847e91e2aaa5b9152391715e9&v=4
|
||||
url: https://github.com/DoctorJohn
|
||||
- login: eqsdxr
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/157279130?u=58fddf77ed76966eaa8c73eea9bea4bb0c53b673&v=4
|
||||
url: https://github.com/eqsdxr
|
||||
- login: Kludex
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7353520?u=df8a3f06ba8f55ae1967a3e2d5ed882903a4e330&v=4
|
||||
url: https://github.com/Kludex
|
||||
- login: Jelle-tenB
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/210023470?u=c25d66addf36a747bd9fab773c4a6e7b238f45d4&v=4
|
||||
url: https://github.com/Jelle-tenB
|
||||
- login: adsouza
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/275832?u=f90f110cfafeafed2f14339e840941c2c328c186&v=4
|
||||
url: https://github.com/adsouza
|
||||
- login: pythonweb2
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/32141163?v=4
|
||||
url: https://github.com/pythonweb2
|
||||
- login: WilliamDEdwards
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12184311?u=9b29d5d1d71f5f1a7ef9e439963ad3529e3b33a4&v=4
|
||||
url: https://github.com/WilliamDEdwards
|
||||
- login: Brikas
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/80290187?v=4
|
||||
url: https://github.com/Brikas
|
||||
- login: purepani
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7587353?v=4
|
||||
url: https://github.com/purepani
|
||||
- login: TaigoFr
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/17792131?u=372b27056ec82f1ae03d8b3f37ef55b04a7cfdd1&v=4
|
||||
url: https://github.com/TaigoFr
|
||||
- login: Garrett-R
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6614695?u=c128fd775002882f6e391bda5a89d1bdc5bdf45f&v=4
|
||||
url: https://github.com/Garrett-R
|
||||
- login: EverStarck
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/51029456?u=343409b7cb6b3ea6a59359f4e8370d9c3f140ecd&v=4
|
||||
url: https://github.com/EverStarck
|
||||
- login: henrymcl
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/26480299?v=4
|
||||
url: https://github.com/henrymcl
|
||||
- login: jymchng
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/27895426?u=fb88c47775147d62a395fdb895d1af4148c7b566&v=4
|
||||
url: https://github.com/jymchng
|
||||
- login: davidhuser
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4357648?u=6ed702f8f6d49a8b2a0ed33cbd8ab59c2d7db7f7&v=4
|
||||
url: https://github.com/davidhuser
|
||||
- login: PidgeyBE
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/19860056?u=47b584eb1c1ab45e31c1b474109a962d7e82be49&v=4
|
||||
url: https://github.com/PidgeyBE
|
||||
- login: KianAnbarestani
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/145364424?u=dcc3d8fb4ca07d36fb52a17f38b6650565de40be&v=4
|
||||
url: https://github.com/KianAnbarestani
|
||||
- login: jgould22
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4335847?u=ed77f67e0bb069084639b24d812dbb2a2b1dc554&v=4
|
||||
url: https://github.com/jgould22
|
||||
- login: marsboy02
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/86903678?u=04cc319d6605f8d1ba3a0bed9f4f55a582719ae6&v=4
|
||||
url: https://github.com/marsboy02
|
||||
one_year_experts:
|
||||
- login: YuriiMotov
|
||||
count: 824
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/109919500?u=b9b13d598dddfab529a52d264df80a900bfe7060&v=4
|
||||
url: https://github.com/YuriiMotov
|
||||
- login: luzzodev
|
||||
count: 89
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/27291415?u=5607ae1ce75c5f54f09500ca854227f7bfd2033b&v=4
|
||||
url: https://github.com/luzzodev
|
||||
- login: Kludex
|
||||
count: 50
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7353520?u=df8a3f06ba8f55ae1967a3e2d5ed882903a4e330&v=4
|
||||
url: https://github.com/Kludex
|
||||
- login: sinisaos
|
||||
count: 33
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/30960668?v=4
|
||||
url: https://github.com/sinisaos
|
||||
- login: alv2017
|
||||
count: 26
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31544722?v=4
|
||||
url: https://github.com/alv2017
|
||||
- login: valentinDruzhinin
|
||||
count: 24
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12831905?u=aae1ebc675c91e8fa582df4fcc4fc4128106344d&v=4
|
||||
url: https://github.com/valentinDruzhinin
|
||||
- login: JavierSanchezCastro
|
||||
count: 24
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/72013291?u=ae5679e6bd971d9d98cd5e76e8683f83642ba950&v=4
|
||||
url: https://github.com/JavierSanchezCastro
|
||||
- login: jgould22
|
||||
count: 17
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4335847?u=ed77f67e0bb069084639b24d812dbb2a2b1dc554&v=4
|
||||
url: https://github.com/jgould22
|
||||
- login: tiangolo
|
||||
count: 14
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1326112?u=cb5d06e73a9e1998141b1641aa88e443c6717651&v=4
|
||||
url: https://github.com/tiangolo
|
||||
- login: Kfir-G
|
||||
count: 13
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/57500876?u=a3bf923ab27bce3d1b13779a8dd22eb7675017fd&v=4
|
||||
url: https://github.com/Kfir-G
|
||||
- login: sehraramiz
|
||||
count: 11
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/14166324?u=8fac65e84dfff24245d304a5b5b09f7b5bd69dc9&v=4
|
||||
url: https://github.com/sehraramiz
|
||||
- login: sachinh35
|
||||
count: 9
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/21972708?u=8560b97b8b41e175f476270b56de8a493b84f302&v=4
|
||||
url: https://github.com/sachinh35
|
||||
- login: yauhen-sobaleu
|
||||
count: 9
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/51629535?u=fc1817060daf2df438bfca86c44f33da5cd667db&v=4
|
||||
url: https://github.com/yauhen-sobaleu
|
||||
- login: estebanx64
|
||||
count: 7
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/10840422?u=1900887aeed268699e5ea6f3fb7db614f7b77cd3&v=4
|
||||
url: https://github.com/estebanx64
|
||||
- login: ceb10n
|
||||
count: 7
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/235213?u=edcce471814a1eba9f0cdaa4cd0de18921a940a6&v=4
|
||||
url: https://github.com/ceb10n
|
||||
- login: yvallois
|
||||
count: 7
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/36999744?v=4
|
||||
url: https://github.com/yvallois
|
||||
- login: raceychan
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/75417963?u=060c62870ec5a791765e63ac20d8885d11143786&v=4
|
||||
url: https://github.com/raceychan
|
||||
- login: yinziyan1206
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/37829370?u=da44ca53aefd5c23f346fab8e9fd2e108294c179&v=4
|
||||
url: https://github.com/yinziyan1206
|
||||
- login: DoctorJohn
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/14076775?u=2913e70a6142772847e91e2aaa5b9152391715e9&v=4
|
||||
url: https://github.com/DoctorJohn
|
||||
- login: n8sty
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/2964996?v=4
|
||||
url: https://github.com/n8sty
|
||||
- login: pythonweb2
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/32141163?v=4
|
||||
url: https://github.com/pythonweb2
|
||||
- login: eqsdxr
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/157279130?u=58fddf77ed76966eaa8c73eea9bea4bb0c53b673&v=4
|
||||
url: https://github.com/eqsdxr
|
||||
- login: yokwejuste
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/71908316?u=4ba43bd63c169b5c015137d8916752a44001445a&v=4
|
||||
url: https://github.com/yokwejuste
|
||||
- login: WilliamDEdwards
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12184311?u=9b29d5d1d71f5f1a7ef9e439963ad3529e3b33a4&v=4
|
||||
url: https://github.com/WilliamDEdwards
|
||||
- login: mattmess1221
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3409962?u=d22ea18aa8ea688af25a45df306134d593621a44&v=4
|
||||
url: https://github.com/mattmess1221
|
||||
- login: Jelle-tenB
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/210023470?u=c25d66addf36a747bd9fab773c4a6e7b238f45d4&v=4
|
||||
url: https://github.com/Jelle-tenB
|
||||
- login: viniciusCalcantara
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/108818737?u=80f3ec7427fa6a41d5896984d0c526432f2299fa&v=4
|
||||
url: https://github.com/viniciusCalcantara
|
||||
- login: davidhuser
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4357648?u=6ed702f8f6d49a8b2a0ed33cbd8ab59c2d7db7f7&v=4
|
||||
url: https://github.com/davidhuser
|
||||
- login: dbfreem
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/9778569?u=f2f1e9135b5e4f1b0c6821a548b17f97572720fc&v=4
|
||||
url: https://github.com/dbfreem
|
||||
- login: SobikXexe
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/87701130?v=4
|
||||
url: https://github.com/SobikXexe
|
||||
- login: pawelad
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7062874?u=d27dc220545a8401ad21840590a97d474d7101e6&v=4
|
||||
url: https://github.com/pawelad
|
||||
- login: Isuxiz
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/48672727?u=34d7b4ade252687d22a27cf53037b735b244bfc1&v=4
|
||||
url: https://github.com/Isuxiz
|
||||
- login: Minibrams
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/8108085?u=b028dbc308fa8485e0e2e9402b3d03d8deb22bf9&v=4
|
||||
url: https://github.com/Minibrams
|
||||
- login: adsouza
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/275832?u=f90f110cfafeafed2f14339e840941c2c328c186&v=4
|
||||
url: https://github.com/adsouza
|
||||
- login: Synrom
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/30272537?v=4
|
||||
url: https://github.com/Synrom
|
||||
- login: gaby
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/835733?u=8c72dec16fa560bdc81113354f2ffd79ad062bde&v=4
|
||||
url: https://github.com/gaby
|
||||
- login: Ale-Cas
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/64859146?u=d52a6ecf8d83d2927e2ae270bdfcc83495dba8c9&v=4
|
||||
url: https://github.com/Ale-Cas
|
||||
- login: CharlesPerrotMinotHCHB
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/112571330?u=e3a666718ff5ad1d1c49d6c31358a9f80c841b30&v=4
|
||||
url: https://github.com/CharlesPerrotMinotHCHB
|
||||
- login: yanggeorge
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/2434407?v=4
|
||||
url: https://github.com/yanggeorge
|
||||
- login: Brikas
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/80290187?v=4
|
||||
url: https://github.com/Brikas
|
||||
- login: dolfinus
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/4661021?u=ed5ddadcf36d9b943ebe61febe0b96ee34e5425d&v=4
|
||||
url: https://github.com/dolfinus
|
||||
- login: slafs
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/210173?v=4
|
||||
url: https://github.com/slafs
|
||||
- login: purepani
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7587353?v=4
|
||||
url: https://github.com/purepani
|
||||
- login: ddahan
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1933516?u=1d200a620e8d6841df017e9f2bb7efb58b580f40&v=4
|
||||
url: https://github.com/ddahan
|
||||
- login: TaigoFr
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/17792131?u=372b27056ec82f1ae03d8b3f37ef55b04a7cfdd1&v=4
|
||||
url: https://github.com/TaigoFr
|
||||
- login: Garrett-R
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6614695?u=c128fd775002882f6e391bda5a89d1bdc5bdf45f&v=4
|
||||
url: https://github.com/Garrett-R
|
||||
- login: jd-solanki
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/47495003?u=6e225cb42c688d0cd70e65c6baedb9f5922b1178&v=4
|
||||
url: https://github.com/jd-solanki
|
||||
- login: EverStarck
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/51029456?u=343409b7cb6b3ea6a59359f4e8370d9c3f140ecd&v=4
|
||||
url: https://github.com/EverStarck
|
||||
- login: henrymcl
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/26480299?v=4
|
||||
url: https://github.com/henrymcl
|
||||
- login: jymchng
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/27895426?u=fb88c47775147d62a395fdb895d1af4148c7b566&v=4
|
||||
url: https://github.com/jymchng
|
||||
- login: christiansicari
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/29756552?v=4
|
||||
url: https://github.com/christiansicari
|
||||
- login: JacobHayes
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/2555532?u=354a525847a276bbb4426b0c95791a8ba5970f9b&v=4
|
||||
url: https://github.com/JacobHayes
|
||||
- login: iloveitaly
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/150855?v=4
|
||||
url: https://github.com/iloveitaly
|
||||
- login: iiotsrc
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/131771119?u=bcaf2559ef6266af70b151b7fda31a1ee3dbecb3&v=4
|
||||
url: https://github.com/iiotsrc
|
||||
- login: PidgeyBE
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/19860056?u=47b584eb1c1ab45e31c1b474109a962d7e82be49&v=4
|
||||
url: https://github.com/PidgeyBE
|
||||
- login: KianAnbarestani
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/145364424?u=dcc3d8fb4ca07d36fb52a17f38b6650565de40be&v=4
|
||||
url: https://github.com/KianAnbarestani
|
||||
- login: ykaiqx
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/56395004?u=1eebf5ce25a8067f7bfa6251a24f667be492d9d6&v=4
|
||||
url: https://github.com/ykaiqx
|
||||
- login: AliYmn
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/18416653?u=a77e2605e3ce6aaf6fef8ad4a7b0d32954fba47a&v=4
|
||||
url: https://github.com/AliYmn
|
||||
- login: gelezo43
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/40732698?u=611f39d3c1d2f4207a590937a78c1f10eed6232c&v=4
|
||||
url: https://github.com/gelezo43
|
||||
- login: jfeaver
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1091338?u=0bcba366447d8fadad63f6705a52d128da4c7ec2&v=4
|
||||
url: https://github.com/jfeaver
|
||||
@@ -0,0 +1,5 @@
|
||||
- tiangolo
|
||||
- codecov
|
||||
- github-actions
|
||||
- pre-commit-ci
|
||||
- dependabot
|
||||
@@ -0,0 +1,73 @@
|
||||
keystone:
|
||||
- url: https://fastapicloud.com
|
||||
title: FastAPI Cloud. By the same team behind FastAPI. You code. We Cloud.
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/fastapicloud.png
|
||||
gold:
|
||||
- url: https://blockbee.io?ref=fastapi
|
||||
title: BlockBee Cryptocurrency Payment Gateway
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/blockbee.png
|
||||
- url: https://github.com/scalar/scalar/?utm_source=fastapi&utm_medium=website&utm_campaign=main-badge
|
||||
title: "Scalar: Beautiful Open-Source API References from Swagger/OpenAPI files"
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/scalar.svg
|
||||
- url: https://www.propelauth.com/?utm_source=fastapi&utm_campaign=1223&utm_medium=mainbadge
|
||||
title: Auth, user management and more for your B2B product
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/propelauth.png
|
||||
- url: https://zuplo.link/fastapi-gh
|
||||
title: 'Zuplo: Deploy, Secure, Document, and Monetize your FastAPI'
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/zuplo.png
|
||||
- url: https://liblab.com?utm_source=fastapi
|
||||
title: liblab - Generate SDKs from FastAPI
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/liblab.png
|
||||
- url: https://docs.render.com/deploy-fastapi?utm_source=deploydoc&utm_medium=referral&utm_campaign=fastapi
|
||||
title: Deploy & scale any full-stack web app on Render. Focus on building apps, not infra.
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/render.svg
|
||||
- url: https://www.coderabbit.ai/?utm_source=fastapi&utm_medium=badge&utm_campaign=fastapi
|
||||
title: Cut Code Review Time & Bugs in Half with CodeRabbit
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/coderabbit.png
|
||||
- url: https://subtotal.com/?utm_source=fastapi&utm_medium=sponsorship&utm_campaign=open-source
|
||||
title: The Gold Standard in Retail Account Linking
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/subtotal.svg
|
||||
- url: https://docs.railway.com/guides/fastapi?utm_medium=integration&utm_source=docs&utm_campaign=fastapi
|
||||
title: Deploy enterprise applications at startup speed
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/railway.png
|
||||
- url: https://serpapi.com/?utm_source=fastapi_website
|
||||
title: "SerpApi: Web Search API"
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/serpapi.png
|
||||
- url: https://www.greptile.com/?utm_source=fastapi&utm_medium=sponsorship&utm_campaign=fastapi_sponsor_page
|
||||
title: "Greptile: The AI Code Reviewer"
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/greptile.png
|
||||
silver:
|
||||
- url: https://databento.com/?utm_source=fastapi&utm_medium=sponsor&utm_content=display
|
||||
title: Pay as you go for market data
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/databento.svg
|
||||
- url: https://speakeasy.com/editor?utm_source=fastapi+repo&utm_medium=github+sponsorship
|
||||
title: SDKs for your API | Speakeasy
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/speakeasy.png
|
||||
- url: https://www.svix.com/
|
||||
title: Svix - Webhooks as a service
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/svix.svg
|
||||
- url: https://www.stainlessapi.com/?utm_source=fastapi&utm_medium=referral
|
||||
title: Stainless | Generate best-in-class SDKs
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/stainless.png
|
||||
- url: https://www.permit.io/blog/implement-authorization-in-fastapi?utm_source=github&utm_medium=referral&utm_campaign=fastapi
|
||||
title: Fine-Grained Authorization for FastAPI
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/permit.png
|
||||
- url: https://www.interviewpal.com/?utm_source=fastapi&utm_medium=open-source&utm_campaign=dev-hiring
|
||||
title: InterviewPal - AI Interview Coach for Engineers and Devs
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/interviewpal.png
|
||||
- url: https://dribia.com/en/
|
||||
title: Dribia - Data Science within your reach
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/dribia.png
|
||||
bronze:
|
||||
- url: https://www.exoflare.com/open-source/?utm_source=FastAPI&utm_campaign=open_source
|
||||
title: Biosecurity risk assessments made easy.
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/exoflare.png
|
||||
# - url: https://testdriven.io/courses/tdd-fastapi/
|
||||
# title: Learn to build high-quality web apps with best practices
|
||||
# img: https://fastapi.tiangolo.com/img/sponsors/testdriven.svg
|
||||
- url: https://lambdatest.com/?utm_source=fastapi&utm_medium=partner&utm_campaign=sponsor&utm_term=opensource&utm_content=webpage
|
||||
title: LambdaTest, AI-Powered Cloud-based Test Orchestration Platform
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/lambdatest.png
|
||||
- url: https://requestly.com/fastapi
|
||||
title: All-in-one platform to Test, Mock and Intercept APIs. Built for speed, privacy and offline support.
|
||||
img: https://fastapi.tiangolo.com/img/sponsors/requestly.png
|
||||
@@ -0,0 +1,50 @@
|
||||
logins:
|
||||
- jina-ai
|
||||
- deta
|
||||
- investsuite
|
||||
- mikeckennedy
|
||||
- deepset-ai
|
||||
- cryptapi
|
||||
- xoflare
|
||||
- DropbaseHQ
|
||||
- VincentParedes
|
||||
- BLUE-DEVIL1134
|
||||
- ObliviousAI
|
||||
- Doist
|
||||
- nihpo
|
||||
- armand-sauzay
|
||||
- databento-bot
|
||||
- databento
|
||||
- nanram22
|
||||
- Flint-company
|
||||
- porter-dev
|
||||
- fern-api
|
||||
- ndimares
|
||||
- svixhq
|
||||
- Alek99
|
||||
- codacy
|
||||
- zanfaruqui
|
||||
- scalar
|
||||
- bump-sh
|
||||
- andrew-propelauth
|
||||
- svix
|
||||
- zuplo-oss
|
||||
- zuplo
|
||||
- Kong
|
||||
- speakeasy-api
|
||||
- jess-render
|
||||
- blockbee-io
|
||||
- liblaber
|
||||
- render-sponsorships
|
||||
- renderinc
|
||||
- stainless-api
|
||||
- snapit-cypher
|
||||
- coderabbitai
|
||||
- permitio
|
||||
- LambdaTest-Inc
|
||||
- dribia
|
||||
- madisonredtfeldt
|
||||
- railwayapp
|
||||
- subtotal
|
||||
- requestly
|
||||
- greptileai
|
||||
@@ -0,0 +1,495 @@
|
||||
- name: full-stack-fastapi-template
|
||||
html_url: https://github.com/fastapi/full-stack-fastapi-template
|
||||
stars: 39475
|
||||
owner_login: fastapi
|
||||
owner_html_url: https://github.com/fastapi
|
||||
- name: Hello-Python
|
||||
html_url: https://github.com/mouredev/Hello-Python
|
||||
stars: 33090
|
||||
owner_login: mouredev
|
||||
owner_html_url: https://github.com/mouredev
|
||||
- name: serve
|
||||
html_url: https://github.com/jina-ai/serve
|
||||
stars: 21798
|
||||
owner_login: jina-ai
|
||||
owner_html_url: https://github.com/jina-ai
|
||||
- name: HivisionIDPhotos
|
||||
html_url: https://github.com/Zeyi-Lin/HivisionIDPhotos
|
||||
stars: 20258
|
||||
owner_login: Zeyi-Lin
|
||||
owner_html_url: https://github.com/Zeyi-Lin
|
||||
- name: sqlmodel
|
||||
html_url: https://github.com/fastapi/sqlmodel
|
||||
stars: 17212
|
||||
owner_login: fastapi
|
||||
owner_html_url: https://github.com/fastapi
|
||||
- name: Douyin_TikTok_Download_API
|
||||
html_url: https://github.com/Evil0ctal/Douyin_TikTok_Download_API
|
||||
stars: 15145
|
||||
owner_login: Evil0ctal
|
||||
owner_html_url: https://github.com/Evil0ctal
|
||||
- name: fastapi-best-practices
|
||||
html_url: https://github.com/zhanymkanov/fastapi-best-practices
|
||||
stars: 14644
|
||||
owner_login: zhanymkanov
|
||||
owner_html_url: https://github.com/zhanymkanov
|
||||
- name: machine-learning-zoomcamp
|
||||
html_url: https://github.com/DataTalksClub/machine-learning-zoomcamp
|
||||
stars: 12320
|
||||
owner_login: DataTalksClub
|
||||
owner_html_url: https://github.com/DataTalksClub
|
||||
- name: fastapi_mcp
|
||||
html_url: https://github.com/tadata-org/fastapi_mcp
|
||||
stars: 11174
|
||||
owner_login: tadata-org
|
||||
owner_html_url: https://github.com/tadata-org
|
||||
- name: SurfSense
|
||||
html_url: https://github.com/MODSetter/SurfSense
|
||||
stars: 10858
|
||||
owner_login: MODSetter
|
||||
owner_html_url: https://github.com/MODSetter
|
||||
- name: awesome-fastapi
|
||||
html_url: https://github.com/mjhea0/awesome-fastapi
|
||||
stars: 10758
|
||||
owner_login: mjhea0
|
||||
owner_html_url: https://github.com/mjhea0
|
||||
- name: XHS-Downloader
|
||||
html_url: https://github.com/JoeanAmier/XHS-Downloader
|
||||
stars: 9313
|
||||
owner_login: JoeanAmier
|
||||
owner_html_url: https://github.com/JoeanAmier
|
||||
- name: FastUI
|
||||
html_url: https://github.com/pydantic/FastUI
|
||||
stars: 8915
|
||||
owner_login: pydantic
|
||||
owner_html_url: https://github.com/pydantic
|
||||
- name: polar
|
||||
html_url: https://github.com/polarsource/polar
|
||||
stars: 8339
|
||||
owner_login: polarsource
|
||||
owner_html_url: https://github.com/polarsource
|
||||
- name: FileCodeBox
|
||||
html_url: https://github.com/vastsa/FileCodeBox
|
||||
stars: 7721
|
||||
owner_login: vastsa
|
||||
owner_html_url: https://github.com/vastsa
|
||||
- name: nonebot2
|
||||
html_url: https://github.com/nonebot/nonebot2
|
||||
stars: 7170
|
||||
owner_login: nonebot
|
||||
owner_html_url: https://github.com/nonebot
|
||||
- name: hatchet
|
||||
html_url: https://github.com/hatchet-dev/hatchet
|
||||
stars: 6253
|
||||
owner_login: hatchet-dev
|
||||
owner_html_url: https://github.com/hatchet-dev
|
||||
- name: fastapi-users
|
||||
html_url: https://github.com/fastapi-users/fastapi-users
|
||||
stars: 5849
|
||||
owner_login: fastapi-users
|
||||
owner_html_url: https://github.com/fastapi-users
|
||||
- name: serge
|
||||
html_url: https://github.com/serge-chat/serge
|
||||
stars: 5756
|
||||
owner_login: serge-chat
|
||||
owner_html_url: https://github.com/serge-chat
|
||||
- name: strawberry
|
||||
html_url: https://github.com/strawberry-graphql/strawberry
|
||||
stars: 4569
|
||||
owner_login: strawberry-graphql
|
||||
owner_html_url: https://github.com/strawberry-graphql
|
||||
- name: chatgpt-web-share
|
||||
html_url: https://github.com/chatpire/chatgpt-web-share
|
||||
stars: 4294
|
||||
owner_login: chatpire
|
||||
owner_html_url: https://github.com/chatpire
|
||||
- name: poem
|
||||
html_url: https://github.com/poem-web/poem
|
||||
stars: 4276
|
||||
owner_login: poem-web
|
||||
owner_html_url: https://github.com/poem-web
|
||||
- name: dynaconf
|
||||
html_url: https://github.com/dynaconf/dynaconf
|
||||
stars: 4202
|
||||
owner_login: dynaconf
|
||||
owner_html_url: https://github.com/dynaconf
|
||||
- name: atrilabs-engine
|
||||
html_url: https://github.com/Atri-Labs/atrilabs-engine
|
||||
stars: 4093
|
||||
owner_login: Atri-Labs
|
||||
owner_html_url: https://github.com/Atri-Labs
|
||||
- name: Kokoro-FastAPI
|
||||
html_url: https://github.com/remsky/Kokoro-FastAPI
|
||||
stars: 4019
|
||||
owner_login: remsky
|
||||
owner_html_url: https://github.com/remsky
|
||||
- name: logfire
|
||||
html_url: https://github.com/pydantic/logfire
|
||||
stars: 3805
|
||||
owner_login: pydantic
|
||||
owner_html_url: https://github.com/pydantic
|
||||
- name: LitServe
|
||||
html_url: https://github.com/Lightning-AI/LitServe
|
||||
stars: 3719
|
||||
owner_login: Lightning-AI
|
||||
owner_html_url: https://github.com/Lightning-AI
|
||||
- name: fastapi-admin
|
||||
html_url: https://github.com/fastapi-admin/fastapi-admin
|
||||
stars: 3632
|
||||
owner_login: fastapi-admin
|
||||
owner_html_url: https://github.com/fastapi-admin
|
||||
- name: datamodel-code-generator
|
||||
html_url: https://github.com/koxudaxi/datamodel-code-generator
|
||||
stars: 3609
|
||||
owner_login: koxudaxi
|
||||
owner_html_url: https://github.com/koxudaxi
|
||||
- name: huma
|
||||
html_url: https://github.com/danielgtaylor/huma
|
||||
stars: 3603
|
||||
owner_login: danielgtaylor
|
||||
owner_html_url: https://github.com/danielgtaylor
|
||||
- name: farfalle
|
||||
html_url: https://github.com/rashadphz/farfalle
|
||||
stars: 3490
|
||||
owner_login: rashadphz
|
||||
owner_html_url: https://github.com/rashadphz
|
||||
- name: tracecat
|
||||
html_url: https://github.com/TracecatHQ/tracecat
|
||||
stars: 3379
|
||||
owner_login: TracecatHQ
|
||||
owner_html_url: https://github.com/TracecatHQ
|
||||
- name: opyrator
|
||||
html_url: https://github.com/ml-tooling/opyrator
|
||||
stars: 3135
|
||||
owner_login: ml-tooling
|
||||
owner_html_url: https://github.com/ml-tooling
|
||||
- name: docarray
|
||||
html_url: https://github.com/docarray/docarray
|
||||
stars: 3114
|
||||
owner_login: docarray
|
||||
owner_html_url: https://github.com/docarray
|
||||
- name: devpush
|
||||
html_url: https://github.com/hunvreus/devpush
|
||||
stars: 3097
|
||||
owner_login: hunvreus
|
||||
owner_html_url: https://github.com/hunvreus
|
||||
- name: fastapi-realworld-example-app
|
||||
html_url: https://github.com/nsidnev/fastapi-realworld-example-app
|
||||
stars: 3050
|
||||
owner_login: nsidnev
|
||||
owner_html_url: https://github.com/nsidnev
|
||||
- name: uvicorn-gunicorn-fastapi-docker
|
||||
html_url: https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker
|
||||
stars: 2911
|
||||
owner_login: tiangolo
|
||||
owner_html_url: https://github.com/tiangolo
|
||||
- name: mcp-context-forge
|
||||
html_url: https://github.com/IBM/mcp-context-forge
|
||||
stars: 2899
|
||||
owner_login: IBM
|
||||
owner_html_url: https://github.com/IBM
|
||||
- name: best-of-web-python
|
||||
html_url: https://github.com/ml-tooling/best-of-web-python
|
||||
stars: 2648
|
||||
owner_login: ml-tooling
|
||||
owner_html_url: https://github.com/ml-tooling
|
||||
- name: FastAPI-template
|
||||
html_url: https://github.com/s3rius/FastAPI-template
|
||||
stars: 2637
|
||||
owner_login: s3rius
|
||||
owner_html_url: https://github.com/s3rius
|
||||
- name: YC-Killer
|
||||
html_url: https://github.com/sahibzada-allahyar/YC-Killer
|
||||
stars: 2599
|
||||
owner_login: sahibzada-allahyar
|
||||
owner_html_url: https://github.com/sahibzada-allahyar
|
||||
- name: fastapi-react
|
||||
html_url: https://github.com/Buuntu/fastapi-react
|
||||
stars: 2569
|
||||
owner_login: Buuntu
|
||||
owner_html_url: https://github.com/Buuntu
|
||||
- name: Yuxi-Know
|
||||
html_url: https://github.com/xerrors/Yuxi-Know
|
||||
stars: 2563
|
||||
owner_login: xerrors
|
||||
owner_html_url: https://github.com/xerrors
|
||||
- name: sqladmin
|
||||
html_url: https://github.com/aminalaee/sqladmin
|
||||
stars: 2558
|
||||
owner_login: aminalaee
|
||||
owner_html_url: https://github.com/aminalaee
|
||||
- name: RasaGPT
|
||||
html_url: https://github.com/paulpierre/RasaGPT
|
||||
stars: 2451
|
||||
owner_login: paulpierre
|
||||
owner_html_url: https://github.com/paulpierre
|
||||
- name: supabase-py
|
||||
html_url: https://github.com/supabase/supabase-py
|
||||
stars: 2344
|
||||
owner_login: supabase
|
||||
owner_html_url: https://github.com/supabase
|
||||
- name: nextpy
|
||||
html_url: https://github.com/dot-agent/nextpy
|
||||
stars: 2335
|
||||
owner_login: dot-agent
|
||||
owner_html_url: https://github.com/dot-agent
|
||||
- name: fastapi-utils
|
||||
html_url: https://github.com/fastapiutils/fastapi-utils
|
||||
stars: 2291
|
||||
owner_login: fastapiutils
|
||||
owner_html_url: https://github.com/fastapiutils
|
||||
- name: 30-Days-of-Python
|
||||
html_url: https://github.com/codingforentrepreneurs/30-Days-of-Python
|
||||
stars: 2220
|
||||
owner_login: codingforentrepreneurs
|
||||
owner_html_url: https://github.com/codingforentrepreneurs
|
||||
- name: langserve
|
||||
html_url: https://github.com/langchain-ai/langserve
|
||||
stars: 2215
|
||||
owner_login: langchain-ai
|
||||
owner_html_url: https://github.com/langchain-ai
|
||||
- name: solara
|
||||
html_url: https://github.com/widgetti/solara
|
||||
stars: 2122
|
||||
owner_login: widgetti
|
||||
owner_html_url: https://github.com/widgetti
|
||||
- name: mangum
|
||||
html_url: https://github.com/Kludex/mangum
|
||||
stars: 2029
|
||||
owner_login: Kludex
|
||||
owner_html_url: https://github.com/Kludex
|
||||
- name: agentkit
|
||||
html_url: https://github.com/BCG-X-Official/agentkit
|
||||
stars: 1912
|
||||
owner_login: BCG-X-Official
|
||||
owner_html_url: https://github.com/BCG-X-Official
|
||||
- name: manage-fastapi
|
||||
html_url: https://github.com/ycd/manage-fastapi
|
||||
stars: 1885
|
||||
owner_login: ycd
|
||||
owner_html_url: https://github.com/ycd
|
||||
- name: openapi-python-client
|
||||
html_url: https://github.com/openapi-generators/openapi-python-client
|
||||
stars: 1862
|
||||
owner_login: openapi-generators
|
||||
owner_html_url: https://github.com/openapi-generators
|
||||
- name: piccolo
|
||||
html_url: https://github.com/piccolo-orm/piccolo
|
||||
stars: 1836
|
||||
owner_login: piccolo-orm
|
||||
owner_html_url: https://github.com/piccolo-orm
|
||||
- name: vue-fastapi-admin
|
||||
html_url: https://github.com/mizhexiaoxiao/vue-fastapi-admin
|
||||
stars: 1831
|
||||
owner_login: mizhexiaoxiao
|
||||
owner_html_url: https://github.com/mizhexiaoxiao
|
||||
- name: python-week-2022
|
||||
html_url: https://github.com/rochacbruno/python-week-2022
|
||||
stars: 1817
|
||||
owner_login: rochacbruno
|
||||
owner_html_url: https://github.com/rochacbruno
|
||||
- name: slowapi
|
||||
html_url: https://github.com/laurentS/slowapi
|
||||
stars: 1798
|
||||
owner_login: laurentS
|
||||
owner_html_url: https://github.com/laurentS
|
||||
- name: fastapi-cache
|
||||
html_url: https://github.com/long2ice/fastapi-cache
|
||||
stars: 1789
|
||||
owner_login: long2ice
|
||||
owner_html_url: https://github.com/long2ice
|
||||
- name: ormar
|
||||
html_url: https://github.com/collerek/ormar
|
||||
stars: 1783
|
||||
owner_login: collerek
|
||||
owner_html_url: https://github.com/collerek
|
||||
- name: termpair
|
||||
html_url: https://github.com/cs01/termpair
|
||||
stars: 1716
|
||||
owner_login: cs01
|
||||
owner_html_url: https://github.com/cs01
|
||||
- name: FastAPI-boilerplate
|
||||
html_url: https://github.com/benavlabs/FastAPI-boilerplate
|
||||
stars: 1660
|
||||
owner_login: benavlabs
|
||||
owner_html_url: https://github.com/benavlabs
|
||||
- name: fastapi-langgraph-agent-production-ready-template
|
||||
html_url: https://github.com/wassim249/fastapi-langgraph-agent-production-ready-template
|
||||
stars: 1638
|
||||
owner_login: wassim249
|
||||
owner_html_url: https://github.com/wassim249
|
||||
- name: langchain-serve
|
||||
html_url: https://github.com/jina-ai/langchain-serve
|
||||
stars: 1635
|
||||
owner_login: jina-ai
|
||||
owner_html_url: https://github.com/jina-ai
|
||||
- name: awesome-fastapi-projects
|
||||
html_url: https://github.com/Kludex/awesome-fastapi-projects
|
||||
stars: 1589
|
||||
owner_login: Kludex
|
||||
owner_html_url: https://github.com/Kludex
|
||||
- name: fastapi-pagination
|
||||
html_url: https://github.com/uriyyo/fastapi-pagination
|
||||
stars: 1585
|
||||
owner_login: uriyyo
|
||||
owner_html_url: https://github.com/uriyyo
|
||||
- name: coronavirus-tracker-api
|
||||
html_url: https://github.com/ExpDev07/coronavirus-tracker-api
|
||||
stars: 1574
|
||||
owner_login: ExpDev07
|
||||
owner_html_url: https://github.com/ExpDev07
|
||||
- name: fastapi-crudrouter
|
||||
html_url: https://github.com/awtkns/fastapi-crudrouter
|
||||
stars: 1559
|
||||
owner_login: awtkns
|
||||
owner_html_url: https://github.com/awtkns
|
||||
- name: bracket
|
||||
html_url: https://github.com/evroon/bracket
|
||||
stars: 1489
|
||||
owner_login: evroon
|
||||
owner_html_url: https://github.com/evroon
|
||||
- name: fastapi-amis-admin
|
||||
html_url: https://github.com/amisadmin/fastapi-amis-admin
|
||||
stars: 1475
|
||||
owner_login: amisadmin
|
||||
owner_html_url: https://github.com/amisadmin
|
||||
- name: fastapi-boilerplate
|
||||
html_url: https://github.com/teamhide/fastapi-boilerplate
|
||||
stars: 1436
|
||||
owner_login: teamhide
|
||||
owner_html_url: https://github.com/teamhide
|
||||
- name: awesome-python-resources
|
||||
html_url: https://github.com/DjangoEx/awesome-python-resources
|
||||
stars: 1426
|
||||
owner_login: DjangoEx
|
||||
owner_html_url: https://github.com/DjangoEx
|
||||
- name: fastcrud
|
||||
html_url: https://github.com/benavlabs/fastcrud
|
||||
stars: 1414
|
||||
owner_login: benavlabs
|
||||
owner_html_url: https://github.com/benavlabs
|
||||
- name: prometheus-fastapi-instrumentator
|
||||
html_url: https://github.com/trallnag/prometheus-fastapi-instrumentator
|
||||
stars: 1388
|
||||
owner_login: trallnag
|
||||
owner_html_url: https://github.com/trallnag
|
||||
- name: fastapi_best_architecture
|
||||
html_url: https://github.com/fastapi-practices/fastapi_best_architecture
|
||||
stars: 1378
|
||||
owner_login: fastapi-practices
|
||||
owner_html_url: https://github.com/fastapi-practices
|
||||
- name: fastapi-code-generator
|
||||
html_url: https://github.com/koxudaxi/fastapi-code-generator
|
||||
stars: 1375
|
||||
owner_login: koxudaxi
|
||||
owner_html_url: https://github.com/koxudaxi
|
||||
- name: budgetml
|
||||
html_url: https://github.com/ebhy/budgetml
|
||||
stars: 1345
|
||||
owner_login: ebhy
|
||||
owner_html_url: https://github.com/ebhy
|
||||
- name: fastapi-tutorial
|
||||
html_url: https://github.com/liaogx/fastapi-tutorial
|
||||
stars: 1327
|
||||
owner_login: liaogx
|
||||
owner_html_url: https://github.com/liaogx
|
||||
- name: fastapi-alembic-sqlmodel-async
|
||||
html_url: https://github.com/jonra1993/fastapi-alembic-sqlmodel-async
|
||||
stars: 1259
|
||||
owner_login: jonra1993
|
||||
owner_html_url: https://github.com/jonra1993
|
||||
- name: fastapi-scaff
|
||||
html_url: https://github.com/atpuxiner/fastapi-scaff
|
||||
stars: 1255
|
||||
owner_login: atpuxiner
|
||||
owner_html_url: https://github.com/atpuxiner
|
||||
- name: bedrock-chat
|
||||
html_url: https://github.com/aws-samples/bedrock-chat
|
||||
stars: 1254
|
||||
owner_login: aws-samples
|
||||
owner_html_url: https://github.com/aws-samples
|
||||
- name: bolt-python
|
||||
html_url: https://github.com/slackapi/bolt-python
|
||||
stars: 1253
|
||||
owner_login: slackapi
|
||||
owner_html_url: https://github.com/slackapi
|
||||
- name: fastapi_production_template
|
||||
html_url: https://github.com/zhanymkanov/fastapi_production_template
|
||||
stars: 1217
|
||||
owner_login: zhanymkanov
|
||||
owner_html_url: https://github.com/zhanymkanov
|
||||
- name: langchain-extract
|
||||
html_url: https://github.com/langchain-ai/langchain-extract
|
||||
stars: 1176
|
||||
owner_login: langchain-ai
|
||||
owner_html_url: https://github.com/langchain-ai
|
||||
- name: restish
|
||||
html_url: https://github.com/rest-sh/restish
|
||||
stars: 1140
|
||||
owner_login: rest-sh
|
||||
owner_html_url: https://github.com/rest-sh
|
||||
- name: odmantic
|
||||
html_url: https://github.com/art049/odmantic
|
||||
stars: 1138
|
||||
owner_login: art049
|
||||
owner_html_url: https://github.com/art049
|
||||
- name: authx
|
||||
html_url: https://github.com/yezz123/authx
|
||||
stars: 1119
|
||||
owner_login: yezz123
|
||||
owner_html_url: https://github.com/yezz123
|
||||
- name: NoteDiscovery
|
||||
html_url: https://github.com/gamosoft/NoteDiscovery
|
||||
stars: 1107
|
||||
owner_login: gamosoft
|
||||
owner_html_url: https://github.com/gamosoft
|
||||
- name: flock
|
||||
html_url: https://github.com/Onelevenvy/flock
|
||||
stars: 1055
|
||||
owner_login: Onelevenvy
|
||||
owner_html_url: https://github.com/Onelevenvy
|
||||
- name: fastapi-observability
|
||||
html_url: https://github.com/blueswen/fastapi-observability
|
||||
stars: 1038
|
||||
owner_login: blueswen
|
||||
owner_html_url: https://github.com/blueswen
|
||||
- name: aktools
|
||||
html_url: https://github.com/akfamily/aktools
|
||||
stars: 1027
|
||||
owner_login: akfamily
|
||||
owner_html_url: https://github.com/akfamily
|
||||
- name: RuoYi-Vue3-FastAPI
|
||||
html_url: https://github.com/insistence/RuoYi-Vue3-FastAPI
|
||||
stars: 1016
|
||||
owner_login: insistence
|
||||
owner_html_url: https://github.com/insistence
|
||||
- name: autollm
|
||||
html_url: https://github.com/viddexa/autollm
|
||||
stars: 1002
|
||||
owner_login: viddexa
|
||||
owner_html_url: https://github.com/viddexa
|
||||
- name: titiler
|
||||
html_url: https://github.com/developmentseed/titiler
|
||||
stars: 999
|
||||
owner_login: developmentseed
|
||||
owner_html_url: https://github.com/developmentseed
|
||||
- name: lanarky
|
||||
html_url: https://github.com/ajndkr/lanarky
|
||||
stars: 994
|
||||
owner_login: ajndkr
|
||||
owner_html_url: https://github.com/ajndkr
|
||||
- name: every-pdf
|
||||
html_url: https://github.com/DDULDDUCK/every-pdf
|
||||
stars: 985
|
||||
owner_login: DDULDDUCK
|
||||
owner_html_url: https://github.com/DDULDDUCK
|
||||
- name: enterprise-deep-research
|
||||
html_url: https://github.com/SalesforceAIResearch/enterprise-deep-research
|
||||
stars: 973
|
||||
owner_login: SalesforceAIResearch
|
||||
owner_html_url: https://github.com/SalesforceAIResearch
|
||||
- name: fastapi-mail
|
||||
html_url: https://github.com/sabuhish/fastapi-mail
|
||||
stars: 964
|
||||
owner_login: sabuhish
|
||||
owner_html_url: https://github.com/sabuhish
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,550 @@
|
||||
nilslindemann:
|
||||
login: nilslindemann
|
||||
count: 125
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6892179?u=1dca6a22195d6cd1ab20737c0e19a4c55d639472&v=4
|
||||
url: https://github.com/nilslindemann
|
||||
jaystone776:
|
||||
login: jaystone776
|
||||
count: 46
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/11191137?u=299205a95e9b6817a43144a48b643346a5aac5cc&v=4
|
||||
url: https://github.com/jaystone776
|
||||
ceb10n:
|
||||
login: ceb10n
|
||||
count: 29
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/235213?u=edcce471814a1eba9f0cdaa4cd0de18921a940a6&v=4
|
||||
url: https://github.com/ceb10n
|
||||
valentinDruzhinin:
|
||||
login: valentinDruzhinin
|
||||
count: 29
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/12831905?u=aae1ebc675c91e8fa582df4fcc4fc4128106344d&v=4
|
||||
url: https://github.com/valentinDruzhinin
|
||||
tokusumi:
|
||||
login: tokusumi
|
||||
count: 23
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/41147016?u=55010621aece725aa702270b54fed829b6a1fe60&v=4
|
||||
url: https://github.com/tokusumi
|
||||
SwftAlpc:
|
||||
login: SwftAlpc
|
||||
count: 23
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/52768429?u=6a3aa15277406520ad37f6236e89466ed44bc5b8&v=4
|
||||
url: https://github.com/SwftAlpc
|
||||
hasansezertasan:
|
||||
login: hasansezertasan
|
||||
count: 22
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13135006?u=99f0b0f0fc47e88e8abb337b4447357939ef93e7&v=4
|
||||
url: https://github.com/hasansezertasan
|
||||
waynerv:
|
||||
login: waynerv
|
||||
count: 20
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/39515546?u=ec35139777597cdbbbddda29bf8b9d4396b429a9&v=4
|
||||
url: https://github.com/waynerv
|
||||
AlertRED:
|
||||
login: AlertRED
|
||||
count: 16
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/15695000?u=f5a4944c6df443030409c88da7d7fa0b7ead985c&v=4
|
||||
url: https://github.com/AlertRED
|
||||
hard-coders:
|
||||
login: hard-coders
|
||||
count: 15
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/9651103?u=95db33927bbff1ed1c07efddeb97ac2ff33068ed&v=4
|
||||
url: https://github.com/hard-coders
|
||||
Joao-Pedro-P-Holanda:
|
||||
login: Joao-Pedro-P-Holanda
|
||||
count: 14
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/110267046?u=331bd016326dac4cf3df4848f6db2dbbf8b5f978&v=4
|
||||
url: https://github.com/Joao-Pedro-P-Holanda
|
||||
codingjenny:
|
||||
login: codingjenny
|
||||
count: 14
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/103817302?u=3a042740dc0ff58615da0d8679230966fd7693e8&v=4
|
||||
url: https://github.com/codingjenny
|
||||
Xewus:
|
||||
login: Xewus
|
||||
count: 13
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/85196001?u=f8e2dc7e5104f109cef944af79050ea8d1b8f914&v=4
|
||||
url: https://github.com/Xewus
|
||||
Zhongheng-Cheng:
|
||||
login: Zhongheng-Cheng
|
||||
count: 13
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/95612344?u=a0f7730a3cc7486827965e01a119ad610bda4b0a&v=4
|
||||
url: https://github.com/Zhongheng-Cheng
|
||||
Smlep:
|
||||
login: Smlep
|
||||
count: 11
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/16785985?u=ffe99fa954c8e774ef1117e58d34aece92051e27&v=4
|
||||
url: https://github.com/Smlep
|
||||
marcelomarkus:
|
||||
login: marcelomarkus
|
||||
count: 11
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/20115018?u=dda090ce9160ef0cd2ff69b1e5ea741283425cba&v=4
|
||||
url: https://github.com/marcelomarkus
|
||||
KaniKim:
|
||||
login: KaniKim
|
||||
count: 10
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/19832624?u=296dbdd490e0eb96e3d45a2608c065603b17dc31&v=4
|
||||
url: https://github.com/KaniKim
|
||||
Vincy1230:
|
||||
login: Vincy1230
|
||||
count: 9
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/81342412?u=ab5e256a4077a4a91f3f9cd2115ba80780454cbe&v=4
|
||||
url: https://github.com/Vincy1230
|
||||
rjNemo:
|
||||
login: rjNemo
|
||||
count: 8
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/56785022?u=d5c3a02567c8649e146fcfc51b6060ccaf8adef8&v=4
|
||||
url: https://github.com/rjNemo
|
||||
xzmeng:
|
||||
login: xzmeng
|
||||
count: 8
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/40202897?v=4
|
||||
url: https://github.com/xzmeng
|
||||
pablocm83:
|
||||
login: pablocm83
|
||||
count: 8
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/28315068?u=3310fbb05bb8bfc50d2c48b6cb64ac9ee4a14549&v=4
|
||||
url: https://github.com/pablocm83
|
||||
tiangolo:
|
||||
login: tiangolo
|
||||
count: 7
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1326112?u=cb5d06e73a9e1998141b1641aa88e443c6717651&v=4
|
||||
url: https://github.com/tiangolo
|
||||
ptt3199:
|
||||
login: ptt3199
|
||||
count: 7
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/51350651?u=2c3d947a80283e32bf616d4c3af139a6be69680f&v=4
|
||||
url: https://github.com/ptt3199
|
||||
NinaHwang:
|
||||
login: NinaHwang
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/79563565?u=241f2cb6d38a2d379536608a8ea5a22ed4b1a3ea&v=4
|
||||
url: https://github.com/NinaHwang
|
||||
batlopes:
|
||||
login: batlopes
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/33462923?u=0fb3d7acb316764616f11e4947faf080e49ad8d9&v=4
|
||||
url: https://github.com/batlopes
|
||||
lucasbalieiro:
|
||||
login: lucasbalieiro
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/37416577?u=dad91601ee4f40458d691774ec439aff308344d7&v=4
|
||||
url: https://github.com/lucasbalieiro
|
||||
Alexandrhub:
|
||||
login: Alexandrhub
|
||||
count: 6
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/119126536?u=9fc0d48f3307817bafecc5861eb2168401a6cb04&v=4
|
||||
url: https://github.com/Alexandrhub
|
||||
Serrones:
|
||||
login: Serrones
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/22691749?u=4795b880e13ca33a73e52fc0ef7dc9c60c8fce47&v=4
|
||||
url: https://github.com/Serrones
|
||||
RunningIkkyu:
|
||||
login: RunningIkkyu
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31848542?u=494ecc298e3f26197495bb357ad0f57cfd5f7a32&v=4
|
||||
url: https://github.com/RunningIkkyu
|
||||
Attsun1031:
|
||||
login: Attsun1031
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1175560?v=4
|
||||
url: https://github.com/Attsun1031
|
||||
rostik1410:
|
||||
login: rostik1410
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/11443899?u=e26a635c2ba220467b308a326a579b8ccf4a8701&v=4
|
||||
url: https://github.com/rostik1410
|
||||
alv2017:
|
||||
login: alv2017
|
||||
count: 5
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31544722?v=4
|
||||
url: https://github.com/alv2017
|
||||
komtaki:
|
||||
login: komtaki
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/39375566?u=260ad6b1a4b34c07dbfa728da5e586f16f6d1824&v=4
|
||||
url: https://github.com/komtaki
|
||||
JulianMaurin:
|
||||
login: JulianMaurin
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/63545168?u=b7d15ac865268cbefc2d739e2f23d9aeeac1a622&v=4
|
||||
url: https://github.com/JulianMaurin
|
||||
stlucasgarcia:
|
||||
login: stlucasgarcia
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/61513630?u=c22d8850e9dc396a8820766a59837f967e14f9a0&v=4
|
||||
url: https://github.com/stlucasgarcia
|
||||
ComicShrimp:
|
||||
login: ComicShrimp
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/43503750?u=d2fbf412e7730183ce91686ca48d4147e1b7dc74&v=4
|
||||
url: https://github.com/ComicShrimp
|
||||
BilalAlpaslan:
|
||||
login: BilalAlpaslan
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/47563997?u=63ed66e304fe8d765762c70587d61d9196e5c82d&v=4
|
||||
url: https://github.com/BilalAlpaslan
|
||||
axel584:
|
||||
login: axel584
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1334088?u=9667041f5b15dc002b6f9665fda8c0412933ac04&v=4
|
||||
url: https://github.com/axel584
|
||||
tamtam-fitness:
|
||||
login: tamtam-fitness
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/62091034?u=8da19a6bd3d02f5d6ba30c7247d5b46c98dd1403&v=4
|
||||
url: https://github.com/tamtam-fitness
|
||||
Limsunoh:
|
||||
login: Limsunoh
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/90311848?u=f456e0c5709fd50c8cd2898b551558eda14e5f21&v=4
|
||||
url: https://github.com/Limsunoh
|
||||
kwang1215:
|
||||
login: kwang1215
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/74170199?u=2a63ff6692119dde3f5e5693365b9fcd6f977b08&v=4
|
||||
url: https://github.com/kwang1215
|
||||
k94-ishi:
|
||||
login: k94-ishi
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/32672580?u=bc7c5c07af0656be9fe4f1784a444af8d81ded89&v=4
|
||||
url: https://github.com/k94-ishi
|
||||
Mohammad222PR:
|
||||
login: Mohammad222PR
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/116789737?u=25810a5fe049d2f1618e2e7417cea011cc353ce4&v=4
|
||||
url: https://github.com/Mohammad222PR
|
||||
NavesSapnis:
|
||||
login: NavesSapnis
|
||||
count: 4
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/79222417?u=b5b10291b8e9130ca84fd20f0a641e04ed94b6b1&v=4
|
||||
url: https://github.com/NavesSapnis
|
||||
jfunez:
|
||||
login: jfunez
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/805749?v=4
|
||||
url: https://github.com/jfunez
|
||||
ycd:
|
||||
login: ycd
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/62724709?u=f1e7bae394a315da950912c92dc861a8eaf95d4c&v=4
|
||||
url: https://github.com/ycd
|
||||
mariacamilagl:
|
||||
login: mariacamilagl
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/11489395?u=4adb6986bf3debfc2b8216ae701f2bd47d73da7d&v=4
|
||||
url: https://github.com/mariacamilagl
|
||||
maoyibo:
|
||||
login: maoyibo
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/7887703?v=4
|
||||
url: https://github.com/maoyibo
|
||||
blt232018:
|
||||
login: blt232018
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/43393471?u=172b0e0391db1aa6c1706498d6dfcb003c8a4857&v=4
|
||||
url: https://github.com/blt232018
|
||||
magiskboy:
|
||||
login: magiskboy
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/13352088?u=18b6d672523f9e9d98401f31dd50e28bb27d826f&v=4
|
||||
url: https://github.com/magiskboy
|
||||
luccasmmg:
|
||||
login: luccasmmg
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/11317382?u=65099a5a0d492b89119471f8a7014637cc2e04da&v=4
|
||||
url: https://github.com/luccasmmg
|
||||
lbmendes:
|
||||
login: lbmendes
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/80999926?u=646619e2f07ac5a7c3f65fe7834197461a4fff9f&v=4
|
||||
url: https://github.com/lbmendes
|
||||
Zssaer:
|
||||
login: Zssaer
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/45691504?u=4c0c195f25cb5ac6af32acfb0ab35427682938d2&v=4
|
||||
url: https://github.com/Zssaer
|
||||
ChuyuChoyeon:
|
||||
login: ChuyuChoyeon
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/129537877?u=f0c76f3327817a8b86b422d62e04a34bf2827f2b&v=4
|
||||
url: https://github.com/ChuyuChoyeon
|
||||
ivan-abc:
|
||||
login: ivan-abc
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/36765187?u=c6e0ba571c1ccb6db9d94e62e4b8b5eda811a870&v=4
|
||||
url: https://github.com/ivan-abc
|
||||
mojtabapaso:
|
||||
login: mojtabapaso
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/121169359?u=ced1d5ad673bcd9e949ebf967a4ab50185637443&v=4
|
||||
url: https://github.com/mojtabapaso
|
||||
hsuanchi:
|
||||
login: hsuanchi
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/24913710?u=7d25a398e478b6e63503bf6f26c54efa9e0da07b&v=4
|
||||
url: https://github.com/hsuanchi
|
||||
alejsdev:
|
||||
login: alejsdev
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/90076947?u=85ceac49fb87138aebe8d663912e359447329090&v=4
|
||||
url: https://github.com/alejsdev
|
||||
riroan:
|
||||
login: riroan
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/33053284?u=2d18e3771506ee874b66d6aa2b3b1107fd95c38f&v=4
|
||||
url: https://github.com/riroan
|
||||
nayeonkinn:
|
||||
login: nayeonkinn
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/98254573?u=64a75ac99b320d4935eff8d1fceea9680fa07473&v=4
|
||||
url: https://github.com/nayeonkinn
|
||||
pe-brian:
|
||||
login: pe-brian
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1783138?u=7e6242eb9e85bcf673fa88bbac9dd6dc3f03b1b5&v=4
|
||||
url: https://github.com/pe-brian
|
||||
maxscheijen:
|
||||
login: maxscheijen
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/47034840?v=4
|
||||
url: https://github.com/maxscheijen
|
||||
ilacftemp:
|
||||
login: ilacftemp
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/159066669?v=4
|
||||
url: https://github.com/ilacftemp
|
||||
devluisrodrigues:
|
||||
login: devluisrodrigues
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/103431660?u=d9674a3249edc4601d2c712cdebf899918503c3a&v=4
|
||||
url: https://github.com/devluisrodrigues
|
||||
devfernandoa:
|
||||
login: devfernandoa
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/28360583?u=c4308abd62e8847c9e572e1bb9fe6b9dc9ef8e50&v=4
|
||||
url: https://github.com/devfernandoa
|
||||
kim-sangah:
|
||||
login: kim-sangah
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/173775778?v=4
|
||||
url: https://github.com/kim-sangah
|
||||
9zimin9:
|
||||
login: 9zimin9
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/174453744?v=4
|
||||
url: https://github.com/9zimin9
|
||||
nahyunkeem:
|
||||
login: nahyunkeem
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/174440096?u=e12401d492eee58570f8914d0872b52e421a776e&v=4
|
||||
url: https://github.com/nahyunkeem
|
||||
timothy-jeong:
|
||||
login: timothy-jeong
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/53824764?u=db3d0cea2f5fab64d810113c5039a369699a2774&v=4
|
||||
url: https://github.com/timothy-jeong
|
||||
gerry-sabar:
|
||||
login: gerry-sabar
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1120123?v=4
|
||||
url: https://github.com/gerry-sabar
|
||||
Rishat-F:
|
||||
login: Rishat-F
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/66554797?v=4
|
||||
url: https://github.com/Rishat-F
|
||||
ruzia:
|
||||
login: ruzia
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/24503?v=4
|
||||
url: https://github.com/ruzia
|
||||
YuriiMotov:
|
||||
login: YuriiMotov
|
||||
count: 3
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/109919500?u=b9b13d598dddfab529a52d264df80a900bfe7060&v=4
|
||||
url: https://github.com/YuriiMotov
|
||||
izaguerreiro:
|
||||
login: izaguerreiro
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/2241504?v=4
|
||||
url: https://github.com/izaguerreiro
|
||||
Xaraxx:
|
||||
login: Xaraxx
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/29824698?u=dde2e233e22bb5ca1f8bb0c6e353ccd0d06e6066&v=4
|
||||
url: https://github.com/Xaraxx
|
||||
sh0nk:
|
||||
login: sh0nk
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/6478810?u=af15d724875cec682ed8088a86d36b2798f981c0&v=4
|
||||
url: https://github.com/sh0nk
|
||||
dukkee:
|
||||
login: dukkee
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/36825394?u=ccfd86e6a4f2d093dad6f7544cc875af67fa2df8&v=4
|
||||
url: https://github.com/dukkee
|
||||
oandersonmagalhaes:
|
||||
login: oandersonmagalhaes
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/83456692?v=4
|
||||
url: https://github.com/oandersonmagalhaes
|
||||
leandrodesouzadev:
|
||||
login: leandrodesouzadev
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/85115541?u=4eb25f43f1fe23727d61e986cf83b73b86e2a95a&v=4
|
||||
url: https://github.com/leandrodesouzadev
|
||||
kty4119:
|
||||
login: kty4119
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/49435654?v=4
|
||||
url: https://github.com/kty4119
|
||||
ASpathfinder:
|
||||
login: ASpathfinder
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/31813636?u=2090bd1b7abb65cfeff0c618f99f11afa82c0548&v=4
|
||||
url: https://github.com/ASpathfinder
|
||||
jujumilk3:
|
||||
login: jujumilk3
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/41659814?u=538f7dfef03b59f25e43f10d59a31c19ef538a0c&v=4
|
||||
url: https://github.com/jujumilk3
|
||||
ayr-ton:
|
||||
login: ayr-ton
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1090517?u=5cf70a0e0f0dbf084e074e494aa94d7c91a46ba6&v=4
|
||||
url: https://github.com/ayr-ton
|
||||
KdHyeon0661:
|
||||
login: KdHyeon0661
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/20253352?u=5ae1aae34b091a39f22cbe60a02b79dcbdbea031&v=4
|
||||
url: https://github.com/KdHyeon0661
|
||||
LorhanSohaky:
|
||||
login: LorhanSohaky
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/16273730?u=095b66f243a2cd6a0aadba9a095009f8aaf18393&v=4
|
||||
url: https://github.com/LorhanSohaky
|
||||
cfraboulet:
|
||||
login: cfraboulet
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/62244267?u=ed0e286ba48fa1dafd64a08e50f3364b8e12df34&v=4
|
||||
url: https://github.com/cfraboulet
|
||||
dedkot01:
|
||||
login: dedkot01
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/26196675?u=e2966887124e67932853df4f10f86cb526edc7b0&v=4
|
||||
url: https://github.com/dedkot01
|
||||
AGolicyn:
|
||||
login: AGolicyn
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/86262613?u=3c21606ab8d210a061a1673decff1e7d5592b380&v=4
|
||||
url: https://github.com/AGolicyn
|
||||
fhabers21:
|
||||
login: fhabers21
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/58401847?v=4
|
||||
url: https://github.com/fhabers21
|
||||
TabarakoAkula:
|
||||
login: TabarakoAkula
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/113298631?u=add801e370dbc502cd94ce6d3484760d7fef5406&v=4
|
||||
url: https://github.com/TabarakoAkula
|
||||
AhsanSheraz:
|
||||
login: AhsanSheraz
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/51913596?u=08e31cacb3048be30722c94010ddd028f3fdbec4&v=4
|
||||
url: https://github.com/AhsanSheraz
|
||||
ArtemKhymenko:
|
||||
login: ArtemKhymenko
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/14346625?u=f2fa553d9e5ec5e0f05d66bd649f7be347169631&v=4
|
||||
url: https://github.com/ArtemKhymenko
|
||||
hasnatsajid:
|
||||
login: hasnatsajid
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/86589885?u=6668823c3b029bfecf10a8918ed3af1aafb8b15e&v=4
|
||||
url: https://github.com/hasnatsajid
|
||||
alperiox:
|
||||
login: alperiox
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/34214152?u=2c5acad3461d4dbc2d48371ba86cac56ae9b25cc&v=4
|
||||
url: https://github.com/alperiox
|
||||
emrhnsyts:
|
||||
login: emrhnsyts
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/42899027?u=ad26798e3f8feed2041c5dd5f87e58933d6c3283&v=4
|
||||
url: https://github.com/emrhnsyts
|
||||
vusallyv:
|
||||
login: vusallyv
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/85983771?u=6fb8e2f876bca06e9f846606423c8f18fb46ad06&v=4
|
||||
url: https://github.com/vusallyv
|
||||
jackleeio:
|
||||
login: jackleeio
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/20477587?u=c5184dab6d021733d10c8f975b20e391856303d6&v=4
|
||||
url: https://github.com/jackleeio
|
||||
choi-haram:
|
||||
login: choi-haram
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/62204475?v=4
|
||||
url: https://github.com/choi-haram
|
||||
imtiaz101325:
|
||||
login: imtiaz101325
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/54007087?u=194d972b501b9ea9d2ddeaed757c492936e0121a&v=4
|
||||
url: https://github.com/imtiaz101325
|
||||
fabianfalon:
|
||||
login: fabianfalon
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/3700760?u=95f69e31280b17ac22299cdcd345323b142fe0af&v=4
|
||||
url: https://github.com/fabianfalon
|
||||
waketzheng:
|
||||
login: waketzheng
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/35413830?u=df19e4fd5bb928e7d086e053ef26a46aad23bf84&v=4
|
||||
url: https://github.com/waketzheng
|
||||
billzhong:
|
||||
login: billzhong
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/1644011?v=4
|
||||
url: https://github.com/billzhong
|
||||
chaoless:
|
||||
login: chaoless
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/64477804?v=4
|
||||
url: https://github.com/chaoless
|
||||
logan2d5:
|
||||
login: logan2d5
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/146642263?u=dbd6621f8b0330d6919f6a7131277b92e26fbe87&v=4
|
||||
url: https://github.com/logan2d5
|
||||
andersonrocha0:
|
||||
login: andersonrocha0
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/22346169?u=93a1359c8c5461d894802c0cc65bcd09217e7a02&v=4
|
||||
url: https://github.com/andersonrocha0
|
||||
saeye:
|
||||
login: saeye
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/62229734?u=312d619db2588b60d5d5bde65260a2f44fdc6c76&v=4
|
||||
url: https://github.com/saeye
|
||||
11kkw:
|
||||
login: 11kkw
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/21125286?v=4
|
||||
url: https://github.com/11kkw
|
||||
yes0ng:
|
||||
login: yes0ng
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/25501794?u=3aed18b0d491e0220a167a1e9e58bea3638c6707&v=4
|
||||
url: https://github.com/yes0ng
|
||||
EgorOnishchuk:
|
||||
login: EgorOnishchuk
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/120256301?v=4
|
||||
url: https://github.com/EgorOnishchuk
|
||||
EdmilsonRodrigues:
|
||||
login: EdmilsonRodrigues
|
||||
count: 2
|
||||
avatarUrl: https://avatars.githubusercontent.com/u/62777025?u=217d6f3cd6cc750bb8818a3af7726c8d74eb7c2d&v=4
|
||||
url: https://github.com/EdmilsonRodrigues
|
||||
@@ -0,0 +1,503 @@
|
||||
# LLM test file { #llm-test-file }
|
||||
|
||||
This document tests if the <abbr title="Large Language Model">LLM</abbr>, which translates the documentation, understands the `general_prompt` in `scripts/translate.py` and the language specific prompt in `docs/{language code}/llm-prompt.md`. The language specific prompt is appended to `general_prompt`.
|
||||
|
||||
Tests added here will be seen by all designers of language specific prompts.
|
||||
|
||||
Use as follows:
|
||||
|
||||
* Have a language specific prompt – `docs/{language code}/llm-prompt.md`.
|
||||
* Do a fresh translation of this document into your desired target language (see e.g. the `translate-page` command of the `translate.py`). This will create the translation under `docs/{language code}/docs/_llm-test.md`.
|
||||
* Check if things are okay in the translation.
|
||||
* If necessary, improve your language specific prompt, the general prompt, or the English document.
|
||||
* Then manually fix the remaining issues in the translation, so that it is a good translation.
|
||||
* Retranslate, having the good translation in place. The ideal result would be that the LLM makes no changes anymore to the translation. That means that the general prompt and your language specific prompt are as good as they can be (It will sometimes make a few seemingly random changes, the reason is that <a href="https://doublespeak.chat/#/handbook#deterministic-output" class="external-link" target="_blank">LLMs are not deterministic algorithms</a>).
|
||||
|
||||
The tests:
|
||||
|
||||
## Code snippets { #code-snippets}
|
||||
|
||||
//// tab | Test
|
||||
|
||||
This is a code snippet: `foo`. And this is another code snippet: `bar`. And another one: `baz quux`.
|
||||
|
||||
////
|
||||
|
||||
//// tab | Info
|
||||
|
||||
Content of code snippets should be left as is.
|
||||
|
||||
See section `### Content of code snippets` in the general prompt in `scripts/translate.py`.
|
||||
|
||||
////
|
||||
|
||||
## Quotes { #quotes }
|
||||
|
||||
//// tab | Test
|
||||
|
||||
Yesterday, my friend wrote: "If you spell incorrectly correctly, you have spelled it incorrectly". To which I answered: "Correct, but 'incorrectly' is incorrectly not '"incorrectly"'".
|
||||
|
||||
/// note
|
||||
|
||||
The LLM will probably translate this wrong. Interesting is only if it keeps the fixed translation when retranslating.
|
||||
|
||||
///
|
||||
|
||||
////
|
||||
|
||||
//// tab | Info
|
||||
|
||||
The prompt designer may choose if they want to convert neutral quotes to typographic quotes. It is okay to leave them as is.
|
||||
|
||||
See for example section `### Quotes` in `docs/de/llm-prompt.md`.
|
||||
|
||||
////
|
||||
|
||||
## Quotes in code snippets { #quotes-in-code-snippets}
|
||||
|
||||
//// tab | Test
|
||||
|
||||
`pip install "foo[bar]"`
|
||||
|
||||
Examples for string literals in code snippets: `"this"`, `'that'`.
|
||||
|
||||
A difficult example for string literals in code snippets: `f"I like {'oranges' if orange else "apples"}"`
|
||||
|
||||
Hardcore: `Yesterday, my friend wrote: "If you spell incorrectly correctly, you have spelled it incorrectly". To which I answered: "Correct, but 'incorrectly' is incorrectly not '"incorrectly"'"`
|
||||
|
||||
////
|
||||
|
||||
//// tab | Info
|
||||
|
||||
... However, quotes inside code snippets must stay as is.
|
||||
|
||||
////
|
||||
|
||||
## code blocks { #code-blocks }
|
||||
|
||||
//// tab | Test
|
||||
|
||||
A Bash code example...
|
||||
|
||||
```bash
|
||||
# Print a greeting to the universe
|
||||
echo "Hello universe"
|
||||
```
|
||||
|
||||
...and a console code example...
|
||||
|
||||
```console
|
||||
$ <font color="#4E9A06">fastapi</font> run <u style="text-decoration-style:solid">main.py</u>
|
||||
<span style="background-color:#009485"><font color="#D3D7CF"> FastAPI </font></span> Starting server
|
||||
Searching for package file structure
|
||||
```
|
||||
|
||||
...and another console code example...
|
||||
|
||||
```console
|
||||
// Create a directory "Code"
|
||||
$ mkdir code
|
||||
// Switch into that directory
|
||||
$ cd code
|
||||
```
|
||||
|
||||
...and a Python code example...
|
||||
|
||||
```Python
|
||||
wont_work() # This won't work 😱
|
||||
works(foo="bar") # This works 🎉
|
||||
```
|
||||
|
||||
...and that's it.
|
||||
|
||||
////
|
||||
|
||||
//// tab | Info
|
||||
|
||||
Code in code blocks should not be modified, with the exception of comments.
|
||||
|
||||
See section `### Content of code blocks` in the general prompt in `scripts/translate.py`.
|
||||
|
||||
////
|
||||
|
||||
## Tabs and colored boxes { #tabs-and-colored-boxes }
|
||||
|
||||
//// tab | Test
|
||||
|
||||
/// info
|
||||
Some text
|
||||
///
|
||||
|
||||
/// note
|
||||
Some text
|
||||
///
|
||||
|
||||
/// note | Technical details
|
||||
Some text
|
||||
///
|
||||
|
||||
/// check
|
||||
Some text
|
||||
///
|
||||
|
||||
/// tip
|
||||
Some text
|
||||
///
|
||||
|
||||
/// warning
|
||||
Some text
|
||||
///
|
||||
|
||||
/// danger
|
||||
Some text
|
||||
///
|
||||
|
||||
////
|
||||
|
||||
//// tab | Info
|
||||
|
||||
Tabs and `Info`/`Note`/`Warning`/etc. blocks should have the translation of their title added after a vertical bar (`|`).
|
||||
|
||||
See sections `### Special blocks` and `### Tab blocks` in the general prompt in `scripts/translate.py`.
|
||||
|
||||
////
|
||||
|
||||
## Web- and internal links { #web-and-internal-links }
|
||||
|
||||
//// tab | Test
|
||||
|
||||
The link text should get translated, the link address should remain unchaged:
|
||||
|
||||
* [Link to heading above](#code-snippets)
|
||||
* [Internal link](index.md#installation){.internal-link target=_blank}
|
||||
* <a href="https://sqlmodel.tiangolo.com/" class="external-link" target="_blank">External link</a>
|
||||
* <a href="https://fastapi.tiangolo.com/css/styles.css" class="external-link" target="_blank">Link to a style</a>
|
||||
* <a href="https://fastapi.tiangolo.com/js/logic.js" class="external-link" target="_blank">Link to a script</a>
|
||||
* <a href="https://fastapi.tiangolo.com/img/foo.jpg" class="external-link" target="_blank">Link to an image</a>
|
||||
|
||||
The link text should get translated, the link address should point to the translation:
|
||||
|
||||
* <a href="https://fastapi.tiangolo.com/" class="external-link" target="_blank">FastAPI link</a>
|
||||
|
||||
////
|
||||
|
||||
//// tab | Info
|
||||
|
||||
Links should be translated, but their address shall remain unchanged. An exception are absolute links to pages of the FastAPI documentation. In that case it should link to the translation.
|
||||
|
||||
See section `### Links` in the general prompt in `scripts/translate.py`.
|
||||
|
||||
////
|
||||
|
||||
## HTML "abbr" elements { #html-abbr-elements }
|
||||
|
||||
//// tab | Test
|
||||
|
||||
Here some things wrapped in HTML "abbr" elements (Some are invented):
|
||||
|
||||
### The abbr gives a full phrase { #the-abbr-gives-a-full-phrase }
|
||||
|
||||
* <abbr title="Getting Things Done">GTD</abbr>
|
||||
* <abbr title="less than"><code>lt</code></abbr>
|
||||
* <abbr title="XML Web Token">XWT</abbr>
|
||||
* <abbr title="Parallel Server Gateway Interface">PSGI</abbr>
|
||||
|
||||
### The abbr gives an explanation { #the-abbr-gives-an-explanation }
|
||||
|
||||
* <abbr title="A group of machines that are configured to be connected and work together in some way.">cluster</abbr>
|
||||
* <abbr title="A method of machine learning that uses artificial neural networks with numerous hidden layers between input and output layers, thereby developing a comprehensive internal structure">Deep Learning</abbr>
|
||||
|
||||
### The abbr gives a full phrase and an explanation { #the-abbr-gives-a-full-phrase-and-an-explanation }
|
||||
|
||||
* <abbr title="Mozilla Developer Network: documentation for developers, written by the Firefox people">MDN</abbr>
|
||||
* <abbr title="Input/Output: disk reading or writing, network communications.">I/O</abbr>.
|
||||
|
||||
////
|
||||
|
||||
//// tab | Info
|
||||
|
||||
"title" attributes of "abbr" elements are translated following some specific instructions.
|
||||
|
||||
Translations can add their own "abbr" elements which the LLM should not remove. E.g. to explain English words.
|
||||
|
||||
See section `### HTML abbr elements` in the general prompt in `scripts/translate.py`.
|
||||
|
||||
////
|
||||
|
||||
## Headings { #headings }
|
||||
|
||||
//// tab | Test
|
||||
|
||||
### Develop a webapp - a tutorial { #develop-a-webapp-a-tutorial }
|
||||
|
||||
Hello.
|
||||
|
||||
### Type hints and -annotations { #type-hints-and-annotations }
|
||||
|
||||
Hello again.
|
||||
|
||||
### Super- and subclasses { #super-and-subclasses }
|
||||
|
||||
Hello again.
|
||||
|
||||
////
|
||||
|
||||
//// tab | Info
|
||||
|
||||
The only hard rule for headings is that the LLM leaves the hash part inside curly brackets unchanged, which ensures that links do not break.
|
||||
|
||||
See section `### Headings` in the general prompt in `scripts/translate.py`.
|
||||
|
||||
For some language specific instructions, see e.g. section `### Headings` in `docs/de/llm-prompt.md`.
|
||||
|
||||
////
|
||||
|
||||
## Terms used in the docs { #terms-used-in-the-docs }
|
||||
|
||||
//// tab | Test
|
||||
|
||||
* you
|
||||
* your
|
||||
|
||||
* e.g.
|
||||
* etc.
|
||||
|
||||
* `foo` as an `int`
|
||||
* `bar` as a `str`
|
||||
* `baz` as a `list`
|
||||
|
||||
* the Tutorial - User guide
|
||||
* the Advanced User Guide
|
||||
* the SQLModel docs
|
||||
* the API docs
|
||||
* the automatic docs
|
||||
|
||||
* Data Science
|
||||
* Deep Learning
|
||||
* Machine Learning
|
||||
* Dependency Injection
|
||||
* HTTP Basic authentication
|
||||
* HTTP Digest
|
||||
* ISO format
|
||||
* the JSON Schema standard
|
||||
* the JSON schema
|
||||
* the schema definition
|
||||
* Password Flow
|
||||
* Mobile
|
||||
|
||||
* deprecated
|
||||
* designed
|
||||
* invalid
|
||||
* on the fly
|
||||
* standard
|
||||
* default
|
||||
* case-sensitive
|
||||
* case-insensitive
|
||||
|
||||
* to serve the application
|
||||
* to serve the page
|
||||
|
||||
* the app
|
||||
* the application
|
||||
|
||||
* the request
|
||||
* the response
|
||||
* the error response
|
||||
|
||||
* the path operation
|
||||
* the path operation decorator
|
||||
* the path operation function
|
||||
|
||||
* the body
|
||||
* the request body
|
||||
* the response body
|
||||
* the JSON body
|
||||
* the form body
|
||||
* the file body
|
||||
* the function body
|
||||
|
||||
* the parameter
|
||||
* the body parameter
|
||||
* the path parameter
|
||||
* the query parameter
|
||||
* the cookie parameter
|
||||
* the header parameter
|
||||
* the form parameter
|
||||
* the function parameter
|
||||
|
||||
* the event
|
||||
* the startup event
|
||||
* the startup of the server
|
||||
* the shutdown event
|
||||
* the lifespan event
|
||||
|
||||
* the handler
|
||||
* the event handler
|
||||
* the exception handler
|
||||
* to handle
|
||||
|
||||
* the model
|
||||
* the Pydantic model
|
||||
* the data model
|
||||
* the database model
|
||||
* the form model
|
||||
* the model object
|
||||
|
||||
* the class
|
||||
* the base class
|
||||
* the parent class
|
||||
* the subclass
|
||||
* the child class
|
||||
* the sibling class
|
||||
* the class method
|
||||
|
||||
* the header
|
||||
* the headers
|
||||
* the authorization header
|
||||
* the `Authorization` header
|
||||
* the forwarded header
|
||||
|
||||
* the dependency injection system
|
||||
* the dependency
|
||||
* the dependable
|
||||
* the dependant
|
||||
|
||||
* I/O bound
|
||||
* CPU bound
|
||||
* concurrency
|
||||
* parallelism
|
||||
* multiprocessing
|
||||
|
||||
* the env var
|
||||
* the environment variable
|
||||
* the `PATH`
|
||||
* the `PATH` variable
|
||||
|
||||
* the authentication
|
||||
* the authentication provider
|
||||
* the authorization
|
||||
* the authorization form
|
||||
* the authorization provider
|
||||
* the user authenticates
|
||||
* the system authenticates the user
|
||||
|
||||
* the CLI
|
||||
* the command line interface
|
||||
|
||||
* the server
|
||||
* the client
|
||||
|
||||
* the cloud provider
|
||||
* the cloud service
|
||||
|
||||
* the development
|
||||
* the development stages
|
||||
|
||||
* the dict
|
||||
* the dictionary
|
||||
* the enumeration
|
||||
* the enum
|
||||
* the enum member
|
||||
|
||||
* the encoder
|
||||
* the decoder
|
||||
* to encode
|
||||
* to decode
|
||||
|
||||
* the exception
|
||||
* to raise
|
||||
|
||||
* the expression
|
||||
* the statement
|
||||
|
||||
* the frontend
|
||||
* the backend
|
||||
|
||||
* the GitHub discussion
|
||||
* the GitHub issue
|
||||
|
||||
* the performance
|
||||
* the performance optimization
|
||||
|
||||
* the return type
|
||||
* the return value
|
||||
|
||||
* the security
|
||||
* the security scheme
|
||||
|
||||
* the task
|
||||
* the background task
|
||||
* the task function
|
||||
|
||||
* the template
|
||||
* the template engine
|
||||
|
||||
* the type annotation
|
||||
* the type hint
|
||||
|
||||
* the server worker
|
||||
* the Uvicorn worker
|
||||
* the Gunicorn Worker
|
||||
* the worker process
|
||||
* the worker class
|
||||
* the workload
|
||||
|
||||
* the deployment
|
||||
* to deploy
|
||||
|
||||
* the SDK
|
||||
* the software development kit
|
||||
|
||||
* the `APIRouter`
|
||||
* the `requirements.txt`
|
||||
* the Bearer Token
|
||||
* the breaking change
|
||||
* the bug
|
||||
* the button
|
||||
* the callable
|
||||
* the code
|
||||
* the commit
|
||||
* the context manager
|
||||
* the coroutine
|
||||
* the database session
|
||||
* the disk
|
||||
* the domain
|
||||
* the engine
|
||||
* the fake X
|
||||
* the HTTP GET method
|
||||
* the item
|
||||
* the library
|
||||
* the lifespan
|
||||
* the lock
|
||||
* the middleware
|
||||
* the mobile application
|
||||
* the module
|
||||
* the mounting
|
||||
* the network
|
||||
* the origin
|
||||
* the override
|
||||
* the payload
|
||||
* the processor
|
||||
* the property
|
||||
* the proxy
|
||||
* the pull request
|
||||
* the query
|
||||
* the RAM
|
||||
* the remote machine
|
||||
* the status code
|
||||
* the string
|
||||
* the tag
|
||||
* the web framework
|
||||
* the wildcard
|
||||
* to return
|
||||
* to validate
|
||||
|
||||
////
|
||||
|
||||
//// tab | Info
|
||||
|
||||
This is a not complete and not normative list of (mostly) technical terms seen in the docs. It may be helpful for the prompt designer to figure out for which terms the LLM needs a helping hand. For example when it keeps reverting a good translation to a suboptimal translation. Or when it has problems conjugating/declinating a term in your language.
|
||||
|
||||
See e.g. section `### List of English terms and their preferred German translations` in `docs/de/llm-prompt.md`.
|
||||
|
||||
////
|
||||
@@ -0,0 +1,3 @@
|
||||
# About { #about }
|
||||
|
||||
About FastAPI, its design, inspiration and more. 🤓
|
||||
@@ -0,0 +1,247 @@
|
||||
# Additional Responses in OpenAPI { #additional-responses-in-openapi }
|
||||
|
||||
/// warning
|
||||
|
||||
This is a rather advanced topic.
|
||||
|
||||
If you are starting with **FastAPI**, you might not need this.
|
||||
|
||||
///
|
||||
|
||||
You can declare additional responses, with additional status codes, media types, descriptions, etc.
|
||||
|
||||
Those additional responses will be included in the OpenAPI schema, so they will also appear in the API docs.
|
||||
|
||||
But for those additional responses you have to make sure you return a `Response` like `JSONResponse` directly, with your status code and content.
|
||||
|
||||
## Additional Response with `model` { #additional-response-with-model }
|
||||
|
||||
You can pass to your *path operation decorators* a parameter `responses`.
|
||||
|
||||
It receives a `dict`: the keys are status codes for each response (like `200`), and the values are other `dict`s with the information for each of them.
|
||||
|
||||
Each of those response `dict`s can have a key `model`, containing a Pydantic model, just like `response_model`.
|
||||
|
||||
**FastAPI** will take that model, generate its JSON Schema and include it in the correct place in OpenAPI.
|
||||
|
||||
For example, to declare another response with a status code `404` and a Pydantic model `Message`, you can write:
|
||||
|
||||
{* ../../docs_src/additional_responses/tutorial001.py hl[18,22] *}
|
||||
|
||||
/// note
|
||||
|
||||
Keep in mind that you have to return the `JSONResponse` directly.
|
||||
|
||||
///
|
||||
|
||||
/// info
|
||||
|
||||
The `model` key is not part of OpenAPI.
|
||||
|
||||
**FastAPI** will take the Pydantic model from there, generate the JSON Schema, and put it in the correct place.
|
||||
|
||||
The correct place is:
|
||||
|
||||
* In the key `content`, that has as value another JSON object (`dict`) that contains:
|
||||
* A key with the media type, e.g. `application/json`, that contains as value another JSON object, that contains:
|
||||
* A key `schema`, that has as the value the JSON Schema from the model, here's the correct place.
|
||||
* **FastAPI** adds a reference here to the global JSON Schemas in another place in your OpenAPI instead of including it directly. This way, other applications and clients can use those JSON Schemas directly, provide better code generation tools, etc.
|
||||
|
||||
///
|
||||
|
||||
The generated responses in the OpenAPI for this *path operation* will be:
|
||||
|
||||
```JSON hl_lines="3-12"
|
||||
{
|
||||
"responses": {
|
||||
"404": {
|
||||
"description": "Additional Response",
|
||||
"content": {
|
||||
"application/json": {
|
||||
"schema": {
|
||||
"$ref": "#/components/schemas/Message"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"200": {
|
||||
"description": "Successful Response",
|
||||
"content": {
|
||||
"application/json": {
|
||||
"schema": {
|
||||
"$ref": "#/components/schemas/Item"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"422": {
|
||||
"description": "Validation Error",
|
||||
"content": {
|
||||
"application/json": {
|
||||
"schema": {
|
||||
"$ref": "#/components/schemas/HTTPValidationError"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The schemas are referenced to another place inside the OpenAPI schema:
|
||||
|
||||
```JSON hl_lines="4-16"
|
||||
{
|
||||
"components": {
|
||||
"schemas": {
|
||||
"Message": {
|
||||
"title": "Message",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"message": {
|
||||
"title": "Message",
|
||||
"type": "string"
|
||||
}
|
||||
}
|
||||
},
|
||||
"Item": {
|
||||
"title": "Item",
|
||||
"required": [
|
||||
"id",
|
||||
"value"
|
||||
],
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"id": {
|
||||
"title": "Id",
|
||||
"type": "string"
|
||||
},
|
||||
"value": {
|
||||
"title": "Value",
|
||||
"type": "string"
|
||||
}
|
||||
}
|
||||
},
|
||||
"ValidationError": {
|
||||
"title": "ValidationError",
|
||||
"required": [
|
||||
"loc",
|
||||
"msg",
|
||||
"type"
|
||||
],
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"loc": {
|
||||
"title": "Location",
|
||||
"type": "array",
|
||||
"items": {
|
||||
"type": "string"
|
||||
}
|
||||
},
|
||||
"msg": {
|
||||
"title": "Message",
|
||||
"type": "string"
|
||||
},
|
||||
"type": {
|
||||
"title": "Error Type",
|
||||
"type": "string"
|
||||
}
|
||||
}
|
||||
},
|
||||
"HTTPValidationError": {
|
||||
"title": "HTTPValidationError",
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"detail": {
|
||||
"title": "Detail",
|
||||
"type": "array",
|
||||
"items": {
|
||||
"$ref": "#/components/schemas/ValidationError"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Additional media types for the main response { #additional-media-types-for-the-main-response }
|
||||
|
||||
You can use this same `responses` parameter to add different media types for the same main response.
|
||||
|
||||
For example, you can add an additional media type of `image/png`, declaring that your *path operation* can return a JSON object (with media type `application/json`) or a PNG image:
|
||||
|
||||
{* ../../docs_src/additional_responses/tutorial002.py hl[19:24,28] *}
|
||||
|
||||
/// note
|
||||
|
||||
Notice that you have to return the image using a `FileResponse` directly.
|
||||
|
||||
///
|
||||
|
||||
/// info
|
||||
|
||||
Unless you specify a different media type explicitly in your `responses` parameter, FastAPI will assume the response has the same media type as the main response class (default `application/json`).
|
||||
|
||||
But if you have specified a custom response class with `None` as its media type, FastAPI will use `application/json` for any additional response that has an associated model.
|
||||
|
||||
///
|
||||
|
||||
## Combining information { #combining-information }
|
||||
|
||||
You can also combine response information from multiple places, including the `response_model`, `status_code`, and `responses` parameters.
|
||||
|
||||
You can declare a `response_model`, using the default status code `200` (or a custom one if you need), and then declare additional information for that same response in `responses`, directly in the OpenAPI schema.
|
||||
|
||||
**FastAPI** will keep the additional information from `responses`, and combine it with the JSON Schema from your model.
|
||||
|
||||
For example, you can declare a response with a status code `404` that uses a Pydantic model and has a custom `description`.
|
||||
|
||||
And a response with a status code `200` that uses your `response_model`, but includes a custom `example`:
|
||||
|
||||
{* ../../docs_src/additional_responses/tutorial003.py hl[20:31] *}
|
||||
|
||||
It will all be combined and included in your OpenAPI, and shown in the API docs:
|
||||
|
||||
<img src="/img/tutorial/additional-responses/image01.png">
|
||||
|
||||
## Combine predefined responses and custom ones { #combine-predefined-responses-and-custom-ones }
|
||||
|
||||
You might want to have some predefined responses that apply to many *path operations*, but you want to combine them with custom responses needed by each *path operation*.
|
||||
|
||||
For those cases, you can use the Python technique of "unpacking" a `dict` with `**dict_to_unpack`:
|
||||
|
||||
```Python
|
||||
old_dict = {
|
||||
"old key": "old value",
|
||||
"second old key": "second old value",
|
||||
}
|
||||
new_dict = {**old_dict, "new key": "new value"}
|
||||
```
|
||||
|
||||
Here, `new_dict` will contain all the key-value pairs from `old_dict` plus the new key-value pair:
|
||||
|
||||
```Python
|
||||
{
|
||||
"old key": "old value",
|
||||
"second old key": "second old value",
|
||||
"new key": "new value",
|
||||
}
|
||||
```
|
||||
|
||||
You can use that technique to reuse some predefined responses in your *path operations* and combine them with additional custom ones.
|
||||
|
||||
For example:
|
||||
|
||||
{* ../../docs_src/additional_responses/tutorial004.py hl[13:17,26] *}
|
||||
|
||||
## More information about OpenAPI responses { #more-information-about-openapi-responses }
|
||||
|
||||
To see what exactly you can include in the responses, you can check these sections in the OpenAPI specification:
|
||||
|
||||
* <a href="https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md#responses-object" class="external-link" target="_blank">OpenAPI Responses Object</a>, it includes the `Response Object`.
|
||||
* <a href="https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md#response-object" class="external-link" target="_blank">OpenAPI Response Object</a>, you can include anything from this directly in each response inside your `responses` parameter. Including `description`, `headers`, `content` (inside of this is that you declare different media types and JSON Schemas), and `links`.
|
||||
@@ -0,0 +1,41 @@
|
||||
# Additional Status Codes { #additional-status-codes }
|
||||
|
||||
By default, **FastAPI** will return the responses using a `JSONResponse`, putting the content you return from your *path operation* inside of that `JSONResponse`.
|
||||
|
||||
It will use the default status code or the one you set in your *path operation*.
|
||||
|
||||
## Additional status codes { #additional-status-codes_1 }
|
||||
|
||||
If you want to return additional status codes apart from the main one, you can do that by returning a `Response` directly, like a `JSONResponse`, and set the additional status code directly.
|
||||
|
||||
For example, let's say that you want to have a *path operation* that allows to update items, and returns HTTP status codes of 200 "OK" when successful.
|
||||
|
||||
But you also want it to accept new items. And when the items didn't exist before, it creates them, and returns an HTTP status code of 201 "Created".
|
||||
|
||||
To achieve that, import `JSONResponse`, and return your content there directly, setting the `status_code` that you want:
|
||||
|
||||
{* ../../docs_src/additional_status_codes/tutorial001_an_py310.py hl[4,25] *}
|
||||
|
||||
/// warning
|
||||
|
||||
When you return a `Response` directly, like in the example above, it will be returned directly.
|
||||
|
||||
It won't be serialized with a model, etc.
|
||||
|
||||
Make sure it has the data you want it to have, and that the values are valid JSON (if you are using `JSONResponse`).
|
||||
|
||||
///
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
You could also use `from starlette.responses import JSONResponse`.
|
||||
|
||||
**FastAPI** provides the same `starlette.responses` as `fastapi.responses` just as a convenience for you, the developer. But most of the available responses come directly from Starlette. The same with `status`.
|
||||
|
||||
///
|
||||
|
||||
## OpenAPI and API docs { #openapi-and-api-docs }
|
||||
|
||||
If you return additional status codes and responses directly, they won't be included in the OpenAPI schema (the API docs), because FastAPI doesn't have a way to know beforehand what you are going to return.
|
||||
|
||||
But you can document that in your code, using: [Additional Responses](additional-responses.md){.internal-link target=_blank}.
|
||||
@@ -0,0 +1,163 @@
|
||||
# Advanced Dependencies { #advanced-dependencies }
|
||||
|
||||
## Parameterized dependencies { #parameterized-dependencies }
|
||||
|
||||
All the dependencies we have seen are a fixed function or class.
|
||||
|
||||
But there could be cases where you want to be able to set parameters on the dependency, without having to declare many different functions or classes.
|
||||
|
||||
Let's imagine that we want to have a dependency that checks if the query parameter `q` contains some fixed content.
|
||||
|
||||
But we want to be able to parameterize that fixed content.
|
||||
|
||||
## A "callable" instance { #a-callable-instance }
|
||||
|
||||
In Python there's a way to make an instance of a class a "callable".
|
||||
|
||||
Not the class itself (which is already a callable), but an instance of that class.
|
||||
|
||||
To do that, we declare a method `__call__`:
|
||||
|
||||
{* ../../docs_src/dependencies/tutorial011_an_py39.py hl[12] *}
|
||||
|
||||
In this case, this `__call__` is what **FastAPI** will use to check for additional parameters and sub-dependencies, and this is what will be called to pass a value to the parameter in your *path operation function* later.
|
||||
|
||||
## Parameterize the instance { #parameterize-the-instance }
|
||||
|
||||
And now, we can use `__init__` to declare the parameters of the instance that we can use to "parameterize" the dependency:
|
||||
|
||||
{* ../../docs_src/dependencies/tutorial011_an_py39.py hl[9] *}
|
||||
|
||||
In this case, **FastAPI** won't ever touch or care about `__init__`, we will use it directly in our code.
|
||||
|
||||
## Create an instance { #create-an-instance }
|
||||
|
||||
We could create an instance of this class with:
|
||||
|
||||
{* ../../docs_src/dependencies/tutorial011_an_py39.py hl[18] *}
|
||||
|
||||
And that way we are able to "parameterize" our dependency, that now has `"bar"` inside of it, as the attribute `checker.fixed_content`.
|
||||
|
||||
## Use the instance as a dependency { #use-the-instance-as-a-dependency }
|
||||
|
||||
Then, we could use this `checker` in a `Depends(checker)`, instead of `Depends(FixedContentQueryChecker)`, because the dependency is the instance, `checker`, not the class itself.
|
||||
|
||||
And when solving the dependency, **FastAPI** will call this `checker` like:
|
||||
|
||||
```Python
|
||||
checker(q="somequery")
|
||||
```
|
||||
|
||||
...and pass whatever that returns as the value of the dependency in our *path operation function* as the parameter `fixed_content_included`:
|
||||
|
||||
{* ../../docs_src/dependencies/tutorial011_an_py39.py hl[22] *}
|
||||
|
||||
/// tip
|
||||
|
||||
All this might seem contrived. And it might not be very clear how is it useful yet.
|
||||
|
||||
These examples are intentionally simple, but show how it all works.
|
||||
|
||||
In the chapters about security, there are utility functions that are implemented in this same way.
|
||||
|
||||
If you understood all this, you already know how those utility tools for security work underneath.
|
||||
|
||||
///
|
||||
|
||||
## Dependencies with `yield`, `HTTPException`, `except` and Background Tasks { #dependencies-with-yield-httpexception-except-and-background-tasks }
|
||||
|
||||
/// warning
|
||||
|
||||
You most probably don't need these technical details.
|
||||
|
||||
These details are useful mainly if you had a FastAPI application older than 0.121.0 and you are facing issues with dependencies with `yield`.
|
||||
|
||||
///
|
||||
|
||||
Dependencies with `yield` have evolved over time to account for the different use cases and to fix some issues, here's a summary of what has changed.
|
||||
|
||||
### Dependencies with `yield` and `scope` { #dependencies-with-yield-and-scope }
|
||||
|
||||
In version 0.121.0, FastAPI added support for `Depends(scope="function")` for dependencies with `yield`.
|
||||
|
||||
Using `Depends(scope="function")`, the exit code after `yield` is executed right after the *path operation function* is finished, before the response is sent back to the client.
|
||||
|
||||
And when using `Depends(scope="request")` (the default), the exit code after `yield` is executed after the response is sent.
|
||||
|
||||
You can read more about it in the docs for [Dependencies with `yield` - Early exit and `scope`](../tutorial/dependencies/dependencies-with-yield.md#early-exit-and-scope).
|
||||
|
||||
### Dependencies with `yield` and `StreamingResponse`, Technical Details { #dependencies-with-yield-and-streamingresponse-technical-details }
|
||||
|
||||
Before FastAPI 0.118.0, if you used a dependency with `yield`, it would run the exit code after the *path operation function* returned but right before sending the response.
|
||||
|
||||
The intention was to avoid holding resources for longer than necessary, waiting for the response to travel through the network.
|
||||
|
||||
This change also meant that if you returned a `StreamingResponse`, the exit code of the dependency with `yield` would have been already run.
|
||||
|
||||
For example, if you had a database session in a dependency with `yield`, the `StreamingResponse` would not be able to use that session while streaming data because the session would have already been closed in the exit code after `yield`.
|
||||
|
||||
This behavior was reverted in 0.118.0, to make the exit code after `yield` be executed after the response is sent.
|
||||
|
||||
/// info
|
||||
|
||||
As you will see below, this is very similar to the behavior before version 0.106.0, but with several improvements and bug fixes for corner cases.
|
||||
|
||||
///
|
||||
|
||||
#### Use Cases with Early Exit Code { #use-cases-with-early-exit-code }
|
||||
|
||||
There are some use cases with specific conditions that could benefit from the old behavior of running the exit code of dependencies with `yield` before sending the response.
|
||||
|
||||
For example, imagine you have code that uses a database session in a dependency with `yield` only to verify a user, but the database session is never used again in the *path operation function*, only in the dependency, **and** the response takes a long time to be sent, like a `StreamingResponse` that sends data slowly, but for some reason doesn't use the database.
|
||||
|
||||
In this case, the database session would be held until the response is finished being sent, but if you don't use it, then it wouldn't be necessary to hold it.
|
||||
|
||||
Here's how it could look like:
|
||||
|
||||
{* ../../docs_src/dependencies/tutorial013_an_py310.py *}
|
||||
|
||||
The exit code, the automatic closing of the `Session` in:
|
||||
|
||||
{* ../../docs_src/dependencies/tutorial013_an_py310.py ln[19:21] *}
|
||||
|
||||
...would be run after the the response finishes sending the slow data:
|
||||
|
||||
{* ../../docs_src/dependencies/tutorial013_an_py310.py ln[30:38] hl[31:33] *}
|
||||
|
||||
But as `generate_stream()` doesn't use the database session, it is not really necessary to keep the session open while sending the response.
|
||||
|
||||
If you have this specific use case using SQLModel (or SQLAlchemy), you could explicitly close the session after you don't need it anymore:
|
||||
|
||||
{* ../../docs_src/dependencies/tutorial014_an_py310.py ln[24:28] hl[28] *}
|
||||
|
||||
That way the session would release the database connection, so other requests could use it.
|
||||
|
||||
If you have a different use case that needs to exit early from a dependency with `yield`, please create a <a href="https://github.com/fastapi/fastapi/discussions/new?category=questions" class="external-link" target="_blank">GitHub Discussion Question</a> with your specific use case and why you would benefit from having early closing for dependencies with `yield`.
|
||||
|
||||
If there are compelling use cases for early closing in dependencies with `yield`, I would consider adding a new way to opt in to early closing.
|
||||
|
||||
### Dependencies with `yield` and `except`, Technical Details { #dependencies-with-yield-and-except-technical-details }
|
||||
|
||||
Before FastAPI 0.110.0, if you used a dependency with `yield`, and then you captured an exception with `except` in that dependency, and you didn't raise the exception again, the exception would be automatically raised/forwarded to any exception handlers or the internal server error handler.
|
||||
|
||||
This was changed in version 0.110.0 to fix unhandled memory consumption from forwarded exceptions without a handler (internal server errors), and to make it consistent with the behavior of regular Python code.
|
||||
|
||||
### Background Tasks and Dependencies with `yield`, Technical Details { #background-tasks-and-dependencies-with-yield-technical-details }
|
||||
|
||||
Before FastAPI 0.106.0, raising exceptions after `yield` was not possible, the exit code in dependencies with `yield` was executed *after* the response was sent, so [Exception Handlers](../tutorial/handling-errors.md#install-custom-exception-handlers){.internal-link target=_blank} would have already run.
|
||||
|
||||
This was designed this way mainly to allow using the same objects "yielded" by dependencies inside of background tasks, because the exit code would be executed after the background tasks were finished.
|
||||
|
||||
This was changed in FastAPI 0.106.0 with the intention to not hold resources while waiting for the response to travel through the network.
|
||||
|
||||
/// tip
|
||||
|
||||
Additionally, a background task is normally an independent set of logic that should be handled separately, with its own resources (e.g. its own database connection).
|
||||
|
||||
So, this way you will probably have cleaner code.
|
||||
|
||||
///
|
||||
|
||||
If you used to rely on this behavior, now you should create the resources for background tasks inside the background task itself, and use internally only data that doesn't depend on the resources of dependencies with `yield`.
|
||||
|
||||
For example, instead of using the same database session, you would create a new database session inside of the background task, and you would obtain the objects from the database using this new session. And then instead of passing the object from the database as a parameter to the background task function, you would pass the ID of that object and then obtain the object again inside the background task function.
|
||||
@@ -0,0 +1,99 @@
|
||||
# Async Tests { #async-tests }
|
||||
|
||||
You have already seen how to test your **FastAPI** applications using the provided `TestClient`. Up to now, you have only seen how to write synchronous tests, without using `async` functions.
|
||||
|
||||
Being able to use asynchronous functions in your tests could be useful, for example, when you're querying your database asynchronously. Imagine you want to test sending requests to your FastAPI application and then verify that your backend successfully wrote the correct data in the database, while using an async database library.
|
||||
|
||||
Let's look at how we can make that work.
|
||||
|
||||
## pytest.mark.anyio { #pytest-mark-anyio }
|
||||
|
||||
If we want to call asynchronous functions in our tests, our test functions have to be asynchronous. AnyIO provides a neat plugin for this, that allows us to specify that some test functions are to be called asynchronously.
|
||||
|
||||
## HTTPX { #httpx }
|
||||
|
||||
Even if your **FastAPI** application uses normal `def` functions instead of `async def`, it is still an `async` application underneath.
|
||||
|
||||
The `TestClient` does some magic inside to call the asynchronous FastAPI application in your normal `def` test functions, using standard pytest. But that magic doesn't work anymore when we're using it inside asynchronous functions. By running our tests asynchronously, we can no longer use the `TestClient` inside our test functions.
|
||||
|
||||
The `TestClient` is based on <a href="https://www.python-httpx.org" class="external-link" target="_blank">HTTPX</a>, and luckily, we can use it directly to test the API.
|
||||
|
||||
## Example { #example }
|
||||
|
||||
For a simple example, let's consider a file structure similar to the one described in [Bigger Applications](../tutorial/bigger-applications.md){.internal-link target=_blank} and [Testing](../tutorial/testing.md){.internal-link target=_blank}:
|
||||
|
||||
```
|
||||
.
|
||||
├── app
|
||||
│ ├── __init__.py
|
||||
│ ├── main.py
|
||||
│ └── test_main.py
|
||||
```
|
||||
|
||||
The file `main.py` would have:
|
||||
|
||||
{* ../../docs_src/async_tests/main.py *}
|
||||
|
||||
The file `test_main.py` would have the tests for `main.py`, it could look like this now:
|
||||
|
||||
{* ../../docs_src/async_tests/test_main.py *}
|
||||
|
||||
## Run it { #run-it }
|
||||
|
||||
You can run your tests as usual via:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ pytest
|
||||
|
||||
---> 100%
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
## In Detail { #in-detail }
|
||||
|
||||
The marker `@pytest.mark.anyio` tells pytest that this test function should be called asynchronously:
|
||||
|
||||
{* ../../docs_src/async_tests/test_main.py hl[7] *}
|
||||
|
||||
/// tip
|
||||
|
||||
Note that the test function is now `async def` instead of just `def` as before when using the `TestClient`.
|
||||
|
||||
///
|
||||
|
||||
Then we can create an `AsyncClient` with the app, and send async requests to it, using `await`.
|
||||
|
||||
{* ../../docs_src/async_tests/test_main.py hl[9:12] *}
|
||||
|
||||
This is the equivalent to:
|
||||
|
||||
```Python
|
||||
response = client.get('/')
|
||||
```
|
||||
|
||||
...that we used to make our requests with the `TestClient`.
|
||||
|
||||
/// tip
|
||||
|
||||
Note that we're using async/await with the new `AsyncClient` - the request is asynchronous.
|
||||
|
||||
///
|
||||
|
||||
/// warning
|
||||
|
||||
If your application relies on lifespan events, the `AsyncClient` won't trigger these events. To ensure they are triggered, use `LifespanManager` from <a href="https://github.com/florimondmanca/asgi-lifespan#usage" class="external-link" target="_blank">florimondmanca/asgi-lifespan</a>.
|
||||
|
||||
///
|
||||
|
||||
## Other Asynchronous Function Calls { #other-asynchronous-function-calls }
|
||||
|
||||
As the testing function is now asynchronous, you can now also call (and `await`) other `async` functions apart from sending requests to your FastAPI application in your tests, exactly as you would call them anywhere else in your code.
|
||||
|
||||
/// tip
|
||||
|
||||
If you encounter a `RuntimeError: Task attached to a different loop` when integrating asynchronous function calls in your tests (e.g. when using <a href="https://stackoverflow.com/questions/41584243/runtimeerror-task-attached-to-a-different-loop" class="external-link" target="_blank">MongoDB's MotorClient</a>), remember to instantiate objects that need an event loop only within async functions, e.g. an `@app.on_event("startup")` callback.
|
||||
|
||||
///
|
||||
@@ -0,0 +1,466 @@
|
||||
# Behind a Proxy { #behind-a-proxy }
|
||||
|
||||
In many situations, you would use a **proxy** like Traefik or Nginx in front of your FastAPI app.
|
||||
|
||||
These proxies could handle HTTPS certificates and other things.
|
||||
|
||||
## Proxy Forwarded Headers { #proxy-forwarded-headers }
|
||||
|
||||
A **proxy** in front of your application would normally set some headers on the fly before sending the requests to your **server** to let the server know that the request was **forwarded** by the proxy, letting it know the original (public) URL, including the domain, that it is using HTTPS, etc.
|
||||
|
||||
The **server** program (for example **Uvicorn** via **FastAPI CLI**) is capable of interpreting these headers, and then passing that information to your application.
|
||||
|
||||
But for security, as the server doesn't know it is behind a trusted proxy, it won't interpret those headers.
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
The proxy headers are:
|
||||
|
||||
* <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For" class="external-link" target="_blank">X-Forwarded-For</a>
|
||||
* <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto" class="external-link" target="_blank">X-Forwarded-Proto</a>
|
||||
* <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Host" class="external-link" target="_blank">X-Forwarded-Host</a>
|
||||
|
||||
///
|
||||
|
||||
### Enable Proxy Forwarded Headers { #enable-proxy-forwarded-headers }
|
||||
|
||||
You can start FastAPI CLI with the *CLI Option* `--forwarded-allow-ips` and pass the IP addresses that should be trusted to read those forwarded headers.
|
||||
|
||||
If you set it to `--forwarded-allow-ips="*"` it would trust all the incoming IPs.
|
||||
|
||||
If your **server** is behind a trusted **proxy** and only the proxy talks to it, this would make it accept whatever is the IP of that **proxy**.
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ fastapi run --forwarded-allow-ips="*"
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
### Redirects with HTTPS { #redirects-with-https }
|
||||
|
||||
For example, let's say you define a *path operation* `/items/`:
|
||||
|
||||
{* ../../docs_src/behind_a_proxy/tutorial001_01.py hl[6] *}
|
||||
|
||||
If the client tries to go to `/items`, by default, it would be redirected to `/items/`.
|
||||
|
||||
But before setting the *CLI Option* `--forwarded-allow-ips` it could redirect to `http://localhost:8000/items/`.
|
||||
|
||||
But maybe your application is hosted at `https://mysuperapp.com`, and the redirection should be to `https://mysuperapp.com/items/`.
|
||||
|
||||
By setting `--proxy-headers` now FastAPI would be able to redirect to the right location. 😎
|
||||
|
||||
```
|
||||
https://mysuperapp.com/items/
|
||||
```
|
||||
|
||||
/// tip
|
||||
|
||||
If you want to learn more about HTTPS, check the guide [About HTTPS](../deployment/https.md){.internal-link target=_blank}.
|
||||
|
||||
///
|
||||
|
||||
### How Proxy Forwarded Headers Work { #how-proxy-forwarded-headers-work }
|
||||
|
||||
Here's a visual representation of how the **proxy** adds forwarded headers between the client and the **application server**:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Client
|
||||
participant Proxy as Proxy/Load Balancer
|
||||
participant Server as FastAPI Server
|
||||
|
||||
Client->>Proxy: HTTPS Request<br/>Host: mysuperapp.com<br/>Path: /items
|
||||
|
||||
Note over Proxy: Proxy adds forwarded headers
|
||||
|
||||
Proxy->>Server: HTTP Request<br/>X-Forwarded-For: [client IP]<br/>X-Forwarded-Proto: https<br/>X-Forwarded-Host: mysuperapp.com<br/>Path: /items
|
||||
|
||||
Note over Server: Server interprets headers<br/>(if --forwarded-allow-ips is set)
|
||||
|
||||
Server->>Proxy: HTTP Response<br/>with correct HTTPS URLs
|
||||
|
||||
Proxy->>Client: HTTPS Response
|
||||
```
|
||||
|
||||
The **proxy** intercepts the original client request and adds the special *forwarded* headers (`X-Forwarded-*`) before passing the request to the **application server**.
|
||||
|
||||
These headers preserve information about the original request that would otherwise be lost:
|
||||
|
||||
* **X-Forwarded-For**: The original client's IP address
|
||||
* **X-Forwarded-Proto**: The original protocol (`https`)
|
||||
* **X-Forwarded-Host**: The original host (`mysuperapp.com`)
|
||||
|
||||
When **FastAPI CLI** is configured with `--forwarded-allow-ips`, it trusts these headers and uses them, for example to generate the correct URLs in redirects.
|
||||
|
||||
## Proxy with a stripped path prefix { #proxy-with-a-stripped-path-prefix }
|
||||
|
||||
You could have a proxy that adds a path prefix to your application.
|
||||
|
||||
In these cases you can use `root_path` to configure your application.
|
||||
|
||||
The `root_path` is a mechanism provided by the ASGI specification (that FastAPI is built on, through Starlette).
|
||||
|
||||
The `root_path` is used to handle these specific cases.
|
||||
|
||||
And it's also used internally when mounting sub-applications.
|
||||
|
||||
Having a proxy with a stripped path prefix, in this case, means that you could declare a path at `/app` in your code, but then, you add a layer on top (the proxy) that would put your **FastAPI** application under a path like `/api/v1`.
|
||||
|
||||
In this case, the original path `/app` would actually be served at `/api/v1/app`.
|
||||
|
||||
Even though all your code is written assuming there's just `/app`.
|
||||
|
||||
{* ../../docs_src/behind_a_proxy/tutorial001.py hl[6] *}
|
||||
|
||||
And the proxy would be **"stripping"** the **path prefix** on the fly before transmitting the request to the app server (probably Uvicorn via FastAPI CLI), keeping your application convinced that it is being served at `/app`, so that you don't have to update all your code to include the prefix `/api/v1`.
|
||||
|
||||
Up to here, everything would work as normally.
|
||||
|
||||
But then, when you open the integrated docs UI (the frontend), it would expect to get the OpenAPI schema at `/openapi.json`, instead of `/api/v1/openapi.json`.
|
||||
|
||||
So, the frontend (that runs in the browser) would try to reach `/openapi.json` and wouldn't be able to get the OpenAPI schema.
|
||||
|
||||
Because we have a proxy with a path prefix of `/api/v1` for our app, the frontend needs to fetch the OpenAPI schema at `/api/v1/openapi.json`.
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
|
||||
browser("Browser")
|
||||
proxy["Proxy on http://0.0.0.0:9999/api/v1/app"]
|
||||
server["Server on http://127.0.0.1:8000/app"]
|
||||
|
||||
browser --> proxy
|
||||
proxy --> server
|
||||
```
|
||||
|
||||
/// tip
|
||||
|
||||
The IP `0.0.0.0` is commonly used to mean that the program listens on all the IPs available in that machine/server.
|
||||
|
||||
///
|
||||
|
||||
The docs UI would also need the OpenAPI schema to declare that this API `server` is located at `/api/v1` (behind the proxy). For example:
|
||||
|
||||
```JSON hl_lines="4-8"
|
||||
{
|
||||
"openapi": "3.1.0",
|
||||
// More stuff here
|
||||
"servers": [
|
||||
{
|
||||
"url": "/api/v1"
|
||||
}
|
||||
],
|
||||
"paths": {
|
||||
// More stuff here
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In this example, the "Proxy" could be something like **Traefik**. And the server would be something like FastAPI CLI with **Uvicorn**, running your FastAPI application.
|
||||
|
||||
### Providing the `root_path` { #providing-the-root-path }
|
||||
|
||||
To achieve this, you can use the command line option `--root-path` like:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ fastapi run main.py --forwarded-allow-ips="*" --root-path /api/v1
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
If you use Hypercorn, it also has the option `--root-path`.
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
The ASGI specification defines a `root_path` for this use case.
|
||||
|
||||
And the `--root-path` command line option provides that `root_path`.
|
||||
|
||||
///
|
||||
|
||||
### Checking the current `root_path` { #checking-the-current-root-path }
|
||||
|
||||
You can get the current `root_path` used by your application for each request, it is part of the `scope` dictionary (that's part of the ASGI spec).
|
||||
|
||||
Here we are including it in the message just for demonstration purposes.
|
||||
|
||||
{* ../../docs_src/behind_a_proxy/tutorial001.py hl[8] *}
|
||||
|
||||
Then, if you start Uvicorn with:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ fastapi run main.py --forwarded-allow-ips="*" --root-path /api/v1
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
The response would be something like:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"message": "Hello World",
|
||||
"root_path": "/api/v1"
|
||||
}
|
||||
```
|
||||
|
||||
### Setting the `root_path` in the FastAPI app { #setting-the-root-path-in-the-fastapi-app }
|
||||
|
||||
Alternatively, if you don't have a way to provide a command line option like `--root-path` or equivalent, you can set the `root_path` parameter when creating your FastAPI app:
|
||||
|
||||
{* ../../docs_src/behind_a_proxy/tutorial002.py hl[3] *}
|
||||
|
||||
Passing the `root_path` to `FastAPI` would be the equivalent of passing the `--root-path` command line option to Uvicorn or Hypercorn.
|
||||
|
||||
### About `root_path` { #about-root-path }
|
||||
|
||||
Keep in mind that the server (Uvicorn) won't use that `root_path` for anything else than passing it to the app.
|
||||
|
||||
But if you go with your browser to <a href="http://127.0.0.1:8000/app" class="external-link" target="_blank">http://127.0.0.1:8000/app</a> you will see the normal response:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"message": "Hello World",
|
||||
"root_path": "/api/v1"
|
||||
}
|
||||
```
|
||||
|
||||
So, it won't expect to be accessed at `http://127.0.0.1:8000/api/v1/app`.
|
||||
|
||||
Uvicorn will expect the proxy to access Uvicorn at `http://127.0.0.1:8000/app`, and then it would be the proxy's responsibility to add the extra `/api/v1` prefix on top.
|
||||
|
||||
## About proxies with a stripped path prefix { #about-proxies-with-a-stripped-path-prefix }
|
||||
|
||||
Keep in mind that a proxy with stripped path prefix is only one of the ways to configure it.
|
||||
|
||||
Probably in many cases the default will be that the proxy doesn't have a stripped path prefix.
|
||||
|
||||
In a case like that (without a stripped path prefix), the proxy would listen on something like `https://myawesomeapp.com`, and then if the browser goes to `https://myawesomeapp.com/api/v1/app` and your server (e.g. Uvicorn) listens on `http://127.0.0.1:8000` the proxy (without a stripped path prefix) would access Uvicorn at the same path: `http://127.0.0.1:8000/api/v1/app`.
|
||||
|
||||
## Testing locally with Traefik { #testing-locally-with-traefik }
|
||||
|
||||
You can easily run the experiment locally with a stripped path prefix using <a href="https://docs.traefik.io/" class="external-link" target="_blank">Traefik</a>.
|
||||
|
||||
<a href="https://github.com/containous/traefik/releases" class="external-link" target="_blank">Download Traefik</a>, it's a single binary, you can extract the compressed file and run it directly from the terminal.
|
||||
|
||||
Then create a file `traefik.toml` with:
|
||||
|
||||
```TOML hl_lines="3"
|
||||
[entryPoints]
|
||||
[entryPoints.http]
|
||||
address = ":9999"
|
||||
|
||||
[providers]
|
||||
[providers.file]
|
||||
filename = "routes.toml"
|
||||
```
|
||||
|
||||
This tells Traefik to listen on port 9999 and to use another file `routes.toml`.
|
||||
|
||||
/// tip
|
||||
|
||||
We are using port 9999 instead of the standard HTTP port 80 so that you don't have to run it with admin (`sudo`) privileges.
|
||||
|
||||
///
|
||||
|
||||
Now create that other file `routes.toml`:
|
||||
|
||||
```TOML hl_lines="5 12 20"
|
||||
[http]
|
||||
[http.middlewares]
|
||||
|
||||
[http.middlewares.api-stripprefix.stripPrefix]
|
||||
prefixes = ["/api/v1"]
|
||||
|
||||
[http.routers]
|
||||
|
||||
[http.routers.app-http]
|
||||
entryPoints = ["http"]
|
||||
service = "app"
|
||||
rule = "PathPrefix(`/api/v1`)"
|
||||
middlewares = ["api-stripprefix"]
|
||||
|
||||
[http.services]
|
||||
|
||||
[http.services.app]
|
||||
[http.services.app.loadBalancer]
|
||||
[[http.services.app.loadBalancer.servers]]
|
||||
url = "http://127.0.0.1:8000"
|
||||
```
|
||||
|
||||
This file configures Traefik to use the path prefix `/api/v1`.
|
||||
|
||||
And then Traefik will redirect its requests to your Uvicorn running on `http://127.0.0.1:8000`.
|
||||
|
||||
Now start Traefik:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ ./traefik --configFile=traefik.toml
|
||||
|
||||
INFO[0000] Configuration loaded from file: /home/user/awesomeapi/traefik.toml
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
And now start your app, using the `--root-path` option:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ fastapi run main.py --forwarded-allow-ips="*" --root-path /api/v1
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
### Check the responses { #check-the-responses }
|
||||
|
||||
Now, if you go to the URL with the port for Uvicorn: <a href="http://127.0.0.1:8000/app" class="external-link" target="_blank">http://127.0.0.1:8000/app</a>, you will see the normal response:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"message": "Hello World",
|
||||
"root_path": "/api/v1"
|
||||
}
|
||||
```
|
||||
|
||||
/// tip
|
||||
|
||||
Notice that even though you are accessing it at `http://127.0.0.1:8000/app` it shows the `root_path` of `/api/v1`, taken from the option `--root-path`.
|
||||
|
||||
///
|
||||
|
||||
And now open the URL with the port for Traefik, including the path prefix: <a href="http://127.0.0.1:9999/api/v1/app" class="external-link" target="_blank">http://127.0.0.1:9999/api/v1/app</a>.
|
||||
|
||||
We get the same response:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"message": "Hello World",
|
||||
"root_path": "/api/v1"
|
||||
}
|
||||
```
|
||||
|
||||
but this time at the URL with the prefix path provided by the proxy: `/api/v1`.
|
||||
|
||||
Of course, the idea here is that everyone would access the app through the proxy, so the version with the path prefix `/api/v1` is the "correct" one.
|
||||
|
||||
And the version without the path prefix (`http://127.0.0.1:8000/app`), provided by Uvicorn directly, would be exclusively for the _proxy_ (Traefik) to access it.
|
||||
|
||||
That demonstrates how the Proxy (Traefik) uses the path prefix and how the server (Uvicorn) uses the `root_path` from the option `--root-path`.
|
||||
|
||||
### Check the docs UI { #check-the-docs-ui }
|
||||
|
||||
But here's the fun part. ✨
|
||||
|
||||
The "official" way to access the app would be through the proxy with the path prefix that we defined. So, as we would expect, if you try the docs UI served by Uvicorn directly, without the path prefix in the URL, it won't work, because it expects to be accessed through the proxy.
|
||||
|
||||
You can check it at <a href="http://127.0.0.1:8000/docs" class="external-link" target="_blank">http://127.0.0.1:8000/docs</a>:
|
||||
|
||||
<img src="/img/tutorial/behind-a-proxy/image01.png">
|
||||
|
||||
But if we access the docs UI at the "official" URL using the proxy with port `9999`, at `/api/v1/docs`, it works correctly! 🎉
|
||||
|
||||
You can check it at <a href="http://127.0.0.1:9999/api/v1/docs" class="external-link" target="_blank">http://127.0.0.1:9999/api/v1/docs</a>:
|
||||
|
||||
<img src="/img/tutorial/behind-a-proxy/image02.png">
|
||||
|
||||
Right as we wanted it. ✔️
|
||||
|
||||
This is because FastAPI uses this `root_path` to create the default `server` in OpenAPI with the URL provided by `root_path`.
|
||||
|
||||
## Additional servers { #additional-servers }
|
||||
|
||||
/// warning
|
||||
|
||||
This is a more advanced use case. Feel free to skip it.
|
||||
|
||||
///
|
||||
|
||||
By default, **FastAPI** will create a `server` in the OpenAPI schema with the URL for the `root_path`.
|
||||
|
||||
But you can also provide other alternative `servers`, for example if you want *the same* docs UI to interact with both a staging and a production environment.
|
||||
|
||||
If you pass a custom list of `servers` and there's a `root_path` (because your API lives behind a proxy), **FastAPI** will insert a "server" with this `root_path` at the beginning of the list.
|
||||
|
||||
For example:
|
||||
|
||||
{* ../../docs_src/behind_a_proxy/tutorial003.py hl[4:7] *}
|
||||
|
||||
Will generate an OpenAPI schema like:
|
||||
|
||||
```JSON hl_lines="5-7"
|
||||
{
|
||||
"openapi": "3.1.0",
|
||||
// More stuff here
|
||||
"servers": [
|
||||
{
|
||||
"url": "/api/v1"
|
||||
},
|
||||
{
|
||||
"url": "https://stag.example.com",
|
||||
"description": "Staging environment"
|
||||
},
|
||||
{
|
||||
"url": "https://prod.example.com",
|
||||
"description": "Production environment"
|
||||
}
|
||||
],
|
||||
"paths": {
|
||||
// More stuff here
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
/// tip
|
||||
|
||||
Notice the auto-generated server with a `url` value of `/api/v1`, taken from the `root_path`.
|
||||
|
||||
///
|
||||
|
||||
In the docs UI at <a href="http://127.0.0.1:9999/api/v1/docs" class="external-link" target="_blank">http://127.0.0.1:9999/api/v1/docs</a> it would look like:
|
||||
|
||||
<img src="/img/tutorial/behind-a-proxy/image03.png">
|
||||
|
||||
/// tip
|
||||
|
||||
The docs UI will interact with the server that you select.
|
||||
|
||||
///
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
The `servers` property in the OpenAPI specification is optional.
|
||||
|
||||
If you don't specify the `servers` parameter and `root_path` is equal to `/`, the `servers` property in the generated OpenAPI schema will be omitted entirely by default, which is the equivalent of a single server with a `url` value of `/`.
|
||||
|
||||
///
|
||||
|
||||
### Disable automatic server from `root_path` { #disable-automatic-server-from-root-path }
|
||||
|
||||
If you don't want **FastAPI** to include an automatic server using the `root_path`, you can use the parameter `root_path_in_servers=False`:
|
||||
|
||||
{* ../../docs_src/behind_a_proxy/tutorial004.py hl[9] *}
|
||||
|
||||
and then it won't include it in the OpenAPI schema.
|
||||
|
||||
## Mounting a sub-application { #mounting-a-sub-application }
|
||||
|
||||
If you need to mount a sub-application (as described in [Sub Applications - Mounts](sub-applications.md){.internal-link target=_blank}) while also using a proxy with `root_path`, you can do it normally, as you would expect.
|
||||
|
||||
FastAPI will internally use the `root_path` smartly, so it will just work. ✨
|
||||
@@ -0,0 +1,313 @@
|
||||
# Custom Response - HTML, Stream, File, others { #custom-response-html-stream-file-others }
|
||||
|
||||
By default, **FastAPI** will return the responses using `JSONResponse`.
|
||||
|
||||
You can override it by returning a `Response` directly as seen in [Return a Response directly](response-directly.md){.internal-link target=_blank}.
|
||||
|
||||
But if you return a `Response` directly (or any subclass, like `JSONResponse`), the data won't be automatically converted (even if you declare a `response_model`), and the documentation won't be automatically generated (for example, including the specific "media type", in the HTTP header `Content-Type` as part of the generated OpenAPI).
|
||||
|
||||
But you can also declare the `Response` that you want to be used (e.g. any `Response` subclass), in the *path operation decorator* using the `response_class` parameter.
|
||||
|
||||
The contents that you return from your *path operation function* will be put inside of that `Response`.
|
||||
|
||||
And if that `Response` has a JSON media type (`application/json`), like is the case with the `JSONResponse` and `UJSONResponse`, the data you return will be automatically converted (and filtered) with any Pydantic `response_model` that you declared in the *path operation decorator*.
|
||||
|
||||
/// note
|
||||
|
||||
If you use a response class with no media type, FastAPI will expect your response to have no content, so it will not document the response format in its generated OpenAPI docs.
|
||||
|
||||
///
|
||||
|
||||
## Use `ORJSONResponse` { #use-orjsonresponse }
|
||||
|
||||
For example, if you are squeezing performance, you can install and use <a href="https://github.com/ijl/orjson" class="external-link" target="_blank">`orjson`</a> and set the response to be `ORJSONResponse`.
|
||||
|
||||
Import the `Response` class (sub-class) you want to use and declare it in the *path operation decorator*.
|
||||
|
||||
For large responses, returning a `Response` directly is much faster than returning a dictionary.
|
||||
|
||||
This is because by default, FastAPI will inspect every item inside and make sure it is serializable as JSON, using the same [JSON Compatible Encoder](../tutorial/encoder.md){.internal-link target=_blank} explained in the tutorial. This is what allows you to return **arbitrary objects**, for example database models.
|
||||
|
||||
But if you are certain that the content that you are returning is **serializable with JSON**, you can pass it directly to the response class and avoid the extra overhead that FastAPI would have by passing your return content through the `jsonable_encoder` before passing it to the response class.
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial001b.py hl[2,7] *}
|
||||
|
||||
/// info
|
||||
|
||||
The parameter `response_class` will also be used to define the "media type" of the response.
|
||||
|
||||
In this case, the HTTP header `Content-Type` will be set to `application/json`.
|
||||
|
||||
And it will be documented as such in OpenAPI.
|
||||
|
||||
///
|
||||
|
||||
/// tip
|
||||
|
||||
The `ORJSONResponse` is only available in FastAPI, not in Starlette.
|
||||
|
||||
///
|
||||
|
||||
## HTML Response { #html-response }
|
||||
|
||||
To return a response with HTML directly from **FastAPI**, use `HTMLResponse`.
|
||||
|
||||
* Import `HTMLResponse`.
|
||||
* Pass `HTMLResponse` as the parameter `response_class` of your *path operation decorator*.
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial002.py hl[2,7] *}
|
||||
|
||||
/// info
|
||||
|
||||
The parameter `response_class` will also be used to define the "media type" of the response.
|
||||
|
||||
In this case, the HTTP header `Content-Type` will be set to `text/html`.
|
||||
|
||||
And it will be documented as such in OpenAPI.
|
||||
|
||||
///
|
||||
|
||||
### Return a `Response` { #return-a-response }
|
||||
|
||||
As seen in [Return a Response directly](response-directly.md){.internal-link target=_blank}, you can also override the response directly in your *path operation*, by returning it.
|
||||
|
||||
The same example from above, returning an `HTMLResponse`, could look like:
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial003.py hl[2,7,19] *}
|
||||
|
||||
/// warning
|
||||
|
||||
A `Response` returned directly by your *path operation function* won't be documented in OpenAPI (for example, the `Content-Type` won't be documented) and won't be visible in the automatic interactive docs.
|
||||
|
||||
///
|
||||
|
||||
/// info
|
||||
|
||||
Of course, the actual `Content-Type` header, status code, etc, will come from the `Response` object you returned.
|
||||
|
||||
///
|
||||
|
||||
### Document in OpenAPI and override `Response` { #document-in-openapi-and-override-response }
|
||||
|
||||
If you want to override the response from inside of the function but at the same time document the "media type" in OpenAPI, you can use the `response_class` parameter AND return a `Response` object.
|
||||
|
||||
The `response_class` will then be used only to document the OpenAPI *path operation*, but your `Response` will be used as is.
|
||||
|
||||
#### Return an `HTMLResponse` directly { #return-an-htmlresponse-directly }
|
||||
|
||||
For example, it could be something like:
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial004.py hl[7,21,23] *}
|
||||
|
||||
In this example, the function `generate_html_response()` already generates and returns a `Response` instead of returning the HTML in a `str`.
|
||||
|
||||
By returning the result of calling `generate_html_response()`, you are already returning a `Response` that will override the default **FastAPI** behavior.
|
||||
|
||||
But as you passed the `HTMLResponse` in the `response_class` too, **FastAPI** will know how to document it in OpenAPI and the interactive docs as HTML with `text/html`:
|
||||
|
||||
<img src="/img/tutorial/custom-response/image01.png">
|
||||
|
||||
## Available responses { #available-responses }
|
||||
|
||||
Here are some of the available responses.
|
||||
|
||||
Keep in mind that you can use `Response` to return anything else, or even create a custom sub-class.
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
You could also use `from starlette.responses import HTMLResponse`.
|
||||
|
||||
**FastAPI** provides the same `starlette.responses` as `fastapi.responses` just as a convenience for you, the developer. But most of the available responses come directly from Starlette.
|
||||
|
||||
///
|
||||
|
||||
### `Response` { #response }
|
||||
|
||||
The main `Response` class, all the other responses inherit from it.
|
||||
|
||||
You can return it directly.
|
||||
|
||||
It accepts the following parameters:
|
||||
|
||||
* `content` - A `str` or `bytes`.
|
||||
* `status_code` - An `int` HTTP status code.
|
||||
* `headers` - A `dict` of strings.
|
||||
* `media_type` - A `str` giving the media type. E.g. `"text/html"`.
|
||||
|
||||
FastAPI (actually Starlette) will automatically include a Content-Length header. It will also include a Content-Type header, based on the `media_type` and appending a charset for text types.
|
||||
|
||||
{* ../../docs_src/response_directly/tutorial002.py hl[1,18] *}
|
||||
|
||||
### `HTMLResponse` { #htmlresponse }
|
||||
|
||||
Takes some text or bytes and returns an HTML response, as you read above.
|
||||
|
||||
### `PlainTextResponse` { #plaintextresponse }
|
||||
|
||||
Takes some text or bytes and returns a plain text response.
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial005.py hl[2,7,9] *}
|
||||
|
||||
### `JSONResponse` { #jsonresponse }
|
||||
|
||||
Takes some data and returns an `application/json` encoded response.
|
||||
|
||||
This is the default response used in **FastAPI**, as you read above.
|
||||
|
||||
### `ORJSONResponse` { #orjsonresponse }
|
||||
|
||||
A fast alternative JSON response using <a href="https://github.com/ijl/orjson" class="external-link" target="_blank">`orjson`</a>, as you read above.
|
||||
|
||||
/// info
|
||||
|
||||
This requires installing `orjson` for example with `pip install orjson`.
|
||||
|
||||
///
|
||||
|
||||
### `UJSONResponse` { #ujsonresponse }
|
||||
|
||||
An alternative JSON response using <a href="https://github.com/ultrajson/ultrajson" class="external-link" target="_blank">`ujson`</a>.
|
||||
|
||||
/// info
|
||||
|
||||
This requires installing `ujson` for example with `pip install ujson`.
|
||||
|
||||
///
|
||||
|
||||
/// warning
|
||||
|
||||
`ujson` is less careful than Python's built-in implementation in how it handles some edge-cases.
|
||||
|
||||
///
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial001.py hl[2,7] *}
|
||||
|
||||
/// tip
|
||||
|
||||
It's possible that `ORJSONResponse` might be a faster alternative.
|
||||
|
||||
///
|
||||
|
||||
### `RedirectResponse` { #redirectresponse }
|
||||
|
||||
Returns an HTTP redirect. Uses a 307 status code (Temporary Redirect) by default.
|
||||
|
||||
You can return a `RedirectResponse` directly:
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial006.py hl[2,9] *}
|
||||
|
||||
---
|
||||
|
||||
Or you can use it in the `response_class` parameter:
|
||||
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial006b.py hl[2,7,9] *}
|
||||
|
||||
If you do that, then you can return the URL directly from your *path operation* function.
|
||||
|
||||
In this case, the `status_code` used will be the default one for the `RedirectResponse`, which is `307`.
|
||||
|
||||
---
|
||||
|
||||
You can also use the `status_code` parameter combined with the `response_class` parameter:
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial006c.py hl[2,7,9] *}
|
||||
|
||||
### `StreamingResponse` { #streamingresponse }
|
||||
|
||||
Takes an async generator or a normal generator/iterator and streams the response body.
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial007.py hl[2,14] *}
|
||||
|
||||
#### Using `StreamingResponse` with file-like objects { #using-streamingresponse-with-file-like-objects }
|
||||
|
||||
If you have a <a href="https://docs.python.org/3/glossary.html#term-file-like-object" class="external-link" target="_blank">file-like</a> object (e.g. the object returned by `open()`), you can create a generator function to iterate over that file-like object.
|
||||
|
||||
That way, you don't have to read it all first in memory, and you can pass that generator function to the `StreamingResponse`, and return it.
|
||||
|
||||
This includes many libraries to interact with cloud storage, video processing, and others.
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial008.py hl[2,10:12,14] *}
|
||||
|
||||
1. This is the generator function. It's a "generator function" because it contains `yield` statements inside.
|
||||
2. By using a `with` block, we make sure that the file-like object is closed after the generator function is done. So, after it finishes sending the response.
|
||||
3. This `yield from` tells the function to iterate over that thing named `file_like`. And then, for each part iterated, yield that part as coming from this generator function (`iterfile`).
|
||||
|
||||
So, it is a generator function that transfers the "generating" work to something else internally.
|
||||
|
||||
By doing it this way, we can put it in a `with` block, and that way, ensure that the file-like object is closed after finishing.
|
||||
|
||||
/// tip
|
||||
|
||||
Notice that here as we are using standard `open()` that doesn't support `async` and `await`, we declare the path operation with normal `def`.
|
||||
|
||||
///
|
||||
|
||||
### `FileResponse` { #fileresponse }
|
||||
|
||||
Asynchronously streams a file as the response.
|
||||
|
||||
Takes a different set of arguments to instantiate than the other response types:
|
||||
|
||||
* `path` - The file path to the file to stream.
|
||||
* `headers` - Any custom headers to include, as a dictionary.
|
||||
* `media_type` - A string giving the media type. If unset, the filename or path will be used to infer a media type.
|
||||
* `filename` - If set, this will be included in the response `Content-Disposition`.
|
||||
|
||||
File responses will include appropriate `Content-Length`, `Last-Modified` and `ETag` headers.
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial009.py hl[2,10] *}
|
||||
|
||||
You can also use the `response_class` parameter:
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial009b.py hl[2,8,10] *}
|
||||
|
||||
In this case, you can return the file path directly from your *path operation* function.
|
||||
|
||||
## Custom response class { #custom-response-class }
|
||||
|
||||
You can create your own custom response class, inheriting from `Response` and using it.
|
||||
|
||||
For example, let's say that you want to use <a href="https://github.com/ijl/orjson" class="external-link" target="_blank">`orjson`</a>, but with some custom settings not used in the included `ORJSONResponse` class.
|
||||
|
||||
Let's say you want it to return indented and formatted JSON, so you want to use the orjson option `orjson.OPT_INDENT_2`.
|
||||
|
||||
You could create a `CustomORJSONResponse`. The main thing you have to do is create a `Response.render(content)` method that returns the content as `bytes`:
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial009c.py hl[9:14,17] *}
|
||||
|
||||
Now instead of returning:
|
||||
|
||||
```json
|
||||
{"message": "Hello World"}
|
||||
```
|
||||
|
||||
...this response will return:
|
||||
|
||||
```json
|
||||
{
|
||||
"message": "Hello World"
|
||||
}
|
||||
```
|
||||
|
||||
Of course, you will probably find much better ways to take advantage of this than formatting JSON. 😉
|
||||
|
||||
## Default response class { #default-response-class }
|
||||
|
||||
When creating a **FastAPI** class instance or an `APIRouter` you can specify which response class to use by default.
|
||||
|
||||
The parameter that defines this is `default_response_class`.
|
||||
|
||||
In the example below, **FastAPI** will use `ORJSONResponse` by default, in all *path operations*, instead of `JSONResponse`.
|
||||
|
||||
{* ../../docs_src/custom_response/tutorial010.py hl[2,4] *}
|
||||
|
||||
/// tip
|
||||
|
||||
You can still override `response_class` in *path operations* as before.
|
||||
|
||||
///
|
||||
|
||||
## Additional documentation { #additional-documentation }
|
||||
|
||||
You can also declare the media type and many other details in OpenAPI using `responses`: [Additional Responses in OpenAPI](additional-responses.md){.internal-link target=_blank}.
|
||||
@@ -0,0 +1,95 @@
|
||||
# Using Dataclasses { #using-dataclasses }
|
||||
|
||||
FastAPI is built on top of **Pydantic**, and I have been showing you how to use Pydantic models to declare requests and responses.
|
||||
|
||||
But FastAPI also supports using <a href="https://docs.python.org/3/library/dataclasses.html" class="external-link" target="_blank">`dataclasses`</a> the same way:
|
||||
|
||||
{* ../../docs_src/dataclasses/tutorial001.py hl[1,7:12,19:20] *}
|
||||
|
||||
This is still supported thanks to **Pydantic**, as it has <a href="https://docs.pydantic.dev/latest/concepts/dataclasses/#use-of-stdlib-dataclasses-with-basemodel" class="external-link" target="_blank">internal support for `dataclasses`</a>.
|
||||
|
||||
So, even with the code above that doesn't use Pydantic explicitly, FastAPI is using Pydantic to convert those standard dataclasses to Pydantic's own flavor of dataclasses.
|
||||
|
||||
And of course, it supports the same:
|
||||
|
||||
* data validation
|
||||
* data serialization
|
||||
* data documentation, etc.
|
||||
|
||||
This works the same way as with Pydantic models. And it is actually achieved in the same way underneath, using Pydantic.
|
||||
|
||||
/// info
|
||||
|
||||
Keep in mind that dataclasses can't do everything Pydantic models can do.
|
||||
|
||||
So, you might still need to use Pydantic models.
|
||||
|
||||
But if you have a bunch of dataclasses laying around, this is a nice trick to use them to power a web API using FastAPI. 🤓
|
||||
|
||||
///
|
||||
|
||||
## Dataclasses in `response_model` { #dataclasses-in-response-model }
|
||||
|
||||
You can also use `dataclasses` in the `response_model` parameter:
|
||||
|
||||
{* ../../docs_src/dataclasses/tutorial002.py hl[1,7:13,19] *}
|
||||
|
||||
The dataclass will be automatically converted to a Pydantic dataclass.
|
||||
|
||||
This way, its schema will show up in the API docs user interface:
|
||||
|
||||
<img src="/img/tutorial/dataclasses/image01.png">
|
||||
|
||||
## Dataclasses in Nested Data Structures { #dataclasses-in-nested-data-structures }
|
||||
|
||||
You can also combine `dataclasses` with other type annotations to make nested data structures.
|
||||
|
||||
In some cases, you might still have to use Pydantic's version of `dataclasses`. For example, if you have errors with the automatically generated API documentation.
|
||||
|
||||
In that case, you can simply swap the standard `dataclasses` with `pydantic.dataclasses`, which is a drop-in replacement:
|
||||
|
||||
{* ../../docs_src/dataclasses/tutorial003.py hl[1,5,8:11,14:17,23:25,28] *}
|
||||
|
||||
1. We still import `field` from standard `dataclasses`.
|
||||
|
||||
2. `pydantic.dataclasses` is a drop-in replacement for `dataclasses`.
|
||||
|
||||
3. The `Author` dataclass includes a list of `Item` dataclasses.
|
||||
|
||||
4. The `Author` dataclass is used as the `response_model` parameter.
|
||||
|
||||
5. You can use other standard type annotations with dataclasses as the request body.
|
||||
|
||||
In this case, it's a list of `Item` dataclasses.
|
||||
|
||||
6. Here we are returning a dictionary that contains `items` which is a list of dataclasses.
|
||||
|
||||
FastAPI is still capable of <abbr title="converting the data to a format that can be transmitted">serializing</abbr> the data to JSON.
|
||||
|
||||
7. Here the `response_model` is using a type annotation of a list of `Author` dataclasses.
|
||||
|
||||
Again, you can combine `dataclasses` with standard type annotations.
|
||||
|
||||
8. Notice that this *path operation function* uses regular `def` instead of `async def`.
|
||||
|
||||
As always, in FastAPI you can combine `def` and `async def` as needed.
|
||||
|
||||
If you need a refresher about when to use which, check out the section _"In a hurry?"_ in the docs about [`async` and `await`](../async.md#in-a-hurry){.internal-link target=_blank}.
|
||||
|
||||
9. This *path operation function* is not returning dataclasses (although it could), but a list of dictionaries with internal data.
|
||||
|
||||
FastAPI will use the `response_model` parameter (that includes dataclasses) to convert the response.
|
||||
|
||||
You can combine `dataclasses` with other type annotations in many different combinations to form complex data structures.
|
||||
|
||||
Check the in-code annotation tips above to see more specific details.
|
||||
|
||||
## Learn More { #learn-more }
|
||||
|
||||
You can also combine `dataclasses` with other Pydantic models, inherit from them, include them in your own models, etc.
|
||||
|
||||
To learn more, check the <a href="https://docs.pydantic.dev/latest/concepts/dataclasses/" class="external-link" target="_blank">Pydantic docs about dataclasses</a>.
|
||||
|
||||
## Version { #version }
|
||||
|
||||
This is available since FastAPI version `0.67.0`. 🔖
|
||||
@@ -0,0 +1,165 @@
|
||||
# Lifespan Events { #lifespan-events }
|
||||
|
||||
You can define logic (code) that should be executed before the application **starts up**. This means that this code will be executed **once**, **before** the application **starts receiving requests**.
|
||||
|
||||
The same way, you can define logic (code) that should be executed when the application is **shutting down**. In this case, this code will be executed **once**, **after** having handled possibly **many requests**.
|
||||
|
||||
Because this code is executed before the application **starts** taking requests, and right after it **finishes** handling requests, it covers the whole application **lifespan** (the word "lifespan" will be important in a second 😉).
|
||||
|
||||
This can be very useful for setting up **resources** that you need to use for the whole app, and that are **shared** among requests, and/or that you need to **clean up** afterwards. For example, a database connection pool, or loading a shared machine learning model.
|
||||
|
||||
## Use Case { #use-case }
|
||||
|
||||
Let's start with an example **use case** and then see how to solve it with this.
|
||||
|
||||
Let's imagine that you have some **machine learning models** that you want to use to handle requests. 🤖
|
||||
|
||||
The same models are shared among requests, so, it's not one model per request, or one per user or something similar.
|
||||
|
||||
Let's imagine that loading the model can **take quite some time**, because it has to read a lot of **data from disk**. So you don't want to do it for every request.
|
||||
|
||||
You could load it at the top level of the module/file, but that would also mean that it would **load the model** even if you are just running a simple automated test, then that test would be **slow** because it would have to wait for the model to load before being able to run an independent part of the code.
|
||||
|
||||
That's what we'll solve, let's load the model before the requests are handled, but only right before the application starts receiving requests, not while the code is being loaded.
|
||||
|
||||
## Lifespan { #lifespan }
|
||||
|
||||
You can define this *startup* and *shutdown* logic using the `lifespan` parameter of the `FastAPI` app, and a "context manager" (I'll show you what that is in a second).
|
||||
|
||||
Let's start with an example and then see it in detail.
|
||||
|
||||
We create an async function `lifespan()` with `yield` like this:
|
||||
|
||||
{* ../../docs_src/events/tutorial003.py hl[16,19] *}
|
||||
|
||||
Here we are simulating the expensive *startup* operation of loading the model by putting the (fake) model function in the dictionary with machine learning models before the `yield`. This code will be executed **before** the application **starts taking requests**, during the *startup*.
|
||||
|
||||
And then, right after the `yield`, we unload the model. This code will be executed **after** the application **finishes handling requests**, right before the *shutdown*. This could, for example, release resources like memory or a GPU.
|
||||
|
||||
/// tip
|
||||
|
||||
The `shutdown` would happen when you are **stopping** the application.
|
||||
|
||||
Maybe you need to start a new version, or you just got tired of running it. 🤷
|
||||
|
||||
///
|
||||
|
||||
### Lifespan function { #lifespan-function }
|
||||
|
||||
The first thing to notice, is that we are defining an async function with `yield`. This is very similar to Dependencies with `yield`.
|
||||
|
||||
{* ../../docs_src/events/tutorial003.py hl[14:19] *}
|
||||
|
||||
The first part of the function, before the `yield`, will be executed **before** the application starts.
|
||||
|
||||
And the part after the `yield` will be executed **after** the application has finished.
|
||||
|
||||
### Async Context Manager { #async-context-manager }
|
||||
|
||||
If you check, the function is decorated with an `@asynccontextmanager`.
|
||||
|
||||
That converts the function into something called an "**async context manager**".
|
||||
|
||||
{* ../../docs_src/events/tutorial003.py hl[1,13] *}
|
||||
|
||||
A **context manager** in Python is something that you can use in a `with` statement, for example, `open()` can be used as a context manager:
|
||||
|
||||
```Python
|
||||
with open("file.txt") as file:
|
||||
file.read()
|
||||
```
|
||||
|
||||
In recent versions of Python, there's also an **async context manager**. You would use it with `async with`:
|
||||
|
||||
```Python
|
||||
async with lifespan(app):
|
||||
await do_stuff()
|
||||
```
|
||||
|
||||
When you create a context manager or an async context manager like above, what it does is that, before entering the `with` block, it will execute the code before the `yield`, and after exiting the `with` block, it will execute the code after the `yield`.
|
||||
|
||||
In our code example above, we don't use it directly, but we pass it to FastAPI for it to use it.
|
||||
|
||||
The `lifespan` parameter of the `FastAPI` app takes an **async context manager**, so we can pass our new `lifespan` async context manager to it.
|
||||
|
||||
{* ../../docs_src/events/tutorial003.py hl[22] *}
|
||||
|
||||
## Alternative Events (deprecated) { #alternative-events-deprecated }
|
||||
|
||||
/// warning
|
||||
|
||||
The recommended way to handle the *startup* and *shutdown* is using the `lifespan` parameter of the `FastAPI` app as described above. If you provide a `lifespan` parameter, `startup` and `shutdown` event handlers will no longer be called. It's all `lifespan` or all events, not both.
|
||||
|
||||
You can probably skip this part.
|
||||
|
||||
///
|
||||
|
||||
There's an alternative way to define this logic to be executed during *startup* and during *shutdown*.
|
||||
|
||||
You can define event handlers (functions) that need to be executed before the application starts up, or when the application is shutting down.
|
||||
|
||||
These functions can be declared with `async def` or normal `def`.
|
||||
|
||||
### `startup` event { #startup-event }
|
||||
|
||||
To add a function that should be run before the application starts, declare it with the event `"startup"`:
|
||||
|
||||
{* ../../docs_src/events/tutorial001.py hl[8] *}
|
||||
|
||||
In this case, the `startup` event handler function will initialize the items "database" (just a `dict`) with some values.
|
||||
|
||||
You can add more than one event handler function.
|
||||
|
||||
And your application won't start receiving requests until all the `startup` event handlers have completed.
|
||||
|
||||
### `shutdown` event { #shutdown-event }
|
||||
|
||||
To add a function that should be run when the application is shutting down, declare it with the event `"shutdown"`:
|
||||
|
||||
{* ../../docs_src/events/tutorial002.py hl[6] *}
|
||||
|
||||
Here, the `shutdown` event handler function will write a text line `"Application shutdown"` to a file `log.txt`.
|
||||
|
||||
/// info
|
||||
|
||||
In the `open()` function, the `mode="a"` means "append", so, the line will be added after whatever is on that file, without overwriting the previous contents.
|
||||
|
||||
///
|
||||
|
||||
/// tip
|
||||
|
||||
Notice that in this case we are using a standard Python `open()` function that interacts with a file.
|
||||
|
||||
So, it involves I/O (input/output), that requires "waiting" for things to be written to disk.
|
||||
|
||||
But `open()` doesn't use `async` and `await`.
|
||||
|
||||
So, we declare the event handler function with standard `def` instead of `async def`.
|
||||
|
||||
///
|
||||
|
||||
### `startup` and `shutdown` together { #startup-and-shutdown-together }
|
||||
|
||||
There's a high chance that the logic for your *startup* and *shutdown* is connected, you might want to start something and then finish it, acquire a resource and then release it, etc.
|
||||
|
||||
Doing that in separated functions that don't share logic or variables together is more difficult as you would need to store values in global variables or similar tricks.
|
||||
|
||||
Because of that, it's now recommended to instead use the `lifespan` as explained above.
|
||||
|
||||
## Technical Details { #technical-details }
|
||||
|
||||
Just a technical detail for the curious nerds. 🤓
|
||||
|
||||
Underneath, in the ASGI technical specification, this is part of the <a href="https://asgi.readthedocs.io/en/latest/specs/lifespan.html" class="external-link" target="_blank">Lifespan Protocol</a>, and it defines events called `startup` and `shutdown`.
|
||||
|
||||
/// info
|
||||
|
||||
You can read more about the Starlette `lifespan` handlers in <a href="https://www.starlette.dev/lifespan/" class="external-link" target="_blank">Starlette's Lifespan' docs</a>.
|
||||
|
||||
Including how to handle lifespan state that can be used in other areas of your code.
|
||||
|
||||
///
|
||||
|
||||
## Sub Applications { #sub-applications }
|
||||
|
||||
🚨 Keep in mind that these lifespan events (startup and shutdown) will only be executed for the main application, not for [Sub Applications - Mounts](sub-applications.md){.internal-link target=_blank}.
|
||||
@@ -0,0 +1,208 @@
|
||||
# Generating SDKs { #generating-sdks }
|
||||
|
||||
Because **FastAPI** is based on the **OpenAPI** specification, its APIs can be described in a standard format that many tools understand.
|
||||
|
||||
This makes it easy to generate up-to-date **documentation**, client libraries (<abbr title="Software Development Kits">**SDKs**</abbr>) in multiple languages, and **testing** or **automation workflows** that stay in sync with your code.
|
||||
|
||||
In this guide, you'll learn how to generate a **TypeScript SDK** for your FastAPI backend.
|
||||
|
||||
## Open Source SDK Generators { #open-source-sdk-generators }
|
||||
|
||||
A versatile option is the <a href="https://openapi-generator.tech/" class="external-link" target="_blank">OpenAPI Generator</a>, which supports **many programming languages** and can generate SDKs from your OpenAPI specification.
|
||||
|
||||
For **TypeScript clients**, <a href="https://heyapi.dev/" class="external-link" target="_blank">Hey API</a> is a purpose-built solution, providing an optimized experience for the TypeScript ecosystem.
|
||||
|
||||
You can discover more SDK generators on <a href="https://openapi.tools/#sdk" class="external-link" target="_blank">OpenAPI.Tools</a>.
|
||||
|
||||
/// tip
|
||||
|
||||
FastAPI automatically generates **OpenAPI 3.1** specifications, so any tool you use must support this version.
|
||||
|
||||
///
|
||||
|
||||
## SDK Generators from FastAPI Sponsors { #sdk-generators-from-fastapi-sponsors }
|
||||
|
||||
This section highlights **venture-backed** and **company-supported** solutions from companies that sponsor FastAPI. These products provide **additional features** and **integrations** on top of high-quality generated SDKs.
|
||||
|
||||
By ✨ [**sponsoring FastAPI**](../help-fastapi.md#sponsor-the-author){.internal-link target=_blank} ✨, these companies help ensure the framework and its **ecosystem** remain healthy and **sustainable**.
|
||||
|
||||
Their sponsorship also demonstrates a strong commitment to the FastAPI **community** (you), showing that they care not only about offering a **great service** but also about supporting a **robust and thriving framework**, FastAPI. 🙇
|
||||
|
||||
For example, you might want to try:
|
||||
|
||||
* <a href="https://speakeasy.com/editor?utm_source=fastapi+repo&utm_medium=github+sponsorship" class="external-link" target="_blank">Speakeasy</a>
|
||||
* <a href="https://www.stainless.com/?utm_source=fastapi&utm_medium=referral" class="external-link" target="_blank">Stainless</a>
|
||||
* <a href="https://developers.liblab.com/tutorials/sdk-for-fastapi?utm_source=fastapi" class="external-link" target="_blank">liblab</a>
|
||||
|
||||
Some of these solutions may also be open source or offer free tiers, so you can try them without a financial commitment. Other commercial SDK generators are available and can be found online. 🤓
|
||||
|
||||
## Create a TypeScript SDK { #create-a-typescript-sdk }
|
||||
|
||||
Let's start with a simple FastAPI application:
|
||||
|
||||
{* ../../docs_src/generate_clients/tutorial001_py39.py hl[7:9,12:13,16:17,21] *}
|
||||
|
||||
Notice that the *path operations* define the models they use for request payload and response payload, using the models `Item` and `ResponseMessage`.
|
||||
|
||||
### API Docs { #api-docs }
|
||||
|
||||
If you go to `/docs`, you will see that it has the **schemas** for the data to be sent in requests and received in responses:
|
||||
|
||||
<img src="/img/tutorial/generate-clients/image01.png">
|
||||
|
||||
You can see those schemas because they were declared with the models in the app.
|
||||
|
||||
That information is available in the app's **OpenAPI schema**, and then shown in the API docs.
|
||||
|
||||
That same information from the models that is included in OpenAPI is what can be used to **generate the client code**.
|
||||
|
||||
### Hey API { #hey-api }
|
||||
|
||||
Once we have a FastAPI app with the models, we can use Hey API to generate a TypeScript client. The fastest way to do that is via npx.
|
||||
|
||||
```sh
|
||||
npx @hey-api/openapi-ts -i http://localhost:8000/openapi.json -o src/client
|
||||
```
|
||||
|
||||
This will generate a TypeScript SDK in `./src/client`.
|
||||
|
||||
You can learn how to <a href="https://heyapi.dev/openapi-ts/get-started" class="external-link" target="_blank">install `@hey-api/openapi-ts`</a> and read about the <a href="https://heyapi.dev/openapi-ts/output" class="external-link" target="_blank">generated output</a> on their website.
|
||||
|
||||
### Using the SDK { #using-the-sdk }
|
||||
|
||||
Now you can import and use the client code. It could look like this, notice that you get autocompletion for the methods:
|
||||
|
||||
<img src="/img/tutorial/generate-clients/image02.png">
|
||||
|
||||
You will also get autocompletion for the payload to send:
|
||||
|
||||
<img src="/img/tutorial/generate-clients/image03.png">
|
||||
|
||||
/// tip
|
||||
|
||||
Notice the autocompletion for `name` and `price`, that was defined in the FastAPI application, in the `Item` model.
|
||||
|
||||
///
|
||||
|
||||
You will have inline errors for the data that you send:
|
||||
|
||||
<img src="/img/tutorial/generate-clients/image04.png">
|
||||
|
||||
The response object will also have autocompletion:
|
||||
|
||||
<img src="/img/tutorial/generate-clients/image05.png">
|
||||
|
||||
## FastAPI App with Tags { #fastapi-app-with-tags }
|
||||
|
||||
In many cases, your FastAPI app will be bigger, and you will probably use tags to separate different groups of *path operations*.
|
||||
|
||||
For example, you could have a section for **items** and another section for **users**, and they could be separated by tags:
|
||||
|
||||
{* ../../docs_src/generate_clients/tutorial002_py39.py hl[21,26,34] *}
|
||||
|
||||
### Generate a TypeScript Client with Tags { #generate-a-typescript-client-with-tags }
|
||||
|
||||
If you generate a client for a FastAPI app using tags, it will normally also separate the client code based on the tags.
|
||||
|
||||
This way, you will be able to have things ordered and grouped correctly for the client code:
|
||||
|
||||
<img src="/img/tutorial/generate-clients/image06.png">
|
||||
|
||||
In this case, you have:
|
||||
|
||||
* `ItemsService`
|
||||
* `UsersService`
|
||||
|
||||
### Client Method Names { #client-method-names }
|
||||
|
||||
Right now, the generated method names like `createItemItemsPost` don't look very clean:
|
||||
|
||||
```TypeScript
|
||||
ItemsService.createItemItemsPost({name: "Plumbus", price: 5})
|
||||
```
|
||||
|
||||
...that's because the client generator uses the OpenAPI internal **operation ID** for each *path operation*.
|
||||
|
||||
OpenAPI requires that each operation ID is unique across all the *path operations*, so FastAPI uses the **function name**, the **path**, and the **HTTP method/operation** to generate that operation ID, because that way it can make sure that the operation IDs are unique.
|
||||
|
||||
But I'll show you how to improve that next. 🤓
|
||||
|
||||
## Custom Operation IDs and Better Method Names { #custom-operation-ids-and-better-method-names }
|
||||
|
||||
You can **modify** the way these operation IDs are **generated** to make them simpler and have **simpler method names** in the clients.
|
||||
|
||||
In this case, you will have to ensure that each operation ID is **unique** in some other way.
|
||||
|
||||
For example, you could make sure that each *path operation* has a tag, and then generate the operation ID based on the **tag** and the *path operation* **name** (the function name).
|
||||
|
||||
### Custom Generate Unique ID Function { #custom-generate-unique-id-function }
|
||||
|
||||
FastAPI uses a **unique ID** for each *path operation*, which is used for the **operation ID** and also for the names of any needed custom models, for requests or responses.
|
||||
|
||||
You can customize that function. It takes an `APIRoute` and outputs a string.
|
||||
|
||||
For example, here it is using the first tag (you will probably have only one tag) and the *path operation* name (the function name).
|
||||
|
||||
You can then pass that custom function to **FastAPI** as the `generate_unique_id_function` parameter:
|
||||
|
||||
{* ../../docs_src/generate_clients/tutorial003_py39.py hl[6:7,10] *}
|
||||
|
||||
### Generate a TypeScript Client with Custom Operation IDs { #generate-a-typescript-client-with-custom-operation-ids }
|
||||
|
||||
Now, if you generate the client again, you will see that it has the improved method names:
|
||||
|
||||
<img src="/img/tutorial/generate-clients/image07.png">
|
||||
|
||||
As you see, the method names now have the tag and then the function name, now they don't include information from the URL path and the HTTP operation.
|
||||
|
||||
### Preprocess the OpenAPI Specification for the Client Generator { #preprocess-the-openapi-specification-for-the-client-generator }
|
||||
|
||||
The generated code still has some **duplicated information**.
|
||||
|
||||
We already know that this method is related to the **items** because that word is in the `ItemsService` (taken from the tag), but we still have the tag name prefixed in the method name too. 😕
|
||||
|
||||
We will probably still want to keep it for OpenAPI in general, as that will ensure that the operation IDs are **unique**.
|
||||
|
||||
But for the generated client, we could **modify** the OpenAPI operation IDs right before generating the clients, just to make those method names nicer and **cleaner**.
|
||||
|
||||
We could download the OpenAPI JSON to a file `openapi.json` and then we could **remove that prefixed tag** with a script like this:
|
||||
|
||||
{* ../../docs_src/generate_clients/tutorial004.py *}
|
||||
|
||||
//// tab | Node.js
|
||||
|
||||
```Javascript
|
||||
{!> ../../docs_src/generate_clients/tutorial004.js!}
|
||||
```
|
||||
|
||||
////
|
||||
|
||||
With that, the operation IDs would be renamed from things like `items-get_items` to just `get_items`, that way the client generator can generate simpler method names.
|
||||
|
||||
### Generate a TypeScript Client with the Preprocessed OpenAPI { #generate-a-typescript-client-with-the-preprocessed-openapi }
|
||||
|
||||
Since the end result is now in an `openapi.json` file, you need to update your input location:
|
||||
|
||||
```sh
|
||||
npx @hey-api/openapi-ts -i ./openapi.json -o src/client
|
||||
```
|
||||
|
||||
After generating the new client, you would now have **clean method names**, with all the **autocompletion**, **inline errors**, etc:
|
||||
|
||||
<img src="/img/tutorial/generate-clients/image08.png">
|
||||
|
||||
## Benefits { #benefits }
|
||||
|
||||
When using the automatically generated clients, you would get **autocompletion** for:
|
||||
|
||||
* Methods.
|
||||
* Request payloads in the body, query parameters, etc.
|
||||
* Response payloads.
|
||||
|
||||
You would also have **inline errors** for everything.
|
||||
|
||||
And whenever you update the backend code, and **regenerate** the frontend, it would have any new *path operations* available as methods, the old ones removed, and any other change would be reflected on the generated code. 🤓
|
||||
|
||||
This also means that if something changed, it will be **reflected** on the client code automatically. And if you **build** the client, it will error out if you have any **mismatch** in the data used.
|
||||
|
||||
So, you would **detect many errors** very early in the development cycle instead of having to wait for the errors to show up to your final users in production and then trying to debug where the problem is. ✨
|
||||
@@ -0,0 +1,21 @@
|
||||
# Advanced User Guide { #advanced-user-guide }
|
||||
|
||||
## Additional Features { #additional-features }
|
||||
|
||||
The main [Tutorial - User Guide](../tutorial/index.md){.internal-link target=_blank} should be enough to give you a tour through all the main features of **FastAPI**.
|
||||
|
||||
In the next sections you will see other options, configurations, and additional features.
|
||||
|
||||
/// tip
|
||||
|
||||
The next sections are **not necessarily "advanced"**.
|
||||
|
||||
And it's possible that for your use case, the solution is in one of them.
|
||||
|
||||
///
|
||||
|
||||
## Read the Tutorial first { #read-the-tutorial-first }
|
||||
|
||||
You could still use most of the features in **FastAPI** with the knowledge from the main [Tutorial - User Guide](../tutorial/index.md){.internal-link target=_blank}.
|
||||
|
||||
And the next sections assume you already read it, and assume that you know those main ideas.
|
||||
@@ -0,0 +1,97 @@
|
||||
# Advanced Middleware { #advanced-middleware }
|
||||
|
||||
In the main tutorial you read how to add [Custom Middleware](../tutorial/middleware.md){.internal-link target=_blank} to your application.
|
||||
|
||||
And then you also read how to handle [CORS with the `CORSMiddleware`](../tutorial/cors.md){.internal-link target=_blank}.
|
||||
|
||||
In this section we'll see how to use other middlewares.
|
||||
|
||||
## Adding ASGI middlewares { #adding-asgi-middlewares }
|
||||
|
||||
As **FastAPI** is based on Starlette and implements the <abbr title="Asynchronous Server Gateway Interface">ASGI</abbr> specification, you can use any ASGI middleware.
|
||||
|
||||
A middleware doesn't have to be made for FastAPI or Starlette to work, as long as it follows the ASGI spec.
|
||||
|
||||
In general, ASGI middlewares are classes that expect to receive an ASGI app as the first argument.
|
||||
|
||||
So, in the documentation for third-party ASGI middlewares they will probably tell you to do something like:
|
||||
|
||||
```Python
|
||||
from unicorn import UnicornMiddleware
|
||||
|
||||
app = SomeASGIApp()
|
||||
|
||||
new_app = UnicornMiddleware(app, some_config="rainbow")
|
||||
```
|
||||
|
||||
But FastAPI (actually Starlette) provides a simpler way to do it that makes sure that the internal middlewares handle server errors and custom exception handlers work properly.
|
||||
|
||||
For that, you use `app.add_middleware()` (as in the example for CORS).
|
||||
|
||||
```Python
|
||||
from fastapi import FastAPI
|
||||
from unicorn import UnicornMiddleware
|
||||
|
||||
app = FastAPI()
|
||||
|
||||
app.add_middleware(UnicornMiddleware, some_config="rainbow")
|
||||
```
|
||||
|
||||
`app.add_middleware()` receives a middleware class as the first argument and any additional arguments to be passed to the middleware.
|
||||
|
||||
## Integrated middlewares { #integrated-middlewares }
|
||||
|
||||
**FastAPI** includes several middlewares for common use cases, we'll see next how to use them.
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
For the next examples, you could also use `from starlette.middleware.something import SomethingMiddleware`.
|
||||
|
||||
**FastAPI** provides several middlewares in `fastapi.middleware` just as a convenience for you, the developer. But most of the available middlewares come directly from Starlette.
|
||||
|
||||
///
|
||||
|
||||
## `HTTPSRedirectMiddleware` { #httpsredirectmiddleware }
|
||||
|
||||
Enforces that all incoming requests must either be `https` or `wss`.
|
||||
|
||||
Any incoming request to `http` or `ws` will be redirected to the secure scheme instead.
|
||||
|
||||
{* ../../docs_src/advanced_middleware/tutorial001.py hl[2,6] *}
|
||||
|
||||
## `TrustedHostMiddleware` { #trustedhostmiddleware }
|
||||
|
||||
Enforces that all incoming requests have a correctly set `Host` header, in order to guard against HTTP Host Header attacks.
|
||||
|
||||
{* ../../docs_src/advanced_middleware/tutorial002.py hl[2,6:8] *}
|
||||
|
||||
The following arguments are supported:
|
||||
|
||||
* `allowed_hosts` - A list of domain names that should be allowed as hostnames. Wildcard domains such as `*.example.com` are supported for matching subdomains. To allow any hostname either use `allowed_hosts=["*"]` or omit the middleware.
|
||||
* `www_redirect` - If set to True, requests to non-www versions of the allowed hosts will be redirected to their www counterparts. Defaults to `True`.
|
||||
|
||||
If an incoming request does not validate correctly then a `400` response will be sent.
|
||||
|
||||
## `GZipMiddleware` { #gzipmiddleware }
|
||||
|
||||
Handles GZip responses for any request that includes `"gzip"` in the `Accept-Encoding` header.
|
||||
|
||||
The middleware will handle both standard and streaming responses.
|
||||
|
||||
{* ../../docs_src/advanced_middleware/tutorial003.py hl[2,6] *}
|
||||
|
||||
The following arguments are supported:
|
||||
|
||||
* `minimum_size` - Do not GZip responses that are smaller than this minimum size in bytes. Defaults to `500`.
|
||||
* `compresslevel` - Used during GZip compression. It is an integer ranging from 1 to 9. Defaults to `9`. Lower value results in faster compression but larger file sizes, while higher value results in slower compression but smaller file sizes.
|
||||
|
||||
## Other middlewares { #other-middlewares }
|
||||
|
||||
There are many other ASGI middlewares.
|
||||
|
||||
For example:
|
||||
|
||||
* <a href="https://github.com/encode/uvicorn/blob/master/uvicorn/middleware/proxy_headers.py" class="external-link" target="_blank">Uvicorn's `ProxyHeadersMiddleware`</a>
|
||||
* <a href="https://github.com/florimondmanca/msgpack-asgi" class="external-link" target="_blank">MessagePack</a>
|
||||
|
||||
To see other available middlewares check <a href="https://www.starlette.dev/middleware/" class="external-link" target="_blank">Starlette's Middleware docs</a> and the <a href="https://github.com/florimondmanca/awesome-asgi" class="external-link" target="_blank">ASGI Awesome List</a>.
|
||||
@@ -0,0 +1,186 @@
|
||||
# OpenAPI Callbacks { #openapi-callbacks }
|
||||
|
||||
You could create an API with a *path operation* that could trigger a request to an *external API* created by someone else (probably the same developer that would be *using* your API).
|
||||
|
||||
The process that happens when your API app calls the *external API* is named a "callback". Because the software that the external developer wrote sends a request to your API and then your API *calls back*, sending a request to an *external API* (that was probably created by the same developer).
|
||||
|
||||
In this case, you could want to document how that external API *should* look like. What *path operation* it should have, what body it should expect, what response it should return, etc.
|
||||
|
||||
## An app with callbacks { #an-app-with-callbacks }
|
||||
|
||||
Let's see all this with an example.
|
||||
|
||||
Imagine you develop an app that allows creating invoices.
|
||||
|
||||
These invoices will have an `id`, `title` (optional), `customer`, and `total`.
|
||||
|
||||
The user of your API (an external developer) will create an invoice in your API with a POST request.
|
||||
|
||||
Then your API will (let's imagine):
|
||||
|
||||
* Send the invoice to some customer of the external developer.
|
||||
* Collect the money.
|
||||
* Send a notification back to the API user (the external developer).
|
||||
* This will be done by sending a POST request (from *your API*) to some *external API* provided by that external developer (this is the "callback").
|
||||
|
||||
## The normal **FastAPI** app { #the-normal-fastapi-app }
|
||||
|
||||
Let's first see how the normal API app would look like before adding the callback.
|
||||
|
||||
It will have a *path operation* that will receive an `Invoice` body, and a query parameter `callback_url` that will contain the URL for the callback.
|
||||
|
||||
This part is pretty normal, most of the code is probably already familiar to you:
|
||||
|
||||
{* ../../docs_src/openapi_callbacks/tutorial001.py hl[9:13,36:53] *}
|
||||
|
||||
/// tip
|
||||
|
||||
The `callback_url` query parameter uses a Pydantic <a href="https://docs.pydantic.dev/latest/api/networks/" class="external-link" target="_blank">Url</a> type.
|
||||
|
||||
///
|
||||
|
||||
The only new thing is the `callbacks=invoices_callback_router.routes` as an argument to the *path operation decorator*. We'll see what that is next.
|
||||
|
||||
## Documenting the callback { #documenting-the-callback }
|
||||
|
||||
The actual callback code will depend heavily on your own API app.
|
||||
|
||||
And it will probably vary a lot from one app to the next.
|
||||
|
||||
It could be just one or two lines of code, like:
|
||||
|
||||
```Python
|
||||
callback_url = "https://example.com/api/v1/invoices/events/"
|
||||
httpx.post(callback_url, json={"description": "Invoice paid", "paid": True})
|
||||
```
|
||||
|
||||
But possibly the most important part of the callback is making sure that your API user (the external developer) implements the *external API* correctly, according to the data that *your API* is going to send in the request body of the callback, etc.
|
||||
|
||||
So, what we will do next is add the code to document how that *external API* should look like to receive the callback from *your API*.
|
||||
|
||||
That documentation will show up in the Swagger UI at `/docs` in your API, and it will let external developers know how to build the *external API*.
|
||||
|
||||
This example doesn't implement the callback itself (that could be just a line of code), only the documentation part.
|
||||
|
||||
/// tip
|
||||
|
||||
The actual callback is just an HTTP request.
|
||||
|
||||
When implementing the callback yourself, you could use something like <a href="https://www.python-httpx.org" class="external-link" target="_blank">HTTPX</a> or <a href="https://requests.readthedocs.io/" class="external-link" target="_blank">Requests</a>.
|
||||
|
||||
///
|
||||
|
||||
## Write the callback documentation code { #write-the-callback-documentation-code }
|
||||
|
||||
This code won't be executed in your app, we only need it to *document* how that *external API* should look like.
|
||||
|
||||
But, you already know how to easily create automatic documentation for an API with **FastAPI**.
|
||||
|
||||
So we are going to use that same knowledge to document how the *external API* should look like... by creating the *path operation(s)* that the external API should implement (the ones your API will call).
|
||||
|
||||
/// tip
|
||||
|
||||
When writing the code to document a callback, it might be useful to imagine that you are that *external developer*. And that you are currently implementing the *external API*, not *your API*.
|
||||
|
||||
Temporarily adopting this point of view (of the *external developer*) can help you feel like it's more obvious where to put the parameters, the Pydantic model for the body, for the response, etc. for that *external API*.
|
||||
|
||||
///
|
||||
|
||||
### Create a callback `APIRouter` { #create-a-callback-apirouter }
|
||||
|
||||
First create a new `APIRouter` that will contain one or more callbacks.
|
||||
|
||||
{* ../../docs_src/openapi_callbacks/tutorial001.py hl[3,25] *}
|
||||
|
||||
### Create the callback *path operation* { #create-the-callback-path-operation }
|
||||
|
||||
To create the callback *path operation* use the same `APIRouter` you created above.
|
||||
|
||||
It should look just like a normal FastAPI *path operation*:
|
||||
|
||||
* It should probably have a declaration of the body it should receive, e.g. `body: InvoiceEvent`.
|
||||
* And it could also have a declaration of the response it should return, e.g. `response_model=InvoiceEventReceived`.
|
||||
|
||||
{* ../../docs_src/openapi_callbacks/tutorial001.py hl[16:18,21:22,28:32] *}
|
||||
|
||||
There are 2 main differences from a normal *path operation*:
|
||||
|
||||
* It doesn't need to have any actual code, because your app will never call this code. It's only used to document the *external API*. So, the function could just have `pass`.
|
||||
* The *path* can contain an <a href="https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md#key-expression" class="external-link" target="_blank">OpenAPI 3 expression</a> (see more below) where it can use variables with parameters and parts of the original request sent to *your API*.
|
||||
|
||||
### The callback path expression { #the-callback-path-expression }
|
||||
|
||||
The callback *path* can have an <a href="https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.md#key-expression" class="external-link" target="_blank">OpenAPI 3 expression</a> that can contain parts of the original request sent to *your API*.
|
||||
|
||||
In this case, it's the `str`:
|
||||
|
||||
```Python
|
||||
"{$callback_url}/invoices/{$request.body.id}"
|
||||
```
|
||||
|
||||
So, if your API user (the external developer) sends a request to *your API* to:
|
||||
|
||||
```
|
||||
https://yourapi.com/invoices/?callback_url=https://www.external.org/events
|
||||
```
|
||||
|
||||
with a JSON body of:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"id": "2expen51ve",
|
||||
"customer": "Mr. Richie Rich",
|
||||
"total": "9999"
|
||||
}
|
||||
```
|
||||
|
||||
then *your API* will process the invoice, and at some point later, send a callback request to the `callback_url` (the *external API*):
|
||||
|
||||
```
|
||||
https://www.external.org/events/invoices/2expen51ve
|
||||
```
|
||||
|
||||
with a JSON body containing something like:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"description": "Payment celebration",
|
||||
"paid": true
|
||||
}
|
||||
```
|
||||
|
||||
and it would expect a response from that *external API* with a JSON body like:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"ok": true
|
||||
}
|
||||
```
|
||||
|
||||
/// tip
|
||||
|
||||
Notice how the callback URL used contains the URL received as a query parameter in `callback_url` (`https://www.external.org/events`) and also the invoice `id` from inside of the JSON body (`2expen51ve`).
|
||||
|
||||
///
|
||||
|
||||
### Add the callback router { #add-the-callback-router }
|
||||
|
||||
At this point you have the *callback path operation(s)* needed (the one(s) that the *external developer* should implement in the *external API*) in the callback router you created above.
|
||||
|
||||
Now use the parameter `callbacks` in *your API's path operation decorator* to pass the attribute `.routes` (that's actually just a `list` of routes/*path operations*) from that callback router:
|
||||
|
||||
{* ../../docs_src/openapi_callbacks/tutorial001.py hl[35] *}
|
||||
|
||||
/// tip
|
||||
|
||||
Notice that you are not passing the router itself (`invoices_callback_router`) to `callback=`, but the attribute `.routes`, as in `invoices_callback_router.routes`.
|
||||
|
||||
///
|
||||
|
||||
### Check the docs { #check-the-docs }
|
||||
|
||||
Now you can start your app and go to <a href="http://127.0.0.1:8000/docs" class="external-link" target="_blank">http://127.0.0.1:8000/docs</a>.
|
||||
|
||||
You will see your docs including a "Callbacks" section for your *path operation* that shows how the *external API* should look like:
|
||||
|
||||
<img src="/img/tutorial/openapi-callbacks/image01.png">
|
||||
@@ -0,0 +1,55 @@
|
||||
# OpenAPI Webhooks { #openapi-webhooks }
|
||||
|
||||
There are cases where you want to tell your API **users** that your app could call *their* app (sending a request) with some data, normally to **notify** of some type of **event**.
|
||||
|
||||
This means that instead of the normal process of your users sending requests to your API, it's **your API** (or your app) that could **send requests to their system** (to their API, their app).
|
||||
|
||||
This is normally called a **webhook**.
|
||||
|
||||
## Webhooks steps { #webhooks-steps }
|
||||
|
||||
The process normally is that **you define** in your code what is the message that you will send, the **body of the request**.
|
||||
|
||||
You also define in some way at which **moments** your app will send those requests or events.
|
||||
|
||||
And **your users** define in some way (for example in a web dashboard somewhere) the **URL** where your app should send those requests.
|
||||
|
||||
All the **logic** about how to register the URLs for webhooks and the code to actually send those requests is up to you. You write it however you want to in **your own code**.
|
||||
|
||||
## Documenting webhooks with **FastAPI** and OpenAPI { #documenting-webhooks-with-fastapi-and-openapi }
|
||||
|
||||
With **FastAPI**, using OpenAPI, you can define the names of these webhooks, the types of HTTP operations that your app can send (e.g. `POST`, `PUT`, etc.) and the request **bodies** that your app would send.
|
||||
|
||||
This can make it a lot easier for your users to **implement their APIs** to receive your **webhook** requests, they might even be able to autogenerate some of their own API code.
|
||||
|
||||
/// info
|
||||
|
||||
Webhooks are available in OpenAPI 3.1.0 and above, supported by FastAPI `0.99.0` and above.
|
||||
|
||||
///
|
||||
|
||||
## An app with webhooks { #an-app-with-webhooks }
|
||||
|
||||
When you create a **FastAPI** application, there is a `webhooks` attribute that you can use to define *webhooks*, the same way you would define *path operations*, for example with `@app.webhooks.post()`.
|
||||
|
||||
{* ../../docs_src/openapi_webhooks/tutorial001.py hl[9:13,36:53] *}
|
||||
|
||||
The webhooks that you define will end up in the **OpenAPI** schema and the automatic **docs UI**.
|
||||
|
||||
/// info
|
||||
|
||||
The `app.webhooks` object is actually just an `APIRouter`, the same type you would use when structuring your app with multiple files.
|
||||
|
||||
///
|
||||
|
||||
Notice that with webhooks you are actually not declaring a *path* (like `/items/`), the text you pass there is just an **identifier** of the webhook (the name of the event), for example in `@app.webhooks.post("new-subscription")`, the webhook name is `new-subscription`.
|
||||
|
||||
This is because it is expected that **your users** would define the actual **URL path** where they want to receive the webhook request in some other way (e.g. a web dashboard).
|
||||
|
||||
### Check the docs { #check-the-docs }
|
||||
|
||||
Now you can start your app and go to <a href="http://127.0.0.1:8000/docs" class="external-link" target="_blank">http://127.0.0.1:8000/docs</a>.
|
||||
|
||||
You will see your docs have the normal *path operations* and now also some **webhooks**:
|
||||
|
||||
<img src="/img/tutorial/openapi-webhooks/image01.png">
|
||||
@@ -0,0 +1,204 @@
|
||||
# Path Operation Advanced Configuration { #path-operation-advanced-configuration }
|
||||
|
||||
## OpenAPI operationId { #openapi-operationid }
|
||||
|
||||
/// warning
|
||||
|
||||
If you are not an "expert" in OpenAPI, you probably don't need this.
|
||||
|
||||
///
|
||||
|
||||
You can set the OpenAPI `operationId` to be used in your *path operation* with the parameter `operation_id`.
|
||||
|
||||
You would have to make sure that it is unique for each operation.
|
||||
|
||||
{* ../../docs_src/path_operation_advanced_configuration/tutorial001.py hl[6] *}
|
||||
|
||||
### Using the *path operation function* name as the operationId { #using-the-path-operation-function-name-as-the-operationid }
|
||||
|
||||
If you want to use your APIs' function names as `operationId`s, you can iterate over all of them and override each *path operation's* `operation_id` using their `APIRoute.name`.
|
||||
|
||||
You should do it after adding all your *path operations*.
|
||||
|
||||
{* ../../docs_src/path_operation_advanced_configuration/tutorial002.py hl[2, 12:21, 24] *}
|
||||
|
||||
/// tip
|
||||
|
||||
If you manually call `app.openapi()`, you should update the `operationId`s before that.
|
||||
|
||||
///
|
||||
|
||||
/// warning
|
||||
|
||||
If you do this, you have to make sure each one of your *path operation functions* has a unique name.
|
||||
|
||||
Even if they are in different modules (Python files).
|
||||
|
||||
///
|
||||
|
||||
## Exclude from OpenAPI { #exclude-from-openapi }
|
||||
|
||||
To exclude a *path operation* from the generated OpenAPI schema (and thus, from the automatic documentation systems), use the parameter `include_in_schema` and set it to `False`:
|
||||
|
||||
{* ../../docs_src/path_operation_advanced_configuration/tutorial003.py hl[6] *}
|
||||
|
||||
## Advanced description from docstring { #advanced-description-from-docstring }
|
||||
|
||||
You can limit the lines used from the docstring of a *path operation function* for OpenAPI.
|
||||
|
||||
Adding an `\f` (an escaped "form feed" character) causes **FastAPI** to truncate the output used for OpenAPI at this point.
|
||||
|
||||
It won't show up in the documentation, but other tools (such as Sphinx) will be able to use the rest.
|
||||
|
||||
{* ../../docs_src/path_operation_advanced_configuration/tutorial004.py hl[19:29] *}
|
||||
|
||||
## Additional Responses { #additional-responses }
|
||||
|
||||
You probably have seen how to declare the `response_model` and `status_code` for a *path operation*.
|
||||
|
||||
That defines the metadata about the main response of a *path operation*.
|
||||
|
||||
You can also declare additional responses with their models, status codes, etc.
|
||||
|
||||
There's a whole chapter here in the documentation about it, you can read it at [Additional Responses in OpenAPI](additional-responses.md){.internal-link target=_blank}.
|
||||
|
||||
## OpenAPI Extra { #openapi-extra }
|
||||
|
||||
When you declare a *path operation* in your application, **FastAPI** automatically generates the relevant metadata about that *path operation* to be included in the OpenAPI schema.
|
||||
|
||||
/// note | Technical details
|
||||
|
||||
In the OpenAPI specification it is called the <a href="https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#operation-object" class="external-link" target="_blank">Operation Object</a>.
|
||||
|
||||
///
|
||||
|
||||
It has all the information about the *path operation* and is used to generate the automatic documentation.
|
||||
|
||||
It includes the `tags`, `parameters`, `requestBody`, `responses`, etc.
|
||||
|
||||
This *path operation*-specific OpenAPI schema is normally generated automatically by **FastAPI**, but you can also extend it.
|
||||
|
||||
/// tip
|
||||
|
||||
This is a low level extension point.
|
||||
|
||||
If you only need to declare additional responses, a more convenient way to do it is with [Additional Responses in OpenAPI](additional-responses.md){.internal-link target=_blank}.
|
||||
|
||||
///
|
||||
|
||||
You can extend the OpenAPI schema for a *path operation* using the parameter `openapi_extra`.
|
||||
|
||||
### OpenAPI Extensions { #openapi-extensions }
|
||||
|
||||
This `openapi_extra` can be helpful, for example, to declare [OpenAPI Extensions](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#specificationExtensions):
|
||||
|
||||
{* ../../docs_src/path_operation_advanced_configuration/tutorial005.py hl[6] *}
|
||||
|
||||
If you open the automatic API docs, your extension will show up at the bottom of the specific *path operation*.
|
||||
|
||||
<img src="/img/tutorial/path-operation-advanced-configuration/image01.png">
|
||||
|
||||
And if you see the resulting OpenAPI (at `/openapi.json` in your API), you will see your extension as part of the specific *path operation* too:
|
||||
|
||||
```JSON hl_lines="22"
|
||||
{
|
||||
"openapi": "3.1.0",
|
||||
"info": {
|
||||
"title": "FastAPI",
|
||||
"version": "0.1.0"
|
||||
},
|
||||
"paths": {
|
||||
"/items/": {
|
||||
"get": {
|
||||
"summary": "Read Items",
|
||||
"operationId": "read_items_items__get",
|
||||
"responses": {
|
||||
"200": {
|
||||
"description": "Successful Response",
|
||||
"content": {
|
||||
"application/json": {
|
||||
"schema": {}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"x-aperture-labs-portal": "blue"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Custom OpenAPI *path operation* schema { #custom-openapi-path-operation-schema }
|
||||
|
||||
The dictionary in `openapi_extra` will be deeply merged with the automatically generated OpenAPI schema for the *path operation*.
|
||||
|
||||
So, you could add additional data to the automatically generated schema.
|
||||
|
||||
For example, you could decide to read and validate the request with your own code, without using the automatic features of FastAPI with Pydantic, but you could still want to define the request in the OpenAPI schema.
|
||||
|
||||
You could do that with `openapi_extra`:
|
||||
|
||||
{* ../../docs_src/path_operation_advanced_configuration/tutorial006.py hl[19:36, 39:40] *}
|
||||
|
||||
In this example, we didn't declare any Pydantic model. In fact, the request body is not even <abbr title="converted from some plain format, like bytes, into Python objects">parsed</abbr> as JSON, it is read directly as `bytes`, and the function `magic_data_reader()` would be in charge of parsing it in some way.
|
||||
|
||||
Nevertheless, we can declare the expected schema for the request body.
|
||||
|
||||
### Custom OpenAPI content type { #custom-openapi-content-type }
|
||||
|
||||
Using this same trick, you could use a Pydantic model to define the JSON Schema that is then included in the custom OpenAPI schema section for the *path operation*.
|
||||
|
||||
And you could do this even if the data type in the request is not JSON.
|
||||
|
||||
For example, in this application we don't use FastAPI's integrated functionality to extract the JSON Schema from Pydantic models nor the automatic validation for JSON. In fact, we are declaring the request content type as YAML, not JSON:
|
||||
|
||||
//// tab | Pydantic v2
|
||||
|
||||
{* ../../docs_src/path_operation_advanced_configuration/tutorial007.py hl[17:22, 24] *}
|
||||
|
||||
////
|
||||
|
||||
//// tab | Pydantic v1
|
||||
|
||||
{* ../../docs_src/path_operation_advanced_configuration/tutorial007_pv1.py hl[17:22, 24] *}
|
||||
|
||||
////
|
||||
|
||||
/// info
|
||||
|
||||
In Pydantic version 1 the method to get the JSON Schema for a model was called `Item.schema()`, in Pydantic version 2, the method is called `Item.model_json_schema()`.
|
||||
|
||||
///
|
||||
|
||||
Nevertheless, although we are not using the default integrated functionality, we are still using a Pydantic model to manually generate the JSON Schema for the data that we want to receive in YAML.
|
||||
|
||||
Then we use the request directly, and extract the body as `bytes`. This means that FastAPI won't even try to parse the request payload as JSON.
|
||||
|
||||
And then in our code, we parse that YAML content directly, and then we are again using the same Pydantic model to validate the YAML content:
|
||||
|
||||
//// tab | Pydantic v2
|
||||
|
||||
{* ../../docs_src/path_operation_advanced_configuration/tutorial007.py hl[26:33] *}
|
||||
|
||||
////
|
||||
|
||||
//// tab | Pydantic v1
|
||||
|
||||
{* ../../docs_src/path_operation_advanced_configuration/tutorial007_pv1.py hl[26:33] *}
|
||||
|
||||
////
|
||||
|
||||
/// info
|
||||
|
||||
In Pydantic version 1 the method to parse and validate an object was `Item.parse_obj()`, in Pydantic version 2, the method is called `Item.model_validate()`.
|
||||
|
||||
///
|
||||
|
||||
/// tip
|
||||
|
||||
Here we reuse the same Pydantic model.
|
||||
|
||||
But the same way, we could have validated it in some other way.
|
||||
|
||||
///
|
||||
@@ -0,0 +1,31 @@
|
||||
# Response - Change Status Code { #response-change-status-code }
|
||||
|
||||
You probably read before that you can set a default [Response Status Code](../tutorial/response-status-code.md){.internal-link target=_blank}.
|
||||
|
||||
But in some cases you need to return a different status code than the default.
|
||||
|
||||
## Use case { #use-case }
|
||||
|
||||
For example, imagine that you want to return an HTTP status code of "OK" `200` by default.
|
||||
|
||||
But if the data didn't exist, you want to create it, and return an HTTP status code of "CREATED" `201`.
|
||||
|
||||
But you still want to be able to filter and convert the data you return with a `response_model`.
|
||||
|
||||
For those cases, you can use a `Response` parameter.
|
||||
|
||||
## Use a `Response` parameter { #use-a-response-parameter }
|
||||
|
||||
You can declare a parameter of type `Response` in your *path operation function* (as you can do for cookies and headers).
|
||||
|
||||
And then you can set the `status_code` in that *temporal* response object.
|
||||
|
||||
{* ../../docs_src/response_change_status_code/tutorial001.py hl[1,9,12] *}
|
||||
|
||||
And then you can return any object you need, as you normally would (a `dict`, a database model, etc).
|
||||
|
||||
And if you declared a `response_model`, it will still be used to filter and convert the object you returned.
|
||||
|
||||
**FastAPI** will use that *temporal* response to extract the status code (also cookies and headers), and will put them in the final response that contains the value you returned, filtered by any `response_model`.
|
||||
|
||||
You can also declare the `Response` parameter in dependencies, and set the status code in them. But keep in mind that the last one to be set will win.
|
||||
@@ -0,0 +1,51 @@
|
||||
# Response Cookies { #response-cookies }
|
||||
|
||||
## Use a `Response` parameter { #use-a-response-parameter }
|
||||
|
||||
You can declare a parameter of type `Response` in your *path operation function*.
|
||||
|
||||
And then you can set cookies in that *temporal* response object.
|
||||
|
||||
{* ../../docs_src/response_cookies/tutorial002.py hl[1, 8:9] *}
|
||||
|
||||
And then you can return any object you need, as you normally would (a `dict`, a database model, etc).
|
||||
|
||||
And if you declared a `response_model`, it will still be used to filter and convert the object you returned.
|
||||
|
||||
**FastAPI** will use that *temporal* response to extract the cookies (also headers and status code), and will put them in the final response that contains the value you returned, filtered by any `response_model`.
|
||||
|
||||
You can also declare the `Response` parameter in dependencies, and set cookies (and headers) in them.
|
||||
|
||||
## Return a `Response` directly { #return-a-response-directly }
|
||||
|
||||
You can also create cookies when returning a `Response` directly in your code.
|
||||
|
||||
To do that, you can create a response as described in [Return a Response Directly](response-directly.md){.internal-link target=_blank}.
|
||||
|
||||
Then set Cookies in it, and then return it:
|
||||
|
||||
{* ../../docs_src/response_cookies/tutorial001.py hl[10:12] *}
|
||||
|
||||
/// tip
|
||||
|
||||
Keep in mind that if you return a response directly instead of using the `Response` parameter, FastAPI will return it directly.
|
||||
|
||||
So, you will have to make sure your data is of the correct type. E.g. it is compatible with JSON, if you are returning a `JSONResponse`.
|
||||
|
||||
And also that you are not sending any data that should have been filtered by a `response_model`.
|
||||
|
||||
///
|
||||
|
||||
### More info { #more-info }
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
You could also use `from starlette.responses import Response` or `from starlette.responses import JSONResponse`.
|
||||
|
||||
**FastAPI** provides the same `starlette.responses` as `fastapi.responses` just as a convenience for you, the developer. But most of the available responses come directly from Starlette.
|
||||
|
||||
And as the `Response` can be used frequently to set headers and cookies, **FastAPI** also provides it at `fastapi.Response`.
|
||||
|
||||
///
|
||||
|
||||
To see all the available parameters and options, check the <a href="https://www.starlette.dev/responses/#set-cookie" class="external-link" target="_blank">documentation in Starlette</a>.
|
||||
@@ -0,0 +1,65 @@
|
||||
# Return a Response Directly { #return-a-response-directly }
|
||||
|
||||
When you create a **FastAPI** *path operation* you can normally return any data from it: a `dict`, a `list`, a Pydantic model, a database model, etc.
|
||||
|
||||
By default, **FastAPI** would automatically convert that return value to JSON using the `jsonable_encoder` explained in [JSON Compatible Encoder](../tutorial/encoder.md){.internal-link target=_blank}.
|
||||
|
||||
Then, behind the scenes, it would put that JSON-compatible data (e.g. a `dict`) inside of a `JSONResponse` that would be used to send the response to the client.
|
||||
|
||||
But you can return a `JSONResponse` directly from your *path operations*.
|
||||
|
||||
It might be useful, for example, to return custom headers or cookies.
|
||||
|
||||
## Return a `Response` { #return-a-response }
|
||||
|
||||
In fact, you can return any `Response` or any sub-class of it.
|
||||
|
||||
/// tip
|
||||
|
||||
`JSONResponse` itself is a sub-class of `Response`.
|
||||
|
||||
///
|
||||
|
||||
And when you return a `Response`, **FastAPI** will pass it directly.
|
||||
|
||||
It won't do any data conversion with Pydantic models, it won't convert the contents to any type, etc.
|
||||
|
||||
This gives you a lot of flexibility. You can return any data type, override any data declaration or validation, etc.
|
||||
|
||||
## Using the `jsonable_encoder` in a `Response` { #using-the-jsonable-encoder-in-a-response }
|
||||
|
||||
Because **FastAPI** doesn't make any changes to a `Response` you return, you have to make sure its contents are ready for it.
|
||||
|
||||
For example, you cannot put a Pydantic model in a `JSONResponse` without first converting it to a `dict` with all the data types (like `datetime`, `UUID`, etc) converted to JSON-compatible types.
|
||||
|
||||
For those cases, you can use the `jsonable_encoder` to convert your data before passing it to a response:
|
||||
|
||||
{* ../../docs_src/response_directly/tutorial001.py hl[6:7,21:22] *}
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
You could also use `from starlette.responses import JSONResponse`.
|
||||
|
||||
**FastAPI** provides the same `starlette.responses` as `fastapi.responses` just as a convenience for you, the developer. But most of the available responses come directly from Starlette.
|
||||
|
||||
///
|
||||
|
||||
## Returning a custom `Response` { #returning-a-custom-response }
|
||||
|
||||
The example above shows all the parts you need, but it's not very useful yet, as you could have just returned the `item` directly, and **FastAPI** would put it in a `JSONResponse` for you, converting it to a `dict`, etc. All that by default.
|
||||
|
||||
Now, let's see how you could use that to return a custom response.
|
||||
|
||||
Let's say that you want to return an <a href="https://en.wikipedia.org/wiki/XML" class="external-link" target="_blank">XML</a> response.
|
||||
|
||||
You could put your XML content in a string, put that in a `Response`, and return it:
|
||||
|
||||
{* ../../docs_src/response_directly/tutorial002.py hl[1,18] *}
|
||||
|
||||
## Notes { #notes }
|
||||
|
||||
When you return a `Response` directly its data is not validated, converted (serialized), or documented automatically.
|
||||
|
||||
But you can still document it as described in [Additional Responses in OpenAPI](additional-responses.md){.internal-link target=_blank}.
|
||||
|
||||
You can see in later sections how to use/declare these custom `Response`s while still having automatic data conversion, documentation, etc.
|
||||
@@ -0,0 +1,41 @@
|
||||
# Response Headers { #response-headers }
|
||||
|
||||
## Use a `Response` parameter { #use-a-response-parameter }
|
||||
|
||||
You can declare a parameter of type `Response` in your *path operation function* (as you can do for cookies).
|
||||
|
||||
And then you can set headers in that *temporal* response object.
|
||||
|
||||
{* ../../docs_src/response_headers/tutorial002.py hl[1, 7:8] *}
|
||||
|
||||
And then you can return any object you need, as you normally would (a `dict`, a database model, etc).
|
||||
|
||||
And if you declared a `response_model`, it will still be used to filter and convert the object you returned.
|
||||
|
||||
**FastAPI** will use that *temporal* response to extract the headers (also cookies and status code), and will put them in the final response that contains the value you returned, filtered by any `response_model`.
|
||||
|
||||
You can also declare the `Response` parameter in dependencies, and set headers (and cookies) in them.
|
||||
|
||||
## Return a `Response` directly { #return-a-response-directly }
|
||||
|
||||
You can also add headers when you return a `Response` directly.
|
||||
|
||||
Create a response as described in [Return a Response Directly](response-directly.md){.internal-link target=_blank} and pass the headers as an additional parameter:
|
||||
|
||||
{* ../../docs_src/response_headers/tutorial001.py hl[10:12] *}
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
You could also use `from starlette.responses import Response` or `from starlette.responses import JSONResponse`.
|
||||
|
||||
**FastAPI** provides the same `starlette.responses` as `fastapi.responses` just as a convenience for you, the developer. But most of the available responses come directly from Starlette.
|
||||
|
||||
And as the `Response` can be used frequently to set headers and cookies, **FastAPI** also provides it at `fastapi.Response`.
|
||||
|
||||
///
|
||||
|
||||
## Custom Headers { #custom-headers }
|
||||
|
||||
Keep in mind that custom proprietary headers can be added <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers" class="external-link" target="_blank">using the `X-` prefix</a>.
|
||||
|
||||
But if you have custom headers that you want a client in a browser to be able to see, you need to add them to your CORS configurations (read more in [CORS (Cross-Origin Resource Sharing)](../tutorial/cors.md){.internal-link target=_blank}), using the parameter `expose_headers` documented in <a href="https://www.starlette.dev/middleware/#corsmiddleware" class="external-link" target="_blank">Starlette's CORS docs</a>.
|
||||
@@ -0,0 +1,107 @@
|
||||
# HTTP Basic Auth { #http-basic-auth }
|
||||
|
||||
For the simplest cases, you can use HTTP Basic Auth.
|
||||
|
||||
In HTTP Basic Auth, the application expects a header that contains a username and a password.
|
||||
|
||||
If it doesn't receive it, it returns an HTTP 401 "Unauthorized" error.
|
||||
|
||||
And returns a header `WWW-Authenticate` with a value of `Basic`, and an optional `realm` parameter.
|
||||
|
||||
That tells the browser to show the integrated prompt for a username and password.
|
||||
|
||||
Then, when you type that username and password, the browser sends them in the header automatically.
|
||||
|
||||
## Simple HTTP Basic Auth { #simple-http-basic-auth }
|
||||
|
||||
* Import `HTTPBasic` and `HTTPBasicCredentials`.
|
||||
* Create a "`security` scheme" using `HTTPBasic`.
|
||||
* Use that `security` with a dependency in your *path operation*.
|
||||
* It returns an object of type `HTTPBasicCredentials`:
|
||||
* It contains the `username` and `password` sent.
|
||||
|
||||
{* ../../docs_src/security/tutorial006_an_py39.py hl[4,8,12] *}
|
||||
|
||||
When you try to open the URL for the first time (or click the "Execute" button in the docs) the browser will ask you for your username and password:
|
||||
|
||||
<img src="/img/tutorial/security/image12.png">
|
||||
|
||||
## Check the username { #check-the-username }
|
||||
|
||||
Here's a more complete example.
|
||||
|
||||
Use a dependency to check if the username and password are correct.
|
||||
|
||||
For this, use the Python standard module <a href="https://docs.python.org/3/library/secrets.html" class="external-link" target="_blank">`secrets`</a> to check the username and password.
|
||||
|
||||
`secrets.compare_digest()` needs to take `bytes` or a `str` that only contains ASCII characters (the ones in English), this means it wouldn't work with characters like `á`, as in `Sebastián`.
|
||||
|
||||
To handle that, we first convert the `username` and `password` to `bytes` encoding them with UTF-8.
|
||||
|
||||
Then we can use `secrets.compare_digest()` to ensure that `credentials.username` is `"stanleyjobson"`, and that `credentials.password` is `"swordfish"`.
|
||||
|
||||
{* ../../docs_src/security/tutorial007_an_py39.py hl[1,12:24] *}
|
||||
|
||||
This would be similar to:
|
||||
|
||||
```Python
|
||||
if not (credentials.username == "stanleyjobson") or not (credentials.password == "swordfish"):
|
||||
# Return some error
|
||||
...
|
||||
```
|
||||
|
||||
But by using the `secrets.compare_digest()` it will be secure against a type of attacks called "timing attacks".
|
||||
|
||||
### Timing Attacks { #timing-attacks }
|
||||
|
||||
But what's a "timing attack"?
|
||||
|
||||
Let's imagine some attackers are trying to guess the username and password.
|
||||
|
||||
And they send a request with a username `johndoe` and a password `love123`.
|
||||
|
||||
Then the Python code in your application would be equivalent to something like:
|
||||
|
||||
```Python
|
||||
if "johndoe" == "stanleyjobson" and "love123" == "swordfish":
|
||||
...
|
||||
```
|
||||
|
||||
But right at the moment Python compares the first `j` in `johndoe` to the first `s` in `stanleyjobson`, it will return `False`, because it already knows that those two strings are not the same, thinking that "there's no need to waste more computation comparing the rest of the letters". And your application will say "Incorrect username or password".
|
||||
|
||||
But then the attackers try with username `stanleyjobsox` and password `love123`.
|
||||
|
||||
And your application code does something like:
|
||||
|
||||
```Python
|
||||
if "stanleyjobsox" == "stanleyjobson" and "love123" == "swordfish":
|
||||
...
|
||||
```
|
||||
|
||||
Python will have to compare the whole `stanleyjobso` in both `stanleyjobsox` and `stanleyjobson` before realizing that both strings are not the same. So it will take some extra microseconds to reply back "Incorrect username or password".
|
||||
|
||||
#### The time to answer helps the attackers { #the-time-to-answer-helps-the-attackers }
|
||||
|
||||
At that point, by noticing that the server took some microseconds longer to send the "Incorrect username or password" response, the attackers will know that they got _something_ right, some of the initial letters were right.
|
||||
|
||||
And then they can try again knowing that it's probably something more similar to `stanleyjobsox` than to `johndoe`.
|
||||
|
||||
#### A "professional" attack { #a-professional-attack }
|
||||
|
||||
Of course, the attackers would not try all this by hand, they would write a program to do it, possibly with thousands or millions of tests per second. And they would get just one extra correct letter at a time.
|
||||
|
||||
But doing that, in some minutes or hours the attackers would have guessed the correct username and password, with the "help" of our application, just using the time taken to answer.
|
||||
|
||||
#### Fix it with `secrets.compare_digest()` { #fix-it-with-secrets-compare-digest }
|
||||
|
||||
But in our code we are actually using `secrets.compare_digest()`.
|
||||
|
||||
In short, it will take the same time to compare `stanleyjobsox` to `stanleyjobson` than it takes to compare `johndoe` to `stanleyjobson`. And the same for the password.
|
||||
|
||||
That way, using `secrets.compare_digest()` in your application code, it will be safe against this whole range of security attacks.
|
||||
|
||||
### Return the error { #return-the-error }
|
||||
|
||||
After detecting that the credentials are incorrect, return an `HTTPException` with a status code 401 (the same returned when no credentials are provided) and add the header `WWW-Authenticate` to make the browser show the login prompt again:
|
||||
|
||||
{* ../../docs_src/security/tutorial007_an_py39.py hl[26:30] *}
|
||||
@@ -0,0 +1,19 @@
|
||||
# Advanced Security { #advanced-security }
|
||||
|
||||
## Additional Features { #additional-features }
|
||||
|
||||
There are some extra features to handle security apart from the ones covered in the [Tutorial - User Guide: Security](../../tutorial/security/index.md){.internal-link target=_blank}.
|
||||
|
||||
/// tip
|
||||
|
||||
The next sections are **not necessarily "advanced"**.
|
||||
|
||||
And it's possible that for your use case, the solution is in one of them.
|
||||
|
||||
///
|
||||
|
||||
## Read the Tutorial first { #read-the-tutorial-first }
|
||||
|
||||
The next sections assume you already read the main [Tutorial - User Guide: Security](../../tutorial/security/index.md){.internal-link target=_blank}.
|
||||
|
||||
They are all based on the same concepts, but allow some extra functionalities.
|
||||
@@ -0,0 +1,274 @@
|
||||
# OAuth2 scopes { #oauth2-scopes }
|
||||
|
||||
You can use OAuth2 scopes directly with **FastAPI**, they are integrated to work seamlessly.
|
||||
|
||||
This would allow you to have a more fine-grained permission system, following the OAuth2 standard, integrated into your OpenAPI application (and the API docs).
|
||||
|
||||
OAuth2 with scopes is the mechanism used by many big authentication providers, like Facebook, Google, GitHub, Microsoft, X (Twitter), etc. They use it to provide specific permissions to users and applications.
|
||||
|
||||
Every time you "log in with" Facebook, Google, GitHub, Microsoft, X (Twitter), that application is using OAuth2 with scopes.
|
||||
|
||||
In this section you will see how to manage authentication and authorization with the same OAuth2 with scopes in your **FastAPI** application.
|
||||
|
||||
/// warning
|
||||
|
||||
This is a more or less advanced section. If you are just starting, you can skip it.
|
||||
|
||||
You don't necessarily need OAuth2 scopes, and you can handle authentication and authorization however you want.
|
||||
|
||||
But OAuth2 with scopes can be nicely integrated into your API (with OpenAPI) and your API docs.
|
||||
|
||||
Nevertheless, you still enforce those scopes, or any other security/authorization requirement, however you need, in your code.
|
||||
|
||||
In many cases, OAuth2 with scopes can be an overkill.
|
||||
|
||||
But if you know you need it, or you are curious, keep reading.
|
||||
|
||||
///
|
||||
|
||||
## OAuth2 scopes and OpenAPI { #oauth2-scopes-and-openapi }
|
||||
|
||||
The OAuth2 specification defines "scopes" as a list of strings separated by spaces.
|
||||
|
||||
The content of each of these strings can have any format, but should not contain spaces.
|
||||
|
||||
These scopes represent "permissions".
|
||||
|
||||
In OpenAPI (e.g. the API docs), you can define "security schemes".
|
||||
|
||||
When one of these security schemes uses OAuth2, you can also declare and use scopes.
|
||||
|
||||
Each "scope" is just a string (without spaces).
|
||||
|
||||
They are normally used to declare specific security permissions, for example:
|
||||
|
||||
* `users:read` or `users:write` are common examples.
|
||||
* `instagram_basic` is used by Facebook / Instagram.
|
||||
* `https://www.googleapis.com/auth/drive` is used by Google.
|
||||
|
||||
/// info
|
||||
|
||||
In OAuth2 a "scope" is just a string that declares a specific permission required.
|
||||
|
||||
It doesn't matter if it has other characters like `:` or if it is a URL.
|
||||
|
||||
Those details are implementation specific.
|
||||
|
||||
For OAuth2 they are just strings.
|
||||
|
||||
///
|
||||
|
||||
## Global view { #global-view }
|
||||
|
||||
First, let's quickly see the parts that change from the examples in the main **Tutorial - User Guide** for [OAuth2 with Password (and hashing), Bearer with JWT tokens](../../tutorial/security/oauth2-jwt.md){.internal-link target=_blank}. Now using OAuth2 scopes:
|
||||
|
||||
{* ../../docs_src/security/tutorial005_an_py310.py hl[5,9,13,47,65,106,108:116,122:126,130:136,141,157] *}
|
||||
|
||||
Now let's review those changes step by step.
|
||||
|
||||
## OAuth2 Security scheme { #oauth2-security-scheme }
|
||||
|
||||
The first change is that now we are declaring the OAuth2 security scheme with two available scopes, `me` and `items`.
|
||||
|
||||
The `scopes` parameter receives a `dict` with each scope as a key and the description as the value:
|
||||
|
||||
{* ../../docs_src/security/tutorial005_an_py310.py hl[63:66] *}
|
||||
|
||||
Because we are now declaring those scopes, they will show up in the API docs when you log-in/authorize.
|
||||
|
||||
And you will be able to select which scopes you want to give access to: `me` and `items`.
|
||||
|
||||
This is the same mechanism used when you give permissions while logging in with Facebook, Google, GitHub, etc:
|
||||
|
||||
<img src="/img/tutorial/security/image11.png">
|
||||
|
||||
## JWT token with scopes { #jwt-token-with-scopes }
|
||||
|
||||
Now, modify the token *path operation* to return the scopes requested.
|
||||
|
||||
We are still using the same `OAuth2PasswordRequestForm`. It includes a property `scopes` with a `list` of `str`, with each scope it received in the request.
|
||||
|
||||
And we return the scopes as part of the JWT token.
|
||||
|
||||
/// danger
|
||||
|
||||
For simplicity, here we are just adding the scopes received directly to the token.
|
||||
|
||||
But in your application, for security, you should make sure you only add the scopes that the user is actually able to have, or the ones you have predefined.
|
||||
|
||||
///
|
||||
|
||||
{* ../../docs_src/security/tutorial005_an_py310.py hl[157] *}
|
||||
|
||||
## Declare scopes in *path operations* and dependencies { #declare-scopes-in-path-operations-and-dependencies }
|
||||
|
||||
Now we declare that the *path operation* for `/users/me/items/` requires the scope `items`.
|
||||
|
||||
For this, we import and use `Security` from `fastapi`.
|
||||
|
||||
You can use `Security` to declare dependencies (just like `Depends`), but `Security` also receives a parameter `scopes` with a list of scopes (strings).
|
||||
|
||||
In this case, we pass a dependency function `get_current_active_user` to `Security` (the same way we would do with `Depends`).
|
||||
|
||||
But we also pass a `list` of scopes, in this case with just one scope: `items` (it could have more).
|
||||
|
||||
And the dependency function `get_current_active_user` can also declare sub-dependencies, not only with `Depends` but also with `Security`. Declaring its own sub-dependency function (`get_current_user`), and more scope requirements.
|
||||
|
||||
In this case, it requires the scope `me` (it could require more than one scope).
|
||||
|
||||
/// note
|
||||
|
||||
You don't necessarily need to add different scopes in different places.
|
||||
|
||||
We are doing it here to demonstrate how **FastAPI** handles scopes declared at different levels.
|
||||
|
||||
///
|
||||
|
||||
{* ../../docs_src/security/tutorial005_an_py310.py hl[5,141,172] *}
|
||||
|
||||
/// info | Technical Details
|
||||
|
||||
`Security` is actually a subclass of `Depends`, and it has just one extra parameter that we'll see later.
|
||||
|
||||
But by using `Security` instead of `Depends`, **FastAPI** will know that it can declare security scopes, use them internally, and document the API with OpenAPI.
|
||||
|
||||
But when you import `Query`, `Path`, `Depends`, `Security` and others from `fastapi`, those are actually functions that return special classes.
|
||||
|
||||
///
|
||||
|
||||
## Use `SecurityScopes` { #use-securityscopes }
|
||||
|
||||
Now update the dependency `get_current_user`.
|
||||
|
||||
This is the one used by the dependencies above.
|
||||
|
||||
Here's where we are using the same OAuth2 scheme we created before, declaring it as a dependency: `oauth2_scheme`.
|
||||
|
||||
Because this dependency function doesn't have any scope requirements itself, we can use `Depends` with `oauth2_scheme`, we don't have to use `Security` when we don't need to specify security scopes.
|
||||
|
||||
We also declare a special parameter of type `SecurityScopes`, imported from `fastapi.security`.
|
||||
|
||||
This `SecurityScopes` class is similar to `Request` (`Request` was used to get the request object directly).
|
||||
|
||||
{* ../../docs_src/security/tutorial005_an_py310.py hl[9,106] *}
|
||||
|
||||
## Use the `scopes` { #use-the-scopes }
|
||||
|
||||
The parameter `security_scopes` will be of type `SecurityScopes`.
|
||||
|
||||
It will have a property `scopes` with a list containing all the scopes required by itself and all the dependencies that use this as a sub-dependency. That means, all the "dependants"... this might sound confusing, it is explained again later below.
|
||||
|
||||
The `security_scopes` object (of class `SecurityScopes`) also provides a `scope_str` attribute with a single string, containing those scopes separated by spaces (we are going to use it).
|
||||
|
||||
We create an `HTTPException` that we can reuse (`raise`) later at several points.
|
||||
|
||||
In this exception, we include the scopes required (if any) as a string separated by spaces (using `scope_str`). We put that string containing the scopes in the `WWW-Authenticate` header (this is part of the spec).
|
||||
|
||||
{* ../../docs_src/security/tutorial005_an_py310.py hl[106,108:116] *}
|
||||
|
||||
## Verify the `username` and data shape { #verify-the-username-and-data-shape }
|
||||
|
||||
We verify that we get a `username`, and extract the scopes.
|
||||
|
||||
And then we validate that data with the Pydantic model (catching the `ValidationError` exception), and if we get an error reading the JWT token or validating the data with Pydantic, we raise the `HTTPException` we created before.
|
||||
|
||||
For that, we update the Pydantic model `TokenData` with a new property `scopes`.
|
||||
|
||||
By validating the data with Pydantic we can make sure that we have, for example, exactly a `list` of `str` with the scopes and a `str` with the `username`.
|
||||
|
||||
Instead of, for example, a `dict`, or something else, as it could break the application at some point later, making it a security risk.
|
||||
|
||||
We also verify that we have a user with that username, and if not, we raise that same exception we created before.
|
||||
|
||||
{* ../../docs_src/security/tutorial005_an_py310.py hl[47,117:129] *}
|
||||
|
||||
## Verify the `scopes` { #verify-the-scopes }
|
||||
|
||||
We now verify that all the scopes required, by this dependency and all the dependants (including *path operations*), are included in the scopes provided in the token received, otherwise raise an `HTTPException`.
|
||||
|
||||
For this, we use `security_scopes.scopes`, that contains a `list` with all these scopes as `str`.
|
||||
|
||||
{* ../../docs_src/security/tutorial005_an_py310.py hl[130:136] *}
|
||||
|
||||
## Dependency tree and scopes { #dependency-tree-and-scopes }
|
||||
|
||||
Let's review again this dependency tree and the scopes.
|
||||
|
||||
As the `get_current_active_user` dependency has as a sub-dependency on `get_current_user`, the scope `"me"` declared at `get_current_active_user` will be included in the list of required scopes in the `security_scopes.scopes` passed to `get_current_user`.
|
||||
|
||||
The *path operation* itself also declares a scope, `"items"`, so this will also be in the list of `security_scopes.scopes` passed to `get_current_user`.
|
||||
|
||||
Here's how the hierarchy of dependencies and scopes looks like:
|
||||
|
||||
* The *path operation* `read_own_items` has:
|
||||
* Required scopes `["items"]` with the dependency:
|
||||
* `get_current_active_user`:
|
||||
* The dependency function `get_current_active_user` has:
|
||||
* Required scopes `["me"]` with the dependency:
|
||||
* `get_current_user`:
|
||||
* The dependency function `get_current_user` has:
|
||||
* No scopes required by itself.
|
||||
* A dependency using `oauth2_scheme`.
|
||||
* A `security_scopes` parameter of type `SecurityScopes`:
|
||||
* This `security_scopes` parameter has a property `scopes` with a `list` containing all these scopes declared above, so:
|
||||
* `security_scopes.scopes` will contain `["me", "items"]` for the *path operation* `read_own_items`.
|
||||
* `security_scopes.scopes` will contain `["me"]` for the *path operation* `read_users_me`, because it is declared in the dependency `get_current_active_user`.
|
||||
* `security_scopes.scopes` will contain `[]` (nothing) for the *path operation* `read_system_status`, because it didn't declare any `Security` with `scopes`, and its dependency, `get_current_user`, doesn't declare any `scopes` either.
|
||||
|
||||
/// tip
|
||||
|
||||
The important and "magic" thing here is that `get_current_user` will have a different list of `scopes` to check for each *path operation*.
|
||||
|
||||
All depending on the `scopes` declared in each *path operation* and each dependency in the dependency tree for that specific *path operation*.
|
||||
|
||||
///
|
||||
|
||||
## More details about `SecurityScopes` { #more-details-about-securityscopes }
|
||||
|
||||
You can use `SecurityScopes` at any point, and in multiple places, it doesn't have to be at the "root" dependency.
|
||||
|
||||
It will always have the security scopes declared in the current `Security` dependencies and all the dependants for **that specific** *path operation* and **that specific** dependency tree.
|
||||
|
||||
Because the `SecurityScopes` will have all the scopes declared by dependants, you can use it to verify that a token has the required scopes in a central dependency function, and then declare different scope requirements in different *path operations*.
|
||||
|
||||
They will be checked independently for each *path operation*.
|
||||
|
||||
## Check it { #check-it }
|
||||
|
||||
If you open the API docs, you can authenticate and specify which scopes you want to authorize.
|
||||
|
||||
<img src="/img/tutorial/security/image11.png">
|
||||
|
||||
If you don't select any scope, you will be "authenticated", but when you try to access `/users/me/` or `/users/me/items/` you will get an error saying that you don't have enough permissions. You will still be able to access `/status/`.
|
||||
|
||||
And if you select the scope `me` but not the scope `items`, you will be able to access `/users/me/` but not `/users/me/items/`.
|
||||
|
||||
That's what would happen to a third party application that tried to access one of these *path operations* with a token provided by a user, depending on how many permissions the user gave the application.
|
||||
|
||||
## About third party integrations { #about-third-party-integrations }
|
||||
|
||||
In this example we are using the OAuth2 "password" flow.
|
||||
|
||||
This is appropriate when we are logging in to our own application, probably with our own frontend.
|
||||
|
||||
Because we can trust it to receive the `username` and `password`, as we control it.
|
||||
|
||||
But if you are building an OAuth2 application that others would connect to (i.e., if you are building an authentication provider equivalent to Facebook, Google, GitHub, etc.) you should use one of the other flows.
|
||||
|
||||
The most common is the implicit flow.
|
||||
|
||||
The most secure is the code flow, but it's more complex to implement as it requires more steps. As it is more complex, many providers end up suggesting the implicit flow.
|
||||
|
||||
/// note
|
||||
|
||||
It's common that each authentication provider names their flows in a different way, to make it part of their brand.
|
||||
|
||||
But in the end, they are implementing the same OAuth2 standard.
|
||||
|
||||
///
|
||||
|
||||
**FastAPI** includes utilities for all these OAuth2 authentication flows in `fastapi.security.oauth2`.
|
||||
|
||||
## `Security` in decorator `dependencies` { #security-in-decorator-dependencies }
|
||||
|
||||
The same way you can define a `list` of `Depends` in the decorator's `dependencies` parameter (as explained in [Dependencies in path operation decorators](../../tutorial/dependencies/dependencies-in-path-operation-decorators.md){.internal-link target=_blank}), you could also use `Security` with `scopes` there.
|
||||
@@ -0,0 +1,346 @@
|
||||
# Settings and Environment Variables { #settings-and-environment-variables }
|
||||
|
||||
In many cases your application could need some external settings or configurations, for example secret keys, database credentials, credentials for email services, etc.
|
||||
|
||||
Most of these settings are variable (can change), like database URLs. And many could be sensitive, like secrets.
|
||||
|
||||
For this reason it's common to provide them in environment variables that are read by the application.
|
||||
|
||||
/// tip
|
||||
|
||||
To understand environment variables you can read [Environment Variables](../environment-variables.md){.internal-link target=_blank}.
|
||||
|
||||
///
|
||||
|
||||
## Types and validation { #types-and-validation }
|
||||
|
||||
These environment variables can only handle text strings, as they are external to Python and have to be compatible with other programs and the rest of the system (and even with different operating systems, as Linux, Windows, macOS).
|
||||
|
||||
That means that any value read in Python from an environment variable will be a `str`, and any conversion to a different type or any validation has to be done in code.
|
||||
|
||||
## Pydantic `Settings` { #pydantic-settings }
|
||||
|
||||
Fortunately, Pydantic provides a great utility to handle these settings coming from environment variables with <a href="https://docs.pydantic.dev/latest/concepts/pydantic_settings/" class="external-link" target="_blank">Pydantic: Settings management</a>.
|
||||
|
||||
### Install `pydantic-settings` { #install-pydantic-settings }
|
||||
|
||||
First, make sure you create your [virtual environment](../virtual-environments.md){.internal-link target=_blank}, activate it, and then install the `pydantic-settings` package:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ pip install pydantic-settings
|
||||
---> 100%
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
It also comes included when you install the `all` extras with:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ pip install "fastapi[all]"
|
||||
---> 100%
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
/// info
|
||||
|
||||
In Pydantic v1 it came included with the main package. Now it is distributed as this independent package so that you can choose to install it or not if you don't need that functionality.
|
||||
|
||||
///
|
||||
|
||||
### Create the `Settings` object { #create-the-settings-object }
|
||||
|
||||
Import `BaseSettings` from Pydantic and create a sub-class, very much like with a Pydantic model.
|
||||
|
||||
The same way as with Pydantic models, you declare class attributes with type annotations, and possibly default values.
|
||||
|
||||
You can use all the same validation features and tools you use for Pydantic models, like different data types and additional validations with `Field()`.
|
||||
|
||||
//// tab | Pydantic v2
|
||||
|
||||
{* ../../docs_src/settings/tutorial001.py hl[2,5:8,11] *}
|
||||
|
||||
////
|
||||
|
||||
//// tab | Pydantic v1
|
||||
|
||||
/// info
|
||||
|
||||
In Pydantic v1 you would import `BaseSettings` directly from `pydantic` instead of from `pydantic_settings`.
|
||||
|
||||
///
|
||||
|
||||
{* ../../docs_src/settings/tutorial001_pv1.py hl[2,5:8,11] *}
|
||||
|
||||
////
|
||||
|
||||
/// tip
|
||||
|
||||
If you want something quick to copy and paste, don't use this example, use the last one below.
|
||||
|
||||
///
|
||||
|
||||
Then, when you create an instance of that `Settings` class (in this case, in the `settings` object), Pydantic will read the environment variables in a case-insensitive way, so, an upper-case variable `APP_NAME` will still be read for the attribute `app_name`.
|
||||
|
||||
Next it will convert and validate the data. So, when you use that `settings` object, you will have data of the types you declared (e.g. `items_per_user` will be an `int`).
|
||||
|
||||
### Use the `settings` { #use-the-settings }
|
||||
|
||||
Then you can use the new `settings` object in your application:
|
||||
|
||||
{* ../../docs_src/settings/tutorial001.py hl[18:20] *}
|
||||
|
||||
### Run the server { #run-the-server }
|
||||
|
||||
Next, you would run the server passing the configurations as environment variables, for example you could set an `ADMIN_EMAIL` and `APP_NAME` with:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ ADMIN_EMAIL="deadpool@example.com" APP_NAME="ChimichangApp" fastapi run main.py
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
/// tip
|
||||
|
||||
To set multiple env vars for a single command just separate them with a space, and put them all before the command.
|
||||
|
||||
///
|
||||
|
||||
And then the `admin_email` setting would be set to `"deadpool@example.com"`.
|
||||
|
||||
The `app_name` would be `"ChimichangApp"`.
|
||||
|
||||
And the `items_per_user` would keep its default value of `50`.
|
||||
|
||||
## Settings in another module { #settings-in-another-module }
|
||||
|
||||
You could put those settings in another module file as you saw in [Bigger Applications - Multiple Files](../tutorial/bigger-applications.md){.internal-link target=_blank}.
|
||||
|
||||
For example, you could have a file `config.py` with:
|
||||
|
||||
{* ../../docs_src/settings/app01/config.py *}
|
||||
|
||||
And then use it in a file `main.py`:
|
||||
|
||||
{* ../../docs_src/settings/app01/main.py hl[3,11:13] *}
|
||||
|
||||
/// tip
|
||||
|
||||
You would also need a file `__init__.py` as you saw in [Bigger Applications - Multiple Files](../tutorial/bigger-applications.md){.internal-link target=_blank}.
|
||||
|
||||
///
|
||||
|
||||
## Settings in a dependency { #settings-in-a-dependency }
|
||||
|
||||
In some occasions it might be useful to provide the settings from a dependency, instead of having a global object with `settings` that is used everywhere.
|
||||
|
||||
This could be especially useful during testing, as it's very easy to override a dependency with your own custom settings.
|
||||
|
||||
### The config file { #the-config-file }
|
||||
|
||||
Coming from the previous example, your `config.py` file could look like:
|
||||
|
||||
{* ../../docs_src/settings/app02/config.py hl[10] *}
|
||||
|
||||
Notice that now we don't create a default instance `settings = Settings()`.
|
||||
|
||||
### The main app file { #the-main-app-file }
|
||||
|
||||
Now we create a dependency that returns a new `config.Settings()`.
|
||||
|
||||
{* ../../docs_src/settings/app02_an_py39/main.py hl[6,12:13] *}
|
||||
|
||||
/// tip
|
||||
|
||||
We'll discuss the `@lru_cache` in a bit.
|
||||
|
||||
For now you can assume `get_settings()` is a normal function.
|
||||
|
||||
///
|
||||
|
||||
And then we can require it from the *path operation function* as a dependency and use it anywhere we need it.
|
||||
|
||||
{* ../../docs_src/settings/app02_an_py39/main.py hl[17,19:21] *}
|
||||
|
||||
### Settings and testing { #settings-and-testing }
|
||||
|
||||
Then it would be very easy to provide a different settings object during testing by creating a dependency override for `get_settings`:
|
||||
|
||||
{* ../../docs_src/settings/app02/test_main.py hl[9:10,13,21] *}
|
||||
|
||||
In the dependency override we set a new value for the `admin_email` when creating the new `Settings` object, and then we return that new object.
|
||||
|
||||
Then we can test that it is used.
|
||||
|
||||
## Reading a `.env` file { #reading-a-env-file }
|
||||
|
||||
If you have many settings that possibly change a lot, maybe in different environments, it might be useful to put them on a file and then read them from it as if they were environment variables.
|
||||
|
||||
This practice is common enough that it has a name, these environment variables are commonly placed in a file `.env`, and the file is called a "dotenv".
|
||||
|
||||
/// tip
|
||||
|
||||
A file starting with a dot (`.`) is a hidden file in Unix-like systems, like Linux and macOS.
|
||||
|
||||
But a dotenv file doesn't really have to have that exact filename.
|
||||
|
||||
///
|
||||
|
||||
Pydantic has support for reading from these types of files using an external library. You can read more at <a href="https://docs.pydantic.dev/latest/concepts/pydantic_settings/#dotenv-env-support" class="external-link" target="_blank">Pydantic Settings: Dotenv (.env) support</a>.
|
||||
|
||||
/// tip
|
||||
|
||||
For this to work, you need to `pip install python-dotenv`.
|
||||
|
||||
///
|
||||
|
||||
### The `.env` file { #the-env-file }
|
||||
|
||||
You could have a `.env` file with:
|
||||
|
||||
```bash
|
||||
ADMIN_EMAIL="deadpool@example.com"
|
||||
APP_NAME="ChimichangApp"
|
||||
```
|
||||
|
||||
### Read settings from `.env` { #read-settings-from-env }
|
||||
|
||||
And then update your `config.py` with:
|
||||
|
||||
//// tab | Pydantic v2
|
||||
|
||||
{* ../../docs_src/settings/app03_an/config.py hl[9] *}
|
||||
|
||||
/// tip
|
||||
|
||||
The `model_config` attribute is used just for Pydantic configuration. You can read more at <a href="https://docs.pydantic.dev/latest/concepts/config/" class="external-link" target="_blank">Pydantic: Concepts: Configuration</a>.
|
||||
|
||||
///
|
||||
|
||||
////
|
||||
|
||||
//// tab | Pydantic v1
|
||||
|
||||
{* ../../docs_src/settings/app03_an/config_pv1.py hl[9:10] *}
|
||||
|
||||
/// tip
|
||||
|
||||
The `Config` class is used just for Pydantic configuration. You can read more at <a href="https://docs.pydantic.dev/1.10/usage/model_config/" class="external-link" target="_blank">Pydantic Model Config</a>.
|
||||
|
||||
///
|
||||
|
||||
////
|
||||
|
||||
/// info
|
||||
|
||||
In Pydantic version 1 the configuration was done in an internal class `Config`, in Pydantic version 2 it's done in an attribute `model_config`. This attribute takes a `dict`, and to get autocompletion and inline errors you can import and use `SettingsConfigDict` to define that `dict`.
|
||||
|
||||
///
|
||||
|
||||
Here we define the config `env_file` inside of your Pydantic `Settings` class, and set the value to the filename with the dotenv file we want to use.
|
||||
|
||||
### Creating the `Settings` only once with `lru_cache` { #creating-the-settings-only-once-with-lru-cache }
|
||||
|
||||
Reading a file from disk is normally a costly (slow) operation, so you probably want to do it only once and then reuse the same settings object, instead of reading it for each request.
|
||||
|
||||
But every time we do:
|
||||
|
||||
```Python
|
||||
Settings()
|
||||
```
|
||||
|
||||
a new `Settings` object would be created, and at creation it would read the `.env` file again.
|
||||
|
||||
If the dependency function was just like:
|
||||
|
||||
```Python
|
||||
def get_settings():
|
||||
return Settings()
|
||||
```
|
||||
|
||||
we would create that object for each request, and we would be reading the `.env` file for each request. ⚠️
|
||||
|
||||
But as we are using the `@lru_cache` decorator on top, the `Settings` object will be created only once, the first time it's called. ✔️
|
||||
|
||||
{* ../../docs_src/settings/app03_an_py39/main.py hl[1,11] *}
|
||||
|
||||
Then for any subsequent call of `get_settings()` in the dependencies for the next requests, instead of executing the internal code of `get_settings()` and creating a new `Settings` object, it will return the same object that was returned on the first call, again and again.
|
||||
|
||||
#### `lru_cache` Technical Details { #lru-cache-technical-details }
|
||||
|
||||
`@lru_cache` modifies the function it decorates to return the same value that was returned the first time, instead of computing it again, executing the code of the function every time.
|
||||
|
||||
So, the function below it will be executed once for each combination of arguments. And then the values returned by each of those combinations of arguments will be used again and again whenever the function is called with exactly the same combination of arguments.
|
||||
|
||||
For example, if you have a function:
|
||||
|
||||
```Python
|
||||
@lru_cache
|
||||
def say_hi(name: str, salutation: str = "Ms."):
|
||||
return f"Hello {salutation} {name}"
|
||||
```
|
||||
|
||||
your program could execute like this:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
||||
participant code as Code
|
||||
participant function as say_hi()
|
||||
participant execute as Execute function
|
||||
|
||||
rect rgba(0, 255, 0, .1)
|
||||
code ->> function: say_hi(name="Camila")
|
||||
function ->> execute: execute function code
|
||||
execute ->> code: return the result
|
||||
end
|
||||
|
||||
rect rgba(0, 255, 255, .1)
|
||||
code ->> function: say_hi(name="Camila")
|
||||
function ->> code: return stored result
|
||||
end
|
||||
|
||||
rect rgba(0, 255, 0, .1)
|
||||
code ->> function: say_hi(name="Rick")
|
||||
function ->> execute: execute function code
|
||||
execute ->> code: return the result
|
||||
end
|
||||
|
||||
rect rgba(0, 255, 0, .1)
|
||||
code ->> function: say_hi(name="Rick", salutation="Mr.")
|
||||
function ->> execute: execute function code
|
||||
execute ->> code: return the result
|
||||
end
|
||||
|
||||
rect rgba(0, 255, 255, .1)
|
||||
code ->> function: say_hi(name="Rick")
|
||||
function ->> code: return stored result
|
||||
end
|
||||
|
||||
rect rgba(0, 255, 255, .1)
|
||||
code ->> function: say_hi(name="Camila")
|
||||
function ->> code: return stored result
|
||||
end
|
||||
```
|
||||
|
||||
In the case of our dependency `get_settings()`, the function doesn't even take any arguments, so it always returns the same value.
|
||||
|
||||
That way, it behaves almost as if it was just a global variable. But as it uses a dependency function, then we can override it easily for testing.
|
||||
|
||||
`@lru_cache` is part of `functools` which is part of Python's standard library, you can read more about it in the <a href="https://docs.python.org/3/library/functools.html#functools.lru_cache" class="external-link" target="_blank">Python docs for `@lru_cache`</a>.
|
||||
|
||||
## Recap { #recap }
|
||||
|
||||
You can use Pydantic Settings to handle the settings or configurations for your application, with all the power of Pydantic models.
|
||||
|
||||
* By using a dependency you can simplify testing.
|
||||
* You can use `.env` files with it.
|
||||
* Using `@lru_cache` lets you avoid reading the dotenv file again and again for each request, while allowing you to override it during testing.
|
||||
@@ -0,0 +1,67 @@
|
||||
# Sub Applications - Mounts { #sub-applications-mounts }
|
||||
|
||||
If you need to have two independent FastAPI applications, with their own independent OpenAPI and their own docs UIs, you can have a main app and "mount" one (or more) sub-application(s).
|
||||
|
||||
## Mounting a **FastAPI** application { #mounting-a-fastapi-application }
|
||||
|
||||
"Mounting" means adding a completely "independent" application in a specific path, that then takes care of handling everything under that path, with the _path operations_ declared in that sub-application.
|
||||
|
||||
### Top-level application { #top-level-application }
|
||||
|
||||
First, create the main, top-level, **FastAPI** application, and its *path operations*:
|
||||
|
||||
{* ../../docs_src/sub_applications/tutorial001.py hl[3, 6:8] *}
|
||||
|
||||
### Sub-application { #sub-application }
|
||||
|
||||
Then, create your sub-application, and its *path operations*.
|
||||
|
||||
This sub-application is just another standard FastAPI application, but this is the one that will be "mounted":
|
||||
|
||||
{* ../../docs_src/sub_applications/tutorial001.py hl[11, 14:16] *}
|
||||
|
||||
### Mount the sub-application { #mount-the-sub-application }
|
||||
|
||||
In your top-level application, `app`, mount the sub-application, `subapi`.
|
||||
|
||||
In this case, it will be mounted at the path `/subapi`:
|
||||
|
||||
{* ../../docs_src/sub_applications/tutorial001.py hl[11, 19] *}
|
||||
|
||||
### Check the automatic API docs { #check-the-automatic-api-docs }
|
||||
|
||||
Now, run the `fastapi` command with your file:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ fastapi dev main.py
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
And open the docs at <a href="http://127.0.0.1:8000/docs" class="external-link" target="_blank">http://127.0.0.1:8000/docs</a>.
|
||||
|
||||
You will see the automatic API docs for the main app, including only its own _path operations_:
|
||||
|
||||
<img src="/img/tutorial/sub-applications/image01.png">
|
||||
|
||||
And then, open the docs for the sub-application, at <a href="http://127.0.0.1:8000/subapi/docs" class="external-link" target="_blank">http://127.0.0.1:8000/subapi/docs</a>.
|
||||
|
||||
You will see the automatic API docs for the sub-application, including only its own _path operations_, all under the correct sub-path prefix `/subapi`:
|
||||
|
||||
<img src="/img/tutorial/sub-applications/image02.png">
|
||||
|
||||
If you try interacting with any of the two user interfaces, they will work correctly, because the browser will be able to talk to each specific app or sub-app.
|
||||
|
||||
### Technical Details: `root_path` { #technical-details-root-path }
|
||||
|
||||
When you mount a sub-application as described above, FastAPI will take care of communicating the mount path for the sub-application using a mechanism from the ASGI specification called a `root_path`.
|
||||
|
||||
That way, the sub-application will know to use that path prefix for the docs UI.
|
||||
|
||||
And the sub-application could also have its own mounted sub-applications and everything would work correctly, because FastAPI handles all these `root_path`s automatically.
|
||||
|
||||
You will learn more about the `root_path` and how to use it explicitly in the section about [Behind a Proxy](behind-a-proxy.md){.internal-link target=_blank}.
|
||||
@@ -0,0 +1,126 @@
|
||||
# Templates { #templates }
|
||||
|
||||
You can use any template engine you want with **FastAPI**.
|
||||
|
||||
A common choice is Jinja2, the same one used by Flask and other tools.
|
||||
|
||||
There are utilities to configure it easily that you can use directly in your **FastAPI** application (provided by Starlette).
|
||||
|
||||
## Install dependencies { #install-dependencies }
|
||||
|
||||
Make sure you create a [virtual environment](../virtual-environments.md){.internal-link target=_blank}, activate it, and install `jinja2`:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ pip install jinja2
|
||||
|
||||
---> 100%
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
## Using `Jinja2Templates` { #using-jinja2templates }
|
||||
|
||||
* Import `Jinja2Templates`.
|
||||
* Create a `templates` object that you can reuse later.
|
||||
* Declare a `Request` parameter in the *path operation* that will return a template.
|
||||
* Use the `templates` you created to render and return a `TemplateResponse`, pass the name of the template, the request object, and a "context" dictionary with key-value pairs to be used inside of the Jinja2 template.
|
||||
|
||||
{* ../../docs_src/templates/tutorial001.py hl[4,11,15:18] *}
|
||||
|
||||
/// note
|
||||
|
||||
Before FastAPI 0.108.0, Starlette 0.29.0, the `name` was the first parameter.
|
||||
|
||||
Also, before that, in previous versions, the `request` object was passed as part of the key-value pairs in the context for Jinja2.
|
||||
|
||||
///
|
||||
|
||||
/// tip
|
||||
|
||||
By declaring `response_class=HTMLResponse` the docs UI will be able to know that the response will be HTML.
|
||||
|
||||
///
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
You could also use `from starlette.templating import Jinja2Templates`.
|
||||
|
||||
**FastAPI** provides the same `starlette.templating` as `fastapi.templating` just as a convenience for you, the developer. But most of the available responses come directly from Starlette. The same with `Request` and `StaticFiles`.
|
||||
|
||||
///
|
||||
|
||||
## Writing templates { #writing-templates }
|
||||
|
||||
Then you can write a template at `templates/item.html` with, for example:
|
||||
|
||||
```jinja hl_lines="7"
|
||||
{!../../docs_src/templates/templates/item.html!}
|
||||
```
|
||||
|
||||
### Template Context Values { #template-context-values }
|
||||
|
||||
In the HTML that contains:
|
||||
|
||||
{% raw %}
|
||||
|
||||
```jinja
|
||||
Item ID: {{ id }}
|
||||
```
|
||||
|
||||
{% endraw %}
|
||||
|
||||
...it will show the `id` taken from the "context" `dict` you passed:
|
||||
|
||||
```Python
|
||||
{"id": id}
|
||||
```
|
||||
|
||||
For example, with an ID of `42`, this would render:
|
||||
|
||||
```html
|
||||
Item ID: 42
|
||||
```
|
||||
|
||||
### Template `url_for` Arguments { #template-url-for-arguments }
|
||||
|
||||
You can also use `url_for()` inside of the template, it takes as arguments the same arguments that would be used by your *path operation function*.
|
||||
|
||||
So, the section with:
|
||||
|
||||
{% raw %}
|
||||
|
||||
```jinja
|
||||
<a href="{{ url_for('read_item', id=id) }}">
|
||||
```
|
||||
|
||||
{% endraw %}
|
||||
|
||||
...will generate a link to the same URL that would be handled by the *path operation function* `read_item(id=id)`.
|
||||
|
||||
For example, with an ID of `42`, this would render:
|
||||
|
||||
```html
|
||||
<a href="/items/42">
|
||||
```
|
||||
|
||||
## Templates and static files { #templates-and-static-files }
|
||||
|
||||
You can also use `url_for()` inside of the template, and use it, for example, with the `StaticFiles` you mounted with the `name="static"`.
|
||||
|
||||
```jinja hl_lines="4"
|
||||
{!../../docs_src/templates/templates/item.html!}
|
||||
```
|
||||
|
||||
In this example, it would link to a CSS file at `static/styles.css` with:
|
||||
|
||||
```CSS hl_lines="4"
|
||||
{!../../docs_src/templates/static/styles.css!}
|
||||
```
|
||||
|
||||
And because you are using `StaticFiles`, that CSS file would be served automatically by your **FastAPI** application at the URL `/static/styles.css`.
|
||||
|
||||
## More details { #more-details }
|
||||
|
||||
For more details, including how to test templates, check <a href="https://www.starlette.dev/templates/" class="external-link" target="_blank">Starlette's docs on templates</a>.
|
||||
@@ -0,0 +1,53 @@
|
||||
# Testing Dependencies with Overrides { #testing-dependencies-with-overrides }
|
||||
|
||||
## Overriding dependencies during testing { #overriding-dependencies-during-testing }
|
||||
|
||||
There are some scenarios where you might want to override a dependency during testing.
|
||||
|
||||
You don't want the original dependency to run (nor any of the sub-dependencies it might have).
|
||||
|
||||
Instead, you want to provide a different dependency that will be used only during tests (possibly only some specific tests), and will provide a value that can be used where the value of the original dependency was used.
|
||||
|
||||
### Use cases: external service { #use-cases-external-service }
|
||||
|
||||
An example could be that you have an external authentication provider that you need to call.
|
||||
|
||||
You send it a token and it returns an authenticated user.
|
||||
|
||||
This provider might be charging you per request, and calling it might take some extra time than if you had a fixed mock user for tests.
|
||||
|
||||
You probably want to test the external provider once, but not necessarily call it for every test that runs.
|
||||
|
||||
In this case, you can override the dependency that calls that provider, and use a custom dependency that returns a mock user, only for your tests.
|
||||
|
||||
### Use the `app.dependency_overrides` attribute { #use-the-app-dependency-overrides-attribute }
|
||||
|
||||
For these cases, your **FastAPI** application has an attribute `app.dependency_overrides`, it is a simple `dict`.
|
||||
|
||||
To override a dependency for testing, you put as a key the original dependency (a function), and as the value, your dependency override (another function).
|
||||
|
||||
And then **FastAPI** will call that override instead of the original dependency.
|
||||
|
||||
{* ../../docs_src/dependency_testing/tutorial001_an_py310.py hl[26:27,30] *}
|
||||
|
||||
/// tip
|
||||
|
||||
You can set a dependency override for a dependency used anywhere in your **FastAPI** application.
|
||||
|
||||
The original dependency could be used in a *path operation function*, a *path operation decorator* (when you don't use the return value), a `.include_router()` call, etc.
|
||||
|
||||
FastAPI will still be able to override it.
|
||||
|
||||
///
|
||||
|
||||
Then you can reset your overrides (remove them) by setting `app.dependency_overrides` to be an empty `dict`:
|
||||
|
||||
```Python
|
||||
app.dependency_overrides = {}
|
||||
```
|
||||
|
||||
/// tip
|
||||
|
||||
If you want to override a dependency only during some tests, you can set the override at the beginning of the test (inside the test function) and reset it at the end (at the end of the test function).
|
||||
|
||||
///
|
||||
@@ -0,0 +1,12 @@
|
||||
# Testing Events: lifespan and startup - shutdown { #testing-events-lifespan-and-startup-shutdown }
|
||||
|
||||
When you need `lifespan` to run in your tests, you can use the `TestClient` with a `with` statement:
|
||||
|
||||
{* ../../docs_src/app_testing/tutorial004.py hl[9:15,18,27:28,30:32,41:43] *}
|
||||
|
||||
|
||||
You can read more details about the ["Running lifespan in tests in the official Starlette documentation site."](https://www.starlette.dev/lifespan/#running-lifespan-in-tests)
|
||||
|
||||
For the deprecated `startup` and `shutdown` events, you can use the `TestClient` as follows:
|
||||
|
||||
{* ../../docs_src/app_testing/tutorial003.py hl[9:12,20:24] *}
|
||||
@@ -0,0 +1,13 @@
|
||||
# Testing WebSockets { #testing-websockets }
|
||||
|
||||
You can use the same `TestClient` to test WebSockets.
|
||||
|
||||
For this, you use the `TestClient` in a `with` statement, connecting to the WebSocket:
|
||||
|
||||
{* ../../docs_src/app_testing/tutorial002.py hl[27:31] *}
|
||||
|
||||
/// note
|
||||
|
||||
For more details, check Starlette's documentation for <a href="https://www.starlette.dev/testclient/#testing-websocket-sessions" class="external-link" target="_blank">testing WebSockets</a>.
|
||||
|
||||
///
|
||||
@@ -0,0 +1,56 @@
|
||||
# Using the Request Directly { #using-the-request-directly }
|
||||
|
||||
Up to now, you have been declaring the parts of the request that you need with their types.
|
||||
|
||||
Taking data from:
|
||||
|
||||
* The path as parameters.
|
||||
* Headers.
|
||||
* Cookies.
|
||||
* etc.
|
||||
|
||||
And by doing so, **FastAPI** is validating that data, converting it and generating documentation for your API automatically.
|
||||
|
||||
But there are situations where you might need to access the `Request` object directly.
|
||||
|
||||
## Details about the `Request` object { #details-about-the-request-object }
|
||||
|
||||
As **FastAPI** is actually **Starlette** underneath, with a layer of several tools on top, you can use Starlette's <a href="https://www.starlette.dev/requests/" class="external-link" target="_blank">`Request`</a> object directly when you need to.
|
||||
|
||||
It would also mean that if you get data from the `Request` object directly (for example, read the body) it won't be validated, converted or documented (with OpenAPI, for the automatic API user interface) by FastAPI.
|
||||
|
||||
Although any other parameter declared normally (for example, the body with a Pydantic model) would still be validated, converted, annotated, etc.
|
||||
|
||||
But there are specific cases where it's useful to get the `Request` object.
|
||||
|
||||
## Use the `Request` object directly { #use-the-request-object-directly }
|
||||
|
||||
Let's imagine you want to get the client's IP address/host inside of your *path operation function*.
|
||||
|
||||
For that you need to access the request directly.
|
||||
|
||||
{* ../../docs_src/using_request_directly/tutorial001.py hl[1,7:8] *}
|
||||
|
||||
By declaring a *path operation function* parameter with the type being the `Request` **FastAPI** will know to pass the `Request` in that parameter.
|
||||
|
||||
/// tip
|
||||
|
||||
Note that in this case, we are declaring a path parameter beside the request parameter.
|
||||
|
||||
So, the path parameter will be extracted, validated, converted to the specified type and annotated with OpenAPI.
|
||||
|
||||
The same way, you can declare any other parameter as normally, and additionally, get the `Request` too.
|
||||
|
||||
///
|
||||
|
||||
## `Request` documentation { #request-documentation }
|
||||
|
||||
You can read more details about the <a href="https://www.starlette.dev/requests/" class="external-link" target="_blank">`Request` object in the official Starlette documentation site</a>.
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
You could also use `from starlette.requests import Request`.
|
||||
|
||||
**FastAPI** provides it directly just as a convenience for you, the developer. But it comes directly from Starlette.
|
||||
|
||||
///
|
||||
@@ -0,0 +1,186 @@
|
||||
# WebSockets { #websockets }
|
||||
|
||||
You can use <a href="https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API" class="external-link" target="_blank">WebSockets</a> with **FastAPI**.
|
||||
|
||||
## Install `websockets` { #install-websockets }
|
||||
|
||||
Make sure you create a [virtual environment](../virtual-environments.md){.internal-link target=_blank}, activate it, and install `websockets` (a Python library that makes it easy to use the "WebSocket" protocol):
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ pip install websockets
|
||||
|
||||
---> 100%
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
## WebSockets client { #websockets-client }
|
||||
|
||||
### In production { #in-production }
|
||||
|
||||
In your production system, you probably have a frontend created with a modern framework like React, Vue.js or Angular.
|
||||
|
||||
And to communicate using WebSockets with your backend you would probably use your frontend's utilities.
|
||||
|
||||
Or you might have a native mobile application that communicates with your WebSocket backend directly, in native code.
|
||||
|
||||
Or you might have any other way to communicate with the WebSocket endpoint.
|
||||
|
||||
---
|
||||
|
||||
But for this example, we'll use a very simple HTML document with some JavaScript, all inside a long string.
|
||||
|
||||
This, of course, is not optimal and you wouldn't use it for production.
|
||||
|
||||
In production you would have one of the options above.
|
||||
|
||||
But it's the simplest way to focus on the server-side of WebSockets and have a working example:
|
||||
|
||||
{* ../../docs_src/websockets/tutorial001.py hl[2,6:38,41:43] *}
|
||||
|
||||
## Create a `websocket` { #create-a-websocket }
|
||||
|
||||
In your **FastAPI** application, create a `websocket`:
|
||||
|
||||
{* ../../docs_src/websockets/tutorial001.py hl[1,46:47] *}
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
You could also use `from starlette.websockets import WebSocket`.
|
||||
|
||||
**FastAPI** provides the same `WebSocket` directly just as a convenience for you, the developer. But it comes directly from Starlette.
|
||||
|
||||
///
|
||||
|
||||
## Await for messages and send messages { #await-for-messages-and-send-messages }
|
||||
|
||||
In your WebSocket route you can `await` for messages and send messages.
|
||||
|
||||
{* ../../docs_src/websockets/tutorial001.py hl[48:52] *}
|
||||
|
||||
You can receive and send binary, text, and JSON data.
|
||||
|
||||
## Try it { #try-it }
|
||||
|
||||
If your file is named `main.py`, run your application with:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ fastapi dev main.py
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
Open your browser at <a href="http://127.0.0.1:8000" class="external-link" target="_blank">http://127.0.0.1:8000</a>.
|
||||
|
||||
You will see a simple page like:
|
||||
|
||||
<img src="/img/tutorial/websockets/image01.png">
|
||||
|
||||
You can type messages in the input box, and send them:
|
||||
|
||||
<img src="/img/tutorial/websockets/image02.png">
|
||||
|
||||
And your **FastAPI** application with WebSockets will respond back:
|
||||
|
||||
<img src="/img/tutorial/websockets/image03.png">
|
||||
|
||||
You can send (and receive) many messages:
|
||||
|
||||
<img src="/img/tutorial/websockets/image04.png">
|
||||
|
||||
And all of them will use the same WebSocket connection.
|
||||
|
||||
## Using `Depends` and others { #using-depends-and-others }
|
||||
|
||||
In WebSocket endpoints you can import from `fastapi` and use:
|
||||
|
||||
* `Depends`
|
||||
* `Security`
|
||||
* `Cookie`
|
||||
* `Header`
|
||||
* `Path`
|
||||
* `Query`
|
||||
|
||||
They work the same way as for other FastAPI endpoints/*path operations*:
|
||||
|
||||
{* ../../docs_src/websockets/tutorial002_an_py310.py hl[68:69,82] *}
|
||||
|
||||
/// info
|
||||
|
||||
As this is a WebSocket it doesn't really make sense to raise an `HTTPException`, instead we raise a `WebSocketException`.
|
||||
|
||||
You can use a closing code from the <a href="https://tools.ietf.org/html/rfc6455#section-7.4.1" class="external-link" target="_blank">valid codes defined in the specification</a>.
|
||||
|
||||
///
|
||||
|
||||
### Try the WebSockets with dependencies { #try-the-websockets-with-dependencies }
|
||||
|
||||
If your file is named `main.py`, run your application with:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ fastapi dev main.py
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
Open your browser at <a href="http://127.0.0.1:8000" class="external-link" target="_blank">http://127.0.0.1:8000</a>.
|
||||
|
||||
There you can set:
|
||||
|
||||
* The "Item ID", used in the path.
|
||||
* The "Token" used as a query parameter.
|
||||
|
||||
/// tip
|
||||
|
||||
Notice that the query `token` will be handled by a dependency.
|
||||
|
||||
///
|
||||
|
||||
With that you can connect the WebSocket and then send and receive messages:
|
||||
|
||||
<img src="/img/tutorial/websockets/image05.png">
|
||||
|
||||
## Handling disconnections and multiple clients { #handling-disconnections-and-multiple-clients }
|
||||
|
||||
When a WebSocket connection is closed, the `await websocket.receive_text()` will raise a `WebSocketDisconnect` exception, which you can then catch and handle like in this example.
|
||||
|
||||
{* ../../docs_src/websockets/tutorial003_py39.py hl[79:81] *}
|
||||
|
||||
To try it out:
|
||||
|
||||
* Open the app with several browser tabs.
|
||||
* Write messages from them.
|
||||
* Then close one of the tabs.
|
||||
|
||||
That will raise the `WebSocketDisconnect` exception, and all the other clients will receive a message like:
|
||||
|
||||
```
|
||||
Client #1596980209979 left the chat
|
||||
```
|
||||
|
||||
/// tip
|
||||
|
||||
The app above is a minimal and simple example to demonstrate how to handle and broadcast messages to several WebSocket connections.
|
||||
|
||||
But keep in mind that, as everything is handled in memory, in a single list, it will only work while the process is running, and will only work with a single process.
|
||||
|
||||
If you need something easy to integrate with FastAPI but that is more robust, supported by Redis, PostgreSQL or others, check <a href="https://github.com/encode/broadcaster" class="external-link" target="_blank">encode/broadcaster</a>.
|
||||
|
||||
///
|
||||
|
||||
## More info { #more-info }
|
||||
|
||||
To learn more about the options, check Starlette's documentation for:
|
||||
|
||||
* <a href="https://www.starlette.dev/websockets/" class="external-link" target="_blank">The `WebSocket` class</a>.
|
||||
* <a href="https://www.starlette.dev/endpoints/#websocketendpoint" class="external-link" target="_blank">Class-based WebSocket handling</a>.
|
||||
@@ -0,0 +1,35 @@
|
||||
# Including WSGI - Flask, Django, others { #including-wsgi-flask-django-others }
|
||||
|
||||
You can mount WSGI applications as you saw with [Sub Applications - Mounts](sub-applications.md){.internal-link target=_blank}, [Behind a Proxy](behind-a-proxy.md){.internal-link target=_blank}.
|
||||
|
||||
For that, you can use the `WSGIMiddleware` and use it to wrap your WSGI application, for example, Flask, Django, etc.
|
||||
|
||||
## Using `WSGIMiddleware` { #using-wsgimiddleware }
|
||||
|
||||
You need to import `WSGIMiddleware`.
|
||||
|
||||
Then wrap the WSGI (e.g. Flask) app with the middleware.
|
||||
|
||||
And then mount that under a path.
|
||||
|
||||
{* ../../docs_src/wsgi/tutorial001.py hl[2:3,3] *}
|
||||
|
||||
## Check it { #check-it }
|
||||
|
||||
Now, every request under the path `/v1/` will be handled by the Flask application.
|
||||
|
||||
And the rest will be handled by **FastAPI**.
|
||||
|
||||
If you run it and go to <a href="http://localhost:8000/v1/" class="external-link" target="_blank">http://localhost:8000/v1/</a> you will see the response from Flask:
|
||||
|
||||
```txt
|
||||
Hello, World from Flask!
|
||||
```
|
||||
|
||||
And if you go to <a href="http://localhost:8000/v2" class="external-link" target="_blank">http://localhost:8000/v2</a> you will see the response from FastAPI:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"message": "Hello World"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,485 @@
|
||||
# Alternatives, Inspiration and Comparisons { #alternatives-inspiration-and-comparisons }
|
||||
|
||||
What inspired **FastAPI**, how it compares to alternatives and what it learned from them.
|
||||
|
||||
## Intro { #intro }
|
||||
|
||||
**FastAPI** wouldn't exist if not for the previous work of others.
|
||||
|
||||
There have been many tools created before that have helped inspire its creation.
|
||||
|
||||
I have been avoiding the creation of a new framework for several years. First I tried to solve all the features covered by **FastAPI** using many different frameworks, plug-ins, and tools.
|
||||
|
||||
But at some point, there was no other option than creating something that provided all these features, taking the best ideas from previous tools, and combining them in the best way possible, using language features that weren't even available before (Python 3.6+ type hints).
|
||||
|
||||
## Previous tools { #previous-tools }
|
||||
|
||||
### <a href="https://www.djangoproject.com/" class="external-link" target="_blank">Django</a> { #django }
|
||||
|
||||
It's the most popular Python framework and is widely trusted. It is used to build systems like Instagram.
|
||||
|
||||
It's relatively tightly coupled with relational databases (like MySQL or PostgreSQL), so, having a NoSQL database (like Couchbase, MongoDB, Cassandra, etc) as the main store engine is not very easy.
|
||||
|
||||
It was created to generate the HTML in the backend, not to create APIs used by a modern frontend (like React, Vue.js and Angular) or by other systems (like <abbr title="Internet of Things">IoT</abbr> devices) communicating with it.
|
||||
|
||||
### <a href="https://www.django-rest-framework.org/" class="external-link" target="_blank">Django REST Framework</a> { #django-rest-framework }
|
||||
|
||||
Django REST framework was created to be a flexible toolkit for building Web APIs using Django underneath, to improve its API capabilities.
|
||||
|
||||
It is used by many companies including Mozilla, Red Hat and Eventbrite.
|
||||
|
||||
It was one of the first examples of **automatic API documentation**, and this was specifically one of the first ideas that inspired "the search for" **FastAPI**.
|
||||
|
||||
/// note
|
||||
|
||||
Django REST Framework was created by Tom Christie. The same creator of Starlette and Uvicorn, on which **FastAPI** is based.
|
||||
|
||||
///
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Have an automatic API documentation web user interface.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://flask.palletsprojects.com" class="external-link" target="_blank">Flask</a> { #flask }
|
||||
|
||||
Flask is a "microframework", it doesn't include database integrations nor many of the things that come by default in Django.
|
||||
|
||||
This simplicity and flexibility allow doing things like using NoSQL databases as the main data storage system.
|
||||
|
||||
As it is very simple, it's relatively intuitive to learn, although the documentation gets somewhat technical at some points.
|
||||
|
||||
It is also commonly used for other applications that don't necessarily need a database, user management, or any of the many features that come pre-built in Django. Although many of these features can be added with plug-ins.
|
||||
|
||||
This decoupling of parts, and being a "microframework" that could be extended to cover exactly what is needed was a key feature that I wanted to keep.
|
||||
|
||||
Given the simplicity of Flask, it seemed like a good match for building APIs. The next thing to find was a "Django REST Framework" for Flask.
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Be a micro-framework. Making it easy to mix and match the tools and parts needed.
|
||||
|
||||
Have a simple and easy to use routing system.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://requests.readthedocs.io" class="external-link" target="_blank">Requests</a> { #requests }
|
||||
|
||||
**FastAPI** is not actually an alternative to **Requests**. Their scope is very different.
|
||||
|
||||
It would actually be common to use Requests *inside* of a FastAPI application.
|
||||
|
||||
But still, FastAPI got quite some inspiration from Requests.
|
||||
|
||||
**Requests** is a library to *interact* with APIs (as a client), while **FastAPI** is a library to *build* APIs (as a server).
|
||||
|
||||
They are, more or less, at opposite ends, complementing each other.
|
||||
|
||||
Requests has a very simple and intuitive design, it's very easy to use, with sensible defaults. But at the same time, it's very powerful and customizable.
|
||||
|
||||
That's why, as said in the official website:
|
||||
|
||||
> Requests is one of the most downloaded Python packages of all time
|
||||
|
||||
The way you use it is very simple. For example, to do a `GET` request, you would write:
|
||||
|
||||
```Python
|
||||
response = requests.get("http://example.com/some/url")
|
||||
```
|
||||
|
||||
The FastAPI counterpart API *path operation* could look like:
|
||||
|
||||
```Python hl_lines="1"
|
||||
@app.get("/some/url")
|
||||
def read_url():
|
||||
return {"message": "Hello World"}
|
||||
```
|
||||
|
||||
See the similarities in `requests.get(...)` and `@app.get(...)`.
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
* Have a simple and intuitive API.
|
||||
* Use HTTP method names (operations) directly, in a straightforward and intuitive way.
|
||||
* Have sensible defaults, but powerful customizations.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://swagger.io/" class="external-link" target="_blank">Swagger</a> / <a href="https://github.com/OAI/OpenAPI-Specification/" class="external-link" target="_blank">OpenAPI</a> { #swagger-openapi }
|
||||
|
||||
The main feature I wanted from Django REST Framework was the automatic API documentation.
|
||||
|
||||
Then I found that there was a standard to document APIs, using JSON (or YAML, an extension of JSON) called Swagger.
|
||||
|
||||
And there was a web user interface for Swagger APIs already created. So, being able to generate Swagger documentation for an API would allow using this web user interface automatically.
|
||||
|
||||
At some point, Swagger was given to the Linux Foundation, to be renamed OpenAPI.
|
||||
|
||||
That's why when talking about version 2.0 it's common to say "Swagger", and for version 3+ "OpenAPI".
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Adopt and use an open standard for API specifications, instead of a custom schema.
|
||||
|
||||
And integrate standards-based user interface tools:
|
||||
|
||||
* <a href="https://github.com/swagger-api/swagger-ui" class="external-link" target="_blank">Swagger UI</a>
|
||||
* <a href="https://github.com/Rebilly/ReDoc" class="external-link" target="_blank">ReDoc</a>
|
||||
|
||||
These two were chosen for being fairly popular and stable, but doing a quick search, you could find dozens of alternative user interfaces for OpenAPI (that you can use with **FastAPI**).
|
||||
|
||||
///
|
||||
|
||||
### Flask REST frameworks { #flask-rest-frameworks }
|
||||
|
||||
There are several Flask REST frameworks, but after investing the time and work into investigating them, I found that many are discontinued or abandoned, with several standing issues that made them unfit.
|
||||
|
||||
### <a href="https://marshmallow.readthedocs.io/en/stable/" class="external-link" target="_blank">Marshmallow</a> { #marshmallow }
|
||||
|
||||
One of the main features needed by API systems is data "<abbr title="also called marshalling, conversion">serialization</abbr>" which is taking data from the code (Python) and converting it into something that can be sent through the network. For example, converting an object containing data from a database into a JSON object. Converting `datetime` objects into strings, etc.
|
||||
|
||||
Another big feature needed by APIs is data validation, making sure that the data is valid, given certain parameters. For example, that some field is an `int`, and not some random string. This is especially useful for incoming data.
|
||||
|
||||
Without a data validation system, you would have to do all the checks by hand, in code.
|
||||
|
||||
These features are what Marshmallow was built to provide. It is a great library, and I have used it a lot before.
|
||||
|
||||
But it was created before there existed Python type hints. So, to define every <abbr title="the definition of how data should be formed">schema</abbr> you need to use specific utils and classes provided by Marshmallow.
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Use code to define "schemas" that provide data types and validation, automatically.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://webargs.readthedocs.io/en/latest/" class="external-link" target="_blank">Webargs</a> { #webargs }
|
||||
|
||||
Another big feature required by APIs is <abbr title="reading and converting to Python data">parsing</abbr> data from incoming requests.
|
||||
|
||||
Webargs is a tool that was made to provide that on top of several frameworks, including Flask.
|
||||
|
||||
It uses Marshmallow underneath to do the data validation. And it was created by the same developers.
|
||||
|
||||
It's a great tool and I have used it a lot too, before having **FastAPI**.
|
||||
|
||||
/// info
|
||||
|
||||
Webargs was created by the same Marshmallow developers.
|
||||
|
||||
///
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Have automatic validation of incoming request data.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://apispec.readthedocs.io/en/stable/" class="external-link" target="_blank">APISpec</a> { #apispec }
|
||||
|
||||
Marshmallow and Webargs provide validation, parsing and serialization as plug-ins.
|
||||
|
||||
But documentation is still missing. Then APISpec was created.
|
||||
|
||||
It is a plug-in for many frameworks (and there's a plug-in for Starlette too).
|
||||
|
||||
The way it works is that you write the definition of the schema using YAML format inside the docstring of each function handling a route.
|
||||
|
||||
And it generates OpenAPI schemas.
|
||||
|
||||
That's how it works in Flask, Starlette, Responder, etc.
|
||||
|
||||
But then, we have again the problem of having a micro-syntax, inside of a Python string (a big YAML).
|
||||
|
||||
The editor can't help much with that. And if we modify parameters or Marshmallow schemas and forget to also modify that YAML docstring, the generated schema would be obsolete.
|
||||
|
||||
/// info
|
||||
|
||||
APISpec was created by the same Marshmallow developers.
|
||||
|
||||
///
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Support the open standard for APIs, OpenAPI.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://flask-apispec.readthedocs.io/en/latest/" class="external-link" target="_blank">Flask-apispec</a> { #flask-apispec }
|
||||
|
||||
It's a Flask plug-in, that ties together Webargs, Marshmallow and APISpec.
|
||||
|
||||
It uses the information from Webargs and Marshmallow to automatically generate OpenAPI schemas, using APISpec.
|
||||
|
||||
It's a great tool, very underrated. It should be way more popular than many Flask plug-ins out there. It might be due to its documentation being too concise and abstract.
|
||||
|
||||
This solved having to write YAML (another syntax) inside of Python docstrings.
|
||||
|
||||
This combination of Flask, Flask-apispec with Marshmallow and Webargs was my favorite backend stack until building **FastAPI**.
|
||||
|
||||
Using it led to the creation of several Flask full-stack generators. These are the main stacks I (and several external teams) have been using up to now:
|
||||
|
||||
* <a href="https://github.com/tiangolo/full-stack" class="external-link" target="_blank">https://github.com/tiangolo/full-stack</a>
|
||||
* <a href="https://github.com/tiangolo/full-stack-flask-couchbase" class="external-link" target="_blank">https://github.com/tiangolo/full-stack-flask-couchbase</a>
|
||||
* <a href="https://github.com/tiangolo/full-stack-flask-couchdb" class="external-link" target="_blank">https://github.com/tiangolo/full-stack-flask-couchdb</a>
|
||||
|
||||
And these same full-stack generators were the base of the [**FastAPI** Project Generators](project-generation.md){.internal-link target=_blank}.
|
||||
|
||||
/// info
|
||||
|
||||
Flask-apispec was created by the same Marshmallow developers.
|
||||
|
||||
///
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Generate the OpenAPI schema automatically, from the same code that defines serialization and validation.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://nestjs.com/" class="external-link" target="_blank">NestJS</a> (and <a href="https://angular.io/" class="external-link" target="_blank">Angular</a>) { #nestjs-and-angular }
|
||||
|
||||
This isn't even Python, NestJS is a JavaScript (TypeScript) NodeJS framework inspired by Angular.
|
||||
|
||||
It achieves something somewhat similar to what can be done with Flask-apispec.
|
||||
|
||||
It has an integrated dependency injection system, inspired by Angular 2. It requires pre-registering the "injectables" (like all the other dependency injection systems I know), so, it adds to the verbosity and code repetition.
|
||||
|
||||
As the parameters are described with TypeScript types (similar to Python type hints), editor support is quite good.
|
||||
|
||||
But as TypeScript data is not preserved after compilation to JavaScript, it cannot rely on the types to define validation, serialization and documentation at the same time. Due to this and some design decisions, to get validation, serialization and automatic schema generation, it's needed to add decorators in many places. So, it becomes quite verbose.
|
||||
|
||||
It can't handle nested models very well. So, if the JSON body in the request is a JSON object that has inner fields that in turn are nested JSON objects, it cannot be properly documented and validated.
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Use Python types to have great editor support.
|
||||
|
||||
Have a powerful dependency injection system. Find a way to minimize code repetition.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://sanic.readthedocs.io/en/latest/" class="external-link" target="_blank">Sanic</a> { #sanic }
|
||||
|
||||
It was one of the first extremely fast Python frameworks based on `asyncio`. It was made to be very similar to Flask.
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
It used <a href="https://github.com/MagicStack/uvloop" class="external-link" target="_blank">`uvloop`</a> instead of the default Python `asyncio` loop. That's what made it so fast.
|
||||
|
||||
It clearly inspired Uvicorn and Starlette, that are currently faster than Sanic in open benchmarks.
|
||||
|
||||
///
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Find a way to have a crazy performance.
|
||||
|
||||
That's why **FastAPI** is based on Starlette, as it is the fastest framework available (tested by third-party benchmarks).
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://falconframework.org/" class="external-link" target="_blank">Falcon</a> { #falcon }
|
||||
|
||||
Falcon is another high performance Python framework, it is designed to be minimal, and work as the foundation of other frameworks like Hug.
|
||||
|
||||
It is designed to have functions that receive two parameters, one "request" and one "response". Then you "read" parts from the request, and "write" parts to the response. Because of this design, it is not possible to declare request parameters and bodies with standard Python type hints as function parameters.
|
||||
|
||||
So, data validation, serialization, and documentation, have to be done in code, not automatically. Or they have to be implemented as a framework on top of Falcon, like Hug. This same distinction happens in other frameworks that are inspired by Falcon's design, of having one request object and one response object as parameters.
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Find ways to get great performance.
|
||||
|
||||
Along with Hug (as Hug is based on Falcon) inspired **FastAPI** to declare a `response` parameter in functions.
|
||||
|
||||
Although in FastAPI it's optional, and is used mainly to set headers, cookies, and alternative status codes.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://moltenframework.com/" class="external-link" target="_blank">Molten</a> { #molten }
|
||||
|
||||
I discovered Molten in the first stages of building **FastAPI**. And it has quite similar ideas:
|
||||
|
||||
* Based on Python type hints.
|
||||
* Validation and documentation from these types.
|
||||
* Dependency Injection system.
|
||||
|
||||
It doesn't use a data validation, serialization and documentation third-party library like Pydantic, it has its own. So, these data type definitions would not be reusable as easily.
|
||||
|
||||
It requires a little bit more verbose configurations. And as it is based on WSGI (instead of ASGI), it is not designed to take advantage of the high performance provided by tools like Uvicorn, Starlette and Sanic.
|
||||
|
||||
The dependency injection system requires pre-registration of the dependencies and the dependencies are solved based on the declared types. So, it's not possible to declare more than one "component" that provides a certain type.
|
||||
|
||||
Routes are declared in a single place, using functions declared in other places (instead of using decorators that can be placed right on top of the function that handles the endpoint). This is closer to how Django does it than to how Flask (and Starlette) does it. It separates in the code things that are relatively tightly coupled.
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Define extra validations for data types using the "default" value of model attributes. This improves editor support, and it was not available in Pydantic before.
|
||||
|
||||
This actually inspired updating parts of Pydantic, to support the same validation declaration style (all this functionality is now already available in Pydantic).
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://github.com/hugapi/hug" class="external-link" target="_blank">Hug</a> { #hug }
|
||||
|
||||
Hug was one of the first frameworks to implement the declaration of API parameter types using Python type hints. This was a great idea that inspired other tools to do the same.
|
||||
|
||||
It used custom types in its declarations instead of standard Python types, but it was still a huge step forward.
|
||||
|
||||
It also was one of the first frameworks to generate a custom schema declaring the whole API in JSON.
|
||||
|
||||
It was not based on a standard like OpenAPI and JSON Schema. So it wouldn't be straightforward to integrate it with other tools, like Swagger UI. But again, it was a very innovative idea.
|
||||
|
||||
It has an interesting, uncommon feature: using the same framework, it's possible to create APIs and also CLIs.
|
||||
|
||||
As it is based on the previous standard for synchronous Python web frameworks (WSGI), it can't handle Websockets and other things, although it still has high performance too.
|
||||
|
||||
/// info
|
||||
|
||||
Hug was created by Timothy Crosley, the same creator of <a href="https://github.com/timothycrosley/isort" class="external-link" target="_blank">`isort`</a>, a great tool to automatically sort imports in Python files.
|
||||
|
||||
///
|
||||
|
||||
/// check | Ideas inspiring **FastAPI**
|
||||
|
||||
Hug inspired parts of APIStar, and was one of the tools I found most promising, alongside APIStar.
|
||||
|
||||
Hug helped inspiring **FastAPI** to use Python type hints to declare parameters, and to generate a schema defining the API automatically.
|
||||
|
||||
Hug inspired **FastAPI** to declare a `response` parameter in functions to set headers and cookies.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://github.com/encode/apistar" class="external-link" target="_blank">APIStar</a> (<= 0.5) { #apistar-0-5 }
|
||||
|
||||
Right before deciding to build **FastAPI** I found **APIStar** server. It had almost everything I was looking for and had a great design.
|
||||
|
||||
It was one of the first implementations of a framework using Python type hints to declare parameters and requests that I ever saw (before NestJS and Molten). I found it more or less at the same time as Hug. But APIStar used the OpenAPI standard.
|
||||
|
||||
It had automatic data validation, data serialization and OpenAPI schema generation based on the same type hints in several places.
|
||||
|
||||
Body schema definitions didn't use the same Python type hints like Pydantic, it was a bit more similar to Marshmallow, so, editor support wouldn't be as good, but still, APIStar was the best available option.
|
||||
|
||||
It had the best performance benchmarks at the time (only surpassed by Starlette).
|
||||
|
||||
At first, it didn't have an automatic API documentation web UI, but I knew I could add Swagger UI to it.
|
||||
|
||||
It had a dependency injection system. It required pre-registration of components, as other tools discussed above. But still, it was a great feature.
|
||||
|
||||
I was never able to use it in a full project, as it didn't have security integration, so, I couldn't replace all the features I was having with the full-stack generators based on Flask-apispec. I had in my backlog of projects to create a pull request adding that functionality.
|
||||
|
||||
But then, the project's focus shifted.
|
||||
|
||||
It was no longer an API web framework, as the creator needed to focus on Starlette.
|
||||
|
||||
Now APIStar is a set of tools to validate OpenAPI specifications, not a web framework.
|
||||
|
||||
/// info
|
||||
|
||||
APIStar was created by Tom Christie. The same guy that created:
|
||||
|
||||
* Django REST Framework
|
||||
* Starlette (in which **FastAPI** is based)
|
||||
* Uvicorn (used by Starlette and **FastAPI**)
|
||||
|
||||
///
|
||||
|
||||
/// check | Inspired **FastAPI** to
|
||||
|
||||
Exist.
|
||||
|
||||
The idea of declaring multiple things (data validation, serialization and documentation) with the same Python types, that at the same time provided great editor support, was something I considered a brilliant idea.
|
||||
|
||||
And after searching for a long time for a similar framework and testing many different alternatives, APIStar was the best option available.
|
||||
|
||||
Then APIStar stopped to exist as a server and Starlette was created, and was a new better foundation for such a system. That was the final inspiration to build **FastAPI**.
|
||||
|
||||
I consider **FastAPI** a "spiritual successor" to APIStar, while improving and increasing the features, typing system, and other parts, based on the learnings from all these previous tools.
|
||||
|
||||
///
|
||||
|
||||
## Used by **FastAPI** { #used-by-fastapi }
|
||||
|
||||
### <a href="https://docs.pydantic.dev/" class="external-link" target="_blank">Pydantic</a> { #pydantic }
|
||||
|
||||
Pydantic is a library to define data validation, serialization and documentation (using JSON Schema) based on Python type hints.
|
||||
|
||||
That makes it extremely intuitive.
|
||||
|
||||
It is comparable to Marshmallow. Although it's faster than Marshmallow in benchmarks. And as it is based on the same Python type hints, the editor support is great.
|
||||
|
||||
/// check | **FastAPI** uses it to
|
||||
|
||||
Handle all the data validation, data serialization and automatic model documentation (based on JSON Schema).
|
||||
|
||||
**FastAPI** then takes that JSON Schema data and puts it in OpenAPI, apart from all the other things it does.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://www.starlette.dev/" class="external-link" target="_blank">Starlette</a> { #starlette }
|
||||
|
||||
Starlette is a lightweight <abbr title="The new standard for building asynchronous Python web applications">ASGI</abbr> framework/toolkit, which is ideal for building high-performance asyncio services.
|
||||
|
||||
It is very simple and intuitive. It's designed to be easily extensible, and have modular components.
|
||||
|
||||
It has:
|
||||
|
||||
* Seriously impressive performance.
|
||||
* WebSocket support.
|
||||
* In-process background tasks.
|
||||
* Startup and shutdown events.
|
||||
* Test client built on HTTPX.
|
||||
* CORS, GZip, Static Files, Streaming responses.
|
||||
* Session and Cookie support.
|
||||
* 100% test coverage.
|
||||
* 100% type annotated codebase.
|
||||
* Few hard dependencies.
|
||||
|
||||
Starlette is currently the fastest Python framework tested. Only surpassed by Uvicorn, which is not a framework, but a server.
|
||||
|
||||
Starlette provides all the basic web microframework functionality.
|
||||
|
||||
But it doesn't provide automatic data validation, serialization or documentation.
|
||||
|
||||
That's one of the main things that **FastAPI** adds on top, all based on Python type hints (using Pydantic). That, plus the dependency injection system, security utilities, OpenAPI schema generation, etc.
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
ASGI is a new "standard" being developed by Django core team members. It is still not a "Python standard" (a PEP), although they are in the process of doing that.
|
||||
|
||||
Nevertheless, it is already being used as a "standard" by several tools. This greatly improves interoperability, as you could switch Uvicorn for any other ASGI server (like Daphne or Hypercorn), or you could add ASGI compatible tools, like `python-socketio`.
|
||||
|
||||
///
|
||||
|
||||
/// check | **FastAPI** uses it to
|
||||
|
||||
Handle all the core web parts. Adding features on top.
|
||||
|
||||
The class `FastAPI` itself inherits directly from the class `Starlette`.
|
||||
|
||||
So, anything that you can do with Starlette, you can do it directly with **FastAPI**, as it is basically Starlette on steroids.
|
||||
|
||||
///
|
||||
|
||||
### <a href="https://www.uvicorn.dev/" class="external-link" target="_blank">Uvicorn</a> { #uvicorn }
|
||||
|
||||
Uvicorn is a lightning-fast ASGI server, built on uvloop and httptools.
|
||||
|
||||
It is not a web framework, but a server. For example, it doesn't provide tools for routing by paths. That's something that a framework like Starlette (or **FastAPI**) would provide on top.
|
||||
|
||||
It is the recommended server for Starlette and **FastAPI**.
|
||||
|
||||
/// check | **FastAPI** recommends it as
|
||||
|
||||
The main web server to run **FastAPI** applications.
|
||||
|
||||
You can also use the `--workers` command line option to have an asynchronous multi-process server.
|
||||
|
||||
Check more details in the [Deployment](deployment/index.md){.internal-link target=_blank} section.
|
||||
|
||||
///
|
||||
|
||||
## Benchmarks and speed { #benchmarks-and-speed }
|
||||
|
||||
To understand, compare, and see the difference between Uvicorn, Starlette and FastAPI, check the section about [Benchmarks](benchmarks.md){.internal-link target=_blank}.
|
||||
@@ -0,0 +1,444 @@
|
||||
# Concurrency and async / await { #concurrency-and-async-await }
|
||||
|
||||
Details about the `async def` syntax for *path operation functions* and some background about asynchronous code, concurrency, and parallelism.
|
||||
|
||||
## In a hurry? { #in-a-hurry }
|
||||
|
||||
<abbr title="too long; didn't read"><strong>TL;DR:</strong></abbr>
|
||||
|
||||
If you are using third party libraries that tell you to call them with `await`, like:
|
||||
|
||||
```Python
|
||||
results = await some_library()
|
||||
```
|
||||
|
||||
Then, declare your *path operation functions* with `async def` like:
|
||||
|
||||
```Python hl_lines="2"
|
||||
@app.get('/')
|
||||
async def read_results():
|
||||
results = await some_library()
|
||||
return results
|
||||
```
|
||||
|
||||
/// note
|
||||
|
||||
You can only use `await` inside of functions created with `async def`.
|
||||
|
||||
///
|
||||
|
||||
---
|
||||
|
||||
If you are using a third party library that communicates with something (a database, an API, the file system, etc.) and doesn't have support for using `await`, (this is currently the case for most database libraries), then declare your *path operation functions* as normally, with just `def`, like:
|
||||
|
||||
```Python hl_lines="2"
|
||||
@app.get('/')
|
||||
def results():
|
||||
results = some_library()
|
||||
return results
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
If your application (somehow) doesn't have to communicate with anything else and wait for it to respond, use `async def`, even if you don't need to use `await` inside.
|
||||
|
||||
---
|
||||
|
||||
If you just don't know, use normal `def`.
|
||||
|
||||
---
|
||||
|
||||
**Note**: You can mix `def` and `async def` in your *path operation functions* as much as you need and define each one using the best option for you. FastAPI will do the right thing with them.
|
||||
|
||||
Anyway, in any of the cases above, FastAPI will still work asynchronously and be extremely fast.
|
||||
|
||||
But by following the steps above, it will be able to do some performance optimizations.
|
||||
|
||||
## Technical Details { #technical-details }
|
||||
|
||||
Modern versions of Python have support for **"asynchronous code"** using something called **"coroutines"**, with **`async` and `await`** syntax.
|
||||
|
||||
Let's see that phrase by parts in the sections below:
|
||||
|
||||
* **Asynchronous Code**
|
||||
* **`async` and `await`**
|
||||
* **Coroutines**
|
||||
|
||||
## Asynchronous Code { #asynchronous-code }
|
||||
|
||||
Asynchronous code just means that the language 💬 has a way to tell the computer / program 🤖 that at some point in the code, it 🤖 will have to wait for *something else* to finish somewhere else. Let's say that *something else* is called "slow-file" 📝.
|
||||
|
||||
So, during that time, the computer can go and do some other work, while "slow-file" 📝 finishes.
|
||||
|
||||
Then the computer / program 🤖 will come back every time it has a chance because it's waiting again, or whenever it 🤖 finished all the work it had at that point. And it 🤖 will see if any of the tasks it was waiting for have already finished, doing whatever it had to do.
|
||||
|
||||
Next, it 🤖 takes the first task to finish (let's say, our "slow-file" 📝) and continues whatever it had to do with it.
|
||||
|
||||
That "wait for something else" normally refers to <abbr title="Input and Output">I/O</abbr> operations that are relatively "slow" (compared to the speed of the processor and the RAM memory), like waiting for:
|
||||
|
||||
* the data from the client to be sent through the network
|
||||
* the data sent by your program to be received by the client through the network
|
||||
* the contents of a file in the disk to be read by the system and given to your program
|
||||
* the contents your program gave to the system to be written to disk
|
||||
* a remote API operation
|
||||
* a database operation to finish
|
||||
* a database query to return the results
|
||||
* etc.
|
||||
|
||||
As the execution time is consumed mostly by waiting for <abbr title="Input and Output">I/O</abbr> operations, they call them "I/O bound" operations.
|
||||
|
||||
It's called "asynchronous" because the computer / program doesn't have to be "synchronized" with the slow task, waiting for the exact moment that the task finishes, while doing nothing, to be able to take the task result and continue the work.
|
||||
|
||||
Instead of that, by being an "asynchronous" system, once finished, the task can wait in line a little bit (some microseconds) for the computer / program to finish whatever it went to do, and then come back to take the results and continue working with them.
|
||||
|
||||
For "synchronous" (contrary to "asynchronous") they commonly also use the term "sequential", because the computer / program follows all the steps in sequence before switching to a different task, even if those steps involve waiting.
|
||||
|
||||
### Concurrency and Burgers { #concurrency-and-burgers }
|
||||
|
||||
This idea of **asynchronous** code described above is also sometimes called **"concurrency"**. It is different from **"parallelism"**.
|
||||
|
||||
**Concurrency** and **parallelism** both relate to "different things happening more or less at the same time".
|
||||
|
||||
But the details between *concurrency* and *parallelism* are quite different.
|
||||
|
||||
To see the difference, imagine the following story about burgers:
|
||||
|
||||
### Concurrent Burgers { #concurrent-burgers }
|
||||
|
||||
You go with your crush to get fast food, you stand in line while the cashier takes the orders from the people in front of you. 😍
|
||||
|
||||
<img src="/img/async/concurrent-burgers/concurrent-burgers-01.png" class="illustration">
|
||||
|
||||
Then it's your turn, you place your order of 2 very fancy burgers for your crush and you. 🍔🍔
|
||||
|
||||
<img src="/img/async/concurrent-burgers/concurrent-burgers-02.png" class="illustration">
|
||||
|
||||
The cashier says something to the cook in the kitchen so they know they have to prepare your burgers (even though they are currently preparing the ones for the previous clients).
|
||||
|
||||
<img src="/img/async/concurrent-burgers/concurrent-burgers-03.png" class="illustration">
|
||||
|
||||
You pay. 💸
|
||||
|
||||
The cashier gives you the number of your turn.
|
||||
|
||||
<img src="/img/async/concurrent-burgers/concurrent-burgers-04.png" class="illustration">
|
||||
|
||||
While you are waiting, you go with your crush and pick a table, you sit and talk with your crush for a long time (as your burgers are very fancy and take some time to prepare).
|
||||
|
||||
As you are sitting at the table with your crush, while you wait for the burgers, you can spend that time admiring how awesome, cute and smart your crush is ✨😍✨.
|
||||
|
||||
<img src="/img/async/concurrent-burgers/concurrent-burgers-05.png" class="illustration">
|
||||
|
||||
While waiting and talking to your crush, from time to time, you check the number displayed on the counter to see if it's your turn already.
|
||||
|
||||
Then at some point, it finally is your turn. You go to the counter, get your burgers and come back to the table.
|
||||
|
||||
<img src="/img/async/concurrent-burgers/concurrent-burgers-06.png" class="illustration">
|
||||
|
||||
You and your crush eat the burgers and have a nice time. ✨
|
||||
|
||||
<img src="/img/async/concurrent-burgers/concurrent-burgers-07.png" class="illustration">
|
||||
|
||||
/// info
|
||||
|
||||
Beautiful illustrations by <a href="https://www.instagram.com/ketrinadrawsalot" class="external-link" target="_blank">Ketrina Thompson</a>. 🎨
|
||||
|
||||
///
|
||||
|
||||
---
|
||||
|
||||
Imagine you are the computer / program 🤖 in that story.
|
||||
|
||||
While you are at the line, you are just idle 😴, waiting for your turn, not doing anything very "productive". But the line is fast because the cashier is only taking the orders (not preparing them), so that's fine.
|
||||
|
||||
Then, when it's your turn, you do actual "productive" work, you process the menu, decide what you want, get your crush's choice, pay, check that you give the correct bill or card, check that you are charged correctly, check that the order has the correct items, etc.
|
||||
|
||||
But then, even though you still don't have your burgers, your work with the cashier is "on pause" ⏸, because you have to wait 🕙 for your burgers to be ready.
|
||||
|
||||
But as you go away from the counter and sit at the table with a number for your turn, you can switch 🔀 your attention to your crush, and "work" ⏯ 🤓 on that. Then you are again doing something very "productive" as is flirting with your crush 😍.
|
||||
|
||||
Then the cashier 💁 says "I'm finished with doing the burgers" by putting your number on the counter's display, but you don't jump like crazy immediately when the displayed number changes to your turn number. You know no one will steal your burgers because you have the number of your turn, and they have theirs.
|
||||
|
||||
So you wait for your crush to finish the story (finish the current work ⏯ / task being processed 🤓), smile gently and say that you are going for the burgers ⏸.
|
||||
|
||||
Then you go to the counter 🔀, to the initial task that is now finished ⏯, pick the burgers, say thanks and take them to the table. That finishes that step / task of interaction with the counter ⏹. That in turn, creates a new task, of "eating burgers" 🔀 ⏯, but the previous one of "getting burgers" is finished ⏹.
|
||||
|
||||
### Parallel Burgers { #parallel-burgers }
|
||||
|
||||
Now let's imagine these aren't "Concurrent Burgers", but "Parallel Burgers".
|
||||
|
||||
You go with your crush to get parallel fast food.
|
||||
|
||||
You stand in line while several (let's say 8) cashiers that at the same time are cooks take the orders from the people in front of you.
|
||||
|
||||
Everyone before you is waiting for their burgers to be ready before leaving the counter because each of the 8 cashiers goes and prepares the burger right away before getting the next order.
|
||||
|
||||
<img src="/img/async/parallel-burgers/parallel-burgers-01.png" class="illustration">
|
||||
|
||||
Then it's finally your turn, you place your order of 2 very fancy burgers for your crush and you.
|
||||
|
||||
You pay 💸.
|
||||
|
||||
<img src="/img/async/parallel-burgers/parallel-burgers-02.png" class="illustration">
|
||||
|
||||
The cashier goes to the kitchen.
|
||||
|
||||
You wait, standing in front of the counter 🕙, so that no one else takes your burgers before you do, as there are no numbers for turns.
|
||||
|
||||
<img src="/img/async/parallel-burgers/parallel-burgers-03.png" class="illustration">
|
||||
|
||||
As you and your crush are busy not letting anyone get in front of you and take your burgers whenever they arrive, you cannot pay attention to your crush. 😞
|
||||
|
||||
This is "synchronous" work, you are "synchronized" with the cashier/cook 👨🍳. You have to wait 🕙 and be there at the exact moment that the cashier/cook 👨🍳 finishes the burgers and gives them to you, or otherwise, someone else might take them.
|
||||
|
||||
<img src="/img/async/parallel-burgers/parallel-burgers-04.png" class="illustration">
|
||||
|
||||
Then your cashier/cook 👨🍳 finally comes back with your burgers, after a long time waiting 🕙 there in front of the counter.
|
||||
|
||||
<img src="/img/async/parallel-burgers/parallel-burgers-05.png" class="illustration">
|
||||
|
||||
You take your burgers and go to the table with your crush.
|
||||
|
||||
You just eat them, and you are done. ⏹
|
||||
|
||||
<img src="/img/async/parallel-burgers/parallel-burgers-06.png" class="illustration">
|
||||
|
||||
There was not much talk or flirting as most of the time was spent waiting 🕙 in front of the counter. 😞
|
||||
|
||||
/// info
|
||||
|
||||
Beautiful illustrations by <a href="https://www.instagram.com/ketrinadrawsalot" class="external-link" target="_blank">Ketrina Thompson</a>. 🎨
|
||||
|
||||
///
|
||||
|
||||
---
|
||||
|
||||
In this scenario of the parallel burgers, you are a computer / program 🤖 with two processors (you and your crush), both waiting 🕙 and dedicating their attention ⏯ to be "waiting on the counter" 🕙 for a long time.
|
||||
|
||||
The fast food store has 8 processors (cashiers/cooks). While the concurrent burgers store might have had only 2 (one cashier and one cook).
|
||||
|
||||
But still, the final experience is not the best. 😞
|
||||
|
||||
---
|
||||
|
||||
This would be the parallel equivalent story for burgers. 🍔
|
||||
|
||||
For a more "real life" example of this, imagine a bank.
|
||||
|
||||
Up to recently, most of the banks had multiple cashiers 👨💼👨💼👨💼👨💼 and a big line 🕙🕙🕙🕙🕙🕙🕙🕙.
|
||||
|
||||
All of the cashiers doing all the work with one client after the other 👨💼⏯.
|
||||
|
||||
And you have to wait 🕙 in the line for a long time or you lose your turn.
|
||||
|
||||
You probably wouldn't want to take your crush 😍 with you to run errands at the bank 🏦.
|
||||
|
||||
### Burger Conclusion { #burger-conclusion }
|
||||
|
||||
In this scenario of "fast food burgers with your crush", as there is a lot of waiting 🕙, it makes a lot more sense to have a concurrent system ⏸🔀⏯.
|
||||
|
||||
This is the case for most of the web applications.
|
||||
|
||||
Many, many users, but your server is waiting 🕙 for their not-so-good connection to send their requests.
|
||||
|
||||
And then waiting 🕙 again for the responses to come back.
|
||||
|
||||
This "waiting" 🕙 is measured in microseconds, but still, summing it all, it's a lot of waiting in the end.
|
||||
|
||||
That's why it makes a lot of sense to use asynchronous ⏸🔀⏯ code for web APIs.
|
||||
|
||||
This kind of asynchronicity is what made NodeJS popular (even though NodeJS is not parallel) and that's the strength of Go as a programming language.
|
||||
|
||||
And that's the same level of performance you get with **FastAPI**.
|
||||
|
||||
And as you can have parallelism and asynchronicity at the same time, you get higher performance than most of the tested NodeJS frameworks and on par with Go, which is a compiled language closer to C <a href="https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=query&l=zijmkf-1" class="external-link" target="_blank">(all thanks to Starlette)</a>.
|
||||
|
||||
### Is concurrency better than parallelism? { #is-concurrency-better-than-parallelism }
|
||||
|
||||
Nope! That's not the moral of the story.
|
||||
|
||||
Concurrency is different than parallelism. And it is better on **specific** scenarios that involve a lot of waiting. Because of that, it generally is a lot better than parallelism for web application development. But not for everything.
|
||||
|
||||
So, to balance that out, imagine the following short story:
|
||||
|
||||
> You have to clean a big, dirty house.
|
||||
|
||||
*Yep, that's the whole story*.
|
||||
|
||||
---
|
||||
|
||||
There's no waiting 🕙 anywhere, just a lot of work to be done, on multiple places of the house.
|
||||
|
||||
You could have turns as in the burgers example, first the living room, then the kitchen, but as you are not waiting 🕙 for anything, just cleaning and cleaning, the turns wouldn't affect anything.
|
||||
|
||||
It would take the same amount of time to finish with or without turns (concurrency) and you would have done the same amount of work.
|
||||
|
||||
But in this case, if you could bring the 8 ex-cashier/cooks/now-cleaners, and each one of them (plus you) could take a zone of the house to clean it, you could do all the work in **parallel**, with the extra help, and finish much sooner.
|
||||
|
||||
In this scenario, each one of the cleaners (including you) would be a processor, doing their part of the job.
|
||||
|
||||
And as most of the execution time is taken by actual work (instead of waiting), and the work in a computer is done by a <abbr title="Central Processing Unit">CPU</abbr>, they call these problems "CPU bound".
|
||||
|
||||
---
|
||||
|
||||
Common examples of CPU bound operations are things that require complex math processing.
|
||||
|
||||
For example:
|
||||
|
||||
* **Audio** or **image processing**.
|
||||
* **Computer vision**: an image is composed of millions of pixels, each pixel has 3 values / colors, processing that normally requires computing something on those pixels, all at the same time.
|
||||
* **Machine Learning**: it normally requires lots of "matrix" and "vector" multiplications. Think of a huge spreadsheet with numbers and multiplying all of them together at the same time.
|
||||
* **Deep Learning**: this is a sub-field of Machine Learning, so, the same applies. It's just that there is not a single spreadsheet of numbers to multiply, but a huge set of them, and in many cases, you use a special processor to build and / or use those models.
|
||||
|
||||
### Concurrency + Parallelism: Web + Machine Learning { #concurrency-parallelism-web-machine-learning }
|
||||
|
||||
With **FastAPI** you can take advantage of concurrency that is very common for web development (the same main attraction of NodeJS).
|
||||
|
||||
But you can also exploit the benefits of parallelism and multiprocessing (having multiple processes running in parallel) for **CPU bound** workloads like those in Machine Learning systems.
|
||||
|
||||
That, plus the simple fact that Python is the main language for **Data Science**, Machine Learning and especially Deep Learning, make FastAPI a very good match for Data Science / Machine Learning web APIs and applications (among many others).
|
||||
|
||||
To see how to achieve this parallelism in production see the section about [Deployment](deployment/index.md){.internal-link target=_blank}.
|
||||
|
||||
## `async` and `await` { #async-and-await }
|
||||
|
||||
Modern versions of Python have a very intuitive way to define asynchronous code. This makes it look just like normal "sequential" code and do the "awaiting" for you at the right moments.
|
||||
|
||||
When there is an operation that will require waiting before giving the results and has support for these new Python features, you can code it like:
|
||||
|
||||
```Python
|
||||
burgers = await get_burgers(2)
|
||||
```
|
||||
|
||||
The key here is the `await`. It tells Python that it has to wait ⏸ for `get_burgers(2)` to finish doing its thing 🕙 before storing the results in `burgers`. With that, Python will know that it can go and do something else 🔀 ⏯ in the meanwhile (like receiving another request).
|
||||
|
||||
For `await` to work, it has to be inside a function that supports this asynchronicity. To do that, you just declare it with `async def`:
|
||||
|
||||
```Python hl_lines="1"
|
||||
async def get_burgers(number: int):
|
||||
# Do some asynchronous stuff to create the burgers
|
||||
return burgers
|
||||
```
|
||||
|
||||
...instead of `def`:
|
||||
|
||||
```Python hl_lines="2"
|
||||
# This is not asynchronous
|
||||
def get_sequential_burgers(number: int):
|
||||
# Do some sequential stuff to create the burgers
|
||||
return burgers
|
||||
```
|
||||
|
||||
With `async def`, Python knows that, inside that function, it has to be aware of `await` expressions, and that it can "pause" ⏸ the execution of that function and go do something else 🔀 before coming back.
|
||||
|
||||
When you want to call an `async def` function, you have to "await" it. So, this won't work:
|
||||
|
||||
```Python
|
||||
# This won't work, because get_burgers was defined with: async def
|
||||
burgers = get_burgers(2)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
So, if you are using a library that tells you that you can call it with `await`, you need to create the *path operation functions* that uses it with `async def`, like in:
|
||||
|
||||
```Python hl_lines="2-3"
|
||||
@app.get('/burgers')
|
||||
async def read_burgers():
|
||||
burgers = await get_burgers(2)
|
||||
return burgers
|
||||
```
|
||||
|
||||
### More technical details { #more-technical-details }
|
||||
|
||||
You might have noticed that `await` can only be used inside of functions defined with `async def`.
|
||||
|
||||
But at the same time, functions defined with `async def` have to be "awaited". So, functions with `async def` can only be called inside of functions defined with `async def` too.
|
||||
|
||||
So, about the egg and the chicken, how do you call the first `async` function?
|
||||
|
||||
If you are working with **FastAPI** you don't have to worry about that, because that "first" function will be your *path operation function*, and FastAPI will know how to do the right thing.
|
||||
|
||||
But if you want to use `async` / `await` without FastAPI, you can do it as well.
|
||||
|
||||
### Write your own async code { #write-your-own-async-code }
|
||||
|
||||
Starlette (and **FastAPI**) are based on <a href="https://anyio.readthedocs.io/en/stable/" class="external-link" target="_blank">AnyIO</a>, which makes it compatible with both Python's standard library <a href="https://docs.python.org/3/library/asyncio-task.html" class="external-link" target="_blank">asyncio</a> and <a href="https://trio.readthedocs.io/en/stable/" class="external-link" target="_blank">Trio</a>.
|
||||
|
||||
In particular, you can directly use <a href="https://anyio.readthedocs.io/en/stable/" class="external-link" target="_blank">AnyIO</a> for your advanced concurrency use cases that require more advanced patterns in your own code.
|
||||
|
||||
And even if you were not using FastAPI, you could also write your own async applications with <a href="https://anyio.readthedocs.io/en/stable/" class="external-link" target="_blank">AnyIO</a> to be highly compatible and get its benefits (e.g. *structured concurrency*).
|
||||
|
||||
I created another library on top of AnyIO, as a thin layer on top, to improve a bit the type annotations and get better **autocompletion**, **inline errors**, etc. It also has a friendly introduction and tutorial to help you **understand** and write **your own async code**: <a href="https://asyncer.tiangolo.com/" class="external-link" target="_blank">Asyncer</a>. It would be particularly useful if you need to **combine async code with regular** (blocking/synchronous) code.
|
||||
|
||||
### Other forms of asynchronous code { #other-forms-of-asynchronous-code }
|
||||
|
||||
This style of using `async` and `await` is relatively new in the language.
|
||||
|
||||
But it makes working with asynchronous code a lot easier.
|
||||
|
||||
This same syntax (or almost identical) was also included recently in modern versions of JavaScript (in Browser and NodeJS).
|
||||
|
||||
But before that, handling asynchronous code was quite more complex and difficult.
|
||||
|
||||
In previous versions of Python, you could have used threads or <a href="https://www.gevent.org/" class="external-link" target="_blank">Gevent</a>. But the code is way more complex to understand, debug, and think about.
|
||||
|
||||
In previous versions of NodeJS / Browser JavaScript, you would have used "callbacks". Which leads to "callback hell".
|
||||
|
||||
## Coroutines { #coroutines }
|
||||
|
||||
**Coroutine** is just the very fancy term for the thing returned by an `async def` function. Python knows that it is something like a function, that it can start and that it will end at some point, but that it might be paused ⏸ internally too, whenever there is an `await` inside of it.
|
||||
|
||||
But all this functionality of using asynchronous code with `async` and `await` is many times summarized as using "coroutines". It is comparable to the main key feature of Go, the "Goroutines".
|
||||
|
||||
## Conclusion { #conclusion }
|
||||
|
||||
Let's see the same phrase from above:
|
||||
|
||||
> Modern versions of Python have support for **"asynchronous code"** using something called **"coroutines"**, with **`async` and `await`** syntax.
|
||||
|
||||
That should make more sense now. ✨
|
||||
|
||||
All that is what powers FastAPI (through Starlette) and what makes it have such an impressive performance.
|
||||
|
||||
## Very Technical Details { #very-technical-details }
|
||||
|
||||
/// warning
|
||||
|
||||
You can probably skip this.
|
||||
|
||||
These are very technical details of how **FastAPI** works underneath.
|
||||
|
||||
If you have quite some technical knowledge (coroutines, threads, blocking, etc.) and are curious about how FastAPI handles `async def` vs normal `def`, go ahead.
|
||||
|
||||
///
|
||||
|
||||
### Path operation functions { #path-operation-functions }
|
||||
|
||||
When you declare a *path operation function* with normal `def` instead of `async def`, it is run in an external threadpool that is then awaited, instead of being called directly (as it would block the server).
|
||||
|
||||
If you are coming from another async framework that does not work in the way described above and you are used to defining trivial compute-only *path operation functions* with plain `def` for a tiny performance gain (about 100 nanoseconds), please note that in **FastAPI** the effect would be quite opposite. In these cases, it's better to use `async def` unless your *path operation functions* use code that performs blocking <abbr title="Input/Output: disk reading or writing, network communications.">I/O</abbr>.
|
||||
|
||||
Still, in both situations, chances are that **FastAPI** will [still be faster](index.md#performance){.internal-link target=_blank} than (or at least comparable to) your previous framework.
|
||||
|
||||
### Dependencies { #dependencies }
|
||||
|
||||
The same applies for [dependencies](tutorial/dependencies/index.md){.internal-link target=_blank}. If a dependency is a standard `def` function instead of `async def`, it is run in the external threadpool.
|
||||
|
||||
### Sub-dependencies { #sub-dependencies }
|
||||
|
||||
You can have multiple dependencies and [sub-dependencies](tutorial/dependencies/sub-dependencies.md){.internal-link target=_blank} requiring each other (as parameters of the function definitions), some of them might be created with `async def` and some with normal `def`. It would still work, and the ones created with normal `def` would be called on an external thread (from the threadpool) instead of being "awaited".
|
||||
|
||||
### Other utility functions { #other-utility-functions }
|
||||
|
||||
Any other utility function that you call directly can be created with normal `def` or `async def` and FastAPI won't affect the way you call it.
|
||||
|
||||
This is in contrast to the functions that FastAPI calls for you: *path operation functions* and dependencies.
|
||||
|
||||
If your utility function is a normal function with `def`, it will be called directly (as you write it in your code), not in a threadpool, if the function is created with `async def` then you should `await` for that function when you call it in your code.
|
||||
|
||||
---
|
||||
|
||||
Again, these are very technical details that would probably be useful if you came searching for them.
|
||||
|
||||
Otherwise, you should be good with the guidelines from the section above: <a href="#in-a-hurry">In a hurry?</a>.
|
||||
@@ -0,0 +1,34 @@
|
||||
# Benchmarks { #benchmarks }
|
||||
|
||||
Independent TechEmpower benchmarks show **FastAPI** applications running under Uvicorn as <a href="https://www.techempower.com/benchmarks/#section=test&runid=7464e520-0dc2-473d-bd34-dbdfd7e85911&hw=ph&test=query&l=zijzen-7" class="external-link" target="_blank">one of the fastest Python frameworks available</a>, only below Starlette and Uvicorn themselves (used internally by FastAPI).
|
||||
|
||||
But when checking benchmarks and comparisons you should keep the following in mind.
|
||||
|
||||
## Benchmarks and speed { #benchmarks-and-speed }
|
||||
|
||||
When you check the benchmarks, it is common to see several tools of different types compared as equivalent.
|
||||
|
||||
Specifically, to see Uvicorn, Starlette and FastAPI compared together (among many other tools).
|
||||
|
||||
The simpler the problem solved by the tool, the better performance it will get. And most of the benchmarks don't test the additional features provided by the tool.
|
||||
|
||||
The hierarchy is like:
|
||||
|
||||
* **Uvicorn**: an ASGI server
|
||||
* **Starlette**: (uses Uvicorn) a web microframework
|
||||
* **FastAPI**: (uses Starlette) an API microframework with several additional features for building APIs, with data validation, etc.
|
||||
|
||||
* **Uvicorn**:
|
||||
* Will have the best performance, as it doesn't have much extra code apart from the server itself.
|
||||
* You wouldn't write an application in Uvicorn directly. That would mean that your code would have to include more or less, at least, all the code provided by Starlette (or **FastAPI**). And if you did that, your final application would have the same overhead as having used a framework and minimizing your app code and bugs.
|
||||
* If you are comparing Uvicorn, compare it against Daphne, Hypercorn, uWSGI, etc. Application servers.
|
||||
* **Starlette**:
|
||||
* Will have the next best performance, after Uvicorn. In fact, Starlette uses Uvicorn to run. So, it probably can only get "slower" than Uvicorn by having to execute more code.
|
||||
* But it provides you the tools to build simple web applications, with routing based on paths, etc.
|
||||
* If you are comparing Starlette, compare it against Sanic, Flask, Django, etc. Web frameworks (or microframeworks).
|
||||
* **FastAPI**:
|
||||
* The same way that Starlette uses Uvicorn and cannot be faster than it, **FastAPI** uses Starlette, so it cannot be faster than it.
|
||||
* FastAPI provides more features on top of Starlette. Features that you almost always need when building APIs, like data validation and serialization. And by using it, you get automatic documentation for free (the automatic documentation doesn't even add overhead to running applications, it is generated on startup).
|
||||
* If you didn't use FastAPI and used Starlette directly (or another tool, like Sanic, Flask, Responder, etc) you would have to implement all the data validation and serialization yourself. So, your final application would still have the same overhead as if it was built using FastAPI. And in many cases, this data validation and serialization is the biggest amount of code written in applications.
|
||||
* So, by using FastAPI you are saving development time, bugs, lines of code, and you would probably get the same performance (or better) you would if you didn't use it (as you would have to implement it all in your code).
|
||||
* If you are comparing FastAPI, compare it against a web application framework (or set of tools) that provides data validation, serialization and documentation, like Flask-apispec, NestJS, Molten, etc. Frameworks with integrated automatic data validation, serialization and documentation.
|
||||
@@ -0,0 +1,452 @@
|
||||
# Development - Contributing
|
||||
|
||||
First, you might want to see the basic ways to [help FastAPI and get help](help-fastapi.md){.internal-link target=_blank}.
|
||||
|
||||
## Developing
|
||||
|
||||
If you already cloned the <a href="https://github.com/fastapi/fastapi" class="external-link" target="_blank">fastapi repository</a> and you want to deep dive in the code, here are some guidelines to set up your environment.
|
||||
|
||||
### Virtual environment
|
||||
|
||||
Follow the instructions to create and activate a [virtual environment](virtual-environments.md){.internal-link target=_blank} for the internal code of `fastapi`.
|
||||
|
||||
### Install requirements
|
||||
|
||||
After activating the environment, install the required packages:
|
||||
|
||||
//// tab | `pip`
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ pip install -r requirements.txt
|
||||
|
||||
---> 100%
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
////
|
||||
|
||||
//// tab | `uv`
|
||||
|
||||
If you have <a href="https://github.com/astral-sh/uv" class="external-link" target="_blank">`uv`</a>:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ uv pip install -r requirements.txt
|
||||
|
||||
---> 100%
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
////
|
||||
|
||||
It will install all the dependencies and your local FastAPI in your local environment.
|
||||
|
||||
### Using your local FastAPI
|
||||
|
||||
If you create a Python file that imports and uses FastAPI, and run it with the Python from your local environment, it will use your cloned local FastAPI source code.
|
||||
|
||||
And if you update that local FastAPI source code when you run that Python file again, it will use the fresh version of FastAPI you just edited.
|
||||
|
||||
That way, you don't have to "install" your local version to be able to test every change.
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
This only happens when you install using this included `requirements.txt` instead of running `pip install fastapi` directly.
|
||||
|
||||
That is because inside the `requirements.txt` file, the local version of FastAPI is marked to be installed in "editable" mode, with the `-e` option.
|
||||
|
||||
///
|
||||
|
||||
### Format the code
|
||||
|
||||
There is a script that you can run that will format and clean all your code:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ bash scripts/format.sh
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
It will also auto-sort all your imports.
|
||||
|
||||
## Tests
|
||||
|
||||
There is a script that you can run locally to test all the code and generate coverage reports in HTML:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ bash scripts/test-cov-html.sh
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
This command generates a directory `./htmlcov/`, if you open the file `./htmlcov/index.html` in your browser, you can explore interactively the regions of code that are covered by the tests, and notice if there is any region missing.
|
||||
|
||||
## Docs
|
||||
|
||||
First, make sure you set up your environment as described above, that will install all the requirements.
|
||||
|
||||
### Docs live
|
||||
|
||||
During local development, there is a script that builds the site and checks for any changes, live-reloading:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ python ./scripts/docs.py live
|
||||
|
||||
<span style="color: green;">[INFO]</span> Serving on http://127.0.0.1:8008
|
||||
<span style="color: green;">[INFO]</span> Start watching changes
|
||||
<span style="color: green;">[INFO]</span> Start detecting changes
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
It will serve the documentation on `http://127.0.0.1:8008`.
|
||||
|
||||
That way, you can edit the documentation/source files and see the changes live.
|
||||
|
||||
/// tip
|
||||
|
||||
Alternatively, you can perform the same steps that scripts does manually.
|
||||
|
||||
Go into the language directory, for the main docs in English it's at `docs/en/`:
|
||||
|
||||
```console
|
||||
$ cd docs/en/
|
||||
```
|
||||
|
||||
Then run `mkdocs` in that directory:
|
||||
|
||||
```console
|
||||
$ mkdocs serve --dev-addr 127.0.0.1:8008
|
||||
```
|
||||
|
||||
///
|
||||
|
||||
#### Typer CLI (optional)
|
||||
|
||||
The instructions here show you how to use the script at `./scripts/docs.py` with the `python` program directly.
|
||||
|
||||
But you can also use <a href="https://typer.tiangolo.com/typer-cli/" class="external-link" target="_blank">Typer CLI</a>, and you will get autocompletion in your terminal for the commands after installing completion.
|
||||
|
||||
If you install Typer CLI, you can install completion with:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ typer --install-completion
|
||||
|
||||
zsh completion installed in /home/user/.bashrc.
|
||||
Completion will take effect once you restart the terminal.
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
### Docs Structure
|
||||
|
||||
The documentation uses <a href="https://www.mkdocs.org/" class="external-link" target="_blank">MkDocs</a>.
|
||||
|
||||
And there are extra tools/scripts in place to handle translations in `./scripts/docs.py`.
|
||||
|
||||
/// tip
|
||||
|
||||
You don't need to see the code in `./scripts/docs.py`, you just use it in the command line.
|
||||
|
||||
///
|
||||
|
||||
All the documentation is in Markdown format in the directory `./docs/en/`.
|
||||
|
||||
Many of the tutorials have blocks of code.
|
||||
|
||||
In most of the cases, these blocks of code are actual complete applications that can be run as is.
|
||||
|
||||
In fact, those blocks of code are not written inside the Markdown, they are Python files in the `./docs_src/` directory.
|
||||
|
||||
And those Python files are included/injected in the documentation when generating the site.
|
||||
|
||||
### Docs for tests
|
||||
|
||||
Most of the tests actually run against the example source files in the documentation.
|
||||
|
||||
This helps to make sure that:
|
||||
|
||||
* The documentation is up-to-date.
|
||||
* The documentation examples can be run as is.
|
||||
* Most of the features are covered by the documentation, ensured by test coverage.
|
||||
|
||||
#### Apps and docs at the same time
|
||||
|
||||
If you run the examples with, e.g.:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ fastapi dev tutorial001.py
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
as Uvicorn by default will use the port `8000`, the documentation on port `8008` won't clash.
|
||||
|
||||
### Translations
|
||||
|
||||
/// warning | Attention
|
||||
|
||||
**Update on Translations**
|
||||
|
||||
We're updating the way we handle documentation translations.
|
||||
|
||||
Until now, we invited community members to translate pages via pull requests, which were then reviewed by at least two native speakers. While this has helped bring FastAPI to many more users, we’ve also run into several challenges - some languages have only a few translated pages, others are outdated and hard to maintain over time.
|
||||
To improve this, we’re working on automation tools 🤖 to manage translations more efficiently. Once ready, documentation will be machine-translated and still reviewed by at least two native speakers ✅ before publishing. This will allow us to keep translations up-to-date while reducing the review burden on maintainers.
|
||||
|
||||
What’s changing now:
|
||||
|
||||
* 🚫 We’re no longer accepting new community-submitted translation PRs.
|
||||
|
||||
* ⏳ Existing open PRs will be reviewed and can still be merged if completed within the next 3 weeks (since July 11 2025).
|
||||
|
||||
* 🌐 In the future, we will only support languages where at least three active native speakers are available to review and maintain translations.
|
||||
|
||||
This transition will help us keep translations more consistent and timely while better supporting our contributors 🙌. Thank you to everyone who has contributed so far — your help has been invaluable! 💖
|
||||
|
||||
///
|
||||
|
||||
|
||||
Help with translations is VERY MUCH appreciated! And it can't be done without the help from the community. 🌎 🚀
|
||||
|
||||
Here are the steps to help with translations.
|
||||
|
||||
#### Tips and guidelines
|
||||
|
||||
* Check the currently <a href="https://github.com/fastapi/fastapi/pulls" class="external-link" target="_blank">existing pull requests</a> for your language. You can filter the pull requests by the ones with the label for your language. For example, for Spanish, the label is <a href="https://github.com/fastapi/fastapi/pulls?q=is%3Aopen+sort%3Aupdated-desc+label%3Alang-es+label%3Aawaiting-review" class="external-link" target="_blank">`lang-es`</a>.
|
||||
|
||||
* Review those pull requests, requesting changes or approving them. For the languages I don't speak, I'll wait for several others to review the translation before merging.
|
||||
|
||||
/// tip
|
||||
|
||||
You can <a href="https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request" class="external-link" target="_blank">add comments with change suggestions</a> to existing pull requests.
|
||||
|
||||
Check the docs about <a href="https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews" class="external-link" target="_blank">adding a pull request review</a> to approve it or request changes.
|
||||
|
||||
///
|
||||
|
||||
* Check if there's a <a href="https://github.com/fastapi/fastapi/discussions/categories/translations" class="external-link" target="_blank">GitHub Discussion</a> to coordinate translations for your language. You can subscribe to it, and when there's a new pull request to review, an automatic comment will be added to the discussion.
|
||||
|
||||
* If you translate pages, add a single pull request per page translated. That will make it much easier for others to review it.
|
||||
|
||||
* To check the 2-letter code for the language you want to translate, you can use the table <a href="https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes" class="external-link" target="_blank">List of ISO 639-1 codes</a>.
|
||||
|
||||
#### Existing language
|
||||
|
||||
Let's say you want to translate a page for a language that already has translations for some pages, like Spanish.
|
||||
|
||||
In the case of Spanish, the 2-letter code is `es`. So, the directory for Spanish translations is located at `docs/es/`.
|
||||
|
||||
/// tip
|
||||
|
||||
The main ("official") language is English, located at `docs/en/`.
|
||||
|
||||
///
|
||||
|
||||
Now run the live server for the docs in Spanish:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
// Use the command "live" and pass the language code as a CLI argument
|
||||
$ python ./scripts/docs.py live es
|
||||
|
||||
<span style="color: green;">[INFO]</span> Serving on http://127.0.0.1:8008
|
||||
<span style="color: green;">[INFO]</span> Start watching changes
|
||||
<span style="color: green;">[INFO]</span> Start detecting changes
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
/// tip
|
||||
|
||||
Alternatively, you can perform the same steps that scripts does manually.
|
||||
|
||||
Go into the language directory, for the Spanish translations it's at `docs/es/`:
|
||||
|
||||
```console
|
||||
$ cd docs/es/
|
||||
```
|
||||
|
||||
Then run `mkdocs` in that directory:
|
||||
|
||||
```console
|
||||
$ mkdocs serve --dev-addr 127.0.0.1:8008
|
||||
```
|
||||
|
||||
///
|
||||
|
||||
Now you can go to <a href="http://127.0.0.1:8008" class="external-link" target="_blank">http://127.0.0.1:8008</a> and see your changes live.
|
||||
|
||||
You will see that every language has all the pages. But some pages are not translated and have an info box at the top, about the missing translation.
|
||||
|
||||
Now let's say that you want to add a translation for the section [Features](features.md){.internal-link target=_blank}.
|
||||
|
||||
* Copy the file at:
|
||||
|
||||
```
|
||||
docs/en/docs/features.md
|
||||
```
|
||||
|
||||
* Paste it in exactly the same location but for the language you want to translate, e.g.:
|
||||
|
||||
```
|
||||
docs/es/docs/features.md
|
||||
```
|
||||
|
||||
/// tip
|
||||
|
||||
Notice that the only change in the path and file name is the language code, from `en` to `es`.
|
||||
|
||||
///
|
||||
|
||||
If you go to your browser you will see that now the docs show your new section (the info box at the top is gone). 🎉
|
||||
|
||||
Now you can translate it all and see how it looks as you save the file.
|
||||
|
||||
#### Don't Translate these Pages
|
||||
|
||||
🚨 Don't translate:
|
||||
|
||||
* Files under `reference/`
|
||||
* `release-notes.md`
|
||||
* `fastapi-people.md`
|
||||
* `external-links.md`
|
||||
* `newsletter.md`
|
||||
* `management-tasks.md`
|
||||
* `management.md`
|
||||
* `contributing.md`
|
||||
|
||||
Some of these files are updated very frequently and a translation would always be behind, or they include the main content from English source files, etc.
|
||||
|
||||
#### Request a New Language
|
||||
|
||||
Let's say that you want to request translations for a language that is not yet translated, not even some pages. For example, Latin.
|
||||
|
||||
If there is no discussion for that language, you can start by requesting the new language. For that, you can follow these steps:
|
||||
|
||||
* Create a new discussion following the template.
|
||||
* Get a few native speakers to comment on the discussion and commit to help review translations for that language.
|
||||
|
||||
Once there are several people in the discussion, the FastAPI team can evaluate it and can make it an official translation.
|
||||
|
||||
Then the docs will be automatically translated using AI, and the team of native speakers can review the translation, and help tweak the AI prompts.
|
||||
|
||||
Once there's a new translation, for example if docs are updated or there's a new section, there will be a comment in the same discussion with the link to the new translation to review.
|
||||
|
||||
#### New Language
|
||||
|
||||
/// note
|
||||
|
||||
These steps will be performed by the FastAPI team.
|
||||
|
||||
///
|
||||
|
||||
Checking the link from above (List of ISO 639-1 codes), you can see that the 2-letter code for Latin is `la`.
|
||||
|
||||
Now you can create a new directory for the new language, running the following script:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
// Use the command new-lang, pass the language code as a CLI argument
|
||||
$ python ./scripts/docs.py new-lang la
|
||||
|
||||
Successfully initialized: docs/la
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
Now you can check in your code editor the newly created directory `docs/la/`.
|
||||
|
||||
That command created a file `docs/la/mkdocs.yml` with a simple config that inherits everything from the `en` version:
|
||||
|
||||
```yaml
|
||||
INHERIT: ../en/mkdocs.yml
|
||||
```
|
||||
|
||||
/// tip
|
||||
|
||||
You could also simply create that file with those contents manually.
|
||||
|
||||
///
|
||||
|
||||
That command also created a dummy file `docs/la/index.md` for the main page, you can start by translating that one.
|
||||
|
||||
You can continue with the previous instructions for an "Existing Language" for that process.
|
||||
|
||||
You can make the first pull request with those two files, `docs/la/mkdocs.yml` and `docs/la/index.md`. 🎉
|
||||
|
||||
#### Preview the result
|
||||
|
||||
As already mentioned above, you can use the `./scripts/docs.py` with the `live` command to preview the results (or `mkdocs serve`).
|
||||
|
||||
Once you are done, you can also test it all as it would look online, including all the other languages.
|
||||
|
||||
To do that, first build all the docs:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
// Use the command "build-all", this will take a bit
|
||||
$ python ./scripts/docs.py build-all
|
||||
|
||||
Building docs for: en
|
||||
Building docs for: es
|
||||
Successfully built docs for: es
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
This builds all those independent MkDocs sites for each language, combines them, and generates the final output at `./site/`.
|
||||
|
||||
Then you can serve that with the command `serve`:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
// Use the command "serve" after running "build-all"
|
||||
$ python ./scripts/docs.py serve
|
||||
|
||||
Warning: this is a very simple server. For development, use mkdocs serve instead.
|
||||
This is here only to preview a site with translations already built.
|
||||
Make sure you run the build-all command first.
|
||||
Serving at: http://127.0.0.1:8008
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
#### Translation specific tips and guidelines
|
||||
|
||||
* Translate only the Markdown documents (`.md`). Do not translate the code examples at `./docs_src`.
|
||||
|
||||
* In code blocks within the Markdown document, translate comments (`# a comment`), but leave the rest unchanged.
|
||||
|
||||
* Do not change anything enclosed in "``" (inline code).
|
||||
|
||||
* In lines starting with `///` translate only the text part after `|`. Leave the rest unchanged.
|
||||
|
||||
* You can translate info boxes like `/// warning` with for example `/// warning | Achtung`. But do not change the word immediately after the `///`, it determines the color of the info box.
|
||||
|
||||
* Do not change the paths in links to images, code files, Markdown documents.
|
||||
|
||||
* However, when a Markdown document is translated, the `#hash-parts` in links to its headings may change. Update these links if possible.
|
||||
* Search for such links in the translated document using the regex `#[^# ]`.
|
||||
* Search in all documents already translated into your language for `your-translated-document.md`. For example VS Code has an option "Edit" -> "Find in Files".
|
||||
* When translating a document, do not "pre-translate" `#hash-parts` that link to headings in untranslated documents.
|
||||
@@ -0,0 +1,205 @@
|
||||
/* Fira Code, including characters used by Rich output, like the "heavy right-pointing angle bracket ornament", not included in Google Fonts */
|
||||
@import url(https://cdn.jsdelivr.net/npm/firacode@6.2.0/distr/fira_code.css);
|
||||
/* Noto Color Emoji for emoji support with the same font everywhere */
|
||||
@import url(https://fonts.googleapis.com/css2?family=Noto+Color+Emoji&display=swap);
|
||||
|
||||
/* Override default code font in Material for MkDocs to Fira Code */
|
||||
:root {
|
||||
--md-code-font: "Fira Code", monospace, "Noto Color Emoji";
|
||||
}
|
||||
|
||||
/* Override default regular font in Material for MkDocs to include Noto Color Emoji */
|
||||
:root {
|
||||
--md-text-font: "Roboto", "Noto Color Emoji";
|
||||
}
|
||||
|
||||
.termynal-comment {
|
||||
color: #4a968f;
|
||||
font-style: italic;
|
||||
display: block;
|
||||
}
|
||||
|
||||
.termy {
|
||||
/* For right to left languages */
|
||||
direction: ltr;
|
||||
}
|
||||
|
||||
.termy [data-termynal] {
|
||||
white-space: pre-wrap;
|
||||
}
|
||||
|
||||
.termy .linenos {
|
||||
display: none;
|
||||
}
|
||||
|
||||
a.external-link {
|
||||
/* For right to left languages */
|
||||
direction: ltr;
|
||||
display: inline-block;
|
||||
}
|
||||
|
||||
a.external-link::after {
|
||||
/* \00A0 is a non-breaking space
|
||||
to make the mark be on the same line as the link
|
||||
*/
|
||||
content: "\00A0[↪]";
|
||||
}
|
||||
|
||||
a.internal-link::after {
|
||||
/* \00A0 is a non-breaking space
|
||||
to make the mark be on the same line as the link
|
||||
*/
|
||||
content: "\00A0↪";
|
||||
}
|
||||
|
||||
.shadow {
|
||||
box-shadow: 5px 5px 10px #999;
|
||||
}
|
||||
|
||||
/* Give space to lower icons so Gitter chat doesn't get on top of them */
|
||||
.md-footer-meta {
|
||||
padding-bottom: 2em;
|
||||
}
|
||||
|
||||
.user-list {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
margin-bottom: 2rem;
|
||||
}
|
||||
|
||||
.user-list-center {
|
||||
justify-content: space-evenly;
|
||||
}
|
||||
|
||||
.user {
|
||||
margin: 1em;
|
||||
min-width: 7em;
|
||||
}
|
||||
|
||||
.user .avatar-wrapper {
|
||||
width: 80px;
|
||||
height: 80px;
|
||||
margin: 10px auto;
|
||||
overflow: hidden;
|
||||
border-radius: 50%;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.user .avatar-wrapper img {
|
||||
position: absolute;
|
||||
top: 50%;
|
||||
left: 50%;
|
||||
transform: translate(-50%, -50%);
|
||||
}
|
||||
|
||||
.user .title {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.user .count {
|
||||
font-size: 80%;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
a.announce-link:link,
|
||||
a.announce-link:visited {
|
||||
color: #fff;
|
||||
}
|
||||
|
||||
a.announce-link:hover {
|
||||
color: var(--md-accent-fg-color);
|
||||
}
|
||||
|
||||
.announce-wrapper {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
flex-wrap: wrap;
|
||||
align-items: center;
|
||||
}
|
||||
|
||||
.announce-wrapper #announce-left div.item {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.announce-wrapper #announce-right {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.announce-wrapper #announce-right div.item {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.announce-wrapper .sponsor-badge {
|
||||
display: block;
|
||||
position: absolute;
|
||||
top: -10px;
|
||||
right: 0;
|
||||
font-size: 0.5rem;
|
||||
color: #e6e6e6;
|
||||
background-color: #666;
|
||||
border-radius: 10px;
|
||||
padding: 0 10px;
|
||||
z-index: 10;
|
||||
}
|
||||
|
||||
.announce-wrapper .sponsor-image {
|
||||
display: block;
|
||||
border-radius: 20px;
|
||||
}
|
||||
|
||||
.announce-wrapper>div {
|
||||
min-height: 40px;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
}
|
||||
|
||||
.twitter {
|
||||
color: #00acee;
|
||||
}
|
||||
|
||||
/* Right to left languages */
|
||||
code {
|
||||
direction: ltr;
|
||||
display: inline-block;
|
||||
}
|
||||
|
||||
.illustration {
|
||||
margin-top: 2em;
|
||||
margin-bottom: 2em;
|
||||
}
|
||||
|
||||
/* Screenshots */
|
||||
/*
|
||||
Simulate a browser window frame.
|
||||
Inspired by Termynal's CSS tricks with modifications
|
||||
*/
|
||||
|
||||
.screenshot {
|
||||
display: block;
|
||||
background-color: #d3e0de;
|
||||
border-radius: 4px;
|
||||
padding: 45px 5px 5px;
|
||||
position: relative;
|
||||
-webkit-box-sizing: border-box;
|
||||
box-sizing: border-box;
|
||||
}
|
||||
|
||||
.screenshot img {
|
||||
display: block;
|
||||
border-radius: 2px;
|
||||
}
|
||||
|
||||
.screenshot:before {
|
||||
content: '';
|
||||
position: absolute;
|
||||
top: 15px;
|
||||
left: 15px;
|
||||
display: inline-block;
|
||||
width: 15px;
|
||||
height: 15px;
|
||||
border-radius: 50%;
|
||||
/* A little hack to display the window buttons in one pseudo element. */
|
||||
background: #d9515d;
|
||||
-webkit-box-shadow: 25px 0 0 #f4c025, 50px 0 0 #3ec930;
|
||||
box-shadow: 25px 0 0 #f4c025, 50px 0 0 #3ec930;
|
||||
}
|
||||
@@ -0,0 +1,111 @@
|
||||
/**
|
||||
* termynal.js
|
||||
*
|
||||
* @author Ines Montani <ines@ines.io>
|
||||
* @version 0.0.1
|
||||
* @license MIT
|
||||
*/
|
||||
|
||||
:root {
|
||||
--color-bg: #252a33;
|
||||
--color-text: #eee;
|
||||
--color-text-subtle: #a2a2a2;
|
||||
}
|
||||
|
||||
[data-termynal] {
|
||||
width: 750px;
|
||||
max-width: 100%;
|
||||
background: var(--color-bg);
|
||||
color: var(--color-text);
|
||||
/* font-size: 18px; */
|
||||
font-size: 15px;
|
||||
/* font-family: 'Fira Mono', Consolas, Menlo, Monaco, 'Courier New', Courier, monospace; */
|
||||
font-family: var(--md-code-font-family), 'Roboto Mono', 'Fira Mono', Consolas, Menlo, Monaco, 'Courier New', Courier, monospace;
|
||||
border-radius: 4px;
|
||||
padding: 75px 45px 35px;
|
||||
position: relative;
|
||||
-webkit-box-sizing: border-box;
|
||||
box-sizing: border-box;
|
||||
/* Custom line-height */
|
||||
line-height: 1.2;
|
||||
}
|
||||
|
||||
[data-termynal]:before {
|
||||
content: '';
|
||||
position: absolute;
|
||||
top: 15px;
|
||||
left: 15px;
|
||||
display: inline-block;
|
||||
width: 15px;
|
||||
height: 15px;
|
||||
border-radius: 50%;
|
||||
/* A little hack to display the window buttons in one pseudo element. */
|
||||
background: #d9515d;
|
||||
-webkit-box-shadow: 25px 0 0 #f4c025, 50px 0 0 #3ec930;
|
||||
box-shadow: 25px 0 0 #f4c025, 50px 0 0 #3ec930;
|
||||
}
|
||||
|
||||
[data-termynal]:after {
|
||||
content: 'bash';
|
||||
position: absolute;
|
||||
color: var(--color-text-subtle);
|
||||
top: 5px;
|
||||
left: 0;
|
||||
width: 100%;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
a[data-terminal-control] {
|
||||
text-align: right;
|
||||
display: block;
|
||||
color: #aebbff;
|
||||
}
|
||||
|
||||
[data-ty] {
|
||||
display: block;
|
||||
line-height: 2;
|
||||
}
|
||||
|
||||
[data-ty]:before {
|
||||
/* Set up defaults and ensure empty lines are displayed. */
|
||||
content: '';
|
||||
display: inline-block;
|
||||
vertical-align: middle;
|
||||
}
|
||||
|
||||
[data-ty="input"]:before,
|
||||
[data-ty-prompt]:before {
|
||||
margin-right: 0.75em;
|
||||
color: var(--color-text-subtle);
|
||||
}
|
||||
|
||||
[data-ty="input"]:before {
|
||||
content: '$';
|
||||
}
|
||||
|
||||
[data-ty][data-ty-prompt]:before {
|
||||
content: attr(data-ty-prompt);
|
||||
}
|
||||
|
||||
[data-ty-cursor]:after {
|
||||
content: attr(data-ty-cursor);
|
||||
font-family: monospace;
|
||||
margin-left: 0.5em;
|
||||
-webkit-animation: blink 1s infinite;
|
||||
animation: blink 1s infinite;
|
||||
}
|
||||
|
||||
|
||||
/* Cursor animation */
|
||||
|
||||
@-webkit-keyframes blink {
|
||||
50% {
|
||||
opacity: 0;
|
||||
}
|
||||
}
|
||||
|
||||
@keyframes blink {
|
||||
50% {
|
||||
opacity: 0;
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,24 @@
|
||||
# Deploy FastAPI on Cloud Providers { #deploy-fastapi-on-cloud-providers }
|
||||
|
||||
You can use virtually **any cloud provider** to deploy your FastAPI application.
|
||||
|
||||
In most of the cases, the main cloud providers have guides to deploy FastAPI with them.
|
||||
|
||||
## FastAPI Cloud { #fastapi-cloud }
|
||||
|
||||
**<a href="https://fastapicloud.com" class="external-link" target="_blank">FastAPI Cloud</a>** is built by the same author and team behind **FastAPI**.
|
||||
|
||||
It streamlines the process of **building**, **deploying**, and **accessing** an API with minimal effort.
|
||||
|
||||
It brings the same **developer experience** of building apps with FastAPI to **deploying** them to the cloud. 🎉
|
||||
|
||||
FastAPI Cloud is the primary sponsor and funding provider for the *FastAPI and friends* open source projects. ✨
|
||||
|
||||
## Cloud Providers - Sponsors { #cloud-providers-sponsors }
|
||||
|
||||
Some other cloud providers ✨ [**sponsor FastAPI**](../help-fastapi.md#sponsor-the-author){.internal-link target=_blank} ✨ too. 🙇
|
||||
|
||||
You might also want to consider them to follow their guides and try their services:
|
||||
|
||||
* <a href="https://docs.render.com/deploy-fastapi?utm_source=deploydoc&utm_medium=referral&utm_campaign=fastapi" class="external-link" target="_blank">Render</a>
|
||||
* <a href="https://docs.railway.com/guides/fastapi?utm_medium=integration&utm_source=docs&utm_campaign=fastapi" class="external-link" target="_blank">Railway</a>
|
||||
@@ -0,0 +1,321 @@
|
||||
# Deployments Concepts { #deployments-concepts }
|
||||
|
||||
When deploying a **FastAPI** application, or actually, any type of web API, there are several concepts that you probably care about, and using them you can find the **most appropriate** way to **deploy your application**.
|
||||
|
||||
Some of the important concepts are:
|
||||
|
||||
* Security - HTTPS
|
||||
* Running on startup
|
||||
* Restarts
|
||||
* Replication (the number of processes running)
|
||||
* Memory
|
||||
* Previous steps before starting
|
||||
|
||||
We'll see how they would affect **deployments**.
|
||||
|
||||
In the end, the ultimate objective is to be able to **serve your API clients** in a way that is **secure**, to **avoid disruptions**, and to use the **compute resources** (for example remote servers/virtual machines) as efficiently as possible. 🚀
|
||||
|
||||
I'll tell you a bit more about these **concepts** here, and that would hopefully give you the **intuition** you would need to decide how to deploy your API in very different environments, possibly even in **future** ones that don't exist yet.
|
||||
|
||||
By considering these concepts, you will be able to **evaluate and design** the best way to deploy **your own APIs**.
|
||||
|
||||
In the next chapters, I'll give you more **concrete recipes** to deploy FastAPI applications.
|
||||
|
||||
But for now, let's check these important **conceptual ideas**. These concepts also apply to any other type of web API. 💡
|
||||
|
||||
## Security - HTTPS { #security-https }
|
||||
|
||||
In the [previous chapter about HTTPS](https.md){.internal-link target=_blank} we learned about how HTTPS provides encryption for your API.
|
||||
|
||||
We also saw that HTTPS is normally provided by a component **external** to your application server, a **TLS Termination Proxy**.
|
||||
|
||||
And there has to be something in charge of **renewing the HTTPS certificates**, it could be the same component or it could be something different.
|
||||
|
||||
### Example Tools for HTTPS { #example-tools-for-https }
|
||||
|
||||
Some of the tools you could use as a TLS Termination Proxy are:
|
||||
|
||||
* Traefik
|
||||
* Automatically handles certificates renewals ✨
|
||||
* Caddy
|
||||
* Automatically handles certificates renewals ✨
|
||||
* Nginx
|
||||
* With an external component like Certbot for certificate renewals
|
||||
* HAProxy
|
||||
* With an external component like Certbot for certificate renewals
|
||||
* Kubernetes with an Ingress Controller like Nginx
|
||||
* With an external component like cert-manager for certificate renewals
|
||||
* Handled internally by a cloud provider as part of their services (read below 👇)
|
||||
|
||||
Another option is that you could use a **cloud service** that does more of the work including setting up HTTPS. It could have some restrictions or charge you more, etc. But in that case, you wouldn't have to set up a TLS Termination Proxy yourself.
|
||||
|
||||
I'll show you some concrete examples in the next chapters.
|
||||
|
||||
---
|
||||
|
||||
Then the next concepts to consider are all about the program running your actual API (e.g. Uvicorn).
|
||||
|
||||
## Program and Process { #program-and-process }
|
||||
|
||||
We will talk a lot about the running "**process**", so it's useful to have clarity about what it means, and what's the difference with the word "**program**".
|
||||
|
||||
### What is a Program { #what-is-a-program }
|
||||
|
||||
The word **program** is commonly used to describe many things:
|
||||
|
||||
* The **code** that you write, the **Python files**.
|
||||
* The **file** that can be **executed** by the operating system, for example: `python`, `python.exe` or `uvicorn`.
|
||||
* A particular program while it is **running** on the operating system, using the CPU, and storing things in memory. This is also called a **process**.
|
||||
|
||||
### What is a Process { #what-is-a-process }
|
||||
|
||||
The word **process** is normally used in a more specific way, only referring to the thing that is running in the operating system (like in the last point above):
|
||||
|
||||
* A particular program while it is **running** on the operating system.
|
||||
* This doesn't refer to the file, nor to the code, it refers **specifically** to the thing that is being **executed** and managed by the operating system.
|
||||
* Any program, any code, **can only do things** when it is being **executed**. So, when there's a **process running**.
|
||||
* The process can be **terminated** (or "killed") by you, or by the operating system. At that point, it stops running/being executed, and it can **no longer do things**.
|
||||
* Each application that you have running on your computer has some process behind it, each running program, each window, etc. And there are normally many processes running **at the same time** while a computer is on.
|
||||
* There can be **multiple processes** of the **same program** running at the same time.
|
||||
|
||||
If you check out the "task manager" or "system monitor" (or similar tools) in your operating system, you will be able to see many of those processes running.
|
||||
|
||||
And, for example, you will probably see that there are multiple processes running the same browser program (Firefox, Chrome, Edge, etc). They normally run one process per tab, plus some other extra processes.
|
||||
|
||||
<img class="shadow" src="/img/deployment/concepts/image01.png">
|
||||
|
||||
---
|
||||
|
||||
Now that we know the difference between the terms **process** and **program**, let's continue talking about deployments.
|
||||
|
||||
## Running on Startup { #running-on-startup }
|
||||
|
||||
In most cases, when you create a web API, you want it to be **always running**, uninterrupted, so that your clients can always access it. This is of course, unless you have a specific reason why you want it to run only in certain situations, but most of the time you want it constantly running and **available**.
|
||||
|
||||
### In a Remote Server { #in-a-remote-server }
|
||||
|
||||
When you set up a remote server (a cloud server, a virtual machine, etc.) the simplest thing you can do is use `fastapi run` (which uses Uvicorn) or something similar, manually, the same way you do when developing locally.
|
||||
|
||||
And it will work and will be useful **during development**.
|
||||
|
||||
But if your connection to the server is lost, the **running process** will probably die.
|
||||
|
||||
And if the server is restarted (for example after updates, or migrations from the cloud provider) you probably **won't notice it**. And because of that, you won't even know that you have to restart the process manually. So, your API will just stay dead. 😱
|
||||
|
||||
### Run Automatically on Startup { #run-automatically-on-startup }
|
||||
|
||||
In general, you will probably want the server program (e.g. Uvicorn) to be started automatically on server startup, and without needing any **human intervention**, to have a process always running with your API (e.g. Uvicorn running your FastAPI app).
|
||||
|
||||
### Separate Program { #separate-program }
|
||||
|
||||
To achieve this, you will normally have a **separate program** that would make sure your application is run on startup. And in many cases, it would also make sure other components or applications are also run, for example, a database.
|
||||
|
||||
### Example Tools to Run at Startup { #example-tools-to-run-at-startup }
|
||||
|
||||
Some examples of the tools that can do this job are:
|
||||
|
||||
* Docker
|
||||
* Kubernetes
|
||||
* Docker Compose
|
||||
* Docker in Swarm Mode
|
||||
* Systemd
|
||||
* Supervisor
|
||||
* Handled internally by a cloud provider as part of their services
|
||||
* Others...
|
||||
|
||||
I'll give you more concrete examples in the next chapters.
|
||||
|
||||
## Restarts { #restarts }
|
||||
|
||||
Similar to making sure your application is run on startup, you probably also want to make sure it is **restarted** after failures.
|
||||
|
||||
### We Make Mistakes { #we-make-mistakes }
|
||||
|
||||
We, as humans, make **mistakes**, all the time. Software almost *always* has **bugs** hidden in different places. 🐛
|
||||
|
||||
And we as developers keep improving the code as we find those bugs and as we implement new features (possibly adding new bugs too 😅).
|
||||
|
||||
### Small Errors Automatically Handled { #small-errors-automatically-handled }
|
||||
|
||||
When building web APIs with FastAPI, if there's an error in our code, FastAPI will normally contain it to the single request that triggered the error. 🛡
|
||||
|
||||
The client will get a **500 Internal Server Error** for that request, but the application will continue working for the next requests instead of just crashing completely.
|
||||
|
||||
### Bigger Errors - Crashes { #bigger-errors-crashes }
|
||||
|
||||
Nevertheless, there might be cases where we write some code that **crashes the entire application** making Uvicorn and Python crash. 💥
|
||||
|
||||
And still, you would probably not want the application to stay dead because there was an error in one place, you probably want it to **continue running** at least for the *path operations* that are not broken.
|
||||
|
||||
### Restart After Crash { #restart-after-crash }
|
||||
|
||||
But in those cases with really bad errors that crash the running **process**, you would want an external component that is in charge of **restarting** the process, at least a couple of times...
|
||||
|
||||
/// tip
|
||||
|
||||
...Although if the whole application is just **crashing immediately** it probably doesn't make sense to keep restarting it forever. But in those cases, you will probably notice it during development, or at least right after deployment.
|
||||
|
||||
So let's focus on the main cases, where it could crash entirely in some particular cases **in the future**, and it still makes sense to restart it.
|
||||
|
||||
///
|
||||
|
||||
You would probably want to have the thing in charge of restarting your application as an **external component**, because by that point, the same application with Uvicorn and Python already crashed, so there's nothing in the same code of the same app that could do anything about it.
|
||||
|
||||
### Example Tools to Restart Automatically { #example-tools-to-restart-automatically }
|
||||
|
||||
In most cases, the same tool that is used to **run the program on startup** is also used to handle automatic **restarts**.
|
||||
|
||||
For example, this could be handled by:
|
||||
|
||||
* Docker
|
||||
* Kubernetes
|
||||
* Docker Compose
|
||||
* Docker in Swarm Mode
|
||||
* Systemd
|
||||
* Supervisor
|
||||
* Handled internally by a cloud provider as part of their services
|
||||
* Others...
|
||||
|
||||
## Replication - Processes and Memory { #replication-processes-and-memory }
|
||||
|
||||
With a FastAPI application, using a server program like the `fastapi` command that runs Uvicorn, running it once in **one process** can serve multiple clients concurrently.
|
||||
|
||||
But in many cases, you will want to run several worker processes at the same time.
|
||||
|
||||
### Multiple Processes - Workers { #multiple-processes-workers }
|
||||
|
||||
If you have more clients than what a single process can handle (for example if the virtual machine is not too big) and you have **multiple cores** in the server's CPU, then you could have **multiple processes** running with the same application at the same time, and distribute all the requests among them.
|
||||
|
||||
When you run **multiple processes** of the same API program, they are commonly called **workers**.
|
||||
|
||||
### Worker Processes and Ports { #worker-processes-and-ports }
|
||||
|
||||
Remember from the docs [About HTTPS](https.md){.internal-link target=_blank} that only one process can be listening on one combination of port and IP address in a server?
|
||||
|
||||
This is still true.
|
||||
|
||||
So, to be able to have **multiple processes** at the same time, there has to be a **single process listening on a port** that then transmits the communication to each worker process in some way.
|
||||
|
||||
### Memory per Process { #memory-per-process }
|
||||
|
||||
Now, when the program loads things in memory, for example, a machine learning model in a variable, or the contents of a large file in a variable, all that **consumes a bit of the memory (RAM)** of the server.
|
||||
|
||||
And multiple processes normally **don't share any memory**. This means that each running process has its own things, variables, and memory. And if you are consuming a large amount of memory in your code, **each process** will consume an equivalent amount of memory.
|
||||
|
||||
### Server Memory { #server-memory }
|
||||
|
||||
For example, if your code loads a Machine Learning model with **1 GB in size**, when you run one process with your API, it will consume at least 1 GB of RAM. And if you start **4 processes** (4 workers), each will consume 1 GB of RAM. So in total, your API will consume **4 GB of RAM**.
|
||||
|
||||
And if your remote server or virtual machine only has 3 GB of RAM, trying to load more than 4 GB of RAM will cause problems. 🚨
|
||||
|
||||
### Multiple Processes - An Example { #multiple-processes-an-example }
|
||||
|
||||
In this example, there's a **Manager Process** that starts and controls two **Worker Processes**.
|
||||
|
||||
This Manager Process would probably be the one listening on the **port** in the IP. And it would transmit all the communication to the worker processes.
|
||||
|
||||
Those worker processes would be the ones running your application, they would perform the main computations to receive a **request** and return a **response**, and they would load anything you put in variables in RAM.
|
||||
|
||||
<img src="/img/deployment/concepts/process-ram.drawio.svg">
|
||||
|
||||
And of course, the same machine would probably have **other processes** running as well, apart from your application.
|
||||
|
||||
An interesting detail is that the percentage of the **CPU used** by each process can **vary** a lot over time, but the **memory (RAM)** normally stays more or less **stable**.
|
||||
|
||||
If you have an API that does a comparable amount of computations every time and you have a lot of clients, then the **CPU utilization** will probably *also be stable* (instead of constantly going up and down quickly).
|
||||
|
||||
### Examples of Replication Tools and Strategies { #examples-of-replication-tools-and-strategies }
|
||||
|
||||
There can be several approaches to achieve this, and I'll tell you more about specific strategies in the next chapters, for example when talking about Docker and containers.
|
||||
|
||||
The main constraint to consider is that there has to be a **single** component handling the **port** in the **public IP**. And then it has to have a way to **transmit** the communication to the replicated **processes/workers**.
|
||||
|
||||
Here are some possible combinations and strategies:
|
||||
|
||||
* **Uvicorn** with `--workers`
|
||||
* One Uvicorn **process manager** would listen on the **IP** and **port**, and it would start **multiple Uvicorn worker processes**.
|
||||
* **Kubernetes** and other distributed **container systems**
|
||||
* Something in the **Kubernetes** layer would listen on the **IP** and **port**. The replication would be by having **multiple containers**, each with **one Uvicorn process** running.
|
||||
* **Cloud services** that handle this for you
|
||||
* The cloud service will probably **handle replication for you**. It would possibly let you define **a process to run**, or a **container image** to use, in any case, it would most probably be **a single Uvicorn process**, and the cloud service would be in charge of replicating it.
|
||||
|
||||
/// tip
|
||||
|
||||
Don't worry if some of these items about **containers**, Docker, or Kubernetes don't make a lot of sense yet.
|
||||
|
||||
I'll tell you more about container images, Docker, Kubernetes, etc. in a future chapter: [FastAPI in Containers - Docker](docker.md){.internal-link target=_blank}.
|
||||
|
||||
///
|
||||
|
||||
## Previous Steps Before Starting { #previous-steps-before-starting }
|
||||
|
||||
There are many cases where you want to perform some steps **before starting** your application.
|
||||
|
||||
For example, you might want to run **database migrations**.
|
||||
|
||||
But in most cases, you will want to perform these steps only **once**.
|
||||
|
||||
So, you will want to have a **single process** to perform those **previous steps**, before starting the application.
|
||||
|
||||
And you will have to make sure that it's a single process running those previous steps *even* if afterwards, you start **multiple processes** (multiple workers) for the application itself. If those steps were run by **multiple processes**, they would **duplicate** the work by running it in **parallel**, and if the steps were something delicate like a database migration, they could cause conflicts with each other.
|
||||
|
||||
Of course, there are some cases where there's no problem in running the previous steps multiple times, in that case, it's a lot easier to handle.
|
||||
|
||||
/// tip
|
||||
|
||||
Also, keep in mind that depending on your setup, in some cases you **might not even need any previous steps** before starting your application.
|
||||
|
||||
In that case, you wouldn't have to worry about any of this. 🤷
|
||||
|
||||
///
|
||||
|
||||
### Examples of Previous Steps Strategies { #examples-of-previous-steps-strategies }
|
||||
|
||||
This will **depend heavily** on the way you **deploy your system**, and it would probably be connected to the way you start programs, handling restarts, etc.
|
||||
|
||||
Here are some possible ideas:
|
||||
|
||||
* An "Init Container" in Kubernetes that runs before your app container
|
||||
* A bash script that runs the previous steps and then starts your application
|
||||
* You would still need a way to start/restart *that* bash script, detect errors, etc.
|
||||
|
||||
/// tip
|
||||
|
||||
I'll give you more concrete examples for doing this with containers in a future chapter: [FastAPI in Containers - Docker](docker.md){.internal-link target=_blank}.
|
||||
|
||||
///
|
||||
|
||||
## Resource Utilization { #resource-utilization }
|
||||
|
||||
Your server(s) is (are) a **resource**, you can consume or **utilize**, with your programs, the computation time on the CPUs, and the RAM memory available.
|
||||
|
||||
How much of the system resources do you want to be consuming/utilizing? It might be easy to think "not much", but in reality, you will probably want to consume **as much as possible without crashing**.
|
||||
|
||||
If you are paying for 3 servers but you are using only a little bit of their RAM and CPU, you are probably **wasting money** 💸, and probably **wasting server electric power** 🌎, etc.
|
||||
|
||||
In that case, it could be better to have only 2 servers and use a higher percentage of their resources (CPU, memory, disk, network bandwidth, etc).
|
||||
|
||||
On the other hand, if you have 2 servers and you are using **100% of their CPU and RAM**, at some point one process will ask for more memory, and the server will have to use the disk as "memory" (which can be thousands of times slower), or even **crash**. Or one process might need to do some computation and would have to wait until the CPU is free again.
|
||||
|
||||
In this case, it would be better to get **one extra server** and run some processes on it so that they all have **enough RAM and CPU time**.
|
||||
|
||||
There's also the chance that for some reason you have a **spike** of usage of your API. Maybe it went viral, or maybe some other services or bots start using it. And you might want to have extra resources to be safe in those cases.
|
||||
|
||||
You could put an **arbitrary number** to target, for example, something **between 50% to 90%** of resource utilization. The point is that those are probably the main things you will want to measure and use to tweak your deployments.
|
||||
|
||||
You can use simple tools like `htop` to see the CPU and RAM used in your server or the amount used by each process. Or you can use more complex monitoring tools, which may be distributed across servers, etc.
|
||||
|
||||
## Recap { #recap }
|
||||
|
||||
You have been reading here some of the main concepts that you would probably need to keep in mind when deciding how to deploy your application:
|
||||
|
||||
* Security - HTTPS
|
||||
* Running on startup
|
||||
* Restarts
|
||||
* Replication (the number of processes running)
|
||||
* Memory
|
||||
* Previous steps before starting
|
||||
|
||||
Understanding these ideas and how to apply them should give you the intuition necessary to take any decisions when configuring and tweaking your deployments. 🤓
|
||||
|
||||
In the next sections, I'll give you more concrete examples of possible strategies you can follow. 🚀
|
||||
@@ -0,0 +1,620 @@
|
||||
# FastAPI in Containers - Docker { #fastapi-in-containers-docker }
|
||||
|
||||
When deploying FastAPI applications a common approach is to build a **Linux container image**. It's normally done using <a href="https://www.docker.com/" class="external-link" target="_blank">**Docker**</a>. You can then deploy that container image in one of a few possible ways.
|
||||
|
||||
Using Linux containers has several advantages including **security**, **replicability**, **simplicity**, and others.
|
||||
|
||||
/// tip
|
||||
|
||||
In a hurry and already know this stuff? Jump to the [`Dockerfile` below 👇](#build-a-docker-image-for-fastapi).
|
||||
|
||||
///
|
||||
|
||||
<details>
|
||||
<summary>Dockerfile Preview 👀</summary>
|
||||
|
||||
```Dockerfile
|
||||
FROM python:3.9
|
||||
|
||||
WORKDIR /code
|
||||
|
||||
COPY ./requirements.txt /code/requirements.txt
|
||||
|
||||
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
|
||||
|
||||
COPY ./app /code/app
|
||||
|
||||
CMD ["fastapi", "run", "app/main.py", "--port", "80"]
|
||||
|
||||
# If running behind a proxy like Nginx or Traefik add --proxy-headers
|
||||
# CMD ["fastapi", "run", "app/main.py", "--port", "80", "--proxy-headers"]
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## What is a Container { #what-is-a-container }
|
||||
|
||||
Containers (mainly Linux containers) are a very **lightweight** way to package applications including all their dependencies and necessary files while keeping them isolated from other containers (other applications or components) in the same system.
|
||||
|
||||
Linux containers run using the same Linux kernel of the host (machine, virtual machine, cloud server, etc). This just means that they are very lightweight (compared to full virtual machines emulating an entire operating system).
|
||||
|
||||
This way, containers consume **little resources**, an amount comparable to running the processes directly (a virtual machine would consume much more).
|
||||
|
||||
Containers also have their own **isolated** running processes (commonly just one process), file system, and network, simplifying deployment, security, development, etc.
|
||||
|
||||
## What is a Container Image { #what-is-a-container-image }
|
||||
|
||||
A **container** is run from a **container image**.
|
||||
|
||||
A container image is a **static** version of all the files, environment variables, and the default command/program that should be present in a container. **Static** here means that the container **image** is not running, it's not being executed, it's only the packaged files and metadata.
|
||||
|
||||
In contrast to a "**container image**" that is the stored static contents, a "**container**" normally refers to the running instance, the thing that is being **executed**.
|
||||
|
||||
When the **container** is started and running (started from a **container image**) it could create or change files, environment variables, etc. Those changes will exist only in that container, but would not persist in the underlying container image (would not be saved to disk).
|
||||
|
||||
A container image is comparable to the **program** file and contents, e.g. `python` and some file `main.py`.
|
||||
|
||||
And the **container** itself (in contrast to the **container image**) is the actual running instance of the image, comparable to a **process**. In fact, a container is running only when it has a **process running** (and normally it's only a single process). The container stops when there's no process running in it.
|
||||
|
||||
## Container Images { #container-images }
|
||||
|
||||
Docker has been one of the main tools to create and manage **container images** and **containers**.
|
||||
|
||||
And there's a public <a href="https://hub.docker.com/" class="external-link" target="_blank">Docker Hub</a> with pre-made **official container images** for many tools, environments, databases, and applications.
|
||||
|
||||
For example, there's an official <a href="https://hub.docker.com/_/python" class="external-link" target="_blank">Python Image</a>.
|
||||
|
||||
And there are many other images for different things like databases, for example for:
|
||||
|
||||
* <a href="https://hub.docker.com/_/postgres" class="external-link" target="_blank">PostgreSQL</a>
|
||||
* <a href="https://hub.docker.com/_/mysql" class="external-link" target="_blank">MySQL</a>
|
||||
* <a href="https://hub.docker.com/_/mongo" class="external-link" target="_blank">MongoDB</a>
|
||||
* <a href="https://hub.docker.com/_/redis" class="external-link" target="_blank">Redis</a>, etc.
|
||||
|
||||
By using a pre-made container image it's very easy to **combine** and use different tools. For example, to try out a new database. In most cases, you can use the **official images**, and just configure them with environment variables.
|
||||
|
||||
That way, in many cases you can learn about containers and Docker and reuse that knowledge with many different tools and components.
|
||||
|
||||
So, you would run **multiple containers** with different things, like a database, a Python application, a web server with a React frontend application, and connect them together via their internal network.
|
||||
|
||||
All the container management systems (like Docker or Kubernetes) have these networking features integrated into them.
|
||||
|
||||
## Containers and Processes { #containers-and-processes }
|
||||
|
||||
A **container image** normally includes in its metadata the default program or command that should be run when the **container** is started and the parameters to be passed to that program. Very similar to what would be if it was in the command line.
|
||||
|
||||
When a **container** is started, it will run that command/program (although you can override it and make it run a different command/program).
|
||||
|
||||
A container is running as long as the **main process** (command or program) is running.
|
||||
|
||||
A container normally has a **single process**, but it's also possible to start subprocesses from the main process, and that way you will have **multiple processes** in the same container.
|
||||
|
||||
But it's not possible to have a running container without **at least one running process**. If the main process stops, the container stops.
|
||||
|
||||
## Build a Docker Image for FastAPI { #build-a-docker-image-for-fastapi }
|
||||
|
||||
Okay, let's build something now! 🚀
|
||||
|
||||
I'll show you how to build a **Docker image** for FastAPI **from scratch**, based on the **official Python** image.
|
||||
|
||||
This is what you would want to do in **most cases**, for example:
|
||||
|
||||
* Using **Kubernetes** or similar tools
|
||||
* When running on a **Raspberry Pi**
|
||||
* Using a cloud service that would run a container image for you, etc.
|
||||
|
||||
### Package Requirements { #package-requirements }
|
||||
|
||||
You would normally have the **package requirements** for your application in some file.
|
||||
|
||||
It would depend mainly on the tool you use to **install** those requirements.
|
||||
|
||||
The most common way to do it is to have a file `requirements.txt` with the package names and their versions, one per line.
|
||||
|
||||
You would of course use the same ideas you read in [About FastAPI versions](versions.md){.internal-link target=_blank} to set the ranges of versions.
|
||||
|
||||
For example, your `requirements.txt` could look like:
|
||||
|
||||
```
|
||||
fastapi[standard]>=0.113.0,<0.114.0
|
||||
pydantic>=2.7.0,<3.0.0
|
||||
```
|
||||
|
||||
And you would normally install those package dependencies with `pip`, for example:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ pip install -r requirements.txt
|
||||
---> 100%
|
||||
Successfully installed fastapi pydantic
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
/// info
|
||||
|
||||
There are other formats and tools to define and install package dependencies.
|
||||
|
||||
///
|
||||
|
||||
### Create the **FastAPI** Code { #create-the-fastapi-code }
|
||||
|
||||
* Create an `app` directory and enter it.
|
||||
* Create an empty file `__init__.py`.
|
||||
* Create a `main.py` file with:
|
||||
|
||||
```Python
|
||||
from typing import Union
|
||||
|
||||
from fastapi import FastAPI
|
||||
|
||||
app = FastAPI()
|
||||
|
||||
|
||||
@app.get("/")
|
||||
def read_root():
|
||||
return {"Hello": "World"}
|
||||
|
||||
|
||||
@app.get("/items/{item_id}")
|
||||
def read_item(item_id: int, q: Union[str, None] = None):
|
||||
return {"item_id": item_id, "q": q}
|
||||
```
|
||||
|
||||
### Dockerfile { #dockerfile }
|
||||
|
||||
Now in the same project directory create a file `Dockerfile` with:
|
||||
|
||||
```{ .dockerfile .annotate }
|
||||
# (1)!
|
||||
FROM python:3.9
|
||||
|
||||
# (2)!
|
||||
WORKDIR /code
|
||||
|
||||
# (3)!
|
||||
COPY ./requirements.txt /code/requirements.txt
|
||||
|
||||
# (4)!
|
||||
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
|
||||
|
||||
# (5)!
|
||||
COPY ./app /code/app
|
||||
|
||||
# (6)!
|
||||
CMD ["fastapi", "run", "app/main.py", "--port", "80"]
|
||||
```
|
||||
|
||||
1. Start from the official Python base image.
|
||||
|
||||
2. Set the current working directory to `/code`.
|
||||
|
||||
This is where we'll put the `requirements.txt` file and the `app` directory.
|
||||
|
||||
3. Copy the file with the requirements to the `/code` directory.
|
||||
|
||||
Copy **only** the file with the requirements first, not the rest of the code.
|
||||
|
||||
As this file **doesn't change often**, Docker will detect it and use the **cache** for this step, enabling the cache for the next step too.
|
||||
|
||||
4. Install the package dependencies in the requirements file.
|
||||
|
||||
The `--no-cache-dir` option tells `pip` to not save the downloaded packages locally, as that is only if `pip` was going to be run again to install the same packages, but that's not the case when working with containers.
|
||||
|
||||
/// note
|
||||
|
||||
The `--no-cache-dir` is only related to `pip`, it has nothing to do with Docker or containers.
|
||||
|
||||
///
|
||||
|
||||
The `--upgrade` option tells `pip` to upgrade the packages if they are already installed.
|
||||
|
||||
Because the previous step copying the file could be detected by the **Docker cache**, this step will also **use the Docker cache** when available.
|
||||
|
||||
Using the cache in this step will **save** you a lot of **time** when building the image again and again during development, instead of **downloading and installing** all the dependencies **every time**.
|
||||
|
||||
5. Copy the `./app` directory inside the `/code` directory.
|
||||
|
||||
As this has all the code which is what **changes most frequently** the Docker **cache** won't be used for this or any **following steps** easily.
|
||||
|
||||
So, it's important to put this **near the end** of the `Dockerfile`, to optimize the container image build times.
|
||||
|
||||
6. Set the **command** to use `fastapi run`, which uses Uvicorn underneath.
|
||||
|
||||
`CMD` takes a list of strings, each of these strings is what you would type in the command line separated by spaces.
|
||||
|
||||
This command will be run from the **current working directory**, the same `/code` directory you set above with `WORKDIR /code`.
|
||||
|
||||
/// tip
|
||||
|
||||
Review what each line does by clicking each number bubble in the code. 👆
|
||||
|
||||
///
|
||||
|
||||
/// warning
|
||||
|
||||
Make sure to **always** use the **exec form** of the `CMD` instruction, as explained below.
|
||||
|
||||
///
|
||||
|
||||
#### Use `CMD` - Exec Form { #use-cmd-exec-form }
|
||||
|
||||
The <a href="https://docs.docker.com/reference/dockerfile/#cmd" class="external-link" target="_blank">`CMD`</a> Docker instruction can be written using two forms:
|
||||
|
||||
✅ **Exec** form:
|
||||
|
||||
```Dockerfile
|
||||
# ✅ Do this
|
||||
CMD ["fastapi", "run", "app/main.py", "--port", "80"]
|
||||
```
|
||||
|
||||
⛔️ **Shell** form:
|
||||
|
||||
```Dockerfile
|
||||
# ⛔️ Don't do this
|
||||
CMD fastapi run app/main.py --port 80
|
||||
```
|
||||
|
||||
Make sure to always use the **exec** form to ensure that FastAPI can shutdown gracefully and [lifespan events](../advanced/events.md){.internal-link target=_blank} are triggered.
|
||||
|
||||
You can read more about it in the <a href="https://docs.docker.com/reference/dockerfile/#shell-and-exec-form" class="external-link" target="_blank">Docker docs for shell and exec form</a>.
|
||||
|
||||
This can be quite noticeable when using `docker compose`. See this Docker Compose FAQ section for more technical details: <a href="https://docs.docker.com/compose/faq/#why-do-my-services-take-10-seconds-to-recreate-or-stop" class="external-link" target="_blank">Why do my services take 10 seconds to recreate or stop?</a>.
|
||||
|
||||
#### Directory Structure { #directory-structure }
|
||||
|
||||
You should now have a directory structure like:
|
||||
|
||||
```
|
||||
.
|
||||
├── app
|
||||
│ ├── __init__.py
|
||||
│ └── main.py
|
||||
├── Dockerfile
|
||||
└── requirements.txt
|
||||
```
|
||||
|
||||
#### Behind a TLS Termination Proxy { #behind-a-tls-termination-proxy }
|
||||
|
||||
If you are running your container behind a TLS Termination Proxy (load balancer) like Nginx or Traefik, add the option `--proxy-headers`, this will tell Uvicorn (through the FastAPI CLI) to trust the headers sent by that proxy telling it that the application is running behind HTTPS, etc.
|
||||
|
||||
```Dockerfile
|
||||
CMD ["fastapi", "run", "app/main.py", "--proxy-headers", "--port", "80"]
|
||||
```
|
||||
|
||||
#### Docker Cache { #docker-cache }
|
||||
|
||||
There's an important trick in this `Dockerfile`, we first copy the **file with the dependencies alone**, not the rest of the code. Let me tell you why is that.
|
||||
|
||||
```Dockerfile
|
||||
COPY ./requirements.txt /code/requirements.txt
|
||||
```
|
||||
|
||||
Docker and other tools **build** these container images **incrementally**, adding **one layer on top of the other**, starting from the top of the `Dockerfile` and adding any files created by each of the instructions of the `Dockerfile`.
|
||||
|
||||
Docker and similar tools also use an **internal cache** when building the image, if a file hasn't changed since the last time building the container image, then it will **reuse the same layer** created the last time, instead of copying the file again and creating a new layer from scratch.
|
||||
|
||||
Just avoiding the copy of files doesn't necessarily improve things too much, but because it used the cache for that step, it can **use the cache for the next step**. For example, it could use the cache for the instruction that installs dependencies with:
|
||||
|
||||
```Dockerfile
|
||||
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
|
||||
```
|
||||
|
||||
The file with the package requirements **won't change frequently**. So, by copying only that file, Docker will be able to **use the cache** for that step.
|
||||
|
||||
And then, Docker will be able to **use the cache for the next step** that downloads and install those dependencies. And here's where we **save a lot of time**. ✨ ...and avoid boredom waiting. 😪😆
|
||||
|
||||
Downloading and installing the package dependencies **could take minutes**, but using the **cache** would **take seconds** at most.
|
||||
|
||||
And as you would be building the container image again and again during development to check that your code changes are working, there's a lot of accumulated time this would save.
|
||||
|
||||
Then, near the end of the `Dockerfile`, we copy all the code. As this is what **changes most frequently**, we put it near the end, because almost always, anything after this step will not be able to use the cache.
|
||||
|
||||
```Dockerfile
|
||||
COPY ./app /code/app
|
||||
```
|
||||
|
||||
### Build the Docker Image { #build-the-docker-image }
|
||||
|
||||
Now that all the files are in place, let's build the container image.
|
||||
|
||||
* Go to the project directory (in where your `Dockerfile` is, containing your `app` directory).
|
||||
* Build your FastAPI image:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ docker build -t myimage .
|
||||
|
||||
---> 100%
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
/// tip
|
||||
|
||||
Notice the `.` at the end, it's equivalent to `./`, it tells Docker the directory to use to build the container image.
|
||||
|
||||
In this case, it's the same current directory (`.`).
|
||||
|
||||
///
|
||||
|
||||
### Start the Docker Container { #start-the-docker-container }
|
||||
|
||||
* Run a container based on your image:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ docker run -d --name mycontainer -p 80:80 myimage
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
## Check it { #check-it }
|
||||
|
||||
You should be able to check it in your Docker container's URL, for example: <a href="http://192.168.99.100/items/5?q=somequery" class="external-link" target="_blank">http://192.168.99.100/items/5?q=somequery</a> or <a href="http://127.0.0.1/items/5?q=somequery" class="external-link" target="_blank">http://127.0.0.1/items/5?q=somequery</a> (or equivalent, using your Docker host).
|
||||
|
||||
You will see something like:
|
||||
|
||||
```JSON
|
||||
{"item_id": 5, "q": "somequery"}
|
||||
```
|
||||
|
||||
## Interactive API docs { #interactive-api-docs }
|
||||
|
||||
Now you can go to <a href="http://192.168.99.100/docs" class="external-link" target="_blank">http://192.168.99.100/docs</a> or <a href="http://127.0.0.1/docs" class="external-link" target="_blank">http://127.0.0.1/docs</a> (or equivalent, using your Docker host).
|
||||
|
||||
You will see the automatic interactive API documentation (provided by <a href="https://github.com/swagger-api/swagger-ui" class="external-link" target="_blank">Swagger UI</a>):
|
||||
|
||||
|
||||
|
||||
## Alternative API docs { #alternative-api-docs }
|
||||
|
||||
And you can also go to <a href="http://192.168.99.100/redoc" class="external-link" target="_blank">http://192.168.99.100/redoc</a> or <a href="http://127.0.0.1/redoc" class="external-link" target="_blank">http://127.0.0.1/redoc</a> (or equivalent, using your Docker host).
|
||||
|
||||
You will see the alternative automatic documentation (provided by <a href="https://github.com/Rebilly/ReDoc" class="external-link" target="_blank">ReDoc</a>):
|
||||
|
||||
|
||||
|
||||
## Build a Docker Image with a Single-File FastAPI { #build-a-docker-image-with-a-single-file-fastapi }
|
||||
|
||||
If your FastAPI is a single file, for example, `main.py` without an `./app` directory, your file structure could look like this:
|
||||
|
||||
```
|
||||
.
|
||||
├── Dockerfile
|
||||
├── main.py
|
||||
└── requirements.txt
|
||||
```
|
||||
|
||||
Then you would just have to change the corresponding paths to copy the file inside the `Dockerfile`:
|
||||
|
||||
```{ .dockerfile .annotate hl_lines="10 13" }
|
||||
FROM python:3.9
|
||||
|
||||
WORKDIR /code
|
||||
|
||||
COPY ./requirements.txt /code/requirements.txt
|
||||
|
||||
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
|
||||
|
||||
# (1)!
|
||||
COPY ./main.py /code/
|
||||
|
||||
# (2)!
|
||||
CMD ["fastapi", "run", "main.py", "--port", "80"]
|
||||
```
|
||||
|
||||
1. Copy the `main.py` file to the `/code` directory directly (without any `./app` directory).
|
||||
|
||||
2. Use `fastapi run` to serve your application in the single file `main.py`.
|
||||
|
||||
When you pass the file to `fastapi run` it will detect automatically that it is a single file and not part of a package and will know how to import it and serve your FastAPI app. 😎
|
||||
|
||||
## Deployment Concepts { #deployment-concepts }
|
||||
|
||||
Let's talk again about some of the same [Deployment Concepts](concepts.md){.internal-link target=_blank} in terms of containers.
|
||||
|
||||
Containers are mainly a tool to simplify the process of **building and deploying** an application, but they don't enforce a particular approach to handle these **deployment concepts**, and there are several possible strategies.
|
||||
|
||||
The **good news** is that with each different strategy there's a way to cover all of the deployment concepts. 🎉
|
||||
|
||||
Let's review these **deployment concepts** in terms of containers:
|
||||
|
||||
* HTTPS
|
||||
* Running on startup
|
||||
* Restarts
|
||||
* Replication (the number of processes running)
|
||||
* Memory
|
||||
* Previous steps before starting
|
||||
|
||||
## HTTPS { #https }
|
||||
|
||||
If we focus just on the **container image** for a FastAPI application (and later the running **container**), HTTPS normally would be handled **externally** by another tool.
|
||||
|
||||
It could be another container, for example with <a href="https://traefik.io/" class="external-link" target="_blank">Traefik</a>, handling **HTTPS** and **automatic** acquisition of **certificates**.
|
||||
|
||||
/// tip
|
||||
|
||||
Traefik has integrations with Docker, Kubernetes, and others, so it's very easy to set up and configure HTTPS for your containers with it.
|
||||
|
||||
///
|
||||
|
||||
Alternatively, HTTPS could be handled by a cloud provider as one of their services (while still running the application in a container).
|
||||
|
||||
## Running on Startup and Restarts { #running-on-startup-and-restarts }
|
||||
|
||||
There is normally another tool in charge of **starting and running** your container.
|
||||
|
||||
It could be **Docker** directly, **Docker Compose**, **Kubernetes**, a **cloud service**, etc.
|
||||
|
||||
In most (or all) cases, there's a simple option to enable running the container on startup and enabling restarts on failures. For example, in Docker, it's the command line option `--restart`.
|
||||
|
||||
Without using containers, making applications run on startup and with restarts can be cumbersome and difficult. But when **working with containers** in most cases that functionality is included by default. ✨
|
||||
|
||||
## Replication - Number of Processes { #replication-number-of-processes }
|
||||
|
||||
If you have a <abbr title="A group of machines that are configured to be connected and work together in some way.">cluster</abbr> of machines with **Kubernetes**, Docker Swarm Mode, Nomad, or another similar complex system to manage distributed containers on multiple machines, then you will probably want to **handle replication** at the **cluster level** instead of using a **process manager** (like Uvicorn with workers) in each container.
|
||||
|
||||
One of those distributed container management systems like Kubernetes normally has some integrated way of handling **replication of containers** while still supporting **load balancing** for the incoming requests. All at the **cluster level**.
|
||||
|
||||
In those cases, you would probably want to build a **Docker image from scratch** as [explained above](#dockerfile), installing your dependencies, and running **a single Uvicorn process** instead of using multiple Uvicorn workers.
|
||||
|
||||
### Load Balancer { #load-balancer }
|
||||
|
||||
When using containers, you would normally have some component **listening on the main port**. It could possibly be another container that is also a **TLS Termination Proxy** to handle **HTTPS** or some similar tool.
|
||||
|
||||
As this component would take the **load** of requests and distribute that among the workers in a (hopefully) **balanced** way, it is also commonly called a **Load Balancer**.
|
||||
|
||||
/// tip
|
||||
|
||||
The same **TLS Termination Proxy** component used for HTTPS would probably also be a **Load Balancer**.
|
||||
|
||||
///
|
||||
|
||||
And when working with containers, the same system you use to start and manage them would already have internal tools to transmit the **network communication** (e.g. HTTP requests) from that **load balancer** (that could also be a **TLS Termination Proxy**) to the container(s) with your app.
|
||||
|
||||
### One Load Balancer - Multiple Worker Containers { #one-load-balancer-multiple-worker-containers }
|
||||
|
||||
When working with **Kubernetes** or similar distributed container management systems, using their internal networking mechanisms would allow the single **load balancer** that is listening on the main **port** to transmit communication (requests) to possibly **multiple containers** running your app.
|
||||
|
||||
Each of these containers running your app would normally have **just one process** (e.g. a Uvicorn process running your FastAPI application). They would all be **identical containers**, running the same thing, but each with its own process, memory, etc. That way you would take advantage of **parallelization** in **different cores** of the CPU, or even in **different machines**.
|
||||
|
||||
And the distributed container system with the **load balancer** would **distribute the requests** to each one of the containers with your app **in turns**. So, each request could be handled by one of the multiple **replicated containers** running your app.
|
||||
|
||||
And normally this **load balancer** would be able to handle requests that go to *other* apps in your cluster (e.g. to a different domain, or under a different URL path prefix), and would transmit that communication to the right containers for *that other* application running in your cluster.
|
||||
|
||||
### One Process per Container { #one-process-per-container }
|
||||
|
||||
In this type of scenario, you probably would want to have **a single (Uvicorn) process per container**, as you would already be handling replication at the cluster level.
|
||||
|
||||
So, in this case, you **would not** want to have a multiple workers in the container, for example with the `--workers` command line option. You would want to have just a **single Uvicorn process** per container (but probably multiple containers).
|
||||
|
||||
Having another process manager inside the container (as would be with multiple workers) would only add **unnecessary complexity** that you are most probably already taking care of with your cluster system.
|
||||
|
||||
### Containers with Multiple Processes and Special Cases { #containers-with-multiple-processes-and-special-cases }
|
||||
|
||||
Of course, there are **special cases** where you could want to have **a container** with several **Uvicorn worker processes** inside.
|
||||
|
||||
In those cases, you can use the `--workers` command line option to set the number of workers that you want to run:
|
||||
|
||||
```{ .dockerfile .annotate }
|
||||
FROM python:3.9
|
||||
|
||||
WORKDIR /code
|
||||
|
||||
COPY ./requirements.txt /code/requirements.txt
|
||||
|
||||
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
|
||||
|
||||
COPY ./app /code/app
|
||||
|
||||
# (1)!
|
||||
CMD ["fastapi", "run", "app/main.py", "--port", "80", "--workers", "4"]
|
||||
```
|
||||
|
||||
1. Here we use the `--workers` command line option to set the number of workers to 4.
|
||||
|
||||
Here are some examples of when that could make sense:
|
||||
|
||||
#### A Simple App { #a-simple-app }
|
||||
|
||||
You could want a process manager in the container if your application is **simple enough** that can run it on a **single server**, not a cluster.
|
||||
|
||||
#### Docker Compose { #docker-compose }
|
||||
|
||||
You could be deploying to a **single server** (not a cluster) with **Docker Compose**, so you wouldn't have an easy way to manage replication of containers (with Docker Compose) while preserving the shared network and **load balancing**.
|
||||
|
||||
Then you could want to have **a single container** with a **process manager** starting **several worker processes** inside.
|
||||
|
||||
---
|
||||
|
||||
The main point is, **none** of these are **rules written in stone** that you have to blindly follow. You can use these ideas to **evaluate your own use case** and decide what is the best approach for your system, checking out how to manage the concepts of:
|
||||
|
||||
* Security - HTTPS
|
||||
* Running on startup
|
||||
* Restarts
|
||||
* Replication (the number of processes running)
|
||||
* Memory
|
||||
* Previous steps before starting
|
||||
|
||||
## Memory { #memory }
|
||||
|
||||
If you run **a single process per container** you will have a more or less well-defined, stable, and limited amount of memory consumed by each of those containers (more than one if they are replicated).
|
||||
|
||||
And then you can set those same memory limits and requirements in your configurations for your container management system (for example in **Kubernetes**). That way it will be able to **replicate the containers** in the **available machines** taking into account the amount of memory needed by them, and the amount available in the machines in the cluster.
|
||||
|
||||
If your application is **simple**, this will probably **not be a problem**, and you might not need to specify hard memory limits. But if you are **using a lot of memory** (for example with **machine learning** models), you should check how much memory you are consuming and adjust the **number of containers** that runs in **each machine** (and maybe add more machines to your cluster).
|
||||
|
||||
If you run **multiple processes per container** you will have to make sure that the number of processes started doesn't **consume more memory** than what is available.
|
||||
|
||||
## Previous Steps Before Starting and Containers { #previous-steps-before-starting-and-containers }
|
||||
|
||||
If you are using containers (e.g. Docker, Kubernetes), then there are two main approaches you can use.
|
||||
|
||||
### Multiple Containers { #multiple-containers }
|
||||
|
||||
If you have **multiple containers**, probably each one running a **single process** (for example, in a **Kubernetes** cluster), then you would probably want to have a **separate container** doing the work of the **previous steps** in a single container, running a single process, **before** running the replicated worker containers.
|
||||
|
||||
/// info
|
||||
|
||||
If you are using Kubernetes, this would probably be an <a href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers/" class="external-link" target="_blank">Init Container</a>.
|
||||
|
||||
///
|
||||
|
||||
If in your use case there's no problem in running those previous steps **multiple times in parallel** (for example if you are not running database migrations, but just checking if the database is ready yet), then you could also just put them in each container right before starting the main process.
|
||||
|
||||
### Single Container { #single-container }
|
||||
|
||||
If you have a simple setup, with a **single container** that then starts multiple **worker processes** (or also just one process), then you could run those previous steps in the same container, right before starting the process with the app.
|
||||
|
||||
### Base Docker Image { #base-docker-image }
|
||||
|
||||
There used to be an official FastAPI Docker image: <a href="https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker" class="external-link" target="_blank">tiangolo/uvicorn-gunicorn-fastapi</a>. But it is now deprecated. ⛔️
|
||||
|
||||
You should probably **not** use this base Docker image (or any other similar one).
|
||||
|
||||
If you are using **Kubernetes** (or others) and you are already setting **replication** at the cluster level, with multiple **containers**. In those cases, you are better off **building an image from scratch** as described above: [Build a Docker Image for FastAPI](#build-a-docker-image-for-fastapi).
|
||||
|
||||
And if you need to have multiple workers, you can simply use the `--workers` command line option.
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
The Docker image was created when Uvicorn didn't support managing and restarting dead workers, so it was needed to use Gunicorn with Uvicorn, which added quite some complexity, just to have Gunicorn manage and restart the Uvicorn worker processes.
|
||||
|
||||
But now that Uvicorn (and the `fastapi` command) support using `--workers`, there's no reason to use a base Docker image instead of building your own (it's pretty much the same amount of code 😅).
|
||||
|
||||
///
|
||||
|
||||
## Deploy the Container Image { #deploy-the-container-image }
|
||||
|
||||
After having a Container (Docker) Image there are several ways to deploy it.
|
||||
|
||||
For example:
|
||||
|
||||
* With **Docker Compose** in a single server
|
||||
* With a **Kubernetes** cluster
|
||||
* With a Docker Swarm Mode cluster
|
||||
* With another tool like Nomad
|
||||
* With a cloud service that takes your container image and deploys it
|
||||
|
||||
## Docker Image with `uv` { #docker-image-with-uv }
|
||||
|
||||
If you are using <a href="https://github.com/astral-sh/uv" class="external-link" target="_blank">uv</a> to install and manage your project, you can follow their <a href="https://docs.astral.sh/uv/guides/integration/docker/" class="external-link" target="_blank">uv Docker guide</a>.
|
||||
|
||||
## Recap { #recap }
|
||||
|
||||
Using container systems (e.g. with **Docker** and **Kubernetes**) it becomes fairly straightforward to handle all the **deployment concepts**:
|
||||
|
||||
* HTTPS
|
||||
* Running on startup
|
||||
* Restarts
|
||||
* Replication (the number of processes running)
|
||||
* Memory
|
||||
* Previous steps before starting
|
||||
|
||||
In most cases, you probably won't want to use any base image, and instead **build a container image from scratch** based on the official Python Docker image.
|
||||
|
||||
Taking care of the **order** of instructions in the `Dockerfile` and the **Docker cache** you can **minimize build times**, to maximize your productivity (and avoid boredom). 😎
|
||||
@@ -0,0 +1,65 @@
|
||||
# FastAPI Cloud { #fastapi-cloud }
|
||||
|
||||
You can deploy your FastAPI app to <a href="https://fastapicloud.com" class="external-link" target="_blank">FastAPI Cloud</a> with **one command**, go and join the waiting list if you haven't. 🚀
|
||||
|
||||
## Login { #login }
|
||||
|
||||
Make sure you already have a **FastAPI Cloud** account (we invited you from the waiting list 😉).
|
||||
|
||||
Then log in:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ fastapi login
|
||||
|
||||
You are logged in to FastAPI Cloud 🚀
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
## Deploy { #deploy }
|
||||
|
||||
Now deploy your app, with **one command**:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ fastapi deploy
|
||||
|
||||
Deploying to FastAPI Cloud...
|
||||
|
||||
✅ Deployment successful!
|
||||
|
||||
🐔 Ready the chicken! Your app is ready at https://myapp.fastapicloud.dev
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
That's it! Now you can access your app at that URL. ✨
|
||||
|
||||
## About FastAPI Cloud { #about-fastapi-cloud }
|
||||
|
||||
**<a href="https://fastapicloud.com" class="external-link" target="_blank">FastAPI Cloud</a>** is built by the same author and team behind **FastAPI**.
|
||||
|
||||
It streamlines the process of **building**, **deploying**, and **accessing** an API with minimal effort.
|
||||
|
||||
It brings the same **developer experience** of building apps with FastAPI to **deploying** them to the cloud. 🎉
|
||||
|
||||
It will also take care of most of the things you would need when deploying an app, like:
|
||||
|
||||
* HTTPS
|
||||
* Replication, with autoscaling based on requests
|
||||
* etc.
|
||||
|
||||
FastAPI Cloud is the primary sponsor and funding provider for the *FastAPI and friends* open source projects. ✨
|
||||
|
||||
## Deploy to other cloud providers { #deploy-to-other-cloud-providers }
|
||||
|
||||
FastAPI is open source and based on standards. You can deploy FastAPI apps to any cloud provider you choose.
|
||||
|
||||
Follow your cloud provider's guides to deploy FastAPI apps with them. 🤓
|
||||
|
||||
## Deploy your own server { #deploy-your-own-server }
|
||||
|
||||
I will also teach you later in this **Deployment** guide all the details, so you can understand what is going on, what needs to happen, or how to deploy FastAPI apps on your own, also with your own servers. 🤓
|
||||
@@ -0,0 +1,231 @@
|
||||
# About HTTPS { #about-https }
|
||||
|
||||
It is easy to assume that HTTPS is something that is just "enabled" or not.
|
||||
|
||||
But it is way more complex than that.
|
||||
|
||||
/// tip
|
||||
|
||||
If you are in a hurry or don't care, continue with the next sections for step by step instructions to set everything up with different techniques.
|
||||
|
||||
///
|
||||
|
||||
To **learn the basics of HTTPS**, from a consumer perspective, check <a href="https://howhttps.works/" class="external-link" target="_blank">https://howhttps.works/</a>.
|
||||
|
||||
Now, from a **developer's perspective**, here are several things to keep in mind while thinking about HTTPS:
|
||||
|
||||
* For HTTPS, **the server** needs to **have "certificates"** generated by a **third party**.
|
||||
* Those certificates are actually **acquired** from the third party, not "generated".
|
||||
* Certificates have a **lifetime**.
|
||||
* They **expire**.
|
||||
* And then they need to be **renewed**, **acquired again** from the third party.
|
||||
* The encryption of the connection happens at the **TCP level**.
|
||||
* That's one layer **below HTTP**.
|
||||
* So, the **certificate and encryption** handling is done **before HTTP**.
|
||||
* **TCP doesn't know about "domains"**. Only about IP addresses.
|
||||
* The information about the **specific domain** requested goes in the **HTTP data**.
|
||||
* The **HTTPS certificates** "certify" a **certain domain**, but the protocol and encryption happen at the TCP level, **before knowing** which domain is being dealt with.
|
||||
* **By default**, that would mean that you can only have **one HTTPS certificate per IP address**.
|
||||
* No matter how big your server is or how small each application you have on it might be.
|
||||
* There is a **solution** to this, however.
|
||||
* There's an **extension** to the **TLS** protocol (the one handling the encryption at the TCP level, before HTTP) called **<a href="https://en.wikipedia.org/wiki/Server_Name_Indication" class="external-link" target="_blank"><abbr title="Server Name Indication">SNI</abbr></a>**.
|
||||
* This SNI extension allows one single server (with a **single IP address**) to have **several HTTPS certificates** and serve **multiple HTTPS domains/applications**.
|
||||
* For this to work, a **single** component (program) running on the server, listening on the **public IP address**, must have **all the HTTPS certificates** in the server.
|
||||
* **After** obtaining a secure connection, the communication protocol is **still HTTP**.
|
||||
* The contents are **encrypted**, even though they are being sent with the **HTTP protocol**.
|
||||
|
||||
It is a common practice to have **one program/HTTP server** running on the server (the machine, host, etc.) and **managing all the HTTPS parts**: receiving the **encrypted HTTPS requests**, sending the **decrypted HTTP requests** to the actual HTTP application running in the same server (the **FastAPI** application, in this case), take the **HTTP response** from the application, **encrypt it** using the appropriate **HTTPS certificate** and sending it back to the client using **HTTPS**. This server is often called a **<a href="https://en.wikipedia.org/wiki/TLS_termination_proxy" class="external-link" target="_blank">TLS Termination Proxy</a>**.
|
||||
|
||||
Some of the options you could use as a TLS Termination Proxy are:
|
||||
|
||||
* Traefik (that can also handle certificate renewals)
|
||||
* Caddy (that can also handle certificate renewals)
|
||||
* Nginx
|
||||
* HAProxy
|
||||
|
||||
## Let's Encrypt { #lets-encrypt }
|
||||
|
||||
Before Let's Encrypt, these **HTTPS certificates** were sold by trusted third parties.
|
||||
|
||||
The process to acquire one of these certificates used to be cumbersome, require quite some paperwork and the certificates were quite expensive.
|
||||
|
||||
But then **<a href="https://letsencrypt.org/" class="external-link" target="_blank">Let's Encrypt</a>** was created.
|
||||
|
||||
It is a project from the Linux Foundation. It provides **HTTPS certificates for free**, in an automated way. These certificates use all the standard cryptographic security, and are short-lived (about 3 months), so the **security is actually better** because of their reduced lifespan.
|
||||
|
||||
The domains are securely verified and the certificates are generated automatically. This also allows automating the renewal of these certificates.
|
||||
|
||||
The idea is to automate the acquisition and renewal of these certificates so that you can have **secure HTTPS, for free, forever**.
|
||||
|
||||
## HTTPS for Developers { #https-for-developers }
|
||||
|
||||
Here's an example of how an HTTPS API could look like, step by step, paying attention mainly to the ideas important for developers.
|
||||
|
||||
### Domain Name { #domain-name }
|
||||
|
||||
It would probably all start by you **acquiring** some **domain name**. Then, you would configure it in a DNS server (possibly your same cloud provider).
|
||||
|
||||
You would probably get a cloud server (a virtual machine) or something similar, and it would have a <abbr title="That doesn't change">fixed</abbr> **public IP address**.
|
||||
|
||||
In the DNS server(s) you would configure a record (an "`A record`") to point **your domain** to the public **IP address of your server**.
|
||||
|
||||
You would probably do this just once, the first time, when setting everything up.
|
||||
|
||||
/// tip
|
||||
|
||||
This Domain Name part is way before HTTPS, but as everything depends on the domain and the IP address, it's worth mentioning it here.
|
||||
|
||||
///
|
||||
|
||||
### DNS { #dns }
|
||||
|
||||
Now let's focus on all the actual HTTPS parts.
|
||||
|
||||
First, the browser would check with the **DNS servers** what is the **IP for the domain**, in this case, `someapp.example.com`.
|
||||
|
||||
The DNS servers would tell the browser to use some specific **IP address**. That would be the public IP address used by your server, that you configured in the DNS servers.
|
||||
|
||||
<img src="/img/deployment/https/https01.drawio.svg">
|
||||
|
||||
### TLS Handshake Start { #tls-handshake-start }
|
||||
|
||||
The browser would then communicate with that IP address on **port 443** (the HTTPS port).
|
||||
|
||||
The first part of the communication is just to establish the connection between the client and the server and to decide the cryptographic keys they will use, etc.
|
||||
|
||||
<img src="/img/deployment/https/https02.drawio.svg">
|
||||
|
||||
This interaction between the client and the server to establish the TLS connection is called the **TLS handshake**.
|
||||
|
||||
### TLS with SNI Extension { #tls-with-sni-extension }
|
||||
|
||||
**Only one process** in the server can be listening on a specific **port** in a specific **IP address**. There could be other processes listening on other ports in the same IP address, but only one for each combination of IP address and port.
|
||||
|
||||
TLS (HTTPS) uses the specific port `443` by default. So that's the port we would need.
|
||||
|
||||
As only one process can be listening on this port, the process that would do it would be the **TLS Termination Proxy**.
|
||||
|
||||
The TLS Termination Proxy would have access to one or more **TLS certificates** (HTTPS certificates).
|
||||
|
||||
Using the **SNI extension** discussed above, the TLS Termination Proxy would check which of the TLS (HTTPS) certificates available it should use for this connection, using the one that matches the domain expected by the client.
|
||||
|
||||
In this case, it would use the certificate for `someapp.example.com`.
|
||||
|
||||
<img src="/img/deployment/https/https03.drawio.svg">
|
||||
|
||||
The client already **trusts** the entity that generated that TLS certificate (in this case Let's Encrypt, but we'll see about that later), so it can **verify** that the certificate is valid.
|
||||
|
||||
Then, using the certificate, the client and the TLS Termination Proxy **decide how to encrypt** the rest of the **TCP communication**. This completes the **TLS Handshake** part.
|
||||
|
||||
After this, the client and the server have an **encrypted TCP connection**, this is what TLS provides. And then they can use that connection to start the actual **HTTP communication**.
|
||||
|
||||
And that's what **HTTPS** is, it's just plain **HTTP** inside a **secure TLS connection** instead of a pure (unencrypted) TCP connection.
|
||||
|
||||
/// tip
|
||||
|
||||
Notice that the encryption of the communication happens at the **TCP level**, not at the HTTP level.
|
||||
|
||||
///
|
||||
|
||||
### HTTPS Request { #https-request }
|
||||
|
||||
Now that the client and server (specifically the browser and the TLS Termination Proxy) have an **encrypted TCP connection**, they can start the **HTTP communication**.
|
||||
|
||||
So, the client sends an **HTTPS request**. This is just an HTTP request through an encrypted TLS connection.
|
||||
|
||||
<img src="/img/deployment/https/https04.drawio.svg">
|
||||
|
||||
### Decrypt the Request { #decrypt-the-request }
|
||||
|
||||
The TLS Termination Proxy would use the encryption agreed to **decrypt the request**, and would transmit the **plain (decrypted) HTTP request** to the process running the application (for example a process with Uvicorn running the FastAPI application).
|
||||
|
||||
<img src="/img/deployment/https/https05.drawio.svg">
|
||||
|
||||
### HTTP Response { #http-response }
|
||||
|
||||
The application would process the request and send a **plain (unencrypted) HTTP response** to the TLS Termination Proxy.
|
||||
|
||||
<img src="/img/deployment/https/https06.drawio.svg">
|
||||
|
||||
### HTTPS Response { #https-response }
|
||||
|
||||
The TLS Termination Proxy would then **encrypt the response** using the cryptography agreed before (that started with the certificate for `someapp.example.com`), and send it back to the browser.
|
||||
|
||||
Next, the browser would verify that the response is valid and encrypted with the right cryptographic key, etc. It would then **decrypt the response** and process it.
|
||||
|
||||
<img src="/img/deployment/https/https07.drawio.svg">
|
||||
|
||||
The client (browser) will know that the response comes from the correct server because it is using the cryptography they agreed using the **HTTPS certificate** before.
|
||||
|
||||
### Multiple Applications { #multiple-applications }
|
||||
|
||||
In the same server (or servers), there could be **multiple applications**, for example, other API programs or a database.
|
||||
|
||||
Only one process can be handling the specific IP and port (the TLS Termination Proxy in our example) but the other applications/processes can be running on the server(s) too, as long as they don't try to use the same **combination of public IP and port**.
|
||||
|
||||
<img src="/img/deployment/https/https08.drawio.svg">
|
||||
|
||||
That way, the TLS Termination Proxy could handle HTTPS and certificates for **multiple domains**, for multiple applications, and then transmit the requests to the right application in each case.
|
||||
|
||||
### Certificate Renewal { #certificate-renewal }
|
||||
|
||||
At some point in the future, each certificate would **expire** (about 3 months after acquiring it).
|
||||
|
||||
And then, there would be another program (in some cases it's another program, in some cases it could be the same TLS Termination Proxy) that would talk to Let's Encrypt, and renew the certificate(s).
|
||||
|
||||
<img src="/img/deployment/https/https.drawio.svg">
|
||||
|
||||
The **TLS certificates** are **associated with a domain name**, not with an IP address.
|
||||
|
||||
So, to renew the certificates, the renewal program needs to **prove** to the authority (Let's Encrypt) that it indeed **"owns" and controls that domain**.
|
||||
|
||||
To do that, and to accommodate different application needs, there are several ways it can do it. Some popular ways are:
|
||||
|
||||
* **Modify some DNS records**.
|
||||
* For this, the renewal program needs to support the APIs of the DNS provider, so, depending on the DNS provider you are using, this might or might not be an option.
|
||||
* **Run as a server** (at least during the certificate acquisition process) on the public IP address associated with the domain.
|
||||
* As we said above, only one process can be listening on a specific IP and port.
|
||||
* This is one of the reasons why it's very useful when the same TLS Termination Proxy also takes care of the certificate renewal process.
|
||||
* Otherwise, you might have to stop the TLS Termination Proxy momentarily, start the renewal program to acquire the certificates, then configure them with the TLS Termination Proxy, and then restart the TLS Termination Proxy. This is not ideal, as your app(s) will not be available during the time that the TLS Termination Proxy is off.
|
||||
|
||||
All this renewal process, while still serving the app, is one of the main reasons why you would want to have a **separate system to handle HTTPS** with a TLS Termination Proxy instead of just using the TLS certificates with the application server directly (e.g. Uvicorn).
|
||||
|
||||
## Proxy Forwarded Headers { #proxy-forwarded-headers }
|
||||
|
||||
When using a proxy to handle HTTPS, your **application server** (for example Uvicorn via FastAPI CLI) doesn't known anything about the HTTPS process, it communicates with plain HTTP with the **TLS Termination Proxy**.
|
||||
|
||||
This **proxy** would normally set some HTTP headers on the fly before transmitting the request to the **application server**, to let the application server know that the request is being **forwarded** by the proxy.
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
The proxy headers are:
|
||||
|
||||
* <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For" class="external-link" target="_blank">X-Forwarded-For</a>
|
||||
* <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto" class="external-link" target="_blank">X-Forwarded-Proto</a>
|
||||
* <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Host" class="external-link" target="_blank">X-Forwarded-Host</a>
|
||||
|
||||
///
|
||||
|
||||
Nevertheless, as the **application server** doesn't know it is behind a trusted **proxy**, by default, it wouldn't trust those headers.
|
||||
|
||||
But you can configure the **application server** to trust the *forwarded* headers sent by the **proxy**. If you are using FastAPI CLI, you can use the *CLI Option* `--forwarded-allow-ips` to tell it from which IPs it should trust those *forwarded* headers.
|
||||
|
||||
For example, if the **application server** is only receiving communication from the trusted **proxy**, you can set it to `--forwarded-allow-ips="*"` to make it trust all incoming IPs, as it will only receive requests from whatever is the IP used by the **proxy**.
|
||||
|
||||
This way the application would be able to know what is its own public URL, if it is using HTTPS, the domain, etc.
|
||||
|
||||
This would be useful for example to properly handle redirects.
|
||||
|
||||
/// tip
|
||||
|
||||
You can learn more about this in the documentation for [Behind a Proxy - Enable Proxy Forwarded Headers](../advanced/behind-a-proxy.md#enable-proxy-forwarded-headers){.internal-link target=_blank}
|
||||
|
||||
///
|
||||
|
||||
## Recap { #recap }
|
||||
|
||||
Having **HTTPS** is very important, and quite **critical** in most cases. Most of the effort you as a developer have to put around HTTPS is just about **understanding these concepts** and how they work.
|
||||
|
||||
But once you know the basic information of **HTTPS for developers** you can easily combine and configure different tools to help you manage everything in a simple way.
|
||||
|
||||
In some of the next chapters, I'll show you several concrete examples of how to set up **HTTPS** for **FastAPI** applications. 🔒
|
||||
@@ -0,0 +1,23 @@
|
||||
# Deployment { #deployment }
|
||||
|
||||
Deploying a **FastAPI** application is relatively easy.
|
||||
|
||||
## What Does Deployment Mean { #what-does-deployment-mean }
|
||||
|
||||
To **deploy** an application means to perform the necessary steps to make it **available to the users**.
|
||||
|
||||
For a **web API**, it normally involves putting it in a **remote machine**, with a **server program** that provides good performance, stability, etc, so that your **users** can **access** the application efficiently and without interruptions or problems.
|
||||
|
||||
This is in contrast to the **development** stages, where you are constantly changing the code, breaking it and fixing it, stopping and restarting the development server, etc.
|
||||
|
||||
## Deployment Strategies { #deployment-strategies }
|
||||
|
||||
There are several ways to do it depending on your specific use case and the tools that you use.
|
||||
|
||||
You could **deploy a server** yourself using a combination of tools, you could use a **cloud service** that does part of the work for you, or other possible options.
|
||||
|
||||
For example, we, the team behind FastAPI, built <a href="https://fastapicloud.com" class="external-link" target="_blank">**FastAPI Cloud**</a>, to make deploying FastAPI apps to the cloud as streamlined as possible, with the same developer experience of working with FastAPI.
|
||||
|
||||
I will show you some of the main concepts you should probably keep in mind when deploying a **FastAPI** application (although most of it applies to any other type of web application).
|
||||
|
||||
You will see more details to keep in mind and some of the techniques to do it in the next sections. ✨
|
||||
@@ -0,0 +1,157 @@
|
||||
# Run a Server Manually { #run-a-server-manually }
|
||||
|
||||
## Use the `fastapi run` Command { #use-the-fastapi-run-command }
|
||||
|
||||
In short, use `fastapi run` to serve your FastAPI application:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ <font color="#4E9A06">fastapi</font> run <u style="text-decoration-style:solid">main.py</u>
|
||||
|
||||
<span style="background-color:#009485"><font color="#D3D7CF"> FastAPI </font></span> Starting production server 🚀
|
||||
|
||||
Searching for package file structure from directories
|
||||
with <font color="#3465A4">__init__.py</font> files
|
||||
Importing from <font color="#75507B">/home/user/code/</font><font color="#AD7FA8">awesomeapp</font>
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> module </font></span> 🐍 main.py
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> code </font></span> Importing the FastAPI app object from the module with
|
||||
the following code:
|
||||
|
||||
<u style="text-decoration-style:solid">from </u><u style="text-decoration-style:solid"><b>main</b></u><u style="text-decoration-style:solid"> import </u><u style="text-decoration-style:solid"><b>app</b></u>
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> app </font></span> Using import string: <font color="#3465A4">main:app</font>
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> server </font></span> Server started at <font color="#729FCF"><u style="text-decoration-style:solid">http://0.0.0.0:8000</u></font>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> server </font></span> Documentation at <font color="#729FCF"><u style="text-decoration-style:solid">http://0.0.0.0:8000/docs</u></font>
|
||||
|
||||
Logs:
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Started server process <b>[</b><font color="#34E2E2"><b>2306215</b></font><b>]</b>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Waiting for application startup.
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Application startup complete.
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Uvicorn running on <font color="#729FCF"><u style="text-decoration-style:solid">http://0.0.0.0:8000</u></font> <b>(</b>Press CTRL+C
|
||||
to quit<b>)</b>
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
That would work for most of the cases. 😎
|
||||
|
||||
You could use that command for example to start your **FastAPI** app in a container, in a server, etc.
|
||||
|
||||
## ASGI Servers { #asgi-servers }
|
||||
|
||||
Let's go a little deeper into the details.
|
||||
|
||||
FastAPI uses a standard for building Python web frameworks and servers called <abbr title="Asynchronous Server Gateway Interface">ASGI</abbr>. FastAPI is an ASGI web framework.
|
||||
|
||||
The main thing you need to run a **FastAPI** application (or any other ASGI application) in a remote server machine is an ASGI server program like **Uvicorn**, this is the one that comes by default in the `fastapi` command.
|
||||
|
||||
There are several alternatives, including:
|
||||
|
||||
* <a href="https://www.uvicorn.dev/" class="external-link" target="_blank">Uvicorn</a>: a high performance ASGI server.
|
||||
* <a href="https://hypercorn.readthedocs.io/" class="external-link" target="_blank">Hypercorn</a>: an ASGI server compatible with HTTP/2 and Trio among other features.
|
||||
* <a href="https://github.com/django/daphne" class="external-link" target="_blank">Daphne</a>: the ASGI server built for Django Channels.
|
||||
* <a href="https://github.com/emmett-framework/granian" class="external-link" target="_blank">Granian</a>: A Rust HTTP server for Python applications.
|
||||
* <a href="https://unit.nginx.org/howto/fastapi/" class="external-link" target="_blank">NGINX Unit</a>: NGINX Unit is a lightweight and versatile web application runtime.
|
||||
|
||||
## Server Machine and Server Program { #server-machine-and-server-program }
|
||||
|
||||
There's a small detail about names to keep in mind. 💡
|
||||
|
||||
The word "**server**" is commonly used to refer to both the remote/cloud computer (the physical or virtual machine) and also the program that is running on that machine (e.g. Uvicorn).
|
||||
|
||||
Just keep in mind that when you read "server" in general, it could refer to one of those two things.
|
||||
|
||||
When referring to the remote machine, it's common to call it **server**, but also **machine**, **VM** (virtual machine), **node**. Those all refer to some type of remote machine, normally running Linux, where you run programs.
|
||||
|
||||
## Install the Server Program { #install-the-server-program }
|
||||
|
||||
When you install FastAPI, it comes with a production server, Uvicorn, and you can start it with the `fastapi run` command.
|
||||
|
||||
But you can also install an ASGI server manually.
|
||||
|
||||
Make sure you create a [virtual environment](../virtual-environments.md){.internal-link target=_blank}, activate it, and then you can install the server application.
|
||||
|
||||
For example, to install Uvicorn:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ pip install "uvicorn[standard]"
|
||||
|
||||
---> 100%
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
A similar process would apply to any other ASGI server program.
|
||||
|
||||
/// tip
|
||||
|
||||
By adding the `standard`, Uvicorn will install and use some recommended extra dependencies.
|
||||
|
||||
That including `uvloop`, the high-performance drop-in replacement for `asyncio`, that provides the big concurrency performance boost.
|
||||
|
||||
When you install FastAPI with something like `pip install "fastapi[standard]"` you already get `uvicorn[standard]` as well.
|
||||
|
||||
///
|
||||
|
||||
## Run the Server Program { #run-the-server-program }
|
||||
|
||||
If you installed an ASGI server manually, you would normally need to pass an import string in a special format for it to import your FastAPI application:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ uvicorn main:app --host 0.0.0.0 --port 80
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://0.0.0.0:80 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
/// note
|
||||
|
||||
The command `uvicorn main:app` refers to:
|
||||
|
||||
* `main`: the file `main.py` (the Python "module").
|
||||
* `app`: the object created inside of `main.py` with the line `app = FastAPI()`.
|
||||
|
||||
It is equivalent to:
|
||||
|
||||
```Python
|
||||
from main import app
|
||||
```
|
||||
|
||||
///
|
||||
|
||||
Each alternative ASGI server program would have a similar command, you can read more in their respective documentation.
|
||||
|
||||
/// warning
|
||||
|
||||
Uvicorn and other servers support a `--reload` option that is useful during development.
|
||||
|
||||
The `--reload` option consumes much more resources, is more unstable, etc.
|
||||
|
||||
It helps a lot during **development**, but you **shouldn't** use it in **production**.
|
||||
|
||||
///
|
||||
|
||||
## Deployment Concepts { #deployment-concepts }
|
||||
|
||||
These examples run the server program (e.g Uvicorn), starting **a single process**, listening on all the IPs (`0.0.0.0`) on a predefined port (e.g. `80`).
|
||||
|
||||
This is the basic idea. But you will probably want to take care of some additional things, like:
|
||||
|
||||
* Security - HTTPS
|
||||
* Running on startup
|
||||
* Restarts
|
||||
* Replication (the number of processes running)
|
||||
* Memory
|
||||
* Previous steps before starting
|
||||
|
||||
I'll tell you more about each of these concepts, how to think about them, and some concrete examples with strategies to handle them in the next chapters. 🚀
|
||||
@@ -0,0 +1,139 @@
|
||||
# Server Workers - Uvicorn with Workers { #server-workers-uvicorn-with-workers }
|
||||
|
||||
Let's check back those deployment concepts from before:
|
||||
|
||||
* Security - HTTPS
|
||||
* Running on startup
|
||||
* Restarts
|
||||
* **Replication (the number of processes running)**
|
||||
* Memory
|
||||
* Previous steps before starting
|
||||
|
||||
Up to this point, with all the tutorials in the docs, you have probably been running a **server program**, for example, using the `fastapi` command, that runs Uvicorn, running a **single process**.
|
||||
|
||||
When deploying applications you will probably want to have some **replication of processes** to take advantage of **multiple cores** and to be able to handle more requests.
|
||||
|
||||
As you saw in the previous chapter about [Deployment Concepts](concepts.md){.internal-link target=_blank}, there are multiple strategies you can use.
|
||||
|
||||
Here I'll show you how to use **Uvicorn** with **worker processes** using the `fastapi` command or the `uvicorn` command directly.
|
||||
|
||||
/// info
|
||||
|
||||
If you are using containers, for example with Docker or Kubernetes, I'll tell you more about that in the next chapter: [FastAPI in Containers - Docker](docker.md){.internal-link target=_blank}.
|
||||
|
||||
In particular, when running on **Kubernetes** you will probably **not** want to use workers and instead run **a single Uvicorn process per container**, but I'll tell you about it later in that chapter.
|
||||
|
||||
///
|
||||
|
||||
## Multiple Workers { #multiple-workers }
|
||||
|
||||
You can start multiple workers with the `--workers` command line option:
|
||||
|
||||
//// tab | `fastapi`
|
||||
|
||||
If you use the `fastapi` command:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ <font color="#4E9A06">fastapi</font> run --workers 4 <u style="text-decoration-style:solid">main.py</u>
|
||||
|
||||
<span style="background-color:#009485"><font color="#D3D7CF"> FastAPI </font></span> Starting production server 🚀
|
||||
|
||||
Searching for package file structure from directories with
|
||||
<font color="#3465A4">__init__.py</font> files
|
||||
Importing from <font color="#75507B">/home/user/code/</font><font color="#AD7FA8">awesomeapp</font>
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> module </font></span> 🐍 main.py
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> code </font></span> Importing the FastAPI app object from the module with the
|
||||
following code:
|
||||
|
||||
<u style="text-decoration-style:solid">from </u><u style="text-decoration-style:solid"><b>main</b></u><u style="text-decoration-style:solid"> import </u><u style="text-decoration-style:solid"><b>app</b></u>
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> app </font></span> Using import string: <font color="#3465A4">main:app</font>
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> server </font></span> Server started at <font color="#729FCF"><u style="text-decoration-style:solid">http://0.0.0.0:8000</u></font>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> server </font></span> Documentation at <font color="#729FCF"><u style="text-decoration-style:solid">http://0.0.0.0:8000/docs</u></font>
|
||||
|
||||
Logs:
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Uvicorn running on <font color="#729FCF"><u style="text-decoration-style:solid">http://0.0.0.0:8000</u></font> <b>(</b>Press CTRL+C to
|
||||
quit<b>)</b>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Started parent process <b>[</b><font color="#34E2E2"><b>27365</b></font><b>]</b>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Started server process <b>[</b><font color="#34E2E2"><b>27368</b></font><b>]</b>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Started server process <b>[</b><font color="#34E2E2"><b>27369</b></font><b>]</b>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Started server process <b>[</b><font color="#34E2E2"><b>27370</b></font><b>]</b>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Started server process <b>[</b><font color="#34E2E2"><b>27367</b></font><b>]</b>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Waiting for application startup.
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Waiting for application startup.
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Waiting for application startup.
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Waiting for application startup.
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Application startup complete.
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Application startup complete.
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Application startup complete.
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Application startup complete.
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
////
|
||||
|
||||
//// tab | `uvicorn`
|
||||
|
||||
If you prefer to use the `uvicorn` command directly:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ uvicorn main:app --host 0.0.0.0 --port 8080 --workers 4
|
||||
<font color="#A6E22E">INFO</font>: Uvicorn running on <b>http://0.0.0.0:8080</b> (Press CTRL+C to quit)
|
||||
<font color="#A6E22E">INFO</font>: Started parent process [<font color="#A1EFE4"><b>27365</b></font>]
|
||||
<font color="#A6E22E">INFO</font>: Started server process [<font color="#A1EFE4">27368</font>]
|
||||
<font color="#A6E22E">INFO</font>: Waiting for application startup.
|
||||
<font color="#A6E22E">INFO</font>: Application startup complete.
|
||||
<font color="#A6E22E">INFO</font>: Started server process [<font color="#A1EFE4">27369</font>]
|
||||
<font color="#A6E22E">INFO</font>: Waiting for application startup.
|
||||
<font color="#A6E22E">INFO</font>: Application startup complete.
|
||||
<font color="#A6E22E">INFO</font>: Started server process [<font color="#A1EFE4">27370</font>]
|
||||
<font color="#A6E22E">INFO</font>: Waiting for application startup.
|
||||
<font color="#A6E22E">INFO</font>: Application startup complete.
|
||||
<font color="#A6E22E">INFO</font>: Started server process [<font color="#A1EFE4">27367</font>]
|
||||
<font color="#A6E22E">INFO</font>: Waiting for application startup.
|
||||
<font color="#A6E22E">INFO</font>: Application startup complete.
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
////
|
||||
|
||||
The only new option here is `--workers` telling Uvicorn to start 4 worker processes.
|
||||
|
||||
You can also see that it shows the **PID** of each process, `27365` for the parent process (this is the **process manager**) and one for each worker process: `27368`, `27369`, `27370`, and `27367`.
|
||||
|
||||
## Deployment Concepts { #deployment-concepts }
|
||||
|
||||
Here you saw how to use multiple **workers** to **parallelize** the execution of the application, take advantage of **multiple cores** in the CPU, and be able to serve **more requests**.
|
||||
|
||||
From the list of deployment concepts from above, using workers would mainly help with the **replication** part, and a little bit with the **restarts**, but you still need to take care of the others:
|
||||
|
||||
* **Security - HTTPS**
|
||||
* **Running on startup**
|
||||
* ***Restarts***
|
||||
* Replication (the number of processes running)
|
||||
* **Memory**
|
||||
* **Previous steps before starting**
|
||||
|
||||
## Containers and Docker { #containers-and-docker }
|
||||
|
||||
In the next chapter about [FastAPI in Containers - Docker](docker.md){.internal-link target=_blank} I'll explain some strategies you could use to handle the other **deployment concepts**.
|
||||
|
||||
I'll show you how to **build your own image from scratch** to run a single Uvicorn process. It is a simple process and is probably what you would want to do when using a distributed container management system like **Kubernetes**.
|
||||
|
||||
## Recap { #recap }
|
||||
|
||||
You can use multiple worker processes with the `--workers` CLI option with the `fastapi` or `uvicorn` commands to take advantage of **multi-core CPUs**, to run **multiple processes in parallel**.
|
||||
|
||||
You could use these tools and ideas if you are setting up **your own deployment system** while taking care of the other deployment concepts yourself.
|
||||
|
||||
Check out the next chapter to learn about **FastAPI** with containers (e.g. Docker and Kubernetes). You will see that those tools have simple ways to solve the other **deployment concepts** as well. ✨
|
||||
@@ -0,0 +1,93 @@
|
||||
# About FastAPI versions { #about-fastapi-versions }
|
||||
|
||||
**FastAPI** is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly.
|
||||
|
||||
New features are added frequently, bugs are fixed regularly, and the code is still continuously improving.
|
||||
|
||||
That's why the current versions are still `0.x.x`, this reflects that each version could potentially have breaking changes. This follows the <a href="https://semver.org/" class="external-link" target="_blank">Semantic Versioning</a> conventions.
|
||||
|
||||
You can create production applications with **FastAPI** right now (and you have probably been doing it for some time), you just have to make sure that you use a version that works correctly with the rest of your code.
|
||||
|
||||
## Pin your `fastapi` version { #pin-your-fastapi-version }
|
||||
|
||||
The first thing you should do is to "pin" the version of **FastAPI** you are using to the specific latest version that you know works correctly for your application.
|
||||
|
||||
For example, let's say you are using version `0.112.0` in your app.
|
||||
|
||||
If you use a `requirements.txt` file you could specify the version with:
|
||||
|
||||
```txt
|
||||
fastapi[standard]==0.112.0
|
||||
```
|
||||
|
||||
that would mean that you would use exactly the version `0.112.0`.
|
||||
|
||||
Or you could also pin it with:
|
||||
|
||||
```txt
|
||||
fastapi[standard]>=0.112.0,<0.113.0
|
||||
```
|
||||
|
||||
that would mean that you would use the versions `0.112.0` or above, but less than `0.113.0`, for example, a version `0.112.2` would still be accepted.
|
||||
|
||||
If you use any other tool to manage your installations, like `uv`, Poetry, Pipenv, or others, they all have a way that you can use to define specific versions for your packages.
|
||||
|
||||
## Available versions { #available-versions }
|
||||
|
||||
You can see the available versions (e.g. to check what is the current latest) in the [Release Notes](../release-notes.md){.internal-link target=_blank}.
|
||||
|
||||
## About versions { #about-versions }
|
||||
|
||||
Following the Semantic Versioning conventions, any version below `1.0.0` could potentially add breaking changes.
|
||||
|
||||
FastAPI also follows the convention that any "PATCH" version change is for bug fixes and non-breaking changes.
|
||||
|
||||
/// tip
|
||||
|
||||
The "PATCH" is the last number, for example, in `0.2.3`, the PATCH version is `3`.
|
||||
|
||||
///
|
||||
|
||||
So, you should be able to pin to a version like:
|
||||
|
||||
```txt
|
||||
fastapi>=0.45.0,<0.46.0
|
||||
```
|
||||
|
||||
Breaking changes and new features are added in "MINOR" versions.
|
||||
|
||||
/// tip
|
||||
|
||||
The "MINOR" is the number in the middle, for example, in `0.2.3`, the MINOR version is `2`.
|
||||
|
||||
///
|
||||
|
||||
## Upgrading the FastAPI versions { #upgrading-the-fastapi-versions }
|
||||
|
||||
You should add tests for your app.
|
||||
|
||||
With **FastAPI** it's very easy (thanks to Starlette), check the docs: [Testing](../tutorial/testing.md){.internal-link target=_blank}
|
||||
|
||||
After you have tests, then you can upgrade the **FastAPI** version to a more recent one, and make sure that all your code is working correctly by running your tests.
|
||||
|
||||
If everything is working, or after you make the necessary changes, and all your tests are passing, then you can pin your `fastapi` to that new recent version.
|
||||
|
||||
## About Starlette { #about-starlette }
|
||||
|
||||
You shouldn't pin the version of `starlette`.
|
||||
|
||||
Different versions of **FastAPI** will use a specific newer version of Starlette.
|
||||
|
||||
So, you can just let **FastAPI** use the correct Starlette version.
|
||||
|
||||
## About Pydantic { #about-pydantic }
|
||||
|
||||
Pydantic includes the tests for **FastAPI** with its own tests, so new versions of Pydantic (above `1.0.0`) are always compatible with FastAPI.
|
||||
|
||||
You can pin Pydantic to any version above `1.0.0` that works for you.
|
||||
|
||||
For example:
|
||||
|
||||
```txt
|
||||
pydantic>=2.7.0,<3.0.0
|
||||
```
|
||||
@@ -0,0 +1,298 @@
|
||||
# Environment Variables { #environment-variables }
|
||||
|
||||
/// tip
|
||||
|
||||
If you already know what "environment variables" are and how to use them, feel free to skip this.
|
||||
|
||||
///
|
||||
|
||||
An environment variable (also known as "**env var**") is a variable that lives **outside** of the Python code, in the **operating system**, and could be read by your Python code (or by other programs as well).
|
||||
|
||||
Environment variables could be useful for handling application **settings**, as part of the **installation** of Python, etc.
|
||||
|
||||
## Create and Use Env Vars { #create-and-use-env-vars }
|
||||
|
||||
You can **create** and use environment variables in the **shell (terminal)**, without needing Python:
|
||||
|
||||
//// tab | Linux, macOS, Windows Bash
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
// You could create an env var MY_NAME with
|
||||
$ export MY_NAME="Wade Wilson"
|
||||
|
||||
// Then you could use it with other programs, like
|
||||
$ echo "Hello $MY_NAME"
|
||||
|
||||
Hello Wade Wilson
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
////
|
||||
|
||||
//// tab | Windows PowerShell
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
// Create an env var MY_NAME
|
||||
$ $Env:MY_NAME = "Wade Wilson"
|
||||
|
||||
// Use it with other programs, like
|
||||
$ echo "Hello $Env:MY_NAME"
|
||||
|
||||
Hello Wade Wilson
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
////
|
||||
|
||||
## Read env vars in Python { #read-env-vars-in-python }
|
||||
|
||||
You could also create environment variables **outside** of Python, in the terminal (or with any other method), and then **read them in Python**.
|
||||
|
||||
For example you could have a file `main.py` with:
|
||||
|
||||
```Python hl_lines="3"
|
||||
import os
|
||||
|
||||
name = os.getenv("MY_NAME", "World")
|
||||
print(f"Hello {name} from Python")
|
||||
```
|
||||
|
||||
/// tip
|
||||
|
||||
The second argument to <a href="https://docs.python.org/3.8/library/os.html#os.getenv" class="external-link" target="_blank">`os.getenv()`</a> is the default value to return.
|
||||
|
||||
If not provided, it's `None` by default, here we provide `"World"` as the default value to use.
|
||||
|
||||
///
|
||||
|
||||
Then you could call that Python program:
|
||||
|
||||
//// tab | Linux, macOS, Windows Bash
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
// Here we don't set the env var yet
|
||||
$ python main.py
|
||||
|
||||
// As we didn't set the env var, we get the default value
|
||||
|
||||
Hello World from Python
|
||||
|
||||
// But if we create an environment variable first
|
||||
$ export MY_NAME="Wade Wilson"
|
||||
|
||||
// And then call the program again
|
||||
$ python main.py
|
||||
|
||||
// Now it can read the environment variable
|
||||
|
||||
Hello Wade Wilson from Python
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
////
|
||||
|
||||
//// tab | Windows PowerShell
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
// Here we don't set the env var yet
|
||||
$ python main.py
|
||||
|
||||
// As we didn't set the env var, we get the default value
|
||||
|
||||
Hello World from Python
|
||||
|
||||
// But if we create an environment variable first
|
||||
$ $Env:MY_NAME = "Wade Wilson"
|
||||
|
||||
// And then call the program again
|
||||
$ python main.py
|
||||
|
||||
// Now it can read the environment variable
|
||||
|
||||
Hello Wade Wilson from Python
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
////
|
||||
|
||||
As environment variables can be set outside of the code, but can be read by the code, and don't have to be stored (committed to `git`) with the rest of the files, it's common to use them for configurations or **settings**.
|
||||
|
||||
You can also create an environment variable only for a **specific program invocation**, that is only available to that program, and only for its duration.
|
||||
|
||||
To do that, create it right before the program itself, on the same line:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
// Create an env var MY_NAME in line for this program call
|
||||
$ MY_NAME="Wade Wilson" python main.py
|
||||
|
||||
// Now it can read the environment variable
|
||||
|
||||
Hello Wade Wilson from Python
|
||||
|
||||
// The env var no longer exists afterwards
|
||||
$ python main.py
|
||||
|
||||
Hello World from Python
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
/// tip
|
||||
|
||||
You can read more about it at <a href="https://12factor.net/config" class="external-link" target="_blank">The Twelve-Factor App: Config</a>.
|
||||
|
||||
///
|
||||
|
||||
## Types and Validation { #types-and-validation }
|
||||
|
||||
These environment variables can only handle **text strings**, as they are external to Python and have to be compatible with other programs and the rest of the system (and even with different operating systems, as Linux, Windows, macOS).
|
||||
|
||||
That means that **any value** read in Python from an environment variable **will be a `str`**, and any conversion to a different type or any validation has to be done in code.
|
||||
|
||||
You will learn more about using environment variables for handling **application settings** in the [Advanced User Guide - Settings and Environment Variables](./advanced/settings.md){.internal-link target=_blank}.
|
||||
|
||||
## `PATH` Environment Variable { #path-environment-variable }
|
||||
|
||||
There is a **special** environment variable called **`PATH`** that is used by the operating systems (Linux, macOS, Windows) to find programs to run.
|
||||
|
||||
The value of the variable `PATH` is a long string that is made of directories separated by a colon `:` on Linux and macOS, and by a semicolon `;` on Windows.
|
||||
|
||||
For example, the `PATH` environment variable could look like this:
|
||||
|
||||
//// tab | Linux, macOS
|
||||
|
||||
```plaintext
|
||||
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
|
||||
```
|
||||
|
||||
This means that the system should look for programs in the directories:
|
||||
|
||||
* `/usr/local/bin`
|
||||
* `/usr/bin`
|
||||
* `/bin`
|
||||
* `/usr/sbin`
|
||||
* `/sbin`
|
||||
|
||||
////
|
||||
|
||||
//// tab | Windows
|
||||
|
||||
```plaintext
|
||||
C:\Program Files\Python312\Scripts;C:\Program Files\Python312;C:\Windows\System32
|
||||
```
|
||||
|
||||
This means that the system should look for programs in the directories:
|
||||
|
||||
* `C:\Program Files\Python312\Scripts`
|
||||
* `C:\Program Files\Python312`
|
||||
* `C:\Windows\System32`
|
||||
|
||||
////
|
||||
|
||||
When you type a **command** in the terminal, the operating system **looks for** the program in **each of those directories** listed in the `PATH` environment variable.
|
||||
|
||||
For example, when you type `python` in the terminal, the operating system looks for a program called `python` in the **first directory** in that list.
|
||||
|
||||
If it finds it, then it will **use it**. Otherwise it keeps looking in the **other directories**.
|
||||
|
||||
### Installing Python and Updating the `PATH` { #installing-python-and-updating-the-path }
|
||||
|
||||
When you install Python, you might be asked if you want to update the `PATH` environment variable.
|
||||
|
||||
//// tab | Linux, macOS
|
||||
|
||||
Let's say you install Python and it ends up in a directory `/opt/custompython/bin`.
|
||||
|
||||
If you say yes to update the `PATH` environment variable, then the installer will add `/opt/custompython/bin` to the `PATH` environment variable.
|
||||
|
||||
It could look like this:
|
||||
|
||||
```plaintext
|
||||
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/custompython/bin
|
||||
```
|
||||
|
||||
This way, when you type `python` in the terminal, the system will find the Python program in `/opt/custompython/bin` (the last directory) and use that one.
|
||||
|
||||
////
|
||||
|
||||
//// tab | Windows
|
||||
|
||||
Let's say you install Python and it ends up in a directory `C:\opt\custompython\bin`.
|
||||
|
||||
If you say yes to update the `PATH` environment variable, then the installer will add `C:\opt\custompython\bin` to the `PATH` environment variable.
|
||||
|
||||
```plaintext
|
||||
C:\Program Files\Python312\Scripts;C:\Program Files\Python312;C:\Windows\System32;C:\opt\custompython\bin
|
||||
```
|
||||
|
||||
This way, when you type `python` in the terminal, the system will find the Python program in `C:\opt\custompython\bin` (the last directory) and use that one.
|
||||
|
||||
////
|
||||
|
||||
So, if you type:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ python
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
//// tab | Linux, macOS
|
||||
|
||||
The system will **find** the `python` program in `/opt/custompython/bin` and run it.
|
||||
|
||||
It would be roughly equivalent to typing:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ /opt/custompython/bin/python
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
////
|
||||
|
||||
//// tab | Windows
|
||||
|
||||
The system will **find** the `python` program in `C:\opt\custompython\bin\python` and run it.
|
||||
|
||||
It would be roughly equivalent to typing:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ C:\opt\custompython\bin\python
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
////
|
||||
|
||||
This information will be useful when learning about [Virtual Environments](virtual-environments.md){.internal-link target=_blank}.
|
||||
|
||||
## Conclusion { #conclusion }
|
||||
|
||||
With this you should have a basic understanding of what **environment variables** are and how to use them in Python.
|
||||
|
||||
You can also read more about them in the <a href="https://en.wikipedia.org/wiki/Environment_variable" class="external-link" target="_blank">Wikipedia for Environment Variable</a>.
|
||||
|
||||
In many cases it's not very obvious how environment variables would be useful and applicable right away. But they keep showing up in many different scenarios when you are developing, so it's good to know about them.
|
||||
|
||||
For example, you will need this information in the next section, about [Virtual Environments](virtual-environments.md).
|
||||
@@ -0,0 +1,39 @@
|
||||
# External Links and Articles
|
||||
|
||||
**FastAPI** has a great community constantly growing.
|
||||
|
||||
There are many posts, articles, tools, and projects, related to **FastAPI**.
|
||||
|
||||
Here's an incomplete list of some of them.
|
||||
|
||||
/// tip
|
||||
|
||||
If you have an article, project, tool, or anything related to **FastAPI** that is not yet listed here, create a <a href="https://github.com/fastapi/fastapi/edit/master/docs/en/data/external_links.yml" class="external-link" target="_blank">Pull Request adding it</a>.
|
||||
|
||||
///
|
||||
|
||||
{% for section_name, section_content in external_links.items() %}
|
||||
|
||||
## {{ section_name }}
|
||||
|
||||
{% for lang_name, lang_content in section_content.items() %}
|
||||
|
||||
### {{ lang_name }}
|
||||
|
||||
{% for item in lang_content %}
|
||||
|
||||
* <a href="{{ item.link }}" class="external-link" target="_blank">{{ item.title }}</a> by <a href="{{ item.author_link }}" class="external-link" target="_blank">{{ item.author }}</a>.
|
||||
|
||||
{% endfor %}
|
||||
{% endfor %}
|
||||
{% endfor %}
|
||||
|
||||
## GitHub Repositories
|
||||
|
||||
Most starred GitHub repositories with the topic `fastapi`:
|
||||
|
||||
{% for repo in topic_repos %}
|
||||
|
||||
<a href={{repo.html_url}} target="_blank">★ {{repo.stars}} - {{repo.name}}</a> by <a href={{repo.owner_html_url}} target="_blank">@{{repo.owner_login}}</a>.
|
||||
|
||||
{% endfor %}
|
||||
@@ -0,0 +1,75 @@
|
||||
# FastAPI CLI { #fastapi-cli }
|
||||
|
||||
**FastAPI CLI** is a command line program that you can use to serve your FastAPI app, manage your FastAPI project, and more.
|
||||
|
||||
When you install FastAPI (e.g. with `pip install "fastapi[standard]"`), it includes a package called `fastapi-cli`, this package provides the `fastapi` command in the terminal.
|
||||
|
||||
To run your FastAPI app for development, you can use the `fastapi dev` command:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ <font color="#4E9A06">fastapi</font> dev <u style="text-decoration-style:solid">main.py</u>
|
||||
|
||||
<span style="background-color:#009485"><font color="#D3D7CF"> FastAPI </font></span> Starting development server 🚀
|
||||
|
||||
Searching for package file structure from directories with
|
||||
<font color="#3465A4">__init__.py</font> files
|
||||
Importing from <font color="#75507B">/home/user/code/</font><font color="#AD7FA8">awesomeapp</font>
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> module </font></span> 🐍 main.py
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> code </font></span> Importing the FastAPI app object from the module with the
|
||||
following code:
|
||||
|
||||
<u style="text-decoration-style:solid">from </u><u style="text-decoration-style:solid"><b>main</b></u><u style="text-decoration-style:solid"> import </u><u style="text-decoration-style:solid"><b>app</b></u>
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> app </font></span> Using import string: <font color="#3465A4">main:app</font>
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> server </font></span> Server started at <font color="#729FCF"><u style="text-decoration-style:solid">http://127.0.0.1:8000</u></font>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> server </font></span> Documentation at <font color="#729FCF"><u style="text-decoration-style:solid">http://127.0.0.1:8000/docs</u></font>
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> tip </font></span> Running in development mode, for production use:
|
||||
<b>fastapi run</b>
|
||||
|
||||
Logs:
|
||||
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Will watch for changes in these directories:
|
||||
<b>[</b><font color="#4E9A06">'/home/user/code/awesomeapp'</font><b>]</b>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Uvicorn running on <font color="#729FCF"><u style="text-decoration-style:solid">http://127.0.0.1:8000</u></font> <b>(</b>Press CTRL+C to
|
||||
quit<b>)</b>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Started reloader process <b>[</b><font color="#34E2E2"><b>383138</b></font><b>]</b> using WatchFiles
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Started server process <b>[</b><font color="#34E2E2"><b>383153</b></font><b>]</b>
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Waiting for application startup.
|
||||
<span style="background-color:#007166"><font color="#D3D7CF"> INFO </font></span> Application startup complete.
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
The command line program called `fastapi` is **FastAPI CLI**.
|
||||
|
||||
FastAPI CLI takes the path to your Python program (e.g. `main.py`) and automatically detects the `FastAPI` instance (commonly named `app`), determines the correct import process, and then serves it.
|
||||
|
||||
For production you would use `fastapi run` instead. 🚀
|
||||
|
||||
Internally, **FastAPI CLI** uses <a href="https://www.uvicorn.dev" class="external-link" target="_blank">Uvicorn</a>, a high-performance, production-ready, ASGI server. 😎
|
||||
|
||||
## `fastapi dev` { #fastapi-dev }
|
||||
|
||||
Running `fastapi dev` initiates development mode.
|
||||
|
||||
By default, **auto-reload** is enabled, automatically reloading the server when you make changes to your code. This is resource-intensive and could be less stable than when it's disabled. You should only use it for development. It also listens on the IP address `127.0.0.1`, which is the IP for your machine to communicate with itself alone (`localhost`).
|
||||
|
||||
## `fastapi run` { #fastapi-run }
|
||||
|
||||
Executing `fastapi run` starts FastAPI in production mode by default.
|
||||
|
||||
By default, **auto-reload** is disabled. It also listens on the IP address `0.0.0.0`, which means all the available IP addresses, this way it will be publicly accessible to anyone that can communicate with the machine. This is how you would normally run it in production, for example, in a container.
|
||||
|
||||
In most cases you would (and should) have a "termination proxy" handling HTTPS for you on top, this will depend on how you deploy your application, your provider might do this for you, or you might need to set it up yourself.
|
||||
|
||||
/// tip
|
||||
|
||||
You can learn more about it in the [deployment documentation](deployment/index.md){.internal-link target=_blank}.
|
||||
|
||||
///
|
||||
@@ -0,0 +1,305 @@
|
||||
---
|
||||
hide:
|
||||
- navigation
|
||||
---
|
||||
|
||||
# FastAPI People
|
||||
|
||||
FastAPI has an amazing community that welcomes people from all backgrounds.
|
||||
|
||||
## Creator
|
||||
|
||||
Hey! 👋
|
||||
|
||||
This is me:
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
{% for user in people.maintainers %}
|
||||
|
||||
<div class="user"><a href="{{ contributors.tiangolo.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ contributors.tiangolo.avatarUrl }}"/></div><div class="title">@{{ contributors.tiangolo.login }}</div></a> <div class="count">Answers: {{ user.answers }}</div><div class="count">Pull Requests: {{ contributors.tiangolo.count }}</div></div>
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
I'm the creator of **FastAPI**. You can read more about that in [Help FastAPI - Get Help - Connect with the author](help-fastapi.md#connect-with-the-author){.internal-link target=_blank}.
|
||||
|
||||
...But here I want to show you the community.
|
||||
|
||||
---
|
||||
|
||||
**FastAPI** receives a lot of support from the community. And I want to highlight their contributions.
|
||||
|
||||
These are the people that:
|
||||
|
||||
* [Help others with questions in GitHub](help-fastapi.md#help-others-with-questions-in-github){.internal-link target=_blank}.
|
||||
* [Create Pull Requests](help-fastapi.md#create-a-pull-request){.internal-link target=_blank}.
|
||||
* Review Pull Requests, [especially important for translations](contributing.md#translations){.internal-link target=_blank}.
|
||||
* Help [manage the repository](management-tasks.md){.internal-link target=_blank} (team members).
|
||||
|
||||
All these tasks help maintain the repository.
|
||||
|
||||
A round of applause to them. 👏 🙇
|
||||
|
||||
## Team
|
||||
|
||||
This is the current list of team members. 😎
|
||||
|
||||
They have different levels of involvement and permissions, they can perform [repository management tasks](./management-tasks.md){.internal-link target=_blank} and together we [manage the FastAPI repository](./management.md){.internal-link target=_blank}.
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
|
||||
{% for user in members["members"] %}
|
||||
|
||||
<div class="user"><a href="{{ user.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ user.avatar_url }}"/></div><div class="title">@{{ user.login }}</div></a></div>
|
||||
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
Although the team members have the permissions to perform privileged tasks, all the [help from others maintaining FastAPI](./help-fastapi.md#help-maintain-fastapi){.internal-link target=_blank} is very much appreciated! 🙇♂️
|
||||
|
||||
## FastAPI Experts
|
||||
|
||||
These are the users that have been [helping others the most with questions in GitHub](help-fastapi.md#help-others-with-questions-in-github){.internal-link target=_blank}. 🙇
|
||||
|
||||
They have proven to be **FastAPI Experts** by helping many others. ✨
|
||||
|
||||
/// tip
|
||||
|
||||
You could become an official FastAPI Expert too!
|
||||
|
||||
Just [help others with questions in GitHub](help-fastapi.md#help-others-with-questions-in-github){.internal-link target=_blank}. 🤓
|
||||
|
||||
///
|
||||
|
||||
You can see the **FastAPI Experts** for:
|
||||
|
||||
* [Last Month](#fastapi-experts-last-month) 🤓
|
||||
* [3 Months](#fastapi-experts-3-months) 😎
|
||||
* [6 Months](#fastapi-experts-6-months) 🧐
|
||||
* [1 Year](#fastapi-experts-1-year) 🧑🔬
|
||||
* [**All Time**](#fastapi-experts-all-time) 🧙
|
||||
|
||||
### FastAPI Experts - Last Month
|
||||
|
||||
These are the users that have been [helping others the most with questions in GitHub](help-fastapi.md#help-others-with-questions-in-github){.internal-link target=_blank} during the last month. 🤓
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
|
||||
{% for user in people.last_month_experts[:10] %}
|
||||
|
||||
{% if user.login not in skip_users %}
|
||||
|
||||
<div class="user"><a href="{{ user.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ user.avatarUrl }}"/></div><div class="title">@{{ user.login }}</div></a> <div class="count">Questions replied: {{ user.count }}</div></div>
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
### FastAPI Experts - 3 Months
|
||||
|
||||
These are the users that have been [helping others the most with questions in GitHub](help-fastapi.md#help-others-with-questions-in-github){.internal-link target=_blank} during the last 3 months. 😎
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
|
||||
{% for user in people.three_months_experts[:10] %}
|
||||
|
||||
{% if user.login not in skip_users %}
|
||||
|
||||
<div class="user"><a href="{{ user.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ user.avatarUrl }}"/></div><div class="title">@{{ user.login }}</div></a> <div class="count">Questions replied: {{ user.count }}</div></div>
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
### FastAPI Experts - 6 Months
|
||||
|
||||
These are the users that have been [helping others the most with questions in GitHub](help-fastapi.md#help-others-with-questions-in-github){.internal-link target=_blank} during the last 6 months. 🧐
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
|
||||
{% for user in people.six_months_experts[:10] %}
|
||||
|
||||
{% if user.login not in skip_users %}
|
||||
|
||||
<div class="user"><a href="{{ user.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ user.avatarUrl }}"/></div><div class="title">@{{ user.login }}</div></a> <div class="count">Questions replied: {{ user.count }}</div></div>
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
### FastAPI Experts - 1 Year
|
||||
|
||||
These are the users that have been [helping others the most with questions in GitHub](help-fastapi.md#help-others-with-questions-in-github){.internal-link target=_blank} during the last year. 🧑🔬
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
|
||||
{% for user in people.one_year_experts[:20] %}
|
||||
|
||||
{% if user.login not in skip_users %}
|
||||
|
||||
<div class="user"><a href="{{ user.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ user.avatarUrl }}"/></div><div class="title">@{{ user.login }}</div></a> <div class="count">Questions replied: {{ user.count }}</div></div>
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
### FastAPI Experts - All Time
|
||||
|
||||
Here are the all time **FastAPI Experts**. 🤓🤯
|
||||
|
||||
These are the users that have [helped others the most with questions in GitHub](help-fastapi.md#help-others-with-questions-in-github){.internal-link target=_blank} through *all time*. 🧙
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
|
||||
{% for user in people.experts[:50] %}
|
||||
|
||||
{% if user.login not in skip_users %}
|
||||
|
||||
<div class="user"><a href="{{ user.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ user.avatarUrl }}"/></div><div class="title">@{{ user.login }}</div></a> <div class="count">Questions replied: {{ user.count }}</div></div>
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
## Top Contributors
|
||||
|
||||
Here are the **Top Contributors**. 👷
|
||||
|
||||
These users have [created the most Pull Requests](help-fastapi.md#create-a-pull-request){.internal-link target=_blank} that have been *merged*.
|
||||
|
||||
They have contributed source code, documentation, etc. 📦
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
|
||||
{% for user in (contributors.values() | list)[:50] %}
|
||||
|
||||
{% if user.login not in skip_users %}
|
||||
|
||||
<div class="user"><a href="{{ user.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ user.avatarUrl }}"/></div><div class="title">@{{ user.login }}</div></a> <div class="count">Pull Requests: {{ user.count }}</div></div>
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
There are hundreds of other contributors, you can see them all in the <a href="https://github.com/fastapi/fastapi/graphs/contributors" class="external-link" target="_blank">FastAPI GitHub Contributors page</a>. 👷
|
||||
|
||||
## Top Translators
|
||||
|
||||
These are the **Top Translators**. 🌐
|
||||
|
||||
These users have created the most Pull Requests with [translations to other languages](contributing.md#translations){.internal-link target=_blank} that have been *merged*.
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
|
||||
{% for user in (translators.values() | list)[:50] %}
|
||||
|
||||
{% if user.login not in skip_users %}
|
||||
|
||||
<div class="user"><a href="{{ user.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ user.avatarUrl }}"/></div><div class="title">@{{ user.login }}</div></a> <div class="count">Translations: {{ user.count }}</div></div>
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
## Top Translation Reviewers
|
||||
|
||||
These users are the **Top Translation Reviewers**. 🕵️
|
||||
|
||||
I only speak a few languages (and not very well 😅). So, the reviewers are the ones that have the [**power to approve translations**](contributing.md#translations){.internal-link target=_blank} of the documentation. Without them, there wouldn't be documentation in several other languages.
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
{% for user in (translation_reviewers.values() | list)[:50] %}
|
||||
|
||||
{% if user.login not in skip_users %}
|
||||
|
||||
<div class="user"><a href="{{ user.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ user.avatarUrl }}"/></div><div class="title">@{{ user.login }}</div></a> <div class="count">Reviews: {{ user.count }}</div></div>
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
## Sponsors
|
||||
|
||||
These are the **Sponsors**. 😎
|
||||
|
||||
They are supporting my work with **FastAPI** (and others), mainly through <a href="https://github.com/sponsors/tiangolo" class="external-link" target="_blank">GitHub Sponsors</a>.
|
||||
|
||||
{% if sponsors %}
|
||||
|
||||
{% if sponsors.gold %}
|
||||
|
||||
### Gold Sponsors
|
||||
|
||||
{% for sponsor in sponsors.gold -%}
|
||||
<a href="{{ sponsor.url }}" target="_blank" title="{{ sponsor.title }}"><img src="{{ sponsor.img }}" style="border-radius:15px"></a>
|
||||
{% endfor %}
|
||||
{% endif %}
|
||||
|
||||
{% if sponsors.silver %}
|
||||
|
||||
### Silver Sponsors
|
||||
|
||||
{% for sponsor in sponsors.silver -%}
|
||||
<a href="{{ sponsor.url }}" target="_blank" title="{{ sponsor.title }}"><img src="{{ sponsor.img }}" style="border-radius:15px"></a>
|
||||
{% endfor %}
|
||||
{% endif %}
|
||||
|
||||
{% if sponsors.bronze %}
|
||||
|
||||
### Bronze Sponsors
|
||||
|
||||
{% for sponsor in sponsors.bronze -%}
|
||||
<a href="{{ sponsor.url }}" target="_blank" title="{{ sponsor.title }}"><img src="{{ sponsor.img }}" style="border-radius:15px"></a>
|
||||
{% endfor %}
|
||||
{% endif %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Individual Sponsors
|
||||
|
||||
{% if github_sponsors %}
|
||||
{% for group in github_sponsors.sponsors %}
|
||||
|
||||
<div class="user-list user-list-center">
|
||||
|
||||
{% for user in group %}
|
||||
{% if user.login not in sponsors_badge.logins %}
|
||||
|
||||
<div class="user"><a href="{{ user.url }}" target="_blank"><div class="avatar-wrapper"><img src="{{ user.avatarUrl }}"/></div><div class="title">@{{ user.login }}</div></a></div>
|
||||
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
|
||||
</div>
|
||||
|
||||
{% endfor %}
|
||||
{% endif %}
|
||||
|
||||
## About the data - technical details
|
||||
|
||||
The main intention of this page is to highlight the effort of the community to help others.
|
||||
|
||||
Especially including efforts that are normally less visible, and in many cases more arduous, like helping others with questions and reviewing Pull Requests with translations.
|
||||
|
||||
The data is calculated each month, you can read the <a href="https://github.com/fastapi/fastapi/blob/master/scripts/" class="external-link" target="_blank">source code here</a>.
|
||||
|
||||
Here I'm also highlighting contributions from sponsors.
|
||||
|
||||
I also reserve the right to update the algorithm, sections, thresholds, etc (just in case 🤷).
|
||||
@@ -0,0 +1,201 @@
|
||||
# Features { #features }
|
||||
|
||||
## FastAPI features { #fastapi-features }
|
||||
|
||||
**FastAPI** gives you the following:
|
||||
|
||||
### Based on open standards { #based-on-open-standards }
|
||||
|
||||
* <a href="https://github.com/OAI/OpenAPI-Specification" class="external-link" target="_blank"><strong>OpenAPI</strong></a> for API creation, including declarations of <abbr title="also known as: endpoints, routes">path</abbr> <abbr title="also known as HTTP methods, as POST, GET, PUT, DELETE">operations</abbr>, parameters, request bodies, security, etc.
|
||||
* Automatic data model documentation with <a href="https://json-schema.org/" class="external-link" target="_blank"><strong>JSON Schema</strong></a> (as OpenAPI itself is based on JSON Schema).
|
||||
* Designed around these standards, after a meticulous study. Instead of an afterthought layer on top.
|
||||
* This also allows using automatic **client code generation** in many languages.
|
||||
|
||||
### Automatic docs { #automatic-docs }
|
||||
|
||||
Interactive API documentation and exploration web user interfaces. As the framework is based on OpenAPI, there are multiple options, 2 included by default.
|
||||
|
||||
* <a href="https://github.com/swagger-api/swagger-ui" class="external-link" target="_blank"><strong>Swagger UI</strong></a>, with interactive exploration, call and test your API directly from the browser.
|
||||
|
||||
|
||||
|
||||
* Alternative API documentation with <a href="https://github.com/Rebilly/ReDoc" class="external-link" target="_blank"><strong>ReDoc</strong></a>.
|
||||
|
||||
|
||||
|
||||
### Just Modern Python { #just-modern-python }
|
||||
|
||||
It's all based on standard **Python type** declarations (thanks to Pydantic). No new syntax to learn. Just standard modern Python.
|
||||
|
||||
If you need a 2 minute refresher of how to use Python types (even if you don't use FastAPI), check the short tutorial: [Python Types](python-types.md){.internal-link target=_blank}.
|
||||
|
||||
You write standard Python with types:
|
||||
|
||||
```Python
|
||||
from datetime import date
|
||||
|
||||
from pydantic import BaseModel
|
||||
|
||||
# Declare a variable as a str
|
||||
# and get editor support inside the function
|
||||
def main(user_id: str):
|
||||
return user_id
|
||||
|
||||
|
||||
# A Pydantic model
|
||||
class User(BaseModel):
|
||||
id: int
|
||||
name: str
|
||||
joined: date
|
||||
```
|
||||
|
||||
That can then be used like:
|
||||
|
||||
```Python
|
||||
my_user: User = User(id=3, name="John Doe", joined="2018-07-19")
|
||||
|
||||
second_user_data = {
|
||||
"id": 4,
|
||||
"name": "Mary",
|
||||
"joined": "2018-11-30",
|
||||
}
|
||||
|
||||
my_second_user: User = User(**second_user_data)
|
||||
```
|
||||
|
||||
/// info
|
||||
|
||||
`**second_user_data` means:
|
||||
|
||||
Pass the keys and values of the `second_user_data` dict directly as key-value arguments, equivalent to: `User(id=4, name="Mary", joined="2018-11-30")`
|
||||
|
||||
///
|
||||
|
||||
### Editor support { #editor-support }
|
||||
|
||||
All the framework was designed to be easy and intuitive to use, all the decisions were tested on multiple editors even before starting development, to ensure the best development experience.
|
||||
|
||||
In the Python developer surveys, it's clear <a href="https://www.jetbrains.com/research/python-developers-survey-2017/#tools-and-features" class="external-link" target="_blank">that one of the most used features is "autocompletion"</a>.
|
||||
|
||||
The whole **FastAPI** framework is based to satisfy that. Autocompletion works everywhere.
|
||||
|
||||
You will rarely need to come back to the docs.
|
||||
|
||||
Here's how your editor might help you:
|
||||
|
||||
* in <a href="https://code.visualstudio.com/" class="external-link" target="_blank">Visual Studio Code</a>:
|
||||
|
||||
|
||||
|
||||
* in <a href="https://www.jetbrains.com/pycharm/" class="external-link" target="_blank">PyCharm</a>:
|
||||
|
||||
|
||||
|
||||
You will get completion in code you might even consider impossible before. As for example, the `price` key inside a JSON body (that could have been nested) that comes from a request.
|
||||
|
||||
No more typing the wrong key names, coming back and forth between docs, or scrolling up and down to find if you finally used `username` or `user_name`.
|
||||
|
||||
### Short { #short }
|
||||
|
||||
It has sensible **defaults** for everything, with optional configurations everywhere. All the parameters can be fine-tuned to do what you need and to define the API you need.
|
||||
|
||||
But by default, it all **"just works"**.
|
||||
|
||||
### Validation { #validation }
|
||||
|
||||
* Validation for most (or all?) Python **data types**, including:
|
||||
* JSON objects (`dict`).
|
||||
* JSON array (`list`) defining item types.
|
||||
* String (`str`) fields, defining min and max lengths.
|
||||
* Numbers (`int`, `float`) with min and max values, etc.
|
||||
|
||||
* Validation for more exotic types, like:
|
||||
* URL.
|
||||
* Email.
|
||||
* UUID.
|
||||
* ...and others.
|
||||
|
||||
All the validation is handled by the well-established and robust **Pydantic**.
|
||||
|
||||
### Security and authentication { #security-and-authentication }
|
||||
|
||||
Security and authentication integrated. Without any compromise with databases or data models.
|
||||
|
||||
All the security schemes defined in OpenAPI, including:
|
||||
|
||||
* HTTP Basic.
|
||||
* **OAuth2** (also with **JWT tokens**). Check the tutorial on [OAuth2 with JWT](tutorial/security/oauth2-jwt.md){.internal-link target=_blank}.
|
||||
* API keys in:
|
||||
* Headers.
|
||||
* Query parameters.
|
||||
* Cookies, etc.
|
||||
|
||||
Plus all the security features from Starlette (including **session cookies**).
|
||||
|
||||
All built as reusable tools and components that are easy to integrate with your systems, data stores, relational and NoSQL databases, etc.
|
||||
|
||||
### Dependency Injection { #dependency-injection }
|
||||
|
||||
FastAPI includes an extremely easy to use, but extremely powerful <abbr title='also known as "components", "resources", "services", "providers"'><strong>Dependency Injection</strong></abbr> system.
|
||||
|
||||
* Even dependencies can have dependencies, creating a hierarchy or **"graph" of dependencies**.
|
||||
* All **automatically handled** by the framework.
|
||||
* All the dependencies can require data from requests and **augment the path operation** constraints and automatic documentation.
|
||||
* **Automatic validation** even for *path operation* parameters defined in dependencies.
|
||||
* Support for complex user authentication systems, **database connections**, etc.
|
||||
* **No compromise** with databases, frontends, etc. But easy integration with all of them.
|
||||
|
||||
### Unlimited "plug-ins" { #unlimited-plug-ins }
|
||||
|
||||
Or in other way, no need for them, import and use the code you need.
|
||||
|
||||
Any integration is designed to be so simple to use (with dependencies) that you can create a "plug-in" for your application in 2 lines of code using the same structure and syntax used for your *path operations*.
|
||||
|
||||
### Tested { #tested }
|
||||
|
||||
* 100% <abbr title="The amount of code that is automatically tested">test coverage</abbr>.
|
||||
* 100% <abbr title="Python type annotations, with this your editor and external tools can give you better support">type annotated</abbr> code base.
|
||||
* Used in production applications.
|
||||
|
||||
## Starlette features { #starlette-features }
|
||||
|
||||
**FastAPI** is fully compatible with (and based on) <a href="https://www.starlette.dev/" class="external-link" target="_blank"><strong>Starlette</strong></a>. So, any additional Starlette code you have, will also work.
|
||||
|
||||
`FastAPI` is actually a sub-class of `Starlette`. So, if you already know or use Starlette, most of the functionality will work the same way.
|
||||
|
||||
With **FastAPI** you get all of **Starlette**'s features (as FastAPI is just Starlette on steroids):
|
||||
|
||||
* Seriously impressive performance. It is <a href="https://github.com/encode/starlette#performance" class="external-link" target="_blank">one of the fastest Python frameworks available, on par with **NodeJS** and **Go**</a>.
|
||||
* **WebSocket** support.
|
||||
* In-process background tasks.
|
||||
* Startup and shutdown events.
|
||||
* Test client built on HTTPX.
|
||||
* **CORS**, GZip, Static Files, Streaming responses.
|
||||
* **Session and Cookie** support.
|
||||
* 100% test coverage.
|
||||
* 100% type annotated codebase.
|
||||
|
||||
## Pydantic features { #pydantic-features }
|
||||
|
||||
**FastAPI** is fully compatible with (and based on) <a href="https://docs.pydantic.dev/" class="external-link" target="_blank"><strong>Pydantic</strong></a>. So, any additional Pydantic code you have, will also work.
|
||||
|
||||
Including external libraries also based on Pydantic, as <abbr title="Object-Relational Mapper">ORM</abbr>s, <abbr title="Object-Document Mapper">ODM</abbr>s for databases.
|
||||
|
||||
This also means that in many cases you can pass the same object you get from a request **directly to the database**, as everything is validated automatically.
|
||||
|
||||
The same applies the other way around, in many cases you can just pass the object you get from the database **directly to the client**.
|
||||
|
||||
With **FastAPI** you get all of **Pydantic**'s features (as FastAPI is based on Pydantic for all the data handling):
|
||||
|
||||
* **No brainfuck**:
|
||||
* No new schema definition micro-language to learn.
|
||||
* If you know Python types you know how to use Pydantic.
|
||||
* Plays nicely with your **<abbr title="Integrated Development Environment: similar to a code editor">IDE</abbr>/<abbr title="A program that checks for code errors">linter</abbr>/brain**:
|
||||
* Because pydantic data structures are just instances of classes you define; auto-completion, linting, mypy and your intuition should all work properly with your validated data.
|
||||
* Validate **complex structures**:
|
||||
* Use of hierarchical Pydantic models, Python `typing`’s `List` and `Dict`, etc.
|
||||
* And validators allow complex data schemas to be clearly and easily defined, checked and documented as JSON Schema.
|
||||
* You can have deeply **nested JSON** objects and have them all validated and annotated.
|
||||
* **Extensible**:
|
||||
* Pydantic allows custom data types to be defined or you can extend validation with methods on a model decorated with the validator decorator.
|
||||
* 100% test coverage.
|
||||
@@ -0,0 +1,256 @@
|
||||
# Help FastAPI - Get Help { #help-fastapi-get-help }
|
||||
|
||||
Do you like **FastAPI**?
|
||||
|
||||
Would you like to help FastAPI, other users, and the author?
|
||||
|
||||
Or would you like to get help with **FastAPI**?
|
||||
|
||||
There are very simple ways to help (several involve just one or two clicks).
|
||||
|
||||
And there are several ways to get help too.
|
||||
|
||||
## Subscribe to the newsletter { #subscribe-to-the-newsletter }
|
||||
|
||||
You can subscribe to the (infrequent) [**FastAPI and friends** newsletter](newsletter.md){.internal-link target=_blank} to stay updated about:
|
||||
|
||||
* News about FastAPI and friends 🚀
|
||||
* Guides 📝
|
||||
* Features ✨
|
||||
* Breaking changes 🚨
|
||||
* Tips and tricks ✅
|
||||
|
||||
## Follow FastAPI on X (Twitter) { #follow-fastapi-on-x-twitter }
|
||||
|
||||
<a href="https://x.com/fastapi" class="external-link" target="_blank">Follow @fastapi on **X (Twitter)**</a> to get the latest news about **FastAPI**. 🐦
|
||||
|
||||
## Star **FastAPI** in GitHub { #star-fastapi-in-github }
|
||||
|
||||
You can "star" FastAPI in GitHub (clicking the star button at the top right): <a href="https://github.com/fastapi/fastapi" class="external-link" target="_blank">https://github.com/fastapi/fastapi</a>. ⭐️
|
||||
|
||||
By adding a star, other users will be able to find it more easily and see that it has been already useful for others.
|
||||
|
||||
## Watch the GitHub repository for releases { #watch-the-github-repository-for-releases }
|
||||
|
||||
You can "watch" FastAPI in GitHub (clicking the "watch" button at the top right): <a href="https://github.com/fastapi/fastapi" class="external-link" target="_blank">https://github.com/fastapi/fastapi</a>. 👀
|
||||
|
||||
There you can select "Releases only".
|
||||
|
||||
By doing it, you will receive notifications (in your email) whenever there's a new release (a new version) of **FastAPI** with bug fixes and new features.
|
||||
|
||||
## Connect with the author { #connect-with-the-author }
|
||||
|
||||
You can connect with <a href="https://tiangolo.com" class="external-link" target="_blank">me (Sebastián Ramírez / `tiangolo`)</a>, the author.
|
||||
|
||||
You can:
|
||||
|
||||
* <a href="https://github.com/tiangolo" class="external-link" target="_blank">Follow me on **GitHub**</a>.
|
||||
* See other Open Source projects I have created that could help you.
|
||||
* Follow me to see when I create a new Open Source project.
|
||||
* <a href="https://x.com/tiangolo" class="external-link" target="_blank">Follow me on **X (Twitter)**</a> or <a href="https://fosstodon.org/@tiangolo" class="external-link" target="_blank">Mastodon</a>.
|
||||
* Tell me how you use FastAPI (I love to hear that).
|
||||
* Hear when I make announcements or release new tools.
|
||||
* You can also <a href="https://x.com/fastapi" class="external-link" target="_blank">follow @fastapi on X (Twitter)</a> (a separate account).
|
||||
* <a href="https://www.linkedin.com/in/tiangolo/" class="external-link" target="_blank">Follow me on **LinkedIn**</a>.
|
||||
* Hear when I make announcements or release new tools (although I use X (Twitter) more often 🤷♂).
|
||||
* Read what I write (or follow me) on <a href="https://dev.to/tiangolo" class="external-link" target="_blank">**Dev.to**</a> or <a href="https://medium.com/@tiangolo" class="external-link" target="_blank">**Medium**</a>.
|
||||
* Read other ideas, articles, and read about tools I have created.
|
||||
* Follow me to read when I publish something new.
|
||||
|
||||
## Tweet about **FastAPI** { #tweet-about-fastapi }
|
||||
|
||||
<a href="https://x.com/compose/tweet?text=I'm loving @fastapi because... https://github.com/fastapi/fastapi" class="external-link" target="_blank">Tweet about **FastAPI**</a> and let me and others know why you like it. 🎉
|
||||
|
||||
I love to hear about how **FastAPI** is being used, what you have liked in it, in which project/company are you using it, etc.
|
||||
|
||||
## Vote for FastAPI { #vote-for-fastapi }
|
||||
|
||||
* <a href="https://www.slant.co/options/34241/~fastapi-review" class="external-link" target="_blank">Vote for **FastAPI** in Slant</a>.
|
||||
* <a href="https://alternativeto.net/software/fastapi/about/" class="external-link" target="_blank">Vote for **FastAPI** in AlternativeTo</a>.
|
||||
* <a href="https://stackshare.io/pypi-fastapi" class="external-link" target="_blank">Say you use **FastAPI** on StackShare</a>.
|
||||
|
||||
## Help others with questions in GitHub { #help-others-with-questions-in-github }
|
||||
|
||||
You can try and help others with their questions in:
|
||||
|
||||
* <a href="https://github.com/fastapi/fastapi/discussions/categories/questions?discussions_q=category%3AQuestions+is%3Aunanswered" class="external-link" target="_blank">GitHub Discussions</a>
|
||||
* <a href="https://github.com/fastapi/fastapi/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Aquestion+-label%3Aanswered+" class="external-link" target="_blank">GitHub Issues</a>
|
||||
|
||||
In many cases you might already know the answer for those questions. 🤓
|
||||
|
||||
If you are helping a lot of people with their questions, you will become an official [FastAPI Expert](fastapi-people.md#fastapi-experts){.internal-link target=_blank}. 🎉
|
||||
|
||||
Just remember, the most important point is: try to be kind. People come with their frustrations and in many cases don't ask in the best way, but try as best as you can to be kind. 🤗
|
||||
|
||||
The idea is for the **FastAPI** community to be kind and welcoming. At the same time, don't accept bullying or disrespectful behavior towards others. We have to take care of each other.
|
||||
|
||||
---
|
||||
|
||||
Here's how to help others with questions (in discussions or issues):
|
||||
|
||||
### Understand the question { #understand-the-question }
|
||||
|
||||
* Check if you can understand what is the **purpose** and use case of the person asking.
|
||||
|
||||
* Then check if the question (the vast majority are questions) is **clear**.
|
||||
|
||||
* In many cases the question asked is about an imaginary solution from the user, but there might be a **better** one. If you can understand the problem and use case better, you might be able to suggest a better **alternative solution**.
|
||||
|
||||
* If you can't understand the question, ask for more **details**.
|
||||
|
||||
### Reproduce the problem { #reproduce-the-problem }
|
||||
|
||||
For most of the cases and most of the questions there's something related to the person's **original code**.
|
||||
|
||||
In many cases they will only copy a fragment of the code, but that's not enough to **reproduce the problem**.
|
||||
|
||||
* You can ask them to provide a <a href="https://stackoverflow.com/help/minimal-reproducible-example" class="external-link" target="_blank">minimal, reproducible, example</a>, that you can **copy-paste** and run locally to see the same error or behavior they are seeing, or to understand their use case better.
|
||||
|
||||
* If you are feeling too generous, you can try to **create an example** like that yourself, just based on the description of the problem. Just keep in mind that this might take a lot of time and it might be better to ask them to clarify the problem first.
|
||||
|
||||
### Suggest solutions { #suggest-solutions }
|
||||
|
||||
* After being able to understand the question, you can give them a possible **answer**.
|
||||
|
||||
* In many cases, it's better to understand their **underlying problem or use case**, because there might be a better way to solve it than what they are trying to do.
|
||||
|
||||
### Ask to close { #ask-to-close }
|
||||
|
||||
If they reply, there's a high chance you would have solved their problem, congrats, **you're a hero**! 🦸
|
||||
|
||||
* Now, if that solved their problem, you can ask them to:
|
||||
|
||||
* In GitHub Discussions: mark the comment as the **answer**.
|
||||
* In GitHub Issues: **close** the issue.
|
||||
|
||||
## Watch the GitHub repository { #watch-the-github-repository }
|
||||
|
||||
You can "watch" FastAPI in GitHub (clicking the "watch" button at the top right): <a href="https://github.com/fastapi/fastapi" class="external-link" target="_blank">https://github.com/fastapi/fastapi</a>. 👀
|
||||
|
||||
If you select "Watching" instead of "Releases only" you will receive notifications when someone creates a new issue or question. You can also specify that you only want to be notified about new issues, or discussions, or PRs, etc.
|
||||
|
||||
Then you can try and help them solve those questions.
|
||||
|
||||
## Ask Questions { #ask-questions }
|
||||
|
||||
You can <a href="https://github.com/fastapi/fastapi/discussions/new?category=questions" class="external-link" target="_blank">create a new question</a> in the GitHub repository, for example to:
|
||||
|
||||
* Ask a **question** or ask about a **problem**.
|
||||
* Suggest a new **feature**.
|
||||
|
||||
**Note**: if you do it, then I'm going to ask you to also help others. 😉
|
||||
|
||||
## Review Pull Requests { #review-pull-requests }
|
||||
|
||||
You can help me review pull requests from others.
|
||||
|
||||
Again, please try your best to be kind. 🤗
|
||||
|
||||
---
|
||||
|
||||
Here's what to keep in mind and how to review a pull request:
|
||||
|
||||
### Understand the problem { #understand-the-problem }
|
||||
|
||||
* First, make sure you **understand the problem** that the pull request is trying to solve. It might have a longer discussion in a GitHub Discussion or issue.
|
||||
|
||||
* There's also a good chance that the pull request is not actually needed because the problem can be solved in a **different way**. Then you can suggest or ask about that.
|
||||
|
||||
### Don't worry about style { #dont-worry-about-style }
|
||||
|
||||
* Don't worry too much about things like commit message styles, I will squash and merge customizing the commit manually.
|
||||
|
||||
* Also don't worry about style rules, there are already automatized tools checking that.
|
||||
|
||||
And if there's any other style or consistency need, I'll ask directly for that, or I'll add commits on top with the needed changes.
|
||||
|
||||
### Check the code { #check-the-code }
|
||||
|
||||
* Check and read the code, see if it makes sense, **run it locally** and see if it actually solves the problem.
|
||||
|
||||
* Then **comment** saying that you did that, that's how I will know you really checked it.
|
||||
|
||||
/// info
|
||||
|
||||
Unfortunately, I can't simply trust PRs that just have several approvals.
|
||||
|
||||
Several times it has happened that there are PRs with 3, 5 or more approvals, probably because the description is appealing, but when I check the PRs, they are actually broken, have a bug, or don't solve the problem they claim to solve. 😅
|
||||
|
||||
So, it's really important that you actually read and run the code, and let me know in the comments that you did. 🤓
|
||||
|
||||
///
|
||||
|
||||
* If the PR can be simplified in a way, you can ask for that, but there's no need to be too picky, there might be a lot of subjective points of view (and I will have my own as well 🙈), so it's better if you can focus on the fundamental things.
|
||||
|
||||
### Tests { #tests }
|
||||
|
||||
* Help me check that the PR has **tests**.
|
||||
|
||||
* Check that the tests **fail** before the PR. 🚨
|
||||
|
||||
* Then check that the tests **pass** after the PR. ✅
|
||||
|
||||
* Many PRs don't have tests, you can **remind** them to add tests, or you can even **suggest** some tests yourself. That's one of the things that consume most time and you can help a lot with that.
|
||||
|
||||
* Then also comment what you tried, that way I'll know that you checked it. 🤓
|
||||
|
||||
## Create a Pull Request { #create-a-pull-request }
|
||||
|
||||
You can [contribute](contributing.md){.internal-link target=_blank} to the source code with Pull Requests, for example:
|
||||
|
||||
* To fix a typo you found on the documentation.
|
||||
* To share an article, video, or podcast you created or found about FastAPI by <a href="https://github.com/fastapi/fastapi/edit/master/docs/en/data/external_links.yml" class="external-link" target="_blank">editing this file</a>.
|
||||
* Make sure you add your link to the start of the corresponding section.
|
||||
* To help [translate the documentation](contributing.md#translations){.internal-link target=_blank} to your language.
|
||||
* You can also help to review the translations created by others.
|
||||
* To propose new documentation sections.
|
||||
* To fix an existing issue/bug.
|
||||
* Make sure to add tests.
|
||||
* To add a new feature.
|
||||
* Make sure to add tests.
|
||||
* Make sure to add documentation if it's relevant.
|
||||
|
||||
## Help Maintain FastAPI { #help-maintain-fastapi }
|
||||
|
||||
Help me maintain **FastAPI**! 🤓
|
||||
|
||||
There's a lot of work to do, and for most of it, **YOU** can do it.
|
||||
|
||||
The main tasks that you can do right now are:
|
||||
|
||||
* [Help others with questions in GitHub](#help-others-with-questions-in-github){.internal-link target=_blank} (see the section above).
|
||||
* [Review Pull Requests](#review-pull-requests){.internal-link target=_blank} (see the section above).
|
||||
|
||||
Those two tasks are what **consume time the most**. That's the main work of maintaining FastAPI.
|
||||
|
||||
If you can help me with that, **you are helping me maintain FastAPI** and making sure it keeps **advancing faster and better**. 🚀
|
||||
|
||||
## Join the chat { #join-the-chat }
|
||||
|
||||
Join the 👥 <a href="https://discord.gg/VQjSZaeJmf" class="external-link" target="_blank">Discord chat server</a> 👥 and hang out with others in the FastAPI community.
|
||||
|
||||
/// tip
|
||||
|
||||
For questions, ask them in <a href="https://github.com/fastapi/fastapi/discussions/new?category=questions" class="external-link" target="_blank">GitHub Discussions</a>, there's a much better chance you will receive help by the [FastAPI Experts](fastapi-people.md#fastapi-experts){.internal-link target=_blank}.
|
||||
|
||||
Use the chat only for other general conversations.
|
||||
|
||||
///
|
||||
|
||||
### Don't use the chat for questions { #dont-use-the-chat-for-questions }
|
||||
|
||||
Keep in mind that as chats allow more "free conversation", it's easy to ask questions that are too general and more difficult to answer, so, you might not receive answers.
|
||||
|
||||
In GitHub, the template will guide you to write the right question so that you can more easily get a good answer, or even solve the problem yourself even before asking. And in GitHub I can make sure I always answer everything, even if it takes some time. I can't personally do that with the chat systems. 😅
|
||||
|
||||
Conversations in the chat systems are also not as easily searchable as in GitHub, so questions and answers might get lost in the conversation. And only the ones in GitHub count to become a [FastAPI Expert](fastapi-people.md#fastapi-experts){.internal-link target=_blank}, so you will most probably receive more attention in GitHub.
|
||||
|
||||
On the other side, there are thousands of users in the chat systems, so there's a high chance you'll find someone to talk to there, almost all the time. 😄
|
||||
|
||||
## Sponsor the author { #sponsor-the-author }
|
||||
|
||||
If your **product/company** depends on or is related to **FastAPI** and you want to reach its users, you can sponsor the author (me) through <a href="https://github.com/sponsors/tiangolo" class="external-link" target="_blank">GitHub sponsors</a>. Depending on the tier, you could get some extra benefits, like a badge in the docs. 🎁
|
||||
|
||||
---
|
||||
|
||||
Thanks! 🚀
|
||||
@@ -0,0 +1,79 @@
|
||||
# History, Design and Future { #history-design-and-future }
|
||||
|
||||
Some time ago, <a href="https://github.com/fastapi/fastapi/issues/3#issuecomment-454956920" class="external-link" target="_blank">a **FastAPI** user asked</a>:
|
||||
|
||||
> What’s the history of this project? It seems to have come from nowhere to awesome in a few weeks [...]
|
||||
|
||||
Here's a little bit of that history.
|
||||
|
||||
## Alternatives { #alternatives }
|
||||
|
||||
I have been creating APIs with complex requirements for several years (Machine Learning, distributed systems, asynchronous jobs, NoSQL databases, etc), leading several teams of developers.
|
||||
|
||||
As part of that, I needed to investigate, test and use many alternatives.
|
||||
|
||||
The history of **FastAPI** is in great part the history of its predecessors.
|
||||
|
||||
As said in the section [Alternatives](alternatives.md){.internal-link target=_blank}:
|
||||
|
||||
<blockquote markdown="1">
|
||||
|
||||
**FastAPI** wouldn't exist if not for the previous work of others.
|
||||
|
||||
There have been many tools created before that have helped inspire its creation.
|
||||
|
||||
I have been avoiding the creation of a new framework for several years. First I tried to solve all the features covered by **FastAPI** using many different frameworks, plug-ins, and tools.
|
||||
|
||||
But at some point, there was no other option than creating something that provided all these features, taking the best ideas from previous tools, and combining them in the best way possible, using language features that weren't even available before (Python 3.6+ type hints).
|
||||
|
||||
</blockquote>
|
||||
|
||||
## Investigation { #investigation }
|
||||
|
||||
By using all the previous alternatives I had the chance to learn from all of them, take ideas, and combine them in the best way I could find for myself and the teams of developers I have worked with.
|
||||
|
||||
For example, it was clear that ideally it should be based on standard Python type hints.
|
||||
|
||||
Also, the best approach was to use already existing standards.
|
||||
|
||||
So, before even starting to code **FastAPI**, I spent several months studying the specs for OpenAPI, JSON Schema, OAuth2, etc. Understanding their relationship, overlap, and differences.
|
||||
|
||||
## Design { #design }
|
||||
|
||||
Then I spent some time designing the developer "API" I wanted to have as a user (as a developer using FastAPI).
|
||||
|
||||
I tested several ideas in the most popular Python editors: PyCharm, VS Code, Jedi based editors.
|
||||
|
||||
By the last <a href="https://www.jetbrains.com/research/python-developers-survey-2018/#development-tools" class="external-link" target="_blank">Python Developer Survey</a>, that covers about 80% of the users.
|
||||
|
||||
It means that **FastAPI** was specifically tested with the editors used by 80% of the Python developers. And as most of the other editors tend to work similarly, all its benefits should work for virtually all editors.
|
||||
|
||||
That way I could find the best ways to reduce code duplication as much as possible, to have completion everywhere, type and error checks, etc.
|
||||
|
||||
All in a way that provided the best development experience for all the developers.
|
||||
|
||||
## Requirements { #requirements }
|
||||
|
||||
After testing several alternatives, I decided that I was going to use <a href="https://docs.pydantic.dev/" class="external-link" target="_blank">**Pydantic**</a> for its advantages.
|
||||
|
||||
Then I contributed to it, to make it fully compliant with JSON Schema, to support different ways to define constraint declarations, and to improve editor support (type checks, autocompletion) based on the tests in several editors.
|
||||
|
||||
During the development, I also contributed to <a href="https://www.starlette.dev/" class="external-link" target="_blank">**Starlette**</a>, the other key requirement.
|
||||
|
||||
## Development { #development }
|
||||
|
||||
By the time I started creating **FastAPI** itself, most of the pieces were already in place, the design was defined, the requirements and tools were ready, and the knowledge about the standards and specifications was clear and fresh.
|
||||
|
||||
## Future { #future }
|
||||
|
||||
By this point, it's already clear that **FastAPI** with its ideas is being useful for many people.
|
||||
|
||||
It is being chosen over previous alternatives for suiting many use cases better.
|
||||
|
||||
Many developers and teams already depend on **FastAPI** for their projects (including me and my team).
|
||||
|
||||
But still, there are many improvements and features to come.
|
||||
|
||||
**FastAPI** has a great future ahead.
|
||||
|
||||
And [your help](help-fastapi.md){.internal-link target=_blank} is greatly appreciated.
|
||||
@@ -0,0 +1,17 @@
|
||||
# Use Old 403 Authentication Error Status Codes { #use-old-403-authentication-error-status-codes }
|
||||
|
||||
Before FastAPI version `0.122.0`, when the integrated security utilities returned an error to the client after a failed authentication, they used the HTTP status code `403 Forbidden`.
|
||||
|
||||
Starting with FastAPI version `0.122.0`, they use the more appropriate HTTP status code `401 Unauthorized`, and return a sensible `WWW-Authenticate` header in the response, following the HTTP specifications, <a href="https://datatracker.ietf.org/doc/html/rfc7235#section-3.1" class="external-link" target="_blank">RFC 7235</a>, <a href="https://datatracker.ietf.org/doc/html/rfc9110#name-401-unauthorized" class="external-link" target="_blank">RFC 9110</a>.
|
||||
|
||||
But if for some reason your clients depend on the old behavior, you can revert to it by overriding the method `make_not_authenticated_error` in your security classes.
|
||||
|
||||
For example, you can create a subclass of `HTTPBearer` that returns a `403 Forbidden` error instead of the default `401 Unauthorized` error:
|
||||
|
||||
{* ../../docs_src/authentication_error_status_code/tutorial001_an_py39.py hl[9:13] *}
|
||||
|
||||
/// tip
|
||||
|
||||
Notice that the function returns the exception instance, it doesn't raise it. The raising is done in the rest of the internal code.
|
||||
|
||||
///
|
||||
@@ -0,0 +1,56 @@
|
||||
# Conditional OpenAPI { #conditional-openapi }
|
||||
|
||||
If you needed to, you could use settings and environment variables to configure OpenAPI conditionally depending on the environment, and even disable it entirely.
|
||||
|
||||
## About security, APIs, and docs { #about-security-apis-and-docs }
|
||||
|
||||
Hiding your documentation user interfaces in production *shouldn't* be the way to protect your API.
|
||||
|
||||
That doesn't add any extra security to your API, the *path operations* will still be available where they are.
|
||||
|
||||
If there's a security flaw in your code, it will still exist.
|
||||
|
||||
Hiding the documentation just makes it more difficult to understand how to interact with your API, and could make it more difficult for you to debug it in production. It could be considered simply a form of <a href="https://en.wikipedia.org/wiki/Security_through_obscurity" class="external-link" target="_blank">Security through obscurity</a>.
|
||||
|
||||
If you want to secure your API, there are several better things you can do, for example:
|
||||
|
||||
* Make sure you have well defined Pydantic models for your request bodies and responses.
|
||||
* Configure any required permissions and roles using dependencies.
|
||||
* Never store plaintext passwords, only password hashes.
|
||||
* Implement and use well-known cryptographic tools, like pwdlib and JWT tokens, etc.
|
||||
* Add more granular permission controls with OAuth2 scopes where needed.
|
||||
* ...etc.
|
||||
|
||||
Nevertheless, you might have a very specific use case where you really need to disable the API docs for some environment (e.g. for production) or depending on configurations from environment variables.
|
||||
|
||||
## Conditional OpenAPI from settings and env vars { #conditional-openapi-from-settings-and-env-vars }
|
||||
|
||||
You can easily use the same Pydantic settings to configure your generated OpenAPI and the docs UIs.
|
||||
|
||||
For example:
|
||||
|
||||
{* ../../docs_src/conditional_openapi/tutorial001.py hl[6,11] *}
|
||||
|
||||
Here we declare the setting `openapi_url` with the same default of `"/openapi.json"`.
|
||||
|
||||
And then we use it when creating the `FastAPI` app.
|
||||
|
||||
Then you could disable OpenAPI (including the UI docs) by setting the environment variable `OPENAPI_URL` to the empty string, like:
|
||||
|
||||
<div class="termy">
|
||||
|
||||
```console
|
||||
$ OPENAPI_URL= uvicorn main:app
|
||||
|
||||
<span style="color: green;">INFO</span>: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
Then if you go to the URLs at `/openapi.json`, `/docs`, or `/redoc` you will just get a `404 Not Found` error like:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"detail": "Not Found"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,70 @@
|
||||
# Configure Swagger UI { #configure-swagger-ui }
|
||||
|
||||
You can configure some extra <a href="https://swagger.io/docs/open-source-tools/swagger-ui/usage/configuration/" class="external-link" target="_blank">Swagger UI parameters</a>.
|
||||
|
||||
To configure them, pass the `swagger_ui_parameters` argument when creating the `FastAPI()` app object or to the `get_swagger_ui_html()` function.
|
||||
|
||||
`swagger_ui_parameters` receives a dictionary with the configurations passed to Swagger UI directly.
|
||||
|
||||
FastAPI converts the configurations to **JSON** to make them compatible with JavaScript, as that's what Swagger UI needs.
|
||||
|
||||
## Disable Syntax Highlighting { #disable-syntax-highlighting }
|
||||
|
||||
For example, you could disable syntax highlighting in Swagger UI.
|
||||
|
||||
Without changing the settings, syntax highlighting is enabled by default:
|
||||
|
||||
<img src="/img/tutorial/extending-openapi/image02.png">
|
||||
|
||||
But you can disable it by setting `syntaxHighlight` to `False`:
|
||||
|
||||
{* ../../docs_src/configure_swagger_ui/tutorial001.py hl[3] *}
|
||||
|
||||
...and then Swagger UI won't show the syntax highlighting anymore:
|
||||
|
||||
<img src="/img/tutorial/extending-openapi/image03.png">
|
||||
|
||||
## Change the Theme { #change-the-theme }
|
||||
|
||||
The same way you could set the syntax highlighting theme with the key `"syntaxHighlight.theme"` (notice that it has a dot in the middle):
|
||||
|
||||
{* ../../docs_src/configure_swagger_ui/tutorial002.py hl[3] *}
|
||||
|
||||
That configuration would change the syntax highlighting color theme:
|
||||
|
||||
<img src="/img/tutorial/extending-openapi/image04.png">
|
||||
|
||||
## Change Default Swagger UI Parameters { #change-default-swagger-ui-parameters }
|
||||
|
||||
FastAPI includes some default configuration parameters appropriate for most of the use cases.
|
||||
|
||||
It includes these default configurations:
|
||||
|
||||
{* ../../fastapi/openapi/docs.py ln[8:23] hl[17:23] *}
|
||||
|
||||
You can override any of them by setting a different value in the argument `swagger_ui_parameters`.
|
||||
|
||||
For example, to disable `deepLinking` you could pass these settings to `swagger_ui_parameters`:
|
||||
|
||||
{* ../../docs_src/configure_swagger_ui/tutorial003.py hl[3] *}
|
||||
|
||||
## Other Swagger UI Parameters { #other-swagger-ui-parameters }
|
||||
|
||||
To see all the other possible configurations you can use, read the official <a href="https://swagger.io/docs/open-source-tools/swagger-ui/usage/configuration/" class="external-link" target="_blank">docs for Swagger UI parameters</a>.
|
||||
|
||||
## JavaScript-only settings { #javascript-only-settings }
|
||||
|
||||
Swagger UI also allows other configurations to be **JavaScript-only** objects (for example, JavaScript functions).
|
||||
|
||||
FastAPI also includes these JavaScript-only `presets` settings:
|
||||
|
||||
```JavaScript
|
||||
presets: [
|
||||
SwaggerUIBundle.presets.apis,
|
||||
SwaggerUIBundle.SwaggerUIStandalonePreset
|
||||
]
|
||||
```
|
||||
|
||||
These are **JavaScript** objects, not strings, so you can't pass them from Python code directly.
|
||||
|
||||
If you need to use JavaScript-only configurations like those, you can use one of the methods above. Override all the Swagger UI *path operation* and manually write any JavaScript you need.
|
||||
@@ -0,0 +1,185 @@
|
||||
# Custom Docs UI Static Assets (Self-Hosting) { #custom-docs-ui-static-assets-self-hosting }
|
||||
|
||||
The API docs use **Swagger UI** and **ReDoc**, and each of those need some JavaScript and CSS files.
|
||||
|
||||
By default, those files are served from a <abbr title="Content Delivery Network: A service, normally composed of several servers, that provides static files, like JavaScript and CSS. It's commonly used to serve those files from the server closer to the client, improving performance.">CDN</abbr>.
|
||||
|
||||
But it's possible to customize it, you can set a specific CDN, or serve the files yourself.
|
||||
|
||||
## Custom CDN for JavaScript and CSS { #custom-cdn-for-javascript-and-css }
|
||||
|
||||
Let's say that you want to use a different <abbr title="Content Delivery Network">CDN</abbr>, for example you want to use `https://unpkg.com/`.
|
||||
|
||||
This could be useful if for example you live in a country that restricts some URLs.
|
||||
|
||||
### Disable the automatic docs { #disable-the-automatic-docs }
|
||||
|
||||
The first step is to disable the automatic docs, as by default, those use the default CDN.
|
||||
|
||||
To disable them, set their URLs to `None` when creating your `FastAPI` app:
|
||||
|
||||
{* ../../docs_src/custom_docs_ui/tutorial001.py hl[8] *}
|
||||
|
||||
### Include the custom docs { #include-the-custom-docs }
|
||||
|
||||
Now you can create the *path operations* for the custom docs.
|
||||
|
||||
You can reuse FastAPI's internal functions to create the HTML pages for the docs, and pass them the needed arguments:
|
||||
|
||||
* `openapi_url`: the URL where the HTML page for the docs can get the OpenAPI schema for your API. You can use here the attribute `app.openapi_url`.
|
||||
* `title`: the title of your API.
|
||||
* `oauth2_redirect_url`: you can use `app.swagger_ui_oauth2_redirect_url` here to use the default.
|
||||
* `swagger_js_url`: the URL where the HTML for your Swagger UI docs can get the **JavaScript** file. This is the custom CDN URL.
|
||||
* `swagger_css_url`: the URL where the HTML for your Swagger UI docs can get the **CSS** file. This is the custom CDN URL.
|
||||
|
||||
And similarly for ReDoc...
|
||||
|
||||
{* ../../docs_src/custom_docs_ui/tutorial001.py hl[2:6,11:19,22:24,27:33] *}
|
||||
|
||||
/// tip
|
||||
|
||||
The *path operation* for `swagger_ui_redirect` is a helper for when you use OAuth2.
|
||||
|
||||
If you integrate your API with an OAuth2 provider, you will be able to authenticate and come back to the API docs with the acquired credentials. And interact with it using the real OAuth2 authentication.
|
||||
|
||||
Swagger UI will handle it behind the scenes for you, but it needs this "redirect" helper.
|
||||
|
||||
///
|
||||
|
||||
### Create a *path operation* to test it { #create-a-path-operation-to-test-it }
|
||||
|
||||
Now, to be able to test that everything works, create a *path operation*:
|
||||
|
||||
{* ../../docs_src/custom_docs_ui/tutorial001.py hl[36:38] *}
|
||||
|
||||
### Test it { #test-it }
|
||||
|
||||
Now, you should be able to go to your docs at <a href="http://127.0.0.1:8000/docs" class="external-link" target="_blank">http://127.0.0.1:8000/docs</a>, and reload the page, it will load those assets from the new CDN.
|
||||
|
||||
## Self-hosting JavaScript and CSS for docs { #self-hosting-javascript-and-css-for-docs }
|
||||
|
||||
Self-hosting the JavaScript and CSS could be useful if, for example, you need your app to keep working even while offline, without open Internet access, or in a local network.
|
||||
|
||||
Here you'll see how to serve those files yourself, in the same FastAPI app, and configure the docs to use them.
|
||||
|
||||
### Project file structure { #project-file-structure }
|
||||
|
||||
Let's say your project file structure looks like this:
|
||||
|
||||
```
|
||||
.
|
||||
├── app
|
||||
│ ├── __init__.py
|
||||
│ ├── main.py
|
||||
```
|
||||
|
||||
Now create a directory to store those static files.
|
||||
|
||||
Your new file structure could look like this:
|
||||
|
||||
```
|
||||
.
|
||||
├── app
|
||||
│ ├── __init__.py
|
||||
│ ├── main.py
|
||||
└── static/
|
||||
```
|
||||
|
||||
### Download the files { #download-the-files }
|
||||
|
||||
Download the static files needed for the docs and put them on that `static/` directory.
|
||||
|
||||
You can probably right-click each link and select an option similar to "Save link as...".
|
||||
|
||||
**Swagger UI** uses the files:
|
||||
|
||||
* <a href="https://cdn.jsdelivr.net/npm/swagger-ui-dist@5/swagger-ui-bundle.js" class="external-link" target="_blank">`swagger-ui-bundle.js`</a>
|
||||
* <a href="https://cdn.jsdelivr.net/npm/swagger-ui-dist@5/swagger-ui.css" class="external-link" target="_blank">`swagger-ui.css`</a>
|
||||
|
||||
And **ReDoc** uses the file:
|
||||
|
||||
* <a href="https://cdn.jsdelivr.net/npm/redoc@2/bundles/redoc.standalone.js" class="external-link" target="_blank">`redoc.standalone.js`</a>
|
||||
|
||||
After that, your file structure could look like:
|
||||
|
||||
```
|
||||
.
|
||||
├── app
|
||||
│ ├── __init__.py
|
||||
│ ├── main.py
|
||||
└── static
|
||||
├── redoc.standalone.js
|
||||
├── swagger-ui-bundle.js
|
||||
└── swagger-ui.css
|
||||
```
|
||||
|
||||
### Serve the static files { #serve-the-static-files }
|
||||
|
||||
* Import `StaticFiles`.
|
||||
* "Mount" a `StaticFiles()` instance in a specific path.
|
||||
|
||||
{* ../../docs_src/custom_docs_ui/tutorial002.py hl[7,11] *}
|
||||
|
||||
### Test the static files { #test-the-static-files }
|
||||
|
||||
Start your application and go to <a href="http://127.0.0.1:8000/static/redoc.standalone.js" class="external-link" target="_blank">http://127.0.0.1:8000/static/redoc.standalone.js</a>.
|
||||
|
||||
You should see a very long JavaScript file for **ReDoc**.
|
||||
|
||||
It could start with something like:
|
||||
|
||||
```JavaScript
|
||||
/*! For license information please see redoc.standalone.js.LICENSE.txt */
|
||||
!function(e,t){"object"==typeof exports&&"object"==typeof module?module.exports=t(require("null")):
|
||||
...
|
||||
```
|
||||
|
||||
That confirms that you are being able to serve static files from your app, and that you placed the static files for the docs in the correct place.
|
||||
|
||||
Now we can configure the app to use those static files for the docs.
|
||||
|
||||
### Disable the automatic docs for static files { #disable-the-automatic-docs-for-static-files }
|
||||
|
||||
The same as when using a custom CDN, the first step is to disable the automatic docs, as those use the CDN by default.
|
||||
|
||||
To disable them, set their URLs to `None` when creating your `FastAPI` app:
|
||||
|
||||
{* ../../docs_src/custom_docs_ui/tutorial002.py hl[9] *}
|
||||
|
||||
### Include the custom docs for static files { #include-the-custom-docs-for-static-files }
|
||||
|
||||
And the same way as with a custom CDN, now you can create the *path operations* for the custom docs.
|
||||
|
||||
Again, you can reuse FastAPI's internal functions to create the HTML pages for the docs, and pass them the needed arguments:
|
||||
|
||||
* `openapi_url`: the URL where the HTML page for the docs can get the OpenAPI schema for your API. You can use here the attribute `app.openapi_url`.
|
||||
* `title`: the title of your API.
|
||||
* `oauth2_redirect_url`: you can use `app.swagger_ui_oauth2_redirect_url` here to use the default.
|
||||
* `swagger_js_url`: the URL where the HTML for your Swagger UI docs can get the **JavaScript** file. **This is the one that your own app is now serving**.
|
||||
* `swagger_css_url`: the URL where the HTML for your Swagger UI docs can get the **CSS** file. **This is the one that your own app is now serving**.
|
||||
|
||||
And similarly for ReDoc...
|
||||
|
||||
{* ../../docs_src/custom_docs_ui/tutorial002.py hl[2:6,14:22,25:27,30:36] *}
|
||||
|
||||
/// tip
|
||||
|
||||
The *path operation* for `swagger_ui_redirect` is a helper for when you use OAuth2.
|
||||
|
||||
If you integrate your API with an OAuth2 provider, you will be able to authenticate and come back to the API docs with the acquired credentials. And interact with it using the real OAuth2 authentication.
|
||||
|
||||
Swagger UI will handle it behind the scenes for you, but it needs this "redirect" helper.
|
||||
|
||||
///
|
||||
|
||||
### Create a *path operation* to test static files { #create-a-path-operation-to-test-static-files }
|
||||
|
||||
Now, to be able to test that everything works, create a *path operation*:
|
||||
|
||||
{* ../../docs_src/custom_docs_ui/tutorial002.py hl[39:41] *}
|
||||
|
||||
### Test Static Files UI { #test-static-files-ui }
|
||||
|
||||
Now, you should be able to disconnect your WiFi, go to your docs at <a href="http://127.0.0.1:8000/docs" class="external-link" target="_blank">http://127.0.0.1:8000/docs</a>, and reload the page.
|
||||
|
||||
And even without Internet, you would be able to see the docs for your API and interact with it.
|
||||
@@ -0,0 +1,109 @@
|
||||
# Custom Request and APIRoute class { #custom-request-and-apiroute-class }
|
||||
|
||||
In some cases, you may want to override the logic used by the `Request` and `APIRoute` classes.
|
||||
|
||||
In particular, this may be a good alternative to logic in a middleware.
|
||||
|
||||
For example, if you want to read or manipulate the request body before it is processed by your application.
|
||||
|
||||
/// danger
|
||||
|
||||
This is an "advanced" feature.
|
||||
|
||||
If you are just starting with **FastAPI** you might want to skip this section.
|
||||
|
||||
///
|
||||
|
||||
## Use cases { #use-cases }
|
||||
|
||||
Some use cases include:
|
||||
|
||||
* Converting non-JSON request bodies to JSON (e.g. <a href="https://msgpack.org/index.html" class="external-link" target="_blank">`msgpack`</a>).
|
||||
* Decompressing gzip-compressed request bodies.
|
||||
* Automatically logging all request bodies.
|
||||
|
||||
## Handling custom request body encodings { #handling-custom-request-body-encodings }
|
||||
|
||||
Let's see how to make use of a custom `Request` subclass to decompress gzip requests.
|
||||
|
||||
And an `APIRoute` subclass to use that custom request class.
|
||||
|
||||
### Create a custom `GzipRequest` class { #create-a-custom-gziprequest-class }
|
||||
|
||||
/// tip
|
||||
|
||||
This is a toy example to demonstrate how it works, if you need Gzip support, you can use the provided [`GzipMiddleware`](../advanced/middleware.md#gzipmiddleware){.internal-link target=_blank}.
|
||||
|
||||
///
|
||||
|
||||
First, we create a `GzipRequest` class, which will overwrite the `Request.body()` method to decompress the body in the presence of an appropriate header.
|
||||
|
||||
If there's no `gzip` in the header, it will not try to decompress the body.
|
||||
|
||||
That way, the same route class can handle gzip compressed or uncompressed requests.
|
||||
|
||||
{* ../../docs_src/custom_request_and_route/tutorial001.py hl[8:15] *}
|
||||
|
||||
### Create a custom `GzipRoute` class { #create-a-custom-gziproute-class }
|
||||
|
||||
Next, we create a custom subclass of `fastapi.routing.APIRoute` that will make use of the `GzipRequest`.
|
||||
|
||||
This time, it will overwrite the method `APIRoute.get_route_handler()`.
|
||||
|
||||
This method returns a function. And that function is what will receive a request and return a response.
|
||||
|
||||
Here we use it to create a `GzipRequest` from the original request.
|
||||
|
||||
{* ../../docs_src/custom_request_and_route/tutorial001.py hl[18:26] *}
|
||||
|
||||
/// note | Technical Details
|
||||
|
||||
A `Request` has a `request.scope` attribute, that's just a Python `dict` containing the metadata related to the request.
|
||||
|
||||
A `Request` also has a `request.receive`, that's a function to "receive" the body of the request.
|
||||
|
||||
The `scope` `dict` and `receive` function are both part of the ASGI specification.
|
||||
|
||||
And those two things, `scope` and `receive`, are what is needed to create a new `Request` instance.
|
||||
|
||||
To learn more about the `Request` check <a href="https://www.starlette.dev/requests/" class="external-link" target="_blank">Starlette's docs about Requests</a>.
|
||||
|
||||
///
|
||||
|
||||
The only thing the function returned by `GzipRequest.get_route_handler` does differently is convert the `Request` to a `GzipRequest`.
|
||||
|
||||
Doing this, our `GzipRequest` will take care of decompressing the data (if necessary) before passing it to our *path operations*.
|
||||
|
||||
After that, all of the processing logic is the same.
|
||||
|
||||
But because of our changes in `GzipRequest.body`, the request body will be automatically decompressed when it is loaded by **FastAPI** when needed.
|
||||
|
||||
## Accessing the request body in an exception handler { #accessing-the-request-body-in-an-exception-handler }
|
||||
|
||||
/// tip
|
||||
|
||||
To solve this same problem, it's probably a lot easier to use the `body` in a custom handler for `RequestValidationError` ([Handling Errors](../tutorial/handling-errors.md#use-the-requestvalidationerror-body){.internal-link target=_blank}).
|
||||
|
||||
But this example is still valid and it shows how to interact with the internal components.
|
||||
|
||||
///
|
||||
|
||||
We can also use this same approach to access the request body in an exception handler.
|
||||
|
||||
All we need to do is handle the request inside a `try`/`except` block:
|
||||
|
||||
{* ../../docs_src/custom_request_and_route/tutorial002.py hl[13,15] *}
|
||||
|
||||
If an exception occurs, the`Request` instance will still be in scope, so we can read and make use of the request body when handling the error:
|
||||
|
||||
{* ../../docs_src/custom_request_and_route/tutorial002.py hl[16:18] *}
|
||||
|
||||
## Custom `APIRoute` class in a router { #custom-apiroute-class-in-a-router }
|
||||
|
||||
You can also set the `route_class` parameter of an `APIRouter`:
|
||||
|
||||
{* ../../docs_src/custom_request_and_route/tutorial003.py hl[26] *}
|
||||
|
||||
In this example, the *path operations* under the `router` will use the custom `TimedRoute` class, and will have an extra `X-Response-Time` header in the response with the time it took to generate the response:
|
||||
|
||||
{* ../../docs_src/custom_request_and_route/tutorial003.py hl[13:20] *}
|
||||
@@ -0,0 +1,80 @@
|
||||
# Extending OpenAPI { #extending-openapi }
|
||||
|
||||
There are some cases where you might need to modify the generated OpenAPI schema.
|
||||
|
||||
In this section you will see how.
|
||||
|
||||
## The normal process { #the-normal-process }
|
||||
|
||||
The normal (default) process, is as follows.
|
||||
|
||||
A `FastAPI` application (instance) has an `.openapi()` method that is expected to return the OpenAPI schema.
|
||||
|
||||
As part of the application object creation, a *path operation* for `/openapi.json` (or for whatever you set your `openapi_url`) is registered.
|
||||
|
||||
It just returns a JSON response with the result of the application's `.openapi()` method.
|
||||
|
||||
By default, what the method `.openapi()` does is check the property `.openapi_schema` to see if it has contents and return them.
|
||||
|
||||
If it doesn't, it generates them using the utility function at `fastapi.openapi.utils.get_openapi`.
|
||||
|
||||
And that function `get_openapi()` receives as parameters:
|
||||
|
||||
* `title`: The OpenAPI title, shown in the docs.
|
||||
* `version`: The version of your API, e.g. `2.5.0`.
|
||||
* `openapi_version`: The version of the OpenAPI specification used. By default, the latest: `3.1.0`.
|
||||
* `summary`: A short summary of the API.
|
||||
* `description`: The description of your API, this can include markdown and will be shown in the docs.
|
||||
* `routes`: A list of routes, these are each of the registered *path operations*. They are taken from `app.routes`.
|
||||
|
||||
/// info
|
||||
|
||||
The parameter `summary` is available in OpenAPI 3.1.0 and above, supported by FastAPI 0.99.0 and above.
|
||||
|
||||
///
|
||||
|
||||
## Overriding the defaults { #overriding-the-defaults }
|
||||
|
||||
Using the information above, you can use the same utility function to generate the OpenAPI schema and override each part that you need.
|
||||
|
||||
For example, let's add <a href="https://github.com/Rebilly/ReDoc/blob/master/docs/redoc-vendor-extensions.md#x-logo" class="external-link" target="_blank">ReDoc's OpenAPI extension to include a custom logo</a>.
|
||||
|
||||
### Normal **FastAPI** { #normal-fastapi }
|
||||
|
||||
First, write all your **FastAPI** application as normally:
|
||||
|
||||
{* ../../docs_src/extending_openapi/tutorial001.py hl[1,4,7:9] *}
|
||||
|
||||
### Generate the OpenAPI schema { #generate-the-openapi-schema }
|
||||
|
||||
Then, use the same utility function to generate the OpenAPI schema, inside a `custom_openapi()` function:
|
||||
|
||||
{* ../../docs_src/extending_openapi/tutorial001.py hl[2,15:21] *}
|
||||
|
||||
### Modify the OpenAPI schema { #modify-the-openapi-schema }
|
||||
|
||||
Now you can add the ReDoc extension, adding a custom `x-logo` to the `info` "object" in the OpenAPI schema:
|
||||
|
||||
{* ../../docs_src/extending_openapi/tutorial001.py hl[22:24] *}
|
||||
|
||||
### Cache the OpenAPI schema { #cache-the-openapi-schema }
|
||||
|
||||
You can use the property `.openapi_schema` as a "cache", to store your generated schema.
|
||||
|
||||
That way, your application won't have to generate the schema every time a user opens your API docs.
|
||||
|
||||
It will be generated only once, and then the same cached schema will be used for the next requests.
|
||||
|
||||
{* ../../docs_src/extending_openapi/tutorial001.py hl[13:14,25:26] *}
|
||||
|
||||
### Override the method { #override-the-method }
|
||||
|
||||
Now you can replace the `.openapi()` method with your new function.
|
||||
|
||||
{* ../../docs_src/extending_openapi/tutorial001.py hl[29] *}
|
||||
|
||||
### Check it { #check-it }
|
||||
|
||||
Once you go to <a href="http://127.0.0.1:8000/redoc" class="external-link" target="_blank">http://127.0.0.1:8000/redoc</a> you will see that you are using your custom logo (in this example, **FastAPI**'s logo):
|
||||
|
||||
<img src="/img/tutorial/extending-openapi/image01.png">
|
||||
@@ -0,0 +1,39 @@
|
||||
# General - How To - Recipes { #general-how-to-recipes }
|
||||
|
||||
Here are several pointers to other places in the docs, for general or frequent questions.
|
||||
|
||||
## Filter Data - Security { #filter-data-security }
|
||||
|
||||
To ensure that you don't return more data than you should, read the docs for [Tutorial - Response Model - Return Type](../tutorial/response-model.md){.internal-link target=_blank}.
|
||||
|
||||
## Documentation Tags - OpenAPI { #documentation-tags-openapi }
|
||||
|
||||
To add tags to your *path operations*, and group them in the docs UI, read the docs for [Tutorial - Path Operation Configurations - Tags](../tutorial/path-operation-configuration.md#tags){.internal-link target=_blank}.
|
||||
|
||||
## Documentation Summary and Description - OpenAPI { #documentation-summary-and-description-openapi }
|
||||
|
||||
To add a summary and description to your *path operations*, and show them in the docs UI, read the docs for [Tutorial - Path Operation Configurations - Summary and Description](../tutorial/path-operation-configuration.md#summary-and-description){.internal-link target=_blank}.
|
||||
|
||||
## Documentation Response description - OpenAPI { #documentation-response-description-openapi }
|
||||
|
||||
To define the description of the response, shown in the docs UI, read the docs for [Tutorial - Path Operation Configurations - Response description](../tutorial/path-operation-configuration.md#response-description){.internal-link target=_blank}.
|
||||
|
||||
## Documentation Deprecate a *Path Operation* - OpenAPI { #documentation-deprecate-a-path-operation-openapi }
|
||||
|
||||
To deprecate a *path operation*, and show it in the docs UI, read the docs for [Tutorial - Path Operation Configurations - Deprecation](../tutorial/path-operation-configuration.md#deprecate-a-path-operation){.internal-link target=_blank}.
|
||||
|
||||
## Convert any Data to JSON-compatible { #convert-any-data-to-json-compatible }
|
||||
|
||||
To convert any data to JSON-compatible, read the docs for [Tutorial - JSON Compatible Encoder](../tutorial/encoder.md){.internal-link target=_blank}.
|
||||
|
||||
## OpenAPI Metadata - Docs { #openapi-metadata-docs }
|
||||
|
||||
To add metadata to your OpenAPI schema, including a license, version, contact, etc, read the docs for [Tutorial - Metadata and Docs URLs](../tutorial/metadata.md){.internal-link target=_blank}.
|
||||
|
||||
## OpenAPI Custom URL { #openapi-custom-url }
|
||||
|
||||
To customize the OpenAPI URL (or remove it), read the docs for [Tutorial - Metadata and Docs URLs](../tutorial/metadata.md#openapi-url){.internal-link target=_blank}.
|
||||
|
||||
## OpenAPI Docs URLs { #openapi-docs-urls }
|
||||
|
||||
To update the URLs used for the automatically generated docs user interfaces, read the docs for [Tutorial - Metadata and Docs URLs](../tutorial/metadata.md#docs-urls){.internal-link target=_blank}.
|
||||
@@ -0,0 +1,60 @@
|
||||
# GraphQL { #graphql }
|
||||
|
||||
As **FastAPI** is based on the **ASGI** standard, it's very easy to integrate any **GraphQL** library also compatible with ASGI.
|
||||
|
||||
You can combine normal FastAPI *path operations* with GraphQL on the same application.
|
||||
|
||||
/// tip
|
||||
|
||||
**GraphQL** solves some very specific use cases.
|
||||
|
||||
It has **advantages** and **disadvantages** when compared to common **web APIs**.
|
||||
|
||||
Make sure you evaluate if the **benefits** for your use case compensate the **drawbacks**. 🤓
|
||||
|
||||
///
|
||||
|
||||
## GraphQL Libraries { #graphql-libraries }
|
||||
|
||||
Here are some of the **GraphQL** libraries that have **ASGI** support. You could use them with **FastAPI**:
|
||||
|
||||
* <a href="https://strawberry.rocks/" class="external-link" target="_blank">Strawberry</a> 🍓
|
||||
* With <a href="https://strawberry.rocks/docs/integrations/fastapi" class="external-link" target="_blank">docs for FastAPI</a>
|
||||
* <a href="https://ariadnegraphql.org/" class="external-link" target="_blank">Ariadne</a>
|
||||
* With <a href="https://ariadnegraphql.org/docs/fastapi-integration" class="external-link" target="_blank">docs for FastAPI</a>
|
||||
* <a href="https://tartiflette.io/" class="external-link" target="_blank">Tartiflette</a>
|
||||
* With <a href="https://tartiflette.github.io/tartiflette-asgi/" class="external-link" target="_blank">Tartiflette ASGI</a> to provide ASGI integration
|
||||
* <a href="https://graphene-python.org/" class="external-link" target="_blank">Graphene</a>
|
||||
* With <a href="https://github.com/ciscorn/starlette-graphene3" class="external-link" target="_blank">starlette-graphene3</a>
|
||||
|
||||
## GraphQL with Strawberry { #graphql-with-strawberry }
|
||||
|
||||
If you need or want to work with **GraphQL**, <a href="https://strawberry.rocks/" class="external-link" target="_blank">**Strawberry**</a> is the **recommended** library as it has the design closest to **FastAPI's** design, it's all based on **type annotations**.
|
||||
|
||||
Depending on your use case, you might prefer to use a different library, but if you asked me, I would probably suggest you try **Strawberry**.
|
||||
|
||||
Here's a small preview of how you could integrate Strawberry with FastAPI:
|
||||
|
||||
{* ../../docs_src/graphql/tutorial001.py hl[3,22,25] *}
|
||||
|
||||
You can learn more about Strawberry in the <a href="https://strawberry.rocks/" class="external-link" target="_blank">Strawberry documentation</a>.
|
||||
|
||||
And also the docs about <a href="https://strawberry.rocks/docs/integrations/fastapi" class="external-link" target="_blank">Strawberry with FastAPI</a>.
|
||||
|
||||
## Older `GraphQLApp` from Starlette { #older-graphqlapp-from-starlette }
|
||||
|
||||
Previous versions of Starlette included a `GraphQLApp` class to integrate with <a href="https://graphene-python.org/" class="external-link" target="_blank">Graphene</a>.
|
||||
|
||||
It was deprecated from Starlette, but if you have code that used it, you can easily **migrate** to <a href="https://github.com/ciscorn/starlette-graphene3" class="external-link" target="_blank">starlette-graphene3</a>, that covers the same use case and has an **almost identical interface**.
|
||||
|
||||
/// tip
|
||||
|
||||
If you need GraphQL, I still would recommend you check out <a href="https://strawberry.rocks/" class="external-link" target="_blank">Strawberry</a>, as it's based on type annotations instead of custom classes and types.
|
||||
|
||||
///
|
||||
|
||||
## Learn More { #learn-more }
|
||||
|
||||
You can learn more about **GraphQL** in the <a href="https://graphql.org/" class="external-link" target="_blank">official GraphQL documentation</a>.
|
||||
|
||||
You can also read more about each those libraries described above in their links.
|
||||
@@ -0,0 +1,13 @@
|
||||
# How To - Recipes { #how-to-recipes }
|
||||
|
||||
Here you will see different recipes or "how to" guides for **several topics**.
|
||||
|
||||
Most of these ideas would be more or less **independent**, and in most cases you should only need to study them if they apply directly to **your project**.
|
||||
|
||||
If something seems interesting and useful to your project, go ahead and check it, but otherwise, you might probably just skip them.
|
||||
|
||||
/// tip
|
||||
|
||||
If you want to **learn FastAPI** in a structured way (recommended), go and read the [Tutorial - User Guide](../tutorial/index.md){.internal-link target=_blank} chapter by chapter instead.
|
||||
|
||||
///
|
||||
@@ -0,0 +1,133 @@
|
||||
# Migrate from Pydantic v1 to Pydantic v2 { #migrate-from-pydantic-v1-to-pydantic-v2 }
|
||||
|
||||
If you have an old FastAPI app, you might be using Pydantic version 1.
|
||||
|
||||
FastAPI has had support for either Pydantic v1 or v2 since version 0.100.0.
|
||||
|
||||
If you had installed Pydantic v2, it would use it. If instead you had Pydantic v1, it would use that.
|
||||
|
||||
Pydantic v1 is now deprecated and support for it will be removed in the next versions of FastAPI, you should **migrate to Pydantic v2**. This way you will get the latest features, improvements, and fixes.
|
||||
|
||||
/// warning
|
||||
|
||||
Also, the Pydantic team stopped support for Pydantic v1 for the latest versions of Python, starting with **Python 3.14**.
|
||||
|
||||
If you want to use the latest features of Python, you will need to make sure you use Pydantic v2.
|
||||
|
||||
///
|
||||
|
||||
If you have an old FastAPI app with Pydantic v1, here I'll show you how to migrate it to Pydantic v2, and the **new features in FastAPI 0.119.0** to help you with a gradual migration.
|
||||
|
||||
## Official Guide { #official-guide }
|
||||
|
||||
Pydantic has an official <a href="https://docs.pydantic.dev/latest/migration/" class="external-link" target="_blank">Migration Guide</a> from v1 to v2.
|
||||
|
||||
It also includes what has changed, how validations are now more correct and strict, possible caveats, etc.
|
||||
|
||||
You can read it to understand better what has changed.
|
||||
|
||||
## Tests { #tests }
|
||||
|
||||
Make sure you have [tests](../tutorial/testing.md){.internal-link target=_blank} for your app and you run them on continuous integration (CI).
|
||||
|
||||
This way, you can do the upgrade and make sure everything is still working as expected.
|
||||
|
||||
## `bump-pydantic` { #bump-pydantic }
|
||||
|
||||
In many cases, when you use regular Pydantic models without customizations, you will be able to automate most of the process of migrating from Pydantic v1 to Pydantic v2.
|
||||
|
||||
You can use <a href="https://github.com/pydantic/bump-pydantic" class="external-link" target="_blank">`bump-pydantic`</a> from the same Pydantic team.
|
||||
|
||||
This tool will help you to automatically change most of the code that needs to be changed.
|
||||
|
||||
After this, you can run the tests and check if everything works. If it does, you are done. 😎
|
||||
|
||||
## Pydantic v1 in v2 { #pydantic-v1-in-v2 }
|
||||
|
||||
Pydantic v2 includes everything from Pydantic v1 as a submodule `pydantic.v1`.
|
||||
|
||||
This means that you can install the latest version of Pydantic v2 and import and use the old Pydantic v1 components from this submodule, as if you had the old Pydantic v1 installed.
|
||||
|
||||
{* ../../docs_src/pydantic_v1_in_v2/tutorial001_an_py310.py hl[1,4] *}
|
||||
|
||||
### FastAPI support for Pydantic v1 in v2 { #fastapi-support-for-pydantic-v1-in-v2 }
|
||||
|
||||
Since FastAPI 0.119.0, there's also partial support for Pydantic v1 from inside of Pydantic v2, to facilitate the migration to v2.
|
||||
|
||||
So, you could upgrade Pydantic to the latest version 2, and change the imports to use the `pydantic.v1` submodule, and in many cases it would just work.
|
||||
|
||||
{* ../../docs_src/pydantic_v1_in_v2/tutorial002_an_py310.py hl[2,5,15] *}
|
||||
|
||||
/// warning
|
||||
|
||||
Have in mind that as the Pydantic team no longer supports Pydantic v1 in recent versions of Python, starting from Python 3.14, using `pydantic.v1` is also not supported in Python 3.14 and above.
|
||||
|
||||
///
|
||||
|
||||
### Pydantic v1 and v2 on the same app { #pydantic-v1-and-v2-on-the-same-app }
|
||||
|
||||
It's **not supported** by Pydantic to have a model of Pydantic v2 with its own fields defined as Pydantic v1 models or vice versa.
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "❌ Not Supported"
|
||||
direction TB
|
||||
subgraph V2["Pydantic v2 Model"]
|
||||
V1Field["Pydantic v1 Model"]
|
||||
end
|
||||
subgraph V1["Pydantic v1 Model"]
|
||||
V2Field["Pydantic v2 Model"]
|
||||
end
|
||||
end
|
||||
|
||||
style V2 fill:#f9fff3
|
||||
style V1 fill:#fff6f0
|
||||
style V1Field fill:#fff6f0
|
||||
style V2Field fill:#f9fff3
|
||||
```
|
||||
|
||||
...but, you can have separated models using Pydantic v1 and v2 in the same app.
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "✅ Supported"
|
||||
direction TB
|
||||
subgraph V2["Pydantic v2 Model"]
|
||||
V2Field["Pydantic v2 Model"]
|
||||
end
|
||||
subgraph V1["Pydantic v1 Model"]
|
||||
V1Field["Pydantic v1 Model"]
|
||||
end
|
||||
end
|
||||
|
||||
style V2 fill:#f9fff3
|
||||
style V1 fill:#fff6f0
|
||||
style V1Field fill:#fff6f0
|
||||
style V2Field fill:#f9fff3
|
||||
```
|
||||
|
||||
In some cases, it's even possible to have both Pydantic v1 and v2 models in the same **path operation** in your FastAPI app:
|
||||
|
||||
{* ../../docs_src/pydantic_v1_in_v2/tutorial003_an_py310.py hl[2:3,6,12,21:22] *}
|
||||
|
||||
In this example above, the input model is a Pydantic v1 model, and the output model (defined in `response_model=ItemV2`) is a Pydantic v2 model.
|
||||
|
||||
### Pydantic v1 parameters { #pydantic-v1-parameters }
|
||||
|
||||
If you need to use some of the FastAPI-specific tools for parameters like `Body`, `Query`, `Form`, etc. with Pydantic v1 models, you can import them from `fastapi.temp_pydantic_v1_params` while you finish the migration to Pydantic v2:
|
||||
|
||||
{* ../../docs_src/pydantic_v1_in_v2/tutorial004_an_py310.py hl[4,18] *}
|
||||
|
||||
### Migrate in steps { #migrate-in-steps }
|
||||
|
||||
/// tip
|
||||
|
||||
First try with `bump-pydantic`, if your tests pass and that works, then you're done in one command. ✨
|
||||
|
||||
///
|
||||
|
||||
If `bump-pydantic` doesn't work for your use case, you can use the support for both Pydantic v1 and v2 models in the same app to do the migration to Pydantic v2 gradually.
|
||||
|
||||
You could fist upgrade Pydantic to use the latest version 2, and change the imports to use `pydantic.v1` for all your models.
|
||||
|
||||
Then, you can start migrating your models from Pydantic v1 to v2 in groups, in gradual steps. 🚶
|
||||
@@ -0,0 +1,104 @@
|
||||
# Separate OpenAPI Schemas for Input and Output or Not { #separate-openapi-schemas-for-input-and-output-or-not }
|
||||
|
||||
When using **Pydantic v2**, the generated OpenAPI is a bit more exact and **correct** than before. 😎
|
||||
|
||||
In fact, in some cases, it will even have **two JSON Schemas** in OpenAPI for the same Pydantic model, for input and output, depending on if they have **default values**.
|
||||
|
||||
Let's see how that works and how to change it if you need to do that.
|
||||
|
||||
## Pydantic Models for Input and Output { #pydantic-models-for-input-and-output }
|
||||
|
||||
Let's say you have a Pydantic model with default values, like this one:
|
||||
|
||||
{* ../../docs_src/separate_openapi_schemas/tutorial001_py310.py ln[1:7] hl[7] *}
|
||||
|
||||
### Model for Input { #model-for-input }
|
||||
|
||||
If you use this model as an input like here:
|
||||
|
||||
{* ../../docs_src/separate_openapi_schemas/tutorial001_py310.py ln[1:15] hl[14] *}
|
||||
|
||||
...then the `description` field will **not be required**. Because it has a default value of `None`.
|
||||
|
||||
### Input Model in Docs { #input-model-in-docs }
|
||||
|
||||
You can confirm that in the docs, the `description` field doesn't have a **red asterisk**, it's not marked as required:
|
||||
|
||||
<div class="screenshot">
|
||||
<img src="/img/tutorial/separate-openapi-schemas/image01.png">
|
||||
</div>
|
||||
|
||||
### Model for Output { #model-for-output }
|
||||
|
||||
But if you use the same model as an output, like here:
|
||||
|
||||
{* ../../docs_src/separate_openapi_schemas/tutorial001_py310.py hl[19] *}
|
||||
|
||||
...then because `description` has a default value, if you **don't return anything** for that field, it will still have that **default value**.
|
||||
|
||||
### Model for Output Response Data { #model-for-output-response-data }
|
||||
|
||||
If you interact with the docs and check the response, even though the code didn't add anything in one of the `description` fields, the JSON response contains the default value (`null`):
|
||||
|
||||
<div class="screenshot">
|
||||
<img src="/img/tutorial/separate-openapi-schemas/image02.png">
|
||||
</div>
|
||||
|
||||
This means that it will **always have a value**, it's just that sometimes the value could be `None` (or `null` in JSON).
|
||||
|
||||
That means that, clients using your API don't have to check if the value exists or not, they can **assume the field will always be there**, but just that in some cases it will have the default value of `None`.
|
||||
|
||||
The way to describe this in OpenAPI, is to mark that field as **required**, because it will always be there.
|
||||
|
||||
Because of that, the JSON Schema for a model can be different depending on if it's used for **input or output**:
|
||||
|
||||
* for **input** the `description` will **not be required**
|
||||
* for **output** it will be **required** (and possibly `None`, or in JSON terms, `null`)
|
||||
|
||||
### Model for Output in Docs { #model-for-output-in-docs }
|
||||
|
||||
You can check the output model in the docs too, **both** `name` and `description` are marked as **required** with a **red asterisk**:
|
||||
|
||||
<div class="screenshot">
|
||||
<img src="/img/tutorial/separate-openapi-schemas/image03.png">
|
||||
</div>
|
||||
|
||||
### Model for Input and Output in Docs { #model-for-input-and-output-in-docs }
|
||||
|
||||
And if you check all the available Schemas (JSON Schemas) in OpenAPI, you will see that there are two, one `Item-Input` and one `Item-Output`.
|
||||
|
||||
For `Item-Input`, `description` is **not required**, it doesn't have a red asterisk.
|
||||
|
||||
But for `Item-Output`, `description` is **required**, it has a red asterisk.
|
||||
|
||||
<div class="screenshot">
|
||||
<img src="/img/tutorial/separate-openapi-schemas/image04.png">
|
||||
</div>
|
||||
|
||||
With this feature from **Pydantic v2**, your API documentation is more **precise**, and if you have autogenerated clients and SDKs, they will be more precise too, with a better **developer experience** and consistency. 🎉
|
||||
|
||||
## Do not Separate Schemas { #do-not-separate-schemas }
|
||||
|
||||
Now, there are some cases where you might want to have the **same schema for input and output**.
|
||||
|
||||
Probably the main use case for this is if you already have some autogenerated client code/SDKs and you don't want to update all the autogenerated client code/SDKs yet, you probably will want to do it at some point, but maybe not right now.
|
||||
|
||||
In that case, you can disable this feature in **FastAPI**, with the parameter `separate_input_output_schemas=False`.
|
||||
|
||||
/// info
|
||||
|
||||
Support for `separate_input_output_schemas` was added in FastAPI `0.102.0`. 🤓
|
||||
|
||||
///
|
||||
|
||||
{* ../../docs_src/separate_openapi_schemas/tutorial002_py310.py hl[10] *}
|
||||
|
||||
### Same Schema for Input and Output Models in Docs { #same-schema-for-input-and-output-models-in-docs }
|
||||
|
||||
And now there will be one single schema for input and output for the model, only `Item`, and it will have `description` as **not required**:
|
||||
|
||||
<div class="screenshot">
|
||||
<img src="/img/tutorial/separate-openapi-schemas/image05.png">
|
||||
</div>
|
||||
|
||||
This is the same behavior as in Pydantic v1. 🤓
|
||||
@@ -0,0 +1,7 @@
|
||||
# Testing a Database { #testing-a-database }
|
||||
|
||||
You can study about databases, SQL, and SQLModel in the <a href="https://sqlmodel.tiangolo.com/" class="external-link" target="_blank">SQLModel docs</a>. 🤓
|
||||
|
||||
There's a mini <a href="https://sqlmodel.tiangolo.com/tutorial/fastapi/" class="external-link" target="_blank">tutorial on using SQLModel with FastAPI</a>. ✨
|
||||
|
||||
That tutorial includes a section about <a href="https://sqlmodel.tiangolo.com/tutorial/fastapi/tests/" class="external-link" target="_blank">testing SQL databases</a>. 😎
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 199 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 163 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 169 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 160 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 156 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 161 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 166 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 221 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 199 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 165 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 214 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 181 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 153 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 122 KiB |
@@ -0,0 +1,297 @@
|
||||
<svg host="65bd71144e" xmlns="http://www.w3.org/2000/svg" style="background: transparent; background-color: transparent;" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="924px" height="674px" viewBox="-0.5 -0.5 924 674" content="<mxfile><diagram id="BkDNbdtn8_9fWQybnc8v" name="Page-1">7VvRkqI4FP0aH8eCAAEfHae792G7qmusqdl9jBCFHSRMiK3u128iQQzElm5B6C2fJJdAwj0nh3tvcGTN1rsnitLwmQQ4HgEj2I2sbyMAgON6/EdY9rnFhC7ILSsaBdJWGubRv1gaDWndRAHOlI6MkJhFqWr0SZJgnyk2RCnZqt2WJFZHTdEK1wxzH8V1688oYKG0ToBRnvgDR6uwGBoY8swaFb2lIQtRQLYnJuthZM0oISw/Wu9mOBbuKxyTX/d45uxxZhQnrMkF0vGvKN7Ih5PzYvviaSnZJAEW/Y2R9XUbRgzPU+SLs1sOMLeFbB3zlskPlyRhc3mtaGeMkl9HL9myxyNaR7FA/ztZEEb4eM8k4T8z4aLjUYaS7EuGabTkl9UfTD7rK6YM705M8kGfMFljRve8izxrF06XvAOebG9LEI8Yhif4QVcakSTO6njv0rX8QHpX72lL42kYM+GjFCWKy+HvjcD/4Kov2YH+U94B2Onu4IniPD9ayd+46C/4nINT9iu8XHFq7T5zTLk3i7vxB8pvqA7CzfmEC3OFLhwMpnIi58CMxIRyS0ISLOYaxXHFhOJolfCmzyHm07C+Cmgjvuym8sQ6CgIxjJaEKk1V3lnneNcFzVzHUWk2qdPMMjQ081pgGbz9ej4BcgSsAGFv6ddQ52eg7+HFslcFME1TlQDbrGNjTjTYOEYL4LhnJUCu3GYS0Nn6/z59vrD4F1QjB2rHzywHNyIhhOMJUHkI6jx04diEdSZaLRBxcleJt+IE97JIcEHoSCSKwQarErOXH3eV6JyEjmOPoXlRJDxj7LrdiIRp12DCAc+DZJNQFpIVSVD8UForDi37/ElIKpH9BzO2l0kd2nCHanA/xQDvIvaXuOHY4KqZt/8WvceGKZvfdnLAQ2MvGwHKwsNUim4vHB7uBkGTQ4e20c3IhvpFjlgkpoiu8DEPzG3CjW9ygOIYsehVTTd1WB4unVKK9icdUhIlLDu584swlNTyDFXfHDnCY9P+0KjwKJ9ByarjozQjmjMMoil8uTk3rE64UQcTVMF31FvkE5VXlShfSzLotUyayTBIg5NgKkpK5RuJWx4jMe9+NMZtm0dN3xfHktZNEbnk/+7f6RcR8fpCpJjN+VDyw0HgxZD0/CVXl7teKPFxxrUHorUI4pJFlqqxplqgejNWvXo2zyhBK6Vq1mj0ykrJQpSKwxDvEF8AvEt6EqxI6zF+AQ1SsmiHi9K5XrmqKZmDvcDWpWQeWFgQ9hoNu14lJdOEwtqUzGwjJQO9BCgDUzZQVzbQeszSWNl0+xYDq6b/JPSX0AWj1Ktr6ur9K8RyuQS+tmgTwAV0+lUIz67EtbZGIezOFALeFaLIYBSFsHuLRnvJDz4BIsOoQbiuuknmmpV96gv9oedV2HBlOvkJtmf/dy8UbPKg09W9UCbQtdCwXigQ3vSF4t3lq9j9UuSrt/KGZd4R0SFSbDX0kAToPnYYmGZPE8LCTy7ag8n6Xc2XNN1l/abuc40KHO/aJW+jBNPpHsU7tsir9RjHqyNjaZCx2wDGGyAwfX5PYlXA0EQqpm6ZgDYCFV2NuVMwGpQhBrpKHKPhKmknhNTVyDpFpkE8P1BkoNkUmTYE7I1vgT8eb3z0syDuKOOp8T7FzZfykHRVE35odfVovIok9p0kw68S1EgCnZuSpPsYdaCK7cKGit2Gm4v7dvkqHQ6FPd1H8frvXd/tWt4s/9yU12nLP4lZD/8B</diagram></mxfile>">
|
||||
<defs/>
|
||||
<g>
|
||||
<g>
|
||||
<rect x="2" y="2" width="920" height="670" fill="#ffffff" stroke="#000000" stroke-width="4" pointer-events="all" style="fill: light-dark(#ffffff, var(--ge-dark-color, #121212)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="337" y="12" width="300" height="80" fill="none" stroke="none" pointer-events="all"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 298px; height: 1px; padding-top: 52px; margin-left: 338px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Roboto", "sans-serif"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<span style="font-size: 24px;">
|
||||
<font face="Roboto, sans-serif">
|
||||
Server
|
||||
</font>
|
||||
</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="487" y="56" fill="light-dark(#000000, #ffffff)" font-family=""Roboto", "sans-serif"" font-size="12px" text-anchor="middle">
|
||||
Server
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="692" y="132" width="190" height="500" fill="#dae8fc" stroke="#6c8ebf" stroke-width="4" pointer-events="all" style="fill: light-dark(rgb(218, 232, 252), rgb(29, 41, 59)); stroke: light-dark(rgb(108, 142, 191), rgb(92, 121, 163));"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="748.92" y="142" width="76.16" height="30" fill="none" stroke="none" pointer-events="all"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 74px; height: 1px; padding-top: 157px; margin-left: 750px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Roboto Mono", "mono", "sans-serif"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<font style="font-size: 24px">
|
||||
<font face="Roboto, sans-serif">
|
||||
RAM
|
||||
</font>
|
||||
<br/>
|
||||
</font>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="787" y="161" fill="light-dark(#000000, #ffffff)" font-family=""Roboto Mono", "mono", "sans-serif"" font-size="12px" text-anchor="middle">
|
||||
RAM
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="52" y="132" width="250" height="500" fill="#dae8fc" stroke="#6c8ebf" stroke-width="4" pointer-events="all" style="fill: light-dark(rgb(218, 232, 252), rgb(29, 41, 59)); stroke: light-dark(rgb(108, 142, 191), rgb(92, 121, 163));"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="136.61" y="142" width="80.77" height="30" fill="none" stroke="none" pointer-events="all"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 79px; height: 1px; padding-top: 157px; margin-left: 138px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Roboto Mono", "mono", "sans-serif"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<font style="font-size: 24px">
|
||||
<font face="Roboto, sans-serif">
|
||||
CPU
|
||||
</font>
|
||||
<br/>
|
||||
</font>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="177" y="161" fill="light-dark(#000000, #ffffff)" font-family=""Roboto Mono", "mono", "sans-serif"" font-size="12px" text-anchor="middle">
|
||||
CPU
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 385 243 L 382 243 L 382 282 L 423.9 282" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" stroke-dasharray="9 9" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
<path d="M 430.65 282 L 421.65 286.5 L 423.9 282 L 421.65 277.5 Z" fill="#000000" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(rgb(0, 0, 0), rgb(255, 255, 255)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 382 242 L 382 402 L 423.9 402" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" stroke-dasharray="9 9" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
<path d="M 430.65 402 L 421.65 406.5 L 423.9 402 L 421.65 397.5 Z" fill="#000000" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(rgb(0, 0, 0), rgb(255, 255, 255)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 362 192 L 327 192 L 327 200 L 292 200" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 612 192 L 712 192" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 382 142 L 592 142 L 612 192 L 592 242 L 382 242 L 362 192 Z" fill="#d5e8d4" stroke="#82b366" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(rgb(213, 232, 212), rgb(31, 47, 30)); stroke: light-dark(rgb(130, 179, 102), rgb(68, 110, 44));"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 248px; height: 1px; padding-top: 192px; margin-left: 363px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Roboto Mono", "mono", "sans-serif"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<font face="Roboto, sans-serif">
|
||||
<font style="">
|
||||
<span style="font-size: 24px;">
|
||||
Process
|
||||
</span>
|
||||
</font>
|
||||
<span style="font-size: 24px;">
|
||||
Manager
|
||||
</span>
|
||||
</font>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="487" y="196" fill="light-dark(#000000, #ffffff)" font-family=""Roboto Mono", "mono", "sans-serif"" font-size="12px" text-anchor="middle">
|
||||
Process Manager
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 662 312 L 687 312 L 687 287 L 712 287" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 442 262 L 642 262 L 662 312 L 642 362 L 442 362 L 422 312 Z" fill="#fff2cc" stroke="#d6b656" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(rgb(255, 242, 204), rgb(40, 29, 0)); stroke: light-dark(rgb(214, 182, 86), rgb(109, 81, 0));"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 238px; height: 1px; padding-top: 312px; margin-left: 423px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Roboto Mono", "mono", "sans-serif"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<span style="font-size: 24px;">
|
||||
<font face="Roboto, sans-serif">
|
||||
Worker Process
|
||||
</font>
|
||||
</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="542" y="316" fill="light-dark(#000000, #ffffff)" font-family=""Roboto Mono", "mono", "sans-serif"" font-size="12px" text-anchor="middle">
|
||||
Worker Process
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 662 432 L 687 432 L 687 447 L 712 447" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 422 432 L 357 432 L 357 410 L 292 410" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 442 382 L 642 382 L 662 432 L 642 482 L 442 482 L 422 432 Z" fill="#e1d5e7" stroke="#9673a6" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(rgb(225, 213, 231), rgb(57, 47, 63)); stroke: light-dark(rgb(150, 115, 166), rgb(149, 119, 163));"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 238px; height: 1px; padding-top: 432px; margin-left: 423px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Roboto Mono", "mono", "sans-serif"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<span style="font-size: 24px;">
|
||||
<font face="Roboto, sans-serif">
|
||||
Worker Process
|
||||
</font>
|
||||
</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="542" y="436" fill="light-dark(#000000, #ffffff)" font-family=""Roboto Mono", "mono", "sans-serif"" font-size="12px" text-anchor="middle">
|
||||
Worker Process
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 362 562 L 327 562 L 327 515 L 292 515" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 612 562 L 662 562 L 662 557 L 712 557" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 382 512 L 592 512 L 612 562 L 592 612 L 382 612 L 362 562 Z" fill="#ffffff" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(#ffffff, var(--ge-dark-color, #121212)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 248px; height: 1px; padding-top: 562px; margin-left: 363px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Roboto Mono", "mono", "sans-serif"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<span style="font-size: 24px;">
|
||||
<font face="Roboto, sans-serif">
|
||||
Another Process
|
||||
</font>
|
||||
</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="487" y="566" fill="light-dark(#000000, #ffffff)" font-family=""Roboto Mono", "mono", "sans-serif"" font-size="12px" text-anchor="middle">
|
||||
Another Process
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="62" y="180" width="230" height="40" fill="#d5e8d4" stroke="#82b366" stroke-width="3" stroke-dasharray="9 9" pointer-events="all" style="fill: light-dark(rgb(213, 232, 212), rgb(31, 47, 30)); stroke: light-dark(rgb(130, 179, 102), rgb(68, 110, 44));"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="712" y="182" width="150" height="20" fill="#d5e8d4" stroke="#82b366" stroke-width="3" pointer-events="all" style="fill: light-dark(rgb(213, 232, 212), rgb(31, 47, 30)); stroke: light-dark(rgb(130, 179, 102), rgb(68, 110, 44));"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="62" y="230" width="230" height="100" fill="#fff2cc" stroke="#d6b656" stroke-width="3" stroke-dasharray="9 9" pointer-events="all" style="fill: light-dark(rgb(255, 242, 204), rgb(40, 29, 0)); stroke: light-dark(rgb(214, 182, 86), rgb(109, 81, 0));"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="62" y="340" width="230" height="140" fill="#e1d5e7" stroke="#9673a6" stroke-width="3" stroke-dasharray="9 9" pointer-events="all" style="fill: light-dark(rgb(225, 213, 231), rgb(57, 47, 63)); stroke: light-dark(rgb(150, 115, 166), rgb(149, 119, 163));"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="712" y="212" width="150" height="150" fill="#fff2cc" stroke="#d6b656" stroke-width="3" pointer-events="all" style="fill: light-dark(rgb(255, 242, 204), rgb(40, 29, 0)); stroke: light-dark(rgb(214, 182, 86), rgb(109, 81, 0));"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 148px; height: 1px; padding-top: 287px; margin-left: 713px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Roboto Mono", "mono", "sans-serif"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<font style="font-size: 24px" face="Roboto, sans-serif">
|
||||
1 GB
|
||||
</font>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="787" y="291" fill="light-dark(#000000, #ffffff)" font-family=""Roboto Mono", "mono", "sans-serif"" font-size="12px" text-anchor="middle">
|
||||
1 GB
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="712" y="372" width="150" height="150" fill="#e1d5e7" stroke="#9673a6" stroke-width="3" pointer-events="all" style="fill: light-dark(rgb(225, 213, 231), rgb(57, 47, 63)); stroke: light-dark(rgb(150, 115, 166), rgb(149, 119, 163));"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 148px; height: 1px; padding-top: 447px; margin-left: 713px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Roboto Mono", "mono", "sans-serif"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<font style="font-size: 24px" face="Roboto, sans-serif">
|
||||
1 GB
|
||||
</font>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="787" y="451" fill="light-dark(#000000, #ffffff)" font-family=""Roboto Mono", "mono", "sans-serif"" font-size="12px" text-anchor="middle">
|
||||
1 GB
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="62" y="490" width="230" height="50" fill="#ffffff" stroke="#000000" stroke-width="3" stroke-dasharray="9 9" pointer-events="all" style="fill: light-dark(#ffffff, var(--ge-dark-color, #121212)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="712" y="532" width="150" height="50" fill="#ffffff" stroke="#000000" stroke-width="3" pointer-events="all" style="fill: light-dark(#ffffff, var(--ge-dark-color, #121212)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
</g>
|
||||
<switch>
|
||||
<g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/>
|
||||
<a transform="translate(0,-5)" xlink:href="https://www.drawio.com/doc/faq/svg-export-text-problems" target="_blank">
|
||||
<text text-anchor="middle" font-size="10px" x="50%" y="100%">
|
||||
Text is not SVG - cannot display
|
||||
</text>
|
||||
</a>
|
||||
</switch>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 103 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 647 KiB |
@@ -0,0 +1,131 @@
|
||||
<svg host="65bd71144e" xmlns="http://www.w3.org/2000/svg" style="background: transparent; background-color: transparent;" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="652px" height="817px" viewBox="-0.5 -0.5 652 817" content="<mxfile><diagram id="jyERGzDynktFHFRGN0ph" name="Page-1">1VnbkuI2EP0aHnH5jv04MDO7W7VJTYWHTR41trC1EZYjCzD5+kiW5DuDGWBmA0WBWq1Wq/uodSxmzmpbfqEgT38jMcQz24zLmfM4s+2FufD5l5AcpcT1XFdKEopiKbMawRr9C5XQVNIdimHRUWSEYIbyrjAiWQYj1pEBSsmhq7YhuDtrDhI4EKwjgIfSHyhmqZKGttl0fIUoSfXUtql6tkBrK0GRgpgcWiLnaeasKCFM/tqWK4hF+HRg5LjnE721ZxRmbMoAx5Yj9gDv1OqUY+yol5sTlDFIn/bcpoicNXOWtd8mb8SgSGGsGinbYqW0QRivCCa0suN4pnhzOQavEL+QAjFEMt4XQWGfd+whZYjH+XtP4ZUwRrYthQeMEtHBSM6lZMcwyuCqTreYBCiV2jh3ORcr2paJwKVBNhsUQSOGe/5VGBjk0lrBKPkbar8zkvFBy2FcVaiFR7BsiVScv0CyhYweuYrqnVuuSrrC/XzhyfahAZGnkZK28MMjp8CrgJvUxpvU8h8qu+OZDgZ5hTFHtWoSylKSkAzgp0a6pGSXxXVmG53vRESqyvFPyNhRbVGwY6SLABlLvUkcLoElYn8Kg4YZ2qr9l9A2TEs1H0s1YdU49kGm1V4gRTwKIreVwskUiXW+mSAKMWBo393dY7Guhj5QCo4thWp7FC3LL0LQ5D0wu2n31AzPU/V9s5dn6cGp0c7obLW7BdnRCKpRPfjUMZmEqPDXQFQHGB8FgglZNifF/Vo0+cEb6HhPUs3PyGonhwUDlD2Ic7qpv5XsGQm3ZWnIYq0RYVAUKJJCpTKOlJPgkLnRJENTCkATqCuw/TEocsLeEWGF94HRcCK1xFNVyQ7eHnA18Bx3hIn4mAkeQSpPNkDlyP9nJ/jR8g/CiQGZ2SuRQpAV84IfCZumvwNjLRTG5kUFxAeuYLt52R7hJ+L78fc171tDyo/3QrvBVyA9kTrDfYIxZ6CwRTUiTHZ8ectDihhc59L/A2cfYzWtxZTM6nUZhi8gIn4vlZ4mJi0i4jgjRMT2b0FEPomJ3KmoTDt+uhXGHKkw7sdUGN8zTC8IOKe0Q9eyFlYXCvbEY+sdGzwIRzb4Lw8EpXF7FOgjpQ2CGhn3RoFlnXgUOZP2gaG5a1Qw8t1FBSud5OaUCI2w9fJ688jVX32czfvrsfrPvRcOuJ5H6bL8uWi/hlhNhP40tLtjaP8gbm6ZXq/KBdOq3HnaNDgRbwTowUSuc1t81qVmhG8VOcgmc6eKNPXo0/XETdr5kRLhciGnK/j6QJ4bsATbHEMjItuT1KwWy7WcYGyap6XcZCJumpZ561JBSet7Bvs8k9ugEuoLywt3yyUXSf3iVd+MtgmcNULg+rh/D3+rt+1NmXo3cVcj8NtLpXACBlL8SkenuKNXlu0Ylu3yj8c//hn/zj1v/D/Ray/64A2H4LXdO4HXHiOhn/WUmTKWy9r2LCBwQXnrIaFLE85lmVvSrGOYZfdGNap/XeAGwwoVjD1ivuOumzebf0zkWdj88+Q8/Qc=</diagram></mxfile>">
|
||||
<defs/>
|
||||
<g>
|
||||
<g>
|
||||
<rect x="0" y="466" width="500" height="350" fill="none" stroke="none" pointer-events="all"/>
|
||||
<path d="M 289.06 793.99 C 293.87 793.99 297.23 791.75 296.28 790.03 L 286.73 773.39 C 285.53 770.86 283.81 770.35 280.97 770.35 L 219.03 770.35 C 216.02 770.35 214.47 770.96 213.01 773.49 L 204.15 789.93 C 202.43 792.57 207.59 793.99 211.29 793.99 Z M 433.76 739.91 L 433.76 496.43 L 65.98 496.43 L 65.98 739.91 Z M 25.89 816 C 16.09 815.9 7.31 812.04 3.61 806.06 C 0 800.17 1.46 794.29 4.56 790.23 L 40.18 747.52 L 40.18 495.12 C 40.18 482.43 49.81 466 65.81 466 L 433.84 466 C 446.32 466 459.57 477.77 459.57 496.74 L 459.57 747.52 L 495.53 790.64 C 498.54 794.7 500 800.07 496.39 805.86 C 491.66 813.16 482.71 815.49 474.28 816 Z" fill="#505050" stroke="none" pointer-events="all" style="fill: light-dark(rgb(80, 80, 80), rgb(168, 168, 168));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 530 331 L 530 409 L 420 409 L 420 455.9" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" stroke-dasharray="9 9" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
<path d="M 420 462.65 L 415.5 453.65 L 420 455.9 L 424.5 453.65 Z" fill="#000000" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(rgb(0, 0, 0), rgb(255, 255, 255)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 162.5 66 C 96.5 66 80 131 132.8 144 C 80 172.6 139.4 235 182.3 209 C 212 261 311 261 344 209 C 410 209 410 157 368.75 131 C 410 79 344 27 286.25 53 C 245 14 179 14 162.5 66 Z" fill="#ffffff" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(#ffffff, var(--ge-dark-color, #121212)); stroke: light-dark(rgb(0, 0, 0), rgb(237, 237, 237));"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 328px; height: 1px; padding-top: 131px; margin-left: 81px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Helvetica"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<font style="font-size: 24px" face="Roboto, sans-serif">
|
||||
DNS Servers
|
||||
</font>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="245" y="135" fill="light-dark(#000000, #ffffff)" font-family=""Helvetica"" font-size="12px" text-anchor="middle">
|
||||
DNS Servers
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 185.2 331 L 185.2 296.2 L 245.2 296.2 L 245.06 271.1" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" stroke-dasharray="9 9" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
<path d="M 245.02 264.35 L 249.57 273.33 L 245.06 271.1 L 240.57 273.38 Z" fill="#000000" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(rgb(0, 0, 0), rgb(255, 255, 255)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 130 466 L 130 421 L 130 411" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" stroke-dasharray="9 9" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 408.04 111 L 530 111 L 530 251" fill="none" stroke="#000000" stroke-width="3" stroke-miterlimit="10" stroke-dasharray="9 9" pointer-events="stroke" style="stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 50 331 L 320 331 L 340 371 L 320 411 L 50 411 L 30 371 Z" fill="#ffffff" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(#ffffff, var(--ge-dark-color, #121212)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 308px; height: 1px; padding-top: 371px; margin-left: 31px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Helvetica"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<span style="font-size: 24px;">
|
||||
<font face="Roboto, sans-serif">
|
||||
Who is: someapp.example.com
|
||||
</font>
|
||||
</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="185" y="375" fill="light-dark(#000000, #ffffff)" font-family=""Helvetica"" font-size="12px" text-anchor="middle">
|
||||
Who is: someapp.example.com
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M 430 251 L 630 251 L 650 291 L 630 331 L 430 331 L 410 291 Z" fill="#ffffff" stroke="#000000" stroke-width="3" stroke-miterlimit="10" pointer-events="all" style="fill: light-dark(#ffffff, var(--ge-dark-color, #121212)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 238px; height: 1px; padding-top: 291px; margin-left: 411px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Helvetica"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
|
||||
<font face="Roboto, sans-serif">
|
||||
<span style="font-size: 24px;">
|
||||
IP:
|
||||
</span>
|
||||
<br style=""/>
|
||||
<span style="font-size: 24px;">
|
||||
123.124.125.126
|
||||
</span>
|
||||
</font>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="530" y="295" fill="light-dark(#000000, #ffffff)" font-family=""Helvetica"" font-size="12px" text-anchor="middle">
|
||||
IP:...
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<rect x="60" y="493" width="380" height="250" fill="#ffffff" stroke="#000000" stroke-width="4" pointer-events="all" style="fill: light-dark(#ffffff, var(--ge-dark-color, #121212)); stroke: light-dark(rgb(0, 0, 0), rgb(255, 255, 255));"/>
|
||||
</g>
|
||||
<g>
|
||||
<g transform="translate(-0.5 -0.5)">
|
||||
<switch>
|
||||
<foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
|
||||
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 378px; height: 1px; padding-top: 618px; margin-left: 61px;">
|
||||
<div style="box-sizing: border-box; font-size: 0; text-align: center; color: #000000; ">
|
||||
<div style="display: inline-block; font-size: 12px; font-family: "Helvetica"; color: light-dark(#000000, #ffffff); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; word-wrap: normal; ">
|
||||
<font style="font-size: 24px" face="Roboto, sans-serif">
|
||||
https://someapp.example.com
|
||||
</font>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</foreignObject>
|
||||
<text x="250" y="622" fill="light-dark(#000000, #ffffff)" font-family=""Helvetica"" font-size="12px" text-anchor="middle" font-weight="bold">
|
||||
https://someapp.example.com
|
||||
</text>
|
||||
</switch>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<switch>
|
||||
<g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/>
|
||||
<a transform="translate(0,-5)" xlink:href="https://www.drawio.com/doc/faq/svg-export-text-problems" target="_blank">
|
||||
<text text-anchor="middle" font-size="10px" x="50%" y="100%">
|
||||
Text is not SVG - cannot display
|
||||
</text>
|
||||
</a>
|
||||
</switch>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 12 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user