Forem: Anna

On Facing Extinction (Again)

Anna — Fri, 19 Dec 2025 22:47:10 +0000

This week I was cleaning up my old work laptop before I return it (oh yeah, I quit AWS 🎉), and I finally got around to reading one of the many open tabs that had been lingering in Brave for the past few months of re:Invent madness: AI's Dial-Up Era by Nowfal Khadar, which I found to be a well-reasoned and measured take on where we are in regards to AI - namely, in a similar place we were in the mid-90s with the internet as a whole. There was one particular parallel he drew that stuck with me, about how the journalism industry was disrupted by the ascension of the internet during that time.

Most people I've worked with don't know this, but before I was a software engineer, I was a journalist. While journalism was something I fell into as a way to pay the rent while striving to be a writer, there was absolutely a part of me that idolized Hunter S. and Hemingway and the many others who long ago went deep to find truths and share them with the masses.

Unfortunately, by the time I entered the industry in the mid-2000s, it was in the process of falling apart and transforming into its present, degraded state. There was no going deep and truth was now a tangential goal, replaced by SEO and appeasing Google rankings long enough to survive another day.

So I left journalism and got into tech. This was around 2015, when startups were all the rage and unicorns were getting crowned left and right. I started learning to code online while working as a writer for a startup doing tech events, and eventually was creating content for startup founders while dreaming of becoming one myself.

It actually took several more years (and a move across the world and a coding bootcamp) before I landed a software engineering role, but I was lucky enough to still catch the tail end of the developer heyday, something I had completely missed by the time I was working at a newspaper a decade before.

So now we get to today; another decade has passed, and I'm facing the dilemma of being in yet another industry facing extinction. My fear is that just like with journalism, it will be to the detriment of society as a whole.

This juxtaposition in particular stood out to me in Nowfal's piece, where he asks if there will be more or fewer software engineers with the rise of AI:

To answer this question, go back to 1995 and ask the same question but with journalists. You might have predicted more journalists because the internet would create more demand by enabling you to reach the whole world. You’d be right for 10 or so years as employment in journalism grew until the early 2000s. But 30 years later, the number of newspapers and the number of journalists both have declined, even though more "journalism" happens than ever. Just not by people we call journalists. Bloggers, influencers, YouTubers, and newsletter writers do the work that traditional journalists used to do.

The same pattern will play out with software engineers. We’ll see more people doing software engineering work and in a decade or so, what "software engineer" means will have transformed. Consider the restaurant owner from earlier who uses AI to create custom inventory software that is useful only for them. They won’t call themselves a software engineer.

One aspect of this transformation he fails to mention is how much worse off we are because of this. Yes, democratization of information as a whole is a net positive, but in that process with journalism we lost expertise. Just as optimizing for SEO led to poorer writing quality (not to mention transforming a creative process into a soul-crushing one), optimizing for likes and subscribes has led to content that values sensationalism over truth. When "fact checker" is no longer a role that exists outside of a very few dying institutions, truth is no longer the outcome - and that was before AI started creating whole new realities.

Newspapers used to have subject matter experts, fact checkers, embedded reporters, and probably another dozen roles I'd never heard of because they were gone by the time I got into the trade. Similarly, an engineering team has frontend and backend experts, devOps, appsec engineers, support engineers (ideally), UX, and so on - not to mention doc writers, developer advocates, etc., which you don't need if you're just building an app for your local restaurant, but presumably some people will still make software they want to sell. Will we get to a place where those experts only exist in dying institutions that we call FAANG today? Will the expectation of software actually working well and bugs being fixed be a thing of the past?

Though there is a core difference between journalism and software's role in shaping a society, in that a free and truth-seeking press is essential to a functioning democracy, but apps are not. If anything, the last decade before AI has led to the enshittification of much of the software we use daily, so perhaps democratization will create a bulwark against the monopolies that allow enshittification to take hold (one can dream).

Or maybe that won't happen. Today, when anyone can create journalistic content, most people still consume it from others. I imagine once anyone can create software, most will still consume it from a smaller cohort of builders (though that cohort will probably be much larger than those of us employed as developers today). One thing I am pretty certain about is that the highly-paid, highly sought after senior engineer will become increasingly rare. Just as for every Christiane Amanpour there are millions of bloggers doing journalism at widely varying quality and for a lot less money, those highly-paid roles someone out of bootcamp could get a few years ago will become much rarer and require a lot more expertise.

And we may still be in the middle of the transformation of journalism from what it was into something that once again seeks truth as its goal, and that transformation might just be helped by the democratization of software development.

Either way, at least I'll be a little more ready for this disruption than I was twenty years ago.

RIP CRA - Now what?

Anna — Wed, 02 Jul 2025 02:17:13 +0000

Maybe I'm strange, but I always feel a little sad when an app or framework that has been a regular part of my workflow goes to the great repository in the sky. That was certainly my initial reaction after hearing that Create React App (or CRA to its friends) was being deprecated. My second reaction: now what do I use?

Luckily, the React team put up a list of possible CRA replacements as part of the deprecation announcement, and in this post I'm going to focus on the first option: Next.js. Why? IMO it offers the most features for going above and beyond just a simple migration. But we'll get into that later.

Comparing CRA with Next.js

If you're new to Next.js, here's a quick breakdown of its 1:1 feature equivalents for CRA users, as well as potential server-side functionality:

If you used this in CRA	Client-side equivalent in Next.js	Server-side possibility in Next.js
`npx create-react-app`	`npx create-next-app`	`npx create-next-app` (same, supports both modes)
`--template typescript`	`npx create-next-app --ts`	Full TypeScript setup for both client and server components
`react-router`	File-based routing in `pages/`	App Router with nested layouts and server components
`react-helmet`	`next/head`	Dynamic `<head>` updates in server components
Static file serving at `public/`	Same - uses `public/`	`next/image` with built-in image optimization
Fetch data in `useEffect`	`useSWR` or `fetch()` in a client component	Fetch data directly in server component, RSC fetch
Component state with `useState`	`useState` in client components (`'use client'`)	Server-rendered props via RSC + cookies/session context
Local dev server with Webpack	Webpack (built-in)	Webpack + incremental adoption of Turbopack
Environment variables in `.env`	Same, plus bundle for the browser with `NEXT_PUBLIC_` prefix	Same, plus runtime env vars via Docker image
BYO backend/server	Requires separate Node server	Built-in API routes (`/api/`)
Testing with Jest	User-installed Jest or Vitest	User-installed Jest or Vitest (no native test runner)
CSS with plain files or modules	Global CSS and CSS Modules supported, built-in code-splitting	Full support for Tailwind, Sass, PostCSS, and scoped CSS

The initial setup and much of the configuration of Next.js will seem familiar to CRA users. Like CRA, Next.js has a one-line init command: npx create-next-app. For TypeScript users, adding the --ts flag means your project is automatically configured for TypeScript, much like the --template typescript flag for CRA. Both frameworks ship with Webpack, but Next.js also includes Turbopack, a newer and in most cases more performant bundler from the Next.js team. For testing, CRA uses Jest under the hood, while Next.js leaves it up to the user to choose a testing library.

The main differences between the two frameworks mainly come down to the features Next.js offers that aren't available in CRA. These can be divided into two categories: performance improvements and developer experience (DX) improvements.

Performance improvements:

Server-Side Rendering (SSR) for faster initial loads
Image optimization for responsive, lazy-loaded images
Built-in code splitting by default at the page level
Edge and serverless function support

DX improvements:

File-based routing, so no need to manually configure routes
API routes - build backend logic right in your app
Built-in support for layouts and nested routing in the App Router
Next.js Middleware makes A/B testing, i18n, etc. much easier to implement

Now that we've seen how Next.js compares feature-for-feature with CRA, the next question is: why make the switch at all?

Why migrate?

If you have a legacy app or side project that hasn't been updated in years, you may be wondering why bother migrating if the CRA setup is working? For deployed apps, the answer is vulnerabilities: at some point, you or dependabot will need to update a library with high severity vulnerabilities, and will likely run into the dreaded Conflicting peer dependency error. As CRA's dependencies are no longer being updated, that error is more likely to occur the longer you wait.

Additionally, you'll need to migrate if you want to get newer versions of core libraries such as TypeScript or React. While React 19 currently works with CRA, TypeScript is sadly stuck at version 4, meaning you won't get the speed or size improvements or expanded ESM support of version 5.

But the best reason to migrate is to take advantage of Next.js server-side features and built-in optimizations. So, let's explore some migration strategies next.

Migrating an existing CRA app to Next.js with client-side features only

If you're ready to migrate an existing CRA app to Next.js but want to start with a 1:1 move that keeps your app functioning as a single-page client-side app (SPA), the pages/ directory is the best place to begin. This setup allows you to preserve familiar patterns while getting immediate benefits like built-in routing.

Let's walk through migrating a simple component; in this case, a minimal login UI from a CRA app:

// src/App.tsx
import { useState } from 'react';

export default function App() {
  const [user, setUser] = useState<string | null>(null);

  const handleLogin = async () => {
    const res = await fetch('/login', { method: 'POST' });
    const data = await res.json();
    setUser(data.name);
  };

  return (
    <div>
      {user ? (
        <p>Welcome, {user}!</p>
      ) : (
        <button onClick={handleLogin}>Log In</button>
      )}
    </div>
  );
}

In Next.js, we would first create pages/index.tsx, to replace src/App.tsx, then move the component mostly as-is to the new file:

// pages/index.tsx
import { useState } from 'react';

