DEV Community: Strift

Vector storage is coming to Meilisearch to empower search through AI

Strift — Tue, 11 Jul 2023 11:05:36 +0000

Vector search enables efficient retrieval of objects sharing similar characteristics. This AI-powered search technique uses embedding vectors. These vectors are mathematical representations of objects generated by machine learning models (like LLMs). In the upcoming 1.3 release, Meilisearch will support storing and searching vectors.

The release candidate for Meilisearch v1.3 is out—try it now!

Powering the Future of Search

Vector search might be the dawn of a new era for search. Its use cases are numerous. In ecommerce, it enables offering recommendations for similar products. It also allows building multi-modal search, like image or audio search. Building upon conversational AI technologies enables the creation of Q&A applications. Combining vector search with user-provided information like geolocation and search history can power even more contextual search experiences.

Vector search is also the foundation for semantic search, which aims to understand the query’s meaning. Conversely, traditional lexical search only matches keywords. With semantic search, a warm clothes query could give results like gloves, coat, and more results related to winter clothing.

Vector search unlocks a world of new capabilities for search. Take a look at what some users have already implemented:

similar videos recommendations on a site listing Ruby conferences
a documentation chatbot proof of concept using GPT3.5 and LangChain

Getting started with Meilisearch vector store

Starting with v1.3, you can use Meilisearch as a vector store. Meilisearch allows you to store vector embeddings alongside your documents conveniently. You will need to create the vector embeddings using your third-party tool of choice (Hugging Face, OpenAI). As we published the first v1.3 release candidate, you can try out vector search today.

First, pull the release candidate by using this Docker image:

docker run -p 7700:7700 -v $(pwd)/meili_data:/meili_data getmeili/meilisearch:v1.3.0-rc.0

Then, enable the vector store experimental feature:

curl \
  -X PATCH 'http://localhost:7700/experimental-features/' \
  -H 'Content-Type: application/json'  \
  --data-binary '{
    "vectorStore": true
  }'

💡 This guide uses curl to make HTTP requests to communicate with Meilisearch. When v1.3 will officially be released, you will be able to use the corresponding SDK methods instead.

Meilisearch now accepts a _vector field in your documents. Use it to store the vector embeddings corresponding to your document in this field.

curl -X POST -H 'content-type: application/json' \
     'localhost:7700/indexes/songs/documents' \
     --data-binary '[
         { "id": 0, "_vectors": [0, 0.8, -0.2], "title": "Across The Universe" },
         { "id": 1, "_vectors": [1, -0.2, 0], "title": "All Things Must Pass" },
         { "id": 2, "_vectors": [[0.5, 3, 1], [-0.2, 4, 6]], "title": "And Your Bird Can Sing" }
     ]'

After storing your vectorized documents in Meilisearch, you can query them using the search or multi-search route. To do this, you need to compute the vector of your query (using a third-party tool) and send it in the vector field.

curl -X POST -H 'content-type: application/json' \
   'localhost:7700/indexes/songs/search' \
   --data-binary '{ "vector": [0, 1, 2] }'

When using vector search, returned documents include a semanticScore field:

{
  "hits": [
    { "id": 0, "_vectors": [0, 0.8, -0.2], "title": "Across The Universe", "_semanticScore": 0.6754 },
    { "id": 1, "_vectors": [1, -0.2, 0], "title": "All Things Must Pass", "_semanticScore": 0.7546 },
    { "id": 2, "_vectors": [[0.5, 3, 1], [-0.2, 4, 6]], "title": "And Your Bird Can Sing", "_semanticScore": 0.78 }
  ],
  "query": "",
  "vector": [0, 1, 2],
  "processingTimeMs": 0,
  "limit": 20,
  "offset": 0,
  "estimatedTotalHits": 2
}

📢 This API is experimental. You can help us improve it by sharing your feedback in this Github discussion.

A First Step Toward Semantic Search

Vector search is our first step towards semantic search. But our long-term goal is to provide hybrid search—combining the benefits of full-text and semantic search to provide the most relevant search experience. Clément Renault, founder and CTO of Meilisearch, shared his thoughts on Github about exploring semantic search — read for a founder’s perspective. We can’t wait to share more with you!

