Reloading on request vs change detected

[Ben McCann]

I've noticed that Lagom has a different reloading behavior than Play. Play reloads after a change has been made when a request comes in. Lagom reloads as soon as a change is detected.

Would it make sense for Play to adopt Lagom's reloading behavior or is there a reason we should keep them different form each other?

Thanks,

Ben

[Rich Dougherty]

The difference is probably historical. I think you can do ~run in Play to change it from a lazy recompile to an eager one like Lagom.

My personal ideal would be something more complicated that gives me the latest version of the code with minimal waiting.

- eager compile when changes detected

- on page reload, if build in progress, either wait for it if it is compiling the latest code or interrupt it and compile again if have been more changes since it started compiling (I get annoyed waiting for an out-of-date build to complete)

Cheers

Rich

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rich Dougherty

Engineer, Lightbend, Inc

@richdougherty

[Ben McCann]

Copying James's response to the mailing list for posterity and to share with everyone

Play does what it does for historical reasons.  Plus, for web development, personally I've always preferred Play's approach, I don't want my machine recompiling every time I save, I just want it recompiling when I hit refresh in the browser.

Lagom does what it does because microservices are not websites.  Some microservices might just do messaging, and never receive an HTTP request.  If they only recompiled/reloaded when they received an HTTP request, then those services would never recompile/reload.  So Lagom doesn't have the luxury of making the same assumptions Play does.

 

> Lagom could theoretically reload when it receives any request though, right? Not just an HTTP request. I'm not sure which way would be preferred though

Theoretically, yes.  In practice, it will be hard, for example reloading mid stream in akka-streams-kafka I think would be very difficult, it would require a significantly different architecture, where the akka-streams-kafka was run in a separate actor system that didn't get reloaded when the app reloads.  Another thing to consider is that asynchronous microservices often have their own background timers that schedule things periodically, like online-auction has a timer that checks for finished auctions every 10 seconds. Hooking reloading into this would be very difficult.

On Wed, Mar 29, 2017 at 12:58 PM, Rich Dougherty <ri...@rd.gen.nz> wrote:

The difference is probably historical. I think you can do ~run in Play to change it from a lazy recompile to an eager one like Lagom.

My personal ideal would be something more complicated that gives me the latest version of the code with minimal waiting.

- eager compile when changes detected

- on page reload, if build in progress, either wait for it if it is compiling the latest code or interrupt it and compile again if have been more changes since it started compiling (I get annoyed waiting for an out-of-date build to complete)

Cheers

Rich

On Thu, Mar 30, 2017 at 5:23 AM, Ben McCann <b...@benmccann.com> wrote:

I've noticed that Lagom has a different reloading behavior than Play. Play reloads after a change has been made when a request comes in. Lagom reloads as soon as a change is detected.

Would it make sense for Play to adopt Lagom's reloading behavior or is there a reason we should keep them different form each other?

Thanks,

Ben

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich Dougherty

Engineer, Lightbend, Inc

@richdougherty