[RFC] FastAPI as an Odoo-managed Sidecar Process (Alternative Architecture)

[orcapod-tech]

Hi OCA maintainers and the rest-framework team,

I’ve been working on a different approach to integrating FastAPI with Odoo, and I’d really appreciate your expert feedback on it.

💡 Overview

Instead of running FastAPI inside Odoo’s HTTP/WSGI stack, this PoC runs it as a separate sidecar process that is started and stopped together with Odoo.

In short:

• FastAPI runs in its own process (Uvicorn).
• It’s started directly from Odoo (via post_load).
• Each request creates its own Odoo Environment using Registry(db).cursor().
• Transactions are handled per request (commit / rollback).
• Auth is done using either Odoo sessions or API keys.

🔄 Main Difference

Compared to the current approaches:

• OCA REST / FastAPI: Runs inside Odoo.
• This approach: Runs outside Odoo as a separate, but attached, service.

The goal here is not to replace existing solutions, but to explore a different setup that might be more suitable for async-heavy use cases.

🚀 Why I Tried This

Mainly to see if it makes sense to:

1. Use FastAPI with native async features (SSE, WebSockets, streaming, etc.).
2. Handle external I/O (like AI/LLM streaming calls) without tying up or blocking Odoo workers.
3. Keep API traffic somewhat isolated from Odoo’s main HTTP layer.
4. Work with standard FastAPI patterns without having to adapt everything to Odoo's framework.

⚠️ Concerns / Things I’m Not Fully Sure About

Since this is just a PoC, there are a few things that I expect could be problematic or need strict guardrails:

• Environment Management: Creating a new Environment per request.
• Sync ORM: The Odoo ORM is still synchronous (runs in a threadpool).
• Concurrency: Possible misuse of the same cursor/env in concurrent async code.
• Multi-worker constraints: With --workers, there is currently still only one sidecar process.
• Registry Staleness: A separate process means a separate registry (possible staleness after module updates).
• Security & DB routing: Database selection is currently request-driven (needs proper restriction).
• Auth: Cookie-based auth depends on shared session storage.

🔗 Proof of Concept

You can review the implementation details here:
orcapod-tech/fastapi-addons (18.0)

🤔 Questions for the Maintainers

These are the core questions I am trying to answer before proceeding further:

1. Safety & Architecture: Is this architecture fundamentally safe, or are there hidden pitfalls/side effects in Odoo's core that I might be overlooking by running a sidecar this way?
2. Docker Deployments: How does this approach play with containerized environments? Do you foresee any networking or lifecycle issues for users deploying Odoo via Docker?
3. Odoo.sh Compatibility: Is this sidecar model compatible with managed platforms like Odoo.sh, or would their strict infrastructure rules (ports, background processes) block it?
4. Performance (Env & Event Loop): Regarding the Odoo Environment per request and running an asyncio event loop alongside Odoo: will this introduce significant overhead or negatively impact Odoo's overall server performance?
5. Final Verdict: Ultimately, is this a viable path worth pursuing, or is it fundamentally impractical, meaning I should look for a different architecture?

📌 Status

This is strictly a proof of concept to test the viability of the idea. Before investing more time into it, I want to make sure I’m on the right track.

Thanks for your time and for the amazing work you do! 👍

Best regards,
Omer Ahmed

[omerahmed1994]

Just a quick note: I accidentally opened this issue using our organization account (@orcapod-tech), but I am the author of the PoC and will be following up and replying from this personal account.

Looking forward to your feedback! 🚀

[lmignon]

Hi @omerahmed1994, the approach you describe is the one we promote at Acsone when it comes to the development of an api for a specific customer on top of all the specific addons (no need of the extension mechanism from odoo etc...) It has been setup and presented by Stephane Bidoul some years ago (in 2021 https://www.odoo.com/fr_FR/event/odoo-experience-2021-2847/track/how-to-efficiently-create-modern-rest-apis-with-fastapi-and-odoo-4222).

[omerahmed1994]

Hi @lmignon ,

Thank you so much for your reply! I really appreciate you taking the time to respond, and I want to express my gratitude to you, Stéphane Bidoul, and the entire Acsone & OCA teams for all the effort and contributions you’ve made — it’s truly inspiring.

I’ve reviewed both the FastAPI addon you worked on and the video by Stéphane Bidoul from Odoo Experience 2021, and I must say it’s excellent work. I’ve also used and explored many tools from Acsone & OCA, and I have great respect for the value they bring to the community.

I’d love to get your advice: in your opinion, would the work I’ve done be worth sharing with the community as an Odoo Apps addon or on GitHub, or would it be better to manage FastAPI as a separate service providing RESTful APIs for Odoo?

Looking forward to your thoughts!

Best regards,
Omer Ahmed