Архитектура Web-приложений: обзор современных решений Руслан Шевченко О разных подходах к проектированию web-приложений и трендах в этой области, включая как и относительный мейнстрим, так и экзотические решения, которые могут быть интересны в будущем.

1. Web application architecure:
overview of techniques
Ruslan Shevchenko. <ruslan@shevchenko.kiev.ua>!
GoSave, Inc: http://www.gosave.com!

2. Themes
❖ What are current architecture patterns, which !
❖ can be used!
❖ can be reused ( in other languages or frameworks
than origin)!
!
❖ Client/Service interaction. !
❖ Reactivity

3. What is in mainstream now ?
❖ Sinatra-like frameworks!
❖ Server:!
❖ REST !
❖ Client: MVC!
❖ yesterday: backbone!
❖ today: angular!
❖ tommorow: react.js + sumthing

4. shiny
• http://shiny.rstudio.com/!
• live example: http://shiny.rstudio.com/gallery/telephones-by-region.html!
• R language!
• 8 LOC : server!
• 12 LOC: UI

5. shiny: UI.R
library(shiny)
library(datasets)
!
shinyUI(
fluidPage(
titlePanel("Telephones by region"),
sidebarLayout(
sidebarPanel(
selectInput("region", "Region:",
choices=colnames(WorldPhones)),
hr(),
helpText("Data from AT&T (1961) The World's Telephones.")
),
mainPanel(
plotOutput("phonePlot")
)
)
))

6. shiny: Server.R
library(shiny)
!
# Rely on the 'WorldPhones' dataset in the datasets
# package (which generally comes preloaded).
library(datasets)
!
shinyServer(function(input, output) {
output$phonePlot <- renderPlot({
barplot(WorldPhones[,input$region]*1000,
main=input$region,
ylab="Number of Telephones",
xlab="Year")
})
})

7. Shiny: notes
❖ DSL for HTML!
❖ Reactive!
❖ Websocket transport instead request/reply

8. Shiny: notes
❖ DSL for HTML!
❖ Reactive!
❖ Websocket transport instead request/reply
❖ Predefined UI skin (twitter bootstrap)!
❖ Narrow applicability

9. Conway law
Organizations which design systems ... are constrained to produce designs which
are copies of the communication structures of these organizations ……!
(Conway, 1968)!
Organization communication !
structure
Software structure
Shiny <=> existence of data analysis department

10. max. enterprise: Java
(Server-centric)!
❖ dropwizard: https://dropwizard.github.io/dropwizard/!
❖ spring: http://www.spring.io!
❖ J2EE %-)

