FullStackatnearForm cubeWe get asked a lot these days – by peers, partners, prospective clients and prospective hires – what our development stack is. This post is an attempt to answer that question in detail.

First off, be aware that every project is different (as is every client!) so it’s hard to generalize. However, we are definitely leaning towards a common set of tools and technologies that we use in most projects.

What does full stack mean at nearForm? It’s a project approach that involves both front end and back end development, ranging from HTML5/CSS on the front end to API, business logic, data and DevOps on the back end. It may even involve a robot controlled by JavaScript, but that’s not a given! Usually, our projects (regardless of size and number of people) are full stack by nature. Many are front end-heavy, some are back end-heavy, some are purely DevOps, some are purely microservices, and some may be performance related. However, by and large, the thing that makes them full stack is JavaScript, used at every layer of the stack. FullStackatnearForm human figure

So, generally, as of February 2016, what does our tech stack actually look like?

Front end

What a difference a year makes! This time last year, we used Angular almost exclusively. However, in the past nine months or so, React has totally disrupted our front end development. When React was released, we got it in theory (sort of!), and in theory it sounded great. But we were reluctant to move at first. There was a big learning curve with React; we had a “it’s just the view layer” attitude; we were reasonably comfortable with Angular; we didn’t really see the reason to move; and we were fatigued by the front end JavaScript framework wars.

So what happened?


Nothing happened overnight. First, it was our internal early adopters who moved to React and evangelized it within the company. These pioneers used it first in pet projects, then in small projects, and then convinced us normal developers to use it in our big projects. It also bled in from some of our partners and clients (we work with very smart people!) who were also being converted to the React way. Finally, we were also influenced by the huge React movement in general, as exemplified in posts like this.

Big picture-wise, what’s really interesting about React is that we are starting to see some of the best practices that we’ve been using in back end Node.js development for several years now being applied on the front end. Of particular interest – in the same way that microservices give you a sane way of moving away from a monolithic back end – is the fact that with React, you now no longer have to build a monolithic front end either. (Of course, it has always been technically possible not to build monolithic front ends in the past, but it’s incredibly difficult not to end up with a big ball of mud every single time!)

So what’s so good about React? Let’s stick with the high level reasons:

  • First: it’s JavaScript!! It has proper front end components that can be published and versioned in npm like any other Node module. One of the biggest challenges of creating front end components has been state; more specifically, using state from other components. React combined with the Flux pattern (we use Redux – RIP MVC!) gives you a sane pattern for doing this, and one that doesn’t involve listener hell.
  • Second: it’s finally possible to reuse components well between projects. All you need to do is provide good documentation and stick with semver for breaking changes in your component, just like any other Node module. We find the levels of reuse to be quite interesting, from dumb, single-purpose components right up to full standalone apps. For example, it’s quite common to develop an ‘admin’ section of your overall web app as a totally standalone application (for example, WordPress does this).
  • Third: React has universal rendering, which gives us the best of both worlds: a fast-loading, single-page app that is also SEO-friendly.
  • Fourth: with React, we are finding it much easier to scale front end development. It’s possible to split UI work into teams with their own code bases, development cycles and deployments while still remaining coordinated with the overall project goals. This is very much like you get with microservices on the back end; that is, domain-driven design with a front end focus. Our experience of doing this is worthy of its own blog post, one we hope to post in the coming weeks.

Just to note that at nearForm, we are building HTML mobile apps with React as well as web apps, and having similar successful experiences. What’s really exciting is that this is still early days. Best practices are still emerging; React hasn’t hit 1.0 yet. We have yet to try React Native for native mobile apps – it sounds awesome, however.

Sure, there will be a lot of ‘React vs Angular 2′ posts in the coming months. Don’t get distracted by the volume of posts; React and Angular 2 differ hugely (a classic framework versus multiple libraries battle). The choice is quite succinct: you either want to write logic in your HTML (Angular) or you want to write HTML in your logic (React).

Back end

Thankfully, the back end of the stack is not as volatile. For us, back end development is largely a solved problem. We’ve been using the following tools to successfully deliver project after project at speed:

  • API: we use hapi. Yes, we’re biased, but in short, it’s solid, it’s actively developed, it has a great community, it’s easy to develop, and it’s proven in large enterprises. We also use the Node ‘http’ module directly when speed is a top requirement.
  • Microservices: for projects where microservice patterns are applicable, we use Seneca.js. Again, we’re biased here. :-) nearForm people have been thought leaders in microservices for several years, since before the term was even coined. We do a lot of work today involving high-level consultancy around microservices, including best practices, architecture and systems integration. It’s really exciting now to see microservices disrupting enterprise development across all verticals.
  • Database: in general, we pick the right tool for the job. In many cases, we don’t have a choice (when we have to talk to an existing enterprise database, for example), but we are big fans of PostgreSQL for greenfield projects. PostgreSQL has no licensing costs, and it’s reliable, stable, well proven, and easy to use. We also feel that, with its recent JSON support, there is no real reason to choose a NoSQL database in most cases (but again, all projects are different!). Module-wise, we use Postgrator for migrations, and more recently, Massive.js for everything else.
  • Testing: we mainly use Lab. Lab is part of the hapi ecosystem but totally independent of hapi itself. Client-side, karma/mocha still dominates.
  • Monitoring and analytics: we do this very much on a case-by-case basis. Some clients use NewRelic or AppDynamics; some want integration with their existing monitoring tools (such as Nagios or Zabbix); some are using statsd/graphite-type solutions. We also have much lighter Node-specific solutions ourselves, which we are planning to open source in the coming months.
  • Enterprise integration: again, this is case-by-case. In the best-case scenario, it’s a SOAP server. In the worst case, well… Seriously though, thanks to the richness of the npm ecosystem (235 K packages at the time of writing!), it is very rare to find something that we cannot talk to at some level.

