Node.js Examples – How Enterprises Use Node in 2016 | Hacker News Reader

Node.js Examples – How Enterprises Use Node in 2016

blog.risingstack.com

80 pointshfeeri50 comments

> Because of the way Node works we can attach debuggers, and set breakpoint steps through the code. If you wanted to debug these groovy scripts in the past, you would make some code changes upload it to the edge layer, run it, see if it breaks, make some more changes, upload it again, and so on

Can anyone expand on this? I haven't worked with Groovy, but most languages have debuggers that let you attach to an existing process. Is this something especially great about Node, or something especially horrible about Groovy?

I'm pretty sure Groovy has a debugger too.

I haven't used Groovy, but some quick googling suggests it might have issues with remote debugging.

Also, if that quote is related to the surrounding paragraphs, it sounds like the biggest upgrade isn't so much the node.js debugger, as it is the services being rewritten in a decoupled, non-monolithic way. So now devs can test with local copies of software, instead of requiring an entire infrastructure to be online just to test a single function.

The decoupling and microservice mindset aren't specific to node.js, you can achieve those benefits in any language, however it is more idiomatic in node than other stacks,

Yes, Groovy does have a debugger. It is just the Java debugger. I use it nearly every day to work on a Grails project. Also, yes, you can attach it to an existing process. As far as I can tell, that comment doesn't make any sense.

Apache Groovy (around v 1.0 or 1.5) used to produce bytecode that could easily be decompiled to Java code, but since version 1.6, the bytecode generated was changed so it couldn't be decompiled with the tool I was using at the time -- I forget what it was, could have been JAD. I know the JVM situation has changed a lot since then, but that breaking change was just one of those many little things that put people off using Groovy for anything more serious than quick'n'dirty scripting. I wouldn't imagine it would be easy to write a Groovy debugger if the bytecode generated is still so non-standard it can't be decompiled to Java source.

Why would you need a decompiler to write a debugger for Groovy? The groovy compiler supports including source code line numbers and variable names in compiled jar files (just like Java). As a result you can use any Java debugger to debug Groovy.

Also, why would you expect that Groovy can be compiled and then decompiled to Java? This doesn't even work 100% going from Java to Java, and Groovy is going to have idioms that doesn't map easily to Java idioms.

> The groovy compiler supports including source code line numbers and variable names in compiled jar files

I haven't used Groovy since v 1.8, and certainly didn't know about this facility then.

> why would you expect that Groovy can be compiled and then decompiled to Java?

It worked in Groovy 1.0, and the decompiles to Java were useful back then when Groovy often had unexpected behavior.

>"Instead of two teams, one is a pure back end, and one is a pure front end - consisting seven people overall - a ninja team of five can do both."

...said the manager.

I really don't like it when a framework is touted to be the be-all-and-end-all. The article tries to put this idea across. Node.js is nothing more than a tool, it is good at some things and bad at others. It is not the ultimate solution that "enterprise" developers can use for any problem.

It seems to attract the crowd who do tout it as a tool for everything, which in turn puts me off learning it.

I've been using Django for some years now and have taken an interest in Node.js. In spite of Django (IMO) being simpler to get up and running. Node.js is now everywhere and is making progress in the enterprise stack.

What I'd like to know (or make happen) is a Django equivalent in Node.js. Something with a built-in Admin, ORM, and (server side) templating system. Anything stable out there that fits my requirements?

Won't Django channels cover the same sort of tasks?

I've been doing small projects to get settled with channels and it works very nicely. The big difference with node and django is that Node is backed by bigger entities than Django/Python. I love Django, and use it for many things, but JS and node are winning a lot of ground.

How Node.js affected developer productivity at Netflix?

The developer productivity comes from breaking down the monolith into smaller, much more manageable pieces.

How is that directly related to nodejs only? I mean, you can have a monolith in one language and still break it down into smaller, more manageable pieces in the same language.