export default function Home() {
  const [user, setUser] = useState<string | null>(null);

  const handleLogin = async () => {
    const res = await fetch('/api/login', { method: 'POST' });
    const data = await res.json();
    setUser(data.name);
  };

  return (
    <main>
      {user ? (
        <p>Welcome, {user}!</p>
      ) : (
        <button onClick={handleLogin}>Log In</button>
      )}
    </main>
  );
}

This is still a purely client-side component. You get immediate access to Next.js features like routing without giving up control over how your app behaves. To complete the example, we also need to add a login endpoint under pages/api/:

// pages/api/login.ts
import type { NextApiRequest, NextApiResponse } from 'next';

export default function handler(req: NextApiRequest, res: NextApiResponse) {
  const user = { name: 'Jane Doe' };
  res.status(200).json(user);
}

Pretty straightforward, with minimal code changes. Of course, in a large codebase, things can get more complex, so if you want to see what a migration like this looks like in practice, see this commit of a working example app. If you have an existing CRA app that you're ready to migrate to Next.js, you can follow this step-by-step migration guide.

The migration guide and commit linked above offer examples of straightforward, 1:1 SPA migrations. But to really take advantage of Next.js, let's see what a migration to using server-side rendering (SSR) looks like.

Migrate a SPA to React Server Components

While migrations are often done out of necessity, they can also serve as an opportunity to make significant performance improvements and modernize a legacy app's architecture. Refactoring an SPA to use server components will reduce your client-side JavaScript bundle size, improving initial load times and your users' experience. Server components also allow for resolving authentication state server-side, which has the added benefit of being more secure while also reducing load times. And the final bonus: server-rendered content is better for search engines, if SEO is important to you. React Server Components go one step further than SSR, allowing parts of the component tree to render only on the server, never reaching the client as JavaScript.

What does this look like in practice? Let's return to our authentication example, now migrated to the App Router. In a server component like app/page.tsx, we use cookies() to access login state directly from the server:

// app/page.tsx
import { cookies } from 'next/headers';
import { LoginButton } from './LoginButton';

export default function Home() {
  const user = cookies().get('user')?.value;

  return (
    <main>
      {user ? <p>Welcome, {user}!</p> : <LoginButton />}
    </main>
  );
}

Only the LoginButton component remains client-side. This keeps the interactive part of the app lightweight, while moving the auth check to the server where it belongs:

// app/api/login/route.ts
import { NextResponse } from 'next/server';

export async function POST() {
  const user = { name: 'Jane Doe' };

  const res = NextResponse.json(user);
  res.cookies.set('user', user.name, {
    httpOnly: true,
    maxAge: 60 * 60,
  });

  return res;
}

This structure allows the app to render personalized content without requiring a round trip to the client to determine the user's session. It's a small change that brings meaningful performance and security improvements. To see what this looks like in an existing codebase, this commit from the same repository referenced earlier shows a migration from client components to using server-side API routes and middleware.

Stretch goal: implement Partial Prerendering for the best of both worlds

If you want to go even further into Next.js's experimental features, you can implement Partial Prerendering (PPR) in the same component. While React Server Components are great for applications that need real-time dynamic data, and static generation is great for infrequently updated data, such as content from a CMS, PPR is a new feature that gives you the best of both. PPR uses React Suspense to separate dynamic content from static content, allowing Next.js to pre-render the static content at build time, while dynamic content is streamed at runtime from the server.

Here's an example of our auth component using PPR. First, we'd create a dynamic user component and skeleton:

// app/user.tsx
import { cookies } from 'next/headers';

export async function User() {
  const name = cookies().get('user')?.value;
  return <p>Welcome, {name ?? 'Guest'}!</p>;
}

export function UserSkeleton() {
  return <p>Loading user...</p>;
}

Then, using Suspense, we designate the dynamic part of our page while allowing the remainder to load as static content:

// app/page.tsx
import { Suspense } from 'react';
import { User, UserSkeleton } from './user';

export const experimental_ppr = true; // This enables PPR for the entire app/ route

export default function HomePage() {
  return (
    <main>
      <h1>This content is statically prerendered</h1>

      <Suspense fallback={<UserSkeleton />}>
        <User />
      </Suspense>
    </main>
  );
}

With just a few tweaks, our legacy CRA auth code has evolved into a modern, flexible component that plays nicely with both static and dynamic rendering.

So yes, it's always a little sad to say goodbye to an old tool, especially one that's been part of your team's routine. But as we've seen, moving from CRA to Next.js doesn't mean starting over. It just means migrating to a more flexible, more capable way of building React apps.

Return to the World of AI Mechanics

Anna — Thu, 05 Jun 2025 02:55:43 +0000

It's been over a year since I wrote Entering the World of AI Mechanics, and I happened to come back to it today as I've been reading and thinking a lot about the role of AI in engineering as well as in the wider world.

A year is long enough for several quantum leaps in genAI. Of course new models have come out since then, but the fact that I wrote this before agentic AI was not only a thing, but a regular part of my workflow, makes it feel quaint.

A year ago, my main experience with AI was adding it as a code snippet-generating tool to one of the apps I work on in my Day Job, and thus my point of view came from thinking about the user experience of a feature we added that wouldn't always act in the way a user (or us, the programmers) expected it to, and how to adjust to that uncertainty. Our users were used to software that always had the same result from the same input, and if it didn't, they'd file a ticket, as clearly we had introduced a regression that needed to be fixed. The genAI feature broke that contract between us and our users, and suddenly we had to account for unexpected results as well as unexpected reactions.

As a user though, back then genAI was an occasionally helpful, often wrong, ever-annoying chatbot that was being forced on me at work and invading other software I relied on in nonintuitive, rarely useful ways. That AI very much still exists today, and I ignore it much as I did a year ago. Sure, generating images or recipes from ChatGPT has been entertaining and somewhat useful, but not enough to become a habit.

What changed between then and now is agentic AI. The difference between chat and agents is that I actually want to use the latter now, because it's not only not terrible, it's actually helpful for select tasks. My go-to example is writing unit tests, because:

They have a well-defined scope and purpose
In a production codebase, there are plenty of examples to give the LLM to show style, which testing library to use, mocking examples, etc.
I fucking hate writing them

It's been a huge boost to my productivity to tell the AI that I updated the code for myAwesomeFunction.ts, can you now update the tests in myAwesomeFunction.test.ts for me? And the best part is, agentic AI will make the changes, run the tests, then revise as needed on its own until tests, type checks, linting, etc. all pass, all while I'm moving on to working on the next feature.

This is AI that actually has a purpose; I'm not losing anything by not copy-pastaing code from similar tests, there is no test writer on our team that will lose their job because of this, and even junior developers will benefit from not having to do as many tedious tasks as they learn the codebase.

The caveat here is that at this moment, agents should mainly be used for these kinds of tedious, well-defined tasks, as they still fall apart when given more complexity to work with, even with good guidelines. Additionally, the more complex tasks are the ones I want to do myself; writing code with the user and developer experience in mind is something I know I can do a hell of a lot better than an LLM right now, and it's also something I enjoy doing (for the most part). I may still tag in an agent to help with debugging, but they're serving the role of a rubber duck more often than actually being helpful.

But back to my original post, and particularly this part:

Quantum physics only applies at the subatomic level. Once you have a mass of atoms comprising, for example, a ball, it behaves in a very classical way. Perhaps masses of software, say at an enterprise or at the infrastructure level, should behave in a classical, predictable, and repeatable way.

Yesterday, I read Steve Yegge's Revenge of the junior developer (I'm late to the party, I know. Two months is a geological era these days). The part that hit me the hardest was "Part 5: The agent fleet is coming", because OF COURSE IT IS. This has become so apparent to anyone using agents and seeing people already starting to build workflows where two agents interact with one another, or open-source tooling that lets you pull in multiple agent instances. Fleets are coming, and while I'm ambivalent about the direction this will lead software engineering teams, I'm hopeful in that they may be the answer to the uncertainty I feel when using LLMs today.

If one LLM is a quantum particle, and agents are several particles interacting at the quantum level, my hope is that fleets bring us back to the classical world of more certain outputs.

Entering the World of AI Mechanics

Anna — Fri, 31 May 2024 19:17:32 +0000

Update: I returned to this world a year later, with some updated thoughts.

I’ve been thinking a lot lately about how working with LLMs is spooky, as in “spooky action at a distance” spooky, and some parallels to the world of physics have come up in my mind.

We’re going through a paradigm shift in tech right now, which is a dramatic statement to make at any time and is often incorrect (ahem, blockchain). But given the size of the current #genAI bandwagon, it feels not far off to say that things will not be the same once LLMs are widely adopted.

Being somewhat of a physics buff, I can’t help but see comparisons between what’s currently happening in genAI and what happened when quantum mechanics was introduced into a classical mechanics world, as both brought about a dramatic change in thinking.

In classical mechanics, if you roll a ball from point A, and you know the exact force it was pushed with and the amount of resistance, you’ll know when it will reach point B. If it doesn’t reach point B when you expected it to, something is wrong with your calculations, not with the laws of physics.

The world of classical computing is much like the world of classical mechanics: input A should always result in output B. Sure, there are complexities and race conditions, but for the most part, whatever code you’re writing is likely to be buggy because you didn’t think of some side effect, not because the logic suddenly changed on you.

Not so with LLMs. Input A sometimes results in output B, sometimes in output C, and sometimes in “I’m sorry, I can’t answer that question right now”. And so we enter the quantum world of probabilities, where an atom is X% likely to be in a given position, but you will never be 100% sure until you measure it.

We can give LLMs safeguards and engineer our prompts in specific ways, but the chance that an answer is what we expect will always be a probability, not a guarantee; we’re never sure of the output until it’s measured by the user’s reaction.

