Kraken.js is supposed to be released soon according to this presentation: http://www.slideshare.net/l...

Yes. Sorry for the confusion :-)

I should have anticipated that Cian would get a lot of press and at least had a placeholder up at krakenjs.com ;-)

Really inspiring stuff!

NodeJS for the win!

I'm not sure how NodeJS had anything to do with their success. It was just one of many tools they could have chosen to use to complete this effort. I see nothing remarkable here aside from the fact that a company like paypal would want to be an early adopter of technology that is so young and unproven.

Agreed, this could be done with other similar technologies, but they chose Node, and they triumphed. Node is not a panacea for all software development - it does a lot of things, but it does a bunch of those really well. Just like anything else there is a fine line between winning & losing - the extra edge is all that matters. To conclude, All programming languages are turing complete; they could write there own stack with C if they liked and had the same performance gain (if not less) but that would take 10X the time.

no you are incorrect.

The reason for the productivity boost was not due to Nodejs, it was due to they way the legacy system was designed!

It has nothing to do with nodejs.

It is nearly 5 years old and maturing. The power of NodeJS comes from asynchronous design and javascript. That's why it will be a chosen one on the web. nginx also good performer with same asynchronous design.

You may see that Microsoft adopted it on Azure, and other big companies like Yahoo, eBay, LinkedIn, PayPal are all using it somehow in their structure. I think NodeJS proven its power.

A design which is easily replicated in other platforms and languages. React for PHP as an example.

There are others like twisted matrix, ruby event machine etc. any platform can implement event loop. But it doesn't mean that they can survive and grow powerful. NodeJS made it so far. I do not definitely pick reactphp, because they have long way to go.

NodeJS has great community and resources today. Besides it is javascript. It is going to rule the backend as it did frontend.

I love javascript, in fact I write pure javascript as part of my day job (look ma no frameworks ;)

But I also write in a lot of other languages too. I love js, but I don't want to use js in every situation!

server side js, YUCK that idea died 10 years ago *cough* asp JScript anyone?

Use the right tool for the right job.

If I only knew JavaScript, then nodejs is the kind of hammer I would have invented:

"If all you have is a hammer, everything looks like a nail"

I have used most languages like python, c#, php, java and their web platforms. I think that NodeJS is pretty straightforward and suitable for asynchronous web server design.

Web server architecture must be very simple in it's nature. You must get requests and provide response. That's all. Besides you can forward time consuming I/O operations to child processes. That's how it works. So, i am not sure if you have good understanding on web server architecture.

Btw, NodeJS is not just a hype, a lot of people recognized it already. You may use it or not, it is your choice.

I have some understanding of web servers, one of my abandoned projects called "S3ngularity" was building a web server. And contrary to your assertion that a web server is "simple" is not the case.

It is "simple" in concept & theory. In reality its a little more involved. Take a look at the following specs for a web server (a small snippet):

RFC 1945, RFC 2616, RFC 2396, RFC 2671.

Then you have to think about all the other wonderful things such as process isolation. Node.js is single threaded. If a part of your code crashes it brings your entire "web server" down.

That is simply unacceptable design for a "web server".

I did not understand which part you are addressing in RFC documents as "more involved" with web server? Can you please be more specific? Besides these are protocol documents and do not describing web server infastructure.

Furthermore you are addressing HTTP protocol. Well that can be acceptable, But we have new protocols like WebSockets today. And NodeJS is very acceptable design for that kind of technology.

Interpreted languages has disadvantage for the exceptions, it is the truth. But as you may know faulty code and unhandled exception can bring any server down. NodeJS has exception handling mechanism. So it can recover from errors. Even it crashes and exit, NodeJS server can go live in a second and it can be respawn easily. I am pretty sure it is not possible for all kind of servers.

That's not correct IIS for example has proper worker process isolation. if a application pool crashes it does not take down the entire web server. Nodejs is on the other hand will just die.

This is why you have ridiculous work around such as "supervise" modules for nodejs. Which basically restart nodejs when it dies.

Terrible software design for a web server,

Well, good luck to you with IIS...

I don't need luck when I have well designed web servers, unlike nodejs which is a terrible design for a web server.

Nodejs async IO event is cool***, in fact other platforms are copying this approach, so it does have one positive, I admit that. And in some cases nodejs may be useful.

But when outlandish claims about performances are made, and the numbers do not actually reflect the claims it is plain hype(tm).

