Startpagina van Playzegt:
Play is gebouwd op Akka en biedt voorspelbaar en minimaal bronnenverbruik (CPU, geheugen, threads) voor zeer schaalbare toepassingen.
Ik wil precies weten hoe en waar Akka in Play wordt gebruikt en wat de gevolgen zijn als Play bovenop Akka wordt gebouwd.
Antwoord 1, autoriteit 100%
In Play 2.0delegeerde Play alle verzoeken om via een acteur te gaan. Het was sterk afhankelijk van Akka’s toekomstige API en andere onderdelen.
In Play 2.1, met de verhuizing van Akka’s toekomstige API naar Scala 2.10, begon Play minder direct afhankelijk te zijn van Akka. Het haalt al zijn uitvoeringscontexten van Akka en biedt integratie met Akka, maar dat is ongeveer de omvang ervan.
In Play 2.3voegen we nieuwe functies toe om Akka-integratie te vergemakkelijken, met name rond WebSockets.
In Play 2.4wordt Play geport naar de nieuwe akka-http (voorheen bekend als spray), waarna Play zo veel mogelijk op Akka is gebouwd.
Wat zijn de gevolgen? Akka biedt een paradigma voor programmeren dat concurrency eenvoudig maakt om mee om te gaan. Het biedt ook geweldige abstracties voor gedistribueerd programmeren – het moeilijkste aan gedistribueerd programmeren is om op de juiste manier om te gaan met fouten (die de hele tijd gebeuren). De meeste tools proberen dit aan te pakken door te proberen mislukkingen voor je te verbergen, maar helaas zorgt het verbergen van iets ervoor dat het niet verdwijnt, en maakt het de zaken zelfs echt moeilijker, want wanneer je specifieke soorten fouten probeert aan te pakken, is het feit dat ze verborgen zijn van jou staat je in de weg. Akka duwt fouten in je gezicht, zodat je bij het coderen gedwongen wordt na te denken over hoe je applicatie op fouten zal reageren. Je bent dus genoodzaakt om je applicatie zo te ontwerpen/coderen dat deze tolerant is voor fouten. Het geeft je ook de tools om er op een hiërarchische manier mee om te gaan, zodat je kunt specificeren op welk niveau je welk type storing wilt aanpakken en hoe op de storing moet worden gereageerd (sterven, tot n keer opnieuw proberen, enz.) .
Dus hoe helpt dit Play? De betere vraag is hoe het een Play-gebruiker helpt? Akka helpt me om Play zelf te implementeren, maar het is mogelijk om het te implementeren zonder Akka (in feite doet Netty nu het meeste zware werk, dat zal in Play 2.4 veranderen). Het belangrijkste is dat Play naadloos integreert met Akka, waardoor het gemakkelijk is om HTTP-verzoeken met actoren af te handelen, storingen af te handelen enz. Dit helpt Play-gebruikers omdat het hen in staat stelt hun applicatie zo te ontwerpen dat deze schaalbaar en veerkrachtig is.
UPDATE:Bovenstaande is 3 jaar geleden geschreven, sindsdien is er veel veranderd. Play 2.4 bood wel experimentele ondersteuning voor akka-http, maar Play gebruikt nog steeds standaard Netty.
In Play 2.5hebben we de herhaalde API beëindigd en zijn we overgestapt op Akka-streams. Dit betekende dat nu alle asynchrone IO door Akka-streams ging. Binnenkort (niet zeker of dat Play 2.6 of hoger zal zijn), zal Play de schakelaar omdraaien om akka-http de standaard backing-implementatie van de server te maken (hoewel nog niet de WS-client).
UPDATE 2:Play 2.6maakt nu akka-http de standaard backend-implementatie van zijn HTTP-server (Netty is nog steeds beschikbaar als optie).