Play Framework vs Lagom

[CB]

hi all,

we are using play framework 2.x for over 2 years running in production using micro services architecture.

recently Lightbend launched Lagom and I think that this community deserves a proper message from the project's founders (including James Roper - and others) about the vision and the strategy looking at the near and long future.

I am concerned about the fact that Lightbend is splitting forces into two separate stacks / camps.

I'm also concerned about the Java first approach ($$$). This is a complete flip over with no proper addressing to a live and vibrant Scala adopters of Spray, Akka HTTP and Play.

I also wonder - why a completely new framework instead of a unified solution? The Reactive Stack is starting to become fragmented.

What is the official timeline for Play 3?

Any other insight on what is the broad vision from Lightbend founders about writing next generation micro services components is greatly appreciated.

Don't get me wrong - we admire what the Typesafe team is doing for the community but currently there are big question marks all over the space.

[Andrew Gaydenko]

CB,

Thanks, you have started really interesting theme!

For some reason I also have got some "lost" feeling while reading Jonas' article [1], which is,
as I can see, an official Lagom motivation.

So, agree, some Play team members' shared (may be not official) opinions would smooth Play
community mood.

P.S.Well, I'm sure not to be the first naming Lagom's services as "actors on steroids"; who is the first? :)

[1] https://www.lightbend.com/blog/reactive-microservices-architecture-free-oreilly-report-by-lightbend-cto-jonas-boner

[Naftoli Gugenheim]

Just to be clear, Lagom is *based on* Play and Akka (and Conductr I think).

On Sun, Mar 27, 2016 at 9:07 AM CB <chen....@gmail.com> wrote:

hi all,

we are using play framework 2.x for over 2 years running in production using micro services architecture.

recently Lightbend launched Lagom and I think that this community deserves a proper message from the project's founders (including James Roper - and others) about the vision and the strategy looking at the near and long future.

I agree that would be nice. :)

 

I am concerned about the fact that Lightbend is splitting forces into two separate stacks / camps.

See above, it's not. It's a commercial product based on their open source projects, including Play and Akka.

 

I'm also concerned about the Java first approach ($$$). This is a complete flip over with no proper addressing to a live and vibrant Scala adopters of Spray, Akka HTTP and Play.

I agree. However the best explanation I've seen, which makes some sense, is that it's the Java companies that have a need for something like Lagom, that are fighting with a growing big ball of mud, with no obvious path to migrate to Play or microservices. The scala teams are doing quite fine and don't have much need for a commercial project like Lagom. Also, it sounds like Lagom is maybe less a software package and more a hand-holding service.

I also wonder - why a completely new framework instead of a unified solution? The Reactive Stack is starting to become fragmented.

See above again. Actually it's getting more and more unified, especially with the move to Akka streams and to Akka http.

 

What is the official timeline for Play 3?

Another good question. :)

 

Any other insight on what is the broad vision from Lightbend founders about writing next generation micro services components is greatly appreciated.

Real scala programmers don't just follow some other company's vision. :)

Don't get me wrong - we admire what the Typesafe team is doing for the community but currently there are big question marks all over the space.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/df200a9d-dd57-4ba8-b2d8-185892861d3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg Methvin]

I'm not on the Lagom team but I can give my opinion from my own perspective on the Play team and respond to some of your concerns.

I am concerned about the fact that Lightbend is splitting forces into two separate stacks / camps.

Lagom is built on top of Play, and its goal is more specific than Play's goal as a project. It's not a general-purpose web framework, but rather an opinionated framework for writing microservices. In particular, it adds an API for describing/implementing services and a CQRS-based persistence API on top of the APIs Play already has. Lagom would not have been possible without Play, and whatever it ultimately becomes will depend on continued development of Play.

I'm also concerned about the Java first approach ($$$). This is a complete flip over with no proper addressing to a live and vibrant Scala adopters of Spray, Akka HTTP and Play.

