After this two years, are there any options to play 1

[Hans Poo]

Hi,

This post is in no way intended to cause any debate, just help us choosing technology.

Mi name is Hans Poo and own a small software development company in Chile, we are still using play 1 (exactly 1.2.5.3), and actually have happily some projects in maintenance mode, in fact now we are testing the latest released 1.3.RC1 (thanks to the play team).

But it's hard to explain to our new clients why we are using a software that has been in some way freezed by its own makers, their first question is why we are not going on with play 2, the answer is not easy. Sadly enough we have given play 2 a real try more than once, and don't feel comfortable with it.

Because ot this we have been scanning the web for months and haven't found something like play 1: grails, vaadin, spring, jsf, angular, etc, each one for different reasons don't fit in our expectations.

We would like to know what frameworks you actual (or ex) users of play one are using now. Your information will be very valuable for us.

Hans, CTO Welinux S.A.

[Carl Perfect]

On Thursday, July 3, 2014 7:13:37 PM UTC+2, Hans Poo wrote:

Hi,

This post is in no way intended to cause any debate, just help us choosing technology.

While your post raises a lot of good questions (that I would be to eager to delve into
just for the pleasure of conversation), I will do my best to stay on topic.

Well, I looked into other frameworks too, and the best I found was ninjaframework
It is very inspired by play1 with regular and recent updates.
You can find the author on the dedicated google group.

I like it a lot. But I was rebuffed by the omni presence of maven.
And it seems that maven is here to stay.
Also, ninja uses guice which is quite slow on GAE (Google famously
warned developers against it - as reflection is very slow on GAE).

jfinal looks interesting but the lack of English support
is a big no-no for me.

As for next gen technologies, I keep an eye on frameworks that
would revolve around kotlin (not yet released) or ceylon.
But I haven't found anything stable/interesting yet.

If you're looking for web frameworks, you can always browse the
techempower benchmark that regroups a LOT of them.
Not necessarily java framework, if you are ready to jump ship :)

I have to leave you, I have a play1 performance module I'm eager to
start :)

Cheers,
C.

[Michele Mauro]

Another interesting one is Dropwizard: https://dropwizard.github.io/dropwizard/

Interesting ideas in composing components, and great attention to operational details.

We have an important product on Play! 1.2.7, and we are now architecting our exit strategy.
Spray+Akka is very tempting, since we are very interested about having a Reactive backend.


Michele

[Chris Webb]

I'm in the process of moving a Play1 app to AngularJS single page app which is completely driven by APIs. Once that's done I'll probably look at another framework to reimplement the API and Play2 could be a contender at that point.

--
You received this message because you are subscribed to the Google Groups "playone" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playone+u...@googlegroups.com.
To post to this group, send email to pla...@googlegroups.com.
Visit this group at http://groups.google.com/group/playone.
For more options, visit https://groups.google.com/d/optout.

[Carl Perfect]

Nice answer.

On Friday, July 4, 2014 2:01:58 PM UTC+2, Michele Mauro wrote:

We have an important product on Play! 1.2.7, and we are now architecting our exit strategy.

Is this only because the development on play 1 have "frozen" or is there any
other concerns ?

[Hans Poo]

Carl,

Thanks for your reply, and for stay on topic...

I've looked at ninja too, looks fine, but after play one i was looking for something more established.

Bye

[Hans Poo]

Michele,

I see that Scala is your way to go, i guess type safety over grails/groovy, and then in the front ¿ node.js or something else ?

Thanks,

[Michele Mauro]

The near-abandon of Play 1 is one of our mayor concerns, of course. It is not a pressing problem, because code is still easy to write and there are no significant bugs open on 1.2.7 that impact us, but as a CTO I can't sit confortably on a dead architecture.
Together with a couple of colleagues we're cutting all possible ties to the framework (the Model subsystem is the most difficult one, since it was one of the more interesting solution that drew us to Play! in the first place) in preparation to moving away.
The second motive is the desire to move to a Reactive architecture for reasons of scalability and speed. We are evaluating a couple of Akka-related options; with the news of work ongoing towards a Play! 3 version, I think we can fit this in a timeframe such that it could be a possible contender, along with something more low-level like Spray.

Michele

[Michele Mauro]

Il giorno venerdì 4 luglio 2014 15:27:34 UTC+2, Hans Poo ha scritto:

Michele,

I see that Scala is your way to go, i guess type safety over grails/groovy, and then in the front ¿ node.js or something else ?

the debate is still open about the specific language.
Node.js is out of question, though: we tried a couple of subprojects and didn't like it. On the other hand, completely async code in Play 2 (for example, a simple websockets server) worked like a charm in Scala.

A colleague is very fond of clojure, and sees everything Scala as unnecessary complexity; and sometimes, he is right. My main concern with any such choice is the learning curve given the various levels and personalities that make our team.

