~/challenge $ mix deps.get
~/challenge $ mix compile
~/challenge $ mix dialyzer
~/challenge $ mix test
~/challenge $ mix docs
Many identically named entries from the original file with differing details will be ignored. This implementation assumes that a consumer simply wants to identify the name of a foodtruck that serves a particular dish. And that the consumer can track down the foodtruck via other means, such as social media. If this application were built for a municipal bureaucracy, perhaps all the various locations and relevant permits would be written to the cache, too.
An ETS table serves as the in-memory cache. Only the process named Cache
can write data to the table. Every table row looks like the following:
{"foodTruckName", %{"mapKey": "value", "mapKey2": "value2"}}
Each key in the table is unique, because the table is configured as a set
. And once written, a key can't be re-written, because of the following line:
:ets.insert_new(@table, d)
A simple Client API exists for other processes to read particular data from the cache, such as read_vendor()
& read_food()
.
A web server offers un-secured JSON responses, and properly terminates TCP connections after transactions complete. The web server offers a route for checking the health of the application. If this application relied on a database, an additional route for reporting the status of a connection to that dependency would be valuable.
Open two separate terminals, and use httpie to request data.
~/challenge $ MIX_ENV=prod mix release demo #terminal 1
~/challenge $ _build/prod/rel/demo/bin/demo start #terminal 1
~/challenge $ http get "localhost:8888/health" #terminal 2
~/challenge $ http get "localhost:8888/v0/vendor/Natan's Catering" #terminal 2
~/challenge $ http get "localhost:8888/v0/food/burger" #terminal 2