Forem: Niko Kiirala

NATing on the cheap on AWS

Niko Kiirala — Thu, 12 Dec 2024 12:15:27 +0000

Let's consider this case: you have something running in AWS and that something needs occasional access to public internet. You can either give that something public IP addresses or there needs to be a NAT between your private network and the public internet. Let's consider this second case, setting up a NAT.

In my use case, specifically, I'm running an EC2 instance that has a small web server on it. I also have a CodePipeline + CodeBuild setup that builds and deploys a new version of the server whenever the production branch in the Git repo is pushed to. This CodePipeline + CodeBuild setup is excellently suited for running in a private network as there's no point in having it visible from the public internet. It does, however, need to fetch stuff from the public internet - get dependencies from package repositories and such. Thus I need to have a NAT gateway, but I have no need for all the bells and whistles of AWS-provided NAT gateways. Not to mention, I have just a small budget as well.

Let me be clear on one thing from the get-go: AWS-provided NAT gateways work great. Fast, stable, simple to use - all sorts of things you'd want for production infrastructure. Also I'd like to give a shout-out to alterNAT that is a production-grade replacement for NAT gateways, and from whom I've copied bits and pieces for my version.

In case you have some testing environment, low-usage servers or such, a NAT gateway can get costly. The gateway has a base fee, a per-gigabyte fee for traffic and you need to pay for a public IP, too. These can easily end up costing more than the rest of your usage - especially so if you qualify for and use free tier services.

If you're already running an EC2 instance with a public IP, it's possible to set up a NAT for no cost. Running a low-spec EC2 instance just for this purpose is fairly cheap, too. The solution is a NAT instance.

Set up the EC2 instance

You can use an EC2 instance you already have or set up a new one just for the purpose. This instance needs three important settings:

A public IP address: the NAT gateway needs to be in a public subnet, with an Internet Gateway attached, and it needs to have a public IP address. All traffic from your internal subnets will appear to originate from this IP.
Source/destination check disabled: by default, EC2 instances can only see their own traffic. Incoming traffic where the target IP is not one of the instance's own IPs is filtered out, as is outgoing traffic where source IP doesn't belong to the instance. However, when the instance is doing routing, we need it to do both, so we need to disable the check.
User data blob: this contains the necessary instructions to set up the NAT functionality at every boot. The user data blob gets processed by cloud-init that's active by default in the Amazon Linux 2023 AMI that I'm using.

I'll be using Terraform to set up my instance.

data "aws_ami" "arm64-ecs" {
  owners      = ["amazon"]
  name_regex  = "^al2023-ami-ecs"
  most_recent = true
  filter {
    name   = "architecture"
    values = ["arm64"]
  }
}

resource "aws_instance" "arm64_machine" {
  ami           = data.aws_ami.arm64-ecs.image_id
  instance_type = "t4g.small"

  availability_zone           = data.aws_availability_zones.main.names[0]
  iam_instance_profile        = aws_iam_instance_profile.machine_profile.name
  key_name                    = aws_key_pair.machine_access.key_name
  subnet_id                   = aws_subnet.main[0].id
  vpc_security_group_ids      = [aws_security_group.ecs_on_ec2.id]
  associate_public_ip_address = true
  source_dest_check           = false

  user_data                   = local.instance_cloudconfig
  user_data_replace_on_change = true

  tags = merge(local.common_tags, {
    Name             = "${local.service_name}-arm64"
  })
}

The three important bits described above are already visible in this code snippet:

associate_public_ip_address = true
source_dest_check = false
user_data = local.instance_cloudconfig

User data blob

I could build a new AMI that has the necessary bits and pieces to set up the instance to perform NAT at every boot. That's a fairly heavy process, though, so instead of that I'm using user data to drop a small script and a few configuration files to the instance at boot.

locals {
  instance_cloudconfig_data = {
    write_files = [
      {
        path = "/var/lib/cloud/scripts/per-boot/tinynat.sh"
        permissions = "0744"
        owner       = "root:root"
        content     = file("initscript/tinynat.sh")
      },
      {
        path        = "/etc/tinynat.conf"
        permissions = "0644"
        owner       = "root:root"
        content     = file("initscript/tinynat.conf")
      },
      {
        path        = "/etc/tinynat-route-table-ids.csv"
        permissions = "0644"
        owner       = "root:root"
        content     = aws_route_table.private.id
      },
      {
        path        = "/etc/tinynat-private-nets.csv"
        permissions = "0644"
        owner       = "root:root"
        content     = join(",", aws_subnet.private[*].cidr_block)
      },
    ]
  }
  instance_cloudconfig = <<-END
    #cloud-config
    ${jsonencode(local.instance_cloudconfig_data)}
  END
}