That means as engineers, we need to change our mindsets, from building in a world of known laws to building in a world of probabilities, and optimizing for the best average or consistent result.

We also need to realize that for the average user, this will initially appear as a degradation: we went from presenting sure outputs to widely varying outcomes given the same input, which can be jarring at best and a poor experience at worst.

Rolling out half-baked products without sufficiently sure probabilities of valid results is a good way to frustrate users; no disclaimer will alleviate a bad initial user experience. Most users still live in the classical world, and rather than meeting them where they’re at and easing them into quantum outputs, we’re pulling out the rug and hoping we’ve engineered our prompts correctly, when “correct” is actually a percentage and not a bool.

There’s a final parallel, though: quantum physics only applies at the subatomic level. Once you have a mass of atoms comprising, for example, a ball, it behaves in a very classical way. Perhaps masses of software, say at an enterprise or at the infrastructure level, should behave in a classical, predictable, and repeatable way.

That means that there are places and use cases for LLMs, but there also very much areas that should stay classical, where probability is detrimental to the experience, and the blanket “put an AI on it” push is counterproductive. We’re still learning where that line is, but until we do, maybe some use cases should remain in the classical world.

Generative (A)IaC in the IDE with Application Composer

Anna — Thu, 18 Jan 2024 19:14:47 +0000

TL;DR: New tutorial dropped using App Composer + gen AI! Get the tutorial repo or read on to follow along!

AWS Application Composer launched in the AWS Console at re:Invent one year ago, and this re:Invent it expanded to the VS Code IDE as part of the AWS Toolkit - but that’s not the only exciting part. When using App Composer in the IDE, users also get access to a generative AI partner that will help them write infrastructure as code (IaC) for all 1100+ AWS CloudFormation resources that Application Composer now supports.

Better than docs

Application Composer lets users create IaC templates by dragging and dropping cards on a virtual canvas that represent AWS CloudFormation resources, and wiring them together to create permissions and references. Initially launching with support for 13 core serverless resources such as AWS Lambda, Amazon S3, and DynamoDB, in September our team launched support for all 1100+ resources that AWS CloudFormation allows, updated regularly. That means that users can now build with everything from Amplify to XRay, and hundreds of resources in between.

However, while the 13 enhanced resources come with defaults based on best practices, standard AWS CloudFormation resources come only with basic configuration - generally required settings only, with a type set by a schema rather than an example. So a user adding an Amplify App resource would be given the following configuration by default:

  MyAmplifyApp:
    Type: AWS::Amplify::App
    Properties:
      Name: <String>

And they would see this in the console:

That’s well and good for the AWS CloudFormation expert, but someone new to IaC or even just that resource would then have to go into the CloudFormation docs to find additional properties and determine their types, or scour the web for example configurations that may or may not fit their use case. Luckily, the newest App Composer feature saves builders those steps - and uses generative AI to generate resource-specific configurations with safeguards right in the IDE.

When working on a CloudFormation or SAM template in VS Code, users can sign in with their Builder ID and generate multiple suggested configurations in App Composer - here’s an example for our AWS::Amplify::App type:

These suggestions are specific to the resource type, and are safeguarded by a check against the CloudFormation schema to ensure valid values or helpful placeholders. You can then select, use and modify the suggestions to fit your needs.

So we now know how to generate a simple example with one resource, but let’s look at building a full application with the help of AI-generated suggestions.

Building together with AI

You may be aware of Serverlessland, a treasure trove of developer-centered content and examples of serverless applications. I decided to take one of their more popular (and AI-focused) tutorials, titled “Use GenAI capabilities to build a chatbot”, and recreate it with App Composer and our trusty AI assistant. Here we go!

Getting started with the AWS Toolkit in VS Code

First of all, if you don’t yet have the AWS Toolkit extension, you can find it under the Extensions tab in VS Code. Install or update it so you’re at least on version 2.1.0, and you’ll see a screen like this that mentions Amazon Q and Application Composer:

Next, to enable our AI assistant, we need to enable CodeWhisperer using our Builder ID. The easiest way is to open Q, and select authenticate - you should be taken to this screen, where you can select the Builder ID option and be taken to the browser to create or sign in with your Builder ID.

If all goes well, you’ll see your connection in the VS Code toolkit panel:

Once you’re connected, you’re ready to start building!

Composing your architecture

In a workspace, create a new folder and a blank file called template.yaml. Open template.yaml, and you should see the Application Composer icon in the top right. Click on it to initialize App Composer with a blank canvas. Now we can start building our application.

You may have noticed that the tutorial includes an architecture diagram that looks like this:

First we’re going to add the services in the diagram to sketch out our application architecture - with the added bonus of creating a deployable CloudFormation template.

From the Enhanced components list, drag in a Lambda function and a Lambda layer.
Double-click the Function resource to edit its properties. Rename the Lambda function’s Logical ID to LexGenAIBotLambda.
Change the Source path to src/LexGenAIBotLambda, and the runtime to Python.
Change the handler value to TextGeneration.lambda_handler, and click Save.
Double-click the Layer resource to edit its properties.
Rename the layer Boto3Layer and change its build method to Python. Change its Source path to src/Boto3PillowPyshorteners.zip, and click Save.
Finally, connect the layer to the function to add a reference between them.

You can follow along with the video to see this in action:

You’ll see that your template.yaml file has now been updated to include those resources (and some auto-generated ones, such as a Lambda log group for your function). If you go into your source directory, you’ll see some generated function files. Don’t worry about those - we’ll replace them with the tutorial function and layers later.

So that was the easy part - you added some resources and generated IaC that includes best-practices defaults. Next we'll explore using standard CloudFormation components.

With a little help from our (AI) friend

Let’s start by searching for and adding several of the Standard components needed for our application. These include the types AWS::Lambda::Permission, two roles of type AWS::IAM::Role, and one AWS::IAM::Policy. Some standard resources will have all the defaults you need. For example, when you add the AWS::Lambda::Permission resource, all you have to do is replace the placeholder values.

Other resources, such as the IAM Roles and IAM Policy, have bare-bones config. This is where our AI assistant comes in handy! Choose an IAM Role resource and click Generate suggestions.

Because these suggestions are generated by an LLM, they will likely differ between each generation, but they are tailored to be specific to each resource and to follow valid CloudFormation schema - so go ahead, generate away!

Generating different configurations will give you an idea of what a resource’s policy should look like, and will often give you keys that you can then fill in with the values you need. Below are the actual settings we’ll be using for each resource, so you can replace the generated values when applicable - be sure to replace each resource’s Logical ID as well!

# CfnLexGenAIDemoRole - type AWS::IAM::Role
AssumeRolePolicyDocument:
  Statement:
    - Action: sts:AssumeRole
      Effect: Allow
      Principal:
        Service: lexv2.amazonaws.com
  Version: '2012-10-17'
ManagedPolicyArns:
  - !Join
    - ''
    - - 'arn:'
      - !Ref AWS::Partition
      - ':iam::aws:policy/AWSLambdaExecute'

# LexGenAIBotLambdaServiceRole - type AWS::IAM::Role
AssumeRolePolicyDocument:
  Statement:
    - Action: sts:AssumeRole
      Effect: Allow
      Principal:
        Service: lambda.amazonaws.com
  Version: '2012-10-17'
ManagedPolicyArns:
  - !Join
    - ''
    - - 'arn:'
      - !Ref AWS::Partition
      - ':iam::aws:policy/service-role/AWSLambdaBasicExecutionRole'

# LexGenAIBotLambdaServiceRoleDefaultPolicy - type AWS::IAM::Policy
PolicyDocument:
  Statement:
    - Action:
        - lex:*
        - logs:*
        - s3:DeleteObject
        - s3:GetObject
        - s3:ListBucket
        - s3:PutObject
      Effect: Allow
      Resource: '*'
    - Action: bedrock:InvokeModel
      Effect: Allow
      Resource: !Join
        - ''
        - - 'arn:aws:bedrock:'
          - !Ref AWS::Region
          - '::foundation-model/anthropic.claude-v2'
  Version: '2012-10-17'
PolicyName: LexGenAIBotLambdaServiceRoleDefaultPolicy
Roles:
  - !Ref LexGenAIBotLambdaServiceRole

# LexGenAIBotLambdaInvoke - type AWS::Lambda::Permission
Action: lambda:InvokeFunction
FunctionName: !GetAtt LexGenAIBotLambda.Arn
Principal: lexv2.amazonaws.com

Finally, let’s add our Lex bot! In the resource picker, search for and add type AWS::Lex::Bot. Here’s another chance to see what configuration the AI comes up with!

Change the Lex bot’s Logical ID to LexGenAIBot and update its configuration to the following:

DataPrivacy:
  ChildDirected: false
