DEV Community: Simon Goldin

Trust But Verify: Evaluating Security When Choosing Data Infrastructure Tools

Simon Goldin — Fri, 14 Mar 2025 14:26:41 +0000

Cover Image: How data is stored on a server, as envisioned by Hackers (1995) Dir. Iain Softley ©Metro-Goldwyn-Mayer, Inc.

A data leader's guide to maintaining security when working with third-party vendors

Originally published on Twing Data

Data warehouse optimization tools connect to platforms such as Snowflake, Amazon Redshift, and Google BigQuery to analyze usage and improve performance and cost. Since these tools interface with sensitive enterprise environments, robust security practices are critical.

Below, we’ll dive into security aspects that you should consider when choosing warehouse optimization and observability tools for your organization. More generally, these guidelines can apply to other tools that access your infrastructure or data.

Thanks for reading Twing Data! Subscribe for free to receive new posts and support my work.

Data Access

How can you be confident in the safety of the tool that's analyzing your warehouse? That's a tough question. By knowing what it can access and by what means, you can begin to form an answer.

Least Privilege

An important aspect of security is the “principle of least privilege”, or making sure that different services (especially tools that aren’t developed internally) can only access what they need to be effective. In a data mart set up, that can be a lot of critical information, so it’s important to minimize exposing anything that doesn’t need to be.

Limiting an integration to a dedicated user is a good first step. Giving this user minimal permissions, such as read-only metadata-only access, also alleviates some risk as this user could be revoked with minimal disruption if needed.

For more complex integrations, it may be necessary to have role-based access controls (RBAC) to manage who has access to what. For example, someone inspecting the metadata may not be the same person setting up billing or data connections, but maybe they should still be able to see what connections are set up. Some tools can go even further and support data-specific privilege and limit who can access different parts of the (meta)data and optimization and observability results themselves.

Twing Data takes this principle seriously by supporting secure connections to your warehouses and limiting access to read-only metadata by design and following best practices internally.

API & Integration Security

Different vendors have different, and usually multiple, ways to connect to their systems such as passwords, key-pair authentication, gateways, or entirely unique service accounts.

It’s important to remember that encryption is only as strong as its implementation, and to verify that a more secure method actually is more secure. For example, simply switching from HTTP to HTTPS doesn’t guarantee security if certificate validation is improperly handled, allowing for man-in-the-middle attacks. Similarly, using OAuth 2.0 for API authentication is a step up from basic authentication, but failing to properly manage token expiration, refresh, and revocation could expose your integration to token hijacking or replay attacks. Always evaluate the entire security chain, not just the algorithm or protocol. We’ll talk more about encryption below.

A quick internet search can also reveal any vulnerabilities that were exposed in the past for a given vendor or user.

Data Management

Photo by Mauricio Gutiérrez on Unsplash

Whether it’s just metadata like the queries being run or the data they return, whoever is analyzing the data needs to ingest and store it somewhere for analysis, and possibly to surface it back to their users. This section analyzes which aspects may require a closer look.

Data Retention

Since the vendor may have access to business-critical data (or metadata) it’s important to consider their data retention policy. What a “good” policy is will vary from business to business and use case to use case, but typically you don’t want someone to hold on to your data “forever” (especially not past the point of canceling the service). Long-term data retention can introduce unnecessary risks, such as unauthorized access, data breaches, or compliance violations. On the flipside, too short of retention might give less useful insights.

When vetting vendors, ask about their data retention and deletion policies up front and negotiate shorter retention periods or periodic purges, especially for sensitive information. It’s also a good idea to have an offboarding plan that verifies that the third-party has deleted your data after your integration has ended.

While some vendors don’t share this policy, Twing Data retains 90 days of metadata and persists the resulting analysis during the duration of service. This can be adjusted on a company-by-company basis if requested.

Data Isolation

There are also different methods for segmenting or isolating data and access. Separating customers’ data from one another can be done by setting up separate environments for each customer, ensuring that risk from one customer isn’t carried over to another. This can be especially important for services with privileges that extend beyond read-only, such as those that automatically adjust the size, clustering, or resources of your warehouses, or services that rely on data beyond metadata.

Twing Data can safely grant low-level access to our users by only exposing our analyses through company-specific accounts and views, ensuring that users (or threat actors) aren’t able to view anything they’re not supposed to.

