DEV Community: Dina Berry

GitHub Account Cleanup: Audit, Archive & Remove Stale Repos

Dina Berry — Tue, 30 Dec 2025 00:00:00 +0000

My end of year project is a GitHub account repository-cleanup tool to provide safe, repeatable auditing and cleanup for my GitHub accounts. I also wanted to create a catalog of my active repos. This repo focuses on repository-level cleanup (archive/delete/catalog), but the same audit run can help you discover candidates for cloud-resource reclamation and CI/workflow maintenance.

When to use this project

Periodic account maintenance (end-of-year or scheduled audits).
Before publishing a portfolio or transferring repositories.
When you want a reproducible audit with a dry-run-first approach.

Functionality included in GitHub account cleanup

My TypeScript project cleans up my account in the following way:

Archive stale repositories,
Detect and delete empty repositories,
Remove forks,
Generate repo descriptions and topics with LLM and update repos with that info,
Generate a catalog of active repos for publishing.

High level architecture

The high-level architecture of the npm workspace monorepo:

packages/gh-cleanup — CLI commands and orchestration: categorization rules, scoring, reporting, and the runner that coordinates dry-run and apply flows.
packages/github-rest — GitHub REST helpers, typed endpoint wrappers, and shared network utilities.
packages/llm-completion — LLM/AI utilities: prompt helpers, request wrappers, retries, and response sanitization used by the describe step.
generated/ — Example outputs created by dry-run executions: catalog.md, active.json, descriptions.json, summaries, etc.
.github - Workflows and prompt files.
scripts - Top level script to clean up GitHub account, also used by

Prerequisites

This repo can be opened with Codespaces or locally with .devcontainer/devcontainer.json. The development container has all the developer setup for this project including Node.js. Once you have the repo open with the environment, create a GitHub token and an OpenAI key and an LLM model. Set these values in the root level .env.

A GitHub token in GH_TOKEN (classic PAT with repo scopes; delete_repo only required for destructive operations such as deleting a repo.)
OpenAI key for LLM generation of repo descriptions and topics and an LLM model. I used 4.1-mini from Azure OpenAI.

GH_TOKEN=
GH_USER=YOUR_GITHUB_USER_ACCOUNT
OPENAI_API_KEY=
OPENAI_ENDPOINT=https://RESOURCE-NAME.openai.azure.com/openai/deployments/MODEL_NAME/chat/completions?api-version=API_VERSION
OPENAI_MODEL=gpt-4.1-mini
OPENAI_TEMPERATURE=0.2

Install and build dependencies

The root package.json uses npm workspaces to control and access all the packages in ./packages. Use the root package.json scripts to install and build the tool.

npm install
npm run build

Try out the tool

One-line run examples

Remove forks (dry-run):
Archive stale repos older than a year (dry-run):
Delete empty repos, no PRs, no commits, size is 0 KB (dry-run):
Categorize repos (fetch languages + README, output Markdown):
Summary (write generated/summary.md):

Full run

Once you understand what the tool does, use the ./scripts/run-all.sh to clean up your GitHub account. I used my personal dfberry account to test while building. Now that it is complete, I'll use it on my work diberry account for Microsoft.

npm run run-all:apply

The apply means empty repos are deleted and active repos are updated for description and topics.

AI-assisted development

I use AI tools (Copilot, Ask/Plan/Agent) to speed development while keeping human oversight. I commit frequently and review AI suggestions line-by-line. Choose models and session types (local, background, cloud) deliberately to control cost and behavior. Never let AI run unattended on critical changes—use dry runs and manual tests. I scaffold the repo, add features incrementally, and document decisions so I can return later. Copilot helps with comments and diagrams, but I always review and adjust its output.

Next steps

Cleanup goes beyond removing unused repositories. When tidying a personal or org GitHub account you may also:

Reclaim unused cloud resources referenced by projects (e.g., old deployments, test clusters, or storage buckets).
Remove or archive unused repositories that are forks, abandoned, or no longer relevant.
Find and fix failing or stale GitHub Actions workflows (update action versions or workflow syntax) or remove workflows that are no longer useful.
Update CI matrices and runtimes (programming language versions, OS matrix entries) to reduce CI cost and avoid testing very-old combinations.
Bump pinned GitHub Action versions and dependencies to address deprecations and security fixes.

Deploy Rust app to Azure Container App

Dina Berry — Sun, 23 Feb 2025 00:00:00 +0000

If you're a Rust developer who's just getting started with Azure, this post is for you. In this guide, I'll explore an templated repository you can use that makes deploying your Rust application to Azure Container Apps a breeze. With easy-to-use CLI tools and an automated GitHub Action workflow, deploying your app is as simple as pushing your changes to the main branch!

What's in the Repo?

This repository contains a simple Rust application built using the Axum web server. It includes:

A root route that returns HTML.
An /api/users endpoint returning JSON data.
Example configuration for environment secrets:
- PORT=3000
- MY_SECRET=1234

Easy, CLI-Powered provisioning and deployment

1. Provision Your Azure Environment

The repo ships with a set of bash scripts that take care of provisioning Azure resources. These scripts leverage:

Azure CLI – Use it to interact with and manage your Azure resources.
Azure Developer CLI (azd) – Provision and configure resources using Bicep templates.
GitHub CLI – Configure the deployment secrets necessary for GitHub Actions.

Running these scripts sets up everything from an Azure Container Registry to Application Insights in just a few commands.

2. Push-to-Main Deployments

After setting up your environment, subsequent deployments are incredibly simple:

Automated Workflow: Every push to the main branch triggers a GitHub Action that builds your Rust application and deploys it to Azure Container Apps.
Continuous Deployment: With the automation in place, you no longer need to manually deploy your app. Just push your changes—and your app is live!

3. Real-Time Monitoring and Logs

The repository includes a script (stream-logs.sh) that streams live logs from your Rust Axum server directly to your terminal. This makes it easy to:

Monitor live application activity.
Debug issues in real time.
Gain immediate insights into your app’s behavior.

Simple Rust migration to Azure

For developers new to Azure but familiar with Rust, this repository exemplifies how modern dev tools combine to simplify cloud deployments. Instead of wrestling with complex setups, you get:

A straightforward CLI-driven process.
Seamless integration with GitHub Actions.
An efficient, automated deployment pipeline that gets your app live with minimal hassle.

Repository template

https://github.com/dfberry/rust-on-azure-container-apps

Deploy an Azure Functions app from a monorepo with a GitHub Action for Node.js

Dina Berry — Sun, 07 Apr 2024 00:00:00 +0000

Azure Functions apps can be locally deployed from Visual Studio Code using the Azure Functions extension or when you create the resource in the portal, you can configure deployment. These are straightforward when your app is the only thing in the repo but become a little more challenging in monorepos.

...more

Add a database service to the API project

Dina Berry — Sun, 21 Jan 2024 00:00:00 +0000

The goal of iteration 008 is to add a database to the project.

Cloud-native-todo GitHub repo

At this point, it doesn't matter if it is no-SQL, or SQL-based because there are no relationships or transactions. Someone suggested I look at Prisma for my ORM. After some testing, I realized a free Azure SQL database wasn't going to work because, Prisma requires a 2nd database, although only temporarily, for diffing the migrations.

While I'm sure Prisma has its purpose, at this stage of the project, it seems like overkill compared to adding a database and client library I'm more familiar with. A point in the project where boring is good.

Since I'm already on Azure, selecting some flavor of SQL Server or Cosmos DB makes sense if there is a consumption (pay-as-you-go) pricing tier (SKU) which is free-ish for such as small project. Mongoose and the Cosmos DB API for MongoDB are expedient choices given the wealth of documentation for both for TypeScript/JavaScript.

Add a MongoDB container to the development environment

All the local services are managed by Docker compose for local development where possible. Add the MongoDB container so development and testing don't incur any pay-as-you-go costs.

version: "3"

services:
  api-todo:
    build:
      context: ./api-todo
    ports:
      - "3000:3000"
    depends_on:
      - mongodb

  client-todo:
    build:
      context: ./client-todo
    environment:
      VITE_USE_LOCAL_API: "true"
      VITE_API_URL: http://localhost:3000
    ports:
      - "80:80"
    depends_on:
      - api-todo

  mongodb:
    image: mongo:5.0
    restart: always
    environment:
      - MONGO_INITDB_ROOT_USERNAME=mongo
      - MONGO_INITDB_ROOT_PASSWORD=MongoPass
    ports:
      - "27017:27017"
    volumes:
      - ./mongodata:/data/db

volumes:
  mongodata:

Start the service in a separate terminal with:

docker compose up mongodb

I stole this idea from the Contoso Real Estate project which has a wealth of development environment configuration for you to use.

Now that the database is running, add the MongoDB viewer.

Visual Studio Code extension for MongoDB

Make sure you add the MongoDB viewer extension to the development environment, in the devcontainer.json.

"customizations": {
  "vscode": {
    "extensions": [
      ...other extensions,

      "mongodb.mongodb-vscode",
    ]
  }
},

You can add a connection with a connection string so this can be used for both local and cloud databases.

TODO shape

The shape of the TODO prior to this iteration was:

{
  id: 123
  title: 'Get Milk'
}

Update the shape to allow for data shape growth:

{
  id: '65ad9ad0769c2853d2804f3f',
  title: 'Get Milk',
  description: 'the oaty kind',
  createdAt: '2024-01-21T22:29:36.849Z',
  updatedAt: ''
}

The title and description should have a max size to help the UI.

Install mongoose to API

TypeScript types are already in the package so just install it.

npm install mongoose

The package.json shows "mongoose": "^8.0.4", in the dependencies property.

Connect to the database

Before jumping in with code in the API, make sure you can connect to the database with the client library. Design your schema and make sure any restrictions, validations, and transformations are complete. Leave the script in the repo, it will be handy for the next person onboarded to the project to not have to figure out how to connection and view data. Keep this connection script all as a single file. This allows someone new to the team and Mongoose to understand how the pieces fit together.

const mongoose = require('mongoose');
const Schema = mongoose.Schema;

const COLLECTION = 'TodoConnectionTest';

// Run mongo with `docker compose up mongodb`
const URI = 'mongodb://mongo:MongoPass@localhost:27017/';