***But it is not original, it is how network based comms was done in the old days. Nodejs just brought it back into fashion of late.

The back end API and services run on the JVM, what the front end apps are developed in make no difference, might as well have been PHP, probably would have been faster.

You seem to be really annoyed at node js. Pls keep calm and follow whatever you want. I guess people can judge their app's performance in a few days. They at least get a new experience in a new framework. Continual learning Zen! Peace btw node and php :)

Hi Andrew,

I'm calm :)

You are right developers can use whatever tool they want.

What I hate is that node.js which is a product of Joyent (a private company), is using FUD and hype and misinformation to push its own agenda and products.

NearForm is a node.js consulting company and naturally has a stake also in heavily promoting node.js.

Again use a tool for its merit, its a shame that people often mistake hype for "merit".

You have a good day sir :)

YEEEAH! :D

I can't help but wonder how the hire of Douglas Crockford may have played into the decision to go for Node.

Very nice post, but still looks like a lot of the old Not Invented Here is still there, and they have 10 (!!!) new libraries\frameworks to show for it.

Actually we are purposely not adding a lot to existing frameworks. We have an allergy to the NIH syndrome. Our modules for security, internationalization, etc. are just there to help if you are using express based node apps.

Bill you say you don't have "NIH" syndrome, however the above blog post suggests you have created a whole host of frameworks! why?

Why write a ton of frameworks? I mean "findATag"? sounds a lot like regex to me? or am I mistaken?

I hate frameworks just so you know my bias, I'd rather write raw javascript then strap a ton of frameworks just to display a few shiny things on the screen, but that's just me.

Why is it better to have a mountain of frameworks when a few handwritten lines of raw code would have sufficed?

findATag is just a specialization of string tokenizer handy for dust templates. If you look at our framework we could be criticized for actually it being so lightweight. Over the last year we have thrown away a bunch of node modules/libs that we started writing that once we saw a good open source replacement we started using that instead.

It is interesting that you refer to a "mountain" of frameworks. We released a half dozen or so node modules and some yeoman generators. Not quite a mountain.

I have started an "open source office" at PayPal because I do feel like if you look at our github.com/paypal there is a bunch of previous random stuff out there that has dubious value. I want to clean that up.

The step to release Kraken was more about taking our core part of the framework (there is a lot more inside that is specific to the PayPal/eBay eco-system) and get it outside the walls of PayPal. That way it couldn't get bastardized into a PP specific framework. Kraken is pretty simple (although the journey to get it to be simple is a story I will write about later) as it just adds some nice conventions and lifecycle stuff to express. The other modules are handy as they either don't exist or didn't exist in a way that was satisfactory or we felt made sense to fork.

BTW, there is a nice example of a shopping cart end 2 end on krakenjs.com now. That might help with comprehension of the offering.

Maybe I'm sounding cranky, but it seems you are re-inventing an awful lot of things, that have already been solved.

Want smart templating, heck just use PHP.

Bingo! You are cranky ;-)

And at this point becoming a troll. I am happy to dialogue, but that is a silly comment (PHP being the answer).

Yes php was tongue in cheek, but as a side note, a lot of smart "templates" just end up replicating php in one form or another.

Bill, if node.js works for your use case that's great :)

I personally don't trust the claimed hype, as the benchmarks says otherwise.

+1 I was thinking the same thing!

Lots of libraries that do one thing and do it well. They are valuable additions to the Node ecosystem -- some of them without good alternatives.

Great post but where are the repo links?

In case you haven't seen it: krakenjs.com will get you there.

They are coming. Sorry. We have been using this over the last year in our internal enterprise github. We had to do a bunch of renaming and are moving the libraries to githhub.com/paypal in the next week or so (it will be private repo for a week or so, then opened up). If you want access just email me at billwscott@gmail.com

Link does not go where you think it goes...

really interested in the mentioned express-enrouten but I've googled and checked npm for anything that resembles it and struck out. Would love a link or more information.

As Bill mentioned, we are >thisclose< to releasing the whole thing.
We're basically going through the last of the internal legal requirements :)
Stay tuned!

I had no idea all this was going on at PayPal. Good stuff.

The node fan boys will be rolling in soon, they forget the actual heavy lifting is done by the JVM back-end;

but node.js is all hipster and sounds cool and is "l337" and "web-scale".

