Rework the Lab Scenario and Backend APIs

[simonkurtz-MSFT]

While the current labs are very useful, I think it would be more beneficial if we could rework the organization of the lab to work towards a better-defined purpose. Presently, we have a mix of Calculator API, Star Wars API, Color API, but they don't relate well to one another, and, once labs are completed, a participant will have difficulties looking back and see a progression from a starting to an level-200 stopping point over the course of the workshop.

Specifically, I am thinking of a Contoso company that is entirely new to API management and wants to integrate APIM with APIs, serverless, and Power Platform. I believe the APIs we should focus on are REST - both new and imported via OpenAPI, GraphQL, and WebSocket. Even though SOAP is still relevant for our customers, I think focusing on the aforementioned should be sufficient.

The overview of the workshop should introduce the Contoso company's history and situation. This is important to get right as lab participants can relate with similarities they may have experienced in their own organizations. Technological evolution often places us at crossroads with what we have that has been good or not as good vs. where we want to move as a whole, and this Contoso company is presently experiencing this process, hence the motivation for this workshop. For example, Contoso has done a great job in building out various REST APIs and wants to import (and still create) them. Contoso has also been very excited about the prospect of GraphQL as it sees a simplified experience for its callers by having some APIs with just one endpoint that can be queried for variable information rather than aggregating information through a number of distinct APIs.
The company has used WebSocket / SignalR to stream operational product telemetry and wants to ensure this communication is also driven through APIM to have one point of entry for management and API operational insights.

The labs should be coherent with the fictitious company's needs in mind and leverage a building block approach and consider iterative improvements. Essentially, the question is how we can best support what we have while also subscribing to newer best practices for the future.

API Security is also very important, and we should enhance our labs as best as we can to make them higher-fidelity.

[markharrison]

I think its a valid point - and I have heard it before.

The current demos are simple/not related but it does allow a user to focus on the actual APIM functionality and not get distracted by a complex scenario.

I can see both sides.

[simonkurtz-MSFT]

I agree. I believe we could keep a complex scenario still simple enough to where we work through some 200-level functionality to show how things tie together a bit more. The current labs are great in their complexity - I like your work there a lot - I just want to tie them together a bit more to where someone can look back after the workshop and see the path from beginning to end.

[markharrison]

What you suggest makes lots of sense. I wonder if it needs a V2 of the lab - it seems more than a slight tweak ?

[simonkurtz-MSFT]

I agree. I would suggest to branch for V2 and at least temporarily deploy changes to a secondary github.io page. It would be fine to me to keep it public (although not advertised) since the repo is public, too. Once V2 reaches its milestones, cut it over.