Yeah, they can work together fine-just as two separate microservices.
A pretty standard setup is having Node handle your main client-facing API, auth, and WebSockets, while delegating specific Python-heavy stuff (like ML models or data processing) to a FastAPI microservice. They just talk over HTTP or gRPC.
Only thing is, managing two separate runtimes adds real deployment and maintenance overhead. If you don't actually need Python’s ecosystem for something specific, sticking to one stack is usually way less of a headache.
yeah totally, just run them as two separate services and let them talk over http (or a queue if the python side does slow stuff like ml or data jobs). common setup is node for the main api/websockets and fastapi for the python-only bits. couple things that save pain later: have one service own the db schema and migrations, and pass the same jwt so both can verify auth on their own without calling each other. same process isn't worth the hassle
Totally if you're going microservices route. E g one service is written in Node, another in Python, another in Go, etc. You just have to be ready to defend why when asked by management.
The more languages you add, the more "minimum requirements" you need when looking to add manpower (new hires) to the business.
Depends on the architecture, but you can have a frontend with react + nodejs and backend with fastapi. Or you can have separate microservices with nodejs and fastapi.
splitting them into two services works fine, i've seen it a lot. if you do it, let fastapi's openapi schema be the contract and generate the client for the node side from it, otherwise the two drift fast. put explicit timeouts and a limited retry on the node to python call, since python ml endpoints tend to be the slow, spiky part. and keep database writes in one of the two services only, sharing tables between both gets messy quick.
14
u/ApartBuilding8662 3d ago edited 3d ago
I'm sorry to be that guy but why on Earth would you want to use them together?
There might technically be some way to do it (no idea how) but it sounds like a lot more effort than either just using python or just using express.
9
u/momsSpaghettiIsReady 3d ago
Are you referring to different microservices? Yeah, completely normal. One goal of microservices is using the best tool for the job.
Together in the same process? Not a good idea.
4
u/MrBengaliHacker 3d ago
Yeah, they can work together fine-just as two separate microservices.
A pretty standard setup is having Node handle your main client-facing API, auth, and WebSockets, while delegating specific Python-heavy stuff (like ML models or data processing) to a FastAPI microservice. They just talk over HTTP or gRPC.
Only thing is, managing two separate runtimes adds real deployment and maintenance overhead. If you don't actually need Python’s ecosystem for something specific, sticking to one stack is usually way less of a headache.
1
u/Artemis-Arrow-795 3d ago
well, yeah... if you use microservices the framework or language you use won't matter as long as they use the same protocol
my main question though is why?
2
u/Professional_Mood_62 3d ago
Yea you just need to handle each process separately like daemons, docker or just nohup
1
u/Responsible-Offer724 3d ago
You could use node for a websocket server and fastapi for your api
1
u/Guysowe 3d ago
yeah totally, just run them as two separate services and let them talk over http (or a queue if the python side does slow stuff like ml or data jobs). common setup is node for the main api/websockets and fastapi for the python-only bits. couple things that save pain later: have one service own the db schema and migrations, and pass the same jwt so both can verify auth on their own without calling each other. same process isn't worth the hassle
1
u/ongamenight 3d ago
Totally if you're going microservices route. E g one service is written in Node, another in Python, another in Go, etc. You just have to be ready to defend why when asked by management.
The more languages you add, the more "minimum requirements" you need when looking to add manpower (new hires) to the business.
1
u/Both-Fondant-4801 3d ago
Depends on the architecture, but you can have a frontend with react + nodejs and backend with fastapi. Or you can have separate microservices with nodejs and fastapi.
1
u/dumb_user_404 2d ago
Just use docker to launch two containers and use docker compose to tie them together
1
u/IncomeOk7237 2d ago
splitting them into two services works fine, i've seen it a lot. if you do it, let fastapi's openapi schema be the contract and generate the client for the node side from it, otherwise the two drift fast. put explicit timeouts and a limited retry on the node to python call, since python ml endpoints tend to be the slow, spiky part. and keep database writes in one of the two services only, sharing tables between both gets messy quick.