Data Anonymization

Besides the tactics listed above, a vendor can, and should, anonymize sensitive data — even metadata. Even seemingly innocuous queries that may be executed can contain personal information that is not necessary for an external tool to see. Consider a query such as “WHERE username = ‘celebrity@personalemail.com’ AND phonenumber = ‘(555) 867-5309’” being exposed. A leaked query such as this not only exposes a high-profile individual’s email address but also ties it to their phone number.

Twing Data offers to redact query text at ingestion, replacing it with a constant placeholder token. This way, we can still analyze query structures (e.g. to identify patterns or heavy queries) without storing any actual identifiers or literals. Keep in mind, though, some analyses may not be as useful if we can't identify what makes different query pattern executions different from one another. We’re always looking to strike the right balance..

Encryption (Data at Rest & In Transit)

Nowadays, it’s safe to assume that any enterprise integration is going to use a secure protocol, but it’s still good to make sure. Any person or server that is accessing your data (metadata or otherwise) should be doing so securely. If not — run!

The (meta)data itself should also be stored securely. Twing Data leverages Google BigQuery which encrypts data at rest and adds additional access controls and auditing.

App Architecture

The “cloud”, as we know, is generally “someone else’s servers”. It enables distributing and scaling applications across the world while optimizing cost and speed.

However, as infrastructure evolves and becomes more complex, there are more points of failure and more visibility and failsafes are needed. Let’s take a look at what that means for warehouse optimization tools.

Cloud Infrastructure Security

Similar to data isolation, containerization or virtual machine (VM) isolation can ease security concerns, especially for more than read-only access. A setup like this may spin up VMs per tenant, either on-premise or managed by another provider like AWS or GCP.

Some providers, like fly.io (which Twing Data uses for hosting our application), are easy to scale globally while maintaining security practices. Twing Data’s analyses run on demand and on-premises, interfacing securely with our databases.

Logging and Monitoring

For any organization, it’s important to log events to detect, prevent, or alert on security issues or outages. For big data, an outage can mean inaccurate insights and lost revenue, so alerting and monitoring is crucial. Similarly, monitoring and alerting help catch bugs or security vulnerabilities sooner than later (with additional context about what happened and why), making it quicker to resolve them.

For example, if an API integration suddenly starts returning a high volume of 500 errors, alerting can notify the team before customers are impacted. In a security context, logs showing a spike in failed authentication attempts could indicate a brute-force attack, allowing for a proactive response. Additionally, monitoring data pipeline performance can catch bottlenecks – like a slow ETL job – that might otherwise cause reporting delays or incomplete/inaccurate analytics.

Some services (like fly.io) offer built-in logging, monitoring, and alerting (e.g. Grafana and Sentry integrations) that makes it fast, easy, and secure to set up the necessary infrastructure.

Company Practices

Photo by Piotr Chrobot on Unsplash

Lastly, company practices can give additional insight into what to expect when working with them. Do they take security seriously as part of their culture, or just to check some boxes? If a problem occurs, how likely are they to fix it within a given timeframe?

Compliance & Certification

Some certifications (SOC 2 Type I) evaluate security at a single point in time, and others (SOC 2 Type II) evaluate security over a period of time. These evaluations are based on many factors such as access controls, monitoring & logging, incident response, data encryption & integrity, secure development practices, and others.

Seeing that a vendor has these certifications gives a clear indication of their security practices. It’s something Twing Data is working towards!

Incident Response & Recovery

A company’s processes for detecting, responding to, and recovering from security incidents is just as important as their processes to avoid and alert on such incidents. After all, an alert is only valuable if it cuts through the noise and prompts action – otherwise, it’s just another overlooked warning.

SOC2 certification requires to document related processes thoroughly and test them at least annually. Of course, companies without the certification can still have a plan in place.

These processes cover responsibilities and actions that would be performed internally (e.g. patching a vulnerability) and externally (e.g. notifying affected users) with clear steps for identifying, containing, mitigating, and resolving incidents. In some cases, a service level agreement (SLA) between the vendor and customer may dictate time-to-resolution requirements, ensuring accountability.

For example, if a critical data breach occurs, an engineering team might immediately isolate the affected systems while security and legal teams work together to draft and send a breach notification within the SLA-defined timeframe.