IdleSessionTTLInSeconds: 300
Name: LexGenAIBot
RoleArn: !GetAtt CfnLexGenAIDemoRole.Arn
AutoBuildBotLocales: true
BotLocales:
  - Intents:
      - InitialResponseSetting:
          CodeHook:
            EnableCodeHookInvocation: true
            IsActive: true
            PostCodeHookSpecification: {}
        IntentClosingSetting:
          ClosingResponse:
            MessageGroupsList:
              - Message:
                  PlainTextMessage:
                    Value: Hi there, I'm a GenAI Bot. How can I help you?
        Name: WelcomeIntent
        SampleUtterances:
          - Utterance: Hi
          - Utterance: Hey there
          - Utterance: Hello
          - Utterance: I need some help
          - Utterance: Help needed
          - Utterance: Can I get some help?
      - FulfillmentCodeHook:
          Enabled: true
          IsActive: true
          PostFulfillmentStatusSpecification: {}
        InitialResponseSetting:
          CodeHook:
            EnableCodeHookInvocation: true
            IsActive: true
            PostCodeHookSpecification: {}
        Name: GenerateTextIntent
        SampleUtterances:
          - Utterance: Generate content for
          - Utterance: 'Create text '
          - Utterance: 'Create a response for '
          - Utterance: Text to be generated for
      - FulfillmentCodeHook:
          Enabled: true
          IsActive: true
          PostFulfillmentStatusSpecification: {}
        InitialResponseSetting:
          CodeHook:
            EnableCodeHookInvocation: true
            IsActive: true
            PostCodeHookSpecification: {}
        Name: FallbackIntent
        ParentIntentSignature: AMAZON.FallbackIntent
    LocaleId: en_US
    NluConfidenceThreshold: 0.4
Description: Bot created demonstration of GenAI capabilities.
TestBotAliasSettings:
  BotAliasLocaleSettings:
    - BotAliasLocaleSetting:
        CodeHookSpecification:
          LambdaCodeHook:
            CodeHookInterfaceVersion: '1.0'
            LambdaArn: !GetAtt LexGenAIBotLambda.Arn
        Enabled: true
      LocaleId: en_US

Once all of your resources are configured, your application should look like this:

In case your template looks different or you want to double-check your configuration, you can copy the template directly from my Github repository. You’ll want to copy the Lambda layer directly from the repository, and add it to ./src/Boto3PillowPyshorteners.zip. Finally, rename the generated handler.py to TextGeneration.py and replace the placeholder code with the following:

import json
import boto3
import os
import logging
from botocore.exceptions import ClientError

LOG = logging.getLogger()
LOG.setLevel(logging.INFO)

region_name = os.getenv("region", "us-east-1")
s3_bucket = os.getenv("bucket")
model_id = os.getenv("model_id", "anthropic.claude-v2")

# Bedrock client used to interact with APIs around models
bedrock = boto3.client(service_name="bedrock", region_name=region_name)

# Bedrock Runtime client used to invoke and question the models
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=region_name)


def get_session_attributes(intent_request):
    session_state = intent_request["sessionState"]
    if "sessionAttributes" in session_state:
        return session_state["sessionAttributes"]

    return {}


def close(intent_request, session_attributes, fulfillment_state, message):
    intent_request["sessionState"]["intent"]["state"] = fulfillment_state
    return {
        "sessionState": {
            "sessionAttributes": session_attributes,
            "dialogAction": {"type": "Close"},
            "intent": intent_request["sessionState"]["intent"],
        },
        "messages": [message],
        "sessionId": intent_request["sessionId"],
        "requestAttributes": intent_request["requestAttributes"]
        if "requestAttributes" in intent_request
        else None,
    }


def lambda_handler(event, context):
    LOG.info(f"Event is {event}")
    accept = "application/json"
    content_type = "application/json"
    prompt = event["inputTranscript"]

    try:
        request = json.dumps(
            {
                "prompt": "\n\nHuman:" + prompt + "\n\nAssistant:",
                "max_tokens_to_sample": 4096,
                "temperature": 0.5,
                "top_k": 250,
                "top_p": 1,
                "stop_sequences": ["\\n\\nHuman:"],
            }
        )

        response = bedrock_runtime.invoke_model(
            body=request,
            modelId=model_id,
            accept=accept,
            contentType=content_type,
        )

        response_body = json.loads(response.get("body").read())
        LOG.info(f"Response body: {response_body}")
        response_message = {
            "contentType": "PlainText",
            "content": response_body["completion"],
        }
        session_attributes = get_session_attributes(event)
        fulfillment_state = "Fulfilled"

        return close(event, session_attributes, fulfillment_state, response_message)

    except ClientError as e:
        LOG.error(f"Exception raised while execution and the error is {e}")

To deploy your infrastructure, go back to the App Composer extension, and click the Sync icon. You'll need to have local IAM credentials and the AWS SAM CLI installed, so grab it if you don't already have it. Follow the guided AWS SAM instructions to initiate and complete your deployment.

If all goes well, you’ll see the message SAM Sync succeeded and can navigate to CloudFormation in the AWS Console to see your newly-created resources.

If you want to continue with building your chatbot, be sure to follow the rest of the original tutorial to keep building.

Go build - with help!

I hope that building with AI-generated CloudFormation will help increase your understanding of the different resource settings that are available and commonly used, and accelerate your time from idea to deployed application. As with everything using generative AI today, be sure to read the AWS Responsible AI Policy before applying these examples yourself. Happy building!

A version of this post was originally published over at the AWS Compute Blog - give them a follow to keep up with all things AWS!

The Loneliness of Trying to #EmbraceEquity in FAANG

Anna — Thu, 16 Mar 2023 00:30:39 +0000

This year's theme for International Women's Day at my employer was #EmbraceEquity, with a slate of women-led talks and panels and some truly inspiring stories of women rising in the ranks of Amazon and AWS.

And I love that we're calling out the problem and (in theory) actively working on it, though we still have such a long way to go.

In practice, though, my day-to-day interactions look like this:

with the occasional

(if you know, you know :sevh:)

And then, inspired by a tweet from a colleague, I did the math on my actual team, the people I interact with 90% of the time at work:

and all the hope and optimism IWD is supposed to inspire was brought crashing down by reality.

Don't get me wrong: I am incredibly lucky to work on a respectful, collaborative team of allies, and I have never felt discriminated by my immediate coworkers - they're awesome dudes! But there is something incredibly lonely about never (or hardly ever, if you count Slack) interacting with another member of your gender in your role. I'm jealous of my colleagues that don't have to feel that loneliness, and in my experience, no amount of women in tech meetups can fill that day-to-day gap.

So what can we do about it?

I realize that the bigger the company, the more that equity is a marathon, not a sprint. A startup can hire two new engineers and suddenly the numbers are much closer to 50/50. At a FAANG, this process takes years and requires not just desire from the bottom, but buy-in from the top. And the top... well, let's just say it's even lonelier than I am:

Source

This is compared to all corporate employees, which unfortunately are not broken down by job roles, as based on my experience over the past 1.5 years, the numbers for AWS specifically and all engineering roles are much worse:

The good news is that the numbers are getting better! But for someone working day to day in a very male-dominated environment, that change still feels far too slow. AWS has shown numerous times that when something matters, leadership can act much faster in a concentrated effort. I can only hope that this pledge to #EmbraceEquity results in more action than words.

Why Visual Building Matters (Especially for Serverless)

Anna — Fri, 02 Dec 2022 00:45:35 +0000

My team launched a thing today, and while there are so many features I can talk about (and many more to come), it’s a visual builder after all, so let me visually demonstrate what AWS Application Composer does:

// Detect dark theme var iframe = document.getElementById('tweet-1598433433390575616-488'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1598433433390575616&theme=dark" }

In a nutshell, you can drag and drop serverless resources such as Lambda functions, API Gateway APIs, EventBridge rules, etc. onto a canvas, connect them to each other to add permissions, and out comes CloudFormation YAML with best practices baked in!

Oh yeah, and we're using the File System Access API to save all of this to your local disk, so you can quickly push to git and deploy what you've built using the AWS SAM CLI 🤯

So why does this matter, especially in the serverless ecosystem? Because while there are numerous solutions for diagramming architectures, you then still have to learn how to provision those resources and get all of the permissions right for them to actually work. Before today, that usually meant learning to code that architecture in some sort of proprietary framework.

How visual building delivers the promise of serverless

The promise of serverless was initially this: focus on your business logic, and let the cloud provider take care of the rest. Somehow, that promise evolved into "here are 153 ways to provision 200+ resources via yaml". And then CDK came along, and made that process friendlier for developers, but it still requires learning how to code resources in a specific framework. So here's a novel idea:

Forget code, at least when it comes to your infrastructure! Save it for your Lambda logic and the things that differentiate your application. The world doesn't need more Terraform experts, but it does need cloud architects and devOps engineers who can quickly spin up infrastructure.

Oh, and with App Composer you get the bonus of being able to visualize existing architectures too, which is a killer feature when onboarding new team members:

// Detect dark theme var iframe = document.getElementById('tweet-1598470067779686401-849'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1598470067779686401&theme=dark" }

Anyway, I’m mostly excited to finally be able to talk about what I’ve been working on the past ~8 months 😅 App Composer is a frontend-only, canvas-based service, so stay tuned if you want to know more about how we actually built the thing.

Now excuse me while I go sleep for a week.

Crickets, or hey, I work for a FAANG now and everything is NDA

Anna — Fri, 08 Apr 2022 22:54:08 +0000

The other week, I hit my six-month milestone at AWS. It's been... intense. Mostly in good ways! My team is still mainly my old startup team, plus some great new people that fit right in with us. There's always so much to learn, and most other engineers are supportive and happy to answer my noob questions. And in addition to writing code, thanks to Amazon's famous writing culture, I've also been writing a ton in general. The problem is, none of it is writing I can share on here.

Hence... crickets 🦗.

And I have no side project tutorials to document, because, well, that whole work-life balance thing is real and necessary and I'd rather be snowboarding than hacking away on a new project on my weekends, so that's what I've been doing.

Proof

I even got my first speaking gig in over two years later this month... at an internal conference I can't share.

So I guess this is more of an explanation of my absence from this wonderful Dev community over the last nine or so months, and probably ongoing absence in the near future, until there's something I can publicly write about related to my work. Or maybe until the winter season ends and I feel like hacking together another silly serverless abomination for fun, not profit, one weekend. TBD.