const TodoSchema = new Schema(
  {
    title: {
      type: String,
      unique: true,
      minlength: 1,
      maxlength: 40,
    },
    description: {
      type: String,
      maxlength: 1000,
      default: null,
    },
    createdAt: {
      type: String,
    },
    updatedAt: {
      type: String,
      default: null,
    },
  },
  {
    versionKey: false,
    virtuals: true,
  }
);

TodoSchema.virtual('id').get(function () {
  return this._id.toHexString();
});

// Ensure virtual fields are serialised.
TodoSchema.set('toJSON', {
  virtuals: true,
  versionKey: false,
  transform: function (doc, ret) {
    delete ret._id;
  },
});

const main = async () => {
  // Connect to db
  mongoose.connect(URI);

  // Create a model
  const TodoDb = mongoose.model(COLLECTION, TodoSchema);

  // Using create
  const saveResult1 = await TodoDb.create({
    title: 'first todo',
    description: 'description',
    createdAt: new Date().toISOString(),
  });
  const transformed1 = saveResult1.toJSON();
  console.log('Created lean--------------------------------');
  console.log(transformed1);

  // ADD MORE COMMANDS

};

main()
  .then(() => {
    console.log('done');
    mongoose.disconnect();
  })
  .catch((e) => {
    console.log(e);
  });

Add a script to the package.json so you can test the connection:

"mongoose:test": "node ./scripts/test-mongo-connection.js"

TypeScript database service

Start with a generic CRUD class. All MongoDB collections will use this class to enforce consistency.

export default class CrudService<T> {
  #model: Model<T>;

  constructor(model: Model<T>) {
    this.#model = model;
  }

  // Add
  async add(doc: Partial<T>): Promise<T> {
      const improvedDoc = {
        ...doc,
        createdAt: new Date().toISOString(),
        updatedAt: null,
      };
      const data = await this.#model.create(improvedDoc);

      return data?.toJSON();
  }

  // Read
  async get(id: string): Promise<T> {

      const data = await this.#model.findById(id);

      return data: data?.toJSON();
  }

  // Update
  async update(
    id: string,
    update: Partial<T>
  ): Promise<T> {
      const improvedDoc = { ...update, updatedAt: new Date().toISOString() };

      const data = await this.#model.findByIdAndUpdate(id, improvedDoc, {
        new: true,
      });

      return data?.toJSON();
  }

  // Delete
  async delete(id: string): Promise<T> {
      const data = await this.#model.findByIdAndDelete(id);

      return data?.toJSON();
  }

  // Get All
  async getAll(): Promise<T[]> {
      const data = await this.#model.find();
      return data;
  }

  // Delete All
  async deleteAll(): Promise<unknown> {
      const deleteAllResponse = await this.#model.deleteMany({});
      return deleteAllResponse;
  }

  // Batch insert
  async seed(docs: T[] | Partial<T>[]): Promise<T[]> {
      const result = await this.#model.insertMany(docs);
      return data;
  }
}

MongoDB and the Mongoose client provide a high degree of configuration for what type of information to return from the mongoose calls. Its important to play with this in the previous script to determine what you want returned then apply those changes to this Crud class and the schema via the model that it uses.

_id versus id : MongoDB stores the unique id as _id but I want the REST API and the UI to only use id. Any transformations need to be done at this data layer. If this data service was used for automation or other movement of data between backend services, that would probably require some strict contracts so an ambitious DBA didn't make assumptions that the native _id was required.
transformation on single versus multiple items: many of the convenience functions run a query inside the mongoose client which is meant to operate on multiple values. When running queries, transformations applied to a single object (such as with create()) aren't applied to the objects. You need to either transform the objects yourself, or provide an aggregation pipeline to make sure you get the shape returned which you expect. This means your tests need to validate the shape of objects for all CRUD operations where you want data returned. You may opt to have have the transformations applied at the CRUD class level and the schema level, if the owner of the application code and the owner of the schema object definition are different people. For example, the tests might include:
- Test property property count
- Test property names
- Test that _id and _v aren't returned
- Test a new item only has the createdAt date
- Test an updated item only has the updatedAt data
data returned : the mongoose client methods can return a stunning variety of values and information. For example, when updating, the returned information can include the data set in, the data after it was updated, or include the number of items which were updated. Be clear in your design when to return what kind of information. The API layer should only return what the UI needs.

Use the CRUD class for collections

Create an interface to provide a data layer contract:

export interface IDataClass<T> {
  add: (todo: Partial<T>) => Promise<T>;
  get: (id: string) => Promise<T>;
  getAll: () => Promise<T[]>;
  update: (id: string, todo: Partial<T>) => Promise<T>;
  delete: (id: string) => Promise<T>;
  deleteAll: () => Promise<unknown>;
  batch: (todos: T[]) => Promise<T[]>;
}

If there are specific validations or transformations for a collection, apply them at a layer above the generic CRUD class.

export type CrudServiceResponse<T> = {
  data: T | T[] | unknown | null;
  error: Error | null | ValidationError | ValidationError[] | undefined;
  valid?: boolean;
};

export class TodoService implements IDataClass<Todo> {
  #service: CrudService<Todo>;

  constructor(connection: mongoose.Connection) {
    const ConnectedTodoModel = connection.model<Todo>('Todo', TodoSchema);
    this.#service = new CrudService<Todo>(ConnectedTodoModel);
  }

  async get(id: string): Promise<CrudServiceResponse<Todo>> {
    if (!id) {
      return { data: null, error: new Error('id is required') };
    }

    return await this.#service.get(id);
  }

  async add(todo: Partial<Todo>): Promise<CrudServiceResponse<Todo>> {
    const { valid, error } = isValidPartial(todo);
    if (!valid) {
      return { data: null, error: error };
    }
    const addResponse = await this.#service.add(todo);
    return addResponse;
  }

  async update(
    id: string,
    todo: Partial<Todo>
  ): Promise<CrudServiceResponse<Todo>> {
    if (!id) {
      return { data: null, error: new Error('id is required') };
    }

    const { valid, error } = isValidPartial(todo);
    if (!valid) {
      return { data: null, error: error };
    }

    const updateResponse = await this.#service.update(id, {
      title: todo.title as string,
      description: todo.description as string,
      updatedAt: new Date().toISOString(),
    } as Todo);
    return updateResponse;
  }

  async delete(id: string): Promise<CrudServiceResponse<Todo>> {
    if (!id) {
      return { data: null, error: new Error('id is required') };
    }

    return await this.#service.delete(id);
  }
  async getAll(): Promise<CrudServiceResponse<Todo[]>> {
    return await this.#service.getAll();
  }
  async seed(
    incomingTodos: Partial<Todo>[]
  ): Promise<CrudServiceResponse<Todo[]>> {
    return await this.#service.seed(incomingTodos);
  }
  async deleteAll(): Promise<CrudServiceResponse<Todo[]>> {
    const deleteResponse = await this.#service.deleteAll();
    return deleteResponse;
  }
}

Create the API routes and handlers

The API is separated between individual and multiple items.

// Multiples Routes

// Create Todo router with all routes then export it
const todosRouter = express.Router();

todosRouter.get('/', getAllTodosHandler);
todosRouter.patch('/', batchUploadTodoHandler);
todosRouter.delete('/', deleteAllTodoHandler);

// Catch-all route
todosRouter.all('*', (req, res) => {
  sendResponse(req, res, StatusCodes.NOT_FOUND, { error: 'Not Found' });
  return;
});
todosRouter.use(handleError);

// Singles Routes
// Create Todo router with all routes then export it
const todoRouter = express.Router();

todoRouter.get('/:id', getTodoHandler);
todoRouter.post('/', addTodoHandler);
todoRouter.put('/:id', updateTodoHandler);
todoRouter.delete('/:id', deleteTodoHandler);

// Catch-all route
todoRouter.all('*', (req, res) => {
  sendResponse(req, res, StatusCodes.NOT_FOUND, { error: 'Not Found' });
  return;
});
todoRouter.use(handleError);

Pull in the routes to the Express app:

// Route that operates on a single todo
app.use('/todo', todoRouter);

// Route that operates on multiple todos
app.use('/todos', todosRouter);

Test the APIs

You can use cURL, Postman, or Supertest.

## Single
curl -X GET http://localhost:3000/todo/65ac3b70d3adb5df333004d7 --verbose
curl -X POST -H "Content-Type: application/json" -d '{"todo": {"title":"CURL New Todo", "description":"This is a new todo"}}' http://localhost:3000/todo --verbose
curl -X PUT -H "Content-Type: application/json" -d '{"todo": {"title":"CURL XXX Updated Todo", "description":"This is an updated todo"}}' http://localhost:3000/todo/65ac3d1b4c60586e545b3628 --verbose
curl -X DELETE http://localhost:3000/todo/65ac396a9afd90f786ab1fee --verbose

## Multiple
curl -X GET http://localhost:3000/todos --verbose
curl -X PATCH -H "Content-Type: application/json" -d @batch.json http://localhost:3000/todos/ --verbose
curl -X DELETE http://localhost:3000/todos --verbose

import request from 'supertest';
import configureApp from './server'; // Import your Express app
import 'dotenv/config';

describe('Todo API against running MongoDB', () => {
  it('test all todo routes', async () => {
    process.env.NODE_ENV = 'test';

    const { app, connection } = await configureApp();
    await request(app).delete('/todos');

    // Add one
    const addOneResponse = await request(app)
      .post('/todo')
      .send({
        todo: {
          title: 'Sa1 - ' + Date.now(),
          description: 'Sa2 - ' + Date.now(),
        },
      });
    testAdd(addOneResponse);

    // // Update one
    const updateOneResponse = await request(app)
      .put('/todo/' + addOneResponse.body.data.id)
      .send({
        todo: {
          title: 'Su1 - ' + Date.now(),
          description: 'su2 ' + Date.now(),
        },
      });
    testUpdate(updateOneResponse);

    // // Delete `Sa1`, `Su1` should still be there
    const deletedOneResponse = await request(app).delete(
      '/todo/' + addOneResponse.body.data.id
    );
    testDelete(deletedOneResponse);

    // Batch all - after this call 3 items should be in the database
    // 3 B
    const addThreeBody = {
      todos: [
        {
          title: 'B1a ' + Date.now(),
          description: 'B1b' + Date.now(),
        },
        {
          title: 'B2a' + Date.now(),
          description: 'B2b' + Date.now(),
        },
        {
          title: 'B3a' + Date.now(),
          description: 'B3b' + Date.now(),
        },
      ],
    };
    const batchResponse = await request(app).patch('/todos').send(addThreeBody);
    testBatch(batchResponse);

    // // Get All - should return four items
    const getAllResponse = await request(app).get('/todos');
    testGetAll(getAllResponse, 3);

    // Delete All
    const deleteAllResponse = await request(app).delete('/todos');
    testDeleteAll(deleteAllResponse, 3);

    if (connection) {
      connection.close();
    }
  }, 30000);
});

