14. Patterns: Cached Result
The cached result pattern is used to alleviate load on an underlying system by returning a result that is stored in Flowgear for a specific request. Typical reasons to use this pattern cases where:
- A large number of similar requests come in over a short period of time
- Querying the underlying service is slow
- Querying the underlying service is expensive in some way. For example, it might cause a lot of memory to be allocated or a lot of CPU to be used
Under the pattern, the Workflow looks up the parameters for the request to see if there is a recent result for those parameters. If one is found, that stored result is returned instead of querying the underlying service. If no match is found, the underlying service is invoked and the result is stored (cached) so that it can be returned the next time the same request is received.
Exercise 19: Cached Result
In this exercise, we'll revisit the weather service we used in an earlier exercise but this time, we'll use caching to return the temperature of a city when it has been previously requested.
Add
Web Request 2, rename itServiceand connectStart.RunNow → Service.Set
Service.Urltohttp://api.openweathermap.org/data/2.5/weather?q={city}&APPID={appid}&units=metric.Add
Service.cityandService.appid.Add a
Variable Bar, rename itInputs.Add
Inputs.cityandInputs.appidas Output Properties. Setappidto be aHidden Property.Set the
Inputs.appidProperty value toc95dadb707ef003ac19b0236e63e348a.Set
Inputs.cityto a city name, for exampleatlanta.Connect
Inputs.city → Service.cityandInputs.appid → Service.appid.Run the Workflow to check it's executing correctly.
Add a
Variable Barto the right ofService, rename it toOutputs.Add
Outputs.temperature.Connect
Service.ResponseBody → Outputs.temperature, set the Data Mapping Expression tomain.temp.Next, we will add a Key/Value to store the temperature of a city that has been queried.
Move
Outputsone block to the right and addSet Key-Value 2, rename itStore Temp, connectService → Store Temp.Set
Store Temp.Grouptotemperature.Connect
Inputs.city → Store Temp.Key.Connect
Service.ResponseBody → Store Temp.Value, set the Data Mapping Expression tomain.temp.Run the Workflow and confirm the Set Key/Value step is storing the temperature correctly.
Now we will introduce a test to determine whether the temperature for a city is already in the Key/Value store which is acting as our cache.
Move
Servicethree blocks to the right, in the space created, addGet Key-Value 2, rename toQuery Temp, addDateTime Compare, rename toCompareand addIf.Reconnect
Start.RunNow → Query Temp,Query Temp → Compare,Compare → IfandIf.False → Service.Connect
Query Temp.Missing → Service.Set
Query Temp.MatchGrouptotemperature.Connect
Inputs.city → Query Temp.Key.Connect
Query Temp.DateTime → Compare.DateTime1.Set
Compare.TimeSpanUnittoSeconds.The
DateTime CompareNode returns the difference between two dates and times. If one of theDateTimeProperties is left empty, it defaults to the current UTC time for the comparison.Connect
Compare.TimeSpan → If.Value.Set
If.ExpressiontoValue < 60.We are setting 60 seconds as the cache expiry period. This means that we will serve a temperature for a city from cache until that record is 60 seconds old.
Connect
Query Temp.Value → Outputs.temperature.Run the Workflow to see it re-cache the temperature for Atlanta, then run it again and it should return the cached temperature. Wait 60 seconds to see the cache invalidate and query the weather service again.
Note that we don't need to connect any further steps to the
IfNodeTrueOutput because we already injected the temperature toOutputs.temperaturefromQuery Temp.Value.Notice also that the Workflow runs very quickly when operating through the cache since the "expensive" step of invoking the weather service is skipped.
Save and run your Workflow, then click Submit Exercise to grade it.