
Yes ladies and gentleman, a post about developing with **AI**!

If you're team is looking to incorporate an LLM into your services, the first challenge to overcome is how to do so in a cost effective way.

Chances are, your business is already focused on a specific product domain, with resources targeted towards building that solution. This already is going to point you towards finding an off the shelf solution to integrate with an API.

With your flavor of LLM picked, the next set of challenges center around getting it to respond to questions in a way that meaningfully provides answers from your business data. LLM's need to be informed on how to respond to requests, what data to utilize when considering their answers, and even what to do if they're tempted to guess.

The way forward is through prompt engineering, with the help of **Retrieval-Augmented Generation**

## Retrieval-Augmented Generation

The simplified procedure for RAG goes as follows:

1. Request is made to your app with the message "How many Tex-Mex Restaurants are in Dallas?"
2. Your application gathers context. For example, we may make a query to our DB for a summary of all restaurants in the area.
3. We'll provide a summary of the context and instructions to the LLM with a prompt.
4. We send along the response to the user.

That's an overly simplified walk through, but it should already get you thinking about the details involved in those steps depending on your use case.

Another benefit to this is that requests to an API are not inherently stateful. The chat window of an AI app will remember our previous messages. But my API request to that third party does not automatically. We have to store and retrieve that context.

## AI Agents

It's worth noting that step 2 may even require an LLM to parse the question and then interact with an API to gather data. There's a fair amount of complexity to still parse in developing these solutions. This is where you may be leaning on an **AI Agent**. An agent is an LLM that will parse a result and determine if a tool is required, such as pinging your internal APIs.

