Ir al contenido principal

Ralsina.Me — El sitio web de Roberto Alsina

Publicaciones sobre web

CORS config for FaaS

Be­cause I want to be able to de­ploy ran­dom python code eas­i­ly to my own server, I have set­up a "Func­tion as a Ser­vice" thing, called faasd (think of it as poor peo­ple's AWS lamb­da). More de­tails on how, why and how it turned out will come in the fu­ture. BUT: this ex­plains how to fix the un­avoid­able headache CORS will give you.


  • The Faasd serv­er runs in some ma­chine, which is prox­­ied by a Ng­inx serv­er avail­able at http­s://­­faas­d.ral­si­­

  • Apps are just HTML pages some­where in­­­side ei­ther http­s://ral­si­­ or some oth­­er sim­i­lar do­­main.

What will happen?

You will set­up your func­tion, test it out us­ing curl, be hap­py it work­s, then set it up in your web app and get an er­ror in the con­sole about how CORS is not al­low­ing the re­quest.

What is CORS and why is it annoying me?

CORS is a way for a ser­vice liv­ing in a cer­tain URL to say which oth­er URLs are al­lowed to call it. So, if the app are in, say, http­s://nom­bres.ralsi­ and the func­tion lives in http­s://­faas.ralsi­ then the ORI­GIN for the app is not the same as the ORI­GIN for the func­tion, so this is a "Cross Ori­gin Re­quest" and you are try­ing to do "Cross Ori­gin Re­source Shar­ing" (CORS) and the brows­er won't let you.

How do I fix it?

There are a num­ber of fix­es you can try, but they all come down to the same two ba­sic ap­proach­es:

Option 1

Make it so the re­quest is not cross-­source. To do that, move the func­tion some­how in­to the same URL as the page, and bob's your un­cle.

So, just change the proxy con­fig so nom­bres.ralsi­­func­tions is prox­ied to the faasd server's /func­tions and change the page to use a re­quest that is not cross-o­rig­in, and that's fixed.

I don't want to do this be­cause I don't want to have to set­up the proxy dif­fer­ent­ly for each ap­p.

Option 2

Have the func­tion re­turn a head­er that says "Ac­cess-­Con­trol-Al­low-O­rig­in: some­thing". That "some­thing" should be the ori­gin of the re­quest (in our ex­am­ple nom­bres.ralsi­ or "*" to say "I don't care".

So, you may say "Fine, I'll just add that head­er in my re­sponse and it will work!". Oh sweet sum­mer child. That will NOT work (at least not in the case of Faas­d)


Be­cause web browsers don't just make the re­quest they want and then look at the head­er­s. They do a spe­cial pre­flight re­quest, which is some­thing like "Hey, server, if I were to ask you to give me /func­tion­s/what­ev­er from this orig­in, would you give me a CORS per­mis­sion or not?"

That re­quest is done us­ing the OP­TIONS HTTP method, and Faasd (and, to be hon­est, most web frame­work­s) will not process those by pass­ing them to your code.

So, even if your func­tion says CORS is al­lowed, you still will get CORS er­rors.

You can see this if you ex­am­ine your browser's HTTP traf­fic us­ing the de­vel­op­er tool­s. There will be an OP­TIONS pre­flight re­quest, and that one does­n't have the head­er.

So, the eas­i­est thing is to add those in the proxy.

So, in my case, in the prox­y's ng­inx.­con­f, I had to add this in "the right place":

  add_header 'Access-Control-Allow-Origin' '*';

What is the right place will vary de­pend­ing on how you have con­fig­ured things. But hey, there you go.

Making my site FAST

My site is cre­at­ed us­ing a tool I start­ed and on which I have put a ton of ef­fort over the last 10 years or so, called Niko­la, which is a stat­ic site gen­er­a­tor (SS­G).

One of the sell­ing points of SS­Gs is that the pro­duced sites are fast and I have al­ways tak­en care to check, ev­ery once in a while, that my site was fast ... but not late­ly. And when I checked on Google Page­Speed In­sights I was hor­ri­fied to see it scor­ing 20 points out of 100.

So, I start­ed to see what the heck had hap­pened.

Google PageSpeed HATES Youtube

Each em­bed­ded video is seen as 4MB of block­ing things load­ing and mak­ing your page suck.

So­lu­tion: de­fer load­ing them us­ing http­s://github.­com/­group­board­/yt­de­fer

Bundling things still works

It has been years since it was promised that bundling mul­ti­ple CSS files in­to a large one or merg­ing mul­ti­ple JS files in­to a sin­gle script would not be worth it.

Well, ac­cord­ing to Page­Speed, it's still worth it. Luck­i­ly Niko­la has good sup­port for it, so I made sure EV­ERY­THING was bun­dled. That al­so in­volved get­ting some things off CDNs and in­to my as­sets fold­er:

  • pris­mjs
  • jquery

Google fonts are SLOW

Like, 400ms for two fonts. So, you can self­-host them us­ing http­s://­google-web­fonts-helper.herokuap­p.­com/­fonts


  • use font-display: swap
  • preload the fonts using something like <link rel="preload" href="/assets/fonts/pt-serif-v11-latin-regular.woff2" as="font">

Check CSS for @import

Even after bundling them, if a CSS file uses @import that will still be a separate request.

Check compression and caching

Make sure your web serv­er is do­ing the right things there.

Remove useless stuff

I was load­ing font-awe­some for ONE ICON. There, gone.

Did it work?

Now the score hov­ers around 96 to 98 so, yes it did. And in­deed the page feels very, very snap­py.

Contents © 2000-2023 Roberto Alsina