Why Rewrite InsertBackendHere to Node?
Why Rewrite InsertBackendHere to Node?
The argument for Node is made to the Java community.
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
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 and 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
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.
- front-end role
- back-end 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/offshore, 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 two weeks to deploy to QA.
Heck with that mess - orchestration layers for the win.
Finally, although not Erlang, Node is awesome at Web Sockets. Given our ability to only use one core, we can write async code VERY easily (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-long-term 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 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
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.
Published at DZone with permission of Jesse Warden , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.