-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path60_conclusion.tex
executable file
·11 lines (7 loc) · 4.6 KB
/
60_conclusion.tex
1
2
3
4
5
6
7
8
9
10
11
\chapter{Conclusion and Future Development}
\label{lab:conclusion}
Developing event- and actor-driven applications still poses some difficulties. The purely thread-based concurrency model seems like a natural abstraction choice for developing Web server applications, but problems like blocking and context-switching overhead make event- and actor-based operations the better choice for most Web-typical use-cases. On the other hand, although event- and actor-based paradigms have existed for decades, they represent a significant departure from traditional thread-based programming and thus may seem a less attractive choice for developers. To approach this problem, modern Web frameworks and libraries offer simple abstractions for complex operations; these range from concurrency comprehensions to system-wide abstractions like completely hiding the underlying actor system, like the \textit{Play!} framework does. Many of these frameworks also offer thread-based processing, which further minimises the learning curve. \textit{Node.js} makes use of \textit{JavaScript} and its event-driven development paradigms, which are known to even less experienced Web developers.
Regardless of the technology used, when developing applications with a high amount of concurrency, close attention has to be paid to maintain a clear application structure. Modern Web frameworks and libraries often facilitate this process by offering simplifications and structural rules and guides. However, purely thread-based have the advantage of ordered execution, which results in a structural clarity that is hard to obtain with event- and actor driven development.
It can be concluded from the tests documented in chapter \ref{lab:eval} that asynchronous processing reduces response times for most Web server specific tasks like querying databases and caches as well as communicating with third-party Web services. However, most of these advantages come into effect only above a certain request frequency. Projects that tend to benefit the most from asynchronous processing are characterised by a high number of computationally inexpensive requests involving database or networking operations; a prominent example for this use-case are social networks, where a lot of users use the same platform simultaneously. For smaller projects like personal websites, on the other hand, purely thread-based applications may be the better choice since they can be developed with traditional paradigms in a widespread language like \textit{PHP}. Another use-case for thread-based applications are systems that focus on intensive on-system calculations at a high request frequency. Here, the best strategy may be to use a highly synchronous architecture and scaling out to multiple systems.
Especially with the uprise of more frameworks and libraries, event- and actor-driven paradigms currently are gaining popularity and importance. There is an initiative called the \textit{Reactive Manifesto}, which advocates asynchronous, non-blocking behaviour throughout Web applications, even including client applications \cite{reactive}. Many emerging as well as older technologies are adding asynchronous functionality in order to offer modern functionality. Such technologies include the asynchronous additions made to \textit{C\#}\footnote{\url{http://msdn.microsoft.com/en-us/vstudio/hh341490.aspx}} in version 5, the \textit{Grails} 2.3 events API and the \texttt{@Async} annotated methods in \textit{Spring MVC} 3 \cite{Syme1983} \cite{Ledbrook2013}. Another notable example is the \textit{Martini}\footnote{\url{http://martini.codegangsta.io/}} framework for the \textit{Go}\footnote{\url{http://golang.org/}} language, which uses extensive asynchronous processing featuring a concurrency model called \textit{Pipelines}.
Even though there are numerous new technologies, only few mature Web frameworks already make use of them, despite potentially large performance gains for exactly these systems. For instance, \textit{Node.js} has a shallow learning curve and exceptional performance and documentation, but lacks application structure and compile-time warnings. Many other frameworks that were taken into consideration for this thesis lacked either proper functionality or essential documentation. However, the high number of event- and actor-driven Web frameworks currently in early stages of development gives a positive outlook on the future progress of the subject. With demands and user numbers ever growing, the Web is merely at the beginning of reaching its full potential. Event- and actor-driven paradigms---if sufficiently embraced by Web developers---can play a major role in creating a fast, efficient Web for the future.