Executando verificação de segurança...
2
guscsales
3 min de leitura ·

[PITCH] KV Layer - O "Better Auth" para key/value e feature flags

Se você conhece o better-auth, sabe como autenticação pode ser simples:

export const auth = betterAuth({
    database: pool,
    emailAndPassword: { enabled: true },
    plugins: [twoFactor(), organization()]
})

Tudo bem que é um pouco mais do que apenas instanciar essa função aí, mas no fim das contas é simples mesmo.

Ou até mesmo um outro grande exemplo recente: o Resend. Já existiam AWS SES, SendGrid, Postmark... mas o Resend conseguiu simplificar algo que era chato de fazer:

import { Resend } from 'resend';
import { EmailTemplate } from './email-template';

const resend = new Resend('re_123456789');

await resend.emails.send({
  from: '[email protected]',
  to: '[email protected]',
  subject: 'Hello World',
  react: EmailTemplate({ firstName: 'John' }),
});

DX incrível + React Email + integrações simples conseguiram gerar uma adoção massiva, mesmo num mercado com gigantes estabelecidos.

Acontece que, eu percebi que ninguém fez um jeito mais simples e funcional ainda para key/values. Então vem o problema...

O Problema

Todo projeto eventualmente precisa de:

  • Feature flags pra ativar/desativar funcionalidades
  • Configurações específicas por usuário ou organização, ou até mesmo geral

Mas a realidade é que a maioria resolve isso com "gambiarras", é tipo "cria uma flag em qualquer lugar e ta tudo certo", alguns meses passam e aquilo provavelmente é um mini frankenstein.

Alguns casos que já vi:

  • Hardcoded no código (precisa deploy pra mudar)
  • Variáveis de ambiente (mesma dor)
  • Tabela genérica settings, ou data no banco sem tipo nem validação (o que não é uma má ideia, mas normalmente não tem uma atenção real nela)
  • JSON no Redis sem interface
  • Ou paga por soluções enterprise, mas que no fim ainda da muito trabalho pra lidar.

A Proposta: KV Layer

Uma lib open source, self-hosted, que traz a mesma simplicidade do better-auth, só que para feature flags e configurações.

Como funciona

Princípio fundamental: Os dados ficam no SEU banco de dados (inicialmente Postgres).

Alguns casos de uso:

Setup inicial:

// server/kv.ts
import { createKVLayer } from '@kv-layer/core'
import { drizzleAdapter } from '@kv-layer/adapter-drizzle'

export const kv = createKVLayer({
    adapter: drizzleAdapter(db)
})

No backend:

// Criar/atualizar flags
await kv.set('new-checkout', true)
await kv.set('stripe-key', 'sk_test_...', { scope: 'org:acme', encrypt: true })

// Ler flags
const enabled = await kv.get('new-checkout')
const config = await kv.get('stripe-key', { scope: 'org:acme' })

No frontend (React):

import { useFlag, useConfig } from '@kv-layer/react'

function CheckoutButton() {
    const { data: enabled } = useFlag('new-checkout')
    
    if (!enabled) return <LegacyCheckout />
    return <NewCheckout />
}

function StripeProvider() {
    const { data: apiKey } = useConfig('stripe-key', { 
        scope: `org:${orgId}` 
    })
    
    return <StripeContext apiKey={apiKey}>...</StripeContext>
}

Estado Atual

O que pensei pra uma v0:

  • Agnóstico de framework (a lib core funciona em qualquer lugar)
  • Adapters iniciais: pg, drizzle, prisma
  • Biblioteca para React
  • Type-safe por padrão
  • Self-hosted (seus dados, seu controle)

Preciso do Feedback de Vocês

Estou tentando criar o costume de pesquisar antes de criar algo (é, eu não fazia isso e alguns projetos já foram pro saco [RIP]).

Então esse projeto ainda está em progresso, no momento estou estudando bastante como o better-auth funciona para tentar replicar algo que gere uma Dev Experience similar, e quero construir algo que a comunidade realmente vá usar, então eu adoraria ler alguns feedbacks, se fizer sentido.

Perguntas:

  1. Você usaria algo assim? Por quê (ou por que não)?
  2. Que features você considera essenciais?
  3. A DX proposta faz sentido pra você?
  4. Já usa alguma solução parecida? O que funciona/não funciona?

Se tiver interesse em acompanhar ou contribuir:

  • GitHub: [em breve]
  • Vou atualizar aqui conforme o projeto evolui

Valeu pela atenção!

PS: Sim, o nome é inspirado em "camada" mesmo - uma layer universal pra qualquer key/value que seu app precise.

Valeu!

Carregando publicação patrocinada...