Prompt Engineering is emerging as a role and craft all of its own, and there are [many nuances to doing it well](https://medium.com/@springs_apps/prompt-engineering-examples-and-best-practices-82b1da724643).

## LangChain

The workflow is already so common that there's a framework at the ready to spin up and take care of the heavy lifting for you. [LangChain](https://www.langchain.com/langchain) (stylized as 🦜⛓️‍💥) is just that tool.

For a hands on experience building a RAG application on rails, their docs on [building a chatbot](https://python.langchain.com/docs/tutorials/chatbot/) are a good starting place.

For a more complex agentive tool, [LangGraph](https://www.langchain.com/langgraph) opens up the hood on LangChain for more control and plays nicely with LangChain when needed.


The Retrieval-Augmented Generation Pattern for AI Development

Campfire Folk Intro

Brunner - Rondoletto


![Hootin' and scootin'](https://res.cloudinary.com/cpadilla/image/upload/v1699647693/chrisdpadilla/blog/art/owl_dance_Large_g8fgb8.jpg)


WHO has the smoothest moves?


There are two ways of creating datatypes similar to JavaScript Objects and Python Dictionaries in Go: Structs and Maps.

**Structs** are a collection of data that are related. Values are stored next to each other in memory. Structs are also a value type.

**Maps** are a hash map data type. They are a key value pair where both keys and values are statically typed individually. So all keys need to be of the same type, and all values need to be the same type. The main benefit is that, as a hash map, indexing and look up is much faster.

Let's break all that down:

Values are stored next to each other assuming the value will be lightweight. In this way, it's similar to an array where the keys are strings. Though, the values are not indexed the way that a hash map would for its keys. The tradeoff is that the value is lighter on memory, but slower to iterate through.

Structs are a value type. So if we were to pass them into a function, the entire struct would be copied. Maps, on the other hand, are a reference type. The address in memory for the Map is passed into a function and any changes to the map within the function will occur as a side effect to the same Map.

## Structs

Declaring structs requires a type to be created first:

```
type car struct {
	make		string
	model		string
	maxSpeed	int
}

c := car{make: "Toyota", model: "Prius", maxSpeed: 120}

```

## Methods

Go isn't an Object Oriented Language, but like JavaScript, can be implemented with similar principles. An example is having methods on Structs:

```
type car struct {
	make		string
	model		string
	maxSpeed	int
}

func (c car) floorIt() int {
	return c.maxSpeed
}

c := car{make: "Toyota", model: "Prius", maxSpeed: 120}
c.floorIt() // 120
```

## Embedding

Another OOP principle borrowed in Go is _composition_. In Go, we can embed structs to create more complex types while still maintaining the flexibility of smaller pieces available as individual structs.

```
type car struct {
	make		string
	model		string
	maxSpeed	int
}

type raceCar struct {
	car
	turboEngine	string
}

rc := raceCar{
	car: car{
		make: "Toyota",
		model: "Prius",
		maxSpeed: 120,
	},
	turboEngine: "MAX"
}

```


Structs in Go


Twitter is in a spot, so it's time to turn to good ol' RSS feeds and email for keeping up with your favorite artists, developers, and friends!

We built one [for our game](https://acnewmurder.com/). This is another case in which building forms are more interesting than you'd expect.

# Component Set Up

To get things started, I've already built an API similar to the one outlined [here in my Analytics and CORS post](/diyanalytics)

There are ultimately three states for this simple form: Pre-submitting, success, and failure.

Here's the state that accounts for all of that:

```
// Newsletter.js

import React from 'react';
import styled from 'styled-components';
import { useState } from 'react';
import { signUpForNewsletter } from '../lib/util';

const defaultMessage = 'Enter your email address:';
const successMessage = 'Email submitted! Thank you for signing up!';

const Newsletter = () => {
  const [emailValue, setEmailValue] = useState('');
  const [message, setMessage] = useState(defaultMessage);
  const [emailSuccess, setEmailSuccess] = useState(false);

  . . .
};
```

We're holding the form value in our `emailValue` state. `message` is what is displayed above our input to either prompt them to fill the form, or inform them they succeeded. `emailSuccess` is simply state that will adjust styling for our success message later.

# Rendering Our Component

Here's is that state in action in our render method:

```
// Newsletter.js

  return (
    <StyledNewsletter onSubmit={handleSubmit}>
      <label
        htmlFor="email"
        style={{ color: emailSuccess ? 'green' : 'inherit' }}
      >
        {message}
      </label>
      <input
        type="email"
        name="email"
        id="email"
        value={emailValue}
        onChange={(e) => setEmailValue(e.currentTarget.value)}
      />
      <button type="submit">Sign Up</button>
    </StyledNewsletter>
  );

```

Setting our input to email will give us some nice validation out of the box. I'm going against the current common practice by using inline styles here for simplicity.

# Handling Submit

Let's take a look at what happens on submit:

```
// Newsletter.js

  const handleSubmit = async (e) => {
    e.preventDefault();
    if (emailValue && isValidEmail(emailValue)) {
      const newsletterRes = await signUpForNewsletter(emailValue);
      if (newsletterRes) {
        setEmailValue('');
        setEmailSuccess(true);
        setMessage(successMessage);
      } else {
        window.alert('Oops! Something went wrong!');
      }
    } else {
      window.alert('Please provide a valid email');
    }
  };

```

The html form, even when we prevent the default submit action, actually still checks the email input against it's built in validation method. A great plus! I have a _very_ simple `isValidEmail` method in place just to double check.

Once we've verified everything looks with our inputs, on we go to sending our fetch request.

```
// util.js

export const signUpForNewsletter = (email) => {
  const data = { email };

  if (!email) console.error('No email provided', email);

  return fetch('https://coolsite.app/api/email', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(data),
  })
    .then((response) => response.json())
    .then((data) => {
      console.log('Success:', data);
      return true;
    })
    .catch((error) => {
      console.error('Error:', error);
      return false;
    });
};

```

I'm including return statements and a handler based on those return statements later with `if (newsletterRes) ...` in our component. If it's unsuccessful, returning false will go into our very simple `window.alert` error message. Else, we continue on to updating the state to render a success message!

# Wrap Up

That covers all three states! Inputing, error, and success. This, in my mind, is the bare bones of getting an email form setup! Yet, there's already a lot of interesting wiring that goes into it.

From a design standpoint, a lot of next steps can be taken to build on top of this. From here, you can take a look at the API and handle an automated confirmation message, you can include an unsubscribe flow, and you can include a "name" field to personalize the email.

Even on the front end, a much more robust styling for the form can be put in place.

Maybe more follow up in the future. But for now, a nice sketch to get things started!

Here's the full component in action:

```
// Newsletter.js

import React from 'react';
import styled from 'styled-components';
import { useState } from 'react';
import { signUpForNewsletter } from '../lib/util';

const defaultMessage = 'Enter your email address:';
const successMessage = 'Email submitted! Thank you for signing up!';

const Newsletter = () => {
  const [emailValue, setEmailValue] = useState('');
  const [message, setMessage] = useState(defaultMessage);
  const [emailSuccess, setEmailSuccess] = useState(false);

  function isValidEmail(email) {
    return /\S+@\S+\.\S+/.test(email);
  }

  const handleSubmit = async (e) => {
    e.preventDefault();
    if (emailValue && isValidEmail(emailValue)) {
      const newsletterRes = await signUpForNewsletter(emailValue);
      if (newsletterRes) {
        setEmailValue('');
        setEmailSuccess(true);
        setMessage(successMessage);
      } else {
        window.alert('Oops! Something went wrong!');
      }
    } else {
      window.alert('Please provide a valid email');
    }
  };

  return (
    <StyledNewsletter onSubmit={handleSubmit}>
      <label
        htmlFor="email"
        style={{ color: emailSuccess ? 'green' : 'inherit' }}
      >
        {message}
      </label>
      <input
        type="email"
        name="email"
        id="email"
        value={emailValue}
        onChange={(e) => setEmailValue(e.currentTarget.value)}
      />
      <button type="submit">Sign Up</button>
    </StyledNewsletter>
  );
};

export default Newsletter;

const StyledNewsletter = styled.form`
  display: flex;
  flex-direction: column;
  max-width: 400px;
  font-family: inherit;
  font-size: inherit;
  padding: 1rem;
  text-align: center;
  align-items: center;
  margin: 0 auto;

  label {
    margin: 1rem 0;
  }

  #email {
    width: 80%;
    padding: 0.5rem;
    /* border: 1px solid #75ddc6;
    outline: 3px solid #75ddc6; */
    font-family: inherit;
    font-size: inherit;
  }

  button[type='submit'] {
    position: relative;
    border-radius: 15px;
    height: 60px;
    display: flex;
    -webkit-box-align: center;
    align-items: center;
    -webkit-box-pack: center;
    justify-content: center;
    padding: 2rem;
    font-weight: bold;
    font-size: 1.3em;
    margin-top: 1rem;
    background-color: var(--cream);
    color: var(--brown-black);
    border: 3px solid var(--brown-black);
    transition: transform 0.2s ease;
    text-transform: uppercase;
  }

  button:hover {
    color: #34b3a5;
    background-color: var(--cream);
    border: 3px solid #34b3a5;
    cursor: pointer;
  }
`;

```


Creating a Newsletter Form in React


For those times you just need a sip of backend, Lambda functions serve as a great proxy.

For my situation, I needed a way for a client to submit a form to an endpoint, use a proxy to access an API key through environment variables, and then submit to the appropriate API. The proxy is still holding onto sensitive data, so in lieu of storing an API key on the client (no good!), I'm using [CORS](/diyanalytics) to keep the endpoint secure.

# Handling Pre-Flight Requests:

[This article by Serverless](https://www.serverless.com/blog/cors-api-gateway-survival-guide/) is a nice starting place. Here are the key moments for setting up cors:

```
# serverless.yml

service: products-service

provider:
  name: aws
  runtime: nodejs6.10

functions:
  getProduct:
    handler: handler.getProduct
    events:
      - http:
          path: product/{id}
          method: get
          cors: true # <-- CORS!
  createProduct:
    handler: handler.createProduct
    events:
      - http:
          path: product
          method: post
          cors: true # <-- CORS!

```

The key config, `cors: true` is a good start, but is the equivalent of setting our header to `'Access-Control-Allow-Origin': '*'`. Essentially, this opens our endpoint up to any origin. So we'll need to find a way to secure this to only a couple of urls.

Serverless here recommends handling multiple origins in the request itself:

```
// handler.js
const ALLOWED_ORIGINS = [
	'https://myfirstorigin.com',
	'https://mysecondorigin.com'
];

module.exports.getProduct = (event, context, callback) => {

  const origin = event.headers.origin;
  let headers;

  if (ALLOWED_ORIGINS.includes(origin) {
    headers: {
      'Access-Control-Allow-Origin': origin,
      'Access-Control-Allow-Credentials': true,
    },
  } else {
      headers: {
      'Access-Control-Allow-Origin': '*',
    },
  }

  . . .
}
```

This alone would work fine for simple GET and POST requests, however, more complex requests will send a [Preflight OPTIONS request](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests). I _am_ sending a POST request, but it would have to be an html form submission to qualify as "simple." Since I'm sending JSON, it's considered complex and a preflight request is sent.

A little more looking in [serverless docs](https://www.serverless.com/framework/docs/providers/aws/events/apigateway#http-endpoint-with-extended-options) shows us how we can approve multiple origins for our preflight requests:

```
# serverless.yml

cors:
  origins:
    - http://www.example.com
    - http://example2.com
```

# Server response with Multiple Origins

When allowing multiple origins, the response needs to return a single origin in the header, matching the request origin. If we send a comma delineated string with all our origins, the response will not be accepted.

In our server code above, we did handled this with the logic below:

```
 const origin = event.headers.origin;
  let headers;

  if (ALLOWED_ORIGINS.includes(origin) {
    headers: {
      'Access-Control-Allow-Origin': origin,
      'Access-Control-Allow-Credentials': true,
    },
  }
```

We grab the origin from our request headers, match it with our approved list, and then send it back in the response headers.

# Lambda & Lambda Proxy

To have access to our request headers, we need to ensure we are using the correct integration.

**Lambda Proxy integration** is the default with serverless and the one that will include the headers.

So why am I pointing this out?

Some Lambdas you work with may include `integration: lambda` in their config file:

```
functions:
  create:
    handler: posts.create
    events:
      - http:
          path: posts/create
          method: post
          integration: lambda
```

These are set to launch the function as **Lambda integrations**.

The general idea is that Lambda Proxy integrations are easier to set up while Lambda integrations offer a bit more control. The only extra bit of work required for Lambda proxy is handling your own status codes in the response message, as we did above. Lambda integrations may be more suitable in situations where you need to modify a request before sent to the lambda or a response after. (A really nice overview of the [difference is available in this article](https://medium.com/@lakshmanLD/lambda-proxy-vs-lambda-integration-in-aws-api-gateway-3a9397af0e6d).)

So, if you're setting up your own lambda, no need to do anything different to access the headers. If working with an already established set of APIs, keep an eye out for `integration: lambda`. Accessing headers will take some extra considerations in that case.


Chris Padilla/Blog

On This Day