Now that progress has been made toward my thinking about testing out my adapter class, I want to look into the next step in my requirements. Lunch Panoply needs to be able to save a web service response into the application’s database.
Over the next few days, I’m going to slow down a bit, and try to understand the problem set and how to implement a solution. By doing this my goal is to limit or prevent myself from going too far down a wrong path while trying to solve this.
Today, I’m going to share what I’ve looked into already and some thoughts on coming up with at least some components of a solution.
[T]he process of translating data structures or object state into a format that can be stored (for example, in a file or memory buffer, or transmitted across a network connection link) and reconstructed later in the same or another computer environment. When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. For many complex objects, such as those that make extensive use of references, this process is not straightforward. Serialization of object-oriented objects does not include any of their associated methods with which they were previously inextricably linked.
My first step in confirming that this is what I’m looking for was to check out this RailsCast video on ActiveModel Serializers.
After watching the video and checking out wikipedia, it appears that the concept I’m looking to implement with Lunch Panoply is the opposite of Serialization or Marshalling.
Wikipedia calls this process deserialization or unmarshalling. And it deals with extracting a data structure from a series of bytes.
Saving Web Service Responses into a Rails Model
Of the two approaches Adam Cuppy offered during a past AirPair, saving response data to the db vs having a user’s query hit the JSON endpoint and have the API return data to the user, I think I would like to save the response data as a collection of restaurants and their menu items into my database. And in the future, possibly creating a background job to update this collection periodically. Adam told me that this is preferable in a user’s experience because their queries won’t have to actually hit the web service every time they want to view a different resource, thus speeding up the time to actually review the results.
With that in mind, I’ve found the following resources that seem to accomplish something similar.
- Save data from api request to a model (JSON)
- ActiveResource::Base api docs
- Saving JSON Response as an Object in Rails
So from the links above (particularly the StackOverflows) I see that the responses are used directly inside the controller. I want to find a solution to where I can delegate the response parsing to the Adapter class that was created to hide these details from the rest of my application.
I need to look a little deeper into a similar implementation as displayed in the above links. One difference is that I have an Adapter class that holds the request and filters for the index view.
I’m thinking of saving all this data from one large request, populating my Venue class (synonymous with Restaurants) with the JSON attributes and creating an external_api_id for the restaurant’s JSON ID. And then saving the menu_items (synonymous with dishes in the JSON response) associated with each venue/restaurant.
It appears that accessing the various data is as easy as accessing values from a nested hash, but I could be overlooking something, so I’ll reserve judgement on that until a future post.
Any critiques to my thought process is very welcome. I’ll be posting more as I learn more.