PLAY FRAMEWORK. Webnesday #5. Mirko Stocker Institut für Software Rapperswil, 13. Mai, 2015

Transkript

1 PLAY FRAMEWORK Webnesday #5 Mirko Stocker Institut für Software Rapperswil, 13. Mai, 2015

2 Mirko Stocker Wissenschaftlicher Mitarbeiter Application Architecture Cloud Solutions Parallele Programmierung User Interfaces appquest.hsr.ch Product Manager Eclipse Plug-ins für C++/Scala Forschungsprojekte InfoQ Editor Scala, Ruby Web-Entwicklung Consulting und Projekt-Begleitung github.com/misto facebook.com/misto ch.linkedin.com/in/misto Seite 2

3 Play Framework Seite 3

4 Warum Play? JVM, aber kein JEE/Servlet HTTP Interface, non-blocking I/O Typsicherheit: Templates, URLs Entwicklungszyklus: Edit -> Refresh Seite 4

5 Grundlagen des Webs HTTP Reload Back URLs Seite 5

6 Grundlagen des Webs Bezogen auf Play HTTP nicht verstecken Reload Stateless URLs sprechen Stateless: Der Back-Button funktioniert HTTP ist nicht nur ein Transport für RPC (REST Maturity Model) URLs sollten sprechen (Level 1, Links zu verschiedenen Ressourcen) Reload: Als Entwickler will ich Änderungen sofort sehen Seite 6

7 Play ist Stateless Kein Zustand im Applikations Tier Im Unterschied zu Java Servlet HttpSession Zustand ist also eine Kombination aus Client Session State Database Session State Vorteile Einfach horizontal skalierbar, da egal ist, welche Instanz einen Request behandelt (Cloud-Ready) Kein Synchronisationsaufwand in der Applikation Entwicklung und Test vereinfacht, da Verhalten reproduzierbar ist Seite 8

8 Play macht dem Entwickler Spass Play kommt ohne Applikationsserver aus Basiert auf Netty Kann aber auch als WAR deployed werden Kein Deployment während der Entwicklung Beim Reload werden die geänderten Klassen und Templates neu kompiliert und geladen Gute Fehlermeldungen direkt im Browser Gute Unterstützung von Unit, Functional und Integration Testing Sehr guter JSON und JavaScript Support JSON Parsen, Manipulieren und Generieren Webjars Support und Require-JS eingebaut Minimization, LESS/CoffeeScript Compilation, etc. Seite 9

9 Play macht dem Entwickler Spass Seite 10

10 Play Komponenten Template Engine Integrierter Webserver (Netty) HTTP Interface Asset Compilation Webservices API Async I/O Interaktives Buildsystem und Projekttemplates HTML Form Validation JSON Akka Actors Diverse (NO-) SQL Anbindungen Seite 11

11 Play User Seite 12 Olaf Zimmermann, Mirko Stocker 2014

12 Neues Play Projekt Erstellen Play wird von Typesafe (Scala, Akka) entwickelt Neue Play Projekte erstellt man am einfachsten mit dem Activator Activator: Build-Tool und Projekt-Generator von Typesafe Enthält diverse Beispielprojekte und Templates Seite 13

13 Neues Play Projekt Erstellen Verfügbare Templates auflisten./activator list-templates Neues Projekt aus Template play-java erstellen./activator new my-play-java play-java Browser-basiertes UI starten./activator ui Interaktives CLI starten./activator Eclipse Projekt erstellen./activator eclipse Im Projektordner IntelliJ IDEA Projekt erstellen./activator idea Seite 14

14 Projektlayout Sourcecode Buildfile Static Assets Tests activator app controllers Application.java views index.scala.html main.scala.html build.sbt conf application.conf routes logs application.log public images favicon.png javascripts hello.js stylesheets main.css test ApplicationTest.java IntegrationTest.java Seite 15

15 MVC in Play MVC Pattern lässt sich aus der Projektstruktur erahnen: app controllers Application.java views index.scala.html main.scala.html Controller Model View Models sind typischerweise im app/models Ordner zu finden Seite 16

16 URLs und Routing in Play Sprechende URLs sehen nicht nur schöner aus sie sind auch stabiler wir können sie Bookmarken, Twittern und als Entwickler auch direkt manipulieren URLs in Play sind first class Citizens (und nicht bloss Strings) Compiler prüft Verwendung Interne tote Links sind nicht möglich Alle URLs werden in conf/routes zentral deklariert GET / controllers.application.index GET /computers controllers.application.list GET /computers/new controllers.application.create POST /computers controllers.application.save GET /computers/:id controllers.application.edit(id:long) POST /computers/:id controllers.application.update(id:long) Klasse.Methode Seite 17

17 Controller: Actions Ein (Page) Controller behandelt die eingehenden Requests Controller ist eine Sammlung von Actions package controllers; import play.*; import play.mvc.*; public class Application extends Controller { } public static Result index() { return ok("it works!"); } % GET -s ' 200 OK It works!% Seite 18