Node fan boys will be node fan boys. I would never go so far as to say that NodeJS is a fad, it's just too early in it's life-cycle for me to endorse it's use. If it's still around in a year then maybe I'll take a look, for now though it's just another new tool and I only use new tools when the requirements drive me there, I don't like to use new tools just because their shiny and new.

Good point. Maybe you can even spend some of the time you're not wasting by using Node to improve your grammar.

you do not get it do you? it is not matter of java or javascript, it is the matter of finishing product with fewer people, resources and having better performing product on the web. i am curious who is the fan boy here...

why?

so that a few months down the line, the shambles that is left has to be fixed and completely re-achitectured again by the next developers?

Developer productivity is important, but not at the cost of a poor implementations/design choices.

The PayPal case: their legacy system did everything server side inclduing CSS and html, which is madness for sure. Now they are doing things a little more saner. Technically they could have used anything for the front end. So the use of node.js is nothing special in this regard.

It could be anything like you said but they chosed NodeJS! and it was a good choice indeed. I am not sure if they could make it better with another one.

After looking at the recent benchmarks, the benefits of nodejs are diminished further. Even NodeJs's creator has admitted that php with react framework can replicate nodes async style.

yeah the question is who is going to use reactphp? how much time it will take people to learn and contribute? It is just silly option for this conversation, sorry.

I just demonstrated that nodejs is not special, in fact its "number 1 killer feature" (aysnc I/O) is already available in other platforms.

Nodejs real world performance doesn't live up to its Hype in actual benchmarks.

But feel free to use nodejs if it meets your need.

Obviously you made your mind up about node. I sat on a panel with LinkedIn's head of mobile, the head of engineering at Google. The head of infra at eBay. And earlier with Eran Hammer, head arch at walmart labs (mobile). Additionally, Dav Glass who leads node arch at Yahoo! All of us have seen the same thing. In real web production, in real large scale systems, in real internet companies, node is outperforming the java stack in every case.

Once Java has Narwhal in full swing that could be a different story. Narwhal brings evented IO to Java.

Bill that's great, but I want actual numbers:

http://philsturgeon.co.uk/b...

I just don't buy the hype, its js engine, why would I want to use a js engine at the heart of a web server?

Greate node is async, but at some point actual work has to be done somewhere in the pipeline.

That article is about scraping. Scraping is more about computation than about I/O. When you take in a page and then block on scraping that is completely misunderstanding and misusing node's async capability. We posted numbers on our blog did yo not see them? https://www.paypal-engineer...

These numbers are actually holding up quite well (in fact as we are adding clustering it appears that Node will be 10x faster in our case.)

Yes, actual work has to be done in the pipeline. I wonder if you understand our architecture. Node is at the webapp layer. It is nothing but an aggregator of data and a formatter. That by definition is what functional languages do well. And this aggregation comes from I/O. That is what async does well with evented I/O. No real computation (a little in formatting, but very little).

We call services (non-blocking) like add a card, add a bank, remove a card, remove a bank, confirm a bank, send money, receive money and so on. These are not done in our node layer. They are done in the Java Layer and our node app calls a service for this asynchonously in a fire and forget model. The node process goes back to handling the event loop. but doesn't block while send money happens. it can process tons more requests. Then an event happens where the money got sent (confirmation) and the callback is fired in node and the UI gets sent some JSON or some HTML gets formatted and the world is happy.

The reason you want to use a JS engine at the heart of a web app server is why Ngnix is so much better than apache. evented i/o is better than threads for handling large amounts of i/o bound traffic.

JS gets extra points due to it being a functional programming language, the use of closures that matches so well with asynch and the fact that V8 C++ engine powers it.

Node just happens to be the most mature evented i/o, async, functional programming platform that is ubiquitous to the web.

This is not really a Java vs JS question. It is modern web architecture has led us to see that at different layers in the stack there are different problems and concerns. Node nicely satisfies those.

This is why there is so much interest in Scala, btw. It gives functional programming in the VM and becomes more terse and dynamic compared to classical inheritance schemes.

No one is saying Java is dead. We are using it all over the place at PayPal and will continue to do so. Just not for the web app layer.

Walmart uses it for fronting services as a proxy. If you think about it that is the same aggregrating/formatting challenge that the web apps have. There they have some god awful back end systems speaking in cryptic protocols that Node smooths out to be all RESTful/JSON services.