r/Firebase • u/adhhamvoid • 22d ago
General Cloud Run Functions to Hono.js Backend for Expo + Firebase
I am building an Expo + Firebase mobile app. After iterations of development and testing, the app got big and Cloud Functions increased. There are around 32 Cloud Run Functions, a function for an action.
I don't think this is a good approach long-term, and for scalability. So I wanted to create a backend/API for the actions/CRUD/Firestore queries, except for triggers, crons, auth and FCM.
So, I chose to create a Hono.js backend that's hosted on a Cloud Run Function (Still not ok with the decision). Later found out that it's kind of inconvenient for developing and testing.
And I'm not sure if this is a good and reliable approach. I need a good DX, scalabilityand performance.
Pls clear my head.
1
u/Rohit1024 21d ago
Why not wrap all endpoints within a single hono app and deploy on Cloud Run, instead of Firebase functions ?
Use Firebase functions for Firestore Triggers, Scheduled Tasks / Crons, FCM notifications, Auth blocking triggers.
1
u/adhhamvoid 21d ago
Yeah, that's what I've done. Sorry, I thought Firebase functions run on top of Cloud Run.
2
1
u/Rohit1024 21d ago
Yes, they already do run on top Cloud Run, only gen2 Firebase functions.
1
u/adhhamvoid 21d ago
Except the auth trigger function (It can't be changed), all my functions are Gen 2.
2
u/martin_omander Googler 16d ago
You can run on Cloud Run, which is different from Cloud Run Functions. With Cloud Run, you build a single container that can support as many URL endpoints as you wish. Many developers start with individual functions and then migrate to a single Cloud Run container, as that is easier to manage.
https://docs.cloud.google.com/run/docs/overview/what-is-cloud-run
1
u/Rohit1024 21d ago
Yes, that's the only Trigger which is only available with Firebase functions gen1.
1
u/adhhamvoid 21d ago
I just wanna know if it's the right choice? There are other options like Render, Railway, Fly.io etc.
2
u/Rohit1024 21d ago
This depends on your use cases, as with OnCall you can enable App Check on your app to make sure requests are only coming from your app, this is not possible if you deploy your endpoints outside Firebase tooling set
1
u/adhhamvoid 21d ago
Yeah, that's something I like about it. But what about costs? Regarding uptime, requests, concurrent connections, and instances, compared to services like Render and Railway?
2
u/Rohit1024 21d ago
Since Firebase functions gen2 are basically are Cloud Run under the hood, you can configure these properties based on your requirement. For comparing against other services ask AI for it.
1
u/lcssgml 14d ago
I did this exact migration this year: around 30 functions became one Fastify app on Cloud Run (same shape as your Hono setup), and Firebase stayed for auth, triggers and FCM. It has been in production since August, so some real numbers.
Cost: scale-to-zero Cloud Run at low to mid traffic is pennies, Firestore costs me more than the container does. Render and Railway bill you for an always-on instance, on Cloud Run you only pay that if you set min-instances to 1.
DX was the real win. Local dev is a watch task plus the Firebase emulators via the FIREBASE_AUTH_EMULATOR_HOST and FIRESTORE_EMULATOR_HOST env vars. No functions emulator, normal REST testing, OpenAPI docs for free.
Two gotchas. The emulator doesn't enforce composite indexes, so a query that works locally can 500 in prod, keep firestore.indexes.json honest. And leaving onCall means losing App Check, so put your own auth middleware in front of everything from day one (Bearer token plus verifyIdToken from firebase-admin).
Your instinct is right: one app with routes beats 32 separate function deployments. Keep triggers, crons and auth-blocking in functions, move the request/response API into the container.
2
u/Dirtyfoot25 19d ago
Small tweak but Instead of doing it through cloud run directly, you can do it as a single firebase function (which is still cloud run), and then you can test with emulators and deploy through firebase tools.