.js .js Node Node compared to traditional compared to traditional Java EE Java EE Servers Servers Application Application Niko Köbler Independent Software-Architect, Developer & Trainer > > > niko@n-k.de www.n-k.de @dasniko

? ? Why Why Java app servers are Java app servers are !? !? > > dead dead > Node.js > Node.js app! app! hipster hipster Java is Java is ... (and Node.js is fast?) ... (and Node.js is fast?) > > slow slow But is that all true? But is that all true? Which one is Which one is / / / / ? ? faster faster better better hipster hipster

Some Some ... ... research research

Node.js performance +20% vs. Java ...but no async code in Java...! > http://blog.shinetech.com/2013/10/22/performance-comparison-between-node-js-and-java-ee/

http://www.infoworld.com/article/2883328/java/java-vs-nodejs-an-epic-battle-for-developer-mindshare.html

Rock-solid foundation Cross-compiling from one to the other .js Node Java Topic Topic winning winning Remote debugging Database queries JSON Solid engineering Speed Threads Momentum Ubiquity Better IDEs Build process simplified Libraries http://www.infoworld.com/article/2883328/java/java-vs-nodejs-an-epic-battle-for-developer-mindshare.html

was the was the ? ? What What challenge challenge About UseCases and About UseCases and MicroServices MicroServices

The The Customer Customer conservative > anxious, frightened standards are 10-15 years behind > beware of all "new" (tech bubbles) "enterprise chief architect" > > >

The The UseCase UseCase key management, use every key only once > ~10.000.000 keys per day (avg. 115 req/sec, max. 900 req/sec) business analysts advised MongoDB > no NoSQL database used so far > >

Create a Create a ! ! MicroService MicroService bounded (api) context > independendly deployable own datastore (we used key/value store) > resilience (w/ use of ) scalable > lightweight own process > > Redis Sentinel > >

I'm a I'm a fanboy! fanboy! JavaScript JavaScript (server-side, not necessarily front-end!)

Let's use Let's use .js! .js! Node Node one, lightweight, independent process > good and easy-to-use redis/sentinel communication (also ) few lines of code > solution was after 30mins of coding > asnychronously > ready

! ! No No Unfortunately, the customer said: Unfortunately, the customer said:

..! ..! But But I tried to convince: I tried to convince:

You have to use You have to use ! ! Java Java Can I use ? > No, only (Java EE 6 with Java 7) But that's a heavy-weighted, old-fashioned application server, and everybody is claiming: > ! Do I really have to use such a rhinoceros for such a small "no-brainer"? > Vert.x JBoss EAP 6 > App Servers are dead >

did we solve it? did we solve it? How How Let's have a look into the Let's have a look into the ... ... code code

: : Repositories Repositories Node.js: Node.js: Wildfly: Wildfly: https://gist.github.com/dasniko/48d65bddb06ad6eaad24 https://github.com/dasniko/wildfly-async-redis

Thanks to Thanks to ! ! @Suspend @Suspend Java EE 6 / JAX-RS 1.x doesn't support async requests > synchronous requests result in many HTTP threads Resteasy provides annotation > processing becomes true in JAX-RS 1.x > For the sake of : use an asynchronous redis connector > worker > @Suspend Asynchronous completeness

! ! Results Results Node.js: 1 OS thread > JBoss EAP: 1 JVM thread, only ~3 used > http-worker-threads load/stress tests were performed with .io > Gatling 50 threads min tps Node.js 1ms ~2.000 req/sec JBoss EAP 1ms ~2.000 req/sec

to next? to next? Where Where

about... about... Think Think using http-worker-threads > your code/infrastructure your services using (or Spring Boot, Vert.x, whatever) instead of EAP > ...you it! > more optimizing > scaling > Wildfly Swarm name

It doesn't It doesn't matter matter which technology you use. which technology you use. Use it Use it ! ! right right

Thank Thank ! ! you you Any Any ? ? Questions Questions Niko Köbler Independent Software-Architect, Developer & Trainer > > > niko@n-k.de www.n-k.de @dasniko Blogpost: http://www.n-k.de/2015/01/high-performance-microservices-nodejs.html