I see Scala as something that can be introduced gradually in terms of language complexity, while you keep your architecture in check with types and program structure. When people start thinking in maps instead of for loops, you are almost done. And you can always fall back to plain Java.

Clojure, on the other hand will look alien to most, and I know at least a couple team members that I think haven't got the mental framework to grok it productively. And since we have exsisting code that uses plain HashMaps to drive values around (usually towards JSON services), that when I had to work with it I always needed to hunt down where the map was populated to understand what was happening, the Clojure adagio "just use a map!" sounds to me as more a menace than a suggestion.
I do value Clojure as a very interesting language and an equally interesting philosophical foundation; I just think it won't work well with my team given my team's specific background.

Michele

[R. Rajesh Jeba Anbiah]

On Thursday, 3 July 2014 22:43:37 UTC+5:30, Hans Poo wrote:

We would like to know what frameworks you actual (or ex) users of play one are using now. Your information will be very valuable for us.

AngularJS for SPA. For REST server: PHP (single file) or Node.js or nginx+Lua or Go. PHP & Node.js are amazingly productive in terms of speed of development, etc.

[Tom Carchrae]

Mi name is Hans Poo and own a small software development company in Chile, we are still using play 1 (exactly 1.2.5.3), and actually have happily some projects in maintenance mode, in fact now we are testing the latest released 1.3.RC1 (thanks to the play team).

But it's hard to explain to our new clients why we are using a software that has been in some way freezed by its own makers, their first question is why we are not going on with play 2, the answer is not easy. Sadly enough we have given play 2 a real try more than once, and don't feel comfortable with it.

 

I think the Play team even stated that they are not migrating their existing deployments for Play 2 - so even they have a vested interest in Play 1.  

To your client's question; which I think perhaps, might be more your own self-doubt (it was for me) - using a stable production tested framework like Play 1 is a safe choice.  Does their application really require any bleeding edge technology?  

For myself, I migrated some of my stack to http://vertx.io - and I keep lots of models in Play 1 (you can use vertx embedded in Play).  Why did I do that?  Not because Play 1 was frozen (I agree that it is pretty feature complete) - but rather because I wanted a great async messaging bus for my GWT applications.   I have other projects using dropwizard - and like vertx, it is really great for REST/API servers - but sucks for rendering templates.

I do like using node.js for template rendering backed with a REST server to handle all logic.  I had the unpleasant experience of using databases in node.js (sequelize) - it is really awful compared to the mature tools in Java and it makes you sing love songs about static types.

Tom

[R. Rajesh Jeba Anbiah]

On Tuesday, 8 July 2014 22:33:50 UTC+5:30, Tom Carchrae wrote:

I do like using node.js for template rendering backed with a REST server to handle all logic.  I had the unpleasant experience of using databases in node.js (sequelize) - it is really awful compared to the mature tools in Java and it makes you sing love songs about static types.

What mature tool in Java, are you talking about? Hibernate or? 

[Carl Perfect]

On Tuesday, July 8, 2014 7:03:50 PM UTC+2, Tom Carchrae wrote:

Just my two cents.
 

using a stable production tested framework like Play 1 is a safe choice.  

I feel that way too.
 

Does their application really require any bleeding edge technology?  

To me, the time to market of my applications is the feature I want to optimize.
I know that my app won't receive Facebook traffic.
So far, every performance issue was fixed with aggressive caching (and query tuning) :)

I do like using node.js for template rendering backed with a REST server to handle all logic.  I had the unpleasant experience of using databases in node.js (sequelize) - it is really awful compared to the mature tools in Java and it makes you sing love songs about static types.

Did you try typescript?
Sure it won't solve the database access unpleasantness, but I least you'll get back the
compiler errors, and depending on your IDE, automatic refactoring.

 

Tom

[Hans Poo]

Nobody mention grails, i'v
Been looking at it and it looks very much like play one with many plugins and support.

[Johan Vosloo]

Very interesting question..... and still very relevant for us.

We also still love Play 1 and have invested heavily in it for a significant line of business app.

Also not happy with the current state of Play2 (yet) - so we're in the same boat as with where to from here.

Did you end up going with Grails?

If not, which framework then?

I've been wanting to get excited about NodeJS frameworks like Meteor... but feel that we are just not there yet to be able to switch to something like that for anything non-trivial.

[Hans Poo]

Johan,

I've give up with grails, i've give it a try and really at this moment dynamic languages are not for me, for many years i was a perl programmer and after feeling the benefits of java programming i'm not going back (still use perl for oneliners or small scripts). Well at my company we are using exclusively play one, play 2 and its scala orientation don't attract us, spring mvc and jsf are to heavy, but going to JS frameworks present the same maintenance problems of perl or grails...

Bye,

[Johan Vosloo]

Hi Hans

Thanks for the feedback. I just went through the process of upgrading a fair-sized up from v1.2.7 to v1.3.0.

