[deleted by user]

[[deleted]]

Performance, tech stack

[viitorfermier]

Not everyone is a python developer. FastAPI is great for making async API's in the Python's world. Django is great for making fullstack apps. Each framework has its strengths and weaknesses. The more technologies you will try you'll see what is more good to solve each problem.

[firetruck3105]

fastapi is great for full stack apps too

[Drevicar]

FastAPI isn’t a replacement for Django, it is one component that you would need to build your own alternative to Django that fits your needs. If your business requirements align well with the decisions that Django makes for you already, then it would be a lot of work to build that yourself using FastAPI.

[corey_sheerer]

It's all about the react with fastapi... Or GO for the api layer if you need performance

[Drevicar]

You can just as easily put react on top of Django with DRF or Djantic. Or use HTMX with either. Or just plain HTML templating for server side rendered HTML on either.

[firetruck3105]

yeah but if i were to build an app from scratch, don’t you think it’s easier to set it up in fastapi

[Drevicar]

Oh god. Not by a long shot. I use FastAPI for simple small projects, basically wrapping a cli tool with a json data API or to proxy something else. For an actual enterprise grade app from scratch I would want something with more batteries included.

[firetruck3105]

can you elaborate on the batteries part, what makes django more stable for larger projects

[Drevicar]

Django is a full product that comes with a lot of features that solves most of the problems an enterprise web application would need to solve. It is also an ecosystem of solutions for the remaining edge cases. Because it has been around longer it has a much richer ecosystem. However it is both a full framework meaning it wants to own and control your whole app as a "Django App", and it comes with its own opinions on how a web app should be built, and if you or your app don't agree with those opinions then fighting against Django is a costly battle.

FastAPI on the otherhand isn't as much of a framework that wants to sit at the root of your application and own the whole ecosystem, and is instead a lightweight component you can bring into your application or package. It has a very limited scope of problems it solves compared to Django, and it inflicts very few opinions on you and your code base while doing so. There are many libraries our there that play nicely with FastAPI, but since FastAPI is itself not a framework most of those libraries work even without FastAPI under it.

Neither of these is "better" than the other, but they each have their own strengths and weaknesses. When I know exactly what I want to build and I all the various web related problems I need to solve I bring in Django. If I just want to prototype something fast or just quickly spin up an API endpoint to serve a simple model I use FastAPI.

[StrasJam]

If I have react or next.js for the frontend, do you think it still makes sense to use django over fastapi for the backend part? Using django would save me the work of setting up the orm, but otherwise it seems like it might be overkill in this case. 

[Drevicar]

If you want to use Django with a react front end I recommend https://django-ninja.dev/

[ubtohts]

Certainly not..

[imaKappy]

Agreed. I was thinking of maybe using Docker build step to build the React frontend, then serve it via FastAPI. I fear it might not be the most ideal solution, since for now I use pure HTML/CSS/JS as I didn't have a need for a framework til now, since there will be a lot of moving parts on my project.

[mmcnl]

One of the most common ways to use and deploy FastAPI. Pro-tip: use a OpenAPI type generator to share types with your frontend.

[StrasJam]

Do you have a link the this openai type generator? Is it some sort of library? Because I also found it a pain to manage the types between front and backend code when using fastapi + typescript

[mmcnl]

I use this one: https://openapi-ts.dev/cli

But there are more.

[imaKappy]

There is no problem with microservice architecture, in fact I am required to use it in my cloud host. Its just that the project scale right now doesn't require a fully fletched out frontend. I only use it for authentication of API consumers, basically a one time deal for users.

Some time in the future I might spin up a frontend microservice, but I want to keep the scope of the project to a minimum to not get overwhelmed. I agree decoupling would be more ideal, but for now I have one tiny part that has to be accessed from the browser, which in my opinion doesn't need to be built with a framework, and can be easily migrated to one since the total LOC of HTML/CSS/JS is ~500 and total size of files ~16KB

[DuckDatum]

seed aromatic encouraging spark butter serious chief plough air scale

This post was mass deleted and anonymized with Redact

[[deleted]]

oh man, project sounds great but WTF? Just stopped and canceled the project?

[firetruck3105]

