Rack

Summarized using AI

One Ruby App to Rule Them All

Ian Hunter • April 07, 2011 • Earth

In the presentation titled "One Ruby App to Rule Them All," Ian Hunter discusses creating a robust web application using Ruby, emphasizing a multi-purpose architecture. His motivation stems from the need to develop an operational application for his company in a limited timeframe of two and a half weeks, alongside his experiences from a soft launch at South by Southwest. Ian introduces a technical stack that comprises significant Ruby frameworks and libraries, specifically: Rack, Sinatra, Padrino, Grape, and ZMQ for messaging.

Key Points Discussed:

  • Technological Stack Overview:

    • Rack: Acts as a thin layer crucial for Ruby applications.
    • Sinatra: A minimalistic gem built on Rack, known for its clarity and semantic structure.
    • Padrino: A framework that extends Sinatra to include a larger web stack.
    • Grape: A fast API layer inspired by Sinatra, supporting multiple formats.
    • ZMQ: A high-performance messaging library simplifying messaging complexities.
  • Architecture Setup:

    • Ian explains how to bundle these technologies together, starting with Rack as the interface.
    • He opts for Rails examples, despite his preference for Padrino, to ensure relevance to the audience.
    • Rack Cascade: An approach that allows for managing multiple applications by sequencing them and generating appropriate responses.
  • Authentication Management:

    • The presentation included code for setting up Rack session cookies to manage sessions across applications using authentication from Twitter and Facebook.
    • Shared modules were created for maintaining organized session management code while implementing OAuth path mappings for login and controlling specific providers effectively.
  • EventMachine and WebSocket Implementation:

    • Discussed setting up EventMachine and DripDrop for handling server interactions; emphasizes the need for understanding WebSocket server configurations and the potential deployment on Heroku using a YAML file.

Conclusion/Takeaways:

  • Ian Hunter's talk highlights the efficiencies gained by using a consolidated Ruby application architecture, addressing quick setup needs in a practical environment.
  • The session illustrates a modern approach to web app development that integrates multiple technologies seamlessly and encourages developers interested in complementary Ruby frameworks to embrace this architecture.
  • Ian concludes by promoting his startup in San Francisco, looking for Rails programmers, and acknowledges the supportive community and valuable interactions during his talk.

One Ruby App to Rule Them All
Ian Hunter • April 07, 2011 • Earth

Single Project, Multi Purpose Enterprise Applications come in multiple flavors these days: Rails, Sinatra, Grape, ZMQ.

Let's explore a multi-site mulit-purpose single project architecture which serves all aspects of an enterprise design, heavily seated in RACK. Special attention to Rails, Sinatra, Grape, Rack and ZMQ/EventMachine/ZMQMachine/DripDrop.

Help us caption & translate this video!

http://amara.org/v/GZC9/

Ruby on Ales 2011

