Trouble-Free Shopping with And Java EE 7

Interview with Matyas Bene, an alumni and developer at

What is

Youstice is a company and cloud-solution that helps resolve customer complaints and make shopping trouble-free. With Youstice , companies can seamlessly communicate and handle customer complaints within a matter of minutes. Similarly, disgruntled customers can get prompt assistance with their issues and save valuable time with the possibility to escalate their complaints to a neutral 3rd party for an independent decision.

Which technologies is using on the backend?

The solution consists of 3 pillars:

  • the application itself - developed in a proprietary JVM-based, full-stack development and runtime platform, running on Tomcat,
  • the integration gateway (API) - facilitating the communication between 3rd party SW and the application, developed in J2EE,
  • plugins into various e-shop platforms and other points of entry - utilizing various technologies including PHP, Java, C# and others - as needed

You decided to use JAX-RS 2.0 / Java EE to implement the API, why?

First, we needed to be platform-independent, hence JAVA and the JVM. Choosing J2EE as our framework was a no-brainer for several reason:

  • all the components are already integrated (no wasted time by fiddling with the integration of 3rd party libraries),
  • is well-established and has a solution to the most pressing issues that a developer would encounter in an enterprise or even in the wild-wild world of cloud solutions, and
  • is open, versatile and future-proof,
  • is lean to run and quick to develop.
To give credit where credit is due, Adam Bien (and his videos about "Lean J2EE" on youtube) played a big role in changing my opinion on J2EE a couple of years ago.

How many developers are working on the API?

It was a one-man project since the beginning.

What about the performance?

Development performance is remarkable. We estimated it to 5MD (net effort) to get on feature-parity with the old-version, which we delivered (excluding translations, bug-fixing and tuning). Runtime performance has also improved. Rewriting the API to J2EE helped us to increase the number of requests handled per second three-fold on the same hardware, and, at the same time, eliminate the occasional drop-outs. This migration also opened up possibilities and functionalities that were not available before, or would have required a considerable amount of extra-code.

What is your experience with Java EE so far?

Still learning it, of course. The more I learn about and work with Java EE 7, the more I realize the level of development (and also runtime) efficiency it offers. That said, I guess it's still too easy and tempting not to follow the rules (TM) and end up with >X (=your time here) minutes of compilation times, sending development efficiency to the rock-bottom. So it either requires a really stubborn adamancy in sticking to the rules (TM) or considerable level of expertise.

I'd also like to note, that the number of quality materials specific for Java EE 6/7 is very limited. There are plenty of gems in the platform (especially in conjunction with JDK8) that are either well-hidden or difficult to understand/combine properly at first, yet are huge time-savers for the knowledgeable. A big thank you goes to you, Adam for doing your best to fill this gap. The blogs, Q&A sessions and the trainings are worth gold. So far every session I attended resulted in hundreds of lines deleted, dependencies dropped, features increased, builds simplified.

Which tools, servers, IDEs, external libraries are you using?

IDE is NetBeans. Previously it was Eclipse, but I haven't seen it since my first airhacks session in Munich. As a matter of fact, it was easy to convince my colleagues to switch as well. We utilize Jenkins, SonarQube and Jacoco for the quality cycle. The application server we use is Payara. Important 3rd party libs include querydsl, jersey and jackson. Lately, we introduced porcupine to fight back-pressure and swagger to document our API. However, the overall trend is to shrink the .war size. Currently it's half the size it was 6 months ago. It's partly Payara's advantage (ships many commonly used jars, like jackson) and partly our internal effort to get rid of external dependencies. We even consider dropping jackson in spite of the performance advantages.

You attended the workshops in Munich. Do you had the opportunity to chat with other attendees? What was the most interesting project?

Knowledge sharing between participants is something I especially enjoyed during the last 'micro-services' sessions. The attendants were all seasoned professionals who've brought their lessons learned from past projects. It was very interesting to see how certain challenges pop up in almost every organization (and the different solutions or attempts) as well as learn about the rare cases. Out of the projects I've learned about, the most interesting one for me was - AFAIK they were running glassfish on an embedded raspberry.pi device to monitor showers in camps.

Any resources, links (shameless plugs) you would like to share with us?

Partly mentioned above: Payara, QueryDSL, Orient DB, Swagger, AuthenticRoast and of course Youstice. Just because I think they're great.

Matyas, thank you for the interview!


He still speaks of J2EE instead of Java EE! I guess he is as clueless as most IT managers and HR people.

Posted by javaservant on July 06, 2015 at 11:28 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments