Javascript client, part of "Collaborative Contract Driven Design", demonstrating how a non-Java developer can use Spring Cloud Contract to do contract driven development.

Using this project currently.

You will need to clone the produce-service repo.

The API for the produce service can be seen here: Produce API

Find your local IP address, docker will be making calls out to loca resources and some of hte script files will ne to be updated as a result.

Run: git clone https://github.com/wkorando/produce-client

If you you are on mac you and running wireless you can run: ifconfig en0 which should return the needed IP address, alternatively ifconfig en1 should work if wired. With that ipaddress update the IP addresses in properties APPLICATION_BASE_URL and REPO_WITH_BINARIES_URL in the file validate-produce-service.sh and IP address for the property STUBRUNNER_REPOSITORY_ROOT in run-produce-service-mock.sh.

Run: ./start-artifactory.sh

This will start local artifactory instance. This will be used for storing the stubs that Spring Cloud Contract generates when it executes contracts stored here: produce-contracts

Run: git clone https://github.com/wkorando/produce-service

cd to the root of that project and run: ./mvnw spring-boot:run

Spring Cloud Contract has a docker image that can read in YAML contracts, see above, and produce stubs for them. This allows non-Java developers to write contracts and generate stubs without having to interact with the Java stack. Steps below demonstrate how to excute contracts to generate stubs and then run a mock server. The mock server reads in the generated stubs and gives stable base to build and test a client against (instead of connecting to a live service which might go down, be misconfigured, or have test data go missing).

Run: ./validate-produce-service.sh

Takes roughly 30 seconds to run. If tests pass, stubs will be generated and put in local artifactory.

If tests fail check under build-output/reports/tests/test/index.html to view report on test run.

Run: ./run-produce-service-mock.sh

This will start a docker image serving up the stubs at http://localhost:9876. As mentioned above this gives stable endpoint to work against. The response for a given request will always be the same, which is much more stable and easier to work for a client developer. If something is working correctly on the client side, it's because an issue with not matching API behavior, not because backend service is currently down.

Starting with the Hoxton, Spring Cloud Contract can generate stubs directly from contracts without the need of running the stubs against the producer service first. This is great if you are a consumer/client developer who is ahead of the producer developer.

Run: ./run-produce-service-mock-no-stubs.sh

This works virtually identically to the above, whoever instead of consuming the stubs artifact generated by the Spring Cloud Contract validator, instead the stubs are generated directly from the contracts without validating them against the producer. This allows consumers/clients to write new contracts for functionality they need and continue development while a producer developer implements the actual behavior at a later date. Like above this will start a docker image serving up the stubs at http://localhost:9876.