How to configure rewrite rules inside firebase-hosting to route certain requests to cloud functions?

Question

I've a PWA built using polymer 2.0 and polymerfire and is my web application. I've an express app acting as a cloud function (microservice). Example: exports.register=functions.https.onRequest(app);

How to add the rewrite rules to map say /fns/register and /fns/verify to the above app register.

I've updated my firebase.json file in the cloudfunction microservice project, but when I run firebase deploy --only functions:register it says there is no public folder for deploying the hosting configuration!

{
    "hosting": {
        "rewrites": [{
            "source": "/fns/**", "function": "register"
        }]
    }    
}

Maintaining the rewrite rules in the original web applicaiton could be one option, but still, is not ideal IMHO. If I've to do it in my original web application, I tried that as well, but couldn't make it. Following is my updated firebase.json in my original web application:

{
  "database": {
    "rules": "database.rules.json"
  },
  "hosting": {
    "public": "build/default/public",
    "rewrites": [
      {
        "source": "/fns/**",
        "function": "register"
      },
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

Answer 1

Maintaining just one project for all resources (Hosting, Functions and Database) is the ideal, I think is the right way to manage Firebase projects.

You are trying to change just one parameter (rewrites) of the hosting service, and it's not the way it works. When you deploy the firebase.json, all the others configurations are overwritten. So, the error you got is because Firebase don't look the last configuration file and check what's different to update, it just tries to overwrite all the last configuration file and get an error because "public" is a required parameter for hosting.

That explained, now you are expecting that Firebase rewrites /fns/register to just /register, but it'll not occur. Your function gonna receive the "full" url /fns/register.

The best way, I think, is to create a root route:

var functions = require('firebase-functions');
var express = require('express');

var app = express();
var router = express.Router();

router.post('/register', registerFunction);
router.post('/verify', verifyFunction);

app.use('/fns', router);

exports.fns = functions.https.onRequest(app);

And rewrites all functions to fns function:

{
  "database": {
    "rules": "database.rules.json"
  },
  "hosting": {
    "public": "build/default/public",
    "rewrites": [
      {
        "source": "/fns/**",
        "function": "fns"
      },
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

Now you can use https://<your-project-id>.firebaseapp.com/fns/register to reach your register function and https://<your-project-id>.firebaseapp.com/fns/verify to reach your verify function.

Answer 2

This question is already answered here Firebase Hosting with dynamic cloud functions rewrites

I agree with you that it is best to keep the SPA in one project and the microservice in a different one but @Marcos V its correct about using a root function

Answer 3

I've up-voted for the answer from Marcos V. but I can't really accept that as an answer. Primarily because in microservice world you won't create a monolith with all the functionality in one place. You would rather break into manageable chunks and make as many appropriate microservices as necessary/ reasonable for the application.

With the current set-up with firebase-hosting, you have to have the host configuration file in one project alone. Also, the hosting shall be in one project because all the HTML, JS, CSS related to your site would have inter-dependencies and hence are inseparable (at least as of now).

Whereas cloud functions are better deemed as microservices serving a definitive purpose and hence needs to be in separate project/microservice as needed. Which can be deployed easily with the firebase deploy --only functions:YOUR_FN_NAME

Whenever you need to have a mapping added for the new cloud functions microservice, go ahead and make the routing change in the main hosting application and deploy the same. With this approach, we can at least have the back end part being microservices.

Now maintaining database rules in the same hosting application or a separate project is left to the designers who can decide based on their usecase.