better software through user-centered design

Posts tagged ‘javascript’

Yeoman with Express API Server


After playing around with Yeoman the other day I was pretty darn impressed. Ease of use and efficiency in web tools often forces the sacrifice of customizability and full control Yeoman offers all of the above. Once I realized how powerful it was and how cool liverefresh and watch works from the generated app, I wondered if I could use it to fire up my Express Node API server as well. It turns out, you can…

When a default app is generated using the standard method (yo webapp), Yeoman generates a Grunt file and sets up a working app that can be generated and running in seconds. It it not the typical Hello World where the first thing you do is tear out the crappy generated code because you have a better way. You simply generate and start building out your app…personal or enterprise level!

Once the app is generated the default Gruntfile.js uses connect to host the index.html and static resources. Express uses Connect under the covers but I wanted the routing and middleware goodness Express provides. It took some doing, but basically I use grunt to build and fire up my website, as well as startup up my Express API application at the same time.  Since Grunt is so flexible, allowing you to configure each task independently, locally it fires them up together, but in production grunt will do nothing with the API application as it will live on multiple servers behind a load balancer.

Here is my Gruntfile.js contents. Note that this is the default generated grunt file that I simple swapped internal connect usage for external Express app:

Next order of business is setting up Express to be an API only application that exports in such a way Grunt can use it:

You may call this file app.js but in my specific instance I am using app.js to start Grunt up within Webstorm.

Note that I used Yeoman 1.0 to generate the application.


So there you are, in under 5 minutes you could have a fully usable and ready for development frontend and backend api platform. Let me know what you think or any issues you see with what I found.


To Plugin or Function…That is the Question

I have often wondered what all the advantages of writing a jQuery plugin are instead of simply writing a function to do a custom action inside an application. I see lots of examples of drop down menus, and global behavior overrides which you would use in many applications, but not a lot for custom functionality. After re-factoring some code in a project our team wrote last fall, it became more clear.

In our project, we have a function that posts AJAX calls to WCF services, processes the result (JSON), and uses jTemplates to process the data into html templates. After this magic happens, it takes the JSON result set, and any other parameters you need, and processes a callback. A minor annoyance with this is that our function takes many optional parameters, so if writing inline, it can be WAY to easy to miss some, let alone remember if the optional params require “”, or {} to pass in. Here is an example of what the function looked like previously:

function processTemplate(serviceUrl, serviceData, divToProcessTo, templateFile, callbackFunction, callbackParamters){


ajax call here…


if (callbackFunction)

callback(callbackFunction, callbackParameters);

You can see how calling this could be an issue: processTemplate("MyService.svc", {myData:data}, "#myDiv", "templateFile.html", "", {});
Was the optional ones “” or {}…hhmmm…lets try one, save the file, refresh the page, and try it. If it errors, I’m sure one of them was wrong. You can see how a simple function call could potentially burn 15 minutes of time, instead of 3.5 minutes including testing.

Enter Our Hero (AKA The Silver Bullet, AKA jQuery)
After noticing that we call this function ALL over the place, and rarely do we fill in all the parameters, Oh yeah, new requirements necessitate a payload be passed to nearly every service as a separate parameter from what is currently being passed. Looks like we will have to go through every call to processTemplate requiring the new payload and add yet another optional parameter when required…or do we..MWA HA HA (evil snicker). I begin to think about all the jQuery plugins we use that take 12 parameters, but only 2 are required. That sounds right up our alley!

$.fn.processTemplate = function(options){
var defaults = {
serviceUrl: "Services.svc",
serviceData: {},
templateFile: "defaulTemplate.html,
callbackFunction: null,
callbackParamters: null,
extraPayloadName: null,
extraPayloadData: null
options = $.extend(defaults, options);
return this.each(function(options){
do stuff here...

Sweet! We now have a jQuery plugin that did exactly what we were doing before. All that has really changed is how we call it:

$(“#myDiv”).processTemplate(); or
serviceUrl: “Service2.svc”,
serviceData: {myParam: “1234”},
templateFile: “service2Template.html”

Not having to fill in every parameter seems like some sort of sneaky that is freeing and makes us feel “oh so powerful”.

But Wait! There is more!
Someone said something about an additional data something or other for the service??? I am WAY to lazy to go through every function call and add that in, nor can I afford a 12 bananas an hour that snide chimp charges to run cut and paste….the solution (another plugin):

$.fn.processTemplateAutoData = function(options){
var customOptions = {
extraPayloadName: "CustomPayload",
extraPayloadData: globalVarPreviouslyCreated
options = $.extend(customOptions, options);
return $(this).processTemplate(options);

Ok, ok, so we had to change all the calls anyway…what gives? Well what can I say, it was worth it. I got rid of all the calls with “” and {} in the parameter list and I hate that. Now next time we need additional data or some other global change to the call…perhaps 5 or 6 more optional but necessary parameters, it will be FAR less time consuming and I love that. 🙂 It is also much easier to hook into our functions and create API’s for them to customize our needs, without having to write more functions, AND to make our plugins transferable from project to project.
I am not saying this is the best way, just a better way. Perhaps at the conference this month I will learn some new Kung Foo that will make it even easier to clean this up.

%d bloggers like this: