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 include:
- 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, and rename it toService. ConnectStart.RunNow → Service.Set
Service.Urltohttp://api.openweathermap.org/data/2.5/weather?q={city}&APPID={appid}&units=metric.Add Custom Properties on
Servicenamedcityandappid.Add
Variable Bar, and rename it toInputs.Add Properties on
Inputsnamedcityandappidas outputs. Setappidto be aHidden Property.Set
Inputs.appidtoc95dadb707ef003ac19b0236e63e348a.Set
Inputs.cityto a city name, e.g.atlanta.Connect
Inputs.city → Service.cityandInputs.appid → Service.appid.Run the Workflow to check that it is executing correctly.
Add
Variable Barto the right ofService, and rename it toOutputs.Add a Property on
Outputsnamedtemperature.Connect
Service.ResponseBody → Outputs.temperature, and set the Data Mapping Expression tomain.temp.Next, we will add a
Key/Valueto store the temperature of a city that has been queried.Move
Outputsone block to the right. AddSet Key-Value 2, and rename it toStore Temp. ConnectService → Store Temp.Set
Store Temp.Grouptotemperature.Connect
Inputs.city → Store Temp.Key.Connect
Service.ResponseBody → Store Temp.Value, and set the Data Mapping Expression tomain.temp.Run the Workflow and confirm the
Set Key/Valuestep is storing the temperature correctly.Now, we will introduce a test to determine whether the temperature for a city is already in the
Key/Valuestore, which is acting as our cache.Move
Servicethree blocks to the right. In the space created: addGet Key-Value 2, and rename toQuery Temp; AddDateTime Compare, and rename toCompare; AddIf.Reconnect
Start.RunNow → Query Temp,Query Temp → Compare,Compare → If, andIf.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, and then click Submit Exercise to grade it.