Builder.io

builderio

5 Integrations in React: Contentful, Tilda, Hubspot, Typeform, Builder.io

Welcome back to this series where we are learning how to integrate products into web application. AI Intro & Setup Your First AI Prompt Streaming Responses How Does AI Work Prompt Engineering AI-Generated Images Security & Reliability Deploying In this post, we are going to use AI to generate images. Before we get to that, let’s add a dialog component to our app. This is a modal-like pop-up designed to show content and be dismissed with the mouse or keyboard. https://www.youtube.com/watch?v=V3DjC6-sGBA&embedable=true Create A Dialog Component Before showing an image, we need a place to put it. I think it would be nice to have a dialog that pops up to showcase the image. This is a good opportunity to spend more time with Qwik components. By convention, our new component should go in the folder. I’ll call mine (or if you prefer TypeScript). A Qwik component file should have a default export of a Qwick component. ./src/components Dialog.jsx .tsx To create one, we use the function from . This function takes a function component that returns JSX: component$ @builder.io/qwik import { component$ } from "@builder.io/qwik";

export default component$((props) => {

  return (
    <div>
      
    </div>
  )
}) At the moment, it’s not very useful. Let’s plan out the API design for this dialog. It should have the following characteristics: Opened by clicking on a button. Can be opened programmatically from the parent. Closed by pressing the Esc key. Closed by clicking the dialog background. Can be closed programmatically from the parent. has a element which is great, but it doesn’t quite offer the API that I’m looking for. With a little bit of work, we can fill in the gaps. HTML <dialog> Let’s start with a component that provides a element for controlling the dialog and the element that will contain any content you put inside. Clicking the button should trigger the method. Clicking outside the dialog should trigger the method. <button> <dialog> dialog.showModal() dialog.close() Pressing the Esc key closes the dialog already, so that’s sorted. To trigger the dialog methods, we need access to the DOM node, which we can get by . In our dialog component, we can add content using a , a flexible space inside the dialog where you can put content. using a ref and a signal <Slot> We should also provide a btnText prop to allow for customization of the text on the button that opens the dialogue. Here’s what I have so far: import { component$, useSignal, Slot } from "@builder.io/qwik";

export default component$(({ btnText }) => {
  const dialogRef = useSignal()

  return (
    <div>
      <button onClick$={() => dialogRef.value.showModal()}>
        {btnText}
      </button>

      <dialog
        ref={dialogRef}
        onClick$={(event) => {
          if (event.target.localName !== 'dialog') return
          dialogRef.value.close()
        }}
      >
        <div class="p-2">
          <Slot></Slot>
        </div>
      </dialog>
    </div>
  )
}) Note the additional inside the . This lets me add some padding, but more importantly, it helps me track whether a click on the dialog happened in the background (the dialog element) or on the content (the div and children). This lets us close the dialog only when the background is clicked. <div> <dialog> That gets us some basic functionality, but for my use case, I want to be able to programmatically open the dialog from the parent, not just when the toggle button is clicked. For that, we need a small refactor. To control the dialog from a parent, we need to add a new prop and trigger the dialog methods as it changes. Rather than repeat the open/close functionality for internal external changes, let’s create a local state with to track whether the dialog should be shown or not. and useStore() Then, we can simply toggle the state and respond to those changes using a (it’s like in React). If the prop from the parent changes, we need to respond to that change using another task, but this time, we’ll use . Qwik task useEffect open useVisibleTask$() We also need to provide a way for the parent component to be aware of changes to the dialog’s visibility. We can do that by providing a custom prop that will call the function whenever the dialog closes. And lastly, if we’re providing programmatic control from the parent, we may want to provide a way to hide the . onClose$ <button> import { component$, useSignal, Slot, useStore, useTask$, useVisibleTask$ } from "@builder.io/qwik";

export default component$(({ btnText, open, onClose$ }) => {
  const dialogRef = useSignal()
  const state = useStore({
    isOpen: false,
  })

  useTask$(({ track }) => {
    track(() => state.isOpen)

    const dialog = dialogRef.value
    if (!dialog) return

    if (state.isOpen) {
      dialog.showModal()
    } else {
      dialog.close()
      onClose$ && onClose$()
    }
  })
  useVisibleTask$(({ track }) => {
    track(() => open)
    state.isOpen = open || false
  })

  return (
    <div>
      {btnText && (
        <button onClick$={() => state.isOpen = true}>
          {btnText}
        </button>
      )}

      <dialog
        ref={dialogRef}
        onClick$={(event) => {
          if (event.target.localName !== 'dialog') return
          state.isOpen = false
        }}
      >
        <div class="p-2">
          <Slot></Slot>
        </div>
      </dialog>
    </div>
  )
}) This is a lot better, but there’s still a little work to do. I like to make sure my components are and typed. In this case, since we’re using a button to control the visibility of the dialog, it makes sense to add and attributes to the button. accessible aria-controls aria-expanded To connect them to the dialog, the dialog needs an ID, which we can either take from the props or dynamically generate. Lastly, pressing escape will close the dialog, but we also need to track the dialog’s native event by attaching an handler. "close" onClose$ Here is my finished component, including : JSDoc type definitions import {component$, useSignal, Slot, useStore, useTask$, useVisibleTask$ } from "@builder.io/qwik";
import { randomString } from "~/utils.js";

/**
 * @typedef {HTMLAttributes<HTMLDialogElement>} DialogAttributes
 *
 * @type {Component<DialogAttributes  & {
 * toggle: string|false,
 * open?: Boolean,
 * onClose$?: import('@builder.io/qwik').PropFunction<() => any>
 * }>}
 */
