The current CORS filter is working but we should write a test for it.

Seems Java SDK has a convenient way of wrapping dynamodb operations by annotating properties of the case classes (although this would couple the case class which represents data with the storage implementation, so probably not nice unless it can be done on a separate file).

http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.html
http://stackoverflow.com/questions/17070253/how-can-one-use-amazons-dynamodbmapper-in-scala

Update

This provides a way to do the same using the json document format

https://aws.amazon.com/blogs/aws/dynamodb-update-json-and-more/

seems the better approach

For both models we can do validation on the constructor by using something like

http://stackoverflow.com/questions/20478588/scala-case-class-how-to-validate-constructors-parameters

Then we can see if we return Option/Maybe or Try

Update: Better to use Try to handle possible validation exceptions

http://danielwestheide.com/blog/2012/12/26/the-neophytes-guide-to-scala-part-6-error-handling-with-try.html

Using Try has the disadvantage of making it hard to differentiate the different errors (such as NotFound vs Validation errors, etc). Instead, we should go for something like

http://mavilein.github.io/scala/2015/09/01/comparing-error-handling-scalas-try-with-scalazs-either-disjunction/

Where the different errors are defined as a sealed Trait

sealed trait MyError
case class UnknownUser(userId: Long) extends MyError {
  override def toString = s"User with id [$userId] is unknown."
}
case class WrongSecret(userId: Long) extends MyError {
  override def toString = s"User with id [$userId] provided the wrong secret."
}
case class ServiceUnavailable(service: String) extends MyError {
  override def toString = s"The Service [$service] is currently unavailable"
}

Specs

Car adverts should have the following fields:

• id (required): int or guid, choose whatever is more convenient for you;
• title (required): string, e.g. "Audi A4 Avant";
• fuel (required): gasoline or diesel, use some type which could be extended in the future by adding additional fuel types;
• price (required): integer;
• new (required): boolean, indicates if car is new or used;
• mileage (only for used cars): integer;
• first registration (only for used cars): date without time.

Models

Since the payload to generate a car is smaller than the response (which contains an additional id), best way to do it DRY is to have a base model for the submission/update payloads and an extended model used for the responses

Editor

• Use the Swagger Editor to generate the yaml file and validate it
• Use the Swagger UI official-hosted client to test the UI once it's in production

The data flow is

controller (raw json) -> `hydrated CarAdvert` -> StorageDriverTrait -> StorableTypeTrait -> `hydratedCarAdvert`  -> raw json

Json service

• We need some logic to convert from the raw input json into an Either[AdvertNewCar,AdvertUsedCar]. If we do that then it becomes easy to
• We need logic to convert to raw json.
• Write tests for the Json service

Hydrate Service

We need a service that will hydrate/convert between the database StorableTrait input/output types and the AdvertNewCar/AdvertUsedCar types.

Service needs to:

• Given a StorableType, it needs to convert it into an Either[AdvertNewCar,AdvertUsedCar]. The other direction is already satisfied, since the AdvertNewCar,AdvertUsedCar already implement StorableType.

We want to containerize the app

• Docker container for the play app running through sbt
• Docker container for DynamoDB database

http://www.scalastyle.org/sbt.html

https://github.com/scoverage/sbt-coveralls

It also integrates w/ Travis so bonus points for that

Create method

• Success creating new car advert
• Success creating used car advert
• Check exceptions

Idea:

The following is brainstorming how to best setup the database access layer

• StorageDriverTrait: An interface that has CRUD get/delete/update/create methods and
  • takes the full models Either(CarAdvertNew|CarAdvertUsed) as parameters.
    -This will return the same for the getter methods (with an optional collection). The actual storage format is invisible to the user.
• DynamoDbStorage: The actual implementation, constructs JSON from each of the models (the modes I guess should have a toJson method), and an object companion fromJson probably as well

We want to be able to serve requests from different domains than where the server is hosted client-side, so we need to pass browser CORS tests

https://www.playframework.com/documentation/2.5.x/CorsFilter

We want to build the application (and pass tests) on PR/merges through travis. Optionally perhaps deploy to Heroku, depending on how we deploy the application

https://docs.travis-ci.com/user/docker/

See Inaki's CV Travis config as an example of running a dockerized build

Once the Rest server is up and running, we can add integration tests using play-ws

https://semaphoreci.com/community/tutorials/how-to-add-integration-tests-to-a-play-framework-application-using-scala

Another possibility is to generate the API client from the swagger spec via Scala Swagger codegen

Either start with sbt file from scratch or use one of the given activators

Right now the DynamoDB client is generated in the DynamoDB storage class, this makes it that we have to choose between production & local there. It would be cleaner to have that decision outside and inject the client via Guice.

http://stackoverflow.com/questions/36635128/how-can-i-generalize-either-to-more-and-recursive-types

We need to have 2 case classes:

• AdvertForNewCar
• AdvertForUsedCar
  and use scala Either to wrap them into different return cases. (at the end of the day the only thing that will change will be the validation).

We also need a base AdvertTrait that implements all the shared methods, such as validate (or maybe not validate since if the object is created the data must be valid already), perhaps as a object companion static method without implementation.