Drop your email below to learn more about our progress with AI-powered search. We’ll keep you posted on all updates regarding vector search & semantic search.

We’re excited to walk our first steps toward semantic search. We can’t wait to hear your thoughts on integrating Meilisearch as a vector store. You can give your feedback in this Github discussion.

You can stay in the loop by subscribing to our newsletter. To learn more about Meilisearch's future and help shape it, look at our roadmap and participate in our Product Discussions.

For anything else, join our developers community on Discord.

I’ll see you there.

Bun.js - Fresh JavaScript runtime out of the oven 🧑‍🍳

Strift — Thu, 21 Jul 2022 11:24:14 +0000

When JS devs got bored of rebuilding libraries, they started rebuilding the runtime.

An all-in-one JavaScript runtime

A few weeks ago, Jared Sumner released Bun.js—an all-in-one runtime for JavaScript. Bun includes a native bundler, TypeScript transpiler, task runner, and npm client.

And it is fast. ⚡

Since Bun is an all-in-one tool, performance is not limited to apps. Developer tooling also benefit from it:

4.5x faster starts than node
30x faster script runs than npm
20x faster installs than yarn

On top of all, Bun has full compatibility with all the NPM ecosystem. So there's little to no migration needed. ✅

Should we use Bun?

By all means, try it out! Bun.js looks extremely promising. Its sheer performance could be driving change across the entire JS ecosystem; the same way Vite changed the face of front-end dev in a couple months.

Personally, I'd love to see more tools aim at running on the edge.

But Bun still has to come to grips with:

Project scoping—A monumental scope is not a bad thing per se, but it makes the challenge greater
Sustainable maintaining—Building a team around the creator is vital to ensuring continuous development and support
The Zig question—Bun is built with the Zig language which is quite unproven in the industry

Dig further by reading Bun.js documentation.

Like the content? Follow for more JavaScript & front-end stuff!

Cheers ✌

State of Vue 2022: Amsterdam recap

Strift — Tue, 21 Jun 2022 08:22:45 +0000

Since v3.0 became the default this February, Vue 3 adoption has grown steadily. NPM downloads have known a 4x increase to reach an average of 800k/week.

Since then, the Vue 3 team has been at work on fixing issues with v3 and improving the SFC playground. Meanwhile, the ecosystem is finally catching up. Let's recap what Evan You discussed during the State of the Vuenion talk in Amsterdam two weeks ago.

State of the ecosystem
- Nuxt 3
- Vuetify 3
- VitePress 1
- Volar
What's coming for Vue?
- Back-porting features to Vue 2.7
- Next minor version: Vue 3.3
- A note on Vite 3
- Experimental: new compilation strategies
Bonus: The Vue Report

State of the ecosystem

Nuxt 3

One of the most anticipated release is probably that of Nuxt 3. Currently in Release Candidate stage, the framework is nearing stability. It seems safe enough to start migrating your development environment. Since the conference, NuxtLabs released RC4—check out the release notes.

The Nuxt team has announced that Nuxt v3 should release this summer.

Related: A few weeks ago, the team released v2 of @nuxt/content—it supports Nuxt 3!

Vuetify 3

The Material Design framework is currently in beta. The third beta release has been available for a fortnight. Read the release notes.

VitePress 1

The Vue team has long been dog-fooding VitePress with the new Vue.js docs. To prepare for the v1.0 release, core team member Kia worked on a providing a higher-level API for end users. VitePress is now the recommended solution for Vue 3-powered Static Site Generation. Read the docs.

However, discussion remains on the name and the coexistence with VuePress. Simply put, the question is whether VitePress should replace VuePress 3 or not.

Volar

Johnson Chu, developer of the Volar VS Code extension joined the Vue.js core team. There are brighter days ahead for IDE tooling as the maintainer of the extension is now sponsored by Vue.

This is a welcome news. With the integration of TypeScript, setup syntax, compile-time macros, and Nuxt 3 auto-imports, tooling is now paramount.

What's coming for Vue?

Back-porting features to Vue 2.7