18 Controller: Actions Der Play Router mappt die URLs zu den Controller Methoden GET / controllers.application.index() GET /assets/*file controllers.assets.at(path="/public", file) Vordefinierte Hilfsmethoden für gängige HTTP Status Codes Beispielsweise auch für Redirects public static Result index() { return redirect(routes.application.index()); } % GET -e ' 303 See Other Location: / Seite 19

19 Controller: Routing Verschiedenste URL Pattern möglich GET /computers/:id controllers.app.edit(id: Long) GET /computers/search controllers.app.search(query: String) GET /computers controllers.app.list(page: Int?= 1) GET /computers controllers.app.show(page: Page) Eigene Entsprechen Methoden-Parameter und müssen nicht selber geparsed werden (sogar mit eigenen Klassen): public static Result edit(long id) { } public static Result search(string query) { } public static Result list(int page) { } public static Result show(page page) { } Klasse Seite 20

20 Controller: Routing prüft Parameter % GET -e ' 400 Bad Request Seite 21

21 JSON im Request public static Result sayhello() { JsonNode json = request().body().asjson(); String name = json.findpath("name").textvalue(); if(name == null) { return badrequest("missing parameter [name]"); } else { return ok("hello " + name); } } Jackson % curl --header "Content-type: application/json" --request POST --data '{"name": "HSR"}' HTTP/ OK Content-Type: text/plain; charset=utf-8 Content-Length: 9 Hello HSR Seite 28

22 JSON im Request Body Scala case class Named(name: String) def sayhello() = Action(parse.json[Named]) { request => val named = request.body // named hat Typ Named Ok(s"Hello ${named.name}") } % curl --header "Content-type: application/json" --request POST --data '{"name": "HSR"}' HTTP/ OK Content-Type: text/plain; charset=utf-8 Content-Length: 9 Hello HSR Bad Request wenn fehlt Generiert JSON Parser Seite 29

23 JSON als Result JSON erstellen public static Result sayhello() { ObjectNode result = Json.newObject(); result.put("message", "Hello Webnesday!"); return ok(result); } ok() ist überladen und setzt automatisch den richtigen Content-Type % curl --request GET HTTP/ OK Content-Type: application/json; charset=utf-8 {"message":"hello Webnesday!"} Seite 30

24 Models Typischerweise POJOs in app/models Play ist nicht auf einen spezifischen OR-Mapper festgelegt JPA, JDBC, etc. Auf der Scala Seite auch Anorm und Slick (ähnlich wie MS LINQ) Beispiel mit public static Result list() { EntityManager em = play.db.jpa.jpa.em(); TypedQuery<Computer> query = em.createquery( ) Collection<Computers> computers = query.getresultlist(); return ok(views.html.application.index.render(user, computers)); } Seite 31

25 Non-Blocking I/O Seite 32 Olaf Zimmermann, Mirko Stocker 2014

26 Das Problem mit Threads Threads sind teuer in der Erstellung Lösung: Wiederverwenden, Threadpool verwenden Wie gross soll der Threadpool sein? Aus CPU-Sicht: Ein Thread / Core Zu gross Memory-Overhead Context-Switching Zu klein Abhängigkeit von Downstream-Latenz Requests blockieren wenn keine Threads mehr vorhanden sind Lösung: Keine Threads blockieren! Ein Thread / Core dauernd beschäftigt Non-Blocking I/O (NIO in Java, select / poll / epoll) Seite 33 Olaf Zimmermann, Mirko Stocker 2014

27 Latenz in einem verteilten System mit Blocking DB Backend Service S3 Load Balancer Web Server Backend Service DB DB DB Latenz geht hoch Web Server Backend Service 3rd Party Service Seite 34 Olaf Zimmermann, Mirko Stocker 2014

28 Latenz in einem verteilten System mit Blocking Threads werden «gestaut» DB Load Balancer Web Server Web Server Backend Service Backend Service Backend Service S3 DB DB 3rd Party Service Seite 35 Olaf Zimmermann, Mirko Stocker 2014

29 Evented vs. Threaded Web Server Play basiert auf Netty, einem evented Web Server Traditionell sind Web Server eher Thread based: pro Request ein Thread Event basierend: Pro CPU ein Thread, Threads werden nicht blockiert. Auch asynchron oder non-blocking genannt Siehe auch Reactor Pattern (Pattern Oriented Software Architecture 2) Sobald bei der Bearbeitung des Requests auf eine downstream Datenquelle (WS, DB) gewartet werden muss, wird der Thread freigeben und ein Callback registriert Event-based skaliert besser bei vielen Requests Thread ist nur besetzt, wenn es etwas zu tun gibt Unabhängigkeit von der Downstream Latenz Seite 36

30 Non-Blocking Web Services Controller Action in Play kann auch ein Promise<Result> zurückgeben Promise: analog zu Future (Proxy Objekt für ein zukünftiges Resultat) Aufruf der Action beendet so schnell wie möglich Thread wird für nächsten Request frei Resultat wird ausgeliefert, wenn die Berechnung fertig ist public static Promise<Result> longrunningaction() { System.out.println("Action entry"); String url = " } Promise<Result> result = WS.url(url).get().map(response -> { System.out.println("Processing result"); return ok(response.getbody()).as("text/html"); }); System.out.println("Action exit"); return result; Action entry Action exit Processing result Seite 37

31 Play Zusammenfassung Play ist eine leichtgewichtige moderne Alternative für Java Web Stateless, RESTful (Cloud-Ready) Embrace HTTP, nicht verstecken und wegabstrahieren Schneller Entwicklungszyklus, kein langwieriges Deployment Non-blocking und evented, läuft auf Netty Intern in Scala geschrieben, mit Java und Scala API Typsicher: Routing, URLs und Templates LESS, CoffeeScript, React, etc. unterstützt im Buildsystem JSON, Websockets, SSE Support Seite 38

32 Danke für eure Aufmerksamkeit! Seite 39 Olaf Zimmermann, Mirko Stocker 2014