DEV Community: KOLOG B Josias Yannick

9,000+ Downloads in 2 Weeks: I Just Built and Published

KOLOG B Josias Yannick — Sun, 11 Jan 2026 00:28:22 +0000

Two weeks ago, I published Embex to PyPI and npm.

Today: 9,000+ downloads (7K Python, 2K Node.js).

I made one LinkedIn post after publishing. That's it. And it didn't even got likes or comments.

Here's what I built.

What is Embex?

A universal ORM for vector databases. One API that works across 7 different databases.

The problem:

Every vector database has a completely different API.

Pinecone:

index.upsert(vectors=[(id, values, metadata)])
results = index.query(vector=query, top_k=5)

Qdrant:

client.upsert(collection_name=name, points=points)
results = client.search(collection_name=name, query_vector=query, limit=5)

Weaviate:

client.data_object.create(data_object, class_name)
results = client.query.get(class_name).with_near_vector(query).do()

Switching from Pinecone to Qdrant means rewriting your entire data layer.

With Embex:

# Works with ANY provider
client = await EmbexClient.new_async(provider="lancedb", url="./data")
await client.insert("products", vectors)
results = await client.search("products", vector=query, top_k=5)

# Switch to Qdrant? Change ONE line:
client = await EmbexClient.new_async(provider="qdrant", url="http://localhost:6333")

Same code. Zero vendor lock-in.

Why I Built It

I needed to test different vector databases for a project. Writing separate implementations for each one seemed wasteful.

So I built one API that works with all of them.

The Tech Stack

Core:

Rust (performance-critical operations)
PyO3 (Python bindings)
Napi-rs (Node.js bindings)
SIMD instructions (vector math acceleration)

Why Rust?

Vector operations are CPU-intensive. Rust + SIMD is ~4x faster than pure Python/JavaScript for normalization, similarity calculations, and filtering.

Supported Databases:

LanceDB (embedded, file-based)
Qdrant (managed/self-hosted)
Pinecone (managed)
Chroma (embedded/server)
PgVector (PostgreSQL extension)
Milvus (self-hosted/cloud)
Weaviate (managed/self-hosted)

The Launch

Published to PyPI and npm. Made one LinkedIn post. Went back to building.

Downloads started coming in. 9,000+ in two weeks.

I don't know where the traffic came from. PyPI/npm search, probably. Maybe GitHub. I haven't looked at analytics closely.

What I Noticed

23% of downloads are Node.js. I expected mostly Python. Apparently people are building with JavaScript too.

Multi-language support matters. Supporting both Python and Node.js from day one expanded reach.

Example Usage

Python:

from embex import EmbexClient, Vector
from sentence_transformers import SentenceTransformer

client = await EmbexClient.new_async("lancedb", "./data")
model = SentenceTransformer('all-MiniLM-L6-v2')

await client.create_collection("docs", dimension=384)

vectors = [Vector(
    id="1",
    vector=model.encode("your text").tolist(),
    metadata={"text": "your text"}
)]
await client.insert("docs", vectors)

results = await client.search(
    "docs",
    vector=model.encode("query").tolist(),
    top_k=5
)

Node.js:

const { EmbexClient } = require('@bridgerust/embex');
const { pipeline } = require('@xenova/transformers');

const embedder = await pipeline('feature-extraction', 'Xenova/all-MiniLM-L6-v2');
const client = await EmbexClient.new({ provider: 'qdrant', url: 'http://localhost:6333' });

await client.insert('docs', documents.map(doc => ({
  id: doc.id,
  vector: embedder(doc.content),
  metadata: { title: doc.title }
})));

const results = await client.search(
  'docs',
  embedder('search query'),
  { top_k: 10 }
);

What's Next

Short term:

Hybrid search (vector + keyword)
Performance optimizations
More examples

Medium term:

Elasticsearch/OpenSearch support
Redis vector support
Migration utilities

Try It

Python:

pip install embex lancedb sentence-transformers

Node.js:

npm install @bridgerust/embex lancedb @xenova/transformers

Quick test:

import asyncio
from embex import EmbexClient

async def main():
    client = await EmbexClient.new_async('lancedb', './data')
    await client.create_collection('test', dimension=384)
    print('✅ Works')

asyncio.run(main())

Links:

GitHub: https://github.com/bridgerust/bridgerust
Docs: https://bridgerust.dev/embex/introduction

That's it. I built something I needed. Published it. People downloaded it.

Read the full story on my blog: kologojosias.com/embex-9k-downloads

Still building.

Stop Writing Glue Code: One Rust Core for Python & Node.js 🦀

KOLOG B Josias Yannick — Thu, 08 Jan 2026 14:10:52 +0000

Note: This post was originally published on My Blog.

As developers, we often face a difficult choice when building high-performance libraries:

