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.

[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.

[calloncampbell]

Hi, what's the status of this idea? I think this is a great idea and would make the labs very consistent and iterative across the board.

[simonkurtz-MSFT]

I do, too. The trouble is that this type of work requires a large time investment in addition to internal dependencies for this workshop. As much as I wish I could give an update, I don't have anything to share, unfortunately.

[shailugit]

This lab is really helpfull and I suggest if we can have some one dedicated resource to refresh it say every 3 months as lot of changes are in place including MCP/A2A V2 etc and I agree on KISS design principle :)

[calloncampbell]

Hi Simon, As a Microsoft MVP, is there anything the MVP community can do to help with this? Happy to have this convo in the appropriate channels. Callon

…

________________________________ From: Simon Kurtz ***@***.***> Sent: September 30, 2025 11:47 AM To: Azure/apim-lab ***@***.***> Cc: Callon Campbell ***@***.***>; Comment ***@***.***> Subject: Re: [Azure/apim-lab] Rework the Lab Scenario and Backend APIs (Discussion #60) I do, too. The trouble is that this type of work requires a large time investment in addition to internal dependencies for this workshop. As much as I wish I could give an update, I don't have anything to share, unfortunately. — Reply to this email directly, view it on GitHub<#60 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA7HY2CJD7KVCQPRRVBEFO33VKQ2JAVCNFSM6AAAAACH5E2AISVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINJVGQ2TOOA>. You are receiving this because you commented.Message ID: ***@***.***>