refactor(akka): update config and refactor names

[DanielCliftonGuardian]

What is the value of this and can you measure success?

Part of Akka migration due to licensing changes (#8783)

Note: still using akka (instead of pekko) materializer from Play as both filters extend Play's Filter, so the types need to match

What does this change?

Updates config for akka to pekko as mentioned in the Pekko migration guide

Config names use “pekko” prefix instead of “akka”, e.g. pekko.actor.provider instead of akka.actor.provider

Also renames akkaAsync values to pekkoAsync to make it super clear it's using Pekko not Akka now.

This completes the work from #26582

Checklist

• Tested locally, and on CODE if necessary
• Will not break dotcom-rendering
• Will not break our database – if updating CAPI, updated and committed the database files
• Meets our accessibility standards
  • Tested with screen reader
  • Navigable with keyboard
  • Colour contrast passed

[ioannakok]

Looks great!! 💎 Just one clarification for a few akka related stuff I can still see in the codebase:

1. akka.stream.Materializer in
   • Filters
   • DevFilters
   • PreviewFilters

I remember from #26563 we don't need to migrate those, is that correct?

2. PlayAkkaHttpServer in ProjectSettings. Do we need to wait from the Play framework to migrate?

[DanielCliftonGuardian]

Looks great!! 💎 Just one clarification for a few akka related stuff I can still see in the codebase:

1. akka.stream.Materializer in

   • Filters
   • DevFilters
   • PreviewFilters

I remember from #26563 we don't need to migrate those, is that correct?

2. PlayAkkaHttpServer in ProjectSettings. Do we need to wait from the Play framework to migrate?

akka.stream.materializer is proving difficult as we are using it in all the filters and it extends

frontend/common/app/http/Filters.scala

Line 23 in e93bc21

class Gzipper(implicit val mat: Materializer) extends GzipFilter(new GzipperConfig)

which is built into play and uses akka and cannot mix the two. There is a draft PR though 0729726 But it sounds like we can use this from the migration doc. "The Additional Usage grant in Lightbend's BSL licence states: If you develop an application using a version of Play Framework that utilizes binary versions of akka-streams and its dependencies, you may use such binary versions of akka-streams and its dependencies in the development of your application only as they are incorporated into Play Framework and solely to implement the functionality provided by Play Framework; provided that, they are only used in the following way: Connecting to a Play Framework websocket and/or Play Framework request/response bodies for server and play-ws client."
2. Good spot. This seems to just be disabling the use of the PlayAkkaHttpServer as we use the PlayNettyServer so i think we want to leave this https://github.com/guardian/frontend/blob/e93bc211dc6dd2350e9c6bb5c591531afef32426/project/ProjectSettings.scala#L121C7-L121C42

[ioannakok]

Looks great!! 💎 Just one clarification for a few akka related stuff I can still see in the codebase:

1. akka.stream.Materializer in

   • Filters
   • DevFilters
   • PreviewFilters

I remember from #26563 we don't need to migrate those, is that correct?

2. PlayAkkaHttpServer in ProjectSettings. Do we need to wait from the Play framework to migrate?

akka.stream.materializer is proving difficult as we are using it in all the filters and it extends

frontend/common/app/http/Filters.scala

Line 23 in e93bc21

class Gzipper(implicit val mat: Materializer) extends GzipFilter(new GzipperConfig)

which is built into play and uses akka and cannot mix the two. There is a draft PR though 0729726 But it sounds like we can use this from the migration doc. "The Additional Usage grant in Lightbend's BSL licence states: If you develop an application using a version of Play Framework that utilizes binary versions of akka-streams and its dependencies, you may use such binary versions of akka-streams and its dependencies in the development of your application only as they are incorporated into Play Framework and solely to implement the functionality provided by Play Framework; provided that, they are only used in the following way: Connecting to a Play Framework websocket and/or Play Framework request/response bodies for server and play-ws client."
2. Good spot. This seems to just be disabling the use of the PlayAkkaHttpServer as we use the PlayNettyServer so i think we want to leave this https://github.com/guardian/frontend/blob/e93bc211dc6dd2350e9c6bb5c591531afef32426/project/ProjectSettings.scala#L121C7-L121C42

Thanks! Makes sense. Re the Materializer, perhaps you could add a similar comment.

Looks like both of this points will be addressed in Play 3.0.

Great work!

[prout-bot]

Seen on FRONTS-PROD (merged by @DanielCliftonGuardian 17 minutes and 59 seconds ago)

• Check your changes on www.theguardian.com ✔️
• Keep an eye on the deploy dashboard 📉

[prout-bot]

Seen on ADMIN-PROD (merged by @DanielCliftonGuardian 18 minutes and 7 seconds ago)

• Check your changes on www.theguardian.com ✔️
• Keep an eye on the deploy dashboard 📉

[mkurz]

See

• Switch to Play 3 and go all in on Pekko #26677

for migrating to Play 3 which comes with Pekko now.