Write in a high-level language (JS/Python) for ease of use but sacrifice raw performance.
Write in a low-level language (Rust/C++) and deal with the nightmare of maintaining bindings for multiple languages.

If you've ever chosen the latter, you know the struggle. You end up juggling pyo3 for Python and napi-rs for Node.js. You have snippets of "glue code" scattered everywhere, inconsistent APIs across languages, and a CI pipeline that breaks if you look at it wrong.

I built BridgeRust to change that.

What is BridgeRust?

BridgeRust is a unified framework that lets you write your library once in Rust and automatically deploy native, high-performance bindings to both Python and Node.js (with more languages coming).

It's not just a binding generator; it's a complete toolkit that handles the boring stuff:

Project Scaffold: Set up a multi-language project in seconds.
Unified Macro System: One #[export] macro for all languages.
Type Conversions: Automatic mapping of Vec, Option, Result, and more.
Building & Publishing: Integrated CLI to build wheels and npm packages.

The "Write Once" Magic 🪄

Here is how it actually looks to expose Rust code to the world using BridgeRust.

1. Initialize

cargo install bridge
bridge init my-awesome-lib
cd my-awesome-lib

2. Write Rust

In src/lib.rs, you simply tag your functions and structs with #[export]. You don't need to know the internals of the Python C-API or V8.

use bridgerust::export;

#[export]
pub fn greet(name: String) -> String {
    format!("Hello, {}! This is logic from Rust.", name)
}

#[export]
pub struct Point {
    pub x: f64,
    pub y: f64,
}

#[export]
pub fn fast_math(points: Vec) -> f64 {
    // Heavy computation here...
    points.iter().map(|p| p.x + p.y).sum()
}

3. Build

bridge build --all

That's it. BridgeRust generates:

A Python wheel (pip install ...)
A Node.js native addon (npm install ...)

Consuming the Library

The best part is that the generated bindings feel native in every language. We handle idiomatic naming conventions automatically (snake_case for Python, camelCase for JS).

Python:

import my_awesome_lib

print(my_awesome_lib.greet("Pythoneer"))

p1 = my_awesome_lib.Point(1.0, 2.0)
result = my_awesome_lib.fast_math([p1])

Node.js:

const lib = require("my-awesome-lib");

console.log(lib.greet("JavaScripter"));

const p1 = new lib.Point(1.0, 2.0);
// Notice fast_math became fastMath automatically!
const result = lib.fastMath([p1]);

Real-World Example: Embex

This isn't just a toy project. We built Embex, a universal vector database client, using BridgeRust. It connects to Pinecone, Qdrant, LanceDB, and more.

By using BridgeRust, we maintained a single codebase for the core logic (connection pooling, retry strategies, SIMD operations) while offering native packages for both Python (pip install embex) and Node.js (npm install @bridgerust/embex).

Why I Built This

Zero Boilerplate: I was tired of writing manual PyModule or napi_register_module definitions.
Performance: I wanted zero-cost abstractions where possible.
Consistency: I needed to ensure Python and JS users got exactly the same features and bug fixes at the same time.

Try it out!

BridgeRust is open source and I'd love to hear your feedback on the API design.

Check out the repo: github.com/bridgerust/bridgerust
Read the docs: bridgerust.dev

Stop writing glue code. Start building bridges. 🦀🌉

Have you tried maintaining cross-language bindings before? Let me know in the comments what your biggest pain point was!

Introducing Embex: The Universal Vector Database ORM

KOLOG B Josias Yannick — Sat, 03 Jan 2026 11:05:45 +0000

Note: This post was originally published on My Blog.

TL;DR: Embex is a universal ORM for vector databases that lets you switch between Qdrant, Pinecone, Chroma, LanceDB, Milvus, Weaviate, and PgVector without changing a single line of code. Built on a Rust core with SIMD acceleration, it's 4x faster than pure Python/JS implementations.

The Problem I Was Trying to Solve

If you've worked with vector databases, you know the pain:

Every database has a different API - Qdrant uses one format, Pinecone another, Chroma yet another
Vendor lock-in - Switching providers means rewriting your entire codebase
Performance trade-offs - Most clients are pure Python/JS, leaving performance on the table
Setup complexity - Getting started requires Docker, API keys, cloud accounts...

I wanted a solution that:

✅ Works with any vector database
✅ Lets you start with zero setup
✅ Delivers production-grade performance
✅ Scales from prototype to production

So I built Embex.

What Makes Embex Different?

1. Universal API - Switch Providers Instantly

# Development: LanceDB (embedded, zero setup)
client = await EmbexClient.new_async("lancedb://./data")

# Production: Switch to Qdrant (just change the config!)
client = await EmbexClient.new_async("qdrant://https://your-cluster.com", api_key="...")

# Everything else stays the same!
await collection.insert(points)
results = await collection.search(vector, top_k=10)

Same code. Different backend. Zero rewrites.