The instance_cloudconfig_data is a Terraform object, containing cloud-init instructions. Here, we drop four files in the file system: the setup script, a config file containing IDs of route tables belonging to private networks (likely just one ID), a config file containing IP address ranges of private networks that should get routed and finally a third config file that tells where to find the two other config files.

The setup script is stored under /var/lib/cloud/scripts/per-boot so that it runs every time the instance is booted up. It's making iptables changes that are not persisted across power cycles, so it needs to get run at every boot.

This script, initscript/tinynat.sh is as follows:

#!/bin/bash

# Based on alterNAT
# https://github.com/chime/terraform-aws-alternat/blob/main/scripts/alternat.sh

# Send output to a file and to the console
# Credit to the alestic blog for this one-liner
# https://alestic.com/2010/12/ec2-user-data-output/
exec > >(tee /var/log/alternat.log|logger -t user-data -s 2>/dev/console) 2>&1

shopt -s expand_aliases

panic() {
  [ -n "$1" ] && echo "$1"
  echo "tinyNAT setup failed"
  exit 1
}

load_config() {
   if [ -f "$CONFIG_FILE" ]; then
      . "$CONFIG_FILE"
   else
      panic "Config file $CONFIG_FILE not found"
   fi
   validate_var "route_table_ids_csv" "$route_table_ids_csv"
   validate_var "private_net_cidr_ranges" "$private_net_cidr_ranges"
}

validate_var() {
   var_name="$1"
   var_val="$2"
   if [ ! "$2" ]; then
      echo "Config var \"$var_name\" is unset"
      exit 1
   fi
}

# configure_nat() sets up Linux to act as a NAT device.
# See https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#NATInstance
configure_nat() {
   echo "Beginning NAT configuration"

   local adapter=ens5

   echo "Configuration before enabling NAT:"
   sysctl net.ipv4.ip_forward net.ipv4.conf.${adapter}.send_redirects net.ipv4.ip_local_port_range
   echo "iptables default"
   iptables -n -v -L
   echo "iptables NAT"
   iptables -n -v -t nat -L

   echo "Enabling NAT..."

   IFS=',' read -r -a vpc_cidrs < "${private_net_cidr_ranges}"
   for cidr in "${vpc_cidrs[@]}";
   do
      echo "Adding routing for private network ${cidr}"
      (iptables -t nat -C POSTROUTING -o ${adapter} -s "$cidr" -j MASQUERADE 2>/dev/null ||
      iptables -t nat -A POSTROUTING -o ${adapter} -s "$cidr" -j MASQUERADE) ||
      panic
   done

   iptables -N DOCKER-USER
   iptables -C DOCKER-USER -i ${adapter} -o ${adapter} -j ACCEPT 2>/dev/null ||
      iptables -I DOCKER-USER -i ${adapter} -o ${adapter} -j ACCEPT || panic

   iptables -n -v -L DOCKER-USER
   iptables -n -v -t nat -L POSTROUTING

   echo "NAT configuration complete"
}

# First try to replace an existing route
# If no route exists already (e.g. first time set up) then create the route.
configure_route_table() {
   echo "Configuring route tables"

   IFS=',' read -r -a route_table_ids < "${route_table_ids_csv}"

   for route_table_id in "${route_table_ids[@]}"
   do
      echo "Attempting to find route table $route_table_id"
      local rtb_id=$(aws ec2 describe-route-tables --filters Name=route-table-id,Values=${route_table_id} --query 'RouteTables[0].RouteTableId' | tr -d '"')
      if [ -z "$rtb_id" ]; then
         panic "Unable to find route table $rtb_id"
      fi

      echo "Found route table $rtb_id"
      echo "Replacing route to 0.0.0.0/0 for $rtb_id"
      aws ec2 replace-route --route-table-id "$rtb_id" --instance-id "$INSTANCE_ID" --destination-cidr-block 0.0.0.0/0
      if [ $? -eq 0 ]; then
         echo "Successfully replaced route to 0.0.0.0/0 via instance $INSTANCE_ID for route table $rtb_id"
         continue
      fi

      echo "Unable to replace route. Attempting to create route"
      aws ec2 create-route --route-table-id "$rtb_id" --instance-id "$INSTANCE_ID" --destination-cidr-block 0.0.0.0/0
      if [ $? -eq 0 ]; then
         echo "Successfully created route to 0.0.0.0/0 via instance $INSTANCE_ID for route table $rtb_id"
      else
         panic "Unable to replace or create the route!"
      fi
   done
}

