We might want to replace our cache-only code paths with HyperSwitch, a lightweight microservice frontend built and maintained by Services . It's configured using Swagger spec files, which we already have for ORES. This allows us to decouple cache lookups from ORES and free up Python resources, helps us standardize our service for WMF purposes, and lets us experiment with backend architectures.
I'm not particularly sure what do you mean and want to achieve. Putting ORES behind RESTBase without using storage (as a simple proxy) will not really free up any resourses on ORES side. Do you mean you want reads of pre-computed scores to not touch ORES at all?
Thanks for mentioning this, it does look like nearly the same concept. I'm not familiar enough with RESTBase to give an opinion about whether that would be the right level for integration, but it's certainly worth more exploration. We're considering architectural changes to ORES which make it even more compatible with this approach, namely generating the scores as a decoupled, stream-based process and serving the API from a static, disk-based cache like Cassandra.
Yes, exactly that! It should be possible to migrate from on-demand scoring to a stream-based backend, by at first serving uncached requests using an internal API request to ORES, then later filling the cache with a complete set of scores for each wiki. Having a non-ORES frontend would give us more flexibility in managing this transition.