Secure Development Practices

Cutting-edge companies should embed security throughout the development lifecycle. Increasingly, security and code quality checks are happening earlier in the development lifecycle. Tools like static code analysis, linting, code reviews, and automated security scanning help catch issues before they even reach a staging environment.

Security-minded SaaS providers also conduct regular automated and manual penetration testing on their application and infrastructure, and any critical findings are fixed as part of their vulnerability management process.

By embedding security holistically within the development workflow, companies can better safeguard sensitive data and reduce the overall cost and risk of fixing vulnerabilities later.

Third-Party Risk Management

Third-party risks typically encompass technical topics such as security breaches and downtime, but can include more qualitative risks like reputational risk.

Using reputable third parties like GCP and fly.io that have their own certifications is one way to mitigate risk that comes with outsourcing to external service providers, especially when it comes to some of the topics above around data and cloud security — items that are most commonly outsourced (since maintaining your own hardware comes with its own high costs and risks).

Vendors can also be classified based on risk — a database vendor is of higher risk than an office supplier, for example, and possibly doesn’t need to be reassessed as frequently.

Choosing the right data vendor for your business

As I was writing and researching for this article, the main takeaway became clear: it's essential to choose a vendor that analyzes your company's unique and mission-critical data effectively and securely. I hope these findings help you mitigate that risk by knowing what to look for and avoid when digging into vendors’ security policies.

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.

Setting up Create React App with @emotion/react v11 and and TypeScript 4.5.5 (Bonus: replacing npm with yarn)

Simon Goldin — Sun, 23 Jan 2022 23:01:52 +0000

Intro

A quick, straightforward and (as of January 2022) up-to-date guide for setting up create-react-app with the latest versions of emotion (11.7.1) and TypeScript (4.5.5).

This also documents the steps needed to migrate from npm to yarn v3, with offline cache, if you want.

initialize the project.

npx create-react-app my-app --template typescript

