Choosing a better software stack

[Rakesh]

Hi,

wanted the wisdom of the group to help me out.

My current project is essentially a platform providing web services to
a number of clients.

We've developed the web services by using Grails as it was considered
a very quick way to get things going.

Grails has been a positive experience from a development point of view
but there are a number of disadvantages which are now prompting a
rethink:

Grails' sweet spot is creating a web application (rather than web
services) to do CRUD.

Our platform is not about typical CRUD. We do not have a html
front-end for example. Or a relational db. We use Mongodb.

We are also concerned about the runtime performance of Grails as well
as how long it takes to startup in Jetty.

So can anyone suggest an alternative? Performance and load are
important. Being able to expose web services easily from Java is also
important.

I was thinking using Tomcat + Spring, mainly because its a stack I
know and Tomcat can handle a huge load and I can pick and choose the
bits of Spring I need. I would consider something lighter weight but I
really don't want to muck around with web.xml files and the usual
standard java web app crap (which Grails does a fantastic job of
abstracting away).

Any other ideas?

Thanks

Rakesh

[vjosullivan]

It might be worth taking a look through the answers to this thread
http://groups.google.com/group/javaposse/browse_frm/thread/fadc0d3423ade6ea
where I asked a similar question.

[rakesh mailgroups]

that thread is focused on building wep apps with a front end. In fact, I replied saying consider Grails!!

Mentions were made of Scalate, Play and Spark. I'll have a quick look at them and see if they seem suitable.

Some further context of the requirements - expose restful urls, convert json data into Java objects, transform and out into MongoDB.

Like I said, Grails allows this (quite nicely) but just with a heavy weight infrastructure that I'm wondering is really necessary.....

Rakesh

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Moandji Ezana]

On Fri, Mar 16, 2012 at 11:52 AM, rakesh mailgroups <rakesh.m...@gmail.com> wrote:

Some further context of the requirements - expose restful urls, convert json data into Java objects, transform and out into MongoDB.

What about plain JAX-RS?

Moandji 

[Chris Phelps]

+1. If you are just doing basic RESTful services, JAX-RS (in our case, using Jersey) fits the bill very well without a whole lot of config overhead.

-C

--

[Scott Finnie]

A bit off-left (and I know, this is the _java_ posse, but):

