The purpose of this web server is to provide an API for retrieving weather information provided by Accuweather.
- Scala 2.11.8
- Java 8
- sbt 0.13.8
To start the service use sbt run.
To run the tests use sbt test .
The API specs can be found in the swagger.yaml file.
Please, note that the server will start on localhost:8140.
In order to provide the required functionality, the following have been used:
- typesafe-config for parsing the configuration files
- spray-json for marshalling and unmarshalling data
- akka-actor for scheduling jobs purposes
- akka-http libraries for dealing with the communication over Http
- scala-logging for logging purposes
- scalatest, scala-mock and akka-http-testkit for testing purposes
The entry point of the server is represented by the Bootstrap object, which builds the service configuration, the actor system and materializer, and starts RestService. In addition to this, it schedules the actor system to periodically perform several actions (discussed below).
The RestService is responsible for handling all the incoming Http requests, using the defined routes within WeatherMonitorRoutes. If the processing of a request fails, the failure is mapped to a corresponding Http Status Code and error, using Fault.Handler.
WeatherMonitorRoutes maps the Http requests paths to a corresponding operation to be executed, defined in WeatherMonitorOps - Future based operations.
AccuWeatherClient handles the communication with the Accuweather service by passing corresponding Http requests and unwraps the responses in a certain manner.
In order to efficiently provide weather information with regards to a specific location, a caching strategy has been used. An active location is defined as a location that has been searched for in the past month. For such locations, the server stores relevant data locally, in State. Whenever a client asks for data related to a location, the service checks whether the location is active or not. If this is the case, the request is completed by providing already registered data instead of fetching it from the Accuweather service.
To ensure the registered data is still up-to-date, the actor system is scheduled to sample temperature records for all the active locations at a configurable time interval. Also, to only store data with respect to active locations, the system is scheduled to clean up all the data corresponding to inactive locations (not been triggered in the past month) at a configurable interval. Please, see the StateManagerActor for more details.
NOTE that all the configurable parameters can be found in the application.conf file.
The caching strategy could be improved by using Akka Persistence.
"Akka persistence enables stateful actors to persist their internal state so that it can be recovered when an actor is started, restarted after a JVM crash or by a supervisor, or migrated in a cluster. The key concept behind Akka persistence is that only changes to an actor's internal state are persisted but never its current state directly (except for optional snapshots). These changes are only ever appended to storage, nothing is ever mutated, which allows for very high transaction rates and efficient replication. Stateful actors are recovered by replaying stored changes to these actors from which they can rebuild internal state. This can be either the full history of changes or starting from a snapshot which can dramatically reduce recovery times."
In this case, it would handle events and commands with regards to the active locations data records. Along the advantage of configuring the journal for keeping the data records, Akka Persistence ensures fault tolerance, ie. the server would not lose the registered data if it fails.