install @emotion/react
```
npm i @emotion/react
```
emotion v11 includes emotion-theming (https://emotion.sh/docs/theming)
Add a property to tsconfig.json:
```
"jsxImportSource": "@emotion/react"
```
Add jsxImportSource pragma to top (important) of each tsx file:
```
/** @jsxImportSource @emotion/react */
```

Optionally, remove the react import.

Bonus: `npm` to `yarn 3` migration

There aren't a lot of documentation about the latest (again, as of January 2022) version of yarn, 3.1.1. Here's the steps I took to move from npm and enable offline cache.

Remove package-lock.json and node_modules.

add the following to .gitignore (I like to include a link for context):

# https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored
.yarn/*
!.yarn/cache
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions

add to yarnrc.yml (create it if needed):

nodeLinker: node-modules

yarnPath: .yarn/releases/yarn-3.1.1.cjs

run yarn.
You're done! yarn start should start the dev environment as expected.
Optional: replace references to npm in the README.md. npm run -> yarn, npm start -> yarn start, npm test -> yarn test.

Configuring your React Starter Kit

Simon Goldin — Sun, 07 Jun 2020 22:18:54 +0000

Previously, I outlined things to consider when picking a starter kit. This post goes into what I do after making a selection.

Introduction

Now that I picked a starter kit (in this case, NextJS's with-typescript-eslint-jest), as much as I want to start actually building something, I want to lay some foundation first. Of course, I'll build it first to make sure it works! In my case, yarn && yarn dev is enough to make sure it's working as expected. Other frameworks and libraries may have other commands, and npm may be used in place of yarn.

Once I know it's working, I'll do a few things to modernize the project and enforce consistency and code safety in the future:

Update dependencies
Configure ESLint, Prettier, and TypeScript
Rebuild and run tests
Commit and push
Set up the IDE

Taking these steps will introduce consistency and safety which will help avoid bugs and friction in the future.

Please read on for details on each of these steps!

Update dependencies

Once I knew it was working, I jumped back into the package.json file. This time in my IDE, rather than the repository linked above. As I noted in my previous post, a few dependencies were a bit out of date so I updated them to use the latest and greatest.

yarn upgrade will update packages depending on how they are required in your package.json. Typically, a caret (^) is used to avoid breaking changes (i.e. major versions will not be updated) when updating dependencies (a ~ can be used to only pick up "patch" changes, usually bug fixes). Therefore, dependencies bundled with your application may be minor or patch versions ahead of what your package.json file says.

Since this is a fresh project, I want to pick up major changes too, since breaking changes are unlikely to affect anything or will be easy to resolve. My preferred IDE, WebStorm has a hotkey (ctrl + space) to find and include latest dependencies:

The WebStorm documentation has an explanation:

Code completion for previous package versions. When you press ⌃Space or start typing a version different from the latest one, WebStorm displays a suggestion list with all the previous versions of the package.

Visual Studio Code has a plugin, Version Lens, that displays the latest version and lets you update your package.json with a click:

In my case, most packages already used the most recent major versions so it wasn't likely that these updates caused any problems. I ran yarn dev to quickly make sure.

Configurations

I purposefully picked a starter kit that has some extra devDependencies included, such as Prettier, Jest, and ESLint, but they might not align with my preferences or needs. Before I decide on architecture or start writing new code, I want to configure these settings. Now that I have the most recent versions of my dependencies, I might also be able to leverage some new features that weren't available before.

ESLint

In the .eslintrc.json, I replaced 0s with "off"s and 2s with "error"s because I like the explicitness. The "extends" array, which uses preset recommendations, sets a good baseline, and customizations are up to personal preference. I make a few customizations to make linting a little stricter, like setting @typescript-eslint/no-explicit-any to "warn". Other rules I leave off because TypeScript and Prettier remove the need for them (such as react/prop-types and @typescript-eslint/indent, respectively).

The "extends" list has a note about Prettier:

// Uncomment the following lines to enable eslint-config-prettier
// Is not enabled right now to avoid issues with the Next.js repo
"prettier",
"prettier/@typescript-eslint"

This is straightforward enough, so I do that, and then move on to the .prettierrc configuration.

Prettier

Prettier is an opinionated code formatter to stop all the on-going debates over styles.. The .prettierrc file allows you to define a few options such as spaces or tabs (a hottly debated topic!) and whether or not to omit semicolons, or trailing commas.

I'm not going to go into details about what rules I set; the specific rules aren't as important as having the code style consistency that Prettier provides.

I ran this starter kit's format script to reformat my files with my new settings.

TypeScript

TypeScript, an extension of JavaScript that adds type safety, has an optional configuration file, tsconfig.json. The file included in with-typescript-eslint-jest has some preset options. I set "strict" to true to turn on "strict mode" which will add some additional safety to my codebase. strict is a combination of other TypeScript options: noImplicitAny, noImplicitThis, alwaysStrict, strictBindCallApply, strictNullChecks, strictFunctionTypes and strictPropertyInitialization. Setting the strict option will tell TypeScript to be more strict around null and undefined (strictNullChecks) and will prevent code from remaining un-typed (noImplicitAny), among other things.

Other Configurations

There are other configurations that you might want to create or update, such as jest.config.js (for unit tests) or next.config.js (for Next.JS), but since those are related to your specific application, that's not necessary this early on. Another benefit of starting with a starter kit is that they will be set up properly.

Rebuild and Run Tests

Once my dependencies are up to date and configurations are done, I ran yarn dev to make sure there were not regressions. I also ran yarn test for good measure, and discovered that a test failed because a snapshot was not updated, so I had a great opportunity to fix it by opening a pull request!

Commit and push

If using git, running the commit and push commands at this point will bring up potential issues with version control such as permissions and making sure the repository actually exists and some quality checks may also run, facilitated by git hooks). Running these git commands will also show whether or not they are set up and working properly.

Auto-formatting and linting scripts are often set up as a pre-commit scripts. Both of these actions are usually quick since they can run on individual files and are not concerned with the rest of the code.

TypeScript compilation typically takes longer, and depending on your workflow can be frustrating to run as a "pre-commit" check. As a "pre-push" check, it will make sure that other people working on the same code aren't picking up code that doesn't compile!

pre-commit and pre-push quality gates (as well as others) can be customized to your, or the team's, needs.

In my case, with-typescript-eslint-jest was already set up with Prettier and ESLint to format and lint changed files as a pre-commit hook, and TypeScript compilation was included as a pre-push hook.

IDE Setup

Now that my application has the configurations I want and I know they work, I'll set up my IDE to hook into them. With WebStorm, a lot of these settings are done in the Preferences panel. Searching for Prettier, for example, allows you to automatically pick up the .prettierrc settings (I also like to enable "Run on save"). There are similar options for ESLint and TypeScript, which may be configured automatically.

Visual Studio Code's extensive extension collection covers these features as well: Prettier - Code Formatter and ESLint plugins can be installed and configured as needed and have their own extensive documentation and examples.

Summary

I haven't really built anything quite yet but I know that when I do, future errors will be caught sooner than later since now I have a few places where errors are surfaced: my IDE, before code is committed, and before code is pushed (and likely shared). These automated tools won't find all errors, but the ones they do find are the most common, easiest to fix, and can be underlying errors that cause real bugs.

Setting up Prettier will help me focus on what I'm building. On a team, introducing automated formatting in the workflow will reduce the time code changes spend in code reviews, and will keep the code consistent.

Doing this now, before I've actually written any code, will save me headaches in the future.

Choosing a React Starter Kit

Simon Goldin — Thu, 04 Jun 2020 01:04:00 +0000

General guide for choosing a starter kit (aka starter library, aka boilerplate) that's right for you and your team.

Introduction

This post will explore choosing a starter kit, using my experience building ~~this~~ a blog (note: the blog is not complete yet; I am posting this here in the meantime!) as an example. This will be the first post in a series that comes out of working on this website.

Since this is my first post, I want to start by sharing my experience. Coming into this, I've worked with React and TypeScript for about 5 years and I've been working in web development professionally for the past 10 years. My career has spanned finance, ed-tech, ad-tech, and currently internet security, as well as some freelancing.

I've typically been a full-stack engineer, usually focusing on front-end and user experience, which is where I hope I can provide the most help.

With that, let's (yarn?) start!

Why choose a starter kit at all?

There's value in building an application from scratch, particularly for gaining valuable learning experience as you go, and to be able to specify exactly what you want, and nothing else.

You can also choose to use a starter kit: a minimal application with pre-defined dependencies and some dummy content already in place.

A starter kit does a lot of heavy lifting for you out of the box and is usually a way to hit the ground running. When my team first picked up React, we went with a starter kit (Create React App) which abstracted a lot of the complexity away from us, and we were able to focus on building the application and not worry (as much) about tooling.

How to choose a starter kit

I've gone through this process a handful of times, so at this point I think it may be helpful to others (and future me) to document what I look for and avoid. In a future post, I will also go into some detail about what I do after making a decision. These factors are mainly about the dependencies that are included, since you're going to change the content of the application anyways.

Luckily, it's not too hard to try a few different options before settling on one, and future you (or your team) will thank present you for making a good decision.

What to look for

Minimal
Good Tooling
Officially Supported

Minimal

When looking for a starter kit in the past, I came across a lot of options. After digging into them a bit, there was a lot of things I either didn't need, or didn't know if I needed. Having unnecessary dependencies can bias you into using them and may not align with you or your team's preference. By the time, and if, a need for such a dependency arises, there might be (in the JavaScript ecosystem's case, likely will be) something better.

You'll also probably notice some outdated packages that you'll want to update sooner than later, and having fewer packages to update will make it easier to update them.

For example, updating a library such as Redux (and its peer dependencies, and their TypeScript definitions) might introduce breaking changes into the boilerplate content which you'll be re-writing anyways. By the time you want to introduce state management, there will likely be a newer version, or a more suitable alternative.

Good Tooling

By "tooling", I am essentially referring to specific dev dependencies. You'll likely want things like formatting, linting, and testing systems in place eventually, so you may as well get a starter kit that already has them integrated for you. Each of these will have its own options to choose from (like formatting rules), so picking a starting kit that has these out-of-the-box will mean they will work with each other (for example: ESLint, Prettier, and TypeScript configurations working seamlessly together).

Officially Supported

Official starter kits, like those found on a framework's or library's website, are going to be more general-purpose, and not something that was created for a specific use case in the past and no longer maintained. They'll also be more up-to-date, and in some cases have a built-in mechanism to update itself. Official kits typically have the same licenses as their library or framework which may be important if a license is something you need to consider.

Next.JS has a set of many examples that, while not the most user-friendly, is easy to navigate and covers most needs. These examples are also used to populate the options when you run the create next-app script, so once you pick one, installing it is a snap.

Gatsby has hundreds of starter kits available with easy like previews. However, only three of them are maintained by the Gatsby team themselves. The list can be filtered by Gatsby Version, dependencies, and categories ("Official", "Blog").

While the only official starter kit from the React team, Create React App is likely the most mature stater kit in the React ecosystem, easy to keep up to date, and sufficiently configurable while abstracting a lot of the complexity away.

Conclusion

With these factors in mind, I started looking through the Next.JS examples repo. I knew I wanted to use TypeScript, so that narrowed my choices down to a manageable handful.

With these points in mind, I picked with-typescript-eslint-jest for Next.JS. Taking away aspects that I don't need (or at least don't think I need yet), slimmed the list down to four:

Looking into each package.json file (linked above), I knew that TypeScript will add some extra dependencies for type definitions, but overall they were all manageable.

I knew I wanted a CSS-in-JS library, but wasn't sure if I wanted to use styled-components, so I eliminated with-typescript-styled-components from my list first.

blog-starter-typescript had some useful blog- and markdown-specific libraries (remark, gray-matter), though I wasn't sure if I would be using them. It was also almost on the latest version of TypeScript (although it's in the dependencies section rather than devDependencies). It also included some other libraries I knew I would be removing (tailwindcss). Writing this post and looking into this example more, I found some other questionable decisions such as the inclusion of @types/jest but not jest itself and the inclusion of remark-html which has the following disclaimer on its README "it’s probably smarter to use remark-rehype directly". These are minor points, but all reduce my confidence in picking it.

with-typescript-eslint-jest had by far the largest list of dependencies, but it was everything I would have included anyways, and nothing I wouldn't have. The nature of jest and eslint typically require additional @types in the devDependencies section, but this example had the same list of dependencies as with-typescript itself. Aside from the given ESLint and Jest, the example came with Prettier, lint-staged and husky to automatically format the files when you commit your changes. As a bonus, jest-watch-typeahead, which lets you filter your tests as you're running them, is probably something I would not have installed but eventually wished I had. All dependencies were relatively up to date, and having ESLint and Jest included would save me some installation and configuration steps I would have to do with the bare TypeScript example, so I settled on with-typescript-eslint-jest.

While a complete checklist is not possible, I hope this provides some guidance for your next application. Whether it's a side project to get your career off the ground, an internal tool or your team's next project, carefully considering and vetting your options pays off in the future!

My next post will go into what I did next: from updating configurations to laying down foundation for easier maintenance in the future.

DEV Community: Simon Goldin

Trust But Verify: Evaluating Security When Choosing Data Infrastructure Tools

A data leader's guide to maintaining security when working with third-party vendors

Originally published on Twing Data

Data Access

Least Privilege

API & Integration Security

Data Management

Data Retention

Data Isolation

Data Anonymization

Encryption (Data at Rest & In Transit)

App Architecture

Cloud Infrastructure Security

Logging and Monitoring

Company Practices

Compliance & Certification

Incident Response & Recovery

Secure Development Practices

Third-Party Risk Management

Choosing the right data vendor for your business

Generative AI for 3D Modeling and Printing

Introduction

Initial Attempt

Another Approach

Tradeoffs

Going Further

Final thoughts & takeaways

AI/LLM Recipe Generator with chatGPT

Pre-setup

Calling the API

Handling the response

Advanced options

Limitations

Fine-tuning and cost

Summary

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

Introduction

Project overview

Component setup

Sending emails with AWS Simple Email Service (SES)

Preventing spam with Google ReCaptcha v2

Outro

Setting up Create React App with @emotion/react v11 and and TypeScript 4.5.5 (Bonus: replacing npm with yarn)

Intro

Bonus: npm to yarn 3 migration

Configuring your React Starter Kit

Introduction

Update dependencies

Configurations

ESLint

Prettier

TypeScript

Other Configurations

Rebuild and Run Tests

Commit and push

IDE Setup

Summary

Choosing a React Starter Kit

Introduction

Why choose a starter kit at all?

How to choose a starter kit

What to look for

Minimal

Good Tooling

Officially Supported

Conclusion

Bonus: `npm` to `yarn 3` migration