Why My Finance Dashboard Has Two Backends (And What Broke When I Deployed It)

#architecture #backend #showdev #webdev

I built a personal finance dashboard to help people keep track of their expenses. Here's why I split it into two backends, and the CORS issue that taught me more than the rest of the project combined.
This finance dashboard is really helpful for users to keep track of their expenses. All you have to do is add your budget for your needs, that's it, you can relax now. When you start spending money, just let the finance dashboard know where and how much you are spending. Take a look at the finance dashboard at the end of the month to see where you spent the most and where you saved money. This product helps people be more careful and aware of their spending. It is mainly for young people who are just starting to spend their own money.
The Architecture
The finance dashboard has two backends: a Node and Express server that handles adding expenses, deleting them, and setting budgets, and a Python and FastAPI server that handles all the analysis and chart data. Both backends connect to the same MongoDB Atlas database.
I chose to use two languages because each one is good at different things. Node and Express are great for simple tasks like adding an expense or deleting an entry i.e. things where you want it to happen quickly and don't need a lot of computation. Express handles this with minimal overhead.
The analysis part is different. To see how much you spend each month, how much you spend in each category, and how your budget compares to what you actually spent, you need to look at all the data, group it by category and month, and do some math. This is what Python is good at i.e. looking at data, grouping it, and doing math.
If I had built this project entirely in Node, I would have had to write a lot of extra code to do the analysis. If I had built it entirely in Python, the simple tasks would have been more complicated. So I split it into two backends. Each one does what it's good at.
The downside is that I now have two servers to manage, which means two deployments, two sets of environment variables, and a connection between them that I have to maintain. This is the cost of my decision, and I want to be clear about it.
How They Talk to Each Other
The React frontend talks to both backends directly. When you add an expense, it goes to the Node server. When you look at the analysis, the pie chart or the line chart, it goes to the FastAPI server.
Here's how it works: when you add an expense, the React form sends a request to the Node server, which writes it to the MongoDB Atlas database. Then the frontend asks the FastAPI server for the updated analysis, which looks at the data, does the math, and returns the updated chart data. The two backends never talk to each other directly. They only share the database.
The Biggest Challenge — CORS
The biggest challenge wasn't the analysis or the simple tasks. It was getting the frontend to talk to both backends after deployment. When I was testing it on my computer, everything worked fine. When I deployed it, the frontend on Vercel, the Node server on Render, and the FastAPI server on Render as a separate service, each on a different domain, the browser started blocking requests because of CORS.
To fix this, I had to configure CORS on both backends separately. On the Express server, I added the cors package and specified which origin was allowed to make requests. On the FastAPI server, I did the same using FastAPI's CORSMiddleware.
What made this harder was that I had to debug two problems instead of one. If a request failed, it could be because of the Node CORS config, the FastAPI CORS config, or both. The fix that worked was being explicit i.e. only allowing the exact deployed frontend URL on both servers from the start.
What I'd Do Differently
If I were to start over, I would focus on CORS from the beginning and make sure both the Express server and the FastAPI server are configured correctly before deploying. This would make the deployment process smoother and avoid the back-and-forth debugging across both servers.