Monthly Archives: October 2013

“selfhelp” – a self-upgrading Node.js application

I have a strange little project I’ve been working on over the last few weeks. It’s an example app I wrote using Node.js which is capable of self-upgrading itself to new versions. Thus you could use it as the basis of a cross-platform application with a browser based UI like¬†SABnzbd+, the Plex Media Server, Couch Potato, and Sick Beard. All of which work on different operating systems (Mac OS X, Windows, and Linux) and which offer the same UI across all of them. So, this isn’t really intended for use on servers as much as it is intended for use on desktop machines so you can build apps using Node.js and whatever front-end technologies you happen to fancy (my particular flavor is AngularJS, though there is none in the example application).

I got it to where it works well on Mac OS X so I thought I’d write about it and maybe someone else would find it interesting enough to see if they could add a Windows batch file to it, maybe test it on Linux, or see if it suits a project they have been wanting to build. It’s called “selfhelp” and it’s available over on Github:

About these ads

6 Tips for building JavaScript apps

I’ve actually built a few JavaScript applications in the new style (AngularJS, Backbone.js, or other front-end JavaScript framework on the front-end and only APIs on the back-end) over the last couple of years. Here are some tips on what I think has worked well on those projects:

  1. Understand this, above all else, the front-end code is not real security! If you’re an American you can understand this via an analogy. The JavaScript code running in the browser is the TSA, it is security theater which exists just to make some user’s experience better. For example, it might hide buttons which the user is not allowed to click. But that doesn’t mean that the user cannot hack the JavaScript to turn on the forbidden button anyway. All of the real security in your application exists at the API layer. It must check every single value passed to it and confirm that the user has the permissions to perform the action he/she is trying to perform before actually doing anything. Likewise, it must not return any information which the logged in user should not have access to. Relying on the JavaScript code to hide part of the data will not work. Put all of your security focus on having a bulletproof API and you will never have real security problems.
  2. People use HTTP error codes to communicate back data for their APIs. In my opinion that’s a really bad idea and often not very adaptable to the actual errors you’re having. Instead use the JSend protocol for all the JSON you return. It’s the same objects you would probably send back today except that it is wrapped with an object that tells you status (‘success’, ‘fail’, or ‘error’) and messages/codes when appropriate because there were errors. Going this route will simplify your JavaScript service calling code and help you differentiate API errors from actual transport layer problems like servers being down or problems on the network.
  3. Don’t try to sequence operations from the front-end. I once answered a question on Stack Overflow where the asker wanted to know about how to sequence a seven step process for paying for something. I answered it once telling how to do it and then again to say never to do that. You should not have your front-end be the conductor and the back-end be the orchestra. If you do, you will be sorry because eventually someone will lose their web connection, close their laptop, or just shut down their browser in the middle of your carefully choreographed sequence. Instead, always try to make API calls from front to back that provide complete units of work, complete transactions with all the information needed for multi-step operations so you won’t end up with only part of an operation completing.
  4. Please, please, please, please don’t do things that break basic conventions in your apps. There’s no reason the user shouldn’t be able to hit the back button or the forward button. It requires very little thought to support (especially if you use modern JavaScript frameworks). Ditto bookmarks and multiple tabs. There shouldn’t be any reason I can’t copy a URL and send it to somebody else or make a bookmark of my location so I can get back to the same spot. Nevertheless, I’ve worked on so many apps over the years where these basic operations acted weird or wouldn’t work at all. Don’t be one of those apps.
  5. Spend some time thinking about what happens when the user sits on a page so long his/her session expires on the server. If you’re following suggestion two above then you can send back a standard error in your JSend and catch it in your JavaScript code. Then just prompt the user to login without ever leaving the page. Likewise, think about what happens when the user clicks on a bookmark in the browser or an email and goes to the site but is not yet logged in.
  6. Please, don’t be afraid to reject some ancient browsers. There’s good code out there to help you do it and make it look nice, but ultimately you’re doing yourself, your users, and everybody else a service if you refuse service for IE 6/7/8 and maybe more than that depending upon your needs.