Create REST based applications using SailsJS, Waterlock, AngularJS, Restangular and Material, An introduction

I’ve done reasonable research on different web stacks and combinations of stacks to find out what would be the most useful for me. I ended up using the SWARM stack, which, as far as I know, is a term nobody uses (yet), but is short for Sails + Waterlock + Angular  + Restangular + Material. In all follow up articles I will show more code on the different topics, but below you can find the complete “why” I choose these technologies.

First of all, useful for me can be different than it is for somebody else, but here are my criteria for “useful”:

  • As platform independent as possible, for both development and running the application in production.
  • Front and back separated by a REST interface. You never know whether you will have to make another front-end one day (e.g. an app for iOS or Android), and REST keeps these options open
  • Front and back should work with a well documented, easy to understand framework so I can add functionality very fast without worrying about the technical details, nor the implementation of too much GUI
  • I don’t want to worry about the DB that is used… because I’m not sure on that part yet
  • Open source, preferably MIT License or alike, and well supported by the community. I don’t want to end up with a component somebody wrote “half” or abandoned long time ago.

For the first item on the list, I’m convinced NodeJS is an ideal candidate for the back-end, since it avoids the need of a compiler, heave duty webserver and alike… it’s pretty straightforward, runs on Windows boxes, Macbook,… just have to share the files. Also, all reasonable cloud providers are able to run this, so we’re safe with this choice.

Continuing on the backend, writing a REST application from scratch in NodeJS is still a reasonable amount of work, and reinventing the wheel has helped no one ever, so a web stack that enables this would come in handy. I started with the Express stack, which is pretty basic but already nice to work with, it still required me to do a lot of work. I looked at Loopback framework, where there is a pretty Arc frontend, but this isn’t completely open source (as in free), and for one reason or another I couldn’t find my way in it, so I didn’t stick to it. After checking out a few alternatives (Koa, Hapi, …), I stumbled upon SailsJS, and I’m a fan ever since! Though SailsJS is actually an MVC framework, it creates a REST API by default for all the model/controllers, and you do not need to use the views at all, but can still profit from all the other goodies it offers: policies, nice structure, clear config files,… all very simple to learn. Equally great and a fantastic advantage is the use of the Waterline ORM, which doesn’t force you in the SQL or NoSQL corner, but supports both of them, and even combinations. In development, it works in local files, so you can postpone  your choice if you’re not sure yet, but still develop. For a REST backend, I could not find any better solution that leaves me with so many options, and is so easy to learn.

Note: Waterline ORM can also be used outside of the SailsJS framework, and I would advise it in any way since it make DB development really easy and relieves developers from the actually database dependent stuff.

One item left for the back-end was user authentication, since SailsJS doesn’t provide this out-of-the-box (for good reasons). If your requirements are front and back-end separated by a REST interface to support other apps in the future, you must be consistent and the only way to go is web tokens. Cookies are not done (anymore, for authentication), and session authentication will bring you into trouble if you ever want to scale up, or work with apps that do not support this. SailsJS is based on express and all express modules are reusable, so by default people tend to move to Passport for this task. Truth be told, I’m not a fan of Passport… just couldn’t find my way in it (as you might have noticed, I rely on “feelings” for my selection of components, so this is pretty subjective I guess). As an alternative I found Waterlock, which is specifically designed for JWT authentication on Sails, and it does the job just fine!

So with the back-end covered, time to go to the front-end. I’m a fan of AngularJS since the day I met it, and if I see the community around it, I’m not the only one. It has a clean (MVC) structure that makes it really easy to make single page applications, and though “single page application” was not really one of my requirements, it makes life simpler. With AngularJS however, I have two issues:

  • Absence of nice HTML controls. The nice controls are not provided, since it is no concern of an MVC framework, but, nobody wants the default HTML controls today
  • Calling REST functions is not easy enough, even if there is something like ngResource available

On the HTML controls part, I started with bootstrap, and even though it is nice to work with, it sometimes doesn’t fit into the AngularJS modus operandi. There is an Angular Bootstrap component, but this wasn’t satisfying either. After that, I encountered Angular Material library:

The Angular Material project is an implementation of Material Design in Angular.js. This project provides a set of reusable, well-tested, and accessible UI components based on the Material Design system….  Material Design is a specification for a unified system of visual, motion, and interaction design that adapts across different devices and different screen sizes.

Nothing more to say on that one. Library works great and delivers nice controls. So only part left is call the REST API from within AngularJS. After looking at some generators and alike, I came across Restangular:

AngularJS service to handle Rest API Restful Resources properly and easily

Restangular really delivers what it promises, works nice in AngularJS and calls SailsJS API without any problems, has a good documentation and is well supported.

And with that all in place, I had my full stack ready that meets all my initial requirements for developing web applications. Note that an extra consequence is that all of the pieces in this architecture are written in Javascript, so there is only one language used. Though it isn’t an explicit requirement for me, it could be of interest for some development teams

Advertisements

Running Redis on Docker on Windows