So. It feels pretty silly to write a whole blog post about not being able to write blog posts, but here we are.

But because you took the time to read my silly rantings, you should at least be rewarded with a picture of my cat resting happily on her window perch. Less code, more cats: that's a promise I can keep for now.

A Gentle Reminder to Take a Vacation

Anna — Thu, 20 May 2021 17:56:38 +0000

I landed on my own Github profile the other day, which is a pretty rare occurrence as I'm usually looking for repos in my company's account, but I was in search of a tutorial project I had done a while back. It had been a minute, and I noticed the Github wizards had further expanded the contributions panel (yay, code reviews are finally acknowledged!). But I also saw something more disturbing: too much green.

Let me explain.

I started coding for a living in 2018. This is what my contributions look like from that year:

The big gap in May is the period between finishing code school and getting a job in June (during which I went to Mexico, because YOLO). There's a gap in September when I took a week off to meet my parents in San Francisco and drive up through the redwoods with them back to Portland (highly recommended), and then a winter holiday break in December into January 2019.

Next, there's 2019, my first full year of working as a software engineer:

There are some solid gaps in there: May 2019, when family from Poland came to visit and we toured up and down the West Coast. October, when I flew to Germany and Poland for more family time and a wedding. Another couple of weeks off for the holidays in December-January. Good times.

And then... 2020.

I suppose this one won't be too surprising - there was this little thing about a global pandemic and all:

Wow, so solid green it would give that subway station envy. Ok, there's one little gap: in October, around my birthday, I took a road trip to the Alvord Desert (also highly recommended). But that didn't even last a full week.

And yeah, it makes sense. We were in lockdown. There was literally nowhere to go most of the year, and a pandemic killing millions that made even weekend trips seem like unnecessary risks. Understandable.

But what I saw that disturbed me was my 2021 so far:

Pretty dang solid. And possibly on the road to burnout (anyone else feel that?).

Luckily, I'm now fully vaccinated, and taking my first full week off next week to go on a road trip (by car, to a pretty remote area, because the pandemic's not over). Even planning it a few weeks back felt strange, as if vacations are another thing the pandemic took away. But that doesn't have to be the case.

So, for whoever needs to hear it: this is a gentle reminder to take a vacation. Even if you can't go anywhere yet, your mind and body need time away from the green squares. You'll thank yourself later.

Global State in Gatsby, or Having and Eating Your Cake, Too

Anna — Tue, 04 May 2021 00:00:32 +0000

Gatsby is a fantastic way to build and maintain static websites. React is a fantastic way to build and maintain dynamic web applications. But what if one wants to dream the ~~impossible~~ improbable dream of having your static cake while eating it dynamically, too? (Too many metaphors, I know.)

This was the problem I encountered when I needed to add and persist user data across an existing Gatsby site, without screwing up what was already there. Hopefully this will help the next developer who also dares to dream that improbable dream.

The big Why?

First of all, why was I setting out on this improbable task of adding global state to a static site? Was I so bored at work that my PM decided to let me run amok and make Gatsby harder? Not quite (though I do look forward to that day).

In reality, we were implementing a new feature that requires users to log in to be authenticated with Github, so that we could have access to visualize and run an audit on a private repository. That means we needed to persist that user state across several components, like the navbar that showed a different button depending on the user's logged-in state, as well as the components handling the audit logic. Thus far, we'd only used local state in the site, scoped to each component doing its thing. This was going to be a whole new world of Gatsby functionality for me.

Finding imperfect solutions

The first task I set upon myself was research: was there a Gatsby plugin that could already do what I needed? (Spoiler alert: nope). How about existing tutorials? I already knew what I needed: global state throughout my Gatsby app. I needed to learn the how, or at least be pointed to potential solutions. This short blog post on global state in Gatsby gave me a great start, and led me to consider React's Context as a potential solution.

The next step for me is always: read the docs! Specifically, the React Context docs. Providers! Consumers! Ok, this sounds like exactly what I need, except this was the React example...

class App extends React.Component {
  constructor(props) {
    super(props);

    this.toggleTheme = () => {
      ...
    };
  }

  render() {
    return (
       <ThemeContext.Provider value={this.state.theme}>
           <Toolbar changeTheme={this.toggleTheme} />
       </ThemeContext.Provider>
    );
  }
}

ReactDOM.render(<App />, document.root);

Huh. React apps have an App component. Gatsby apps do not. So I needed a Gatsby-specific way to do this Context thing. More research!

How about the Gatsby docs? That's where I found this incredibly helpful tutorial on React Context with Gatsby, which got me started on the right path. Unfortunately, it's from 2019, which may as well be the prehistoric era when we're talking about React advancements. The example uses class components and no hooks (😱), and is all the way back in React 16.3, while we'd already been in the trenches with 16.8, and were up to 17. What are we, savages? It was definitely time for an update.

Cake-baking time

With a decent understanding of React Context from their docs, as well as knowing I wanted to implement global state using React Hooks, specifically useContext() and useState(), I set about customizing and updating the sample code I had found to work for my use case.

Building a user context and provider

In a nutshell, React Context is a way to set and use global state without passing a prop to every component that needs it. Instead, you create a Context, then set a Provider that provides that context throughout the application, and a Consumer that, well, consumes (or makes available) that context. Then, you use the useContext() hook to get the value of the global state object and, if needed, the function that sets the value in individual components.

In my src directory, I created contexts/UserContext.js and added the following:

// ./src/contexts/UserContext.js
import React, { createContext, useEffect, useState } from 'react';
import { getCurrentUser } from '../utils/cognito';

const defaultState = {
  user: {
    loggedIn: false,
    userid: null,
    username: null
  },
  setUser: () => {}
};

const UserContext = createContext(defaultState);

const UserProvider = (props) => {
  const [user, setUser] = useState(defaultState.user);

  useEffect(async () => {
    const currentUser = await getCurrentUser();
    if (currentUser) {
      // Set the current user in the global context
      setUser(prevState => {
        return {
          ...prevState,
          loggedIn: true,
          userid: currentUser.id,
          username: currentUser.email
        };
      });
    }
  }, []);

  const { children } = props;

  return (
    <UserContext.Provider
      value={{
        user,
        setUser
      }}
    >
      {children}
    </UserContext.Provider>
  );
};

export default UserContext;

export { UserProvider };

Here, we're setting a defaultState - anyone who's used Redux should be familiar with that concept. It's the blank state every user visiting the website starts with.

Next, we're using React's createContext API to create a context object based on our default values for user and setUser.

Then, we use the useState hook to set the user object, and initialize the setUser function that will be used to update that global user object.

The next hook we use is useEffect - this was a new one for me, but essentially it's the Hooks-y way of triggering a ComponentDidMount / ComponentDidUpdate lifecycle event. When it's initialized with an empty array as in the example above, it acts as ComponentDidMount, in that it's only executed once on a render. That's perfect for our use case, as I want to call an async function called getCurrentUser (which is using the AWS Cognito API in the background to fetch user data), and if the user is already logged in, use the setUser hook to update the user object. If not, nothing happens and the user is still in the default state.

Finally, we use

    <UserContext.Provider
      value={{
        user,
        setUser
      }}
    >
      {children}
    </UserContext.Provider>

to wrap all of the children elements with the context of user and setUser. Then we export both UserContext and UserProvider, as we'll need both throughout our codebase.

Wrap that root

So remember that example from the React docs that wrapped the root App component in the Provider? Yeah, that's not gonna work with Gatsby. Luckily, Gatsby has a super-handy wrapRootElement API that basically does the same thing, and it's implemented in gatsby-browser like so:

// ./gatsby-browser.js
import React from 'react';
import { UserProvider } from './src/contexts/UserContext';

export const wrapRootElement = ({ element }) => (
  <UserProvider>{element}</UserProvider>
);

That's all there is to it! Now each component will have access to the UserProvider context.

What the Provider provides, the Consumer consumes

Next, we need a place for the UserProvider Consumer. This should be a parent element to the child components that will need access to the user context. In my codebase, I chose the Layout component, as it wraps just about every page of the site and is where we have another Provider already, the ThemeProvider. Your implementation may vary in this regard, but it's safe to say that most Gatsby starters do include a universal Layout component of some sort.

// ./src/layouts/Layout.jsx
import React, { Fragment } from 'react';
import { ThemeProvider } from '@emotion/react';
import { Footer, NavBar } from 'layouts';
import UserContext from '../contexts/UserContext';

const Layout = (props) => {
  return (
    <ThemeProvider theme={theme}>
      ...
      />
      <UserContext.Consumer>
        {user => (
          <Fragment>
            <NavBar />
            {props.children}
            <Footer />
          </Fragment>
        )}
      </UserContext.Consumer>
    </ThemeProvider>
  );
};

As we can see, it's possible to use multiple Providers and Consumers within one app, though we'll keep our focus on the UserContext.Consumer.

Because we initialized

const UserContext = createContext(defaultState);

back in the context, we can access both UserContext.Provider and UserContext.Consumer. The code above just places the consumer above all the children components of the app. Because of the way the Consumer is set up, it requires a function as a child. That's why we have <UserContext.Consumer> {user => (...)}</UserContext.Consumer>.

Note that we're not passing the user object to the NavBar component here, though we very well could with <NavBar user={props.user} setUser={props.setUser} />. But then, how would we pass that same data to {children}? That's where the handy useContext() hook comes in!

Hooks or it didn't happen

So we've got our Provider, we've got our Consumer in the site's Layout component, and now we need to pull the user object and, in some cases, the setUser function from the global context. Let's start with our NavBar component, which will either render a button or an icon depending on whether a user is logged in or not:

Logged out view

Logged in view

// ./src/layouts/NavBar.jsx
import React, { useContext } from 'react';
import UserContext from '../contexts/UserContext';
import { signOut } from '../utils/cognito';

const NavBar = () => {
  const { user, setUser } = useContext(UserContext);
  const handleSignOut = () => {
    signOut();
    setUser({
      user: {
        loggedIn: false,
        username: '',
        userid: ''
      }
    });
  };

  return (
    <Header>
      <Nav className='navbar navbar-expand-lg fixed-top'>
        <a href='/' className='navbar-brand'>
          <img src={logo} />
        </a>
        <ul>
          ...other nav items
          <li className='nav-item nav-button'>
            {user && user.loggedIn
              ? <UserIcon handleSignOut={handleSignOut} username={user.username}/>
              : <a href='https://app.stackery.io/'><Button type='button' text='Sign In' /></a>
            }
          </li>
        </ul>
      </Nav>
    </Header>
  );
};

Let's start right at the top: we've got our useContext hook, and like a magical fairy pulling a bag of gold out of thin air, useContext pulls user and setUser out of the React ether and assures us that they're the global values our app depends on!

So with const { user, setUser } = useContext(UserContext);, we can now see if the user object exists, and if user.loggedIn is true, we'll show a component called UserIcon that shows the user icon and has a dropdown that allows the user to sign out. And as we can see in handleSignOut(), we use setUser to update the global user state back to the defaults when the user has signed out.

Context in class components

Finally, we've got a class component where we also need access to the user object and setUser function. There are two options for this: if you have a direct parent component that's a functional component, you can pass those values as props like so:

// ./src/pages/Registry.jsx
import React, { useContext } from 'react';
import { RegistryContainer } from 'components/registry';

const Registry = () => {
  const { user, setUser } = useContext(UserContext);

  return (
    <Layout>
        ...
       <RegistryContainer user={user} setUser={setUser} />
    </Layout>
  );
};

export default Registry;

Then in RegistryContainer, we access user and setUser just as we would any other props in a class component:

// ./src/components/registry/RegistryContainer.jsx
import React, { Component } from 'react';

class RegistryContainer extends Component {
  constructor (props) {
    super(props);
    ...
    }

