DEV Community: Digital Canvas Development

Generative AI for 3D Modeling and Printing

Simon Goldin — Fri, 07 Jul 2023 19:00:17 +0000

Introduction

While exploring generative AI, I've seen what it can do with different web programming languages like JavaScript and I thought it might be interesting to see what it can do with 3d modeling.

One tool many people use for parametric modeling is OpenSCAD which is very utilitarian and has methods for constructing 3d and 2d geometry (and 3d from 2d such as extrusion).

Since "OpenSCAD focuses on the CAD aspects rather than the artistic aspects of 3D modeling" it's great for generating practical and functional 3d models (and also things like fractals, which might be a future topic), and I wanted to explore how chatGPT can help - in cutting down on time, exploring different designs, or at the very least teaching me new things.

The project I decided on was a business card holder - it's something that has a little bit of complexity, can lend itself to creativity, and is also relatively geometric and inorganic; not to mention it's something that I can use!

For a little inspiration, I turned to MidJourney:

Initial Attempt

First, I wanted to see what GPT-4 would give me out of the box, without much direction:

generate openSCAD code for a standard size business card holder

Produces the following code (for the brevity, the "fluff" around it is omitted"):

cardWidth = 90; 
cardHeight = 55; 
cardThickness = 5; 

boxWallThickness = 3; 
boxBottomThickness = 3; 
boxInsideWidth = cardWidth - 2; 
boxInsideHeight = cardHeight - 2; 
boxInsideDepth = cardThickness + boxBottomThickness; 

module box() {
    difference() {
        // Outer box
        cube([cardWidth, cardHeight, cardThickness]);
        // Inner box
        translate([boxWallThickness, boxWallThickness, boxBottomThickness])
        cube([boxInsideWidth, boxInsideHeight, boxInsideDepth]);
    }
}

box();

This code generates two "cubes" (well, rectangular prisms) - one representing a stack of business cards, and larger one - and subtracts one from the other.

This code is valid and renders the following shape (I added colors to illustrate the parts):

The general model is right, but there are a few problems with this:

The negative space is a bit too small - a standard business card is 88.9mm x 50.8mm but the cutout is 87mm long, so there will be an overhang.
The depth of this container doesn't allow for many business cards.
I am pretty sure that chatGPT was "trying" to generate a box with walls on each side, but ended up completely removing two of them.

We can play around with some of the variables to give us something more functional, or we can ask chatGPT do it for us:

adjust the model so that there are four walls and a "base" and that a stack of standard business cards fits in the cutout.

Gives us:

cardWidth = 90; 
cardHeight = 55; 
stackThickness = 10; 

boxWallThickness = 3; 
boxBaseThickness = 3; 
boxInsideWidth = cardWidth + 2; 
boxInsideHeight = cardHeight + 2; 
boxInsideDepth = stackThickness + boxBaseThickness;

module box() {
    difference() {
        // Outer box
        cube([boxInsideWidth + (2 * boxWallThickness), boxInsideHeight + (2 * boxWallThickness), boxInsideDepth]);
        // Inner box
        translate([boxWallThickness, boxWallThickness, boxBaseThickness])
        cube([boxInsideWidth, boxInsideHeight, stackThickness]);
    }
}

box();

This results in a cutout that is 92mm x 57mm and 10mm high which gives us a little clearance for the business cards:

The code could be cleaned up (for example by starting off with the dimensions of the entire stack of cards, and going from there) but the result is a perfectly functional container.

Another Approach

We can take a more "engineering" approach by crafting our prompt as if we were writing the code ourselves. This might be less error-prone if the prompt is crafted well:

generate openSCAD code for the following:

a rectangular prism that is 98mm across, 63mm deep, and 13mm high.

subtract a prism that is 92mm x 57mm and 10mm high from the top center of the previous prism.

Generates a very simple block of code (and goes on to explain what it does):

difference() {
    cube([98, 63, 13]); // Outer rectangle
    translate([3, 3, 3]) cube([92, 57, 10]); // Inner rectangle subtracted from the outer rectangle
}

And looks identical to the previous version:

Tradeoffs

The second approach resulted in much less code (generally good!) which was also more straightforward, but we had to do a little more "manual" work like finding the exact dimensions we need and breaking the prompt up into steps, as if we were writing the code ourselves.

The first approach might still be better for exploration and experimentation, if we want to see wildly different versions of what a "business card holder" can look like.

Either way, we get the same model which can be 3d-printed in a little under two hours:

Going Further

Let's combine these approaches to create a more interesting design.

Generate openSCAD code for standard size business card holder composed of the following modules:

a base that is flat against the surface it will be placed.

a small front face "lip" connected to the base that keeps the cards from slipping out.

a back that has a bottom side that connects to the back side of the "base". This "back" shape is almost vertical but with the top rotated away from the front.

Color-code each module.

Skipping the code here, this renders:

Obviously, that's not how we want the "back" oriented.

Another attempt:

Generate openSCAD code for standard size business card holder composed of the following modules:

a base that is flat against the surface it will be placed.

a small front face "lip" connected to the base that keeps the cards from slipping out.

a back that has a bottom side that connects to the back side of the "base". This "back" shape is almost vertical but rotated so that this "back" shape is tilted back, away from the front of the model.

Color-code each module.

Regenerating the response strays further away from what we want:

Further generations aren't much better, so we'll be direct when discussing these actions by giving it specific dimensions:

Generate openSCAD code for standard size business card holder composed of the following modules:

a 2mm thick, 90mm across, and 20mm deep bottom that is horizontal to the surface it will be placed on.

a 2mm thick and 5mm tall front face "lip" at the top front of the base that will keep the cards from slipping out.

a 2mm thick and 40mm tall vertical back side. Cards will rest on this.

Rotate and translate each module to adhere to the description.

Color-code each module for debugging. Do not provide anything except for the code.

Does pretty much we want:

$fn = 100; // Higher resolution

module base() {
    color("Blue")
    cube([90, 20, 2]);
}

module lip() {
    color("Green")
    translate([0, 15, 0])
    cube([90, 2, 5]);
}

module back() {
    color("Red")
    translate([0, 0, 2])
    cube([90, 2, 40]);
}

// Combine modules
base();
lip();
back();

Rotating the back part and placing it correctly took some trial and error: rotate the "back" 10 degrees so that the top is angled away from the front and move the "back" module so that the bottom edge connects to the back edge of the base. ... fix the rotation direction ... fix the rotation direction and placement so that the back is at the back, away from the lip ... move the back piece to the back edge of the base.

Eventually, I got more or less what I wanted:

$fn = 100; // Higher resolution

module base() {
    color("Blue")
    cube([90, 20, 2]);
}

module lip() {
    color("Green")
    translate([0, 15, 0])
    cube([90, 2, 5]);
}

module back() {
    color("Red")
    translate([45, 0, 1]) // Move upwards by 1mm and center for rotation
    rotate([10, 0, 0]) // Rotate 10 degrees
    translate([-45, 0, 0]) // Re-center after rotation
    cube([90, 2, 40]);
}

// Combine modules
base();
lip();
back();

After this point, I prompted GPT-4 to add "caps" to the sides:

create two quadrilaterals that will act as left and right "caps" described as:

each cap is 2mm wide

bottom edges are flush with the bottom of the base

front edges are flush with the front lip

back edges are flush with the back part

top edges connect between the middle of the back part and the top of the front lip

The best way would probably be to create the points and then extrude and then move them to different positions based on "left" or "right"

Which produced a syntactical error and not what I was going for:

module cap(right) {
    color("Yellow")
    points = [[0,0],[90,0],[90,15],[45,35]]; // Define points of a polygon
    linear_extrude(height = 2)
        polygon(points=points); // Create the polygon
    translate([right ? 88 : 0, 0, 0]); // Position the cap
}

But it was on the right track, programmatically-speaking.

Given that one of my initial goals was to speed up development, I took the reigns and fixed the issues manually:

module cap(right) {
    color("Yellow");
    points = [[0, 0], [24, -4], [4, 16], [0, 16]]; // Points on the X-Y plane
    translate([right ? 90 : 2, 0, 0]) 
    rotate([0, -90, 0]) // Rotate points to Y-Z plane
    linear_extrude(height = 2) 
    polygon(points = points);
}

and fed it back to chatGPT.

After this point, I asked chatGPT to increase the width from 90mm to 95mm to account for the end caps, "etched" text into the back, and then made some manual adjustments to arrive at my final (for now) product:

module base() {
    color("Blue")
    cube([95, 20, 2]);
}

module lip() {
    color("Green")
    translate([0, 18, 0])
    cube([95, 2, 5]);
}

module back() {
    color("Red")
    difference() {
        translate([0, 0, 1]) // Move upwards by 1mm and center for rotation
        rotate([10, 0, 0]) // Rotate 10 degrees
        cube([95, 2, 40]);
        translate([85.5, -2, 18]) // Adjusted position of the text
        scale([.65, 1, .65]) // Decrease scale of the text
        rotate([260, 180, 0]) // Adjusted rotation to make the text parallel with the 'back'
        linear_extrude(height = 2, convexity = 2)
        text("digitalcanvas.dev", font = "Merriweather"); // Text to be cut out
    }
}

module cap(right) {
    color("Yellow");
    points = [[0, 0], [24, -4], [5, 18], [0, 18]]; // Points on the X-Y plane
    translate([right ? 95 : 2, 0, 0]) 
    rotate([0, -90, 0]) // Rotate points to Y-Z plane
    linear_extrude(height = 2) 
    polygon(points = points);
}

// Combine modules
base();
lip();
back();
cap(true); // Right cap
cap(false); // Left cap

I loaded this into my slicer (PrusaSlicer) and began the print!

Final thoughts & takeaways

Ultimately, I didn't get the level of polish that MidJourney teased was possible, and the process was imperfect but a good learning experience for both working with Generative AI and OpenSCAD.

GPT-4 gave valid code the vast majority of the time and I was able to adjust it when needed. Having larger chunks of code generated for me definitely saved time - both in typing and looking up documentation - and being able to tweak specific numbers and feed it back to chatGPT allowed for a relatively smooth workflow; though I concede that as a first try, using chatGPT was slower than coding it by hand; I spent a lot of time checking and tweaking the generated outputs (not to mention having to wait for rate limits to expire).

There were some themes that came out of this. Generated OpenSCAD code was prone to mixing up axes when rotating and translating, and getting the right "Points on the X-Y plane" was a struggle. Doing this manually was much faster, but prompts like "the module was rotated along the wrong axis" usually worked, too.

It's also important to be as direct as possible - do not assume "module A should connect to module B" will result in what you expect; give more direction: "the bottom edge of module A should be flush with the top edge of module B and the smaller edge should be centered on the larger edge."

Finally, it helps to break the end goal into smaller tasks (e.g. "generate module A", "adjust model A", "add module B") rather than start with a larger prompt that has more things that can go wrong. Interestingly, generating modules was generally less error-prone than modifying them.

In my opinion, it's best to treat it as pair programming where you hand the work off between two software engineers while speaking in "the highest level of abstraction" (which, in some cases, is lower than you'd think).

