How can I force my nodejs app running on Google App Engine, to always redirect to HTTPS ?
I have a pretty vanilla app that looks like this:
This thing is running in Google App Engine (GAE), and I’d like to make sure it listens only on HTTPS. There are standards like HSTS that can help. How can I use them?
This question and answer on Stackoverflow showed me the way. Basically, just add in a tiny module called yes-https. The new code looks like this:
Redeploying (no change to app.yaml) gets me the always-HTTPS behavior I want. When a client requests my service via http, it receives a 301 redirect pointing to the secure site.
HTTP/1.1 301 Moved Permanently
Date: Wed, 20 Jun 2018 16:27:56 GMT
Via: 1.1 google
Nice, easy, clear.
Thanks to Justin for this handy module.
Recently I decided to download “the latest and greatest” URI.js, and what I found… did not make me jump for joy.
URI.js is no longer “just downloadable”.
Where before I could just download the raw JS file, URI.js now has a builder that allows me to select which options I wish to include. I get the concept, and it’s a nice idea, but when I de-selected every option, I got a minimized URI.js that I did not want. When I went to the source tree I found a URI.js that included all the require() statements for punycode, Second-Level Domains, and ipv6, all stuff I did not want.
I couldn’t figure out how to get it to “just work” in nodejs without all of that, so I had to resort to manually changing the code. Basically I just removed all the require() statements for those unneeded / unwanted modules.
And it works.
It’s possible I’m missing something basic, but for sure, it got more complicated to get the simple solution. Seems like a step backward.
I write more code using NodeJS these days, than in anything else.
Recently I had occasion to write a little utility that computes TP99 for a set of API transactions being managed by Apigee Edge.
What it does is retrieve the transaction records logged from the Edge Analytics database, sorts them, and emits a computed TP99 (and TP95, TP90, TP50) to a Carbon server, which is backing Graphite, which then serves up charts of that data. A sample is below.
For this tool, I chose NOT to use NodeJS but instead relied on good-old PERL. I didn’t want asynchrony, and I did want easy file I/O, pattern matching, and sorting. Also I wanted it to be maintainable by old-school sysadmins who no-doubt have not been following the finer points of using Q’s promises in NodeJS. Perl was the obvious choice. The sort required to compute TP99 will run on 60000 records or more, and needs to occur every minute, for all transactions logged during that minute. A cron job running a perl script was perfect for this.
But, recently I wrote another tool… this one automates the provisioning of EC2 instances in AWS, then installs Java and Apigee Edge on them, and configures them into a cluster. I wouldn’t want to do that in perl or Bash. NodeJS was the right tool for that much more complicated job. And of course there are NPM libraries for AWS, and for ssh and scp. Really helpful.
A provocative post by Eric Jiang, entitles “The emperor’s new clothes were built with Node.js”, regarding the undeserved praise being heaped upon NodeJS. While I think he gets his analysis all right, he is still missing the forest for the trees.
Nodejs has grown the way it has grown for the same reason that Visual Basic and PHP grew the way they did: These things work well, and help people get things done quickly and relatively easily. And maybe, people even have fun doing it. The community support has been critical in all three cases.
Sure it’d be nice to have multi-threading like Go and a single set of known and blessed libraries like C# and performance like C. But we don’t have all those things in one package, not yet anyway.
No religion, yo: nodejs is not always the right choice. Of course it isn’t. I like nodejs and use it… daily. but I’m learning Go and am enjoying that as well.
Remember a while back when I wrote that Node.js is popular and getting moreso?
Well, today I came across a blog that explains why.
In the very clearest terms.
A while back I commented on a rant by someone who said that NodeJS is stupid and if you use it, so are you.
I didn’t agree.
But, NodeJS documentation is stupid. Look, for example, at the doc for the http.request() object and it’s syntactic sugar cousin, http.get(). Let’s suppose you want to do an http get from within a node program. So you look at the doc for http.get, which says: This is like http.request(), except it sets the method to GET and calls req.end() automatically.
I wonder what that callback parameter is? http.get() accepts a callback parameter. Obviously it’s a function, but WHEN Does it get called? The doc doesn’t say.
Hmm, not very much to go on! So now I have to read the entire entry on the http.request() function. The http.get() sugar doesn’t really offer much benefit if I have to read the doc for the lower-level method, now, does it? But guess what! The doc entry for http.request() ALSO does not define the semantics of the callback parameter. It’s just a callback.
I guess if I have to ask, then I don’t need to know.
Uh, folks, I’m here to tell ya, that ain’t new or novel.
ASP later became part of Windows NT, and in subsequent service packs and in Windows 2000, IIS + ASP was just “in there”. Prior to the NTOP, Windows NT 4.0 included IIS, but IIS was just a static web page server and CGI server. (I think). ASP was something a little different. By the way, ASP is still supported in IIS, yea verily, after yea these many years, 17 years by my count. So… to all those poeple who claim that Microsoft doesn’t support technologies long enough, ASP is counterexample #1.
In practice, “Classic ASP” code often resembles what I will call “Rubbish PHP” code, which is to say, it mixes markup with code, willynilly, there’s poor templating, poor code re-use, poor use of classes and generally things are just an unmaintainable mess. But that is by no means required by either Classic ASP or PHP. That is just an unpleasant side effect of being really easy to use, which means novice programmers use it. Both Classic ASP and PHP have that quality. It is possible to author nicely architected ASP code, and PHP code.
Nicely architected? If I may be so bold, here’s an example.
One thing that makes NodeJS different is asynchrony. Classic ASP did not support asynchrony very well.
Another thing that sets NodeJS apart now, is the active community and the sharing. the npm is a beautiful thing, and while there were many many ASP Classic developers back in the day, there was no such thing as npm and they resorted to newsgroups and forums to share code. Primitive approaches compared to what we do now, for sure.