I had a little quirkiness to deal with, but it was all around Hibernate changes and then mostly in some plugins that I had to adapt to work with Hib4.

Other than that it was smooth and painless and reaffirmed that Playone is still the best option for that (and similar) apps for me.

Btw... the upgraded Groovy lib (up from v1.8.6 to v2.3.6) should offer a nice performance boost for template rendering.

I did some performance tests a while ago with Morten's FasterGT plugin vs the standard and the single performance gain I got was just dopping in the v2.x of thr Groovy jar into Play 1.2.7's framework lib.

Regards

Johan

[Hans Poo]

Johan,

Before the final release, one month ago or so, i was running play 1.3 with two real sites and experienced a very slow performance with hibernate, then rolled back to 1.2.5.
I'll give it a try soon.

Bye,

[Johan Vosloo]

Ha! I also ran into the slow performance issue.

In my case it seems that for some reason the fetchtype behaviour for especially ManyToOne relationships changed, as well as the cascading behaviour for child collections, which means that much more data gets loaded on every request, as well as child items being updated like crazy on parent saves.

I've toned that down by adjusting the cascade and fetch type settings in a few places (on OneToMany and ManyToOne) - it's looking much better.

Along with a few other optimization tweaks it's proving to be not too bad.

[Chris Webb]

Hi Johan,

It would be great to get some more specifics of the cascade/fetch adjustments and the other optimisation tweaks as I think they will apply to a lot of deployments moving to 1.3

cheers

--

You received this message because you are subscribed to the Google Groups "playone" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playone+u...@googlegroups.com.
To post to this group, send email to pla...@googlegroups.com.
Visit this group at http://groups.google.com/group/playone.
For more options, visit https://groups.google.com/d/optout.

--

e: ch...@spinthewebb.com

m: +44 77 8639 2359

[Johan Vosloo]

Hi Chris

Like I mentioned before, in terms tuning JPA/Hibernate behaviour, I mostly changed fetchtype and cascade settings.

ManyToOne FetchType

For the fetchtype stuff... afaik the default fetch type for ManyToOne relationships in JPA and Hibernate is "eager".

This should be the same then between 1.2.x and 1.3.0... but for some reason (and I'm not 100% sure of this yet - so please verify for yourself), it seems certain model loads would just return a much larger graph of data than before... mainly due to all the eager fetching of parent entities.

Now as I said... I'm pretty sure the same rules should have applied in 1.2.x (i.e. Hibernate 3, etc), but the app I'm migrating has been noticably slower in a few places...and it looks like it was loading related entities like mad. After specifying lazy fetching on a few ManyToOne annotations, i.e. like so:

@ManyToOne(fetch=FetchType.LAZY)
public Parent parent;

I was no longer pulling back half the DB on each certain requests. You have to be careful with this though... to many of those and you will quickly get killed by the N+1 selects problem.

OneToMany Cascading

As for cascading - I specify "ALL" as the default cascade type on OneToMany collections in most cases.

I had especially one parent model class with a lot of child collections, which (after moving to 1.3.0) suddenly took FOREVER to update, even though I would just be changing one field on the parent item. In 1.2.x this isn't a problem for some reason.

I solved this by completely removing the cascade statement from the OneToMany annotations in this particular class, like so:

Before:

@OneToMany(mappedBy="parent", cascade=CascadeType.ALL)

public List<Child> children = new ArrayList<Child>();

After:

@OneToMany(mappedBy="parent")

public List<Child> children = new ArrayList<Child>();

You can argue that I never should specified the CascadeType.ALL on those child collections to begin with, since in that particular case I never would want all the child collections to be either updated or removed on update/remove of the parent. That being said.... it was never a problem in 1.2.x, but it sure is with 1.3.0.

Other tweaks

As for the other tweaks - slow DB operations like the ones mentioned above made me realise that there are a few places that I could improve the user experience (and better manage server load) by splitting things some more things up into jobs, specifically post-insert processing of a large child collection (I use jobs quite extensively already) - so quite app specific and nothing new really.

Conclusion

So if anything, I guess that with 1.3.0/Hib4/whatever-else-was-updated, some of the rules about how data is loaded and relationships are managed are actually being enforced properly - i.e. it seems that I may have gotten away with murder before :)

All this is still to be verified properly though--- this is just my initial take on what's happening.

If I come across anything else I will post it here - but will also appreciate some feedback/comments from others on whether they experienced similar behaviour and what they did to fix/improve things.

Regards

Johan

[Scott Rippee]

Hi Johan,

Thanks for taking the time to write out these specifics!

[Johan Vosloo]

You're welcome Scott :)

[Hans Poo]

Johan,

Thanks too for taking the time, don't you find a way to correct performance issues without modifying java code, like something in application.conf, for example, we have been always using  hibernate.max_fetch_depth=1, without this it really gets very slow.

Bye,