Why I like a NodeJS web application on Azure using SQL as a backend

I’ve been doing a lot of studying lately on which technology is best for my new project, and with the abundance of frameworks life doesn’t get any easier. I have a number of requirements which most of us have when creating a new web applications:

– A framework that is easy to use and well supported (in terms of modules, libraries, … whatever makes us not invent the wheel twice)
– Must run in the cloud
– Must run for free in the cloud while I’m developing the thing. I only want to pay as soon as people pay me
– Must be able to develop code easy on any machine

After all my research, I think I found my ideal combination: it is a NodeJS application that delivers a REST API and accompanying AngularJS client pages in combination with SQL on the backend. A number of people reading this will put question marks with this choice of technology, but, there is a good reason why this combination makes sense.

Why NodeJS?

I like NodeJS for two reasons, which are not accidentally on my requirements list:

– It’s javascript, and doesn’t require a compile step while developing. Hence, it is easy to develop NodeJS applications on any system. Macbook, not a problem. Pc at home, with windows 8.1. No problem. Editors in abundance, see my previous article on Visual Studio Code fore example, but for Windows there is also Visual Studio Community edition, one of the better Javascript editors available today.
– There is an extensive list of free modules available via NPM, and up until today, I haven’t found one problem I couldn’t tackle with a module that is freely available. Is seems me from reinventing the wheel, just make up the glue to deliver a nice service

Note: I like C# code as well, don’t get me wrong, and I’ve written web applications in MVC as well. I just like the fact that NodeJS has no compiler requirement, which makes it very easy to develop.

Why Azure?

Most of the people I meet associate Azure development with ASP.NET websites (with our without MVC). That is one option, but NodeJS applications are equally good supported, and, web applications are for free on Azure! You can say about MS what you want, but Azure is a nice piece of work, and the fact you can easily run NodeJS applications on a free of charge web tier is fantastic. Deployment via Git is included and super easy, so what else do you need? I think most people don’t know these options, and often turn to Amazon and OpenShift for these kind of things, as they are more commonly associated with NodeJS.

Though not really applicable for a simple website, but, there is also an Azure module for NodeJS available to manage your Azure objects, so don’t underestimate what NodeJS and Azure have to offer.

Why SQL?

If you see NodeJS, you always see MongoDB or another NoSQL backend. I like MongoDB and NoSQL for what they are made, but, my data is simple and relational, so why should I go for a NoSQL DB? It would just end up in objects referring to each other like a relational schema, I would use Mongoose to enforce all the constraints…. so at the end of the day, SQL does the job here better than NoSQL. I don’t believe following a trend or hype is a good thing if it just for the sake of the trend. If you can get profit out of it, do it, else, stick to what you have and works.

NodeJS has no issue with SQL, for those who are in doubt. There is a great library called Sequelize (check npm repository) that makes it really easy to work with traditional SQL databases.

A limited MySQL DB is also available for free on Azure, so that’s good for kicking off my development. When the app grows, it might not be sufficient anymore, but the customers should pay for the growing storage cost, so no worries about that.

Note: it thought it was possible to get a limited free MS SQL instance for development, but, this seems not to be available anymore. However, the Sequelize component should hide most of the backend for us thus this should be doable.

Note: it is possible to get a MongoDB instance as well on Azure, thought I’m not sure whether that is for free to start with (up until a number of MB’s). If you would need a MongoDB in the cloud, you can always turn to MongoLabs for a free MongoDB instance in the cloud (to start with). I takes only 5 minutes to register and have it working.

Conclusion

For these reasons, this combination is my ideal environment. It might be yours as well for the same or even slightly other reasons. It’s not a trendy combination, but I believe it is a solid one, and that is what counts at the end of the day.

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.