jpgough / api-workshop Goto Github PK

Improvements from the original lightning talk required for conference

• IntelliJ Community Edition
• Java (12)
• Docker For Mac/Windows

This image appears to be missing https://github.com/jpgough/api-workshop/blob/master/02-contracts/images/pact_broker.png

The Version presentation references the API lifecycle from PayPal.
We should include references of MSFT and there standards.

• Create a solution with auto deployment to Dockerhub
• Update README with link to solution project

A short demo of Service Mesh capability

Improvements from the existing lightning talk

Java 12 has gone EOL and the workshop images etc are not available for 13.

Suggest we move to use Java 11.

• Update pre-requisites
• Update labs

Slide title form slide 2 should be changed to what will be covered

https://github.com/jpgough/api-workshop/tree/master/prerequisites#download-springboot-project

1. Instead of - "The following URL is pre-configured to take you directly to https://start.spring.io and download a zip file containing the project. Just open your browser and enter the URL, the download should begin.",
   It should be:
   "The following URL is pre-configured to take you directly to https://start.spring.io and set the required dependencies to Spring Web and Spring Contract Verifier. Open your browser and enter the URL, and then click on "Generate" to download a zip file containing the project."

2. Intellij Project Import and Eclipse Project Import images aren't loading.

When using AdoptOpenJDK the JDK is not installed in Contents/Home

It is in c:/ProgramFiles/AdoptOpenJDK/

This should be selected NOT the Contents/Home location

Introduction to API Gateway

Improvements from the existing lightning talks

Demo walkthrough of API Gateway with our sample API

Java -jar command typo, needs a space after api-docs

Add
@RunWith(SpringRunner.class)
@SpringBootTest
example for the Contract base if you want to go pure spring.
This all needs to be put in the Solution

Step One and Step Two need removing from lab 1 and should instead just be a link to the pre-reqs

In the solution the /todos API returns a Map, which is not a List as specified by the lab. Can we check this for consistency as this will also appear during the contract testing

Couple of notes on the app for the first part of the app.

• The image to create the app in the spring initialiser show shows 2.1.5 as the release. The current release is 2.1.7
• The eclipse instructions to bring in JUnit show say JUnit5. 2.1.7 currently brings in JUnit 4 by default so I thing it could lead to miss configuration unless this has been tested?

An improvement that was mentioned and would streamline the process for attendees is to make the swagger-diff lab more efficent.

At present it required that the CLI Swagger diff tool is available and this includes having Ruby.
What would be better is to have the java lib from http://deepoove.com/swagger-diff/ available and use this to compare swagger specs

Add in pre-req details with new links and make docker section optional

The images in the presentation that show the Versioned containers/serverices is large and shows 6 of them. This can be made smaller and would provide more clarity. 4 of these containers would be better

• a Mixture of examples, Pizza/Google. Should we just center on the todo service? I think that will lead nicer into the lab.
• It’s not so clear when we are moving between Spring Cloud Contract and pact. I’m wondering if the flow would work better as Producer driven contracts with diagrams, and the technology. Followed by what’s a consumer driven contract and how does that differ with a diagram.
• Missing conversation on stub server/broker and how that leads to more effective team collaboration

Windows home has a limitation with the Docker installation.

We need to document any potential work arounds.

Follow steps here:
https://docs.docker.com/toolbox/toolbox_install_windows/

download version 19.03.1

A new set of slides should be created that can be used to discuss API Best practacies.

This should have some best practacies from MSFT included. It is important to show that that the key part is to take a standard and follow it. This will give you consistancy

Improvements on the current lightning talk

Currently the slides on Best Practacies for building API's is an overview.
These points should be expanded upon and explained as attendees will want to know more about these subjects when designing there API's

Lab 3 images need to be updated to the new URL format

• Typo "Consumers from" on diagram should be "Consumes from"
• Provider or Producer Contract Development?

Following on from the API Gateway Deck introduces the Service Mesh briefly in the role of loopback

Rather than ask people to download the swagger-codegen-cli as a pre-req, maybe we could just add the JAR to the repo under correct lab? One less step for people to do.

http://central.maven.org/maven2/io/swagger/swagger-codegen-cli/2.3.1/swagger-codegen-cli-2.3.1.jar

Transition is too abrupt.

• GET is probably easier to start with, as it has less to consider/think about
• Status codes/status code category ranges could do with a brief coverage e.g. 2xx,4xx,5xx meaning
• Would be worth covering the DELETE, PUT or at least the meaning behind the methods
• Query Parameters are not covered, which are important for advanced gets
• I think we need some coverage/call out on the path structure

In intelliJ select and Open the build.gradle file