Explore other options instead of using singleton in API Service

[anirudh-eka]

Reason for using singleton:

The API Service is a singleton that stores the last time it pulls from Social Media in an instance variable. We used a singleton because:

1. We wanted a single instance of the service to interact with external api so that we don't hit any api rate limits.
2. We wanted to avoid storing this information in the db if possible because it would often be updated and we thought it would be cheaper as far as performance to have it simply live in memory

   Questions:

   1. First of all, do any of the reasons above not make sense?
   2. When is it appropriate/not appropriate to use a singleton in a Rails App?
   3. What are some alternatives we could use?

Thanks!

@pturley, do you have any advice?

[pturley]

Well, there are a few things that we could do instead of the singleton object to basically share state between requests without hitting the database. The honest truth is that none of them are without problems:

1. Caching the calls in class variables inside a service class. This one's big problem is that those class variables wont be shared across processes or threads. Sometimes it makes for an inconsistent experience for users.
2. Storing the result of the calls in something like memcache (or the database for that matter). This seems like a bit of a tough given the fact that we move to being a gem. Tough to request that people put in a cache solution to use our gem.
3. Store the entire html in the database and just use the database to be our caching solution completely and that itself prevents us from making the service calls.
4. Same story but with the filesystem, but if we roll this thing out to multiple servers, that wouldnt be a good idea.