Make sure you validate the data returned:

//write a function to test the shape of a Todo
const testTodoShape = (todo) => {
  const keys = Object.keys(todo);

  expect(keys.length).toEqual(5);
  expect(keys).toContainEqual('id');
  expect(keys).toContainEqual('title');
  expect(keys).toContainEqual('description');
  expect(keys).toContainEqual('createdAt');
  expect(keys).toContainEqual('updatedAt');
};
const testTodoArrayShape = (todos) => {
  expect(todos).toBeInstanceOf(Array);
  todos.forEach(testTodoShape);
};

const testAdd = (addResponse) => {
  // operational error
  expect(addResponse.error).toEqual(false);

  const { status, body } = addResponse;
  expect(status).toEqual(201);
  const { data, error } = body;
  expect(error).toEqual(null);
  expect(data).not.toEqual(null);
  testTodoShape(data);
};

const testUpdate = (updateResponse) => {
  // operational error
  expect(updateResponse.error).toEqual(false);

  const { status, body } = updateResponse;
  expect(status).toEqual(202);
  const { data, error } = body;
  expect(error).toEqual(null);
  expect(data).not.toEqual(null);
  testTodoShape(data);
};

const testDelete = (deleteResponse) => {
  // operational error
  expect(deleteResponse.error).toEqual(false);

  const { status, body } = deleteResponse;
  expect(status).toEqual(202);
  const { data, error } = body;
  expect(error).toEqual(null);
  expect(data).not.toEqual(null);
  testTodoShape(data);
};

const testBatch = (batchResponse) => {
  // operational error
  expect(batchResponse.error).toEqual(false);

  const { status, body } = batchResponse;
  expect(status).toEqual(201);
  const { data, error } = body;
  expect(error).toEqual(null);
  expect(data).not.toEqual(null);
  testTodoArrayShape(data);
};

const testGetAll = (getAllResponse, dataLength) => {
  // operational error
  expect(getAllResponse.error).toEqual(false);

  const { status, body } = getAllResponse;
  expect(status).toEqual(200);
  const { data, error } = body;
  expect(error).toEqual(null);
  expect(data).not.toEqual(null);
  expect(data.length).toEqual(dataLength);
  testTodoArrayShape(data);
};

const testDeleteAll = (deleteAllResponse, dataLength) => {
  // operational error
  expect(deleteAllResponse.error).toEqual(false);

  const { status, body } = deleteAllResponse;
  expect(status).toEqual(202);
  const { data, error } = body;
  expect(error).toEqual(null);
  expect(data).not.toEqual(null);
  expect(data.deletedCount).toEqual(dataLength);
};

Changes...

I'm sure there are choices I made I'll need to rethink or fix. Right now, I'm relying on good tests all the way through the layers.

Next step

The next step is to add this functionality to the cloud environment. Then update the UI for the new shape.

Add Azure Developer CLI deployment ID and UTC timestamp to Bicep files

Dina Berry — Mon, 08 Jan 2024 00:00:00 +0000

If you frequently deploy to Azure with Azure Developer CLI, either through your local computer or through an automated pipeline, you need a quick and obvious way to track back from the Azure resource to the pipeline or deployment.

In order to mark the deployment resource itself, use the Azure Developer CLI's deployment().name and the Bicep utcNow() function to mark your deployments. The deployment().name is the name of your environment and a timestamp (expressed as a unix timestamp).

To use these in your bicep file, a sample snippet of code is provided:

param deploymentDateTimeUtc string = utcNow()
param deploymentName string = deployment().name

You can use these variables in your Bicep to add as tags to your resources.

var tags = {
  'azd-env-name': environmentName
  'azd-deployment-id': deploymentName
  'azd-deployment-utc': deploymentDateTimeUtc
}

You can also export the variables as an environment variable to use in post-processing activities.

output DEPLOYMENT_NAME string = deploymentName
output DEPLOYMENT_DATETIME_UTC string = deploymentDateTimeUtc

If you are using Terraform instead of Bicep, with Azure Developer CLI, you still have access to the deployment name but the utcNow() is not available.

React Vite Client UI: quick Todo app proof of concept

Dina Berry — Thu, 28 Dec 2023 00:00:00 +0000

This sixth iteration of the cloud-native project, https://github.com/dfberry/cloud-native-todo, added the client UI to the monorepo.

YouTube video

Use Vite React to create basic project structure.
Add React page and components for Todo: form, list, item.
Add Tests for components.
Add API integration.

Reminder: A quick reminder that this project is using an in-memory DB at this point in the API. Each step of the way is meant to bootstrap the next step for speed instead of complete build out. This step is focusing on a bare-bones UI that interacts with the API.

Front-end framework choices and ChatGPT

This iteration is a proof of concept (POC) that can grow, as opposed to being thrown away. With that in mind, I picked Vite React as the frontend framework. I'm comfortable with React and I like the Vite toolchain.

In this day and age of ChatGPT everywhere, does it matter what framework you pick for a POC? This is up to you. Whatever answers or code your AI partner (such as ChatGPT) gives you, you still need to be able to integrate it and debug it. I suggest you pick something that you work with as though ChatGPT weren't available. If your team knows a different stack, and that stack has any duration (not built in the last year), go with that stack.

I considered Next.js, plain React, Vite React, and create-react-app (CRA). The POC needs velocity but not at the risk of the velocity or chaos of the underlying stack:

Next.js is a great framework but has its own ideas about the cloud.
Plain React means building out my own toolchain -- a waste of time compared to Next, Vite, CRA and other stacks that provide that.
Create React App has had some bumps in the road the last few years. Reminds me of the Angular 2,3,4,5 releases which is why I don't use Angular anymore.
Vite has been dependable in the last few projects so I'm sticking with that. ChatGPT answers enough of the Vite config and ViTest questions so that's a plus.

Creating the basic Vite React app

Vite has a quick ability to scaffold out the app with the CLI for a variety of front-end frameworks including React, Vue, and Svelte, and Electron. I chose TypeScript and SWC.

npm create vite@latest

This gives a basic runnable app with ESLint already configured.

{
  "name": "vite-project",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "lint": "eslint . --ext ts,tsx --report-unused-disable-directives --max-warnings 0",
    "preview": "vite preview"
  },
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@types/react": "^18.2.43",
    "@types/react-dom": "^18.2.17",
    "@typescript-eslint/eslint-plugin": "^6.14.0",
    "@typescript-eslint/parser": "^6.14.0",
    "@vitejs/plugin-react-swc": "^3.5.0",
    "eslint": "^8.55.0",
    "eslint-plugin-react-hooks": "^4.6.0",
    "eslint-plugin-react-refresh": "^0.4.5",
    "typescript": "^5.2.2",
    "vite": "^5.0.8"
  }
}

The vite.config.ts is where all the configuration goes.

Add environment variable for API

Create a .env file and add an environment variable prefixed with VITE_ for the API URL such as http://localhost:3000. When the client is deployed to the host, this URL will need to be changes and the front-end client build with the correct cloud URL. This URL is used later to build out the full API URL to fetch results:

const ENV_URL = import.meta.env.VITE_API_URL || 'http://localhost:3000';
if(!ENV_URL) {
  console.log('VITE_API_URL is not defined');
}

export const API_URL = `${ENV_URL}/todo`;

For this POC, a simple API service looks like:

import { NewTodo } from './models';

const ENV_URL = import.meta.env.VITE_API_URL || 'http://localhost:3000';
if(!ENV_URL) {
  console.log('VITE_API_URL is not defined');
}

export const API_URL = `${ENV_URL}/todo`;

export const addTodo = async (newTodo: NewTodo): Promise<Response> => {
    return await fetch(API_URL, {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify(newTodo),
      });
    };
export const deleteTodo = async (id: number): Promise<Response> => {
    return await fetch(`${API_URL}/${id}`, {
        method: 'DELETE',
      });
    };

Clean up the app

The main boilerplate for the Vite React app has a few things going on but none of which this POC needs at this point.

import { useState } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from '/vite.svg'
import './App.css'

function App() {
  const [count, setCount] = useState(0)

  return (
    <>
      <div>
        <a href="https://vitejs.dev" target="_blank">
          <img src={viteLogo} className="logo" alt="Vite logo" />
        </a>
        <a href="https://react.dev" target="_blank">
          <img src={reactLogo} className="logo react" alt="React logo" />
        </a>
      </div>
      <h1>Vite + React</h1>
      <div className="card">
        <button onClick={() => setCount((count) => count + 1)}>
          count is {count}
        </button>
        <p>
          Edit <code>src/App.tsx</code> and save to test HMR
        </p>
      </div>
      <p className="read-the-docs">
        Click on the Vite and React logos to learn more
      </p>
    </>
  )
}

export default App

Replace the contents with a pared-down component:

import './App.css'

import Todo from './todo'

function App() {

  return (
    <>
        <Todo />
    </>
  )
}

export default App

Add the page, form, list, and item

To keep the client UI clean and clear, create a new subfolder for everything for the Todo named todo.

Create the main todo page, index.tsx, which handled the events, API call, and child rerenders.

import { useState } from 'react';
import useSWR, { mutate } from 'swr';
import TodoForm from './components/form';
import List from './components/list';
import { NewTodo, Todo } from './models';
import { API_URL, addTodo, deleteTodo } from './service';
import { fetcher } from './api';