Note: Embex uses async initialization (new_async()) to properly handle both local (LanceDB) and cloud providers (Qdrant, Pinecone) with the same API. This ensures consistent behavior across all providers.

2. Rust Core with SIMD Acceleration

Embex isn't a wrapper—it's built on a shared Rust core with SIMD intrinsics:

4x faster vector operations (dot product, cosine similarity)
Zero-copy data passing between languages
< 5% overhead vs native clients

# This runs on optimized Rust code with AVX2/NEON
results = await collection.search(query_vector, top_k=10)

3. Start Simple, Scale Later

Day 1: Learning

# LanceDB - embedded, no Docker, no API keys
client = await EmbexClient.new_async("lancedb://./data")

Week 2: Staging

# Qdrant - managed cloud, connection pooling
client = await EmbexClient.new_async("qdrant://https://...", api_key="...")

Month 1: Scale

# Milvus - billion-scale vectors, distributed
client = await EmbexClient.new_async("milvus://https://...")

Quick Start: Semantic Search in 5 Minutes

import asyncio
from embex import EmbexClient, Point
from sentence_transformers import SentenceTransformer

async def main():
    # 1. Setup (LanceDB - zero setup!)
    # Use new_async() for proper initialization across all providers
    client = await EmbexClient.new_async("lancedb://./data")
    model = SentenceTransformer('all-MiniLM-L6-v2')

    # 2. Create collection
    await client.create_collection("products", dimension=384, distance="cosine")

    # 3. Insert documents
    docs = [
        "Apple iPhone 15 Pro Max",
        "Samsung Galaxy S24 Ultra",
        "Fresh Organic Bananas"
    ]

    points = [
        Point(
            id=str(i),
            vector=model.encode(doc).tolist(),
            metadata={"text": doc}
        )
        for i, doc in enumerate(docs)
    ]
    await client.insert("products", points)

    # 4. Search
    query = "smartphone"
    query_vector = model.encode(query).tolist()
    results = await client.search(collection_name="products", vector=query_vector, top_k=2)

    for result in results.results:
        print(f"{result.metadata['text']} (score: {result.score:.3f})")

asyncio.run(main())

That's it! No Docker, no API keys, no cloud setup. Just pip install embex lancedb sentence-transformers and you're running.

Performance Benchmarks

Based on our benchmarks:

SIMD Acceleration: 3.6x - 4.0x faster dot product/cosine similarity
Minimal Overhead: < 5% vs native clients
Package Size: 8-15MB (optimized from 65MB+)

Production Features

Embex comes with everything you need for production:

✅ Connection Pooling: High-concurrency connection management
✅ Migrations: Git-like version control for schema
✅ Observability: OpenTelemetry metrics and tracing
✅ Type Safety: Full TypeScript definitions and Python type hints

Supported Providers

LanceDB - Embedded, zero setup
Qdrant - Production & local
Pinecone - Serverless
Chroma - AI-native
PgVector - PostgreSQL extension
Milvus - Billion-scale
Weaviate - Modular

Try It Now

# Python
pip install embex lancedb sentence-transformers

# Node.js
npm install @bridgerust/embex lancedb @xenova/transformers

Documentation: bridgerust.dev/embex

GitHub: github.com/bridgerust/bridgerust

What's Next?

I'm actively developing Embex and would love your feedback:

What features are missing?
What use cases should I prioritize?
Performance issues you've encountered?
Provider support requests?

Questions? Feedback? Issues? Drop a comment below or open an issue on GitHub!

rust #python #nodejs #vectordatabase #ai #machinelearning #embeddings #semanticsearch

The Next.js Rendering Cheat Sheet: Mastering SSR, RSC & Edge in 2026

KOLOG B Josias Yannick — Sun, 07 Dec 2025 12:56:21 +0000

Why Rendering Strategy Matters More Than Ever in Next.js

Building for the web feels like running a restaurant during busy hours. Some customers want their food instantly, some want it freshly cooked. Some need a custom order and some just want to grab something pre-made and go. Your kitchen can also pre-make most dishes, while cooking fresh items only when the customer orders.

That's exactly what's happening in web traffic today.

Users expect pages to load immediately, adapt to their location, remember who they are, and update in real time. And if your app doesn't deliver on that for even a second, they bounce.

Meanwhile, companies expect engineers to keep costs low and performance high at the same time.

This is why when working with Next.js, knowing how to choose the right rendering strategy is a superpower. SSR, SSG, ISR, RSC, and Edge are each like different kitchen setups. Choose the wrong one and your app will be really slow, choose the right one and everything will feel effortless.

What Rendering Actually Means in Next.js

Rendering in Next.js is about when and where your React components turn into HTML that the browser can display.

Server Components (RSC): They run on the server, send fully rendered HTML, reduce client-side JavaScript, and improve performance.

