Why Rewrite InsertBackendHere to Node?

There are always fads, but sometimes the fads have reasons they are fads. Question from a reader:

“I’m fine re-architecting our various software applications used internally using Backbone/Angular for the front-end. However, why would I use Node for the back-end when my Spring MVC SOAP Java business layer works just fine?”

First, Backend for Frontend

It’s hard for Java Developers to get “why” if they are the same ones doing the front-end an the API for it. People like me (who are rare) and grew up on the front-end love this stuff. Case in point Sam Newman’s lovely “Backend for Frontend” article which summarizes a few of our challenges that Node (or Ruby… or Python… just easier with Node) solves.

Given a variety of devices, OR just different designs need different data, it’s easier to tweak in the back-end once, and have the client get it vs. munging things around all over the place on the client.

Second, Language Reuse

It’s easier for the team if they already know JavaScript to code the same language in both places vs. “Here, use Sublime for here, but Eclipse + JDK 7 for there… and Gulp + Node for here, but Maven for there… Gulpfile.js for here, but pom.xml & friends all over there…”. Same goes for the libraries & API; most are the same.

You get into this weird zone when talking about TypeScript. Many a Java dev has been fine with Java on the back, Flex/ActionScript 3 on the front. Years later, Java on the back, TypeScript + Angular on the front. That’s also ok… but again, the languages are still different. A good Java dev or team can leverage the strengths of both.

If you have a “JavaScript Developer” open role however, you can now put into a:

  • front end role
  • backend role
  • devops role (manage Gulp/Docker/Jenkins)
  • testing role (use Selenium)
  • fullstack role via the MEAN stack or its ilk

That’s insanely flexible, price conscious for on/near/off shore, and staff scalable hence why language reuse is a huge deal because of the tools + roles that surround it.

Third, Scalability in Node is easier for Some Use Cases

… sort of. If you’re doing String parsing, Node does that well. However, for enterprise applications, no one argues the JVM is the shiz, hence Scala & Clojure. The point here, though, is most front-ends nowadays send JSON back and forth and munge it. All the work around that is just easier in Node. Parsing XML, JSON, etc. That’s what most REST API’s do.

The low-level work like Database access, security around SQL/NoSQL injection, etc. is all Java’s and the JVM realm for a lot of Enterprise clients. That’s why a lot of time you have people like me building my own REST API’s for my Angular application hitting Java back-ends. It’s just the norm most of our LLP clients have, many are legacy, a lot new, but both are heavily vested in Java. That’s fine, but it takes me 5 seconds to write an Express GET url to give me exactly what I need vs. begging some Java dev team already overwhelmed to get a node name changed that takes 2 weeks to deploy to QA.

Heck with that mess, orchestration layers for the win.

Finally, although not Erlang, Node’s awesome at Web Sockets. Given our ability to only use 1 core, we can write async code VERY easy (much like C# and Scala). Unlike them, ours doesn’t do parallel processing, but rather, tends to never “lock” the CPU since it’s just a pointer on the stack… unless you do gigantor for loops without using generator functions. Once you start forking processes, it makes it easier for non-longterm server guys (read Jesse Warden with the Associates in Art Degree) to scale back-end systems to the enterprise levels. Things like Redis make it uber easy to expedite fast REST API’s even when the legacy backend is slow. It also has pubsub to allow the cores to talk to each other behind load balancers.

… and again, sockets are just string parsing. Nowadays, you want to real-time data changes vs. stale front-end data (i.e. Meteor), and Node is often the one handling the sockets where Java handles the heavy REST data lifting.

I don’t know multithreading. I know how to easily scale Node to multiple cores with a simple pubsub using Redis to communicate and do basic clustering. That’s huge compared to what you need to know in multithreading to pull that off.

Fourth, Efficient Data

SOAP is garbage. It’s bloated, no one uses the strong typing on the client, and contracts are never enforceable, especially nowadays with microservices. JSON won the war. Flash & Flex developers knew that a decade ago.

Fifth, Spring vs. Spring Boot

Yes, Spring is old and not based on industry trends. Don’t re-write it, just update it. If you ain’t going full-reactive nor Scala/Go/Node, etc, heck yeah, Spring Boot FTW.

Sixth, Microservices

Some things Erlang does well. Some things Scala does well. Node & Java the same. With containers taking over the world, “if it ain’t broke, don’t fix it”. Some people don’t really care and choose a language/platform for other reasons years ago. That doesn’t mean you shouldn’t containerize it. If your back-end does in fact work, you have talent there to work on it, then just allow stuff that grows around it to just add to the microservice ecosystem you have. If another team wants to use [Node or New Framework], fine, have their microservice call your Java microservice. Hotness. Scalable.