export default function Todo() {
    const [requestError, setRequestError] = useState('');
    const { data, error, isLoading } = useSWR(API_URL, fetcher)

    async function handleSubmit(newTodoItem: NewTodo) {
        setRequestError('');

        try {
            const result = await addTodo(newTodoItem);

            if (!result.ok) throw new Error(`result: ${result.status} ${result.statusText}`);
            const savedTodo = await result.json();
            mutate(API_URL, [...data, savedTodo], false);

        } catch (error: unknown) {
            setRequestError(String(error));
        }
    }

    async function handleDelete(id: number) {
        setRequestError('');
        try {
            const result = await deleteTodo(id);
            if (!result.ok) throw new Error(`result: ${result.status} ${result.statusText}`);
            mutate(API_URL, data.filter((todo: Todo) => todo.id !== id), false);
        } catch (error: unknown) {
            setRequestError(String(error));
        }
    }

    if (error && requestError) return <div>failed to load {error ? JSON.stringify(error) : requestError}</div>
    if (isLoading) return <div>loading...{JSON.stringify(isLoading)}</div>

    return (
        <div>
            <TodoForm onSubmit={handleSubmit} requestError={requestError} />
            <div>
                <List todos={data} onDelete={handleDelete} />
            </div>
        </div>
    )
}

Create the listing, components/list.tsx, to display the 3 default todos.

import { Todo } from '../models';
import Item from './item';

export type { Todo };

interface Props {
todos: Todo[];
onDelete: (id: number) => void;
}

export default function List({ todos, onDelete }: Props) {
return (

    todos.length > 0 && (
    <table style={{ width: '100%', marginTop: '20px'}} data-testid="list">
        <thead>
        <tr>
            <th >ID</th>
            <th >Title</th>
            <th >Delete</th>
        </tr>
        </thead>
        <tbody>
        {todos.map((todo) => (
            <Item
            key={todo.id}
            todo={todo}
            onDelete={onDelete}
            />
        ))}
        </tbody>
    </table>
    )
)
}

Add the Item, components/item.tsx, to display each item.

import { Todo } from '../models';

export type { Todo };

export interface ItemProps {
todo: Todo;
onDelete: (id: number) => void;
}

export default function Item({ todo, onDelete }: ItemProps) {

return (
    <tr data-testid="item-row">
    <td data-testid="item-id">{todo.id}</td>
    <td data-testid="item-title">{todo.title}</td>
    <td data-testid="item-delete">
        <button onClick={() => onDelete(todo.id)} >X</button>
    </td>
    </tr>
);
}

Add the Form, components/form.tsx, to capture a new todo item.

import { FormEvent, KeyboardEvent, ChangeEvent, useRef, useState } from 'react';
import { NewTodo } from '../models';

export type { NewTodo };

interface Props {
    onSubmit: (newTodoItem: NewTodo) => void;
    requestError?: string;
}
export default function TodoForm({ onSubmit, requestError }: Props) {
    const formRef = useRef<HTMLFormElement>(null);
    const [newTodo, setNewTodo] = useState<NewTodo>({ title: '' });

    const handleSubmit = (event: FormEvent<HTMLFormElement>) => {
        event.preventDefault();
        const formData = new FormData(event.currentTarget);
        const title = formData.get('title')?.toString() || null;

        if (title !== null) {

            onSubmit({
                title
            });
            if (formRef.current) {
                formRef.current.reset();
            }
            // Reset the newTodo state
            setNewTodo({ title: '' });
        }
    }

    const handleKeyDown = (event: KeyboardEvent<HTMLInputElement>) => {
        if (event.key === 'Enter') {
            if (formRef.current) {
                formRef.current.dispatchEvent(new Event('submit', { cancelable: true }));
            }
        }
    };
    const handleInputChange = (event: ChangeEvent<HTMLInputElement>) => {
        setNewTodo({
            title: event.target.value,
        });
    };
    return (
        <div >
            <div>
                <h1 >What do you have to do?</h1>
            </div>
            <form ref={formRef} onSubmit={handleSubmit} data-testid="todo-form">
                <div >
                    <input
                        id="todoTitle"
                        name="title"
                        type="text"
                        value={newTodo.title}
                        placeholder="Title"
                        onChange={handleInputChange}
                        onKeyDown={handleKeyDown}
                        data-testid="todo-form-input-title"
                    />
                </div>
                {requestError && (
                    <div data-testid="todo-error">
                        {requestError}
                    </div>
                )}
                <button type="submit" disabled={!newTodo.title} data-testid="todo-button">Add Todo</button>
            </form>
        </div>
    );
}

Add any dependency code such as the API service and its API fetcher for SWR, and the TypeScript models for a new todo and an existing todo.
Start the API and the client UI to use the form.

Note: This UI isn't styled and the little style that is there is mostly defaults. If you aren't comfortable with CSS or style libraries, use ChatGPT and GitHub CoPilot for this.

Add ViTest UI tests

Now that the bare bones proof of concept is working, add the UI tests to validate it. This is important so that any future changes to the app don't break existing functionality.

The tests cover the following simple cases:

renders form without error
renders form with error
renders button disabled
renders button enabled
accepts input text
submit form by button
submit form by keypress enter
item component deletes item
renders List with todos
does not render List when todos is empty

Add ViTest following the instructions for that site and a few other packages for testing UI with ViTest. Refer to the package.json for the complete list.
```
npm install -D vitest @vitest/ui
```

Create the vitest.config.ts file for configurations:

import path from 'node:path';
import { defineConfig, defaultExclude } from 'vitest/config';
import configuration from './vite.config';

const config = {
    ...configuration,
    test: {
        reporters: ['json', 'default'],
        outputFile: { json: "./test-output/test-results.json" },
        globals: true,
        setupFiles: path.resolve(__dirname, 'test/setup.ts'),
        exclude: [...defaultExclude],
        environmentMatchGlobs: [
            ['**/*.test.tsx', 'jsdom'],
            ['**/*.component.test.ts', 'jsdom'],
        ]
    },
};

export default defineConfig(config);

The outputFile keeps the output files out of the way. The setupFiles also keep the test setup files tucked away.

The hardest part about getting these tests to work was the TypeScript types for the testing library user events such as await user.type(input, title). The test setup and utility files helped with that. If you run into this, make sure to restart your TS Server in Visual Studio Code as well.

// test/setup.ts
import '@testing-library/jest-dom/vitest';

// test/utilities.ts
import type { ReactElement } from 'react';
import { render as renderComponent } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

type RenderOptions = Parameters<typeof renderComponent>[1];

export * from '@testing-library/react';

export const render = (ui: ReactElement, options?: RenderOptions) => {
    return {
        ...renderComponent(ui, options),
        user: userEvent.setup(),
    };
};

Then the User event test, such as the following, builds and runs.

test('submit form by keypress enter', async () => {

    // new title
    const title = 'Test Todo';

    // mock add function
    const mockAdd = vi.fn();

    // render the component
    const { user, getByTestId } = render(<TodoForm onSubmit={mockAdd}/>);

    // Fill in the input
    const input = getByTestId('todo-form-input-title');
    await user.type(input, title);

    // submit form by keypress
    await user.type(input, '{enter}');

    // todo submitted to parent via onSubmit
    expect(mockAdd).toHaveBeenCalledTimes(1);
    expect(mockAdd).toHaveBeenCalledWith({ title });
})

Run the test with npm run test and see the results:

Where was CoPilot in this iteration?

Where did CoPilot succeed?

CoPilot came in handy in some of the places that I'm happy to let to handle:

Quick CSS tweaks - it's much faster to play with CSS when CoPilot is generating styles over and over.
Config files - I was surprised by how much CoPilot helped with Vite and ViTest.
Components - it wrote most of the component code, I asked for refactors and it provided those as well.
Tests - it wrote most of the UI tests for me in seconds.

Where did CoPilot fail?

The tricky parts of integration, especially across tools, dependencies, and versions are still tricky. I spent the most time on the TypeScript issue with the testing library for user events. The fix came from a StackOverflow post which I had to look for. Considering all the layers involved and the time already saved in other places I used CoPilot and ChatGPT, that seems like net positive time savings for a proof of concept.

Where to next?

Now that the UI code is written and works locally, the project needs a container for the UI, and it needs to provision the UI resources for that container in the cloud. The client container needs to talk to the API container correctly. Fun stuff!

Deploy to Azure from GitHub with Azure Developer CLI

Dina Berry — Sun, 10 Dec 2023 00:00:00 +0000

This fifth iteration of the cloud-native project, https://github.com/dfberry/cloud-native-todo, added the changes to deploy from the GitHub repository:

YouTube demo

Add azure-dev.yml GitHub action to deploy from source code
Run azd pipeline config
- push action to repo
- create Azure service principal with appropriate cloud permissions
- create GitHub variables to connect to Azure service principal

Setup

In the fourth iteration, the project added the infrastructure as code (IaC), created with Azure Developer CLI with azd init. This created the ./azure.yml file and the ./infra folder. Using the infrastructure, the project was deployed with azd up from the local development environment (my local computer). That isn't sustainable or desirable. Let's change that so deployment happens from the source code repository.

Add `azure-dev.yml` GitHub action to deploy from source repository

The easiest way to find the correct azure-dev.yml is to use the official documentation to find the template closest to your deployed resources and sample.

Copy the contents of the template's azure-dev.yml file from the sample repository into your own source control in the ./github/workflows/azure-dev.yml file.

Add the name to the top of the file if one isn't there, such as name: AZD Deploy. This helps distinguish between other actions you have the in repository.

name: AZD Deploy

on:
  workflow_dispatch:
  push:
    # Run when commits are pushed to mainline branch (main or master)
    # Set this to the mainline branch you are using
    branches:
      - main
      - master

Make sure the azure-dev.yml also has the workflow_dispatch as one of the on settings. This allows you to deploy manually from GitHub.

Run `azd pipeline config` to create deployment from source repository

Switch to a branch you intend to be used for deployment such as main or dev. The current branch name is used to create the federated credentials.
Run azd pipeline config
If asked, log into your source control.
When the process is complete, copy the service principal name and id. Mine looked something like:
```
az-dev-12-04-2023-18-11-29 (abc2c40c-b547-4dca-b591-1a4590963066)
```