Thank you for reading! Have you used generative AI for 3d modeling or printing? What approach worked well for you? I would love to hear about other experiences.

Of course, I can't leave this post unfinished! Here is the final product:

The real business cards are in the mail, but I printed a fake one!

AI/LLM Recipe Generator with chatGPT

Simon Goldin — Mon, 26 Jun 2023 19:28:27 +0000

The ChatGPT API is like a magic spell for your web application - with just a few lines of code, it can conjure up engaging, intelligent conversations. Even for a tech novice, it's a breeze to weave into new or existing apps. Dive in, and in no time, you'll have a conversational AI that keeps users captivated and coming back for more.

That's the introduction that chatGPT came up with. Pretty good, right?

In this article I won't be building a conversational AI tool, but I will go into the integration between a Remix application and the chatGPT API.

The "test bed" will be a simple recipe generator that gets some information from the user that it will use to create a prompt for chatGPT.

The code is available on github and ultimately looks like this:

Pre-setup

The "pre-setup" is as straightforward as can be. (After setting up payment) you will need to create a secret API key here and copy it to your .env file (make sure it's in your .gitignore file so no one can find it on github!). Also copy your organization ID from here.

OPENAI_API_KEY=[your secret API key]
OPENAI_ORG_KEY=[your organization id]

And install the openai library. If using npm, that would be:

npm i openai

This includes TypeScript types, too!

Calling the API

For this example, we can use the Chat Completions API, but before we can do that, we'll need to configure the library to use our keys. Since this code is exclusively run on a server, and not a user's browser, we can get what we need from the process.env object:

const configuration = new Configuration({
  apiKey: process.env.OPENAI_API_KEY,
  organization: process.env.OPENAI_API_ORG,
});

const openai = new OpenAIApi(configuration);

Now we can create an object of type CreateChatCompletionRequest. This object can have a variety of different options to tell chatGPT what we want, but the most important (and required) options are model - which model version to use (full list here), and messages - the context and prompt of the chat we want completed.

One messages option can be a system-wide "personality" that the chat can conform to. There are also options to give the API examples of outputs that can be used to train the model for this specific chat.

We'll be using a user message, i.e. the input received from the user, to ask the GTP model what we want.

// for the purpose of this article, we'll abstract this away.
const ingredientsList = getIngredientsList();

const completionRequest: CreateChatCompletionRequest = {
  model: 'gpt-3.5-turbo',
  messages: [
    {
      role: 'system',
      content: 'You are a creative and experienced chef assistant.',
    },
    {
      role: 'user',
      content: `Generate a recipe with these ingredients: ${ingredientsList}.`,
    },
  ],
};

const chatCompletion = await openai.createChatCompletion(completionRequest);

In this case, we're using the gpt-3.5-turbo model and starting the conversation by asking the API to act as a "creative and experienced chef assistant".

Handling the response

The response is well-typed and can be accessed easily:

const generatedOutput = chatCompletion.data.choices[0].message?.content;

Which in this case might result in a "One-Pan Baked Tilapia and Vegetable Dinner" recipe with a complete ingredients list and step-by-step instructions!

This is, of course, a simplification. A full implementation with more options and a user interface might end up looking something like this:

Advanced options

An interesting property that's available to us here, that's not available in the chatGPT interface is temperature which is an abstraction of randomness that can add some chaos.

With a temperature of 2, a "recipe" might start looking like this...

Chicken Delight Recipe Parham Style:

Featured Cooking Equipment(set boAirition above stove required Gas-Telian range VMM incorporated rather below ideal temperature during baking ir regulate heat applied):
- Large non-stick frypan(Qarma brand)->Coloning cooking Stenor service(each Product hasown separate reviews dependable optimization features)

Be careful, as this can eat into your tokens! As a safety measure (or depending on your use case), a max_tokens can be used to limit the size of the output.

In my experience with gpt-3.5-turbo, altering the system content did not have much effect in this case, but can be more useful for ongoing conversations. Since my use case is to just ask for a recipe once, there's no need to set up the system "personality".

Limitations

As of this writing, gpt-3.5-turbo is the latest model available to me but it comes with some limitations.

First off, the processing is fairly slow with it taking about 15 seconds to return a recipe. OpenAI suggests a number of improvements in their docs such as limiting output size, caching, and batching.

There is also an inherent limitation that a conversation is "stateless": if you want to have an ongoing conversation, each previous user message and its assistant response need to be sent before each new user message.

In my example application, providing a very limited set of common ingredients (Salt, Pepper, Olive oil, Butter, All-purpose flour, Sugar, Eggs, Milk, Garlic, Onion, Lemons, White Vinegar, Apple Cider Vinegar, Soy sauce, Baking powder, Cumin) still results in chicken- or shrimp-based recipes. I tried getting around this with more specific prompts ("if chicken is not available, do not recommend recipes with chicken.") but to not to much success.

This is an example of a "hallucination" but has not specifically been an issue with GPT-4, which is not yet broadly available via the API.

There are other important general generative AI limitations to keep in mind such as biases and how they are often "confidently incorrect".

In this case, the worst-case scenario is an unappealing meal, but these limitations are important to keep in mind when relying on generated content.

Fine-tuning and cost

As the only user of this application, my costs have been very minimal 😅. A single execution comes out to about 200 input tokens and the output ranges between 300 and 500 tokens. With gpt-3.5-turbo, this comes out to (0.2 * $0.0015) + (.4 * $0.002) or about one tenth of a cent.

Once more generally available, GPT-4 will be significantly more expensive. Currently, a single run for me would amount to (0.2 * $0.03) + (0.4 * $0.06) or about 3 cents.

API pricing was reduced a few weeks ago so it's reasonable to expect GPT-4 to get cheaper in the future, too.

The GPT-3.5 output can still be fine-tuned by more specific and verbose inputs, but since billing is based on number of "tokens" (i.e. input and output length), fine-tuning this way can be costly, similarly to a conversational application that chains user and assistant messages.

Prompts can also be split into smaller, more specific prompts. However, in addition to increasing the total number of tokens, this approach would also increase the complexity (and maintenance cost) of an application, especially if you're using the output of one query as an input of another.

Summary

The header image for this post was created with MidJourney, just another (tiny) example of how I've been using the technology.

Generative AI opens up a wide range of new and exciting applications, but not without additional considerations that should be kept in mind.

Though this application just barely scratches the surface of what can be done, I hope it has served as a useful introduction to integrating the openai library into your web application whether you're building a cool product, or just exploring new technologies.

Have you explored interesting applications of the API, or experimented with different parts of it? Please share!

Serverless Remix App Contact Form with AWS Lambda, AWS SES and Google ReCaptcha

Simon Goldin — Mon, 19 Jun 2023 16:11:41 +0000

Introduction

This blog post revisits my (apparent) "Check out this new React framework" series that I've strayed away from.

Specifically, I'm going to go through a contact form implementation adapted from working on the Digital Canvas Development website which is built on top of the Remix "Grunge Stack".

The entire website, including the specifics covered here, are available on github: https://github.com/digital-canvas-dev/digitalcanvas.dev

Project overview

My application is a simple site that will act as a landing page for my new business. It's mainly composed of static content and a contact form.

Remix is a full-stack framework that co-locates server-side and client-side code. The Grunge Stack comes with a host of features and libraries including AWS deployment via Architect (e.g. npx arc). Many of the AWS tools are free-tier eligible for low-traffic sites.

This guide assumes you've already deployed your application or you're ready to.

To get the contact form working end-to-end, I'll be using AWS Simple Email Service (SES). To prevent spam, I will be using Google ReCaptcha (v2).

Component setup

The initial form looks very similar to form portion of the official Remix "blog" tutorial. In a nutshell, we're starting with something like this:

import { Form, useActionData, useSubmit } from '@remix-run/react';
import { InputText } from 'my-component-library';

export const Contact = () => {
  const actionData = useActionData();

  const submit = useSubmit();

  const onSubmit = async (e) => {
    await submit(e.currentTarget);
  };

  return (
    <section>
      <Form method="POST" onSubmit={onSubmit}>
        <InputText
          name="name"
          label="Name"
          errorFeedback={actionData?.errors?.name ?? null}
        />
        {/* ... other fields ... */}
        <button type="submit">Send</button>
      </Form>
    </section>
  );
};

And the core of our action looks like this:

export const action = async ({ request }) => {
  const formData = await request.formData();

  // we'll pseudocode this away.
  // it will return an object of errors, if any.
  const errors = validate(formData);

  if (errors) {
    return errors;
  }

  // todo: avoid spam
  // todo: send the email

  return json({
    success: true,
    successMessage: 'Message sent! Expect to hear back soon.',
  });
};

You'll notice two important todos which we'll be addressing in reverse order so we can tackle the more interesting parts first 😀

Sending emails with AWS Simple Email Service (SES)

To integrate with SES, I pulled in the AWS SDK (v3):

npm i @aws-sdk/client-ses

@aws-sdk/client-ses is a wrapper around AWS SES v3 and its documentation is here.

**Important note: your lambda function must use nodeJS v18 to use the AWS v3 SDK. Otherwise, you'll need to use the v2 SDK.

One of the cool thing about using AWS for email architecture with the Grunge Stack is that as long as you already followed the deployment steps, the client-ses library will be able to use the AWS keys from the environment variables that were set in the .deploy script.

Now (after looking at a lot of interfaces and documentation) the action implementation becomes clear: we can simply create an instance of the SESClient, and use it to send an email!

Architecture note:

We can break these methods into a few logical (and reusable, and testable) parts.

This way, we can maintain the instantiation in one place and reuse it later.

Putting it all together, the logic might look like this...

A server-only ses.server.ts file:

import { ActionArgs, json } from '@remix-run/node';
import { SendEmailCommand, SendEmailCommandInput, SESClient } from '@aws-sdk/client-ses';

export const sendEmail = async (params: SendEmailCommandInput) => {

  const sesClient = new SESClient({
    region: 'us-east-1',
  });

  const command = new SendEmailCommand(params);

  return await sesClient.send(command);
};

And an updated action:

export const action = async ({ request }: ActionArgs): Promise<{ success: true, successMessage: string; } | {
  success: false,
  errors: { form: string }
}> => {
  const formData = await request.formData();

  const requesterName = formData.get('name');

  const params = {
    Source: 'no-reply@...',
    Destination: {
      ToAddresses: ['...']
    },
    Message: {
      Subject: {
        Data: 'Form submission'
      },
      Body: {
        Html: {
          Data: `Someone submitted the contact form: Name ${requesterName}, Email: ...`
        }
      }
    }
  };

  const resp = await sendEmail(params);

  const sentError = resp.$metadata.httpStatusCode === 200 ? null : { form: 'Error sending email.' };

  if (sentError) {
    return json({
      success: false,
      errors: sentError
    });
  }

  return json({
    success: true,
    successMessage: 'Thank you for reaching out! Expect to hear back soon.'
  });
};

At this point, you can enable SES and finish the AWS set up as described here.

Once your domain is verified and set up is complete, you can send a test email from your dev environment!

Preventing spam with Google ReCaptcha v2

However, deploying at this point is risky. Even if you're only sending emails to your own email address, a malicious actor might try to continuously submit your form which can rate-limit you or rack up your AWS bill.

In lieu of (or in addition to) site-wide spam prevention, we'll make sure that the form is submitted by a person by adding a checkbox captcha. I decided not to use v3, because frankly, I didn't like the "protected by reCAPTCHA" badge in the bottom-right corner.

First, you'll need to create a ReCaptcha here. Fill in a label, select Challenge (v2) and "I'm not a robot" Checkbox and add the domain name the captcha will be on (while you're here, it's a good idea to create one for localhost and another for a staging environment, if you're using it).

You'll be presented with "site key" and "secret key" that you can add to your 1) .env file, and 2) github repo settings.

I named them CAPTCHA_SITE_KEY and CAPTCHA_SECRET respectively.

The site key will link the site where the form is to ReCaptcha, and the secret key will only be used server-side to validate the value generated by ReCaptcha in the browser.

Next, we'll install the react-google-recaptcha library with npm i react-google-recaptcha.

Import it on the page:

import ReCAPTCHA from 'react-google-recaptcha';

and render it in the component:

export const Contact = () => {
+ const [recaptchaValue, setRecaptchaValue] = useState<string | null>(null);
+ const recaptchaRef = useRef<ReCAPTCHA>(null);

  const actionData = useActionData();

  const submit = useSubmit();

  const onSubmit = async (e) => {
    await submit(e.currentTarget);
+   setRecaptchaValue(null);
+   recaptchaRef?.current?.reset();
  };

+ const handleRecaptchaChange = (value: string | null) => {
+   setRecaptchaValue(value);
+ };

  return (
    <section>
      <Form method='POST' onSubmit={onSubmit}>
        <InputText
          name='name'
          label='Name'
          errorFeedback={actionData?.errors?.name ?? null}
        />
        {/* ... other fields ... */}
+       <input type='hidden' name='recaptchaValue' value={recaptchaValue} />
+       <ReCAPTCHA
+         ref={recaptchaRef}
+         onChange={handleRecaptchaChange}
+       />
        <button type='submit'>Send</button>
      </Form>
    </section>
  );
};

For this to work, the CAPTCHA_SITE_KEY needs to be accessible by the component, so we can use a loader:

export const loader = async (): Promise<TypedResponse<{ ENV: Pick<Globals, 'CAPTCHA_SITE_KEY'> }>> => {
  return json<{
    ENV: Pick<Globals, 'CAPTCHA_SITE_KEY'>;
  }>({
    ENV: {
      CAPTCHA_SITE_KEY: `${process.env.CAPTCHA_SITE_KEY}`,
    }
  });
};

and access the data from the component with useLoaderData:

  const data = useLoaderData<{ ENV: Pick<Globals, 'CAPTCHA_SITE_KEY'> }>();

Lastly (for the component), we'll fill in the real sitekey prop:

<ReCAPTCHA
  ref={recaptchaRef}
  onChange={handleRecaptchaChange}
+ sitekey={data.ENV.CAPTCHA_SITE_KEY}
/>

We'll need to update the action again, to validate the ReCaptcha:

export const action = async ({ request }: ActionArgs): Promise<{ success: true, successMessage: string; } | {
  success: false,
  errors: { form: string }
}> => {
  const formData = await request.formData();

+ const recaptchaValue = formData.get('recaptchaValue');
+
+ const captchaResponse = await validateCaptcha(recaptchaValue);
+
+ if (!captchaResponse.success) {
+   return json({
+     success: false,
+     errors: {
+       recaptchaValue: 'Invalid ReCAPTCHA response.',
+     },
+   });
+ }

  const requesterName = formData.get('name');

  // params, etc...
};

We can create the validateCaptcha function and put it in a captcha.server.ts file:

const ReCaptchaURL = 'https://www.google.com/recaptcha/api/siteverify';
export const validateCaptcha = async (
  recaptchaValue: FormDataEntryValue | null
) => {
  const captchaResponse = await fetch(ReCaptchaURL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: `secret=${process.env.CAPTCHA_SECRET}&response=${recaptchaValue}`,
  });

  return await captchaResponse.json();
};

CAPTCHA_SECRET will be pulled from your build or .env file and there's nothing left to do!

A complete implementation, with more fields and some styling might look like this (at least mine does, as of this writing!):

Outro

Thank you for reading! Tying in these different SDKs into a new application touched on a lot of things I've done in the past, but not all together in a Remix application. As the web has progressed, developers have been given so many options and different (paid and often free) ways of doing things, and nearly infinite opportunities to learn new things.

That being said, consider alternative 3rd party tools such as MailChimp or SendGrid which are more flexible (not tied to AWS and not part of the codebase) and more approachable (they can be configured without needing to code).

Props to this article that I found after building a working proof of concept which gave me some ideas for improvements (for example, I didn't know that client-ses had built-in authentication and my first version was managing the AWS configuration manually!). Even 13 years into this, I'm glad that I'm always learning.