Marketing and mindshare. Node.js encouraged that architecture as the proper way to compose services, and you got async libraries for free. You could do the same thing in Java, but with frameworks and libraries that weren't as well-known before Node.js became popular.

I've been a Node.js developer for a couple years now and one thing I've noticed is I've never come across a company that actually uses it for their core api. There always seems to be a Java based (or another statically typed typically 'monolith' language) backend api server that smaller node.js microservices/apps communicate with.

We're considering switching parts of our Node codebase to TypeScript and I wonder if that will happen to a lot of these APIs you've seen.

As an anecdotal account, that's not surprising. If it takes, let's say, ten years to get good at something, then people who are good at server-side app-building are going to have roots in other technologies and other ways of thinking about the problem than what Node offers. The Node community is a wide but shallow ocean at this point.

As an opposing data point, at my previous employer we built the API with Node.js.

As someone who has been writing core APIs in Node.js for a few years now, one thing I really miss is a good ORM. The best one is probably Bookshelf.js but it's poorly maintained and lags behind more mature ORMs like Active Record in terms of features and stability.

Not to go too off-topic, but Sequelize is worth a look if you haven't played with it already.

I used Sequelize for a while before Bookshelf was released and haven't used it since so I'm not sure how it compares these days. One thing I like about Bookshelf is that the query builder (Knex.js) is fairly decoupled and it's not that scary to drop down to the SQL layer. I still feel it's not quite as good as it could be.

This might not be objective because I hate sequelize but sequelize sucks! I never understood its API. Is so clunky compared to Bookshelf.js.

Bookshelf is less opinionated on the way you integrate it with your web app with makes it good to work with if you have strong opinions on how it should integrate with your codebase.

I recently started playing around with Node for a friend's side project. I helped him set up the database and Sequelize was absolutely horrible to get up and running. The documentation was really lacking and we spent hours trying to track down little details needed to get things running. It does the job once you have it set up, but I found getting to that point was way more difficult that it should have been.

I used bookshelves a couple years ago and while it was very good on paper, I quickly ran into a lot of quirks and bugs for advanced usage.

There was an obvious lack of resources to develop it, and after contributing to it a bit I switched. Reliability is the #1 feature in an ORM in my opinion, and I didn't get that confidence from using bookshelves.

I later moved to sequelize, and it worked flawlessly from the get go, give it a try. You can compare the Github activity, you'll see it's thriving, and everything is much cleaner.

The performance is also way ahead, as last time I used it bookshelves relied on Backbone-esque models underneath, making it way slower for big nested queries.

Thanks. I actually started out with Sequelize before switching to Bookshelf.js but you convinced me to give it another go.

Noo, give it a go Bookshelf.js you will be more happy. Yes, maintenance lacks behind sometimes but the core is strong.

And if you do anything particularly hard you always can tap into knex and get all its powerful API and if that is not enough you run raw queries until the feature is officially supported.

If you're using RethinkDB, https://thinky.io works well. I use it for all my current projects.

You might want to check this https://github.com/Vincit/objection.js it is the only node ORM I don't hate yes even compared to sequelize I tried them all.

Writing asynchronous SQL queries is tedious indeed. SQL is very powerful though, and has it's use cases. But for real time applications, like multi-player servers, it doesn't really fit, so for those use-cases, I've made an ORM (1) that use proxies so data can be treated just like any JavaScript object, with synchronous in memory read/write and asynchronous HDD persistence via an SQL server.

1) https://github.com/Z3TA/dbo

Uber: https://medium.com/@nodejs/how-uber-uses-node-js-to-scale-th...

PayPal is a good example of a company that moved from Java to Node.js where the server listens to the client then have it slowly replace code going forward on the back end. [0]

There is a discussion that the bigger issue was getting management to allow them to rebuild all the code and by using Node over Java provided a mechanism to do this. This is touched on in the article.

[0] https://www.paypal-engineering.com/2013/11/22/node-js-at-pay...

We're a small company, about 150 folks, but our core api is node and we process 10-20bil external requests per month depending on season. Not exactly an enterprise and we have always been a NoSQL shop so YMMV.