When you need to add new configurations, you'll need to know either the name or ID to find it in the Microsoft Entra ID in the Azure portal.

Service principal for secure identity

The process created your service principal which is the identity used to deploy securely from GitHub to Azure. If you search for service principal in the Azure portal, it takes you Enterprise app. Don't go there. An Enterprise app is meant for other people, like customers, to log in. That's a different kind of thing. When you want to find your deployment service principal, search for Microsoft Entra ID.

Go ahead ... find your service principal in the Azure portal by searching for Microsoft Entra ID. The service principals are listed under the Manage -> App registrations -> All applications.
Select your service principal. This takes you to the Default Directory | App registrations.
On the Manage -> Certificates & secrets , view the federated credentials.
On the Manage -> Roles and Administrators , view the Cloud Application Administrator.

When you want to remove this service principal, you can come back to the portal, or use Azure CLI's az ad sp delete --id <service-principal-id>

GitHub action variables to use service principal

The process added the service principal information to your GitHub repository as action variables.

Open your GitHub repository in a browser and go to Settings.
Select Security -> Secrets and variable -> Actions.
Select variables to see the service principal variables.
Take a look at the actions run as part of the push from the process. The Build/Test action ran successfully when AZD pushed the new pipeline file in commit 24f78f4. Look for the actions that run based on that commit.

Verify that the action ran successfully. Since this was the only change, the application should still have the 1.0.1 version number in the response from a root request.

When you want to remove these, you can come back to your repo's settings.

Test a deployment from source repository to Azure with Azure Developer CLI

To test the deployment, make a change and push to the repository. This can be in a branch you merge back into the default branch, or you can stay on the default branch to make the change and push. The important thing is that a push is made to the default branch to run the GitHub action.

In this project, a simple change to the API version in the ./api-todo/package.json's version property is enough of a change. And this change is reflected in the home route and the returned headers from an API call.

Change the version from 1.0.1 to 1.0.2.
Push the change to main.

Verify deployment from source repository to Azure with Azure Developer CLI

Open the repository's actions panel to see the action to deploy complete.
Select the AZD Deploy for that commit to understand it is the same deployment as the local deployment. Continue to drill into the action until you see the individual steps.
Select the Deploy Application step and scroll to the bottom of that step. It shows the same deployed endpoint for the api-todo as the deployment from my local computer.
Open the endpoint in a browser to see the updated version.

Deployment from source code works

This application can now deploy the API app from source code with Azure Developer CLI.

Tips

After some trial and error, here are the tips I would suggest for this process:

Add a meaningful name to the azure-dev.yml. You will have several actions eventually, make sure the name of the deployment action is short and distinct.
Run azd pipeline config with the --principal-name switch in order to have a meaningful name.

Summary

This was an easy process for such an easy project. I'm interested to see how the infrastructure as code experience changes and the project changes.

Supercharging DevOps: Streamlining Cloud Infrastructure with Azure Developer CLI

Dina Berry — Tue, 21 Nov 2023 00:00:00 +0000

This fourth iteration of my cloud-native project, https://github.com/dfberry/cloud-native-todo, added the steps of creating the cloud resources (provisioning) and pushing code to those resources (deployment).

YouTube playlist of videos

For this cloud-native project, I knew there would be a Docker image of the project in a registry but I wasn't sure of the fastest steps to create the image from the repository, push it to the registry or how it was pulled into the hosting environment. The authentication part to push to a registry and from which tool is usually what takes a minute or two. Anything that improved that auth flow would be welcome.

Sticking with tools I know to go as fast as possible, I used Azure Developer CLI for the infrastructure.

Install Azure Developer CLI as a dev container feature in Visual Studio Code

Installation of Azure Developer CLI into dev containers is easy with a feature. Find the feature and add it to the ./.devcontainer/devcontainer.json.

// Features to add to the dev container. More info: https://containers.dev/features.
"features": {
    "ghcr.io/azure/azure-dev/azd:latest": {}
},

Use the Visual Studio Code command palette to select Dev Containers: Rebuild and reopen in container. Check the version of the Azure Developer CLI installed with the following command:

azd version

The response:

azd version 1.5.0 (commit 012ae734904e0c376ce5074605a6d0d3f05789ee)

Create the infrastructure code with Azure Developer CLI

I've done most of this work before in other projects. I didn't really expect to learn anything new. However, GitHub Universe 2023 and Microsoft Ignite 2023 both took place between iteration 003 and my start on this iteration, 004. While I still used Copilot Chat as my pair programming buddy, I also leaned into any new feature I heard of from these two industry conferences. The Azure Developer CLI's azd init feature had an update (version 1.50) and I wanted to see what it would do. It asked Copilot Chat a couple of questions then it created the required files and folders. It took hours of Bicep development and compressed it into 30 seconds. Amazing!!!

Did it correctly configure the infrastructure for this project? Yes. When I add a second app to this project, further down the road, I'll rerun azd init in a new branch.

The azd init process created a ./next-steps.md which was a huge help in validation.

Get cloud resource environment variables from Azure Developer CLI

The next steps covered environment variables because your project may need access to cloud resource secrets, connection strings, resource names, database names, and other settings created during provisioning to complete deployment tests. Azure Developer CLI gives you access this list of environment variables with azd env get-values to create your own .env file for your project.

I created a Bash script to get those values so I could test the endpoint.

#!/bin/bash
# Usage: <script> <path-for-env-file>
# Example: ./scripts/postdeploy.sh "./api-todo-test" 
echo "postdeploy.sh"

set -x

echo "Getting param 1"
ENV_PATH="$1/.env" || ".env"
echo "ENV_PATH: $ENV_PATH"

echo "Remove old .env file"
rm -f $ENV_PATH

echo "Getting values from azd"
azd env get-values > $ENV_PATH

# Check if the .env exists
if [ ! -f "$ENV_PATH" ]; then
  echo "*** .env file not found at $1"
  exit 1
fi

# Run the npm test command
echo "Run test at $1"
cd "$1" && npm test

echo "Test completed"
exit 0

This script is called in the ./azure.yaml file in the post deployment hook:

postdeploy: 
    shell: sh
    run: |
        echo "***** Root postdeploy"
        ./scripts/postdeploy.sh "./api-todo-test"

Develop containers for cloud-native apps

When I tried to use Azure Developer CLI to provision the project with azd up, the provision failed because the CLI couldn't find the tools in the environment to build and push the image to the Azure Container Registy.

While Docker isn't specifically required to run Azure Developer CLI, it's logical to assume if I intend to create images, I need the tools to do that. Copilot advised me to create a new Dockerfile for the dev container. This would have added another level of complexity and maintenance. Instead, I chose to use a dev container feature for docker-in-docker which leaves that complexity to the owner of the feature.

Fix for dev container won't start

I love Docker and I love dev containers but occasionally containers just don't start and the error messages are so low-level that they generally aren't helpful. The whole point of containers is that they consistently work but I develop on a Mac M1 and containers sometimes don't work well with M1.

When I added the docker-in-docker feature to the Visual Studio dev container and rebuilt the container, the container wouldn't start. I changed the configs and looked at the order of features, searched StackOverflow and GitHub and chatted with Copilot. Nothing helped. Using Visual Studio Code to rebuild the dev container without the cache didn't fix it either. Which is when I knew it was my environment.

The fix was to stop the dev container, delete all containers, images, and volumes associated with the dev container and start over completely. I didn't have any other projects in dev containers so I removed everything.

# Delete all containers
docker rm -f $(docker ps -a -q)

# Delete all images
docker rmi -f $(docker images -a -q)

# Delete all volumes
docker volume rm $(docker volume ls -q)

Deploy Express.js container image to Azure

Restart the dev container and the dev container started. At this point, I tried to provision again with azd up (provision & deploy) which succeeded. It's impressive how the services just work together without me having to figure out how to pass integration information around.

Then I tried the endpoint for the API which is shown at the end of the output when azd up is done. I didn't get my project from the endpoint. The "Hello World" for containers responded at the endpoint which meant provisioning worked but deployment failed.

Find container image deployment error in Azure portal deployment log

The Azure resource group, the logical unit for all the resources in the infrastructure, has a deployment log. The Container App showed a failed status. The code is still a very simple Express.js app so the issue had to also be simple. I checked the deployment logs in the Azure portal and found the app's start script pointed to the wrong file.

Following the error to the log shows the issue that the start file is incorrect.

A quick fix to the Dockerfile.

# Wrong cmd
CMD [ "pm2-runtime", "start", "server.js" ]

# Correct cmd
CMD [ "pm2-runtime", "start", "dist/start.js" ]

Then azd up and the correct endpoint worked.

Add a version header to source code

While testing the deployment, I wanted to add versioning to the app so I knew changes to the project were displayed at the endpoint. The root request returns the version found in the ./api-todo/package.json, and the APIs return a x-api-version header with the value.

// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-ignore: Ignoring TS6059 as we want to import version from package.json
import { version } from '../../package.json';

export function setVersionHeader(_, res, next) {
  res.setHeader('x-api-version', version);
  next();
}

The curl request returns the header when using --verbose.

Add Playwright test to validate API

When I added playwright to the dev container and rebuilt the dev container, the container started but Playwright and its dependencies took up too much room. I increased the size of my container and limited by testing to Chrome. I also added the installation in the ./.devcontainer/post-create-command.sh script. By adding the installation here, when the container opens, I can see if it has enough room for a big dependency like Playwright and its browsers.

# ./.devcontainer/post-create-command.sh

#! /bin/bash
sudo apt-get clean
sudo apt update
npm i -g npm@latest
npm install
chmod -R +x ./scripts
npx playwright install --with-deps 
echo "Node version" && node -v
echo "NPM version" && npm -v
echo "Git version" && git -v
echo "Docker version" && docker --version

The Playwright for the API tests the new header and the returned array of todos.

import { test, expect } from '@playwright/test';
import dotenv from 'dotenv';
dotenv.config();

const API_URL = process.env.API_TODO_URL || 'http://localhost:3000';
console.log('API_URL', API_URL);

import { version } from '../../api-todo/package.json';

