Deploy to firebase hosting from a firebase function

Question

Is it possible to deploy static assets from a firebase function to the firebase hosting?

Use case: A blog with static html files. Blog content and meta infos would be stored in the database (content as markdown). On publish or update, a firebase function is triggered which parses the markdown and generates a static html file for the blog post and deploys it to the firebase hosting. After deployment, the function would store the live URL in the database.

Would this workflow be possible? In the current documentation, I cannot find anything about deploy from functions.

As a workaround, I could imagine a setup with travis-ci. The function triggers a rebuild on travis, travis builds the static assets and deploys them to firebase hosting, but this seems like a huge overhead.

I could also pull the markdown content from the db and build on the client, but I really like to try the static file approach for initial loading time reasons.

Answer 1

I've haven't tried this yet, but I hope your cloud function could deploy new static files to firebase hosting with Hosting REST API.

I'll update this answer with function code and tutorial after some tests.

Answer 2

I haven’t fully investigated this yet but I wonder if this is what you’re looking for:

https://gist.github.com/puf/e00c34dd82b35c56e91adbc3a9b1c412

git clone https://gist.github.com/e00c34dd82b35c56e91adbc3a9b1c412.git firebase-hosting-deploy-file cd firebase-hosting-deploy-file npm install

perform a dry run, make sure you're not doing something you'll regret node deployFile.js contentsite /index.html

do the deletion for real node deployFile.js contentsite /index.html commit

Answer 3

I have been wanting to do this for a long time, and it seems that with the newly unveiled Firebase Functions Hosting Integration... well, we still can't do exactly what we want. But we can get close!

If you follow the read the post above, you can see how we can now edit the firebase.json redirect a URL(s) to point to a firebase function which will can build the page from markdown stored in firebase and serve that to the client.

The thing is, this happens on every GET request for each page. Which is dumb (for a largely static page like a typical blog). We want static pages that are instantly available without needing to wait for functions to generate anything (even though that happens really fast). We can mitigate that by setting the Cache-Control header to an arbitrarily large number with the response object as in

res.set('Cache-Control', 'public, max-age=600, s-maxage=31536000');

Which will tell the browser to cache the result for 10 minutes, but the CDN to cache it for a year. This almost solves the problem of wanting pre-rendered, instantly available pages for all but the first hit, which will incur the render cost. Plus, the CDN can evict your cached content if it determines that there is not enough traffic to warrant storing it.

Getting closer.

But we aren't quite where we need to be. Say you publish your post and a few days later, notice a typo? Well, I think you are pretty much hosed. Your cached content will continue to be served for the rest of the year unless you do something like:

Change the URL of the Post - This is probably a bad idea, as it will tank any SEO and break links to the page that are already in the wild.

There may be a way to force the CDN to update, perhaps by augmenting your 'publish blog post' process to included a javascript GET request with something odd in the request header, or maybe there is a way to do it with a firebase function any time the post gets updated. This is where I get stuck.

Firebase uses Google's Cloud Platform CDN which includes a mechanism for Cache invalidation, but I don't know that this is readily available from functions -- and even if it does, it still doesn't solve getting evicted from the cache.

Personally, I will probably use the setup I described with a CDN cache age limit of intermediate length. This beats my current approach of sending markdown to the client and rendering locally using (the excellent) showdown.js, which is still really fast, but does require client side javascript and a few cpu cycles.

Hopefully someone will have a solve for this (or someone at firebase can slip pushing to hosting from functions into the next release :) ). I'll update my answer if I get it nailed down.