Adakah Flask Mati? Adakah FastAPI Masa Depan?

Semasa carian berkaitan saya, saya dapati bahawa walaupun pada tahun 2024, sebilangan besar orang masih mengesyorkan Flask sebagai rangka kerja web Python. Walau bagaimanapun, pada pandangan saya, "Flask sedang dalam perjalanan keluar, dan FastAPI mewakili masa depan." Itulah sebabnya saya menulis artikel ini. Saya mengalu-alukan semua orang untuk menyertai perbincangan dan menawarkan hujah balas.

Flask vs FastAPI

Flask memegang tempat yang penting di hati pembangun Python. Jika anda seorang pembangun web, saya yakin anda berkemungkinan besar menggunakan Flask, tetapi mungkin anda tidak pernah mencuba FastAPI.

Berikut adalah dua bukti:

1. Dalam projek Python baharu yang terkenal berkaitan pembangunan web sejak satu atau dua tahun lalu, hampir kesemuanya yang melibatkan pembangunan web telah menggunakan FastAPI.
2. Sehingga 25 Disember 2024, di GitHub, bilangan bintang untuk FastAPI (78.9k) telah pun mengatasi Flask (68.4k).

Sekarang mari kita lihat perubahan dalam perkadaran rangka kerja web dalam tinjauan rasmi pembangun Python.

Ternyata pada 2019, FastAPI tidak disenaraikan sebagai pilihan, namun menjelang 2023, bahagiannya telah mencapai 25%. (Pada masa ini, kami hanya mempunyai data sehingga 2023.)

Perlu diambil perhatian bahawa data perkadaran ini merangkumi sistem sedia ada, jadi perkadaran Django dan Flask tidak akan menurun dengan cepat. Namun begitu, trendnya jelas.

Kita semua tahu bahawa medan rangka kerja web sangat prolifik, dengan rangka kerja baharu muncul hampir setiap tahun. Kebanyakan rangka kerja ini adalah jangka pendek, manakala sesetengahnya berjaya bertahan. FastAPI dilahirkan pada penghujung 2018 dan mula mencipta nama sekitar penghujung 2019. Jadi, bagaimanakah ia boleh mengatasi Flask, yang dilahirkan pada penghujung 2010, dari segi populariti dalam tempoh lima tahun sahaja? Seterusnya, mari kita jejaki sejarah pembangunan rangka kerja web Python dan penyelesaian berkaitan sepanjang garis masa untuk pemahaman yang lebih baik.

Evolusi Rangka Kerja Web (Plugin, Alat)