00:00:11.840 Thank you.
00:00:21.619 Our first speaker today is Ian Hunter.
00:00:26.180 By night, Ian Hunter works as Henchman number 16 for a famous supervillain.
00:00:28.619 That supervillain is the Monarch.
00:00:36.840 By day, rather than taking over the world for someone else, Ian uses Ruby to take over the world for himself.
00:00:41.700 Today, he's going to talk to us about 'One Ruby App to Rule Them All'.
00:00:50.100 I guess we're about five minutes early, but that's all right. Welcome, Ian!
00:01:03.120 This is the best opening to a conference I've ever seen.
00:01:08.520 Good day! Let’s talk about what’s natural in Ruby.
00:01:17.700 My motivation for this presentation is that we need to build a fully functioning web application for my company in about two and a half weeks. Did everyone hear me?
00:01:32.580 We soft-launched at South by Southwest, which was another interesting experience. It was more or less an exercise for the Rattlers.
00:01:42.720 This is not an argument against multi-app architectures; it's just about how quickly we can organize things.
00:01:53.939 So, I’m dcnot Twitter, um.
00:02:08.220 I'm also a nomad. I didn’t really have a home anymore. I'm just circulating around thanks to people who put me up.
00:02:21.900 Today’s talk itinerary involves putting together a quick basic Rack application, incorporating an API layer with Grape, adding some authentication, and then doing some CMQ messaging.
00:02:43.140 I’ll start with the technology stack for this, which consists of Sinatra, Padrino, Grape, and Rack, with ZMQ for messaging.
00:02:50.879 To give a quick overview for those who may not know, Sinatra is a really sweet gem built on top of Rack. It’s very clear and semantic. Padrino is built on Sinatra and has more of the web stack.
00:03:07.980 Grape is an API layer inspired by Sinatra. It is written to be fast and supports multiple formats and resource definitions.
00:03:29.400 ZMQ is a high-performance messaging library. It abstracts the complexities of messaging into a simple interface.
00:03:36.600 So how do we bundle all of this together? Initially, we have Rack as our interface. Is it Rails 2-2 or 2-3? That’s probably wrong, but we ended up with Rack.
00:03:50.760 Getting started, I personally prefer Padrino at this point, but I know this is a Rails conference. Thus, all my examples are in Rails.
00:04:03.060 For those who don’t spend enough time in this space, Rack is the kind of thin layer you need for Ruby. For Rails, this is pretty basic.
00:04:25.199 So, let me introduce a quick overview of Cascade. Rack Cascade allows you to deal with multiple applications by sequencing them and returning the appropriate responses.
00:04:46.080 Here's a quick sample skeleton for Grape. One of the nice features is versioning, as it prefixes all your requests with the version you want to use.
00:05:05.220 Speaking of resources in Grape, if you send in a hash depending on the format, it will process based on that format. So, this has been a point of debate for me: how to share sessions across applications.
00:05:32.100 The key is to set up Rack session cookies. There are modifications required in Rails session management. It's important to use the right reactive approaches for this to work properly.
00:06:01.020 You add on a Supreme quarterback session cookie, using Rack to manage session tracking across the applications. Here, I’m using Twitter and Facebook authentication and there are many other options out there.
00:06:14.540 So we’re augmenting our CBI by creating a shared module where we can keep all of our login session management code.
00:06:21.180 You can see that in our controller where we include the Azure module, which we wrap in Grape helpers to maintain organization.
00:06:39.460 Overall, it's pretty similar to what you might get out of the box, although with a different setup depending on your application.
00:07:00.420 For those session hooks, we're utilizing a common pattern that allows you to map out your OAuth paths to integrate with various providers.
00:07:15.720 You essentially specify the login path and the specific provider link, ensuring you define a callback. I've set this up in the API, but it can be done anywhere within Sinatra.
00:07:48.960 Now, let me clarify that after we've set this up, you can generate the OAuth hashes with user information, which will come from Twitter as part of the authentication flow, including UID, name, homepage, and profile image.
00:08:09.180 For the actual workflow with Twitter, when you authenticate a user, they are redirected back to the specified callback URL.
00:08:22.680 Kudos to Michael for facilitating this! It's been really great.
00:08:25.440 There's also some device bindings. Although I haven't done any in-depth research, I believe there are some approaches involving Rack session cookies.
00:08:55.140 Switching gears to EventMachine and DripDrop: getting set up is quite straightforward. I believe there’s a Brew install as well, but I used their GitHub for setup information.
00:09:03.240 To create a server, you will only need one action handling method where you declare your route type and the kind of socket you wish to create.
00:09:15.240 In this case, we're going to be doing a WebSocket server, which I've pointed to the back-end processes. The example provided highlights sending out messages every second.
00:09:48.480 This approach is definitely a bit hacky. I apologize if this frustrates anyone, but I like this because Heroku allows you to deploy apps easily with a YAML file.
00:10:07.560 This way, you can deploy the app in multiple environments like in Japan and quickly get things running.
00:10:30.600 If we just require the needed files and declare the server functionalities, it should fire up pretty quickly.
00:10:44.220 A quick WebSocket example will show how to implement such a server. Note that it might only work in Chrome and Safari, depending on their WebSocket support.
00:10:57.220 As we demonstrate this with dual servers, it’s pretty much an example of passing different mail setups.
00:11:08.580 To wrap this up, I want to give a shoutout to my startup, where we're currently looking for Rails programmers.
00:11:19.920 We’ve only been working on this for about five weeks, based in San Francisco. We have some notable investors on our list.
00:11:40.140 If you have any questions, keep in mind I'm only a hobbyist.
00:11:46.620 We’re using EventMachine for handling interactions, specifically with the DripDrop and ZMQ machines, which provide a DSL around CMP machines.
00:12:01.740 In terms of session initialization, that’s one place you'll need to change configurations, switching from the standard cookie setup to utilize Rack session.”},{
Explore all talks recorded at Ruby on Ales 2011
+8