Lagom is Java-API first because we found Java users would benefit more from the opinionated approach Lagom provides, and of course a Java API makes the MVP accessible to the widest audience. The current version is only an MVP and the Scala API is probably the biggest feature coming in the next few releases. Lightbend/Typesafe projects have always had Java and Scala APIs, so nothing is really changing in terms of the philosophy. The difference I suppose is that we chose to release something before a Scala API was completed.

I also wonder - why a completely new framework instead of a unified solution? The Reactive Stack is starting to become fragmented.

It's a framework in the sense that it prescribes several specific solutions to persistence, service definition, etc. on top of what Play already provides. That makes it a lot easier to use than having to provide all those things yourself. I don't see anything wrong with having purpose-built frameworks on top of Play; in some cases it's probably a better solution than having to combine various different modules yourself.

 

What is the official timeline for Play 3?

We're working on the Play 3 timeline soon. We do have a 3.0 milestone on github and will be creating a transitional 2.6 release before 3.0. Lightbend will be providing more resources to the Play project this year so the actual dates may depend on when that happens. In any case, I suspect Play 3.0 is at least a year off, depending on what ultimately goes into it.

--

Greg Methvin

Senior Software Engineer

Lightbend, Inc.

[Rahul Gulabani]

Hello,

I am bit confused with Lagom .when we have akka http and akka clusters to build microservices why lagom.I actually promote lighband technology stack here in india but this time i am also confused .... 

Following is the way to use micro-service using akka framework.

https://tech.iheart.com/why-we-picked-akka-cluster-as-our-microservice-framework-bbf3019a3217#.5gzkwln59

What benefits it will provide over akka http microservices could you please explain in detail? 

Br/

Rahul

[Will Sargent]

> I am bit confused with Lagom .when we have akka http and akka clusters to build microservices why lagom.I actually promote lighband technology stack here in india but this time i am also confused .... 

Here's the description from http://developer.lightbend.com/guides/play-rest-api/index.html#microservices-vs-rest-apis

One thing to note here is that although this guide covers how to make a REST API in Play, it only covers Play itself and deploying Play. Building a REST API in Play does not automatically make it a “microservice” because it does not cover larger scale concerns about microservices such as ensuring resiliency, consistency, or monitoring.

For full scale microservices, you want Lagom, which builds on top of Play – a microservices framework for dealing with the “data on the outside” problem, set up with persistence and service APIs that ensure that the service always stays up and responsive even in the face of chaos monkeys and network partitions.

I recommend reading the "Data on the Outside" paper which discusses the problem of information transfer:

https://blog.acolyer.org/2016/09/13/data-on-the-outside-versus-data-on-the-inside/

And watching the video discussing the problem of dependent services:

https://vimeo.com/163760711

--

Will Sargent

Engineer, Lightbend, Inc.

will.s...@lightbend.com

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/80e5d09b-e273-4853-bf8d-1e51fa4b3659%40googlegroups.com.

[Ivano Pagano]

After having read documentation about the project, I feel pretty confident in saying that Lagom is the gluing and additional makeup to build a microservices architecture on top of play/akka technologies.

You could do it yourself but probably you're gonna face the same design choices done by Lagom and build yourself a similar machinery.

Lagom brings you a ready to use framework to build your own system by customizing what is necessary (i.e. the business logic)

Also lagom supports a specific distributed architecture out-of-the-box (CQRS-ES by default, Async Messaging if needed, json as communication protocol, ...) while letting you play with a limited number of toggles.

This means that it's not a one-size-fits-all solution. You can have specific requirement which couldn't possibly fit into the lagom design, and thus there's still a need for building custom systems from the components.

For everything else you can use lagom, being aware that the best expertise in developing distributed systems was applied there.

As an example, you get CircuitBreaker policy by default and transparently within lagom services, with no need to do anything.

I hope this shed some light into what Lagom brings to the table

Cheers

Ivano