export default component$(({ toggle, open, onClose$, ...props }) => {
  const id = props.id || randomString(8)

  const dialogRef = useSignal()
  const state = useStore({
    isOpen: false,
  })

  useTask$(({ track }) => {
    track(() => state.isOpen)

    const dialog = dialogRef.value
    if (!dialog) return

    if (state.isOpen) {
      dialog.showModal()
    } else {
      dialog.close()
      onClose$ && onClose$()
    }
  })
  useVisibleTask$(({ track }) => {
    track(() => open)
    state.isOpen = open || false
  })

  return (
    <div>
      {toggle && (
        <button aria-controls={id} aria-expanded={state.isOpen} onClick$={() => state.isOpen = true}>
          {toggle}
        </button>
      )}

      <dialog
        ref={dialogRef}
        id={id}
        onClick$={(event) => {
          if (event.target.localName !== 'dialog') return
          state.isOpen = false
        }}
        onClose$={() => state.isOpen = false}
        {...props}
      >
        <div class="p-2">
          <Slot></Slot>
        </div>
      </dialog>
    </div>
  )
}) Cool! Now that we have a working dialog component, we need to put something in it. Generate AI Images With OpenAI Once the AI has determined a winner between opponent1 and opponent2, it would be cool to offer an image of them in combat. So why not add a button that says “Show me” after the results are available? After the text in the template, we could add a conditional like this: {state.winner && (
  <button>
    Show me
  </button>
)} Awesome! It’s just too bad it doesn’t do anything… To actually generate the AI image, we need to make another API request to OpenAI which means we need another API endpoint in our backend. We’ve already assigned a request handler to the current route. Let’s add a new route to handle GET requests to by adding a new file in . /ai-image /src/routes/ai-image/index.js In many cases, a new route may need to return HTML from the server to generate a page. That’s not the case for this route. This will only ever return JSON, so it doesn’t need to be a JSX file or return a component. Instead, we can export a custom like we did for post requests on the first page. To do that, we create a named export called that can look something like this: middleware onGet export const onGet = async (requestEvent) => {
  requestEvent.send(200, JSON.stringify({ some: 'data' }))
} Now, to get the route working, we need to do the following: Grab opponent1 and opponent2 from the request (we’ll use query parameters). Use the opponents to construct a prompt using LangChain templates. Create a body for the OpenAI API request containing the prompt and the image size we want (I’ll use ). "512x512" Create the authenticated HTTP request to OpenAI. Respond to the initial request with the URL of the generated image. For more details on working with images through OpenAI, refer to their . documentation Here’s how my implementation looks: import { PromptTemplate } from 'langchain/prompts'

const mods = [
  'cinematic',
  'high resolution',
  'epic',
];

const promptTemplate = new PromptTemplate({
  template: `{opponent1} and {opponent2} in a battle to the death, ${mods.join(', ')}`,
  inputVariables: ['opponent1', 'opponent2']
})

