Kicking off a brand-new project is always a fun mix of grand architecture planning and immediately running into weird setup bugs. This week, we officially started the MedReach-AI capstone project, and my main focus was getting our Python and FastAPI backend repository scaffolded and ready to go.
Overall, the basic server setup was a breeze, but hooking up our local dev tools and establishing the Git workflow threw a couple of curveballs my way.
The Problem: Firebase Emulators vs. Strict Security
I set up the Firebase Emulator Suite for our Firestore database so we can develop locally without worrying about cloud costs. Usually, when you connect the Firebase Admin SDK to a local emulator, you just pass a dummy credential dictionary with a fake private key (like "private_key": "mock-key"). But when I spun up the Uvicorn server to test it out, the app immediately crashed.
It turns out the underlying Python cryptography package recently got a security upgrade. It now strictly validates the math behind RSA keys before the app is even allowed to start. Since my "mock-key" obviously wasn't a valid RSA structure, it threw a ValueError: Unable to load PEM file and stopped the server dead in its tracks.
The Fix: Demo Projects to the Rescue
Instead of wasting time trying to generate a mathematically valid fake RSA key—which kind of defeats the purpose of a quick local setup—I realized I could bypass the certificate requirement entirely.
Firebase actually has a built-in way to handle this. By stripping out the dummy credential and initializing the app with a "demo" project ID, the SDK knows it's strictly in an offline testing environment.
Python
Tell the SDK to connect to the local emulator
os.environ["FIRESTORE_EMULATOR_HOST"] = "127.0.0.1:8080"
Initialize using a demo project ID instead of a certificate
if not firebase_admin._apps:
firebase_admin.initialize_app(options={
'projectId': 'demo-medreachai'
})
That completely fixed the crash. My /api/health endpoint was instantly able to query the local Firestore database.
The Problem: Git Remote Collisions
Next up, I needed to push this clean, working baseline (complete with Black and Flake8 formatting) up to our backend-dev branch on GitHub. Simple enough, right? Nope. Git immediately rejected the push.
Because the repository was originally created on GitHub's website before I scaffolded the local files, it had an auto-generated template commit (like a default README) that my computer didn't have. Git’s safety features kicked in to stop me from accidentally wiping out that remote work.
The Fix: A Good Old-Fashioned Force Push
Usually, running git pull --allow-unrelated-histories is the move here to merge the two timelines. But since my local environment was specifically built to be the absolute "source of truth" for the backend, I didn't want to merge in random GitHub template files.
I went with a force push to overwrite the remote branch and establish my local folder as the true baseline:
git push -u origin backend-dev --force
Wrapping Up Sprint 1
With Git sorted out and Firebase playing nice with the emulator, the MedReach-AI backend is officially up and running. Our Uvicorn server is live, the interactive Swagger UI is generating our docs automatically, and our linters are keeping the code clean.
The foundation is set, and next week we finally get to dive into feature development!
Top comments (0)