Overview

AI generates code. It doesn't guarantee a well designed application that will meet your needs for maintainability, scalability, and flexibility. PlotCourse's solution PlotStax® was created to address this problem.

As expectations of developer productivity increase, PlotStax® is designed with one overarching goal in mind: Help software developers quickly build high quality software. Using PlotStax, .NET developers can focus their attention almost entirely on the problem domain of their application while leaving PlotStax® to handle broader application structures that are controlled in a quick and easy way.

If you're planning to build a .NET Web API or a website backed by .NET services, let PlotStax help you avoid technical debt, reduce the code that needs to be reviewed in PRs, and position your application for ongoing extension.

Key Concepts in PlotStax®

1. PlotStax handles Communication. Using high-level builders easily defined by a programmer or AI, PlotStax writes all communication code for your application. This includes services, C# and TypeScript proxies that call them, broadcasts, database access, and the wiring up of all DI bindings as well as the injection code in sub-components in both server and web page code. You always have what you need where you need it without writing any communication code (or checking the work of AI).

2. PlotStax is Deterministic. This is an important distinction of PlotStax and part of what makes it such a powerful productivity boost. Once a development team has initially reviewed code generated by PlotStax and understands what it's doing for them, additional PRs can be reviewed by only focusing on changes to the (much smaller) PlotStax builder code and the dev-managed implementation code because the PlotStax generated code is consistent and predictable. That consistency translates to time saved in PRs as well as development. LLM-based tools are not deterministic so all code generated by LLM-based tools should be reviewed carefully by both the initial developer and those approving PRs. With PlotStax, dev-managed code and tool-managed code is clearly separated. With only a small number of exceptions, code that's generated by the tool is done in files named to indicate that they're tool-managed such as "Example.g.cs" or "Example.generated.cs" depending on your preferred format. This separation helps optimize attention during code reviews, however generated code is never hidden (for example existing only in the "obj" folder at build time as is done by some other code generation strategies.)

3. PlotStax codes specifically for Flexibility, Scalability, and Maintenance. The patterns used by PlotStax have been strategically constructed to help your development effort avoid accumulation of technical debt. Major components are separated from one another using clear and consistent boundaries. These boundaries separate both functionality and data allowing both to differ per component as needed. This allows for high-level control and flexibility over the architecture of your application. For example, PlotStax allows you to seamlessly move whole components to a new ASP.NET Core Web API resource group without making any changes to dev-managed code. Because tool-managed code handles all communication, redefining where components run becomes a trivial task. Tool-managed code is nearly always organized into granular virtual methods in a base and/or partial class declaration that can be extended as needed. Typically, a corresponding stub for a dev-managed sub-class is generated for each tool-managed class.

PlotStax® and LLMs

By directing agents to use the PlotStax API instead of scaffolding applications directly, developers can assume consistency in the application structure for data types, organization, and inter-component communication mechanisms. Instead of burning time and tokens on these mechanisms agents remain focused on application logic.

Deferred Containerization Strategy

By starting with a single web API project a software developer can focus entirely on organizing component responsibilities and relationships. Components can be reassigned to separate web API projects later in the development cycle allowing time to better understand the application requirements prior to committing to any particular containerization strategy. PlotStax® will generate the communication code as needed to cross image boundaries.

When using this single container approach here are some suggestions for component design that will make the container refactoring go smoothly later:

1. Design separate components so that each one is no larger in complexity than suitable for running in a single image or container. Use separate components to isolate complexity as well as for code reuse.

2. Consider how scoped service methods might be mapped as endpoints even when not initially exposed as endpoints. For example, methods that need to take several parameters could instead take a single parameter that groups the values in a transient record. If the method is ever exposed as an endpoint, this will keep the endpoint format simple with just the single posted record.

3. If accessing cookies or authentication and authorization inside scoped services, for example to determine record level authorization for changing data, isolate this in the top level components rather than in dependency components so that those dependencies can be easily separated and run in different secured containers later without relying on anything in the top-level HttpContext.