That works well for a while, until you get users that pose multiple questions in one single message. Hey! Do you happen to know what the weather is like in SF? Btw, when did WW2 end and why do I start crying when I peel an onion?

Three completely unrelated questions. It’s unlikely that you would find good matches of knowledge if you simply turn this entire message into an embeddings and do a vector search. Unless you extract all the different queries separately and get knowledge for each query.

Here’s one code example of doing just that. It uses Typescript, Vercel AI SDK and Claude 3.7 Sonnet as LLM.

const getPrompt = (
  targetLanguage: string,
  chatHistory: CoreMessage[]
) => `Generate concise search queries for an embeddings database using cosine similarity based on this chat history:

<chat_history>
${stringifyChatHistory(chatHistory)}
</chat_history>

Guidelines:
- Focus on most recent intent/topics
- Ignore previous irrelevant topics
- For "what is X" questions, NEVER include potential answers

Multiple queries (max 3) ONLY for COMPLETELY UNRELATED topics:
- One query for single topics with multiple aspects
- Combine related aspects (e.g., "studying tips", "study techniques") into ONE query

For each query:
- Keep very brief queries intact
- Summarize longer queries to core intent
- Focus on key terms representing the topic
- Write in ${targetLanguage}
- NEVER include potential answers

Examples:
"User: What's the weather? Assistant: It's sunny. User: Great. How about movies?" → "popular movies current releases"
"User: Tell me about quantum computing and banana bread?" → Two queries: "quantum computing basics" and "banana bread recipe ingredients" 
"User: What is the capital of Sweden?" → "huvudstad Sverige" (NOT "Stockholm huvudstad Sverige")
"User: How do I start a business with registration, marketing, and funding?" → "how to start a business registration marketing funding steps"`;

const QuerySchema = z.object({
  queries: z
    .array(z.string())
    .min(1)
    .max(3)
    .describe(
      "The search queries to be used doing the embeddings search. Return between 1-3 queries for each different topic. Only one query per topic."
    ),
});

const result = await generateObject({
    model,
    prompt: getPrompt(targetLanguage, [ role: "user", content: "Hey! Do you happen to know what the weather is like in SF? Btw, when did WW2 end and why do I start crying when I peel an onion?"]),
    schema: QuerySchema,
  });

// Example result
//[
//    'current weather in San Francisco',
//    'when did World War 2 end',
//    'why onions make people cry'
//]

// Get search results for each of the queries
const knowledge = await Promise.all(result.object.queries.map(findKnowledge))

Some key remarks here:

• We use a targetLanguage for the queries. The language would be the same as we write the content in. There are embeddings models that handle multiple languages, but I feel I get a better result when I keep the original content and the search queries in the same language.

• If you’re not careful the LLM will likely produce multiple queries on the same topic, which is counter productive to what we want to achieve.

The Takeaway

By implementing intelligent query extraction, your chatbot transforms from a one-dimensional responder into a conversation partner that understands context and handles complexity. This approach not only improves the accuracy of responses but also creates a more natural user experience - even when your users jump between asking about the weather in San Francisco, World War II facts, and the science of onion-induced tears in a single breath.

Having a large knowledge base is of no use, if you don’t find the relevant parts for each query.

Today I came across such a problem. This is similar to what I came across. getAllItems is a function that should fetch 100 items at a time, until there are no more items to fetch.

const getAllItems = async () => {
  let maxItems = 100;
  let page = 1;
  let allItems = [];

  while (maxItems === 100) {
    const items = await getItemsPage(page, maxItems);
    if (items.length < 100) {
      maxItems = items.length;
    }
    allItems.push(items);
    page++;
  }

  return allItems;
};

While I've probably written a ton of code like this in my day, but there are a couple of things that bothers me today.

1. We mutate state. page, maxItems and allItems are all being mutated in the function. State mutation for me adds cognitive load and leads to less predictable code.

2. The intent of maxItems is not to control the while loop, but number of items we should fetch for each page. Here it's used for both.

3. All though it's almost always subjective, I don't find the code very readable.

Apart from fixing a bug in the function, I decided to refactor the function using recursion. The updated solution looked something like this:

const getAllItems = async (allItems = [], page = 1) => {
  const items = await getItemsPage(page, 100);
  if (items.length < 100) {
    return [...allItems, ...items];
  }

  return getAllItems([...allItems, ...items], page + 1);
};

In my opinion, this addresses all concerns of the first implementation. No mutation of state and more concise code.

There are times when I'm reluctant to reach for recursion. For example when I know I have a very large dataset that I need to traverse. I don't want to run into stack overflow issues.

When the function is long and complex or when performance is really important, are also examples where I might reach for another approach.

Recursion is vastly different to the "normal" iterations that most are used to. A function that calls itself? Sounds like witchcraft to me! However I'm here to tell you that you should invest time in getting familiar with the technique. It can make your code more robust and more readable. Just remember that with great power, comes great responsibility...

Consider the following class.

class OrderService {
  constructor(
    productDao,
    orderDao,
    paymentService,
    emailService
  ) {
    this.productDao = productDao
    this.orderDao = orderDao
    this.paymentService = paymentService
    this.emailService = emailService
  }

