Snowplow JSON validator
GET /schema/idreturns a status message with a
getSchemaaction, not just the schema itself
POST /schema/idtwice with the same id is an error and does therefore not override the existing schema
- Error messages may differ from the examples in the instructions document
- Simple file system storage seems sufficient for this task and allows me to avoid the complexity of a database. The feature can however be added easily by providing a respective SchemaStorage implementation.
- I picked release candidate / milestone dependencies as an opportunity to take a look at new features such as the cats-effect
Blocker. In a real-world production scenario I would of course choose stable releases.
- The usage of json-schema-validator and circe is a bit of a mess causing me to go back and forth between JSON ASTs. Circe is however the JSON library I am most comfortable with, so I only fall back to json-schema-validator / jackson for schema specific use cases.
- Cleaning JSON documents off
null-values is treated as a json-schema-validator implementation detail.
- The payload response may contain
"message": null. Changing the behavior would require to override
Building an running
sbt is available, running
sbt run is sufficient to build and start the app. The server will become available on
For a more interactive feedback loop (primarily intended for development), sbt-revolver is available via
Docker is primarily intended for CI purposes but can also be used to build the app when
sbt is not available.
Build the image, named
docker build -t spjv .
Start a container with the app mapped to port
docker run -it \ -v $PWD:/root/spjv/ \ -p 8080:8080 \ --entrypoint /bin/bash \ spjv \ sbt run /path/to/storage
Server will become available on
Running the executable
java -jar spjv-1.0.0.jar /path/to/storage
The storage path is optional. When omitted a temporary directory is used. Depending on your setup, that might not persist across app restarts though.
> java -jar spjv-1.0.0.jar & > curl -d @src/test/resources/config-schema.json http://localhost:8080/schema/config-schema > curl -d @src/test/resources/config.json http://localhost:8080/validate/config-schema > curl -d @src/test/resources/config-invalid.json http://localhost:8080/validate/config-schema
Setting up CI for a project like this is probably out of scope and not expected. I do however believe that CI is an integral component of every software project and should never be an afterthought. This is why every project of mine relies on my sbt-houserules plugin, enabling GitLab CI setup in a matter of minutes.
The CI takes care of these tasks:
- Run test suite
- Generate code coverage report
- Check that the build triggers no warning messages
- Validate code format
- Publish code coverage HTML report
- Publish executable artifact
You can access the CI pipelines on the GitLab mirror.