test.use({
  ignoreHTTPSErrors: true, // in case your certificate isn't properly signed
  baseURL: API_URL,
  extraHTTPHeaders: {
    'Accept': 'application/vnd.github.v3+json',
    // Add authorization token to all requests.
    'Authorization': `token ${process.env.API_TOKEN}`,
  }
});
test('should get all todos', async ({ request }) => {
  const response = await request.get(`/todo`);
  expect(response.ok()).toBeTruthy();

  // Validate the x-api-version header
  const headers = response.headers();
  expect(headers).toHaveProperty('x-api-version');
  expect(headers['x-api-version']).toEqual(version);


  // Validate the response body
  const todos = await response.json();
  expect(Array.isArray(todos)).toBeTruthy();
  expect(todos.length).toEqual(3);
});

Run the test from the workspace with npm run test --workspace=api-todo-test and see the test succeeded.

Most fun - time savings

The best part about this project is the tooling. I can spend less time and enjoy that time more.

Currently Copilot shines with technologies that have a lot of Internet coverage including docs and troubleshooting. For this particular iteration, the only place Copilot didn't help was the annoying Docker issue when the dev container wouldn't start after adding the docker-in-docker dev container feature.

Wish list item #1 - `azd test`

While Azure Developer CLI provided provisioning and deployment, it didn't add testing. This seems like a natural next step for the project. It knows what the stack is because it created the infrastructure to support it. And it knows the endpoints because it displays them at the end of the deployment. Adding API tests seems within the tool's ability someday.

Wist list item #2 - docker-in-docker

Since the infrastructure required containers and the environment had the .devcontainer folder, adding docker-in-docker as a dev container feature is probably something Azure Developer CLI can fix in the future...perhaps a YAML snippet for the dev container feature in the ./next-steps.md:

"features": {
    "ghcr.io/azure/azure-dev/azd:latest": {},
    "ghcr.io/devcontainers/features/docker-in-docker:1":{}
},

Tips

There were a few things I found useful that I use moving forward in my development in the Tips list.

Results for 004 - create resources and deploy code

Once again Copilot saved a lot of time but it took backseat to the amazing work Azure Developer CLI provided with the entire DevOps flow. And notice there wasn't any auth flow for the Container registry to deal with when pushing images. That was all wrapped up in the Azure Developer CLI auth. Another time saver.

Embarking on a Cloud-native Journey with a Todo API

Dina Berry — Fri, 10 Nov 2023 00:00:00 +0000

Our cloud-native adventure begins with the API layer - the magical bridge between the front-end UI and the back-end services. For our Todo project, we're keeping the API simple and efficient. Express.js is our chosen framework, a tried-and-true Node.js project. With the power of Copilot Chat, we'll be speeding through the process in no time!

How do you typically approach building a new API for a cloud-native project?

Fire Up the Dev Container

In the previous chapter of our journey, 002-developer-environment-setup, we set up a robust dev environment. Now, it's time to bring it to life! Open it in GitHub Codespaces or locally on your computer with Visual Studio Code (Docker installation required).

Whether you're the lead developer or part of a team, whether you're working on a familiar project or exploring new territories, you've got options. Visual Studio Code and the dev container for local work, or Codespaces for a cloud-based approach.

Stay in the dev container

If you are like me, your local computer may not be a workhorse so docker may not be started when you start working on your project. You can start using Copilot chap locally, then realize you need the dev container for something. The Copilot chat stays with the environment, it doesn't move (at this time). If you are 20 questions into your conversation with a few side trips here and there, switching environments and not having the chat to reference is frustrating.

If you are using dev containers and Copilot chat, start and stay in the container for the entire conversation.

Building an API with Copilot Chat

In just half an hour, Copilot Chat helped me create a fully functional API, complete with types, linting, tests, and a build-test workflow. Here's a sneak peek into the prompts I used:

Building a todo microservice with Node.js and TypeScript.
Adding tests for the todo API.
Refactoring server.ts for both server and test.
Modifying server.ts for CRUD operations.
Providing initial sample data.
Creating an OpenAPI yaml for the API.
Adding an OpenAPI UI route.
Setting up ESLint with Prettier.
Deciding .gitignore contents.
Moving openapi.yaml to the dist folder using tsc.
Creating a GitHub action for linting, building, and testing.
Identifying missing microservice elements.
Adding type safety.

Refining Types and Refactoring

There was some back-and-forth over types and refactoring. Copilot shone in evaluating incoming API request data. After a few prompts, the validation looked like this:

export interface Todo {
  id: number;
  title: string;
}

export interface PartialTodo {
  id?: unknown;
  title?: unknown;
}

const todoSchema = Joi.object({
  id: Joi.number().greater(0).required(),
  title: Joi.string().min(1).max(1000).required(),
}).unknown(false);

const todoPartialSchema = Joi.object({
  id: Joi.number().greater(0),
  title: Joi.string().min(1).max(1000).required(),
}).unknown(false);

export interface TodoValidation {
  valid: boolean;
  error: Error | null | string | ValidationErrorItem[];
  todo: Todo | PartialTodo | null;
}

export const validateTodo = (
  todo: PartialTodo,
  isNewTodo: boolean = false
): TodoValidation => {
  const schema = isNewTodo ? todoPartialSchema : todoSchema;
  const { error } = schema.validate(todo);
  if (error) {
    return {
      valid: false,
      error: error.details,
      todo: null,
    };
  }
  return { valid: true, error: null, todo };
};

Copilot also excelled in creating logging handlers for requests and responses, and in adding those handlers to the route.

Copilot's Strengths

Copilot gave me a flying start. While some answers lacked details, running the app or tests quickly revealed any errors, which were easy to fix.

Copilot's Weaknesses

Despite the conversation and the wealth of examples, I encountered more issues than expected. For more obscure subjects, I'd recommend breaking down the steps more atomically.

Why Not Use Existing Code?

Sure, there are plenty of examples on GitHub. But navigating licenses and attributions can be tricky. I preferred to avoid any potential missteps.

Time Investment

From start to finish, the project took about 2 hours. There were a few hiccups along the way, but each step was small, making issues manageable. Considering everything, 2 hours is a solid benchmark for a proof-of-concept project.

Cloud-native journey - developer environment setup

Dina Berry — Fri, 03 Nov 2023 00:00:00 +0000

While this project is focused on cloud-native, I set up my environment the same way for every project, with GitHub repositories and dev containers. This allows me to move from my Windows laptop, to my Mac M1, and on to GitHub Codespaces when demo-ing.

YouTube video

How do you ensure a consistent developer setup on your team? Survey

Visual Studio Code + dev containers

If you haven't heard of dev containers, let me welcome you to the club. I ❤️ dev containers.

"A development container (or dev container for short) allows you to use a container as a full-featured development environment."

Visual Studio Code has taken this idea, realized how hard Docker can be for newbies, and sorted it out so it is generally painless for beginners. By the time you want to expand beyond the beginner environment, you are ready to ask the right questions.

Meet my good friend Docker

Imagine you want to work in environments other than your current computer, and you don't want to deal with the time and complexity of installations and configurations. A general configuration will do. That's kind of the mentality that eventually (down a long dark road of VirtualBox and Vagrant) led to Docker.

There are many (many!!!) versions of Docker images on Docker Hub for you. This generally just means knowing an image's name. Some images are from manufacturers and some are from community contributions, with improvements and opinions about what the image should have.

Visual Studio Code also has some images, meant specifically for development environments. The base image supports a lot of programming languages and tools so don't feel like you need to research images just yet. The basic image will do.

Make sure Docker is running on your computer.
Make sure you have the Visual Studio Code's Dev Containers extension added.
Pick a Dev containers quickstart in the Visual Studio Docs.
My favorite is the Open an existing folder in a container.
The steps ask you questions and you answer. Its straightforward and to the point. No cumbersome CLI with many switches to understand.
It picks an image for you and asks you if you need anything else. So early in the project, you don't. You can always come back later and check a box if you need something.

Where's the AI?

This is pretty routine for me - I've been in Dockerland for many years so I haven't necessarily asked Copilot for help. However, you can always ask Copilot for advice or next steps. Make sure you have any relevant code in the main Visual Studio editor so Copilot can find the best answer.

Prompt : I need to set up a Todo microservice. What Visual Studio Code dev container would you suggest?

GitHub Copilot : For a JavaScript project using npm and React, I would suggest using a Node.js based dev container. Visual Studio Code has a predefined Node.js & TypeScript dev container that could be a good starting point.

Here's a basic setup:

Install the "Remote - Containers" extension in Visual Studio Code.
Open your project folder in VS Code.
Press F1 to open the command palette and run the "Remote-Containers: Add Development Container Configuration Files..." command.
Choose "Node.js & TypeScript" from the list.

My perspective : This isn't the entire response. Copilot immediately went into dense Docker file syntax. Visual Studio Code does a great job of keeping you out of that.

My dev container setup for Node.js and TypeScript

Here is how I set up my dev container:

I brought the dfberry/cloud-native-todo down to my local computer. You should fork then clone it if you want to do the same.
Open the local repository in Visual Studio Code.
Docker is running and the Visual Studio Code's Dev Containers extension is installed.
Reopen the folder in a New Dev Container.
That pops up a list of container configuration templates.
I selected the one which uses my language of choice: Node.js & TypeScript and an appropriate version (18). If you choose a different template, your questions may be different.
Visual Studio Code reopened with a new terminal prompt, which indicated I was in a dev container environment.
I checked the Node.js version just to make sure: node --version and got back v18.18.0. My dev container works and all I did was answer questions. For a newbie to Docker and containerization, this is a huge time saver. You will eventually know Docker, but you don't need to know it on day 1.

Where is the new dev container?

Visual Studio Code added a file to the repository found in the .devcontainer folder, named devcontainer.json. Open it up.

You'll notice some settings are commented out, you'll eventually use them, but not just yet.

For now, the most important parts are the image which is equivalent to your operating system and its additional installations, and the customizations property which is probably empty.

Since I know I want to use Copilot as my pair programmer, I need to add that to the environment. In the Visual Studio extensions, search for GitHub Copilot Chat and select Install in Dev Container. This adds the appropriate setting to the customizations property.