That's how these transitions happen. They have a monolith which works and is "known good", and they slowly transition away from the monolith by wrapping it in microservices, till the microservices replace chunks of the monolith.

Eventually, hopefully, the monolith will be gone and there will only remain the microservices, but that could take some time.

People keep using this word "monolith"-- I don't think it means what you think it means(tm).

A crappy old system can be crappy because of the way it's written or the people writing it. If, as mentioned in one of the linked articles, it takes you six weeks to get a simple controller layer up and running in Java, something else is wrong, and it isn't the stack.

Node is pretty viral in the "enterprise". My company is listed in the article and I've seen node sneak into big java projects, you know just to run unit tests for the frontend code. Then it takes on more and more responsibility until the project is a node project with a little java rather than a java project with a little node.

Well when the options are Java and Node, even I would choose Node.

I would choose Java. Java 8 with lambda functions and streams library, is a much more pleasant experience than previous versions. If you take the same library over framework approach with Java as you might with Node, you can build microservices just as easily, and docker equalizes the deployment effort. The main advantage I see with Node is working with JSON and a more simplistic concurrency model but to me Java is getting on the reactive bandwagon and beats Node by having more mature and stable libraries and by being statically typed.

What Java libraries are you talking about in this case?

Not OP, but Spring Boot and the Netflix stack (esp with rxjava) make it super easy to write fast, simple, non-blocking, easily-deployable, monitorable, and resilient microservices.

Check out http://start.spring.io/ and click "switch to the full version" to see the huge variety of battle-tested libraries with excellent integration with Spring Boot.

Jackson combined with JSOG is great. Resteasy as the endpoint layer with Guice as the DI framework. Project Lombok to remove the java boilerplate. Run that on AppEngine and you have an infinitely autoscaling application with zero downtime. Use Objectify for the ORM with the Datastore. =)

It's unfair to compare Java and Node. It's more fair to compare Java and JavaScript or JVM and Node. When the options are JVM or Node, I would choose the JVM. When the options are Java and JavaScript, I would choose Java. And when the options are something like Scala or TypeScript, I would choose Scala (because of the JVM vs Node, I love TypeScript). Of course, all of these choices are based on the use case, but I speak of server side apps here.

Mostly testimonials, but interesting examples for me to see considering I've just got 6 months of full-time Node.js under my belt after many years in Java and Ruby. There's a link from this blog post to the Node Hero Tutorial and I don't remember coming across this recommendation to organize file structure around features rather than roles:

https://blog.risingstack.com/node-hero-node-js-project-struc...

It looks like a good option to me. I just finished a standalone notification system in one of our Node.js apps and all the files are organized more like this than the typical Rails file structure.

Is node.js really ready for mainstream? I've coded javascript for 10+ years and I sometimes laugh at the state is in right now. There's a reason why we are experiencing javascript fatigue and that's because it's not mature to the point it should be mainstream yet. Recently the language tried to tackle the callback hells with es7 async/await but it's way too hacky and I believe it's got quite a ways to go before the language can be used to develop elegant/pragmatic codes.

> GoDaddy started to use Node for the front-end

I don't get it. Do they mean asset compilation etc. How can one use Node in front-end?

I assume they mean they use it to build and serve their web pages, but not necessarily their backend services. Ironically, Node is much better suited for data APIs and backend services.

> Ferenc Hámori > PR & Marketing @RisingStack.

Confirmed: NodeJS is pure hype.

I can't tell if you're being cheeky or not, but the fact that a marketing person wrote this does not confirm anything. Also, why would it even matter?

To be fair, RisingStack basically exists because of Node hype. It's literally their name. They've been putting out sensationalist articles like this for years.

It's basically free advertising for them, this account has 0 comments and has submitted 100% from risingstack.com -- 12 posts in 2 months. It's obvious they're just trying to drum up traffic (i.e. business).

Reply on news.ycombinator.com