Epython Lab
6.11K subscribers
680 photos
31 videos
104 files
1.31K links
Welcome to Epython Lab, where you can get resources to learn, one-on-one trainings on machine learning, business analytics, and Python, and solutions for business problems.

Buy ads: https://telega.io/c/epythonlab
Download Telegram
When I build an AI application, choosing the backend framework is an important decision.

There are several good options, but I usually look at ๐…๐š๐ฌ๐ญ๐€๐๐ˆ, ๐ƒ๐ฃ๐š๐ง๐ ๐จ, and ๐…๐ฅ๐š๐ฌ๐ค first.

The choice really depends on what I'm building.

โœ”๏ธ ๐…๐š๐ฌ๐ญ๐€๐๐ˆ makes a lot of sense when the application is mainly an AI/API backend. Since most AI tools I use are already in Python, I can keep the whole stack in one ecosystem, from LLMs and embeddings to document processing, RAG, databases, and the API itself.

โœ”๏ธ ๐ƒ๐ฃ๐š๐ง๐ ๐จ is a strong choice when the AI functionality is part of a larger web application. Its built-in ORM, authentication, admin panel, and other features can save a lot of development time.

โœ”๏ธ ๐…๐ฅ๐š๐ฌ๐ค is still a great option when I want something simple, lightweight, and flexible, especially for smaller services or prototypes.

For an AI application, I also need to think beyond the framework:

โœ”๏ธ Authentication

โœ”๏ธ Database and data persistence

โœ”๏ธ Document processing

โœ”๏ธ Embeddings and vector search

โœ”๏ธ RAG

โœ”๏ธ Background tasks

โœ”๏ธ Testing

โœ”๏ธ Docker

โœ”๏ธ Monitoring

โœ”๏ธ Deployment

There isn't one framework that is "best" for every AI application. For the type of production AI backends I'm building, ๐…๐š๐ฌ๐ญ๐€๐๐ˆ is often a practical choice because it provides a clean API layer while keeping everything close to the Python AI ecosystem.

The framework is only one piece of the puzzle.

Good architecture matters more than the framework you choose.


What do you normally use for AI applications: ๐…๐š๐ฌ๐ญ๐€๐๐ˆ, ๐ƒ๐ฃ๐š๐ง๐ ๐จ, ๐…๐ฅ๐š๐ฌ๐ค, or something else?

Here is the roadmap to build an AI application with FastAPI: https://www.youtube.com/watch?v=0SLLG2Z_Htw


#FastAPI #Python #AIEngineering #GenerativeAI #RAG #BackendDevelopment #MachineLearning #Django #Flask #SoftwareArchitecture
The hardest part of building AI applications isn't writing the prompt or calling the model. In the last two weeks, I learned that keeping the backend from turning into spaghetti code once you move past the tutorial phase.

When you're wiring up an AI document pipeline in FastAPI, a few things quickly become non-negotiable:



โ€ข Payload Guardrails: If your Pydantic schemas aren't catching malformed JSON, missing nested fields, or bad Enums at the door, your AI service will fail unpredictably downstream.



โ€ข Route Isolation: Mixing your raw API endpoints with validation logic and business rules makes refactoring a nightmare by week three.



โ€ข The Persistence Gap: Transitioning from mock in-memory data structures to a real relational database and a vector store for RAG is where most clean prototypes start to break down.



If you're building production backends for AI and ML features, where do you usually draw the line between keeping things simple and over-engineering your architecture?



You can learn about FastAPI: https://www.youtube.com/playlist?list=PLQNCas8_eikM



#FastAPI #Python #BackendEngineering #SoftwareArchitecture #APIs #Pydantic #ArtificialIntelligence #MachineLearning #RAG
While moving from other web frameworks to ๐…๐š๐ฌ๐ญ๐€๐๐ˆ, one question came to my mind:



๐–๐ก๐ฒ ๐๐จ ๐ˆ ๐ง๐ž๐ž๐ ๐€๐๐ˆ๐‘๐จ๐ฎ๐ญ๐ž๐ซ ๐ฐ๐ก๐ž๐ง ๐…๐š๐ฌ๐ญ๐€๐๐ˆ ๐š๐ฅ๐ซ๐ž๐š๐๐ฒ ๐ฅ๐ž๐ญ๐ฌ ๐ฆ๐ž ๐๐ž๐Ÿ๐ข๐ง๐ž ๐ซ๐จ๐ฎ๐ญ๐ž๐ฌ ๐๐ข๐ซ๐ž๐œ๐ญ๐ฅ๐ฒ?



For a small project, this is enough:



@๐’‚๐’‘๐’‘.๐’ˆ๐’†๐’•("/๐’…๐’๐’„๐’–๐’Ž๐’†๐’๐’•๐’”")

๐’‚๐’”๐’š๐’๐’„ ๐’…๐’†๐’‡ ๐’ˆ๐’†๐’•_๐’…๐’๐’„๐’–๐’Ž๐’†๐’๐’•๐’”():

...

So why introduce APIRouter?



The answer became clearer when I started thinking about a real application.



As the project grows, I may have authentication, users, documents, search, AI processing, and many more endpoints.



Keeping all of these routes in one place can quickly become difficult to maintain.

Thatโ€™s where APIRouter becomes useful.



It allows me to organize routes by feature and keep the application structure clean.



So my takeaway is simple:



๐…๐š๐ฌ๐ญ๐€๐๐ˆ ๐ฅ๐ž๐ญ๐ฌ ๐ฆ๐ž ๐๐ž๐Ÿ๐ข๐ง๐ž ๐ญ๐ก๐ž ๐ซ๐จ๐ฎ๐ญ๐ž๐ฌ.

๐€๐๐ˆ๐‘๐จ๐ฎ๐ญ๐ž๐ซ ๐ก๐ž๐ฅ๐ฉ๐ฌ ๐ฆ๐ž ๐จ๐ซ๐ ๐š๐ง๐ข๐ณ๐ž ๐ญ๐ก๐ž๐ฆ.



Itโ€™s not required to make FastAPI work. It becomes useful when I want the application to stay organized and maintainable as it grows.



This was one of those small FastAPI concepts that made much more sense once I started looking at the bigger picture.



๐‡๐š๐ฏ๐ž ๐ฒ๐จ๐ฎ ๐ก๐š๐ ๐ญ๐ก๐ž ๐ฌ๐š๐ฆ๐ž ๐ช๐ฎ๐ž๐ฌ๐ญ๐ข๐จ๐ง ๐ฐ๐ก๐ž๐ง ๐ฆ๐จ๐ฏ๐ข๐ง๐  ๐ญ๐จ ๐…๐š๐ฌ๐ญ๐€๐๐ˆ?



๐Ÿ”— ๐†๐ข๐ญ๐‡๐ฎ๐›: https://github.com/epythonlab2/ai-document-api



๐ŸŽฅ ๐…๐š๐ฌ๐ญ๐€๐๐ˆ ๐œ๐จ๐ฎ๐ซ๐ฌ๐ž: https://www.youtube.com/watch?v=0SLLG2Z_Htw&list=PLQNCas8_eikM



#FastAPI #Python #APIRouter #BackendDevelopment #SoftwareArchitecture #APIDevelopment #PythonDeveloper
๐Ÿ‘2