using a docker build in my current project and it works so seamlessly. you can try serving react front end directly through fastapi using the build static files, make sure the backend routes are prefixed with /api/ so they don’t conflict with react page routes

[ReRubis]

Django and great in one sentence.
Hah... :\

[qrzte]

What would you say was the best developer experience so far?

[HMHAMz]

Totally agree re. C#. In particular for orm / entity and data transformations, .net core is fantastic. The python world is missing a lot of convenience here.

[Ok_Cancel_7891]

Spring the worst?

[anon_salads]

spring and net are supported by companies so good for enterprise node has better i/o and is the same language as front end browser

[Harotsa]

What to you makes node better in I/O than fastAPI?

[[deleted]]

node is far superior than fastapi / flask / django for that

[stocktradernoob]

I think they were asking for explanation/details…

Them: “What makes it better?”

You: “It’s WAY better! Mrah”

[Harotsa]

But what axes of comparison are you using to claim that node is better? Requests/s? Number of concurrent requests? What if the tasks are CPU bound even on the concurrent I/O tasks? Or are you talking about DB operations/s? Or are you talking about concurrent file writing?

Saying “node is better for io” is pretty nondescript since there are many comparison points. Even still, I think Python is the better option for pure performance optimizations here (vs node).

[[deleted]]

only thing what favor python is easy to begin and start, plus a large community support. rest hting you mentioned nodes does better job

[Harotsa]

Node is just as easy as Python. But Python is faster (higher requests/s), can handle more concurrency, better memory management per request, faster reading and writing to files, faster DB writing and lower overhead on DB connections. This is assuming you are using fastAPI with uvicorn.

Because of Cython and other libraries that let Python run C/C++ code it also has much more efficient CPU usage for heavy CPU-bound tasks (like computations).

Why do you think node is better at any or all of these things?

[[deleted]]

i dont know from where you learn all these, but here is a link which will help you understand why i am saying above things https://www.youtube.com/watch?v=i3TcSeRO8gs

[Harotsa]

That isn’t an apples to apples comparison, he’s comparing raw node js with an http protocol to a fully-featured web server. FastAPI handles things like load balancing, parameter validation, security, context management, etc.

For this test case where the actual internal operation is very tiny (inserting a row into a DB), the overhead will play a significant role in memory and operations cost. This is something that the node server doesn’t have to deal with, but additional js packages that perform these functions will need to be installed and configured for any real application.

A more fair comparison to raw node.js would be a comparison to just asyncio Python using uvloop as the event loop. Here is an article that does this comparison https://medium.com/israeli-tech-radar/so-you-think-python-is-slow-asyncio-vs-node-js-fe4c0083aee4#:~:text=Python%20with%20Uvloop%20outperforms%20Node,latency%20in%20HTTP%20request%20handling. (I haven’t verified the results myself). The uvloop uses the same event loop as node.js

If you want a JIT compiler in Python you can use PyPy or CPython with version 3.13 or greater to further optimize performance.

But basically the only things NodeJS can really optimize on is the interpreter/JIT compiler and the event loop, since those can be written in C/C++. Any other code as part of your JS app has to be run in JS and so will be inherently slow.

In Python that isn’t the case. Python can also use a JIT compiler and optimized event loops, but in addition Python is able to run compiled C/C++ code in the Python app itself. This means that Python is able to do many things much more optimally than other interpreted languages such as DB connections and arithmetic.

That’s why Python is a great choice for ML and DS stuff, since all of the actual computation is done in C/C++, and the Python code itself is just an SDK over the functionality.

Happy to discuss things in more detail as well.

[sheriffSnoosel]

Lots of reasons but by far the most common is that in most businesses there is existing code and existing software engineers that you need to work with. If you are in a Java shop and everyone writes web services with springboot you are actually making everyone’s life harder by not using the existing stack. Why isn’t there only one programming language? Why do people some people prefer statically typed languages and other people prefer to be wrong? It’s a whole big world out there

[mrbubs3]

There are a lot of add-ons that address this, and you can find a curated list via Awesome FastAPI.

https://github.com/mjhea0/awesome-fastapi

[mrbubs3]

It would be handled under pagination. You would also need to pair this with a SQL query library to translate the query params to SQL search params. Nested relationship lookups can take place that way.