Are you wedded to the java ecosystem?  If not you might want to look at webmachine (http://wiki.basho.com/Webmachine.html).  Similar in concept to JAX-RS.  It's fast, has a refreshingly simple programming model and written in erlang - so reaps the robustness of the otp infrastructure.  Pretty sure there's also native drivers for mongo.

hth.

 - S.

[clay]

I'd add +1 vote to a Jersey + REST + JSON solution.

I did a fair amount of this work. Jersey didn't do very much, but provided a simple, clean, elegant web services framework that did everything we needed. It was perfect, yet minimalistic. For a server, we used embedded Jetty for development and Tomcat for production, which worked well.

I did my Jersey work in Java, but if I had to start over without legacy considerations, I'd use Scala instead (but keep Jersey).

[Steven Siebert]

+1 Jersey/JSON/REST, but I would suggest you ensure you use Jackson instead of jettison for your JSON parsing library (jettison is default, at least on glassfish).  Mostly, you'll be able to just use straight JAX-RS without having to use Jackson directly - but jackson does two things I find really important over jettison: returns dates in ISO format, renders an empty collection/array as an empty JSON array instead of null/renders a single element collection as a JSON array vs an object.  

S

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/z82cQnuIWgIJ.

To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
...Seggendo in piuma
in fama non si vien, né sotto coltre,
sanza la qual chi sua vita consuma
cotal vestigo in terra di sé lascia
qual fummo in aere ed in acqua la schiuma.

[Kevin Wright]

Disclaimer: For the purposes of that reply, one class per endpoint (with its obligatory ceremony of imports and annotations) shall not be considered to be "config overhead".  

Nor should the one-file-per object and attendant annotations that come with Jackson (that being the JSON framework that's most likely to be used with Jersey)

Counter-Disclaimer: It's possible to put your entire site routing structure in a single file, and avoid pretty much *any* overhead of any kind whatsoever.

• http://www.scalatra.org/stable/book/#Routes
  
• http://unfiltered.databinder.net/Asyncrazy+Temperature+Server.html
  
• https://github.com/jdegoes/blueeyes
  
• https://github.com/spray/spray/blob/master/spray-examples/spray-example-calculator/src/main/scala/cc/spray/examples/calculator/CalculatorService.scala
  
• http://bowlerframework.org/#samples
  

For sheer DSL-exuberance, it's hard not to appreciate the way that bowler embeds the routes directly into method names, even if it does feel a bit like it's pushing things a little *too* far...

The best part is that you still get the full awesomeness of running on the Java platform, while taking your maintainability up by an order of magnitude.  What's not to like?

[Cédric Beust ♔]

On Fri, Mar 16, 2012 at 5:51 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

while taking your maintainability up by an order of magnitude

[citation needed]

-- 

Cédric

[phil swenson]

"Our platform is not about typical CRUD. We do not have a html
front-end for example. Or a relational db. We use Mongodb.

We are also concerned about the runtime performance of Grails as well
as how long it takes to startup in Jetty."

I don't know Grails very well, but I am certain that you are not
forced into a CRUD model.

Check this out: http://grails.org/plugin/mongodb

And of course run this search:
https://www.google.com/webhp?sourceid=chrome-instant&ix=seb&ie=UTF-8&ion=1#hl=en&output=search&sclient=psy-ab&q=grails%20mongo&oq=&aq=&aqi=&aql=&gs_sm=&gs_upl=&gs_l=&pbx=1&fp=d6dedd7a89ce7f98&ix=seb&ion=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.,cf.osb&biw=1442&bih=1018

My other question is: why do you think that the web stack is going to
be your bottleneck? It usually isn't. And don't forget that Grails
largely wraps up spring (which is written in java).

But that all being said: check out the Play framework. If you prefer
Java, it's your best bet IMO.
http://www.playframework.org/modules/mongo

[Ryan Schipper]

In a similar vein, have you tried deploying Grails to Tomcat instead of Jetty?

http://grails.org/doc/latest/guide/gettingStarted.html#supportedJavaEEContainers

[mgkimsal]

On Mar 16, 5:25 am, Rakesh <rakesh.mailgro...@gmail.com> wrote:

>
> Grails' sweet spot is creating a web application (rather than web
> services) to do CRUD.
>
> Our platform is not about typical CRUD. We do not have a html
> front-end for example. Or a relational db. We use Mongodb.
>

As someone else pointed out, there are plugins for grails for mongo -
I believe the mongodb plugin is a bridge between GORM and mongo.

> We are also concerned about the runtime performance of Grails as well
> as how long it takes to startup in Jetty.

Grails' startup time is longer than Java, and that depends somewhat on
the size of your app. I'm dealing with a project with 150+ domains,
and a similar number of controllers. There's a good 40+ seconds spent
loading and decorating the classes with dynamic stuff and, from what I
can tell, doing something with the classes with Spring. I'm no Spring
expert, but I was trying to do some tracing to determine why the app
takes 1.5 minutes to start up, and much of the time was spent simply
finding all the classes on disk, loading them up, and doing something
with Spring to the classes (honestly don't remember exactly what it
was).

To that end, 'pure' Spring outside of Grails might be faster startup,
but I'm not sure *how* much faster. What are you startup times now,
and why do they concern you so much?

Are you using Grails 2 or Grails 1?

Tomcat will probably be at least a bit faster, if only because it's
the defacto standard in the Grails community, and I suspect the Tomcat/
Grails combo has had a bit more love/attention than Jetty has in the
past few years.

You mention the startup time, then mention performance. Have you run
any performance tests on your current Grails setup as a benchmark?

Benchmarks out there all show Groovy being slower than 'plain old
java', which is to be expected, but in 'real world' tests, I've not
found Grails to be a performance bottleneck in and of itself, and the
usual suspects of disks and databases have tended to be the bigger
issues. Once those are addressed (better indexing, optimize queries,
etc), then yes, just the app stack is left, but have you measured how
much of a bottleneck Grails itself is in your situation? What is it
providing, and what are your performance goals?

[Ricky Clarkson]

I know next to nothing about Grails but is there no option to do all that stuff at build time, and if not, why not?

[mgkimsal]

Do all what stuff at build time?

The dynamic stuff I referred to? I'm talking about building during
development. I deploy... once every few weeks. I'm *building*
multiple times per hour during development, and that's what I was
talking about.

That said, *most* of the dev I'm doing is on classes/files that are
hot-reloaded, so I don't often endure the 90 second rebuild - in about
80% of the cases I'm changing files that get hot reloaded and I'm
refreshing a web page in 2 seconds - nearly as fast as PHP! ;)

On Mar 20, 8:09 am, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
> I know next to nothing about Grails but is there no option to do all that
> stuff at build time, and if not, why not?

[Ricky Clarkson]

When you talked about Grails' startup time I assumed you meant on a fresh servlet container. That's the first time I've seen build time called startup time. :)

[Rakesh]

ok, I admit it. I have no proof that Grails is the cause of the
performance issues.

I was hoping someone had been in the same situation as me. Back to the
drawing board...

Rakesh