rynowak

Community call demo 8/8

Prep

Visual aids:

• API documentation
• Example API calls
• Component Diagram: https://excalidraw.com/#json=ZJfVrRxsbu8JKwKlcoCdN,yHZc3JnQAqe6YCBSm6DTrg
• API sequence Diagram: https://excalidraw.com/#json=MR2eRoGYwnysDEiqVGGjY,1DQ3eqw1A_DR5M-z0waWrA

rynowak

Application Model Innovation

Application Model: A document or API that describes a cloud application's configuration and requirements in a way that can be deployed and run.

Industry Landscape

Application models, delivery, and deployment tooling is a target-rich environment with many projects. Developers don't like application deployment and aren't good at it, but making developers more productive is always an important problem to solve. Complexifying this, there are many different models of how organizations work, whether they have separate disciplines, and which people have different responsibilities.

The result is that there's a huge diversity of a projects, no standard terminology, and no one project gets critical mass.

rynowak

Test Plan for Recipes

This document is the starting point for a Recipes test plan. The goal of this document is that we can have a brainstorm together and fill in the plan with input from the whole team. @rynowak will hold the pen for writing the final document, and @kachalwa is the approver. The work that's detailed here will feed into the individual items being driven by feature owners (functional tests are part of the definition of done).

Our goal for this discussion is to introduce the idea of a test plan, collect, and refine input.

We're doing this now because we're executing on Terraform recipes in a highly parallel well. Getting a shared understanding of the test strategy will help individuals build the right tests by doing some big-picture-thinking upfront.

We've also had a lot of churn in our design practices for tests and recently done some thinking about concepts like:

rynowak

Tracked Resources Notes

Synchronous Flow

Today, it looks something like this:

---
title: Sychronous resource flow
---

rynowak

Public Release +1 Planning

This document provides framing for public release +1 - meaning: what are the next set of goals and investments for Radius post-public-release.

Since we moved our announce date back we'll have time to do more before the actual initial release. Additionally we need to build a public roadmap and publish it as part of the project. This document acts as an input to support both those goals.

Updates to goals

Our goals for public release as started original were:

rynowak

Radius workshop

Written by the shores of Lake Tahoe.....

This document is the overall framing of a Radius workshop that we would produce. The goals of this document are to:

• Align the team on the purpose of the workshop and format.
• Align the team on an overall outline so we can assign owners and start work.

Goals of the workshop

rynowak

On Linkability and Size

Optimizing a .NET application for size requires us to develop new muscles, new tools, new designs, and new criteria for decision making. We typically provide customer value though building rich and powerful APIs. Optimizing for size asks something new of us, wanting granular APIs, uncoupled features, and statically-analyzable patterns.

Of the top ten non-Microsoft .NET library packages on nuget.org - 6/10 of these libraries serve the primary purpose of doing dynamic code invocation (IoC).

• Newtonsoft.Json (Serializer)
• Castle.Core (Reflection/IL utilities)
• Moq (Mocking/Proxies/IL Generation)
• Automapper (Object-Mapping)

rynowak

API Template small single exe Roadmap

This document is a proposal for leveraging the learnings from the small-single-exe working group in ASP.NET Core in an immediately actionable way. All of these changes are aimed at improving one or more of the metrics that we're tracking for the single-effort without bad scenario takebacks.

There's still some design and scenario work to do here for ASP.NET Core - these aren't specs - the goal of this document to capture how we can apply learnings from this effort and accounting for what we stand to gain.

Executive Summary

We've completed the prototyping exercise, our primary results:

rynowak

Summary

ASP.NET Core startup code follows regular patterns that are suitable for code analysis and enhancements to the coding experience through analyzers, code fixes, and smarter scaffolding.

What things that analyzers could provide would be most valuable?

Things that analyzers can easily understand:

• What services are registered? (ex: AddMvc() includes AddRouting())
• What options are set? (ex: AddMvcOptions(options => options.EnableEndpointRouting = false)
• What middleware do you have? (ex: UseHealthChecks())

rynowak

Bind cases

Option 0: (current state)

<input type="text" bind="@person.Name" />
<input type="text" bind-value="@person.Name" />
<input type="text" bind-value-oninput="@person.Name" />