🎨 web-server: accelerate input:match via caching rest client call

[pcrespov]

What do these changes do?

Problem
The frontend is currently making frequent calls to the endpoint service/{key}/version/{version}/input:match to validate input matches. This results in a high number of repeated requests, which seem unnecessary and introduce higher load and latency. @odeimaiz is investigating ways to reduce the number of these calls on the frontend.

Implemented Solution 🎨
To mitigate the backend impact in the meantime, we propose adding an in-memory TTL cache to the catalog’s REST client. This cache will store recent results from input:match lookups, significantly improving response times for repeated requests.

Given that connections are sticky, this approach is sufficient to handle short-term bursts of traffic — especially those occurring within a ~1-minute window.

• ✅ Cleanup tests

Related issue/s

• Reported by @wvangeit when using his new jsonifier service which has 12+ inputs
• Complements 🎨 Fix/enh: Avoid duplicated port compatibility calls #7803

How to test

1. add a jsonifier 1.1.0 (with 10+ inputs) and connect with number parameter (single output).
   
2. front-end makes multiple requests to POST service/{key}/version/{version}/input:match

Before

After

Dev-ops

[matusdrobuliak66]

Thanks 👍

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.56%. Comparing base (3b558ec) to head (9ccfda0).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7802      +/-   ##
==========================================
- Coverage   86.72%   82.56%   -4.16%     
==========================================
  Files        1850      703    -1147     
  Lines       71853    33555   -38298     
  Branches     1215      176    -1039     
==========================================
- Hits        62314    27706   -34608     
+ Misses       9198     5791    -3407     
+ Partials      341       58     -283     

Flag	Coverage Δ
integrationtests	64.10% <83.33%> (-0.09%)	⬇️
unittests	86.86% <100.00%> (+0.38%)	⬆️

Components	Coverage Δ
api	∅ <ø> (∅)
pkg_aws_library	∅ <ø> (∅)
pkg_dask_task_models_library	∅ <ø> (∅)
pkg_models_library	∅ <ø> (∅)
pkg_notifications_library	∅ <ø> (∅)
pkg_postgres_database	∅ <ø> (∅)
pkg_service_integration	∅ <ø> (∅)
pkg_service_library	∅ <ø> (∅)
pkg_settings_library	∅ <ø> (∅)
pkg_simcore_sdk	76.84% <ø> (-8.31%)	⬇️
agent	∅ <ø> (∅)
api_server	∅ <ø> (∅)
autoscaling	∅ <ø> (∅)
catalog	∅ <ø> (∅)
clusters_keeper	∅ <ø> (∅)
dask_sidecar	∅ <ø> (∅)
datcore_adapter	∅ <ø> (∅)
director	∅ <ø> (∅)
director_v2	77.52% <ø> (-13.51%)	⬇️
dynamic_scheduler	∅ <ø> (∅)
dynamic_sidecar	88.34% <ø> (-1.74%)	⬇️
efs_guardian	∅ <ø> (∅)
invitations	∅ <ø> (∅)
payments	∅ <ø> (∅)
resource_usage_tracker	∅ <ø> (∅)
storage	∅ <ø> (∅)
webclient	∅ <ø> (∅)
webserver	83.80% <100.00%> (+0.07%)	⬆️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3b558ec...9ccfda0. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mrnicegyu11]

very good optimization, I left a pedantic comment, fell free to ignore

[sanderegg]

Just do not rely on sticky connections. I plan to remove as much of possible as this goes against scaling practices.

Thanks anyway!!

[pcrespov]

@mergify queue

[mergify]

queue

🟠 Waiting for conditions to match

• -closed [📌 queue requirement]
• -conflict [📌 queue requirement]
• -draft [📌 queue requirement]
• any of: [📌 queue -> configuration change requirements]
  • -mergify-configuration-changed
  • check-success = Configuration changed
• any of: [🔀 queue conditions]
  • all of: [📌 queue conditions of queue default]
    • #approved-reviews-by >= 2 [🛡 GitHub branch protection]
    • #approved-reviews-by>=2
    • #changes-requested-reviews-by = 0 [🛡 GitHub branch protection]
    • #changes-requested-reviews-by=0
    • #review-threads-unresolved = 0 [🛡 GitHub branch protection]
    • #review-threads-unresolved=0
    • -conflict
    • -draft
    • base=master
    • branch-protection-review-decision = APPROVED [🛡 GitHub branch protection]
    • label!=🤖-do-not-merge
    • label=🤖-automerge
    • any of: [🛡 GitHub branch protection]
      • check-skipped = deploy to dockerhub
      • check-neutral = deploy to dockerhub
      • check-success = deploy to dockerhub
    • any of: [🛡 GitHub branch protection]
      • check-success = system-tests
      • check-neutral = system-tests
      • check-skipped = system-tests
    • any of: [🛡 GitHub branch protection]
      • check-success = unit-tests
      • check-neutral = unit-tests
      • check-skipped = unit-tests
    • any of: [🛡 GitHub branch protection]
      • check-success = check OAS' are up to date
      • check-neutral = check OAS' are up to date
      • check-skipped = check OAS' are up to date
    • any of: [🛡 GitHub branch protection]
      • check-success = integration-tests
      • check-neutral = integration-tests
      • check-skipped = integration-tests
    • any of: [🛡 GitHub branch protection]
      • check-success = build-test-images (frontend) / build-test-images
      • check-neutral = build-test-images (frontend) / build-test-images
      • check-skipped = build-test-images (frontend) / build-test-images

[pcrespov]

Just do not rely on sticky connections. I plan to remove as much of possible as this goes against scaling practices.

@sanderegg I will leave a note.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[wvangeit]

Great, thanks.