play framework
Post on 07-Jul-2015
136 Views
Preview:
DESCRIPTION
TRANSCRIPT
Play! FrameworkEduard Tudenhöfner
Outline
● Getting Started● Error Handling● Threaded vs Evented● Async Features● Demo● Summary
Outline
● Getting Started● Error Handling● Threaded vs Evented● Async Features● Demo● Summary
Overview
● MVC Pattern● Java & Scala API● Stateless● Built on Akka
Play Console
● play new my-app
● play compile | run | test | debug
● play clean-all
● play eclipse | idea
Application Layout
HTTP Routing
● URI to Controller mapping
GET /projects/:projectId/tasks controllers.Tasks.index(projectId: Long)
POST /projects/:projectId/tasks controllers.Tasks.add(projectId: Long, folder: String)
PUT /tasks/:task controllers.Tasks.update(task: Long)
DELETE /tasks/:task controllers.Tasks.delete(task: Long)
● pattern: <HTTP Method> <URI> <Controller>
State in Play!
● server is stateless● state is stored on client● session and flash scopes
○ for data that is required between subsequent HTTP requests
○ cookie (max 4KB per User / only string values)
Important: The flash scope should only be used to transport success/error messages on simple non-Ajax applications. As the data are just kept for the next request and because there are no guarantees to ensure the request order in a complex Web application, the Flash scope is subject to race conditions.
Model
● POJOs with generated getters/setters● Play uses Active Record pattern● EBean -> default ORM (JPA without
container)
Testing Support
● play test● Helper classes to mock and fake almost
everything● provides support for Selenium &
FluentLenium
Testing Support
Testing Support
Outline
● Getting Started● Error Handling● Threaded vs Evented● Async Features● Demo● Summary
Error Handling
Error Handling
● Big Plus: detailed error messages shown in browser -> no need to search log files
● errors can be in ○ Java/Scala class○ Routes config○ template code○ ….
Error Handling
Error Handling
Outline
● Getting Started● Error Handling● Threaded vs Evented● Async Features● Demo● Summary
Threaded
Threaded
● one thread assigned to each request● any I/O is typically synchronous● problems that might arise?
○ thread pool sizing -> too many/too few?!○ Thread stack size with 64 Bit JVMs -> 1MB○ thread might get blocked, waiting for another
service to complete
Evented
Evented
● one thread per CPU core● basic idea: ensure that these scarce
resources are never blocked● I/O is asynchronous● blocking I/O mostly when talking to DBs
Outline
● Getting Started● Error Handling● Threaded vs Evented● Async Features● Demo● Summary
Async Features
● idea: never block● Play actions are async by default!● Controllers return Result objects● when async, return Promise<Result>
○ client is blocked - server is not blocked and serves result when it’s computed
Note: Whether the action code returns a Result or a Promise<Result>, both kinds of returned object are handled internally in the same way. There is a single kind of Action, which is asynchronous, and not two kinds (a synchronous one and an asynchronous one). Returning a Promise is a technique for writing non-blocking code.
Async Features
Outline
● Getting Started● Error Handling● Threaded vs Evented● Async Features● Demo● Summary
Outline
● Getting Started● Error Handling● Threaded vs Evented● Async Features● Demo● Summary
Summary
● High Developer Productivity○ make a change -> refresh -> see the change○ hot reload for all resources
● Built-in testing support
● Predictable Scalability○ adheres to HTTP principles○ non-blocking I/O support
● Commercial Support available through Typesafe & Zenexity
● Typesafe○ makes it easier for large code bases
Summary
● Immature○ Best Practices aren’t well defined○ API is changing○ Play 2 was entirely rewritten
● Not a Servlet○ breaks away from the Servlet spec
● Build System (SBT)○ hard to understand (even for Scala experts)○ very powerful & flexible, but very steep learning curve
Thank you! - Questions?
top related