Implement caching strategy for the API calls.

Created on 1 March 2023, over 1 year ago
Updated 19 July 2023, about 1 year ago

Problem/Motivation

Noticed that the load function when getting+saving an external media item got called 9 times.
This made me implement a caching strategy for these calls. Nonetheless a caching strategy always comes in handy with API limited services.
You can even choose how long a specific function for a specific plugin will be cached.

Proposed resolution

Caching strategy.

Remaining tasks

Review + commit

User interface changes

Added an extra Setting for cache expiration time.
'media.external_provider.' . $this->getPluginId() . '.cache_expire.' . $functionName
$functionName can be load or or search right now.

API changes

/

Data model changes

/

Feature request
Status

Fixed

Version

1.0

Component

Code

Created by

🇧🇪Belgium Mschudders

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Issue created by @Mschudders
  • @mschudders opened merge request.
  • 🇧🇪Belgium Mschudders

    add time dependency injection as well.

  • 🇳🇱Netherlands seanB Netherlands

    Thanks for the issue. This makes sense to add! The current implementation will probably break existing plugins though. Not sure yet how to get this done in a backwards compatible way. One thing we could do is add a service to wrap the current plugin calls:

    $provider->search($keyword, $this->pagerManager->findPage());

    $photo = $provider->load($external_id);

    This new service could then implement the caching so the plugins themselves don't need to worry about that. What do you think about that?

  • 🇧🇪Belgium Mschudders

    Well we could make a Major release?

    Nonetheless this way a Plugin could still choose to not have caching. For example, for specific external media libraries you maybe don't want caching?

    If a major release isn't possible we could look into it further.

  • 🇧🇪Belgium Mschudders

    another solution would be to have 2 different interfaces.

    Any other change won't have any effect from our point of view.
    since extending classes still call parent::load for example, it doesn't change

  • Status changed to Needs work over 1 year ago
  • 🇧🇪Belgium Mschudders

    I've already worked a intermediary service for caching.

    Not yet tested though. I suppose this is the way you want it?

  • 🇧🇪Belgium Mschudders

    tested and fixed some issues.

    Caching is working properly.

    Todo check diff of main branch

  • Status changed to Needs review over 1 year ago
  • 🇧🇪Belgium Mschudders

    All seems good. Putting to review.

  • Status changed to Fixed about 1 year ago
  • 🇳🇱Netherlands seanB Netherlands

    Nice work! Added some changes before merging to use a single cache backend and renamed the cache wrapper services, but overall it worked perfectly. Thanks!

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024