As coding geeks ourselves, this blog will also feature articles about our own development experiences. Last week was a pivotal moment in our development: I decided to go serverless. Even a week ago if I had put MonsterCoding.com online, it would have been served up by Node.js. I actually love Node.js, and it has made developing rich internet apps way easier. I have access to tons of cool libraries on my desktop that I can use in Grunt or via the command line to automate things, clean things up, process my templates and SASS files, etc.
But I am no expert at Node.js. And using it to actually serve up our website and app made me really nervous. Node.js has the scary habit of completing stopping over a small error. That means your entire site goes down, not just the offending page or process. As we are gearing up for the Hour of Code, the idea of app served by a backend that I cobbled together with online samples, and could crash at any moment, gave me a lot of pause! Then I read an article about Amazon’s JAWS stack. Basically, you keep your website itself static, then use the server stuff on an on demand basis. Eureka! What a sweet idea. Since our website and app are Backbone.js, Dust.js, and jQuery.js at the hear of things, extricating the login and some of the routes from Node.js was a breeze. Now I can just use an AWS Lambda for our social login, as well as saving user data to the Cloud.
The website is served up via Amazon’s Cloudfront, which has some 15 locations where they cache your files for quick serving. The caching is good and bad, mainly bad when you’re trying to get new changes live quickly. You have to actually manually invalidate things in the cache, which isn’t instant. Or set a no-cache header on the file, which means the file won’t be cached at all, which also isn’t a perfect scenario. But right now I am extremely excited about the serverless website, as it nips a bunch of potential problems in the bud, even before they have a chance to crop up.
| Home | About |