Client Components: Run in the browser for interactivity—forms, animations, or any dynamic UI that can't be pre-rendered.

Server Actions: Let you perform server-side logic (database writes/reads) directly from components without needing to create separate API routes.

// app/actions.ts
'use server'
export async function addComment(postId: string, text: string) {
  await db.comments.create({ postId, text })
}

Data Fetching Evolution (2023 → 2026): Next.js moved from simple getStaticProps/getServerSideProps to RSC + server actions + Edge functions, giving developers flexible, faster, and globally distributed ways to fetch data.

In short: rendering now decides speed, interactivity, and where your app does all the heavy lifting.

The Rendering Spectrum in Next.js

Next.js offers different ways to render pages. Each one comes with trade-offs between speed, freshness, and interactivity.

SSR (Server-Side Rendering)

Pages are generated on every request. Perfect when you need always-fresh content, dynamic or user-specific content.

SSG (Static Site Generation)

Pages are built at deploy time. Perfect for blogs, docs, or landing pages.

ISR (Incremental Static Regeneration)

Static pages that regenerate on demand, giving a balance between performance and freshness.

PPR (Partial Pre-Rendering)

Allows a static page shell to render immediately while dynamic holes are filled with server-rendered content. A mix of SSR and SSG.

import { Suspense } from 'react'

export default function Page() {
  return (
    <div>
      <Header />  {/* Loads instantly (Static Shell) */}

      <Suspense fallback={<LoadingSkeleton />}>
        <PostList /> {/* Fetches its own data & streams in */}
      </Suspense>
    </div>
  )
}

Edge Rendering

Pages are rendered close to the user, reducing latency and enabling geo-aware personalization.

Client-side Rendering (The Fallback Nobody Talks About)

In Next.js, the content is pre-rendered on the server, then hydrated client-side (in the browser). We use it usually for interactive widgets or fallback content. This is often overlooked but it's useful for dynamic UI. Hydration adds interactivity without blocking initial page render.

'use client' 
function InteractiveButton() {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(count + 1)}>Click {count}</button>
}

When to Use SSR

The actual use cases: Use SSR for dynamic, user-specific, or frequently changing content. Think dashboards, authenticated pages, live feeds, and personalized recommendations.

When SSR becomes a bottleneck: Pages with heavy computation or high global traffic can slow down if rendered on every request. Server costs and latency can also rise.

Common SSR mistakes to avoid:

Overusing SSR for content that could be static
Neglecting caching strategies
Shipping too much client-side JavaScript alongside SSR pages

Key takeaway: SSR is very powerful, but should be reserved for pages that truly need real-time freshness.

When to Use SSG

Ideal scenarios: Pages with content that rarely changes—blogs, marketing pages, documentation, landing pages.

Trade-offs: Lightning-fast performance, but content can become outdated until the next build.

Managing static output at scale: Use incremental builds, caching, and CDN to handle large sites efficiently.

When to Use ISR (Incremental Static Regeneration)

Perfect use cases: Pages that are mostly static but need occasional updates—product catalogs, news listings, or other frequently accessed but infrequently updated content.

Cache invalidation rules: Configure revalidate times or revalidateTag to refresh the content automatically.

Avoiding stale page pitfalls: Only use ISR for pages where slightly outdated data is acceptable.

// app/blog/[slug]/page.tsx

export const revalidate = 60 // regenerate page every 60 seconds

export default async function Page() {
  const posts = await fetch('https://...', { next: { revalidate: 60 } })
  // ...
}

When to Use Edge Rendering

Geo-aware personalization: Serve content based on user location—regional pricing, local promotions, or language-specific pages.

Low-latency workloads: Ideal for worldwide users needing near-instant responses.

What should not run at the edge: Heavy computations, large database writes, or sensitive business logic that must stay centralized.

Real examples of Edge Functions + RSC: Combining edge functions with RSC for personalized landing pages, recommendations, and A/B testing.

export const runtime = 'edge'
export default async function handler(req: Request) {
  return new Response(JSON.stringify({ message: 'Hello from the Edge!' }))
}

The Core Rendering Model

What should be a Server Component: Heavy data fetching, SEO-critical content, and static or semi-static parts of the UI.

What must remain a Client Component: Interactive UI, forms, animations, and any logic that must run on the browser.

Performance traps: Overloading Server Components with unnecessary computation or client-side dependencies.

RSC + caching rules: Leverage caching headers and global CDNs to reduce redundant server work and improve performance.

How to Choose the Right Strategy Every Time

You choose the right strategy by balancing freshness versus speed, accounting for personalization and geo needs, weighing interactivity against SEO, and strategically using RSC, Edge, and Server Actions within a consistent decision framework.

Remember: there's no one-size-fits-all solution. The best rendering strategy depends on your specific use case, and often, the best approach is combining multiple strategies within a single application.