# tinynatconfig file containing inputs needed for initialization
CONFIG_FILE="/etc/tinynat.conf"

load_config

curl_cmd="curl --silent --fail"

echo "Requesting IMDSv2 token"
token=$($curl_cmd -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 900")
alias CURL_WITH_TOKEN="$curl_cmd -H \"X-aws-ec2-metadata-token: $token\""

# Set CLI Output to text
export AWS_DEFAULT_OUTPUT="text"

# Disable pager output
# https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-pagination.html#cli-usage-pagination-clientside
# This is not needed in aws cli v1 which is installed on the current version of Amazon Linux 2.
# However, it may be needed to prevent breakage if they update to cli v2 in the future.
export AWS_PAGER=""

# Set Instance Identity URI
II_URI="http://169.254.169.254/latest/dynamic/instance-identity/document"

# Retrieve the instance ID
INSTANCE_ID=$(CURL_WITH_TOKEN $II_URI | grep instanceId | awk -F\" '{print $4}')

# Set region of NAT instance
export AWS_DEFAULT_REGION=$(CURL_WITH_TOKEN $II_URI | grep region | awk -F\" '{print $4}')

echo "Beginning self-managed NAT configuration"
configure_nat
configure_route_table
echo "Configuration completed successfully!"

And the configuration file initscript/tinynat.conf is simple two-line affair.

route_table_ids_csv=/etc/tinynat-route-table-ids.csv
private_net_cidr_ranges=/etc/tinynat-private-nets.csv

Permissions setup

The init script reads info about the route table of your internal network and modifies it so that the NAT instance is the default gateway of the internal network. In order for it to do that, the EC2 instance needs an IAM policy that allows those two actions.

data "aws_iam_policy_document" "tinynat_ec2_policy" {
  statement {
    sid    = "tinynatDescribeRoutePermissions"
    effect = "Allow"
    actions = [
      "ec2:DescribeRouteTables"
    ]
    resources = ["*"]
  }

  statement {
    sid    = "tinynatModifyRoutePermissions"
    effect = "Allow"
    actions = [
      "ec2:CreateRoute",
      "ec2:ReplaceRoute"
    ]
    resources = [
      for route_table in [aws_route_table.private.id]
      : "arn:aws:ec2:${data.aws_region.current.name}:${data.aws_caller_identity.current.id}:route-table/${route_table}"
    ]
  }
}

resource "aws_iam_role_policy" "tinynat_ec2" {
  name   = "tinynat-policy"
  policy = data.aws_iam_policy_document.tinynat_ec2_policy.json
  role   = aws_iam_role.machine_role.name
}

You'll also need to verify that your security groups allow instances in your private network to contact the NAT instance, using any protocols and ports they may need for their internet-facing traffic. Also, the NAT instance needs to be allowed to receive such traffic and to send it to public internet. Quite likely, said traffic will be TCP to port 443, aka. HTTPS connections.

Wrap-up

With all this set up, servers in your internal network should now be able to contact the public internet.

When viewing the setup through AWS web UI, the resource map of your VPC should show that your private networks are connected to the routing table you specified in local.instance_cloudconfig_data, but it won't show where that table is routing the traffic to. Viewing the route table, you should see a route with destination 0.0.0.0/0 i.e. the default route with an ENI as its target. Finally, viewing that ENI, under Instance Details there should be a link to your NAT instance.

This, I hope, makes running small-time applications and various under AWS more approachable. For me, at least, this approach provided me major cost savings for running a tiny application, since I could make my existing EC2 instance double as a NAT gateway instead of running one separately.

Compile Protocol Buffers & gRPC to Typescript with Yarn

Niko Kiirala — Wed, 27 Nov 2024 09:11:35 +0000

Earlier I explored on the high level why one might use Protocol Buffers and gRPC. Now I'll start to go into the details how this is actually implemented.

There's a web-grpc repository on GitHub that shows a full example implementation of what I describe in this post.

There are various libraries for protobuf and gRPC on web, and they have significant differences. I will use the ts-proto library - this library generates idiomatic Typescript classes at compile time from .proto message definitions, giving a good development experience. You get working autocomplete in IDE, compile-time type checking and reading and writing message fields works like with any other TS object. It also supports both protobuf and JSON wire formats for data. It does not implement gRPC out of the box, but provides support for gRPC-Web proxy connections. For my use case, where I encode gRPC as HTTP+JSON requests, there's unfortunately no direct support currently.

In order to integrate protobuf build into Yarn build pipeline, we'll need multiple parts, and unfortunately many of them are quite non-obvious to set up:

protoc compiler: reads .proto files, and uses plugins to write implementations for them in various languages
protoc plugin for Typescript: included in the ts-proto library, creates Typescript class definitions and encoding/decoding methods for them
Protocol Buffers common types, distributed as a large collection of .proto files
Compilation script to call protoc with the right parameters, paths, etc.

protoc compiler

The protoc compiler can be installed by various means. I am going to use the grpc-tools NPM package - a method not included in the official documents - since that allows building the packages with Yarn without installing additional software. The downside of this is limiting the platforms where the build can be done: ARM processors are not supported, Linux builds must be done on glibc-based distros and likely other similar limitations.

Protocol Buffer common types

Common types extend what can be described in protocol buffer messages. Some of the types, such as types for dates and times, are distributed with the compiler. Vast majority of the types are, however, distributed separately. Most importantly, we'll need the google.api.http type that is used to describe the gRPC to HTTP+JSON mapping.

There are again many ways to get the common types. They can be copied into your codebase next to your own .proto files. They can be linked as a submodule to your Git repository. I prefer not to pull this kind of dependencies to my codebase, however, so I'm using the google-proto-files NPM package.

Compilation script

It's time to put the compilation script together. The script will need to locate the protoc binary, the Typescript plugin, the common type files and your own .proto files on disk and to call the protoc binary with the correct parameters.

When using Yarn with the PnP mode of installing packages, we need special considerations. Usually Yarn in PnP mode installs packages as .zip files instead of populating a massive node_modules directory. However, running a binary from inside a .zip file is non-trivial and even if we'd manage that, the protoc binary would not know how to load a plugin or .proto files from inside a .zip file. To support such cases, Yarn allows installing packages in unplugged mode, where the contents of single packages are extracted as ordinary files on disk.

Some packages define unplugged mode by default, for example grpc-tools, but all packages might not. Either they haven't been written with PnP in mind, or their main use case might not require unplugging. To unplug these, we can add a dependenciesMeta section to our package.json.

"dependenciesMeta": {
  "google-proto-files@4.2.0": {
    "unplugged": true
  },
  "ts-proto@2.4.0": {
    "unplugged": true
  }
}

Note that the packages in dependenciesMeta are specifies with their exact version number. This number needs to match whichever version is actually installed, so I would highly recommend editing devDependencies section that these packages are imported by their exact version number, too. For example, the dependency should be "ts-proto": "2.4.0", instead of the default format "ts-proto": "^2.4.0", - note the caret in the latter one.

With the dependencies installed and unplugged, we can create a Node program to locate the various pieces and run the protoc program with correct parameters. The full version of this script is build-proto.js (GitHub)

In this script we can import the pnp module to locate any dependencies.

import pnp from '../.pnp.cjs';
pnp.setup();
const selfName = process.argv[1];

const protocPath = pnp.resolveRequest('grpc-tools/bin/protoc', selfName);
const tsExtension = pnp.resolveRequest('ts-proto/protoc-gen-ts_proto', selfName);
const protoLibsPath = pnp.resolveToUnqualified('google-proto-files', selfName);

These functions are further described in the PnP API documentation. Importantly here, resolveRequest locates a specific file inside a package, whereas resolveToUnqualified can locate directories, like the root directory of a package here. We also could use import pnp from 'pnpapi' as described in the documentation, but then this script could only be run through yarn node bin/build-proto.js. As a flip side, when importing the .pnp.cjs directly, we need to be explicit about where the build script is located compared to the package root directory.

Before invoking the compiler, we still need to locate the .proto files to compile. Here, the code is written with the assumption that the files are all located in a single directory and the directory name is passed as a command line argument to the script.

import path from 'node:path';
import { readdir } from 'node:fs/promises';

const protoDir = process.argv[2];
const protoFiles = (await readdir(protoDir))
  .filter((x) => x.endsWith('.proto'))
  .map((x) => path.join(protoDir, x).replaceAll('\\', '/'));

As an improvement, it would be useful to change this so that it recurses into any subdirectories and locates any .proto files in those, too.

Finally, the script invokes protoc with parameters derived from these.

const outputDir = 'src/proto';
const args = [
  `--plugin=${tsExtension}`,
  `--ts_proto_out=${outputDir}`,
  '--ts_proto_opt=esModuleInterop=true',
  `--proto_path=${protoDir}`,
  `--proto_path=${protoLibsPath}`,
  ...protoFiles,
];

const protoc = spawn(protocPath, args);
protoc.stdout.on('data', (data) => {
  console.log(`stdout: ${data}`);
});
protoc.stderr.on('data', (data) => {
  console.error(`stderr: ${data}`);
});
protoc.on('close', (code) => {
  console.log(`child process exited with code ${code}`);
});

Now we have the ability to run the compilation manually. In order to run it automatically whenever the package is installed, we can use the https://github.com/mhassan1/yarn-plugin-after-install plugin for Yarn. This plugin can be installed by calling yarn plugin import.

$ yarn plugin import https://raw.githubusercontent.com/mhassan1/yarn-plugin-after-install/v0.6.0/bundles/@yarnpkg/plugin-after-install.js

When installed, we can add a afterInstall clause to .yarnrc.yml configuration file.

afterInstall: yarn node bin/build-proto.js ../proto

Now, whenever we run yarn to install dependencies, the .proto files will get built automatically, too.

$ yarn
➤ YN0000: · Yarn 4.5.3
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed in 0s 259ms
➤ YN0000: ┌ Link step
➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
➤ YN0000: └ Completed
Running `afterInstall` hook...
Working directory: /workspaces/web-grpc/web-client
Script directory: /workspaces/web-grpc/web-client/bin
Script name /workspaces/web-grpc/web-client/bin/build-proto.js
/workspaces/web-grpc/web-client/.yarn/unplugged/google-proto-files-npm-4.2.0-28512554de/node_modules/google-proto-files/
Running protoc [
  '/workspaces/web-grpc/web-client/.yarn/unplugged/grpc-tools-npm-1.12.4-956df6794d/node_modules/grpc-tools/bin/protoc',
  '--plugin=/workspaces/web-grpc/web-client/.yarn/unplugged/ts-proto-npm-2.4.0-c5c2c1ec55/node_modules/ts-proto/protoc-gen-ts_proto',
  '--ts_proto_out=src/proto',
  '--ts_proto_opt=esModuleInterop=true',
  '--proto_path=../proto',
  '--proto_path=/workspaces/web-grpc/web-client/.yarn/unplugged/google-proto-files-npm-4.2.0-28512554de/node_modules/google-proto-files/',
  '../proto/notes.proto',
  '../proto/ping.proto'
]
child process exited with code 0
➤ YN0000: · Done with warnings in 1s 101ms

This setup gets us a long way to an excellent build pipeline. Without installing extra tools on your dev system, or on a build machine, this setup gives us Typescript definitions for our protobuf messages. There are improvements to be had as well. Automated builds as the .proto files are modified would be a big one. Expanding the range of supported platforms with Windows and ARM would be big, too.

In next posts I'll look into building the same .proto files for a .NET server and connecting the web client and the server together. Also, remember to check out web-grpc repository on GitHub for a full implementation of the techniques described in this post.

Strongly typed web APIs with gRPC

Niko Kiirala — Thu, 07 Nov 2024 14:46:11 +0000

Your web application receives JSON data from the server and shows it in the UI. Simple, right? Indeed, but also filled with pitfalls. Mistyped a field name in UI code? UI crashes. Server leaves out a field you thought would always be there? UI crashes. You quickly become vigilant about checking that you actually received the data you expected to receive, but it never ceases being a burden.

I’m going to describe using gRPC, a cross-platform framework for APIs, to make sure the client and the server agree on message contents. This gives us several great features:

Single source of truth. Each API is described in Protocol Buffers language, also known as a .proto file, and in that language only. From this description you can generate API code for just about any commonly used programming language out there.
Clear upgrade path. Protocol Buffer messages have clearly defined semantics for common changes like adding and removing fields from messages. Very often you can just update message description and old clients work seamlessly with new servers and old servers work with new clients as well. When the API changes are too large, it’s simple to do a versioned API.
Cross-platform. A single server implementation can easily talk to a Typescript web app, an Android app, an iOS app and more.
Compact on-wire binary format. OK, this is only partially true – a lot of what I’ll describe will use JSON as the wire format between the client and the server. But typically gRPC would use the Protocol Buffer binary format that is often significantly smaller than JSON.

What is gRPC?

The gRPC is a cross-platform framework for communicating between different pieces of software over network. It was originally developed by Google and is extensively used within Google, but is not in any way tied to them. You might think the name is related to the origins, but it obviously is just a recursive acronym for “gRPC Remote Procedure Calls”. It’s closely related to Protocol Buffers, a domain-specific language for describing messages and a binary format for storing these messages.

In a typical application, a gRPC server receives and transmits messages in Protocol Buffers binary format over a HTTP/2 channel. This works nicely for server-to-server communications and for Android, iOS, Windows, Mac, Linux, etc. applications.

For clients running inside a web browser, however, a different approach must be taken. While modern browsers can talk HTTP/2, a gRPC implementation would require a low-level access to the HTTP/2 connection, and no browser provides that and likely never will. Instead we’ll need to use some sort of a translation layer. This can either be a separate proxy server, or built-in to the application server. With this layer, the browsers can do HTTP requests as usual and the data can be transmitted either in the Protocol Buffers binary format or in the JSON format.

In browser applications, using JSON as wire format gives certain advantages. Notably the in-browser developer tools automatically pretty-print JSON messages for you, whereas it’s practically impossible to read a Protocol Buffers message in the network traffic view. This is not an all-or-nothing choice, though, since HTTP content negotiation features make it possible to write servers and clients that can use either format. For example, debug version of your app could use JSON and production version Protocol Buffers.

Typescript for write-time type checking

Typescript, an extended version of Javascript developed by Microsoft, is the modern approach in web application development to giving types to variables and for doing compile-time type checking. Not the only one, mind – for example, Google separately developed their own way of attaching type info to Javascript that used type declarations in specially formatted code comments.

Typescript helps somewhat with handling API message contents. If you manually create a type definition for the data you expect to receive, your IDE can auto-complete field names for you and immediately warn you for mistyped field names and for assuming a wrong type for a field. If your backend is also written in Typescript, you can even share the same type declaration between the server and the client. With that, you could already be fairly certain that the messages sent by the server match the ones the clients expect to receive.

It is possible to generate Typescript API interfaces and message type declarations from protocol buffer files. With this approach, you only need to declare the message types once instead of writing them separately for each programming language you use. This is especially important when modifying the message contents, such as adding new fields. If you need to update several declarations separately they are likely to diverge, but a single declaration will not.

The gRPC client libraries don’t just give compile-time type checks, but also runtime assistance. Say, what happens when you leave a field unset on the server and send the message as JSON? Depending on your JSON library and its settings, typically the field would either get left out of the message altogether or it would get set to null. The gRPC client libraries, however, ensure that the runtime object decoded from the JSON contains all the fields that were declared in the proto file at the compile time and that they are of the correct type.

Coming up

In future posts I’m going to delve into the details on how exactly the above gets done. Especially I will look into building a C#/.NET server that talks with a Typescript/React application that uses Yarn as package manager. These topics will include:

How to automatically compile .proto files
- Into Typescript code using Yarn
- Into a .NET package using csproj definition and dotnet tools
How to write a .NET single controller that talks to both native gRPC clients and to web clients
How to call these gRPC services from a React app