Vue 2.7 aims at back-porting the built-in composition API, the <script setup> syntax, and the improvements to TypeScript support to Vue 2.x. As of writing, the composition API has been fully ported, and the team is working on porting <script setup>.

Regarding the latter, the team aims at making vue/compiler-sfc adhere to the same interface as its Vue 3 counterpart. The goal is to make it compatible with vue-loader 16+ and @vitejs/plugin-vue so as to unify loaders across Vue 2 and Vue 3.

Vue 2.7 will be the last minor release of Vue 2.x. It will have 18 months of LTS starting from the 2.7 stable release. Companies can notify interest for extended supported via this link.

Next minor version: Vue 3.3

In v3.3, we should expect a stabilized API for <Suspense>. The Vue team is collaborating with the Nuxt team that is heavily testing the feature in Nuxt 3. Stability should also come for the reactivity transforms API.

Finally, the teams keeps on improving server-side rendering with lazy/conditional hydration and better warnings about SSR mismatch.

A note on Vite 3

The next major of Vite is in development. Although the updates can be considered minor, many will introduce breaking changes. Still, those will be invisible for most end users. Only tools that use Vite directly will need to update, eg. Nuxt, Vitest, etc.

The biggest internal update is moving Vite itself to full ESM and thus dropping support for Node.js 12. The server-side rendering build will now default to ESM output. With these changes, Vite aims to forward the ecosystem migration to ES modules. Also, Vite will now use esbuild for both dev and prod bundling, to reduce friction when deploying.

Experimental: new compilation strategies

⚠️ This is experimental and may never land.

The team has started experimenting with a new compilation strategy inspired by SolidJS. The idea is moving to a no-virtual DOM approach. This will significantly improve memory usage on top of reducing the runtime size.

Although the adoption strategies aren’t clear — that is, if these changes ever release — this would be a great step into transitioning Vue into a more compiler-oriented framework.

Bonus: The Vue Report

The fine folks at Monterail have produced an insightful report on the state of Vue.js. It's packed with community experts opinions and features experts articles and interview.

Read it here: Vue Report

A that’s a wrap!

Follow me here or @StriftCodes on Twitter for more Vue content. You can watch the original talk on YouTube and get the slides here.

Cheers,

Displaying TwicPics Images When Working Offline With Nuxt.js

Strift — Tue, 14 Jun 2022 11:28:01 +0000

TwicPics is an image transformation and optimization SaaS. It works in the cloud, and front-end developers interact with the API via the JavaScript library. But when working in local, you might not want (or be able) to connect to the Internet.

This happened to me, so I wrote a wrapper component around TwicPics that allows me to fallback to local images when necessary. Obviously, this means skipping any image optimization or transformation. But it provides a quick toggle for switching it off and on, which can be useful when working locally.

Adding a on/off switch for local images

First, we’ll add a configuration entry to our Nuxt configuration to be able to easily toggle TwicPics.

// nuxt.config.js

export default {
    publicRuntimeConfig: {
        enableOptimization: process.env.NODE_ENV !== 'development'
    }
}

In this example, we configure the app to default to local images when we’re in development mode. But we could choose any conditions we like or use a specific environment variable.

Wrapping our image in a component

Now that we have a configuration toggle, let’s create an component that makes use of it. We’ll go with the straightforward approach: when enableOptimization is false, we’ll simply display the image; otherwise, we’ll process it with TwicPics.

<!-- components/BaseImage.vue -->
<template>
    <img 
        v-if="$config.enableOptimization"
        :src="src"
    />
    <img
        v-else
        :data-twic-src="`image:${src}`"
    />
</template>

<script>
export default {
    props: {
        src: { type: String, required: true }
        // In reality, you'd probably have more props to handle transformations, etc.
    }
}
</script>

And that’s it!

Your BaseImage component will load your local image whenever enableOptimization is false. You don’t have to change your code to keep using TwicPics in production.

Obviously, that's a simplified example. In reality, you'd probably be wrapping a <TwicImage/> component instead of base <img>. But the overall logic is the same. Read more about @twicpics/components in the documentation.

To go further:

Nuxt.js docs
TwicPics docs
Or just ask a questions in the comments!

