iie labs

Matroyshka Model Pattern

Posted about 5 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:

  • House incoming data from a webhook. The data will not always contain information that I will be able to use in my app. (i.e., not all incoming webhook data is relevant to my app).
  • be able to be read by two different models by users who have two different needs for the data
  • create report styled queries and calculations on the data nightly & monthly.

Some foreseeable problems with one model

Maybe one model could meet all these goals. However, I didn’t want to be dependant on only one model since my app would:

  • be creating new records at any time, thanks to the webhook.
  • have users coming at random times performing some heavy calculations on the exact same model.
  • be running tasks on a nightly and daily basis must interfere with the performance of the webhook response time.

What is a Matroyshka?

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.

Introducing the Matroyshka Model Pattern

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.

Summary

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.

Comments

blog comments powered by Disqus