When it comes down to OS’es, I’m not the monogamous kind of guy. I like things that work on Windows, Linux, and Mac, preferably without a lot of troubles (actually, preferably without any troubles, but, I’m a realistic type of guy as well). As such, I was interested to see the power of Redis, but dissapointed it doesn’t really run “out of the box” on Windows. Ok, there is a port avialable, but that’s not always the real thing. So I decided to kill two birds with one stone, and bring in another technology that is still on my bucket list: Docker.

Docker is a software container technology and has some nice advantages for both developers and IT admins, and after 15 minutes it turns out to run real smooth on my Windows machine as well. More information can be found on the Docker site installation documentation. Another nice and very to the point intro can be found here. Note that running Docker on Windows really involves quite some technology, but the installer really hides that nicely. Once docker is running, make sure you know the IP address of the VM host it is running on so you can connect later. It is logged in the console, but will not be visible anymore after running the redis command.

Phase 1 completed, and for those who like open source technology combined with really fast, no nonsense installation and the usual struggles, I really advise Docker and their public repositories. Installing Redis on Docker is a single line command:

docker run -p 6379:6379 redis

If all goes as planned, after the download, your Docker window should look like the below image.

Truth to be told, I did have some issues during installation, where it had an unexpected EOF and the untar command failed. This seem to be common and according to different sources is caused by the “network” and more specifically the “Wifi”. I don’t know the details, but disabling Wifi and continue on the wire solved the issue.

rediscmd

And that is actually all! Redis is running on your machine, ready to use, which means in my case to be used from within NodeJS. Tons of information are available on how to do this, so I will simply show my sample test code I quickly wrote in the Visual Studio Code editor, and this for four reasons:

  • I’m fond of the editor, which I expressed in my previous post
  • You can really easily debug your server side code
  • I really like intellisense that can be added via definitelytyped.org, it is available for most common node modules and thus also for redis package, and can be simply added by adding the references on top of the file
  • Be warned when connecting to the Redis server. First of all, because this is actually running in a VM with a virtual network on your machine, and thus you need to connect using an IP address as the default localhost will not work. Second, you will use hostname/IP address and port combination, and Redis client takes the port number first. It could be me, but in all languages where I connected to a server, host name is first and then port number comes second. Of course the documentation is correct, but it was that trivial for me that it took me a while to notice and I spend to much time wondering why I was always getting these connecting errors.

rediscode

And here it is, a full functioning system with Redis running in Docker on Windows and connecting via NodeJS app written in VSCode.

 

 

Visual Studio Code for writing and debugging NodeJS applications

I’ve always been a fan of Visual Studio. I started using it when it was still version 6 (when my professional life started) and the only reasonable language was C++. Even though I worked on many different platforms in the meantime, none of the tools I encountered ever came close to Visual Studio. You can hate MS as much as you want (which I do not) but you have got to love their development environment.

Last couple of months I really got into the NodeJS world, which I think is a really great environment: you can develop on any platform, and it runs on all of the platforms, cloud or on premise, everybody supports it. You cannot get any “vendor lock-in”, which is great and you have all options open. You want to move to Azure? Fine, no problem. Amazon. Equally ok. Run locally on your Macbook. Done. An extra advantage is the simple type and run principle (which is a well known principle I just invented), which means there is no compilation or building required before running the application.

If you read this intro, you will understand that I was very pleased with the announcement of Visual Studio Code, which fits perfectly in my scheme of things. Of course there is Sublime which everybody is using for this kind of task (just as me), and truth to be told, some of the VSCode features are simply copies, but it works equally good for me, and has suprised me. Biggest reason why it pleases me: it’s simple. As powerfull as Sublime is, I only used 2% of it’s features for developing node applications, so it was too much. VSCode is simple, offering everything I needed, and even more, using the docs on https://code.visualstudio.com/Docs/ I was able to create a “blanco nodejs template application” and configure debugging in under 5 minutes. Combine this with the great support for client side javascript debugging we have today in allmost all browsers, and you have full support for debugging on client and server!

vscode debugging

 

Another great feature is the support for type definitions in combination with the intellisense. All info is in the docs, just mentioning it here because it actually really works, even tough I’m not the biggest fan of Typescript (I don’t like any “extra” steps for converting or compiling things… remember the type and run principle), I don’t even use it my apps. It just great to have intellisense support for the basics of a language.

vscode2

Next job is to experiment with the task features VSCode offers, which also seems to solve some issues for me… but I need a little more time for that one.

Two remarks to close this article:

– It could well be that Sublime is equally capable of doing all of this, I don’t know. And that is exactly my point. In all the power of Sublime I couldn’t easily find these things, while with VSCode I got things running in no time with a very to the point document

– There are still some improvements to be done on VSCode, especially the part on HTML tags feels sometimes wrong. For example, in any modern HTML editor typing <br> will convert your tag to <br />, while VSCode will just complete the tag, so you end up with <br></br> which of course nobody wants. Same goes for a lot of other tags. Also starting a closing tag does not automatically bring up intellisense to suggest the rest of the tag. These features are available in Visual Studio 201x, so they know how to do it…