/** @type {import('@builder.io/qwik-city').RequestHandler} */
export const onGet = async (requestEvent) => {
  const OPENAI_API_KEY = requestEvent.env.get('OPENAI_API_KEY')

  const opponent1 = requestEvent.query.get('opponent1')
  const opponent2 = requestEvent.query.get('opponent2')

  const prompt = await promptTemplate.format({
    opponent1: opponent1,
    opponent2: opponent2
  })

  const body = {
    prompt: prompt,
    size: '512x512',
  }

  const response = await fetch('https://api.openai.com/v1/images/generations', {
    method: 'post',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${OPENAI_API_KEY}`,
    },
    body: JSON.stringify(body)
  })
  const results = await response.json()

  requestEvent.send(200, JSON.stringify(results.data[0]))
} It’s worth noting that the response from OpenAI should look something like this: {
  "created": 1589478378,
  "data": [
    {
      "url": "https://..."
    },
    {
      "url": "https://..."
    },
  ]
} Also worth mentioning is the lack of validation for the opponents. It’s always a good idea to validate user input before processing it. Why don’t you try addressing that as an additional challenge? Provide AI Images With Art Direction In the code example above, you may have noticed the array that gets joined and appended to the end of the prompt. This is worth a callout. mods Generative images are tricky because the same prompt can return drastically different results. You might get a cartoon, an oil painting, or a sketch. So, it’s important to include a couple of hints to the AI to match the aesthetic of your application. I found that using an array with several different options allowed me to easily toggle off various features. In fact, in my actual project, I keep a much longer list of options, organized by style, format, quality, and effect. const mods = [
  /** Style */
  // 'Abstract',
  // 'Academic',
  // 'Action painting',
  // 'Aesthetic',
  // 'Angular',
  // 'Automatism',
  // 'Avant-garde',
  // 'Baroque',
  // 'Bauhaus',
  // 'Contemporary',
  // 'Cubism',
  // 'Cyberpunk',
  // 'Digital art',
  // 'photo',
  // 'vector art',
  // 'Expressionism',
  // 'Fantasy',
  // 'Impressionism',
  // 'kiyo-e',
  // 'Medieval',
  // 'Minimal',
  // 'Modern',
  // 'Pixel art',
  // 'Realism',
  // 'sci-fi',
  // 'Surrealism',
  // 'synthwave',
  // '3d-model',
  // 'analog-film',
  // 'anime',
  // 'comic-book',
  // 'enhance',
  // 'fantasy-art',
  // 'isometric',
  // 'line-art',
  // 'low-poly',
  // 'modeling-compound',
  // 'origami',
  // 'photographic',
  // 'tile-texture',

  /** Format */
  // '3D render',
  // 'Blender Model',
  // 'CGI rendering',
  'cinematic',
  // 'Detailed render',
  // 'oil painting',
  // 'unreal engine 5',
  // 'watercolor',
  // 'cartoon',
  // 'anime',
  // 'colored pencil',

  /** Quality */
  'high resolution',
  // 'high-detail',
  // 'low-poly',
  // 'photographic',
  // 'photorealistic',
  // 'realistic',

  /** Effects */
  // 'Beautiful lighting',
  // 'Cinematic lighting',
  // 'Dramatic',
  // 'dramatic lighting',
  // 'Dynamic lighting',
  'epic',
  // 'Portrait lighting',
  // 'Volumetric lighting',
]; I’ve also found that it’s better to include these modifiers at the end of the prompt, otherwise, they can be forgotten. Request an AI-Generated Image Now that our endpoint is ready, we can start using it. We need to send an HTTP request with query parameters including opponent1 and opponent2. We can pull those values from the s on demand, but I prefer to maintain some reactive state that gets updated any time a user types into the s. <textarea> <textarea> Let’s modify our to include properties for opponent1 and opponent2: state const state = useStore({
  isLoading: false,
  text: '',
  winner: '',
  opponent1: '',
  opponent2: '',
}) Next, let’s add an event handler that will update the state. The event handler should probably also clear any previous text results and winners. Note that we need to do this for both inputs. onInput$ <Input
  label="Opponent 1"
  name="opponent1"
  value={state.opponent1}
  class={{
    rainbow: state.winner === 'opponent1'
  }}
  onInput$={(event) => {
    state.winner = ''
    state.text = ''
    state.opponent1 = event.target.value
  }}
/> Now that we have the values conveniently available, we can construct the HTTP request. We could do this when the “Show me” button is clicked, but we already made the function in . Might as well reuse it. All it needs is a with the data to send. jsFormSubmit the third post of the series <form> Let’s create a form that submits to our route, prevents the default behavior, and submits the data with instead. We can use hidden inputs to put the data in the form without impacting the UI. /ai-image jsFormSubmit {state.winner && (
  <form
    action="/ai-image"
    preventdefault:submit
    onSubmit$={async (event) => {
      const form = event.target
      console.log(await jsFormSubmit(form))
    }}
    class="mt-4"
  >
    <input
      type="hidden"
      name="opponent1"
      value={state.opponent1}
      required
    />
    <input
      type="hidden"
      name="opponent2"
      value={state.opponent2}
      required
    />
    <button type="submit">
      Show me
    </button>
  </form>
)} It looks the same as it did before, but now, it actually does something. I would show you a screenshot, but it’s pretty much just a button. Unremarkable, but effective. Show the Image in the Dialog The last step is to put it all together. The user submits the two opponents, and the AI returns a winner. The image generation will be available, showing the user the “Show me” button. <form> When the user clicks the button, the API request gets submitted. At the same time, we’ll programmatically open the dialog with some initial loading state. When the request returns, we’ll display the image. For that, I’ll create a new store for the image state using . It’ll hold a state, an state, and the . I’m also going to move the form’s submit handler into a dedicated function called so it’s not nested in the template and all the logic can live together. useStore showDialog isLoading url onSubmitImg The body of the function will activate the dialog, set the loading state, submit the form with , set the image URL from the results, and disable the loading state. obSubmitImg jsFormSubmit const imgState = useStore({
  showDialog: false,
  isLoading: false,
  url: ''
})
const onSubmitImg = $(async (event) => {
  imgState.showDialog = true
  imgState.isLoading = true

  const form = event.target

  const response = await jsFormSubmit(form)
  const results = await response.json()

  imgState.url = results.url
  imgState.isLoading = false
}) Man, I love that function! It lets the HTML provide the declarative HTTP logic and simplifies the business logic. jsFormSubmit Ok – with the state setup, the last thing to do is connect the component. Since we’ll be opening it programmatically, we don’t need the built-in button. We can disable that by making the prop falsy. We can connect the prop to . We’ll also want to update that state when the dialog closes via the event. <Dialog> btnText open imgState.showDialog onClose$ And the contents of the dialog should either show something for the loading state or show the generated image. <Dialog
  btnText={false}
  open={imgState.showDialog}
  onClose$={() => imgState.showDialog = false}
>
  {imgState.isLoading && (
    "Working on it..."
  )}
  {!imgState.isLoading && imgState.url && (
    <img src={imgState.url} alt={`An epic battle between ${state.opponent1} and ${state.opponent2}`} />
  )}
</Dialog> Unfortunately, we now have a button that programmatically opens a dialog element without accessibility considerations. I thought about including the same ARIA attributes as we have on the toggle, but if I’m honest, I’m not sure if a submit button control a dialog. should In this case, I’m leaving it out because I don’t know the right approach, and sometimes doing accessibility wrong leads to a worse experience than doing nothing at all. Open to suggestions. :) Closing Okay, I think that’s as far as we’ll get today. It’s time to stop and enjoy the fruits of our labor. Okay, OpenAI isn’t the best AI image generator, or maybe my prompt skills need some work. I’d love to see how yours turned out. A lot of the things we covered today were a review: building Qwik components, making HTTP requests to OpenAI, state, and conditional rendering in the template. The biggest difference, I think, is how we treat prompts for AI images. I find they require a little more creative thinking and finagling to get right. Hopefully, you found this helpful. In the video version, we covered a really cool SVG component that I think is worth checking out, but this post was already long enough. Functionally, the app is as far as I want to take it, so In the next post, we’ll focus on reliability and security before we get into launching to production. Intro & Setup Your First AI Prompt Streaming Responses How Does AI Work Prompt Engineering AI-Generated Images Security & Reliability Deploying Thank you so much for reading. If you liked this article, and want to support me, the best ways to do so are to , , and . share it sign up for my newsletter follow me on Twitter Originally published on . austingil.com

AI for Web Devs: How to Generate Images Using AI

Welcome back to this series where we are building web applications that incorporate tooling. , we covered what AI is, how it works, and some related terminology. AI In the previous post Articles in this Series Intro & Setup Your First AI Prompt Streaming Responses How Does AI Work Prompt Engineering AI-Generated Images Security & Reliability Deploying In this post, we’re going to cover prompt engineering, which is a way to modify your application’s behavior without changing the code. Since it’s challenging to explain without seeing the code, let’s get to it. https://www.youtube.com/watch?v=pK6WzlTOlYw&embedable=true Content Overview Start Adapting the UI Side-Quest: global.d.ts Adjust the Backend Begin Prompt Engineering Character Building Understanding Tokens Introducing LangChain Identifying the Winner Start Adapting the UI I hope, by now, you’ve come up with your idea for an AI app because this is where we’ll write mostly the same code but could end up with different apps. My app will take two different opponents and tell you who would win in a fight. I’ll start on the UI side of things because that’s easier for me. So far, we’ve been giving users a single and expecting them to write the entire prompt body to send to OpenAI. We can reduce the work users need to do and get more accurate prompts by modifying the UI to only ask for the missing details instead of the whole prompt. In my app’s case, we only need two things: opponent 1 and opponent 2. So instead of one input, we’ll have two. <textarea> This is a good opportunity to replace the with a reusable input component. <textarea> HTML I’ll add a file called to the folder. The most basic example of a Qwik component is a function that uses the function from and returns JSX. Input.jsx /src/components component$ "@builder.io/qwik" import { component$ } from "@builder.io/qwik";

export default component$((props) => {
  return (
    <div>
    </div>
  )
}) Our component should be reusable and accessible. For that, it needs a required prop, a required attribute, and an optional which will default to a random string if not provided. And any other HTML attribute can be applied directly on the form control. Input label name id Here’s what I came up with along with JSDocs type definitions (note that the function comes from ): randomString this utility repo import { component$ } from "@builder.io/qwik";
import { randomString } from "~/utils.js";

/**
 * @typedef {import("@builder.io/qwik").HTMLAttributes<HTMLTextAreaElement>} TextareaAttributes
 */

/**
 * @type {import("@builder.io/qwik").Component<TextareaAttributes  & {
 * label: string,
 * name: string,
 * id?: string,
 * value?: string
 * }>}
 */
export default component$(({id, label, value, ...props}) => {
  const id = id || randomString(8)

  return (
    <div>
      <label for={id}>{label}</label>
      <textarea id={id} {...props}>{value}</textarea>
    </div>
  )
}) It’s rudimentary, but works for our app. If you’re feeling spunky, I encourage you to modify it to support the other input and select elements. Now, instead of using a single for the whole prompt, we can replace it with one of our new Input components for each opponent. I’ll put them in a two-column grid, so they sit next to each other on large screens. <textarea> <div class="grid gap-4 sm:grid-cols-2">
  <Input label="Opponent 1" name="opponent1" />
  <Input label="Opponent 2" name="opponent2" />
</div> Side-Quest: global.d.ts If you’re interested in using or JSDocs, it may be useful to make the Qwik and global declarations so they’re easier to use across the application. TypeScript HTMLAttributes Component To do that, create a file at . Inside it, we’ll import and from with aliases, then create global declarations with their original names that implement their functionality: ./src/global.d.ts HTMLAttributes Component "@builder.io/qwik" import type { Component as QC, HTMLAttributes as QH } from "@builder.io/qwik"

declare global {
  export type Component<T> = QC<T>
  export type HTMLAttributes<T> = QH<T>
} This is just an optional step, but I like to do it because I use these two types of definitions frequently. It’s nice to not have to import them all the time. Adjust the Backend Now that we’ve changed our UI to reduce the amount of information we ask for, we can move to the backend. In the previous version, we were sending the entire prompt content using a form field named “prompt”. Now, we’re sending the two individual opponents, and we need to construct the prompt in the request handler. export const onPost = async (requestEvent) => {
  // ...
  const formData = await requestEvent.parseBody()

  const { opponent1, opponent2 } = formData
  const prompt = `Who would win in a fight between ${opponent1} and ${opponent2}?`

  // ...
} Functionally, this brings us back to where we were, except now there’s less work for the user to do and they have better guidance on what they need. That’s great! Unfortunately, the AI response is still something like, “As an AI language model I can’t predict hypothetical fights or determine definite winners blah blah blah…” It’s not very helpful. But because we’ve moved the control of the prompt to the backend, we’ve set the stage for prompt engineering because now we are in control of it instead of the user. Here’s where our apps can take wildly different routes depending on how closely you want to follow the prompt that I write or if you make your own. Begin Prompt Engineering The AI already told us that there is no way it could know who could win in a fight, but what if we’re a little more persuasive? Let’s change our prompt to something like this: const prompt = `Who would win in a fight between ${opponent1} and ${opponent2}?

Provide a creative and detailed explanation of why they would win and what tactics they might use.` Now, instead of asking the AI for a wishy-washy answer, we’re encouraging it to provide a creative explanation. The result? “In a hypothetical battle between a ninja and a pirate, the outcome would depend on several factors. Both ninjas and pirates possess unique skill sets and tactics that make them formidable opponents, so let’s imagine a thrilling encounter between the two and explore the possible outcome…” That’s much better! Of course, it’s going to be different each time, so I don’t expect you to get the same results, but the key thing is that the AI is cooperating. Character Building Our app is mostly working now, but I think we can also make it more interesting. One way to do that is to give the AI some context about the role it should play as it answers the questions. For example, why not make it answer questions as if it were a professional fighting judge from Liverpool who speaks mostly with Cockney slang? To do that, we simply need to modify our prompt, but I also like to break up my prompt into various sections so it’s easier to manage. const context = `You're a professional fighting judge from Liverpool that speaks mostly with Cockney slang`

const question = `Who would win in a fight between ${opponent1} and ${opponent2}?`

const format = `Provide a creative and detailed explanation of why they would win and what tactics they might use.`

const prompt = [context, question, format].join(' ') This way, each separate section is captured by its own variable, which makes things easier for me to follow when I look at this later on. What’s the result? “Alright, mate! Let me put on me Cockney cap and dive into this lively debate between a ninja and a pirate. Picture meself in Liverpool, surrounded by kickin’ brick walls, ready to analyze this rumble in the most creative way…” It spits out over three thousand words of ridiculousness, which is a lot of fun, but highlights another problem. The output is too long. Understanding Tokens Something worth understanding with these AI tools is “tokens”. F rom the OpenAI help article, “ “: What are tokens and how to count them? “Tokens can be thought of as pieces of words. Before the API processes the prompts, the input is broken down into tokens. These tokens are not cut up exactly where the words start or end – tokens can include trailing spaces and even sub-words.” A token accounts for roughly four characters, they are calculated based on the text that the AI receives and produces, and there are two big reasons we need to be aware of them: The platform charges based on the volume of tokens used. Each LLM has a limit on the maximum tokens it can work with. So it’s worth being cognizant of the length of text we send as a prompt as well as what we receive as a response. In some cases, you may want a lengthy response to achieve a better product, but otherwise, in other cases, it’s better to use fewer tokens. In our case, a three thousand-character response is not only a less-than-ideal user experience, it’s also costing us more money. Reducing Tokens Now that we’ve decided to reduce the tokens we use, the next question is, how? If you’ve read through the OpenAI docs, you may have noticed a parameter that we can set when we make the API request. Also, good on you for reading the docs. Five stars. max_tokens const body = {
  model: 'gpt-3.5-turbo',
  messages: [{ role: 'user', content: prompt }],
  stream: true,
  max_tokens: 100,
}

const response = await fetch('https://api.openai.com/v1/chat/completions', {
  method: 'post',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${OPENAI_API_KEY}`,
  },
  body: JSON.stringify(body)
}) Let’s see what happens when we set the parameter to something like 100. max_tokens Ok, now this is about the right length that I want, but it looks like it’s getting cut off. That’s because the GPT was given a hard limit on how much it could return, but it doesn’t account for that when constructing the response. As a result, we end up with an incomplete thought. Not ideal. Programmatically limiting the allowed length probably makes sense in some applications. It may even make sense in this one to add an upper bound. But to get a short AND complete response, the solution comes back to prompt engineering. Let’s modify our prompt to ask for a “short explanation” instead of a “creative and detailed” one. const format = `Only tell me who would win and a short reason why.` Okay, this is more like what I had in mind. This is about the right length and level of detail. If you want to massage it some more, I encourage you to do so, but I’m going to move on. Introducing LangChain I want to address the clunkiness of the current system. You can imagine if we had a lot more prompts and a lot more endpoints it might be hard to manage. That’s why I want to introduce a toolchain called . In this new and constantly shifting world of AI, it’s been emerging as the leading tool chain for working with prompts. LangChain Let’s see why. First, install the package with . npm install @langchain/core The most relevant thing we can do with LangChain for our project is to generate prompts using . Instead of generating our prompt from within our route handler, we can create a shareable prompt template and only provide the variables (opponent 1 & 2) at runtime. It’s essentially a factory function for prompts. prompt templates We can import the module from , then create a template and configure any variables it will consume like this: PromptTeplate "@langchain/core/prompts" const promptTemplate = new PromptTemplate({
  inputVariables: ['opponent1', 'opponent2'],
  template: `You're a professional fighting judge from Liverpool that speaks mostly with Cockney slang. Who would win in a fight between {opponent1} and {opponent2}? Only tell me who would win and a short reason why.`,
}) Notice that we’re using two called “opponent1” and “opponent2”. These will be referenced in the template inside curly braces. It tells LangChain what variables to expect at runtime and where to place them. inputVariables So now, within our route handler, instead of constructing the entire prompt, we can call and provide our variables. promptTemplate.format const prompt = await promptTemplate.format({
  opponent1: opponent1,
  opponent2: opponent2
}) Separating our prompt template from the route handler’s business logic simplifies the handler, makes the template easier to maintain, and allows us to export and share the template across the codebase if needed. It’s worth mentioning that prompt templates are not the only benefit that LangChain offers. They also have tooling for managing the memory in chat applications, caching, handling timeouts, rate limiting, and more. This is just an introduction, but it’s worth getting more familiar with the capabilities if you plan on going deeper. Identifying the Winner One last thing that I want to do before we finish up today is to highlight the winner based on the response. Unfortunately, it’s hard to know that from a large block of indeterminate text. Now, you may be thinking it would be nice to use a JSON object containing the winner and the text, and you’d be right. Just one problem, in order to parse JSON, we need the entire JSON string, which means we would need to wait until the entire text completes. This kind of defeats the purpose of streaming. This was one of the tricky challenges I found dealing with AI APIs. The solution I came up with was to format the streaming response like so: winner: opponent1 (or opponent2). reason: the reason they won... This way, I could grab the winner programmatically and continue writing the reason to the page as it arrived by skipping the unrelated text. I’d love to hear your thoughts or see what you come up with, but let’s see how this worked. First, we need to modify the prompt. For the AI to know how to respond with the winner, both opponents need a label (“opponent1” and “opponent2”). We’ll add those labels in parentheses when we first mention the opponents. And since we have a more specific requirement on what the returned format needs to be, we should also include that in the template. Here’s what my template looks like now: `You're a professional fighting judge from Liverpool that speaks mostly with Cockney slang. Who would win in a fight between {opponent1} ("opponent1") and {opponent2}("opponent2")? Only tell me who would win and a short reason why.

Format the response like this:
"winner: 'opponent1' or 'opponent2'. reason: the reason they won."` Notice how now I’m giving the AI an example of what the response should look like. This is sometimes referred to as a one-shot prompt. What we had before without any example would be a zero-shot prompt. You can also have a multi-shot where you provide multiple examples. OK, so now we should get back some text that tells us who the winner is and the reasoning. The last step is to modify the way the frontend deals with this response so we separate the winner from the reasoning. Showing just the reason to the user is the easy part. The first bit of the response will always be “ “. So we can store the whole string in state, but skip the first 27 characters and show just the reason to the user. There are certainly some more advanced ways to get just the reasoning, but sometimes I prefer a simple solution. winner: opponent1 (or 2). reason: We can replace this: <p>{state.text}</p> With this: <p>{state.text.slice(27)}</p> Identifying the winner is a little more robust. When the streaming response comes back, it still gets pushed to . After the response is completed, we can pluck the winner from the results. state.text You could slice the string, but I chose to use a : Regular Expression // Previous fetch request logic

const winnerPattern = /winner:\s+(\w+).*/gi
const match = winnerPattern.exec(state.text)
const winner = match?.length ? match[1].toLowerCase() : '' This Regular Expression looks for a string beginning with “winner:”, has an optional white-space character, then captures the next whole word up until a period character. Compared to our template, the captured word should either be “opponent1” or “opponent2”, our winners ;) Once you have the winner, what you do with that information is up to you. I thought it would be cool to store it in state, and apply a fun rainbow background animation and confetti explosion ( ) to the corresponding . party-js <textarea> That’s so fun. I love it! I’ll let you sort that out if you want to recreate it, but here’s some of the code in case you’re interested. JS: if (state.winner) {
  const winnerInput = document.querySelector(`textarea[name=${state.winner}]`)
  if (winnerInput) {
    party.confetti(winnerInput, {
      count: 40,
      size: 2,
      spread: 15
    })
  }
} CSS: .rainbow {
  color: #fff;
  background: linear-gradient(45deg, #cc0000, #c8cc00, #38cc00, #00ccb5, #0015cc, #5f00cc, #c200cc, #cc0000);
  background-size: 1600% 1600%;
  animation: BgSlide 2s linear infinite;
}
@keyframes BgSlide {
  0% { background-position: 0% 50%; }
  100% { background-position: 100% 50%; }
} Review Alright, in the end, we did get into a few code changes, but I don’t want that to overshadow the main focus of this article. Now, we can drastically change the behavior of our app just by tweaking the prompt. Some things we covered were: Providing the AI with some context about its role. Formatting responses. The importance of understanding tokens. Tooling like LangChain Zero-shot, one-shot, and n-shot prompts. I also don’t want to understate how much work can go into getting a prompt just right. This post was a silly example, but it took me a very long time to figure out the right permutations of words and formats to get what I needed. Don’t feel bad if it takes you a while to get used to it as well. I truly believe that becoming a good prompt engineer will serve you well in the future. Even if you’re not building apps, it helps interact with GPTs. But if you’re building apps, the key differentiating factors between the winners and losers will be the secret sauce that goes into the prompts the form factor of using the app. It will need to be intuitive and provide the user with the least friction to get what they want. and In the next post, we’ll start playing around with AI image generation, which comes with its own fun and quirky experience. I hope you stick around, and feel free to reach out at any time Originally published on . austingil.com

Master Innovative Prompt Engineering — AI for Web Devs 

How to Get Faster Responses With HTTP Streaming: AI For Web Devs

Tutorial: Your First API Request to OpenAI - AI for Web Developers

AI is totally changing the game for software developers these days. There are some crazy cool AI tools out there that can seriously level up any programmer's workflow. These aren't just nice extras. They can be total game-changers for modern development work. Any developer looking to step up their game should seriously consider integrating these AI capabilities into their process. AI tools Of all the useful AI tools that exist today, here are six that stand out among the crowd that every developer should absolutely have on their radar. 1. ai-shell 💬 ai-shell is an open-source CLI tool that translates natural language into shell commands. Think of it as having a conversation with your terminal, where you describe what you want, and it provides the relevant command. What it does: Developers unfamiliar with specific shell commands or those who prefer a more intuitive interaction with the terminal. Who is it for: Star ai-shell on Github 🌟 https://github.com/BuilderIO/ai-shell 2. Cursor 💻 Cursor integrates AI directly into the coding process, helping in various tasks. It assists in code changes, bug spotting, debugging, and even offers a chat feature to ask questions about your codebase. What it does: Developers seeking an enhanced coding experience with the power of AI. Who is it for: Or if you want to experience some magic in your IDE, honestly- I just love watching it go. Website: https://cursor.sh 3. v0 🎨 Imagine being able to craft UI components with just a simple text prompt. v0 makes this a reality, allowing developers to swiftly generate a range of UI elements, from chat interfaces to dashboards. What it does: Front-end developers and UI/UX designers looking for a quick design solution. Who is it for: Website: https://v0.dev 4. Pezzo ⚙️ Pezzo is a cloud-native LLMOps platform for building, monitoring, optimizing, and deploying AI features. It offers prompt management, troubleshooting capabilities, and instant prompt change delivery. What it does: Developers who work with language models and seek a unified platform for AI operations with first-class TypeScript Support. Who is it for: Star Pezzo on Github 🌟 https://github.com/pezzolabs/pezzo 5. Tolgee 🌐 Tolgee streamlines the software localization process, making it easier for developers to offer their applications in multiple languages. It offers in-context translating, one-click screenshots, and integrates with various other tools. What it does: Developers working on a product with a global audience and wanting an efficient tool for software translation and localization. Who is it for: Star Tolgee on Github 🌟 https://github.com/tolgee/tolgee-platform 6. Formbricks 📝 Formbricks is an open-source survey toolbox designed for creating in-product micro-surveys. It's a powerful tool to gather insights from users, enhancing the product's user experience. What it does: Product managers and developers keen on understanding their users' needs and enhancing product experience. Who is it for: Star Formbricks on Github 🌟 https://github.com/formbricks/formbricks These tools are just the tip of the iceberg, and as AI continues to advance, I'm sure even more groundbreaking tools will emerge in the near future. So, stay curious and keep exploring! 🚀 Also published . here

6 AI Tools Software Devs Should Have On Their Radar

6টি AI টুল সফ্টওয়্যার দেব তাদের রাডারে থাকা উচিত

6 KI-Tools, die Softwareentwickler auf ihrem Radar haben sollten

6 herramientas de inteligencia artificial que los desarrolladores de software deberían tener en su radar

6 développeurs de logiciels d’outils d’IA devraient avoir sur leur radar

6 एआई उपकरण सॉफ्टवेयर डेवलपर्स को अपने रडार पर रखने चाहिए

ソフトウェア開発者が注目すべき 6 つの AI ツール

소프트웨어 개발자가 염두에 두어야 할 6가지 AI 도구

6 desenvolvedores de software de ferramentas de IA devem ter em seu radar

6 инструментов искусственного интеллекта, которые должны быть в центре внимания разработчиков программного обеспечения

Yazılım Geliştiricilerin Radarında Bulunması Gereken 6 Yapay Zeka Aracı

6 công cụ AI mà nhà phát triển phần mềm nên có trên radar của họ

软件开发人员应该关注的 6 个人工智能工具

https://www.youtube.com/watch?v=gUgRD0sRoCU&embedable=true If you’re anything like me, you’ve noticed the massive boom in technology. It promises to disrupt not just software engineering but every industry. AI THEY’RE COMING FOR US!!! Just kidding ;P I’ve been bettering my understanding of what these tools are and how they work, and I decided to create a tutorial series for web developers to learn how to incorporate AI technology into web apps. In this series, we’ll learn how to integrate ‘s AI services into an application built with , a JavaScript framework focused on the concept of (this will be relevant to understand later). OpenAI Qwik resumability Here’s what the series outline looks like: Intro & Setup Your First AI Prompt Streaming Responses How Does AI Work Prompt Engineering AI-Generated Images Security & Reliability Deploying We’ll get into the specifics of OpenAI and Qwik where it makes sense, but I will mostly focus on general-purpose knowledge, tooling, and implementations that should apply to whatever framework or toolchain you are using. We’ll be working as closely to fundamentals as we can, and I’ll point out which parts are unique to this app. Here’s a little sneak preview. I thought it would be cool to build an app that takes two opponents and uses AI to determine who would win in a hypothetical fight. It provides some explanation and the option to create an AI-generated image. Sometimes, the results come out a little wonky, but that’s what makes it fun. I hope you’re excited to get started because, in this first post, we are mostly going to work on… Boilerplate 😒 Prerequisites Before we start building anything, we have to cover a couple of prerequisites. Qwik is a JavaScript framework, so we will have to have (and NPM) installed. You can download the most recent version, but anything above version v16.8 should work. I’ll be using version 20. Node.js Next, we’ll also need an to have access to their . OpenAI account API At the end of the series, we will deploy our applications to a VPS (Virtual Private Server). The steps we follow should be the same regardless of what provider you choose. I’ll be using Akamai’s cloud computing services (formerly Linode). New users can go to and get $100 in free credits to get started with Akamai. linode.com/austingil Setting Up the Qwik App Assuming we have the prerequisites out of the way, we can open a command line terminal and run the command: . This will run the Qwik CLI that will help us bootstrap our application. npm create qwik@latest It will ask you a series of configuration questions and then generate the project for you. Here’s what my answers looked like: If everything worked, open up the project and start exploring. Inside the project folder, you’ll notice some important files and folders: : contains all application business logic. /src : contains reusable components to build our app with. /src/components : responsible for Qwik’s file-based routing. Each folder represents a route (can be a page or API endpoint). To make a page, drop a file in the route’s folder. /src/routes index.{jsx|tsx} : this file exports the root component responsible for generating the HTML document root. /src/root.tsx Start Development Qwik uses as a bundler, which is convenient because Vite has a built-in development server. It supports running our application locally and updating the browser when files changes. Vite To start the development server, we can open our project in a terminal and execute the command . With the dev server running, you can open the browser and head to and you should see a very basic app. npm run dev http://localhost:5173 Any time we make changes to our app, we should see those changes reflected almost immediately in the browser. Add Styling This project won’t focus too much on styling, so this section is totally optional if you want to do your own thing. To keep things simple, I’ll use . Tailwind The Qwik CLI makes it easy to add the necessary changes by executing the terminal command, . This will prompt you with several available Qwik plugins to choose from. npm run qwik add You can use your arrow keys to move down to the Tailwind plugin and press Enter. Then it will show you the changes it will make to your codebase and ask for confirmation. As long as it looks good, you can hit Enter once again. For my projects, I also like to have a consistent theme, so I keep a file in my to copy and paste styles from. Obviously, if you want your own theme, you can ignore this step, but if you want your project to look as amazing as mine, copy the styles from into the file. You can replace the old styles but leave the Tailwind directives in place. GitHub this file on GitHub /src/global.css Prepare Homepage The last thing we’ll do today to get the project to a good starting point is make some changes to the homepage. This means making changes to . /src/routes/index.tsx By default, this file starts out with some very basic text and an example for modifying the HTML by exporting a variable. The changes I want to make include: <head> head Removing the export. head Removing all text except the . Feel free to add your own page title text. <h1> Adding some Tailwind classes to center the content and make the larger. <h1> Wrapping the content with a tag to make it more semantic. <main> Adding Tailwind classes to the tag to add some padding and center the contents. <main> These are all minor changes that aren’t strictly necessary, but I think they will provide a nice starting point for building out our app in the next post. Here’s what the file looks like after my changes. import { component$ } from "@builder.io/qwik";

export default component$(() => {
  return (
    <main class="max-w-4xl mx-auto p-4">
      <h1 class="text-6xl">Hi 👋</h1>
    </main>
  );
}); And in the browser, it looks like this: Conclusion That’s all we’ll cover today. Again, this post was mostly focused on getting the boilerplate stuff out of the way so that the next post can be dedicated to integrating OpenAI’s API into our project. With that in mind, I encourage you to take a moment to think about some AI app ideas that you might want to build. There will be a lot of flexibility for you to put your own spin on things. I’m excited to see what you come up with, and if you would like to explore the code in more detail, I’ll post it on my GitHub account at . github.com/austingil/versus Thank you so much for reading. If you liked this article and want to support me, the best ways to do so are to , , and . share it sign up for my newsletter follow me on Twitter Also published . here

Introduction and Setup of an AI Project for Web Devs with QwikJS

A benchmark comparison and analysis between Qwik and Next.js 13. TL;DR 🔥 We’ll find out whether the trending framework Qwik is faster than Next.js 🤖 We’ll look at a demo that generates with OpenAI’s DALL-E and its performance benchmark. 🚀 We’ll discuss how Next.js leverages React server component to achieve fast SSR. Page speed matters. Faster website results in . The shows that optimizing leads to: better UX, better SEO, and more profit latest research done by Rekuten 24 Core Web Vitals 53.37% in revenue per visitor. 33.13% in conversion rate. 15.20% in average order value. 9.99% in average time spent. A 35.12% reduction in exit rate. The modern frameworks and frontend libraries address speed and help developers ship better user experiences to the users. We’ll be discussing two of the modern frameworks: and . We’ll see an experiment benchmark and look into how each framework achieves optimal performance. Qwik Next.js Let’s go. How The Experiment Is Set Up qwik v0.16 Next.js v13 React v18 Let’s Peek The Result I built two identical applications with Qwik and Next.js and measured the performances. The demo look like this: You can find . Feel free to take a look at the repo and try it out✨ the demo on GitHub The application lets users enter prompts to , an AI image generator, and displays the generated AI images in the page. It also displays the latest Twitter feed about DALL·E. DALL·E The key features are: Server Side rendering of the application. Client-side fetching the image results with . DALL·E’s REST API Server side fetching the Twitter feed with . Twitter’s REST API Here’s the core Web Vitals by Lighthouse for Qwik: Comparing to Next.js’s Web Vitals: We can observe the following: Qwik’s is 0.5 s faster than Next.js. speed index Qwik’s is 0.3 s faster than Next.js. time to interactive Next.js has a 0 ms , compared to Qwik’s 160 ms. total blocking time Next.js has a slightly higher overall by 5 points. performance score Next.js’s is 0.8 s faster than Qwik. largest contentful paint Let’s take a closer look at how the application in each framework is set up. Qwik Server-Side Rendering The component structure: // qwik/src/routes/index.tsx

export const onGet: RequestHandler<TwitterResponse> = async () => {
  const data = await fetchTweets();
  return data;
}

export default component$(() => {
  const tweets = useEndpoint<TwitterResponse>();
  return (
    <Layout>
      <DallePromptAndResult />
      <Resource
        value={tweets}
        onResolved={(result) => (
          <SSRTwitterCarousel data={result} />
        )}
      />
      <StaticPromptRecommendation />
    </Layout>
  )
}) When the Qwik server receives a page request, it starts the rendering process on the server. The “useEndPoint” function invokes the “onGet” function on the server and fetches the Twitter feed. The “Resource” component will pause the rendering until the Twitter data is resolved or rejected. Once the rendering is completed, the server responds to the client with rendered HTML. We can observe the server-side rendering behavior in the performance profile: The lead time to respond to the client is blocked by the server side data fetching and component rendering. Next.js SSR and Streaming The component structure: // next/app/page.tsx

export default async function Page() {
  const tweets = await fetchTweets();
  return (
    <Layout>
      <DallePromptAndResult />
      <Suspense fallback={<Skeleton />}>
        <SSRTwitterCarousel data={tweets} />
      </Suspense>
      <StaticPromptRecommendation />
    </Layout>
  )
} The “Page” component is a server component. It looks just like a normal component but it supports async/await. When the Next.js server receives a page request, it starts the rendering process and s the rendering result to the client so that the client can progressively render and display the UI to the users. While the server is fetching Twitter feeds, React renders the suspense placeholder to indicate the pending state. Once the data is resolved or rejected, React reveals the suspense boundary and displays the final UI. stream You can see the client starts rendering while the server is streaming. It reduces the lead time for the users to start seeing the page. Resumability v.s. React Server Component Qwik embraces the “Get HTML and render” mental model. is Qwik’s innovation. It allows an application to be rendered as much as possible on the server and resumes the rest of the rendering on the client. Resumability The framework looks like this: When receiving a request, the Qwik server starts the rendering process and generates serialized application state, serialized event handlers, component HTMLs, and component code chunks. The server then responds to the client with the page HTML and the serialized state. On the client, the browser processes the and displays the UI. Qwik deserializes the state after the page HTML is loaded. The state contains all the local states of each component. The lazy-loaded components are able to be dynamically imported independently without knowing the parent’s state because they can refer to the deserialized state for their local states when they are rendering on the client. critical rendering path Qwik also serializes event handlers. In the server-generated HTML, the event handlers are referenced as dynamic JavaScript chunks. When users interact with an interactive element, Qwik uses the reference to dynamically download the chunk from the server and fire the event with the event handler inside the chunk. On the other hand, Next.js has a different approach to server-side rendering. Next.js and React server component promotes the “Render while fetching” mental model. . is a special type of component that can only be rendered on the server. Combining with Suspense and Streaming, the framework is able to progressively render interactive UI while avoiding long data requests from blocking the page rendering. Next.js 13 introduces React server component as an experimental feature Server component The framework looks like this: When Next.js server receives a request, it delegates React to handle rendering. On the server, React renders the component tree into a UI description in JSON instead of native HTML. The UI description describes the entire component tree. For the client components, React describes them as components for the client to handle with serialized props. For the server components, React renders them to native HTMLs and places them in the UI description. On the client, React receives and reconciles the UI description in the response stream to progressively render the UI. When React sees a suspense boundary, it renders the suspense placeholder until the pending data is resolved and reveals the suspense boundary. Because React receives a UI description instead of native HTML on the client, it needs to construct the component tree, render the UI, and attach event handlers on the client. It’s known as hydration. Final Thoughts Qwik’s concept of is very innovative. The client is able to render the page with just HTML and minimal JavaScript. It reduces the amount of JavaScript the client needs to download for the initial load and leverages dynamic import to download event handlers and components on the fly. We can clearly observe the benefit from the benchmark and performance profile. serializing states and event handlers However, the combination of React server component, suspense, and streaming has a profound impact on user experience. Users are able to see and interact with the content of the page without waiting for server-side data fetching to complete. The result of the experiment is not conclusive to me. Both frameworks performed well in the benchmarks. The differences in First Content Paint, Largest Content Paint, and Cumulative Layout Shift are likely a result of different Twitter images. References — OpenAI API Reference: Create image — web.dev Case Study — MDN Critical rendering path — OpenAI DALL·E 2 — Next.js Data Fetching Fundamentals — Andrew Clark First class support for promises — web.dev How Rakuten 24’s investment in Core Web Vitals increased revenue per visitor by 53.37% and conversion rate by 33.13% — Builder.io Hydration is Pure Overhead — Chrome Developers Lighthouse performance scoring — MDN Lazy loading — Vercel Next.js — OpenAI Node.js library — MDN Populating the page: how browsers work — Builder.io Progressively — Builder.io qwik — Daw-Chih Liou qwik-vs-next — React Community RFC: React Server Components — Builder.io Resumable vs. Hydration — Builder.io Reactivity — Next.js Server and Client Components — MDN The “why” of web performance — Builder.io Think Qwik — Chrome Developers Time to Interfactive — Chrome Developers Total Blocking Time — Twitter Developer Aplatform Twitter API v2 — web.dev Web Vitals — Chrome Developers Speed Index — Chrome Developers Largest Contentful Paint Want to Connect? This article was originally posted on__ __. Daw-Chih’s website Also Published Here

Qwik vs Next.js: Speed Comparison

10 Open-source Headless CMS to Supercharge Your Development in 2022

Beyond Text Embeddings: Addressing the Gaps in RAG Applications for Structured Data Queries

Акрамя тэкставых убудоўванняў: ухіленне прабелаў у праграмах RAG для запытаў структураваных даных

Über Texteinbettungen hinaus: Behebung der Lücken in RAG-Anwendungen für strukturierte Datenabfragen

Más allá de las incrustaciones de texto: cómo abordar las deficiencias en las aplicaciones RAG para consultas de datos estructurados

Izvan ugrađivanja teksta: rješavanje nedostataka u RAG aplikacijama za upite strukturiranih podataka

Melampaui Penyematan Teks: Mengatasi Kesenjangan dalam Aplikasi RAG untuk Kueri Data Terstruktur

テキスト埋め込みを超えて: 構造化データクエリの RAG アプリケーションのギャップに対処する

Verder dan tekst-embeddings: de hiaten in RAG-toepassingen voor gestructureerde dataquery's aanpakken

Texto Embeddings nisqamanta aswan karun: RAG Yanapakuykunapi Estructurado Willay Tapuykunapaq Ch'usaq kaqkunata allichay

Përtej përfshirjeve të tekstit: Adresimi i boshllëqeve në aplikacionet RAG për pyetjet e strukturuara të të dhënave

Ғайр аз ҷойгиркунии матн: Бартараф кардани камбудиҳо дар барномаҳои RAG барои дархостҳои сохтории додаҳо

ኪኖ ጽሑፍ ምትእትታው፡ ኣብ ኣፕሊኬሽናት ራግ ንዝተዋደደ ሕቶታት ዳታ ንዘሎ ክፍተታት ምፍታሕ

Vượt ra ngoài nhúng văn bản: Giải quyết các khoảng trống trong ứng dụng RAG cho truy vấn dữ liệu có cấu trúc

Stories, News & Mentions about BUILDERIO

Builderio’s Stories on HackerNoon