Internet of things

Photo: Nico Kaiser

IoT-enabled cocktail robots in action at NodeConf EU 2015

Even though it is not part of nearForm’s core business (!), we built eight cocktail robots for our last nodeconf.eu. Powered by Node and a bunch of Raspberry Pi 2s, we controlled everything through MQTT.js. We are also good friends with the Tessel project, and we are looking for more craziness in the next few months. Stay tuned for more updates!


‘DevOps’ is a bit of an overloaded term with no official meaning. It’s usually taken to mean an organizational culture change. However, at a practical, technical level, when most people talk about DevOps what they are really talking about is continuous delivery. There is a continuous delivery aspect to all the projects we work on, and how you do continuous delivery is largely tied to your infrastructure. Infrastructure-wise, we do a lot of work on AWS;  almost all of our partners and clients use it (and even those that have their own data centers use AWS in parts). Yes, you can remain somewhat infrastructure-independent if your project really requires it, but it’s a conscious investment. For sheer convenience, flexibility, cost and speed of delivery, using AWS directly is hard to beat.

AWS is fast becoming the operating system of the cloud. People often ask what is the best book for learning AWS. There isn’t one. The only way to learn is by doing, and by following the best practices for the services that you are using. It’s also quite hard to stay on top of all the service offerings AWS provides, as it really changes fast. The services we find ourselves commonly using across most projects are IAM, VPC, EC2, S3, RDS, CloudWatch and CodeDeploy. That is not to say we don’t use anything else; we use other services as projects demand, and we are really excited about Lambda (‘nanoservices’, anyone?).

We also get asked a lot about deployment. It is an important part of delivery, after all! Again, it’s what best suits the project, but on AWS it’s usually either CodeDeploy (which we love, but it is very AWS-specific) or Docker-based deploys (which we also love, but again like everything else, not in every case). Occasionally, even the AWS Elastic Beanstalk is appropriate (PAAS does have its place). For on-premises deploys, the deployment solutions are a bit more ad-hoc, but it’s generally done via bash scripts or, increasingly, Docker.

We have various levels of AWS expertise in-house. All our architects can help set up continuous deployment on AWS, and we have dedicated AWS specialists to call on for the tricky stuff. In terms of tools, we have had a lot of success with Terraform lately. We have also used CloudFormation and home-grown Node/AWS-based scripts with great success on several projects.

We have had little exposure to other IAAS providers or PAAS solutions, but we are more than open to any opportunity to compare these with AWS.

What’s next

I should also mention that we use fuge for local development. Fuge really helps developers to get up and running quickly with a project by running all the various parts of the project in a single place.

For example, one of the biggest problems that new React developers have is figuring out where to start. There are numerous starter kits out there, often with conflicting approaches and tools. (For the record, we have found the React Redux Universal Hot Example to be one of best – thank you @erikras!) Internally, when we start a new React project, we typically take one of these boilerplates and customize it, both for the project at hand and for the React best practices that have evolved since the starter kit was written.

Over the next few months, we will publish our own hardened starter kits via fuge – not just for React, but right across all parts of the stack, all based on our experience of continuously delivering real-world projects. Exciting times – stay tuned to this blog!!


In terms of full stack, there has been a lot of fluctuation over the last few years. It seems like a long time since the term MEAN stack was even coined! However, things are settling down. The adoption of React on the front end reminds us of the buzz around Node.js in the early days and how quickly it was adopted. These days, Node is all grown up, and continues to be adopted en masse in the enterprise. Microservices are now also mainstream, as is DevOps.

So, we see 2016 as a period of stability and delivery. The stack as it is enables rapid digital transformation and it’s only going to improve from here. Sure, some small parts of the stack will be replaced with more fashionable parts, but by and large these foundations (React, Node.js, microservices and DevOps) are solid platforms on which to build your business.

For more information about any of the above, reach out to us! You can get in touch using the contact page on the nearForm website, or contact either me or the nearForm account on Twitter. We’d love to talk to you.

If you enjoyed this post, you might also like these recent articles from our blog:


By: Damian Beresford

Damian is a software architect here at nearForm, with an interest in all things Node.js, Docker, microservices, mobile and enterprise. Damian has over 20 years’ experience with all stages of software development, across many technologies and platforms. He is passionate about software development and how next generation mobile and cloud are transforming the enterprise.
  • http://www.hackerstribe.com/ Rocco Musolino

    What about the server? always using the bare http module or something else?

    • Damian Beresford

      Hi Rocco – read ‘server’ instead of ‘api’ here: ‘API: we use hapi. Yes, we’re biased, but in short, it’s solid, it’s actively developed, it has a great community, it’s easy to develop, and it’s proven in large enterprises. We also use the Node ‘http’ module directly when speed is a top requirement.’

  • timsim00

    Hi Damian, thank you for this great info. fuge is terrific. Would love to see your react boilerplate in fuge.