Adam Browner Adam Browner - 1 month ago 7x
Ruby Question

When fetching data using an api, is it best to store that data on another database, or is it best to keep fetching that data whenever you need it?

I'm using the TMDB api in order to fetch information such as film titles and release years, but am wondering whether I need to create an extra database in order to store all this information locally, rather than keep having to use the api to get the info? For example, should I create a film model and call:


and by doing so accessing a local database with the title stored on it, or do I call:


and by doing so making another call to the api?


Having dealt with a large Rails application that made service calls to about a dozen other applications, caching is your best bet. The problem with the database solution is keeping it up to date. The problem with making the calls every time is that it's too slow. There is a middle ground. For this you want Ruby on Rails Low Level Caching:

Sometimes you need to cache a particular value or query result instead of caching view fragments. Rails' caching mechanism works great for storing any kind of information.

The most efficient way to implement low-level caching is using the Rails.cache.fetch method. This method does both reading and writing to the cache. When passed only a single argument, the key is fetched and value from the cache is returned. If a block is passed, the result of the block will be cached to the given key and the result is returned.

An example that is pertinent to your use case:

class TmdbService
  def self.movie_details(id)
    Rails.cache.fetch("{id}", expires_in: 4.hours) do
      Tmdb::Movie.detail 550

You can then configure your Rails application to use memcached or the database for the cache, it doesn't matter. The point is you want this cached data to expire at some point to ensure you are getting up-to-date information.