One final setting I use a bit is the postCreateCommand. I usually add some npm packages for developer experience here but for now I just want to make sure the correct versions of the tools are in the environment.

At this point, my devcontainer.json looks like:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/typescript-node
{
    "name": "Node.js & TypeScript",
    // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
    "image": "mcr.microsoft.com/devcontainers/typescript-node:1-18-bookworm",

    // Features to add to the dev container. More info: https://containers.dev/features.
    "features": {       
    },

    // Use 'forwardPorts' to make a list of ports inside the container available locally.
    // "forwardPorts": [],

    // Use 'postCreateCommand' to run commands after the container is created.
    "postCreateCommand": "node -v && npm -v && git -v",

    // Configure tool-specific properties.
    "customizations": {
        "vscode": {
            "extensions": [
                "GitHub.copilot-chat"
            ]
        }
    },

    // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
    "remoteUser": "root"
}

Check the dev container into source control

Now that you have a working dev container, check it into source control and ask everyone on the team to try it out. This simple container should work on all hosts (host is the term for the machine running the container). More complicated dev containers may not work the first and take some tinkering.

Where's the Cloud-Native?

You may be wondering why there isn't any cloud-native code yet. Don't worry, I'll get to it. Setting up a dev environment that works for every member of your team paves the way to a smooth development experience. Take the time to make sure the dev container is configured correctly and works for everyone.

Sample Code Repository

cloud-native-todo repo, 002-developer-environment-setup branch

Questions?

This is how I approach a consistent developer experience across a team. How do you do it? Let me know. Survey

Cloud-native journey - introduction

Dina Berry — Fri, 27 Oct 2023 00:00:00 +0000

I've been working in the Azure cloud for a few years now. The term cloud-native gets used a lot. In an effort to bridge the gap between Azure cloud and cloud-native, I'm investing some time in learning cloud-native approaches to building apps.

Along the way, I'll use and experiment with practices and tools to expedite the end result. Join me along the way, and let me know how you would have proceeded.

To start with, my tool set includes:

Visual Studio Code.
GitHub & GitHub Copilot (AI pair programming and rubber duck). Copilot provides context-aware answers within Visual Studio code.

This blog will capture the highlights. For the complete picture, head over to the GitHub repo: Cloud native repo.

What is cloud-native?

Prompt : What is cloud-native?

GitHub Copilot : Cloud-native is an approach to building and running applications that takes full advantage of the cloud computing delivery model. It is characterized by the use of containerized applications, microservices architecture, and dynamic orchestration, all of which are designed to be highly scalable, resilient, and agile. The goal of cloud-native is to enable organizations to build and deploy applications faster, with greater flexibility and reliability, while also reducing costs.

How do I begin?

Prompt : Where do I start on a new project for cloud-native?

GitHub Copilot : When starting a new project for cloud-native, there are several steps you can take to ensure that your application is designed for scalability, resilience, and agility. Here are some general steps you can follow:

Choose a cloud platform: Select a cloud platform that meets your needs and provides the services and features you require. Some popular cloud platforms include Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
Define your architecture: Define the architecture of your application, including the components, services, and data stores that you will use. Consider using microservices architecture, which can help you build more scalable and resilient applications.
Use containers: Use containers to package your application and its dependencies, making it easier to deploy and manage your application across different environments.
Use container orchestration: Use a container orchestration platform like Kubernetes to manage your containers and ensure that your application is highly available and scalable.
Use automation: Use automation tools like Ansible, Terraform, or CloudFormation to automate the deployment and management of your application.
Use monitoring and logging: Use monitoring and logging tools to track the performance and health of your application, and to identify and troubleshoot issues.
Use security best practices: Follow security best practices to ensure that your application is secure and protected from attacks.

By following these steps, you can build a cloud-native application that is designed for scalability, resilience, and agility, and that can provide a better experience for your users.

First cloud-native project?

Prompt : What is a simple project I can use for my first cloud-native project?

GitHub Copilot : A simple project that you can use for your first cloud-native project is a web application that allows users to create and manage to-do lists. This project can be built using a microservices architecture, with separate services for user authentication, to-do list management, and data storage.

My perspective

A todo list is perfect, there are plenty of examples:

Architecture

Prompt : Can you suggest a beginning architecture of a todo app which is cloud-native?

GitHub Copilot : here's a beginning architecture for a cloud-native to-do app:

Frontend: A web or mobile app that allows users to create and manage to-do lists. The frontend can be built using a framework like React, Angular, or Vue.js.
API Gateway: An API gateway that serves as the entry point for the application and routes requests to the appropriate microservices. The API gateway can be built using a tool like Kong, Istio, or AWS API Gateway.
Authentication Service: A microservice that handles user authentication and authorization. This service can be built using a tool like Auth0, Okta, or AWS Cognito.
To-Do Service: A microservice that handles the creation, retrieval, updating, and deletion of to-do items. This service can be built using a framework like Express.js, Spring Boot, or Flask.
Database: A database that stores the to-do items and user information. The database can be a SQL or NoSQL database like MySQL, PostgreSQL, MongoDB, or DynamoDB.
Container Orchestration: A container orchestration platform like Kubernetes that manages the deployment and scaling of the microservices. Kubernetes can be used to deploy the microservices as Docker containers and manage their lifecycle.
Monitoring and Logging: A monitoring and logging solution like Prometheus, Grafana, or ELK Stack that provides visibility into the performance and health of the application.

By following this architecture, you can build a cloud-native to-do app that is designed for scalability, resilience, and agility, and that can provide a better experience for your users.

More resources

Read the full conversation: Cloud native repo - introduction.

Azure OpenAI Conversational CLI with TypeScript

Dina Berry — Sun, 04 Jun 2023 00:00:00 +0000

Azure OpenAI Service provides access to OpenAI's powerful language models including the GPT-3, Codex and Embeddings model series. These models can be easily adapted to your specific task including but not limited to content generation, summarization, semantic search, and natural language to code translation.

When to use Azure OpenAI

Use this service when you want to use ChapGPT or OpenAI functionality with your own data and prompts which need to remain private and secure.

How to use Azure OpenAI programmatically

As with most other Azure services, you can use the REST APIs or language-based SDKs. I wrote my integration code with the REST APIs then converted to the JavaScript/TypeScript SDK, @azure/openai, when it released.

Usage tip :

Use the REST APIs when you want to stay on the bleeding edge or use a languages not supported with the SDKs.
Use the SDK when you need the more common integration scenarios and not at the bleeding edge of implementation.

Conversational loops

Conversational loops like those presented with ChapGPT, OpenAI, and Azure OpenAI are commonly browser-based chats provided by:

Microsoft Bot Framework - .NET and JavaScript/TypeScript
Power Virtual Agents - Enterprise - No code required

Build a conversational CLI

This conversational CLI interacts with your prompts with a small code-base. This allows you to understand the Azure OpenAI configurations, playing with the knobs and dials, while using the conversational loop and Azure OpenAI SDK to interact with it.

Remember to store and pass along the conversation so Azure OpenAI has the context of the full conversation.

Azure OpenAI conversation manager class with TypeScript

This conversation manager class is a starting point to your first Azure OpenAI app. After you create your Azure OpenAI resource, you need to pass in your Azure OpenAI endpoint (URL), key, and deployment name to use this class.

export default class OpenAIConversationClient {
  #appConfig: OpenAiAppConfig;
  #conversationConfig: OpenAiConversation;
  #requestConfig: GetChatCompletionsOptions = {
    maxTokens: 800,
    temperature: 0.9,
    topP: 1,
    frequencyPenalty: 0,
    presencePenalty: 0
  };

  #openAiClient: OpenAIClient;

  constructor(
    endpoint: string = process.env.AZURE_OPENAI_ENDPOINT as string,
    apiKey: string = process.env.AZURE_OPENAI_API_KEY as string,
    deployment: string = process.env.AZURE_OPENAI_DEPLOYMENT as string
  ) {
    this.#appConfig = {
      endpoint,
      apiKey,
      deployment
    };

    this.#conversationConfig = {
      messages: []
    };

    if (apiKey && endpoint) {
      this.#openAiClient = new OpenAIClient(
        endpoint,
        new AzureKeyCredential(apiKey)
      );
    } else {
      this.#openAiClient = new OpenAIClient(
        endpoint,
        new DefaultAzureCredential()
      );
    }
  }

  async OpenAiConversationStep(
    userText: string,
    appOptions?: OpenAiAppConfig | undefined,
    requestOptions?: OpenAiRequestConfig | undefined,
    debugOptions?: DebugOptions | undefined
  ): Promise<OpenAiResponse> {
    try {
      // REQUEST
      const request: OpenAiRequest = {
        conversation: {
          messages: [
            // add all previous messages so the conversation
            // has context
            ...this.#conversationConfig.messages,
            // add the latest user message
            {
              role: 'user',
              content: userText
            }
          ]
        },
        appConfig: appOptions ? appOptions : this.#appConfig,
        requestConfig: requestOptions ? requestOptions : this.#requestConfig
      };
      if (debugOptions?.debug) {
        debugOptions.logger(`LIB OpenAi request: ${JSON.stringify(request)}`);
      }

      // RESPONSE
      const response = await this.OpenAiRequest(request);
      if (debugOptions?.debug) {
        debugOptions.logger(`LIB OpenAi response: ${JSON.stringify(response)}`);
      }
      return response;
    } catch (error: unknown) {

      if (error instanceof Error) {
        return {
          status: '499',
          error: {
            message: error.message,
            stack: error.stack
          },
          data: undefined
        };
      } else {
        return {
          status: '498',
          error: {
            message: JSON.stringify(error)
          },
          data: undefined
        };
      }
    }
  }
  async OpenAiRequest(request: OpenAiRequest): Promise<OpenAiResponse> {
    if (
      !request.appConfig.apiKey ||
      !request.appConfig.deployment ||
      !request.appConfig.endpoint
    ) {
      return {
        data: undefined,
        status: '400',
        error: {
          message: 'OpenAiRequest: Missing API Key or Deployment'
        }
      };
    }

    const chatCompletions: ChatCompletions =
      await this.#openAiClient.getChatCompletions(
        request.appConfig.deployment,
        request.conversation.messages,
        request.requestConfig
      );

    return {
      data: chatCompletions,
      status: '200',
      error: undefined
    };
  }
}