Pengarang FastAPI ialah pembangun yang sangat memperhatikan pembangunan ekosistem Python. Pautan bacaan lanjutan 2 ialah "Alternatif, Inspirasi dan Perbandingan" yang ditulis oleh pengarang (https://fastapi.tiangolo.com/alternatives/), yang menghuraikan secara terperinci tentang rujukan atau inspirasi yang telah diambil oleh FastAPI daripada pelbagai perpustakaan. Bahagian sejarah pembangunan artikel ini juga merujuk kepada bahagian ini. Saya akan mengesyorkan membaca teks asal, kerana ia mengandungi rasional di sebalik kemunculan FastAPI serta beberapa konsep reka bentuk pengarang.

Kelalang

Flask ialah rangka kerja "mikro", yang berbeza daripada Django. Ia hanya mengekalkan segelintir fungsi teras dan, untuk memisahkan, membahagikan fungsi lain kepada beberapa perpustakaan (seperti Jinja2, Werkzeug, dll.). Ini memberi pembangun kebebasan yang mencukupi dan membolehkan mereka menulis pemalam pihak ketiga dengan mudah untuk fungsi yang berkaitan. Reka bentuk dalamannya seperti cetak biru, konteks dan penghias untuk mewakili laluan, isyarat, dsb. agak maju pada masa itu. Ditambah dengan dokumentasi yang komprehensif, ia sangat mesra pemula.

Rangka Kerja Flask REST

Berkat kesederhanaannya, Flask sangat sesuai untuk membina API. Walau bagaimanapun, memandangkan Flask sendiri tidak disertakan dengan sebarang fungsi terbina dalam, kami memerlukan rangka kerja REST khusus. Akibatnya, rangka kerja seperti flask-restful, Flask-RESTPlus dan flask-api telah muncul satu demi satu. Selain itu, dalam perkhidmatan REST, terdapat keperluan untuk pengesahan, penghuraian dan spesifikasi data, yang membawa kepada kemunculan Marshmallow, Webargs dan APISpec, sehingga Flask-apispec datang bersama-sama. Walau bagaimanapun, sepanjang proses pembangunan ini, Rangka Kerja Flask REST yang setanding dengan DRF tidak pernah menjadi kenyataan.

Pada peringkat ini, kelemahan Flask secara beransur-ansur kelihatan.

Kekuatan asal Flask terletak pada fleksibiliti dan minimalismenya, tetapi ini juga bermakna bahawa sejumlah besar komponen perlu dibangunkan secara dalaman. Ini sama ada menuntut syarikat besar dengan pembangun yang berdedikasi untuk pembangunan dan penyelenggaraan atau pembangun individu yang sangat berkebolehan. Jika tidak, pemalam adalah sukar untuk mencapai kualiti pengeluaran, mengakibatkan beg bercampur pemalam pihak ketiga untuk Flask, tanpa jaminan penyelenggaraan jangka panjang. Seperti yang dinyatakan sebelum ini, banyak perpustakaan tersebut telah tidak lagi diselenggara.

Jadi, sehingga hari ini, jika anda ingin membina perkhidmatan API dengan Flask, anda masih perlu menggabungkan pelbagai komponen. Untuk beberapa komponen yang belum dikemas kini dengan segera, anda perlu menyelesaikan masalah sendiri. Veteran mungkin boleh mengendalikannya, tetapi bagi pemula, ia agak menakutkan, terutamanya apabila mereka ingin menerapkan amalan dan konsep terkini.

Ekosistem Asyncio

Sejak Python 3.5, asyncio telah menjadi trend masa hadapan. Akibatnya, beberapa rangka kerja web yang menyokong asyncio secara asli telah muncul, seperti aiohttp, Starlette dan sanic.

Pada masa ini, Flask enggan menyesuaikan diri. Komuniti lambat menambah sokongan untuk asyncio, dan pengarang asal Flask telah beralih kepada menulis Rust, meninggalkan projek itu di tangan dua penyelenggara (kini hanya tinggal satu).

Projek untuk membina perkhidmatan API, seperti apistar dan lebur, semuanya telah memberikan inspirasi reka bentuk untuk kelahiran FastAPI.

FastAPI

Kemudian, FastAPI dilahirkan. Penulis pada asalnya mencari penyelesaian yang baik, tetapi situasi di atas masing-masing mempunyai masalah atau batasannya sendiri. Jadi, penulis mencipta rangka kerja baharu ini.

Mengapa FastAPI Terserlah

Ini adalah bahagian teras artikel. Sebab berikut adalah tepat mengapa FastAPI boleh menggantikan Flask.

Pengesahan Data Pengguna dengan Pydantic

Dalam proses pembangunan API, pengesahan format data, penghuraian dan siri adalah operasi rutin. Selama bertahun-tahun, pelbagai penyelesaian telah muncul, dan pada masa ini, Pydantic ialah pilihan utama:

from fastapi import FastAPI
from pydantic import BaseModel


class Item(BaseModel):
    name: str
    description: str | None = None
    price: float
    tax: float | None = None


app = FastAPI()


@app.post("/items/")
async def create_item(item: Item):
    return item

Pada pandangan pertama, kod ini mungkin kelihatan seperti cara menulis ORM atau kelas data, tetapi sebenarnya, ia menggunakan sintaks Petua Jenis asli Python untuk menganotasi jenis medan. Sebagai contoh, dalam contoh di atas, skema Item dalam permintaan /item/ telah ditakrifkan dengan jelas dan jenis nilai setiap medan adalah eksplisit. Berbanding dengan kaedah lama menggunakan penerangan skema atau pengekodan keras, pendekatan ini lebih ringkas, lebih sesuai dengan gaya Python dan mempunyai sokongan IDE yang lebih baik.

Pada masa ini, Pydantic mendominasi bidang pengesahan data pengguna. Memandangkan FastAPI mempunyainya terbina dalam, proses pengesahan sangat dipermudahkan dan ralat dikurangkan. Itulah sebabnya laman web rasmi FastAPI menyebut bahawa penyelesaian ini boleh mengurangkan ralat pembangun sehingga 40%. Untuk bahasa dinamik seperti Python, menggunakan Pydantic adalah penting jika anda tidak menggunakan mypy untuk semakan jenis.

Selain itu, terima kasih kepada penyepaduan Pydantic, menambahkan ORM (seperti SQLAlchemy) pada projek menjadi sangat mudah. Objek yang diperoleh daripada permintaan boleh dihantar terus ke pangkalan data kerana pengesahan data telah pun selesai. Sebaliknya, objek yang diambil daripada pangkalan data juga boleh dipulangkan terus.

Sebaliknya, Flask kekurangan dalam hal ini.

Reka Bentuk Asynchronous

Dalam era Flask, pelaksanaan kod adalah satu-benang dan segerak. Ini bermakna permintaan perlu diproses satu demi satu, dan permintaan lain akan membuang masa menunggu operasi I/O sebelum yang sebelumnya selesai. Asyncio, sebaliknya, adalah penyelesaian yang optimum. Ia boleh menjadikan operasi I/O tidak segerak, membolehkan anda memperoleh hasil tugasan tanpa menunggu tugasan selesai, dan kemudian meneruskan untuk mengendalikan permintaan tugasan lain.

FastAPI secara asli menyokong kod serentak dan tak segerak. Selagi kod ditulis dengan betul, ia boleh mencapai kecekapan puncak. Oleh itu, ia dianggap sebagai rangka kerja Python terpantas pada masa ini, dengan kecekapan yang serupa dengan NodeJS atau Go. Apabila kelajuan dan prestasi adalah penting, FastAPI sudah pasti pilihan terbaik.

Sokongan Asli untuk ASGI

Mari kita sebutkan WSGI dahulu. Nama penuhnya ialah "Antara Muka Gerbang Pelayan Web Python", yang boleh dirujuk dalam "PEP 3333" (https://peps.python.org/pep-3333/). Ia adalah standard Python yang ditulis khusus untuk interaksi antara aplikasi web dan pelayan. Jika anda telah menggunakan PHP atau Ruby, anda mungkin lebih mudah untuk memahaminya. Flask bergantung pada Werkzeug, iaitu suite WSGI, jadi Flask menyokong standard WSGI lama ini dan bukan ASGI.

Masalah dengan WSGI ialah ia tidak dapat memanfaatkan tak segerak untuk meningkatkan prestasi dan kecekapan. Jadi, saluran Django mempelopori ASGI. Nama penuhnya ialah "Antara Muka Gerbang Pelayan Asynchronous", yang merupakan standard berulang dan direka bentuk semula sepenuhnya. Ia menyediakan antara muka pelayan/aplikasi tak segerak dan menyokong HTTP, HTTP/2 dan WebSocket. Tidak seperti WSGI, ASGI membenarkan setiap aplikasi mempunyai berbilang peristiwa tak segerak. Selain itu, ASGI menyokong kedua-dua aplikasi segerak dan tak segerak. Anda boleh sama ada memindahkan aplikasi web WSGI segerak lama ke ASGI atau menggunakan ASGI untuk membina aplikasi web tak segerak baharu.

Sebelum membuat kesimpulan, mari tambah penjelasan lima istilah:

1. Alat ASGI: Perpustakaan yang melaksanakan fungsi berkaitan ASGI (seperti penghalaan URL, objek Permintaan/Respons, enjin templat, dsb.). Dalam artikel ini, ia merujuk terutamanya kepada Starlette, yang sepadan dengan kebergantungan Flask, Werkzeug.
2. Rangka Kerja Web ASGI: Rangka kerja web yang melaksanakan spesifikasi ASGI (seperti FastAPI), manakala Flask dan Django ialah rangka kerja web yang melaksanakan WSGI. Rangka kerja ini direka bentuk untuk pembangun menulis aplikasi, dengan antara muka yang mudah digunakan. Pemaju hanya perlu mengisi logik perniagaan mengikut keperluan mereka. Rangka kerja awal kebanyakannya melaksanakan kit alat ASGI secara dalaman, manakala rangka kerja kemudian biasanya menggabungkan kit alat yang sesuai. Contohnya, Flask menggunakan Werkzeug (sendiri) dan FastAPI menggunakan Starlette (daripada yang lain).
3. Aplikasi Web: Aplikasi yang dibuat menggunakan rangka kerja web ialah aplikasi web. Biasanya, rangka kerja web disertakan dengan pelayan ujian yang boleh dimulakan untuk pembangunan dan penyahpepijatan. Jika prestasi dan kestabilan tidak membimbangkan, anda sudah boleh mengakses alamat pembangunan dalam penyemak imbas untuk melawati aplikasi ini.
4. Pelayan Web: Dunia sebenar lebih kompleks daripada yang dijangkakan. Selepas aplikasi web digunakan ke persekitaran pengeluaran, keperluan seperti permintaan pengimbangan beban, penyajian fail statik, kawalan akses dan proksi terbalik perlu dipertimbangkan, dan terdapat juga keperluan prestasi tinggi. Pelayan web terbina dalam rangka kerja web tidak dapat memenuhi keperluan ini sama sekali, jadi pelayan web khusus diperlukan. Pada masa ini, Nginx ialah pilihan arus perdana.
5. Pelayan ASGI: Pelayan ASGI bertindak sebagai jambatan antara pelayan web dan aplikasi web. Pelayan ASGI juga mematuhi spesifikasi ASGI, tetapi tugas utamanya adalah untuk memenuhi keperluan prestasi permintaan pemajuan, jadi ia terutamanya menjaga bahagian "G" (pintu masuk) ASGI. Kodnya tidak mesra pembangun untuk menulis perniagaan aplikasi web dan logik penghalaan. Pada masa ini, pelayan ASGI yang paling terkenal ialah Uvicorn, dan uvicorn.workers.UvicornWorker, yang asalnya berasal dari pelayan WSGI Gunicorn, juga merupakan pilihan. Ini adalah penggunaan yang disyorkan dalam persekitaran pengeluaran.

Pada masa lalu, penyelesaian persekitaran pengeluaran untuk WSGI biasanya Nginx Gunicorn Flask(Django), manakala pada masa kini, penyelesaian persekitaran pengeluaran untuk ASGI ialah Nginx Uvicorn FastAPI.

Satu perkara lagi. Berdasarkan nama dan pengenalan FastAPI, jelas sekali ia direka untuk membina perkhidmatan API. Malah, kod terasnya betul-betul seperti itu. Boleh dikatakan bahawa ia bukan rangka kerja tradisional yang dilaksanakan sepenuhnya tetapi lebih kepada rangka kerja yang menggabungkan kekuatan pelbagai rangka kerja. Bermula dari cangkang kosong, ia memasang komponen yang diperlukan dan sesuai. Sebagai contoh, ia tidak mempunyai enjin templat. Jika anda benar-benar perlu menggunakannya untuk membina aplikasi web yang memerlukan pemaparan templat, anda boleh memilih dan menggabungkan enjin templat yang anda perlukan. Sudah tentu, anda juga boleh menggunakan Jinja2 terbina dalam Starlette (ya, ia juga terbina dalam Flask).

Mengapa Dikatakan Kelalang Sudah Mati

Kelebihan FastAPI yang dinyatakan di atas tidak mencukupi untuk membuat kesimpulan bahawa Flask sudah mati. Jadi, mengapa saya memegang pandangan ini? Ia terutamanya disebabkan oleh populariti di kalangan pembangun dan pengguna.

"populariti" di sini agak subjektif. Penunjuk yang boleh saya fikirkan adalah seperti berikut:

1. Aktiviti Komuniti(https://github.com/pallets/flask/issues): Ambil bilangan isu dan tarik permintaan projek, sebagai contoh. Flask hanya mempunyai nombor satu digit, yang sepenuhnya dalam liga yang berbeza berbanding dengan FastAPI. Ini sebenarnya mencerminkan dari sisi bahawa projek itu tidak lagi aktif. Jika projek itu aktif, pengguna lama akan mempunyai lebih banyak keperluan. Jika mereka berhenti mengemukakan soalan, ini bermakna mereka telah pergi. Dan pengguna baru pasti akan menghadapi pelbagai jenis masalah. Walaupun dengan dokumentasi terperinci, masih terdapat ramai pengguna yang datang untuk bertanya soalan dan menyumbang kod. Kekurangan situasi sedemikian menunjukkan lebih sedikit pengguna.
2. Panas Perbincangan: Iaitu, populariti pertanyaan dan perbincangan pada catatan blog, Stack Overflow dan tapak web lain. Agak jelas bahawa terdapat sangat sedikit orang yang menulis tentang Flask pada hari ini.
3. Kekerapan Lelaran Pembangunan(https://github.com/pallets/flask/pulls): Melihat rekod komit, kita dapat melihat bahawa Flask hanya mempunyai seorang penyelenggara yang kadangkala membetulkan beberapa pepijat, tanpa sebarang ciri utama pembangunan.
4. Pengaruh Tokoh Utama: Tokoh utama di sebalik Flask, pemula projek, telah lama berhenti mengambil bahagian dalam projek. Menurut rekod sumbangan projek, kali terakhir Armin Ronacher menyumbang kepada pembangunan itu enam tahun lalu.

Semua situasi ini, pada pendapat saya, mencadangkan bahawa zaman kegemilangan Flask telah berlalu dan FastAPI ialah bintang yang semakin meningkat.

Akhir sekali, izinkan saya memperkenalkan platform yang ideal untuk menggunakan Flask/FastAPI: Leapcell.

Leapcell ialah platform pengkomputeran awan yang direka khusus untuk aplikasi pengedaran moden. Model penetapan harga bayar semasa anda memastikan tiada kos terbiar, bermakna pengguna hanya membayar untuk sumber yang sebenarnya mereka gunakan.

Kelebihan unik Leapcell untuk aplikasi WSGI/ASGI:

1. Sokongan Pelbagai Bahasa

• Menyokong pembangunan dalam JavaScript, Python, Go atau Rust.

2. Penggunaan Percuma Projek Tanpa Had

• Hanya caj berdasarkan penggunaan. Tiada caj apabila tiada permintaan.

3. Keberkesanan Kos yang tiada tandingan

• Bayar semasa anda pergi, tanpa yuran terbiar.
• Sebagai contoh, $25 boleh menyokong 6.94 juta permintaan, dengan purata masa tindak balas 60 milisaat.

4. Pengalaman Pembangun Dipermudahkan

• Antara muka pengguna yang intuitif untuk persediaan mudah.
• Saluran paip CI/CD automatik sepenuhnya dan penyepaduan GitOps.
• Metrik dan log masa nyata, memberikan cerapan yang boleh diambil tindakan.

5. Kebolehskalaan dan Prestasi Tinggi yang Mudah

• Penskalaan automatik untuk mengendalikan konkurensi tinggi dengan mudah.
• Sifar operasi overhed, membolehkan pembangun menumpukan pada pembangunan.

Ketahui lebih lanjut dalam dokumentasi!

Twitter Leapcell: https://x.com/LeapcellHQ

Atas ialah kandungan terperinci Adakah Flask Mati? Adakah FastAPI Masa Depan?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!