I’m a web developer working with Nuxt.js & serverless. I’m writing about the stuff I learn. Follow @StriftCodes on Twitter for more.

Cheers,

Testing Firebase Functions with the emulators suite

Strift — Mon, 05 Jul 2021 09:44:58 +0000

Integration tests can be hard to write, especially when using external services. We’ve all heard the “don’t test what you don’t own”. When running serverless, you pretty much own nothing. So how can you test your Firebase functions? Enters the Firebase emulators suite.

The use case: a function that lists users

Let’s take the example of a simple function. This one is a simple function that returns a list of users' UIDs. Internally, the function uses Firebase Auth to list the users.

// api/listUsers.js

const firebase = require('../services/firebase')

const PAGE_SIZE = 1000

module.exports = async function (data, context) {
 let allUsers = []

 let { users, pageToken } = await firebase.auth().listUsers(PAGE_SIZE)
 do {
   allUsers = allUsers.concat(users.map(user => user.uid))
   if (pageToken) {
     ({ users, pageToken } = await firebase.auth().listUsers(PAGE_SIZE, pageToken))
   }
 } while (pageToken)

 return { users: allUsers }
}

Firebase Auth module’s own listUsers function returns a paginated response. So we use the pageToken to check if there are more pages and concatenate that in one single response.

Setting up tests with Jest

We’ve got our function, now let’s set up our testing tools. For this example, I will use Jest.

yarn add --dev jest # Or `npm install --save-dev jest`

If you’re running on VS Code, you will want Intellisense to pick-up Jest global imports. Including Jest types as a development dependency will do the trick.

yarn add --dev @types/jest # or `npm install --save-dev @types/jest`

Writing the tests

Now that we’re all set, let’s actually write tests, shall we? First, let’s scaffold our test file.

// test/api/listUsers.test.js

const admin = require('firebase-admin')

process.env.FIREBASE_AUTH_EMULATOR_HOST = 'localhost:9099'

const test = require('firebase-functions-test')()

// Mock config values here

const functions = require('../../index.js') // import functions *after* initializing Firebase

describe('listUsers', () => {
 let wrapped

 beforeAll(() => {
   wrapped = test.wrap(functions.listUsers)
 })

 afterAll(() => {
   test.cleanup()
 })

 // tests will go here

})

At line 3, we initialize firebase-functions-test without parameters. Because of this, all calls to Firebase will be using the project default’s — most likely your production. We obviously don’t want this. That’s why we initialized it after the following line.

process.env.FIREBASE_AUTH_EMULATOR_HOST = 'localhost:9099'

When initialized, Firebase will recognize the environment variable and use the emulator for Auth instead of the production service. We can now safely write our test.

it('returns an empty array when there are no users', async () => {
   const { users } = await wrapped()
   expect(users).toEqual([])
 })

At this point, running the tests should fail because Firebase cannot connect to it’s Auth service. You should get an error like the following.

Error while making request: connect ECONNREFUSED 127.0.0.1:9099. Error code: ECONNREFUSED

If you don’t get this error, make sure you’ve updated the environment variable and initialized firebase-functions-test without configuration. Your app might be trying to connect to production.

So, how do we get this working? Well, we use the Firebase emulators suite. Like the name suggests, it allows you to emulate Firebase services locally. It’s perfect for local development, but also for testing. Install it by running the following command.

yarn add --dev firebase-tools # or `npm install -save-dev firebase-tools`

We will use the emulator emulators:exec command to launch the Auth service emulator and run our tests. For convenience, I included it in my package.json.

// package.json 

"scripts": {
   "test:run": "jest ./test/",
   // If you're using Yarn
   "test": "firebase emulators:exec --only auth 'yarn test:run'",
   // If you're using NPM
   "test": "firebase emulators:exec --only auth 'npm run test:run'"
}

Ta-da! Your tests should now run without any connection issues. This example only uses the Auth service. You can use the same technique to emulate other Firebase services. Just update the --only parameter to include the other services you need.

Until next time,

Read more

On my blog where I write about code, esports, and writing
On my Twitter where I casually post on similar topics