If you didn’t know, CORS - or Cross-Origin Resource Sharing - is a W3C specification for allowing a page loaded from one domain to access resources on a different domain via XMLHttpRequest calls. This is important for a number of reasons, but the main one for me right now is because it means that you can split your application into multiple smaller services - microservices - that are hosted on different subdomains and still access them all from your Javascript.
For a long time, one of the big problems I’ve had with NodeJS is that of Unit Testing. Specifically with the fact that, by definition, a Unit Test is testing a single unit in complete isolation of the rest of the world. In Node terms, a Unit would be a single Module.
I try to be a bit of a stickler when it comes to testing of my code. As such, I always like to make sure that I have support for Unit Testing in my projects from the very start, knowing full well that if not then the test quality just won’t be as good and the project will suffer as a result.
Testing of a project comes in various different flavours, of various different levels of importance.
In the previous post, I set up a new NPM project to work with, and added in Grunt as a task runner so that we can do complex tasks if we want to. Next is setting it up to build ES6 code into ES5 via Babel, so that we get to use the newer features - Classes, Arrow Functions, Destructuring, Let/Const, and so on - whilst running on a runtime that doesn’t yet support them - because no runtime yet supports ES6 fully.
Babel is a Transpiler that we can use to automatically convert ES6 code into ES5 code for exactly this purpose. It literally takes existing ES6 source code as input, and converts it into ES5 source code as output - in the same way that a compiler would covert source code into machine code.
If we so desired, we could use the exact same setup for working with CoffeeScript, Dart, TypeScript, or any of a growing set of languages that we can convert into Javascript.
Whenever I start a new project using NodeJS, there are several things that I always do first. I thought that I’d finally get around to writing up what these things are, so that I can reference it myself, and in case anyone else might be interested. This covers part one of this writeup, setting up a base Node project, and adding Grunt in to it so that we can use Grunt as a task runner for more complicated builds. Next post will cover setting up the build so that we can write our code in ES6 instead, and later we will look at setting up some static analysis to keep code quality highter.
MongoDB has a lot of good things about it, and equally a lot of bad things about it. This is true of most database engines though, and you need to know what you’re looking at to be able to make a good call over which system to use for what you’re doing.
Optimistic locking is traditionally quite difficult to achieve. You need to ensure that the version in the database matches the version in the update request, and fail if that’s not the case. There are a few ways of achieving this, but often with risks and race conditions involved.
Assuming you’ve got a Maven Build, and you’ve got a correctly configured Site for your build, and then further assuming that you are using the Travis CI system for your Continuous Integration (It’s free, so why not), one potential next step is to automatically deploy your Maven Site somewhere.
I like the idea behind using Node.js for webapp development. I really do. The idea of using a consistent language between both client and server, which therefore means that you are able to share code between the two without replication. Who wouldn’t like that?
The latest version of the ECMAScript Language - ES6 - introduces a lot of new features. One of the most interesting of these is the introduction of a module system that is built into the language. The way this works is, unfortunately, very different to how any of the pre-existing ES5 module systems work.
Wait, what? Most of the time when people discuss the new ES6 module system it is talked about as being one of the brand new features of ES6, and not an existing feature that has been fit into the language - such as Promises. However, there are already a number of module systems that are used and very well supported in ES5. The fact that there are different module systems, and that they aren’t trivially compatible, is a big problem. There are ways of making the three major module systems work together, but it’s not great to have to do that just to work around this fact. As such, the fact that there is a language-level module system in ES6 is a good step forwards. It’s just that the new module system isn’t a perfect solution.
I’ve just recently been working on getting my Hexo blog set up, and importantly on getting it automatically deploy to Github Pages every time I do a commit. Given that this is a generated site, there are intermediate steps involved between the source that is committed and the site that is deployed.
The obvious way to achieve the actual Build part of this is to use the fantastic Travis CI, which can be set up to perform a build every time you do a commit to a Github Repository. The challenge involved in this is getting Travis to be able to push the deployed site back to Github for it to be accessed. However, it turns out that Github have a solution that can work for this as well.
From this point on, I’m going to assume that you’ve already got Hexo configured as you want it, and you know how to configure Travis to build a Github repository correctly.