11. max. enterprise: java
Relative good and applicable:
@Path(“/users”)
@GET
@Produces({MediaType.APPLICATION_JSON})
@ApiOperation(nickname = "getUsers",
value = "get list of users",
httpMethod = "GET",
response = UsersSortDTO.class,
responseContainer = “List")
public List<UserDTO> list(@ApiParam SelectorDTO selector) {
CriteriaQuery<UserDTO> = …
……….
return q.getResultList();
}

12. max. enterprise: java
Relative good and applicable:
❖ Jersey: https://jersey.java.net/!
❖ request bind to method.!
❖ routing is set via annotations.!
❖ Jackson: https://github.com/FasterXML/jackson!
❖ annotation-based json serializer with good defaults!
❖ Swagger: https://helloreverb.com/developers/swagger

13. Client/Server API issues.
REST - is not fit for all
What we do with operations, other than CRUD over resources ?
❖ RPC on some language on top of javascript [?]!
❖ adopt IDL protocol [?]!
❖ fix REST [?]
Ideal solution yet not exists….

14. Client/Server API: One Language
Many implementations
• Javascript (node.js) !
• ClojureScript/ Clojure: http://clojure.org/!
• Kotlin: http://kotlin-web-site.jetbrains.org/ !
• Scala (!
• scala.js [http://www.scala-js.org/], !
• jscala [ https://github.com/nau/jscala ] !
• R !
• etc …
❖ Conway law, !
❖ Not one ‘ideal’ language for all

15. Client/Server API: IDL
IDL == Interface Definition Language
struct ProfileInfo!
{!
1: required string uid;!
2: optional string firstName;!
3: optional string middleName;!
4: optional string lastName;!
5: optional string email;!
6: optional string phone;!
7: optional string addrPostal;!
}!
!
service SelfCare!
{!
ProfileInfo getProfileInfo(required string authToken)!
throws(OperationException)!
…………
Implementations:!
thrift: http://thrift.apache.org/!
RSDL, WADL (xml-based)

16. Client/Server: Fix REST
REST without PUT
RPC call = create event (i.e. POST /event )!
seqence of events instead PUT
CQRS = Command Query Responsibility
Events State
Query
rdonly

17. Client/Server: Streaming
Example: sparkle. https://github.com/mighdoll/sparkle
Visualization of data stream, !
coming from server via websocket transport
Server (scala)
Client (javascript)
Server -> Client : Data Stream, !
(reply to control messages)!
!
Client -> Server: Control messages!
(subscribe/unsubscribe/transform)

18. Reactivity: client.
Shiny: one circuit with client and server.
More common: client-only reactive interactions, !
REST/RPC with server
❖ Angular.js [2/way binding]!
❖ React.js [1/way binding] !
❖ (model => view)!
❖ OM: https://github.com/swannodette/om!
❖ RFP!
❖ backon.js [ http://baconjs.github.io/], RxJs!
❖ ELM (language) http://elm-lang.org!

19. Reactivity: client: Om
https://github.com/swannodette/om
Clojure!
!
!
Application state = Tree, bound to clojure atom!
!
UI component state = path inside application state!
!
Use React.js for updating UI from change in application state!

20. Reactivity: server
Reactivity on server - more about C10K !
• http://www.reactivemanifesto.org/!
• http://en.wikipedia.org/wiki/C10k_problem
No blocking ….!
event oriented …

21. Unreactive pseudocode: 1
def listUsers(r: Request): RequestResult =
listForm.bind(request){
!
success(form) => Ok (ToJson(
users.filter(_.name contains form.q).
page(form.offset,form.limit)
) ),
!
failure(f,message, ex) => Error(403, message)
!
}

22. Unreactive pseudocode: 1
def listUsers(r: Request): RequestResult =
listForm.bind(request){
!
success(form) => Ok (ToJson(
users.filter(_.name contains form.q).
page(form.offset,form.limit)
) ),
!
failure(f,message, ex) => Error(403, message)
!
}

23. Nonreactive: 1
Client Application Server Database

24. Nonreactive: 1 / overload
Client Application Server Database

25. Reactive code: 2
latest Play:
def listUsers = Action { request =>
listForm.bind(request){
!
success(form) => Ok (ToJson(
users.filter(_.name contains form.q).
page(form.offset,form.limit)
) ),
!
failure(f,message, ex) => Error(403, message)
!
}

26. Reactive code: 2
def listUsers = Action { request =>
listForm.bind(request){
!
success(form) => Ok (ToJson(
users.filter(_.name contains form.q).
page(form.offset,form.limit)
) ),
!
failure(f,message, ex) => Error(403, message)
!
}
callback
latest Play:

27. Non-reactive: 1 / overload
Client Application Server Database

28. Reactive: 2 / overload
Client Application Server Database

29. Reactive pseudocode: 3
Imagine, we have reactive db driver:
def listUsers = Action { request =>
listForm.bind(request){
!
success(form) => Ok (
db.query(
users.filter(_.name contains form.q).
page(form.offset,form.limit)
) map ( x => ToJson(x) )
),
!
failure(f,message, ex) => Error(403, message)
!
}
callback
callback

30. Reactive: 3 / overload
Client Application Server Database

31. Server: reactivity
• 2 callbacks instead sequential code!
• (welcome to callback hell ?)!
• functional programming is really needed!
• Infrastructure is not mature yet.!
• reactive-mongo, reactive-postgres,!
• but we have no reactivity suport in jdbc!

32. Server: reactivity
Other computation models:!
• Actors [Erlang, Scala Akka]!
• Channels [Go, Closure core.async]!
• Language reactive extensions!
• [RxNet, RxJava, RxScala]

33. Web architecture: overview of techniques
❖ Can’t say that we have some ‘Canonical ideal architecture’.!
❖ Non-ideal techniques are still interesting.!
❖ Invention/Reinvention cycle => !
❖ Hope we will see something new!
❖ Take care

34. Web architecture: overview of techniques
Thanks for attention.!
!
Ruslan Shevchenko, <ruslan@shevchenko.kiev.ua>!
https://github.com/rssh!
@rssh1!
//this talk was bought to you by GoSave: http://www.gosave.com ;)!