Hello and happy Wednesday!
To bring you up to speed, I’ve been working towards accessing data from a web service and displaying it in my Rails project for probably the past two weeks or so. Last night I had a terrific AirPair with Edward Anderson to help me troubleshoot my difficulties.
I’m still working on putting together the pieces as it pertains to understanding how to access external web service data, and more specifically how to access specific attributes in this hashed list of data for a nice display inside of my project’s view templates. Today I thought I’d share what I have implemented so far in my project and what I’ve learned from my recent AirPair’s with Evan, Adam and Edward during my recent mentor sessions.
The Adapter Pattern
If you haven’t checked out my post yet where I go into what the adapter pattern is and how it helps keep our code modular, have a look here. Do take a peak at it if you haven’t already, I received some very good advice from Marek Publicewicz in the comments.
In a nutshell, the adapter pattern allows us to increase the readability of our code by exposing only relevant methods to the client. I’m not sure if I have implemented this perfectly, and I am very open to critiques also, so feel free to comment! I’d love the improvement guidance.
So the way I’ve implemented this in my current project, lunch_panoply looks a little like this:
From the example above, starting at the controller level, I’m assigning the class method
MenuItem.all_meals to the
@menu_items instance variable. In the
respond_to blcok on lines: 9-12 Adam shared some insight about adding a
format.html. Rails will automatically respond to
.html so technically there’s no need to include line: 10 inside of our
respond_to block. He taught that the reason why he could see a benefit in explicitly asserting the
format.html line is because it makes it very clear to other developers on the project (now or in the future) what the expectations are in this case.
He further mentioned that at his consultancy Zeal, they use a lot of front-end frameworks to handle all views. And if I remember correctly he and the team there use the Service-oriented architecture (SOA) design pattern. Which from my interpretation means that he’s using frameworks like AngularJS to provide services to other applications. The lesson I gained from this is to keep in mind that just because the Ruby interpreter can understand whats going on, real people (myself and other future developers) may consider something like being explicit where necessary in our code base to be a welcomed aid when trying to familiarize or re-familiarize ourselves with a code base.
To look at my attempt at using the adapter pattern check out line:34 in the above example. This class method is the only method in my code that communicates with the web service I’m using. Lets try to put together a birds-eye view of whats happening here. I’m not 100% sure about this, but I’m going to give it a shot and welcome any critiques to help my understanding.
In the case of this project the zesty web service is called the Adaptee, synonymous with the
EnemyRobot class from my last post’s second video called Adapter Design Pattern by: Derek Banas. I need to communicate with this Adaptee in order to get their externally kept data into my web app so I can output the resources how I’d like, in html format as a list of all menu_items.
The module I’ve written
MenuItemsRetriever which is stored inside a folder named
api_clients is the Adapter, synonymous with the
EnemyRobotAdapter class from Derek’s insightful youtube video. It’s purpose is to hide the implementation details of making a connection with the web service and querying for results (in this case a list of all_meals).
Next we can use the class method from our Adapter class (
MenuItemsRetriever) inside of our target class,
MenuItem.rb like so:
For the sake of clarity, I wanted to mention that I’ve added
require 'menu_items_retriever' to line: 1 in my
menu_item.rb so that I can have access to the module’s class method. Now we can say that our Rails model
menu_item.rb delegates the responsibility of communicating with zesty to the Adapter class
From here all we need to do is head over to our
menu_items_controller, and assign our wrapper method in the
menu_item model file to an instance variable and then just add the variable inside of our
index view template which is the template typically associated with listing many objects.
Theres the controller, and here is the
index view template, I’m still working out how to access specific attributes from the JSON return data. I can get the entire list, but so far not a particular dish. If you’re curious about this as well, have a look at Edward’s mentoring from last night. If I remember correctly, the last 10 to 20 minutes deal with doing this. I personally will be watching this video over the next couple of days for guidance.
And here’s a quick peek at the output hitting my page in the browser:
I have more things that Edward taught me in last night’s AirPair. One is to head on over to The Ruby Toolbox when researching gems to use. The benefits of using Ruby Toolbox is that they allow us to search by gem name or by a list of categories (Http clients, testing, etc…). Even cooler is that they allow us to gain an overall sense of a particular gem’s popularity, there’s also convenient links to github & Rdoc among others. Very nice!
He also recommended that I try out a couple of different HTTP clients to see which one I find most appropriate for my particular requirements.
I’m currently looking into the following HTTP client gems:
In my next post, I plan on talking about how to setup a web service request and handle the response generated using one of the above mentioned clients.
Here is the video of Edward and I from last night. I’ll be reviewing this today and tomorrow and moving forward with building the necessary queries to satisfy my project’s requirements.
Have a productive remainder of the day!
Categories: Ruby on rails