00:00:12.160
I’m going to talk today about Waves, which started out as an attempt to move beyond the MVC box and experiment with more of an architectural framework rather than an application framework. Some of you who were at the initial LA Ruby group meetings may remember that I provided a brief overview last summer. We had just come out of a deep and dark cavern of refactoring, and it was our first tentative attempt to present what we had developed following some initial feedback after a release, which included a fair amount of progress. The foundation for Waves seems to be quite solid now. I gave a talk at the national Ruby conference on Waves, and since that time, we haven't had any significant resets or rethinks. In this talk, I will focus more on some questions I have frequently been asked about Waves.
00:01:06.640
Thanks to Kobe, that previous talk is available on the Concrete website. Instead of rehashing what I discussed there, I want to address a recurring question I've encountered: 'Why wouldn’t I just use Rails?' The answer is that if you find yourself painting outside the MVC lines, Rails may not be the right fit for your applications. It can help if you need to do something a bit unconventional, which leads to another question: 'Isn’t that similar to what Rack does?' Indeed, there is a lot of synergy between Rack and Waves, but Waves adds extensive support beyond the basics of handling an HTTP request, which is typically found in frameworks. In fact, there is an MVC layer in Waves that showcases its richness.
00:02:00.159
So, the next question is, if Waves is somewhat of a layer on top of Rack that defines application frameworks, what about resource-oriented architecture? It helps developers write more RESTful applications. While MVC frameworks do provide some support for this, they inherently encapsulate much of what HTTP does under the covers, often making it a bit challenging to access all the HTTP functionality—though it is possible, it may not feel natural. A common question that comes next is: 'Why do I really need REST? If my MVC framework is working well for me, why bother with REST, especially since it often comes with its own constraints?' I will attempt to address that question in this talk and discuss how Waves addresses these concerns while also reflecting on the larger picture of what REST can provide.
00:02:48.000
First, let me introduce myself. I’m Dan Yoder, Director of Development in R&D at AT&T Interactive. I have been doing software development for about 20 years, primarily working with Ruby, which I was introduced to back in 2005 with the emergence of Rails. Our team at AT&T Interactive has developed numerous gems, most of which are offshoots of Waves. Additionally, we have released several applications, including a restroom locator app for iPhone, along with other search utilities all powered by Waves. This background provides context on my perspective.
00:03:45.760
To understand resource-oriented architecture and its significance to Waves, it's helpful to recognize an often-overlooked fact about the web: it is arguably the most successful distributed computing architecture ever. The web is capable of scaling; it accommodates millions of clients and servers of various types, from web browsers to RSS readers to Adobe AIR applications, all powered by open standards. Importantly, the web is an open platform that isn’t reliant on any single vendor, unlike many previous distributed computing systems, which were often hampered by tight vendor control and political maneuvering. Additionally, the web's infrastructure, which includes proxies and load balancers, allows us to offload many logic processes that would typically be required in our own applications. These capabilities make the network more intelligent and allow us to leverage existing infrastructure when building new clients or servers.
00:05:58.399
In my discussions with colleagues, there is often a need for a custom application protocol, which leads some to assume a simple TCP or UDP method might suffice. However, this misses out on the advantages of using HTTP, especially if the application is likely to have a future beyond immediate use. We have a wealth of infrastructure available that can facilitate load balancing and other scaling mechanisms. The benefits provided by this distributed architecture are sometimes underestimated, yet they provide significant value, including better performance through caching strategies and automated handling of protocol separation.
00:07:05.920
The success of web-based systems revolves around the constraints defined by REST architecture. Notably, REST is at the core of Fielding’s dissertation, and his name appears prominently among those who contributed to the initial HTTP specification. To understand what REST is truly striving to achieve, we must recognize and apply these constraints to our web applications. By adhering to these principles, we can foster the same emergent characteristics found in the web’s successful structure.
00:08:41.920
Despite the web’s success, the idea of leveraging it effectively hasn’t been widely realized. Oftentimes, developers continue to use MVC structures, which utilize web browsers as applications and overlook the potential benefits of an environment built on robust REST principles. This has led to a plethora of applications embedded in web document objects, which may restrict the application’s potential. Furthermore, there is sometimes a debate whether such rich internet applications truly belong in the browser environment or if they should instead employ systems like Adobe AIR to avoid browser limitations.
00:10:09.080
Let me give you a couple of examples of how we can perceive the advantages of breaking out of the browser environment. For instance, take RSS feeds. The whole idea behind RDF encapsulates how to access specific feeds, allowing users to retrieve data without needing to scrape HTML from individual blogs, while providing richer metadata and representation. This paradigm has inadvertently led to the growth of podcasting systems, where the principles of resource representation really shine. Another example, albeit less developed, relates to how OAuth can facilitate cooperation between sites. With OAuth, one site can request permission from another to access specific information. Instead of implementing this separately for each application, a smart proxy could handle the OAuth management, thus efficiently centralizing the authorization process.
00:11:34.080
Additionally, consider the use of edge caching for intensive computational operations. While it may not seem intuitive to push computationally heavy tasks to the edge, doing so can improve efficiency significantly, enabling better performance across the board. More importantly, principles of REST emphasize efficient and effective data retrieval mechanisms, and by employing these principles, we can guarantee maximum performance benefits.
00:12:53.839
Ultimately, we must revisit the central question: why does REST work effectively within distributed object systems? My proposal is that the constraints outlined by REST represent the necessary foundation upon which a robust distributed object system can thrive. Historical attempts at establishing distributed architectures have often failed due to inflexible formats and tightly coupled systems. In contrast, HTTP and its principles were designed to learn from past failures, thus promoting a framework that adapts gracefully to technological evolution without enforcing strict rules that limit future growth.
00:14:17.680
We see that what REST encourages is a focus on the object-oriented approach where resources can be treated generically. This not only allows an open approach to resource representation and communication but promotes scalability and adaptability, key characteristics of successful architecture. By employing a uniform and stateless interface, we free ourselves from the constraints of traditional tightly coupled systems, paving the way for innovative and efficient solutions.
00:15:00.640
Waves aims to address the increasing desire to move beyond the confines of traditional web browsers and is designed to empower developers to take further control over the communication between clients and servers. I will outline a few highlights of Waves in relation to resource-oriented architecture, emphasizing the significant advancements we’ve made. One key feature is the Domain-Specific Language (DSL) that allows for a more natural articulation of HTTP requests beyond simple URL constructs, enabling intricate query management based on various parameters.
00:16:24.080
The DSL in Waves facilitates handling HTTP requests without getting bogged down exclusively in URL patterns, allowing us to dynamically match requests based on a wider array of parameters and expectations. Each element of the system remains compliant with the standard methods one would expect in resource-based architectures—GET, POST, PUT, DELETE, etc., while providing a Ruby-centric interface to streamline interaction through code snippets rather than verbose declarations.
00:17:57.919
The design pulls inspiration from frameworks like Sinatra, aiming to provide an efficient, lightweight system for building applications that require effective resource handling in a RESTful manner. We want developers to experience the ease of starting small and building upwards, rather than being overwhelmed by complexity right out of the gate. As we evolve, our goal is to articulate a more complete REST DSL, moving beyond matching requests to comprehensively describe resources to better represent the needs of developers and the applications they wish to create.
00:19:18.960
To that end, we’re focusing on defining resources independent of their representations, echoing a core tenet of REST-based architecture. The concepts we're gravitating toward emphasize the separation of resource and representation, allowing for a clearer structure regarding caching policies and broadening opportunities for diverse resource types—all critical for a seamless user experience while adhering to REST principles. As we develop this vision, we're keen to expand the community discussion around these innovations and welcome contributions from others who share interest.
00:20:47.600
I’d like to express gratitude towards my colleagues who have contributed significantly to Waves. Roberto and aerial cenakari deserve mention, as do Pete Elmore (aka Matthew King) and many others who have diligently worked to refine and advance Waves over the past months. Their hard work is paving the way for a vibrant software landscape that takes full advantage of resource-oriented architecture, and we hope others will also join us in this pursuit.
00:21:57.360
As we conclude, I encourage anyone with thoughts or ideas regarding resource-oriented architecture to share them. We continue striving for better integration and understanding of these principles in Ruby frameworks, and your insights would be invaluable for driving meaningful collaborative efforts. Thank you for your time, and I hope this discussion inspires innovative approaches to application development.
