Posted about 10 years ago by Philip Ingram
When I was creating my last app, I ran into an interesting problem. In this app, i theoretically could have used ONE model.
This one model needed to do the following:
Maybe one model could meet all these goals. However, I didn’t want to be dependant on only one model since my app would:
Matroyshka are those little Russian nesting dolls that all hide inside one another. I googled for this pattern, and didn’t find any relevant patterns that match this one. So this is either new territory or a really dumb idea. Ha, time will tell.
There was one link, i just found today as i write this post to a railsconf ’09 talk but they are talking about the app as a whole and using engines or something. I’ve not watched it, sorry.
Perhaps i could have accomplished these “main” goals differently, but since I do not have a CS background, here is how I implemented it in my last app.
What i did was to take the webhook data into the first model: RawData, we’ll call it.
This allows me to capture the data from the webhook quickly, and report back to the api provider with a 200 response all quick like.
I then take the relevant data i need and put it into a second model: RealData, we’ll call it.
In the same method that this RealData is created, i also create a RealDataTransaction model instance with just bare information in it (e.g., user_id && amount).
Now that i have the RealDataTransaction model i can run two specific nightly tasks on this model, freeing up the RawData and RealData models to continue taking webhook calls. These models can also be made into nice ActiveResource models down the road.
Also now the users can access ‘report’ styled queries on the RealData model at anytime. Since this is a paying app, i can also calculate transactional costs for the past month, based on the RealDataTransaction model.
Even though I’ve put this post in the context of my app, i do feel that this model structure could benefit any app who services clients on a monthly basis and is dependant on transactional data. Your model names and attributes will change, but given this pattern all that really needs to change is the nightly tasks in which you run.