  async componentDidUpdate (prevProps, prevState) {
    const {
      user
    } = this.props;

    if (user.loggedIn && !user.githubAuthState) {
      // do the oauth things!
      ...
      // then update global user
        this.props.setUser({
          ...this.props.user,
          githubAuthState: githubAuthStates.AUTHED
        });
    }
  }
  ...
  render () {
    return (
      <RegistryForm
        ...
        user={this.props.user}
      />
    );

Option two, which I did not end up implementing, uses the contextType class property, and would look something like this:

// example from https://www.taniarascia.com/using-context-api-in-react/
import React, { Component } from 'react';
import UserContext from '../contexts/UserContext';

class HomePage extends Component {
  static contextType = UserContext;

  componentDidMount() {
    const user = this.context

    console.log(user) // { name: 'Tania', loggedIn: true }
  }

  render() {
    return <div>{user.name}</div>
  }
}

Either way should work depending on your codebase, I just went for the clean and simple useContext() option throughout.

The cake is not a lie!

And there we go: we've got access to our user anywhere we fancy on our Gatsby site, and all it took was a little bit of Context.

So now, if a user is logged in and on the Registry page, they'll see the same state in two different components:

And if they're logged out, all the components know:

Hope this is helpful to future Gatsby tinkerers, and feel free to ask questions or point out bugs (no, using semi-standard is not a bug) in the comments. And if you'd like to see this functionality live in the wild, check out stack.new for yourself!

Alexa, How Can I Win an Echo (and learn to build an Alexa app)?

Anna — Tue, 15 Dec 2020 18:03:58 +0000

Build an Alexa Skill with Stackery for re:Invent and get an Amazon Echo Dot!

As this year's virtual, three-week AWS-palooza that is re:Invent 2020 wraps up, I'm sure many of you are as eager as I am to implement some of that new knowledge.

One thing I learned just before re:Invent that I thought I'd share is how to create and deploy an Alexa Skill. Turns out, if you have a tutorial to follow, it's not too hard at all!

So my company decided to encourage others to get into the Skills game by sending out Echos to anyone who deploys. So, want to learn something new and get some free stuff? Read on!

How to enter and get an Echo Dot

Follow the tutorial below to build an Alexa quiz game Skill on AWS, using Stackery to deploy your serverless function that will serve as the Skill backend
You can deploy the code as-is, or modify the content of the quiz - it's about AWS services, but you can make it about any topic you'd like!
Tweet us a screenshot of your deployed backend. It'll look something like this:

Oh, and bonus points for playing the quiz game - find it here: Stackery re:Invent Quiz Alexa Skill.

Sound good? Then let's get to it!

Wait, I have questions!

Ok, let's have them:

What's an Alexa Skill?

A Skill is a voice app that can be opened on an Alexa-enabled device, such as a smart speaker, a smart home device that's Alexa-enabled, a smartwatch... basically, if it has the word "smart" in its name, it probably supports Alexa.

What does this Skill do?

This Skill asks users questions about AWS services, such as Lambda, Cognito or EC2, in a 10-question quiz game. It can also give users facts about certain AWS services.

Do I need to be an AWS expert to follow this tutorial?

Nope! Stackery makes it easy for anyone to deploy serverless apps on AWS, and adding infrastructure is as simple as dragging and dropping! The only thing you need is an AWS account, a modern browser, and a computer connected to the Internet.

Do I need to be a programming ninja to follow this tutorial?

Again, nope! If you can copy-paste, you can build and deploy this app. If you do want to customize the quiz, you will need to know JavaScript/NodeJS at a basic level.

Do I need an Alexa-enabled device to test my Skill?

Not at all - the Alexa developer console includes an in-browser Alexa simulator for testing. Of course, if you deploy and share your Alexa Skill, we'll send you an Echo Dot to test your skill out in the wild.

Will this make my AWS bill go crazy?

Not if you follow the tutorial. Everything here should fit easily within AWS's free tier, and both the AWS account and Amazon Developer account you'll need for this tutorial are free.

Can I make Alexa speak in a sarcastic tone?

Sadly, no (believe me, I tried). But there are some cool things you can do with SSML, the markup language used to dictate how Alexa generates phrases.

Are there terms & conditions you legally need to include in the post?

Of course there are!

Terms and conditions apply. While supplies last. Amazon gift cards for the cost of one Amazon Echo will be sent within 3 business days of deployment. Additional shipping charges may apply depending on location.

Where can I learn more about building Alexa Skills?

The Alexa Developer docs are a great place to start
This tutorial is largely based on and borrows generously from this Skill sample, and I recommend diving into that codebase if you want to go further

Ok, no more questions? Then...

Let's get to it!

1. Create an Alexa Skill

For this step you'll need a free Amazon Developer account

Log in to the Alexa Developer Console, and click the Create Skill button
Name your skill whatever you'd like
Choose Custom as your model
Choose Provision your own as the method to host your skill's backend resources
Scroll back up, make sure everything looks right, and click Create skill

You'll now see your newly-created skill in a list of all skills:

Click on the skill name, and navigate to Interaction Model -> JSON editor

This is where you will paste a JSON file that describes the different forms of interactions your Skill will have with users, as well as the custom data that serves as the allowable answers to quiz questions.

Copy the entire contents of this JSON file from our alexa-reinvent-quiz repo
Paste the copied contents into the Alexa JSON editor, then click Save Model at the top

Once you save, you will see that your Intents were auto-populated. Feel free to poke around and view the sample utterances and slot types that are there now. When you're done, return to the main console where all of your skills are listed, as you'll need to get your Skill ID in a few moments, so be sure to leave this browser tab open.

2. Build your backend in Stackery

For this step you'll need a free Stackery account, a Git provider, and a code editor. If you're a first-time Stackery user, you'll need to link your Git provider and AWS account the first time you commit and deploy a stack. Don't worry, the process is fairly quick and simple and the app will walk you through it.

In a new tab, log in to Stackery, and create a new stack with a new repo

In the Visual edit mode, add a function and give it the name AlexaHandler and change its code source directory to src/AlexaHandler

Flip to the Template edit mode, and add the following YAML as part of the Properties of your AlexaHandler function:

      Events:
        AlexaSkillEvent:
          Type: AlexaSkill
          SkillId: <your-skill-id>

Replace <your-skill-id> with the Skill ID you noted above¹

This is what allows your Lambda function to be accessed by the specific skill you're building, and not any other.

Your template should look now something like this:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  AlexaHandler:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub ${AWS::StackName}-AlexaHandler
      ...
      Policies:
        - AWSXrayWriteOnlyAccess
      Events:
        AlexaSkillEvent:
          Type: AlexaSkill
          SkillId: amzn1.ask.skill.some-long-numbers-and-letters
Parameters:
  ...

If you want to double-check your formatting, you can refer to our SAM template in the tutorial repo.

If everything looks right, click the Commit... button to commit your changes to your Git repository
Follow the repo link below the stack name to access your newly-created repository
Clone your repo to your computer and open it in your favorite (or least-favorite, we're not particular) IDE

3. Add function code

When you created a function in Stackery, it stubbed out some function code for you in the chosen runtime, which is Node 12 in the case of this tutorial. We're going to replace the function code with the Alexa backend from the tutorial repo, as well as its package.json contents to add the required dependencies.

Open your-repo/src/AlexaHandler/index.js and replace its contents with the contents of Stackery's Alexa Skill code. Save the file
Open your-repo/src/AlexaHandler/package.json and replace its contents with the following and save:

{
  "name": "alexahandler",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "author": "Stackery",
  "license": "MIT",
  "devDependencies": {
    "aws-sdk": "^2.796.0"
  },
  "dependencies": {
    "ask-sdk-core": "^2.9.0",
    "ask-sdk-model": "^1.34.1"
  }
}

Commit the changes and push to your Git repo.

If you kept your Stackery tab open, you'll have noticed that it detected the changes you pushed up. Go ahead and hit the refresh link:

4. Deploy to AWS

That's it for the actual coding portion of the tutorial, until you're ready to play around with the code itself to alter the quiz. But let's not get ahead of ourselves: first, we deploy!

In the Stackery app, navigate to the Deploy tab
Select an environment to deploy to (if this is your first time deploying with Stackery, you'll be guided through linking to AWS first). Click Prepare new deployment and then Prepare to start your deployment

Once the deployment is prepared (which will take about a minute), click Deploy. A tab will open in your AWS Console, where you'll need to click Execute to kick off the deployment²

This will take a few minutes - get yourself a coffee and a pat on the back, because you're 90% done with deploying your first Alexa Skill!

You'll get a notification when your stack has deployed. Click the View tab to see your live stack and grab your screenshot for Twitter!
While you're at it, double-click the AlexaHandler function to pull up some handy data and links. Copy the function's ARN, as you'll need it for the final step of this tutorial

5. Connect your backend to your Skill

This is it: the final stage, when we connect all the dots and test our Alexa Skill!

Back in the Amazon Developer Console, select Endpoint from the menu
Enter the ARN you copied in the previous step like so:

Click Save Endpoints
In the side tab, return to Invocation and click Save Model, then Build Model

Now you're ready to test your Skill! Navigate to Test, and say or type "Start Stackery re:Invent Quiz" to kick off the quiz. You can try the quiz yourself, or get some trivia information about specific AWS services. Knock yourself out - this is the fun part!

When you return to the Stackery Dashboard, you'll even notice that your function was successfully invoked while you were testing!

Next steps

Hopefully, this little tutorial has piqued your interests in building Alexa Skills. With a Lambda backend, you can build skills in just about any runtime, and Stackery helps you deploy changes quickly (and automatically if you use our Deployment Pipelines). I'd love to see what you build - feel free to send your projects my way on Twitter, and of course remember to send your deployed stack to Stackery on Twitter and we'll DM you to get the deets for your Echo. Happy deploying!

¹ For the sake of this tutorial, we are hard-coding the Skill ID. If you are saving your Skill ID directly in the template, make sure your repo is private. Alternatively, you can use Stackery's Environments and Parameter Store to follow best practices and store your Skill ID as in AWS's Systems Manager Parameter Store and reference it at build time.

² This tutorial walks you through deploying manually in the browser, but there are other ways to deploy that will likely suit your workflow better. You can deploy with the Stackery CLI with just one command, or completely automate this process upon a merge to the repo's main branch, including automated test runs, with Stackery's Deployment Pipelines.

I used Cypress as an Xbox web scraper and I regret nothing

Anna — Wed, 02 Dec 2020 17:41:10 +0000

Like many people, I would like to get my hands on the new Xbox. And like everyone but the most diligent online shoppers, I have so far failed in my efforts to do so, and have instead been relentlessly greeted by images such as this one:

So what does an enterprising/desperate web developer do? Build their own alert system, of course!

Now, a web scraper is a pretty simple application and generally the ideal use case for this sort of thing. But I wanted to add a visual element to it, to make sure I wasn't getting false positives, and because I tend to prefer user interfaces over bare code (I do work at Stackery, after all). Also, I've been playing with the Cypress test suite for the past month or so, and absolutely love it for frontend testing, so I've been looking for more ways to implement it in my projects.

Now, I should say: I'm guessing this is not exactly the use case the devs at Cypress.io had in mind when they built the browser-based testing library, but as the famous saying goes, "You can invent a hammer, but you can't stop the first user from using it to hit themselves in the head¹".

So without further ado, let's hit ourselves in the proverbial head and get that Xbox!

Setup: get yourself a Cypress account

Cypress has a very neat feature that allows you to view videos from your automated test runs in their web app. In order to do so, you'll need a free developer account:

Go to the Cypress sign-up page and create an account
Once you're in their dashboard, go ahead and create a new project. Name it "Xbox stock scraper", "testing abomination", or whatever you'd like. I generally name my projects the same as my repo, because that's how my brain works
Now, you'll want to take note of the projectId as well as the record key, as you'll need this later

Create a serverless stack for your scraper

Because store inventories changes frequently, we'll want to run our scraper regularly - every hour to start, though it's easy to adjust that up or down as you see fit. Of course, we want to automate these runs, because the whole point is that you have a life and are trying to avoid refreshing web pages on the reg. Is it me, or is this starting to sound like an ideal serverless use case? Not just me? Thought so!

I originally wanted to run the whole thing in a Lambda, but after an hours-long rabbit-hole, I found out that's really, really hard, and ultimately not worth it when a CodeBuild job will do the trick just fine.

I'll be using Stackery to build my stack, so these instructions go through that workflow. This part is optional, as you can also do this in the AWS Console, but I like doing things the easy way, and Stackery is serverless on easy mode².

If you don't already have one, create a free Stackery account
Navigate to /stacks, and click the Add a Stack dropdown arrow to select With a new repo. Here's what that looks like for me:
Normally, you'd add resources one by one in the Design Canvas, but as this stack is mainly based on a CodeBuild job and related roles, it's easier to copy-pasta an AWS SAM template like so:

Under Edit Mode, click Template, clear out the existing template, and paste the following:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  SendMessage:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub ${AWS::StackName}-SendMessage
      Description: !Sub
        - Stack ${StackTagName} Environment ${EnvironmentTagName} Function ${ResourceName}
        - ResourceName: SendMessage
      CodeUri: src/SendMessage
      Handler: index.handler
      Runtime: nodejs12.x
      MemorySize: 3008
      Timeout: 30
      Tracing: Active
      Policies:
        - AWSXrayWriteOnlyAccess
        - SNSPublishMessagePolicy:
            TopicName: !GetAtt XboxAlert.TopicName
      Events:
        EventRule:
          Type: EventBridgeRule
          Properties:
            Pattern:
              source:
                - aws.codebuild
              detail-type:
                - CodeBuild Build State Change
              detail:
                build-status:
                  - SUCCEEDED
                  - FAILED
                project-name:
                  - cypress-xbox-scraper
          Metadata:
            StackeryName: TriggerMessage
      Environment:
        Variables:
          TOPIC_NAME: !GetAtt XboxAlert.TopicName
          TOPIC_ARN: !Ref XboxAlert
  CodeBuildIAMRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          Effect: Allow
          Principal:
            Service: codebuild.amazonaws.com
          Action: sts:AssumeRole
      RoleName: !Sub ${AWS::StackName}-CodeBuildIAMRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AdministratorAccess
  CypressScraper:
    Type: AWS::CodeBuild::Project
    Properties:
      Artifacts:
        Type: NO_ARTIFACTS
      Description: Cypress Xbox Scraper
      Environment:
        ComputeType: BUILD_GENERAL1_SMALL
        Image: aws/codebuild/standard:2.0
        Type: LINUX_CONTAINER
        PrivilegedMode: true
      Name: cypress-xbox-scraper
      ServiceRole: !Ref CodeBuildIAMRole
      Source:
        BuildSpec: buildspec.yml
        Location: https://github.com/<github-user>/<repo-name>.git
        SourceIdentifier: BUILD_SCRIPTS_SRC
        Type: GITHUB
        Auth:
          Type: OAUTH
  CypressScraperTriggerIAMRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          Effect: Allow
          Principal:
            Service:
              - events.amazonaws.com
          Action: sts:AssumeRole
      Policies:
        - PolicyName: TriggerCypressScraperCodeBuild
          PolicyDocument:
            Version: 2012-10-17
            Statement:
              - Effect: Allow
                Action:
                  - codebuild:StartBuild
                  - codebuild:BatchGetBuilds
                Resource:
                  - !GetAtt CypressScraper.Arn
      RoleName: !Sub ${AWS::StackName}-CypressScraperTriggerRole
  TriggerScraper:
    Type: AWS::Events::Rule
    Properties:
      ScheduleExpression: rate(1 hour)
      State: ENABLED
      RoleArn: !GetAtt CypressScraperTriggerIAMRole.Arn
      Targets:
        - Arn: !GetAtt CypressScraper.Arn
          Id: cypress-xbox-scraper
          RoleArn: !GetAtt CypressScraperTriggerIAMRole.Arn
  XboxAlert:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: !Sub ${AWS::StackName}-XboxAlert
Parameters:
  StackTagName:
    Type: String
    Description: Stack Name (injected by Stackery at deployment time)
  EnvironmentTagName:
    Type: String
    Description: Environment Name (injected by Stackery at deployment time)

Let's break this down a bit. For those new to serverless, this is an AWS SAM template. While using Stackery means you generally can avoid writing template files, there are a few things worth noting, and one line you'll need to input your own data into.

We'll start with lines 55-74:

  CypressScraper:
    Type: AWS::CodeBuild::Project
    Properties:
      Artifacts:
        Type: NO_ARTIFACTS
      Description: Cypress Xbox Scraper
      Environment:
        ComputeType: BUILD_GENERAL1_SMALL
        Image: aws/codebuild/standard:2.0
        Type: LINUX_CONTAINER
        PrivilegedMode: true
      Name: cypress-xbox-scraper
      ServiceRole: !Ref CodeBuildIAMRole
      Source:
        BuildSpec: buildspec.yml
        Location: https://github.com/<github-user>/<repo-name>.git
        SourceIdentifier: BUILD_SCRIPTS_SRC
        Type: GITHUB
        Auth:
          Type: OAUTH

This is the CodeBuild project that will be created to run Cypress in a Linux container in one of AWS's magical server estates. You'll need to replace line 70 with the Git repo you just created. This also means you may need to authenticate your Git provider with AWS, but I'll walk you through that a bit later.

Line 101 is where you can change the frequency at which messages are sent. Learn more about AWS schedule expressions here.

Now, if you switch back to Visual mode, you'll see that several resources were just auto-magically populated from the template:

They include:

TriggerScraper: The CloudWatch event rule that triggers the Cypress CodeBuild job every hour
TriggerMessage: The EventBridge Rule that triggers the SendMessage function once the CodeBuild job succeeds or fails
SendMessage: The Lambda function that sends a the SNS message if Xboxes are back in stock
XboxAlert: The SNS topic for sending SMS messages

You can double-click each resource to see its individual settings.

Look at that: a whole backend, and you didn't even have to open the AWS Console!

Hit the Commit... button to commit this to your Git repo, then follow the link below the stack name to your new repo URL, clone the stack locally, and open it in your favorite VSCode (or other text editor, if you must)

To the code!

As you can see, Stackery created some directories for your function, as well as an AWS SAM template you'll be able to deploy. Thanks, Stackery!

First we'll want to add Cypress:

From the root of your repo, run npm install cypress --save
Once it's installed, run ./node_modules/.bin/cypress open.

Cypress will create its own directory, with a bunch of example code. You can go ahead and delete cypress/integration/examples and create cypress/integration/scraper.spec.js. Here's what will go in there:

// xbox-stock-alert/cypress/integration/scraper.spec.js

describe('Xbox out-of-stock scraper', () => {
  it('Checks to see if Xboxes are out of stock at Microsoft', () => {
    cy.visit('https://www.xbox.com/en-us/configure/8WJ714N3RBTL', {
      headers: {
        "Accept-Encoding": "gzip, deflate",
        "keepAlive": true
      }
    });
    cy.get('[aria-label="Checkout bundle"]')
      .should('be.disabled')
  });
});

Let's break that down:

Cypress will visit a specific URL - in this case, it's the product page of the Xbox Series X console
The added headers allow the page to actually load without the dreaded ESOCKETTIMEDOUT error (I found this out the hard way, so you don't have to!)
Cypress looks for an element with the aria-label "Checkout bundle" and checks if it's disabled. If it is, the test ends and it is considered successful. If it isn't, the test ends as a failure (but we all know it tried really, really hard)

Now, why the specific "Checkout bundle" element? Well, if you go to the Xbox page in your browser and inspect it, you'll see that it's actually the checkout button that would be enabled were the Xbox in stock:

Let's automate this sh*t!

Ok, we've got our test, and we've got a chron timer set to run once an hour. Now we need to add the CodeBuild job that actually runs this test. We also need to add code to our SendMessage function that notifies us if the test failed, meaning the checkout button is enabled and we're one step closer to new Xbox bliss.

Remember that Cypress projectId and record key you noted forever ago? Here's where those come in.

Create a new file in the root directory called buildspec.yml and add the following and save³:

version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 10
  build:
    commands:
      - npm install && npm run cypress -- --headless --browser electron --record --key <your-record-key>

Open up cypress.json and replace it with the following and save:

{
  "baseUrl": "https://www.xbox.com/en-us/configure/8WJ714N3RBTL",
  "defaultCommandTimeout": 30000,
  "chromeWebSecurity": false,
  "projectId": "<your-projectId>"
}

Next, we'll add the function code that sends an alert should the test fail. Open up src/SendMessage/index.js and replace it with the following:

// xbox-stock-alert/src/SendMessage/index.js

const AWS = require('aws-sdk');
const sns = new AWS.SNS({region: 'us-west-2'});

const message = 'Xbox alert! Click me now: https://www.xbox.com/en-us/configure/8WJ714N3RBTL';
const defaultMessage = 'No Xboxes available, try again later';

exports.handler = async (event) => {
  // Log the event argument for debugging and for use in local development
  console.log(JSON.stringify(event, undefined, 2));
  // If the CodeBuild job was successful, that means Xboxes are not in stock and no message needs to be sent
  if (event.detail['build-status'] === 'SUCCEEDED') {
    console.log(defaultMessage)
    return {
      statusCode: 200,
      body: defaultMessage
    };
  } else if (event.detail['build-status'] === 'FAILED') {
    // If the CodeBuild job failed, that means Xboxes are back in stock!
    console.log('Sending message: ', message);

    // Create SNS parameters
    const params = {
      Message: message, /* required */
      TopicArn: process.env.TOPIC_ARN,
      MessageAttributes: {
        'AWS.SNS.SMS.SMSType': {
          DataType: 'String',
          StringValue: 'Promotional'
        },
        'AWS.SNS.SMS.SenderID': {
          DataType: 'String',
          StringValue: 'XboxAlert'
        },
      },
    };

    try {
      let data = await sns.publish(params).promise();
      console.log('Message sent! Xbox purchase, commence!');
      return { 
        statusCode: 200,
        body: data
      };
    } catch (err) {
      console.log('Sending failed', err);
      throw err;
    }
  }
  return {};
};

Oh, and while you're at it, you may want to add node_modules and package-lock.json to your .gitignore, unless polluting Git repos is your thing.

Time to deploy this bad boy

Be sure to git add, commit, and push your changes. When deploying, AWS will need access to your Git provider. Follow these instructions to set up access tokens in your account if you've never done that before. (This doc might also come in handy for noobs like me).

If you're using Stackery to deploy, like the smart and also good-looking developer you are, all you need to do is run the following command in the root of your repo:

stackery deploy

This will take a few minutes, during which time you can daydream about how awesome that new Xbox is going to be once it's hooked up to your 4K TV.

Done? Ok! Next step: adding your phone number for text alerts.

Can I get your digits?

As I mentioned above, one of the resources created in your stack was the XboxAlert SNS topic. It was created during the deployment, but right now it's not doing anything. Let's change that.

Open the AWS Console, and navigate to the SNS Dashboard
Under Topics, you should see your freshly-minted topic, called something like xbox-stock-alert-<env>-XboxAlert. Click its name
Click the big orange Create subscription button
Fill out the form like so with your mobile number, and click Create subscription again:

You'll need to verify your phone number if you haven't used it with SNS before, and then you're good to go!

Testing time

Still in AWS, you should now be able to open up the CodeBuild console and see a new project in there:

You'll want to run it manually to make sure everything works before setting and forgetting it, so go ahead and select your project and hit that Start build button. This will take some time as well, but you can tail the CloudWatch logs by clicking the project name and selecting the most recent build run.

Vids or it didn't happen

Hopefully, your build was a success (and if it wasn't, hit me up - I think I hit all the errors while building this out and may be able to help).

But how can you make sure? Well, you can go back to your project in Cypress.io, and see if there's anything in your latest runs. If all went well, you'll be able to watch a video of the headless browser running your spec!

And, should one day that test fail 🤞, you'll get a notification straight to your phone letting you know that Xbox is right there for the taking. Good luck!

Notes

¹ I actually just made that up, but I imagine the inventor of the hammer said that at some point.
² I also just made that up, but that doesn't make it any less true.
³ A much better way to do this is to use environment parameters stored in AWS Systems Manager Parameter Store to store your record key, but for the sake of brevity my example hard-codes the key. Just make sure your repo is private if you follow my bad example 🙏

Postscript

It's possible to extend the scraper spec to add more retailers, though I ran into issues with a few, such as Walmart's bot detector:

I wasn't able to get these running without errors, but maybe someone else will have more luck and can comment with their solutions:

// xbox-stock-alert/cypress/integration/scraper.spec.js

describe('Xbox out-of-stock scraper - more retailers', () => {
  it('Checks to see if Xboxes are out of stock at GameStop', () => {
    cy.visit('https://www.gamestop.com/accessories/xbox-series-x/products/xbox-series-x/11108371.html?condition=New', {
      headers: {
        "Accept-Encoding": "gzip, deflate",
        "keepAlive": true
      }
    });
    cy.get('span.delivery-out-of-stock')
    cy.get('span.store-unavailable')
  });
  it('Checks to see if Xboxes are out of stock at Best Buy', () => {
    cy.visit('https://www.bestbuy.com/site/microsoft-xbox-series-x-1tb-console-black/6428324.p?skuId=6428324', {
      headers: {
        "Accept-Encoding": "gzip, deflate",
        "keepAlive": true
      }
    });
    cy.get('[data-sku-id="6428324"]')
      .should('be.disabled')
  });
  it('Checks to see if Xboxes are out of stock at Walmart', () => {
    cy.visit('https://www.walmart.com/ip/Xbox-Series-X/443574645', {
      headers: {
        "Accept-Encoding": "gzip, deflate",
        "keepAlive": true
      }
    });
    cy.get('.spin-button-children')
      .contains('Get in-stock alert');
  });
  it('Checks to see if Xboxes are out of stock at Costco', () => {
    cy.visit('https://www.costco.com/xbox-series-x-1tb-console-with-additional-controller.product.100691493.html', {
      headers: {
        "Accept-Encoding": "gzip, deflate",
        "keepAlive": true
      },
      pageLoadTimeout: 60000
    });
    cy.get('.oos-overlay')
  });
});