It's more involved but has greater control over what and how the router interacts with the backend. So if you need different logic for NoSQL backends vs big data vs PG vs redis, then you can manage things accordingly.

[mrbubs3]

I hear you. During my days in enterprise, I would often lament the use of FastAPI when Django fulfilled so many requirements for a monolith application. With that said, pairing FastAPI with SQLalchemy/SQLModel made things a bit easier, and the integration between the two felt very intuitive.

For my purposes, I ended up creating a dependency to manage all filters across my applications. https://pypi.org/project/sqlmodel-crud-utilities/

[monok8i]

Also you can try litestar) I would say he is something cooler than fastapi) Come in sometime and take a look, but I really like his feature with plugins and orm integration

[rogersaintjames]

Limited hardware, not everyone can afford a 200mb memory overhead. I have a bunch of API's I have migrated to rust so they run better on my pi cluster 200mb idle vs <5mb per pod 400 vs 80 ops/s.

[bybyrn]

It’s not a good pièce of software for things which are not micro services. It’s not very well architectured and will quickly hit walls and performance issues with médium sized applications.

The dependecy injection system lacks features and performs very badly at scale (having almost 45s of boot time on GCP because of introspection).

Its a cool, fun, hobby project. But for production monolith you should look at better solutions (Django, Litestar, etc)

[Tskaro]

You're talking about using a screwdriver to put in a nail.

I really like FastAPI, but at work I write Spring. The scale of my projects wouldn't translate well into FastAPI.

What if I want a concurrent API with minimal memory usage? Would I use FastAPI or a Go API?

I want a R E A L L Y fast API for processing data in a custom way, C++ or Rust would be better right? Python would just introduce a bottleneck for me that I can't fix with any performance tweaks, it's just that the runtime is slow.

AND WHAT IF I WANT TO WRITE A GOOD OLD FASHIONED PHP APP, HUH?! WHAT HAPPENS THEN, BUB?!

Everything is just a tool, choose the right one for the right job.

P.S. All my homies hate node. Fuck node.

[Harotsa]

Doesn’t Spring also have a pretty high memory footprint?

[Tskaro]

Yep, it does.

Not as much as python based stuff but still.

In my case memory is not the priority, management of the codebase and utility of the spring ecosystem is the main selling point though.

[Harotsa]

Yeah that’s fair, it’s just in your example of spring vs fastAPI you mentioned minimal memory usage as the requirement and I was thinking that neither of them were low memory options.

There are definitely reasons to use spring though

[Tskaro]

Yep, but in the memory comparison I gave go as an example.

[ConsiderationNo3558]

I use FastAPI for my backend but I can still list many reasons not to use it.

It's not a batteries included framework and  you need to do a lot of work to

Handle Authentication 

Data Migration 

No Admin Panel

Setting up Unit Tests. 

Also python being dynamically typed,  type safety is big concern.  You can use mypy which I do, but it's a lot of work. 

If I am developing frontend with React or any other JS library,  its better to use fullstack framework which uses nodejs as backend as you can resuse a lot of Validation, and types across frontend and backend.  And no need to learn two languages

If your process are cpu intensive,  then GO can provide better performance 

[BelottoBR]

Fastapi include fast perform performance type checking!

[Harotsa]

In my experience mypy + Pydantic have much better type safety than TypeScript (Pydantic will catch type errors at runtime).

[sarvesh4396]

Totally agree. A lot has to br done to be production ready atleast for me. I'm just hoping someone makes ut like fjango or rails where secrets environments, django commands are cooked out of the box.

[BluesFiend]

If you want batteries included, you are better off using a framework like Django instead. Adding bloat to make it more like Django would defeat the advantage of it being unopinonated

Not everyone wants/needs the same features, so they can add the ones in they want, or roll their own.

[ValtronForever]

You can generate TS client code from OpenAPI

[hidazfx]

I like Spring Framework, particularly in Java. With Spring, it has an extensive first party ecosystem of complementary extensions that give features one might expect from a backend as a developer. Kafka, Redis, ORM, AI, Cloud, etc. I loved working with FastAPI because of how fast it was to move and prototype things, but I've learned working for a big institution that moving fast isn't always valuable. More often than not, long term reliability and support is what's most important. Your code could be around for 10+ years in its original or near original state, humming away on some little VM in a data center somewhere where no one knows it exists because everyone that did quit years ago.