  async placeOrder(order, customerInfo) {
    const products =
      await this.productDao.getByIds(
        order.productIds
      )
    const totalPrice = products.reduce(
      (acc, product) => acc + product.price,
      0
    )

    const receipt =
      await this.paymentService.chargeCreditCard(
        totalPrice,
        customerInfo.creditCard
      )

    const savedOrder = await this.orderDao.save(
      order,
      receipt
    )

    await this.emailService.sendEmail(
      customerInfo.email,
      `Your order ${savedOrder.id} has been placed`
    )
    return savedOrder
  }

  // More methods for handling orders in different
  // ways, like deleting, updating etc...
}

This is totally fine and very common to see code like this. However, by using a concept called higher-order functions, you can achieve basically the same thing but without classes. Let's see what that might look like in its simplest form.

function createOrderService(
  productDao,
  orderDao,
  paymentService,
  emailService
) {
  async function placeOrder(order, customerInfo) {
    // Same logic as before, but without the `this` keyword
  }

  return { placeOrder }
}

To some, this might be less readable. But remember. New concepts also take some getting used to. I used to write Java for a living, but today I find Object Oriented Programming less readable. Also, if you, like me, have been burnt by the this keyword. In this paradigm, you don't use it anymore.

Let's take this one step further, to make the placeOrder function more testable.

const sumTotalPrice = (products) =>
  products.reduce(
    (acc, curr) => acc + curr.price,
    0
  )

const createPlaceOrder =
  (deps) => async (order, customerInfo) => {
    const {
      getProductsById,
      chargeCreditCard,
      saveOrder,
      sendEmail,
    } = deps

    const products = await getProductsById(
      order.productIds
    )

    const receipt = await chargeCreditCard(
      sumTotalPrice(products),
      customerInfo.creditCard
    )

    const savedOrder = await saveOrder(
      order,
      receipt
    )

    await sendEmail(
      customerInfo.email,
      `Your order ${order.id} has been placed`
    )
    return savedOrder
  }

We did a couple of things here:

• We extracted the price calculation into its own function. The function is pure, making it very easy to test.

• We separated dependencies from the business logic using a higher-order function. This makes it easy to see where they're coming from and it's also very easy to mock & test.

• We explicitly pass exactly what dependencies the function needs. We could have passed in productDao, paymentService etc, but here we only pass in exactly which functions we will use.

The code examples in this article are very brief to give an idea of what it might look like. If you're interested in a bit more elaborate example I added a gist for you to look at.

In summary, while JavaScript classes have their place, exploring the use of higher-order functions and pure functions opens up a world of simplicity, testability, and clarity in your code. As with any programming paradigm, the key is to find the right balance that works for your specific context. Whether you choose classes, functional programming, or a mix of both, always aim for code that is readable, testable, and adaptable to change.

It may sound like a trivial topic. Everybody can write a function, but to me, this is what separates good code from bad code. By bad code, I mean code that it's hard to read, hard to test, hard to change and hard to maintain. Writing a good function can also be very hard to do, so it takes a lot of practice.

Take what you need, leave what you don't

// 😱
async function getUserPosts(user) { 
    return service.getPosts(user.id)
}
// 😍
async function getUserPosts(userId) { 
    return service.getPosts(userId)
}

Don't pass in more than what the function needs. In this example, we pass in the user object, even though we're only using the id. In a test, you will have an easier time just passing in the id, and not having to pass in an entire user to convince Typescript your code is correct. Also, the naming will become more explicit.

Pass in everything the function needs

// 😱
async function getUserPosts(userId) { 
    return service.getPosts(userId)
}
// 🙂
async function getUserPosts(service, userId) { 
    return service.getPosts(userId)
}
// 🥹😍
function createGetUserPosts(getPosts) {
    return async function(userId: string) {
        return getPosts(userId)
    }
}
const getUserPosts = createGetUserPosts(service.getPosts)

In the first example, where did the service come from? Maybe we're in a class and the service is passed to the constructor way up in the file. Maybe it's one of five dependencies. You're going to enjoy testing a lot more if you write it in one of the latter examples. The third example is using a concept of higher-order functions for achieving dependency injection. This in itself deserves its own article, so be on the lookout for that.

Avoid having too many parameters

// 😱
async function getUserPosts(userId, category, date, archived) { 
    return service.getPosts(userId, category, date, archived)
}
// 🙏
function getUserPosts(getPosts) {
    return async function(searchParams) {
        return getPosts(searchParams)
    }
}

I'm not saying I like having many parameters to begin with, but if I have to, I try wrapping them into an object. If my function has four or more parameters, I reach for an object instead. It has a nice side effect of readability when you have optional or boolean parameters.

Avoid long functions

If you try to keep your functions focused with limited responsibility, this will almost be automatic. My personal preference is having the function fit on the screen. This usually means around 20-30 lines.

Be explicit with error handling

// 😱
function validateAge(age: number): { msg: string } {
    if (age < 0) throw new Error('Completely unexpected!')
    if (age > 70) throw new Error('Ok boomer...')
    if (age > 30) throw new Error('Still too old!')
    return { msg: "It's all good!" }
}
// 🙏
function validateAge(age: number): ConceivableError | Success {
  if (age < 0) throw new Error('Completely unexpected!')
  if (age > 70) return 'boomer'
  if (age > 30) return 'still-too-old'
  return { msg: "It's all good!" }
}

Silly example, and one of the principles I haven't yet fully landed in. But take a look at the first function definition. It's hard to understand what can go wrong inside the function. In the second example, we've at least defined some of the more common error states. You can play around a lot with this type of error handling and go for something like the Either type, which you usually find in more functional languages.

Please share if you have any good principles of your own that you think can be helpful!