Full sample code for Azure OpenAI library

Conversational loop

Now that the Azure OpenAI library is built, you need a conversational loop. I used commander with readline's question to build the CLI.

import { Command } from 'commander';
import * as dotenv from 'dotenv';
import { writeFileSync } from 'fs';
import { checkRequiredEnvParams } from './settings';
import OpenAIConversationClient, {
  OpenAiResponse,
  DebugOptions
} from '@azure-typescript-e2e-apps/lib-openai';
import chalk from 'chalk';

import readline from 'node:readline/promises';

// CLI settings
let debug = false;
let debugFile = 'debug.log';
let envFile = '.env';

// CLI client
const program: Command = new Command();

// ReadLine client
const readlineClient = readline.createInterface({
  input: process.stdin,
  output: process.stdout
});

function printf(text: string) {
  printd(text);
  process.stdout.write(`${text}\n`);
}
function printd(text: string) {
  if (debug) {
    writeFileSync(debugFile, `${new Date().toISOString()}:${text}\n`, {
      flag: 'a'
    });
  }
}

program
  .name('conversation')
  .description(
    `A conversation loop

        Examples: 
        index.js -d 'myfile.txt' -e '.env'        Start convo with text from file with settings from .env file
    `
  )
  .option(
    '-d, --dataFile <filename>',
    'Read content from a file. If both input and data file are provided, both are sent with initial request. Only input is sent with subsequent requests.'
  )
  .option(
    '-e, --envFile <filename>. Default: .env',
    'Load environment variables from a file. Prefer .env to individual option switches. If both are sent, .env is used only.'
  )
  .option('-l, --log <filename>. Default: debug.log', 'Log everything to file')
  .option('-x, --exit', 'Exit conversation loop')
  .helpOption('-h, --help', 'Display help');

program.description('Start a conversation').action(async (options) => {
  // Prepare: Get debug logger
  if (options.log) {
    debug = true;
    debugFile = options?.log || 'debug.log';

    // reset debug file
    writeFileSync(debugFile, ``);
  }
  printd(`CLI Options: ${JSON.stringify(options)}`);

  // Prepare: Get OpenAi settings and create client
  if (options.envFile) {
    envFile = options.envFile;
  }
  dotenv.config(options.envFile ? { path: options.envFile } : { path: '.env' });
  printd(`CLI Env file: ${envFile}`);
  printd(`CLI Env vars: ${JSON.stringify(process.env)}`);

  // Prepare: Check required environment variables
  const errors = checkRequiredEnvParams(process.env);
  if (errors.length > 0) {
    const failures = `${errors.join('\n')}`;
    printf(chalk.red(`CLI Required env vars failed: ${failures}`));
  } else {
    printd(`CLI Required env vars success`);
  }

  // Prepare: OpenAi Client
  const openAiClient: OpenAIConversationClient = new OpenAIConversationClient(
    process.env.AZURE_OPENAI_ENDPOINT as string,
    process.env.AZURE_OPENAI_API_KEY as string,
    process.env.AZURE_OPENAI_DEPLOYMENT as string
  );
  printd(`CLI OpenAi client created`);

  // Prepare: Start conversation
  printf(chalk.green('Welcome to the OpenAI conversation!'));

  /* eslint-disable-next-line no-constant-condition */
  while (true) {
    const yourQuestion: string = await readlineClient.question(
      chalk.green('What would you like to ask? (`exit` to stop)\n>')
    );
    // Print response
    printf(`\n${chalk.green.bold(`YOU`)}: ${chalk.gray(yourQuestion)}`);

    // Exit
    if (yourQuestion.toLowerCase() === 'exit') {
      printf(chalk.green('Goodbye!'));
      process.exit();
    }

    await getAnswer(yourQuestion, openAiClient);
  }
});

async function getAnswer(
  question: string,
  openAiClient: OpenAIConversationClient
): Promise<void> {
  // Request
  const appOptions = undefined;
  const requestOptions = undefined;
  const debugOptions: DebugOptions = {
    debug: debug,
    logger: printd
  };

  const { status, data, error }: OpenAiResponse =
    await openAiClient.OpenAiConversationStep(
      question,
      appOptions,
      requestOptions,
      debugOptions
    );

  // Response
  printd(`CLI OpenAi response status: ${status}`);
  printd(`CLI OpenAi response data: ${JSON.stringify(data)}`);
  printd(`CLI OpenAi response error: ${error}`);

  // Error
  if (Number(status) > 299) {
    printf(
      chalk.red(
        `Conversation step request error: ${error?.message || 'unknown'}`
      )
    );
    process.exit();
  }

  // Answer
  if (data?.choices[0]?.message) {
    printf(
      `\n\n${chalk.green.bold(`ASSISTANT`)}:\n\n${
        data?.choices[0].message.content
      }\n\n`
    );
    return;
  }

  // No Answer
  printf(`\n\n${chalk.green.bold(`ASSISTANT`)}:\n\nNo response provided.\n\n`);
  return;
}

program.parse(process.argv);

Full sample code for Conversational loop

Learn more

Learn more about how to create this Conversational CLI.

DEV Community: Dina Berry

GitHub Account Cleanup: Audit, Archive & Remove Stale Repos

Functionality included in GitHub account cleanup​

High level architecture​

Prerequisites​

Install and build dependencies​

Try out the tool​

Full run​

AI-assisted development​

Next steps​

Deploy Rust app to Azure Container App

What's in the Repo?​

Easy, CLI-Powered provisioning and deployment​

1. Provision Your Azure Environment​

2. Push-to-Main Deployments​

3. Real-Time Monitoring and Logs​

Simple Rust migration to Azure​

Repository template​

Deploy an Azure Functions app from a monorepo with a GitHub Action for Node.js

Add a database service to the API project

Add a MongoDB container to the development environment​

Visual Studio Code extension for MongoDB​

TODO shape​

Install mongoose to API​

Connect to the database​

TypeScript database service​

Use the CRUD class for collections​

Create the API routes and handlers​

Test the APIs​

Changes...

Next step​

Add Azure Developer CLI deployment ID and UTC timestamp to Bicep files

React Vite Client UI: quick Todo app proof of concept

Front-end framework choices and ChatGPT​

Creating the basic Vite React app​

Add environment variable for API​

Clean up the app​

Add the page, form, list, and item​

Add ViTest UI tests​

Where was CoPilot in this iteration?​

Where to next?​

Deploy to Azure from GitHub with Azure Developer CLI

Setup​

Add azure-dev.yml GitHub action to deploy from source repository​

Run azd pipeline config to create deployment from source repository​

Service principal for secure identity​

GitHub action variables to use service principal​

Test a deployment from source repository to Azure with Azure Developer CLI​

Verify deployment from source repository to Azure with Azure Developer CLI​

Deployment from source code works​

Tips​

Summary​

Supercharging DevOps: Streamlining Cloud Infrastructure with Azure Developer CLI

Install Azure Developer CLI as a dev container feature in Visual Studio Code​

Create the infrastructure code with Azure Developer CLI​

Get cloud resource environment variables from Azure Developer CLI​

Develop containers for cloud-native apps​

Fix for dev container won't start​

Deploy Express.js container image to Azure​

Find container image deployment error in Azure portal deployment log​

Add a version header to source code​

Add Playwright test to validate API​

Most fun - time savings​

Wish list item #1 - azd test​

Wist list item #2 - docker-in-docker​

Tips​

Results for 004 - create resources and deploy code​

Embarking on a Cloud-native Journey with a Todo API

Fire Up the Dev Container​

Stay in the dev container​

Building an API with Copilot Chat​

Refining Types and Refactoring​

Copilot's Strengths​

Copilot's Weaknesses​

Why Not Use Existing Code?​

Time Investment​

Cloud-native journey - developer environment setup

Visual Studio Code + dev containers​

Meet my good friend Docker​

Where's the AI?​

Functionality included in GitHub account cleanup

High level architecture

Prerequisites

Install and build dependencies

Try out the tool

Full run

AI-assisted development

Next steps

What's in the Repo?

Easy, CLI-Powered provisioning and deployment

1. Provision Your Azure Environment

2. Push-to-Main Deployments

3. Real-Time Monitoring and Logs

Simple Rust migration to Azure

Repository template

Add a MongoDB container to the development environment

Visual Studio Code extension for MongoDB

TODO shape

Install mongoose to API

Connect to the database

TypeScript database service

Use the CRUD class for collections

Create the API routes and handlers

Test the APIs

Next step

Front-end framework choices and ChatGPT

Creating the basic Vite React app

Add environment variable for API

Clean up the app

Add the page, form, list, and item

Add ViTest UI tests

Where was CoPilot in this iteration?

Where to next?

Setup

Add `azure-dev.yml` GitHub action to deploy from source repository

Run `azd pipeline config` to create deployment from source repository

Service principal for secure identity

GitHub action variables to use service principal

Test a deployment from source repository to Azure with Azure Developer CLI

Verify deployment from source repository to Azure with Azure Developer CLI

Deployment from source code works

Tips

Summary

Install Azure Developer CLI as a dev container feature in Visual Studio Code

Create the infrastructure code with Azure Developer CLI

Get cloud resource environment variables from Azure Developer CLI

Develop containers for cloud-native apps

Fix for dev container won't start

Deploy Express.js container image to Azure

Find container image deployment error in Azure portal deployment log

Add a version header to source code

Add Playwright test to validate API

Most fun - time savings

Wish list item #1 - `azd test`

Wist list item #2 - docker-in-docker

Tips

Results for 004 - create resources and deploy code

Fire Up the Dev Container

Stay in the dev container

Building an API with Copilot Chat

Refining Types and Refactoring

Copilot's Strengths

Copilot's Weaknesses

Why Not Use Existing Code?

Time Investment

Visual Studio Code + dev containers

Meet my good friend Docker

Where's the AI?

My dev container setup for Node.js and TypeScript

Where is the new dev container?

Check the dev container into source control

Where's the Cloud-Native?

Sample Code Repository

Questions?

What is cloud-native?

How do I begin?

First cloud-native project?

Architecture

More resources

When to use Azure OpenAI