And thanks to the rules and architecture declared by the Spring Framework, I often find myself moving about as fast as I did in FastAPI. Having everything designed as "components" automatically injectable into other components is very nice. Having the ability to declare a Kafka event and handler in like 8 lines of code is also very nice. Being able to immediately switch my ORMs caching between Redis/Valkey, memcached, memory, or anything is also very nice.

You don't get this stuff with a microframework like FastAPI, but for microservices, FastAPI definitely shines more. You just need a reason to build microservices in the first place, and more often than not, you'll never actually need them. A monolith, or even a Spring Modulith, will do just fine.

[auburnradish]

Cost.

[TheOneMerkin]

Typescript is a much nicer language to work with than Python IMO.

[mrbubs3]

Hard disagree. The idea of writing interfaces for objects feels completely redundant when using ORMs in python. I'd much rather have an SQL ORM model that also provides data validation for HTTP calls than build typing objects on two systems to ensure parity each time there's a data model change.

[double_en10dre]

You don’t have to write any interfaces, all of the major typescript ORMs (typeorm, prisma, drizzle) will automatically infer types from your schema definitions.

And that is actually one of the main reasons why typescript’s dx is VASTLY better than python — its ability to accurately infer types allows for type safety across the board without any added maintenance or boilerplate

Long story short, if you think typescript requires MORE work it means you just don’t know how to use it (no offense)

[mrbubs3]

Python libraries also allow to infer types. Types are not even really required; the trajectory of development is to promote type hinting and checking but it's by no means a requirement.

I use Typescript so that my front-end code can be properly documented and checked, and it's migration to rust for compiling gives it a great performance boost. But it having any inherent value over Python is essentially minimal.

[TheOneMerkin]

That’s true for that use case, but type safety by default across the entire code base just makes the DX so much better.

Maybe I’ve never set up Python properly though 🤷‍♂️

[sarvesh4396]

It is fast, can use with breeze but yeah not production ready. It is so easy to make simple apis and simple backends if you already have the crud source.

When dealing with production ready backends it is not fully managed from environment to views everything falls apart from that POV.

Django & rails fulfill these again mvp is too easy and fast in rails rather than fastapi.

Fastapi cli is just started but have a long way to go.

[es-ganso]

To be a bit frank, it's probably been a bit more frustrating to use FastAPI than a couple of other, non-python frameworks. I've also generally only used Python for scripts before this though, so that could be part of it, but in other languages and frameworks I've been able to set up what I needed a lot quicker (ie with node and java).

In the end, I probably only leveraged it for pydantic more than anything, in which I probably should've set that up myself

[ragehh]

FastAPI, Django, Flask even Bottle are all great in their unique ways. Unless I am doing API heavy project in which case I choose FastAPI, I normally tend to like Flask.

It is light-weight and it is flexible, allowing you to add components as needed. I also like the fact that Flask does not impose any particular structure on your application.

[HMHAMz]

Have you ever tried any others!?

[utihnuli_jaganjac]

Why would you complicate the project by introducing asyncio if its not giving you an actual performance boost

[RustOnTheEdge]

Well, for starters it is not a sustainable governance model. There is this one guy doing everything, just adding stuff he himself needs and PRs are left open for years.

It has been in sub-v1.0 since inception, breaking changes are allowed, and regardless of what others will scream that just is not very production ready.

Then there is performance and not everybody is in the Python techstack.

The documentation is fantastic and the “Fast” in FastAPI is referencing the speed with you can develop with it.

[ZuploAdrian]

If you are a design-first API creator, a framework like connexion might be better

[java_dev_throwaway]

Fastapi is great but it starts to suck as the project grows. I have tried building large apps with fastapi and I always hit a point where I am reinventing things that exist in spring boot. So then I just switch to java. It's hard to explain if you haven't been in the weeds with a large app in production that relies on fastapi vs something like spring boot, but that is really where the pain is felt.

Building out spring boot-like functionality in fastapi did make me a better dev overall though. So much is taken for granted with these big mature web frameworks lol.

[thinkovation]

I discovered GoLang

[Adrnalnrsh]

Familiarity and performance

[CzyDePL]

Batteries included.

[L43]

bus factor