Por que precisamos de um ORM JavaScript padrão para bancos de dados SQL

A necessidade de padronização está ao nosso redor, mas, ocasionalmente, o ecossistema JavaScript — ou melhor, as ferramentas e serviços construídos usando JS — tende a se desviar do curso, o que pode causar perturbações no ecossistema.

Neste artigo discutirei clientes JavaScript e SDKs para bancos de dados SQL onde encontrei problemas. Farei a pergunta: os provedores de banco de dados SaaS deveriam considerar abandonar o suporte de seus próprios clientes em favor de apoiar o Drizzle ORM? Como expliquei em um post anterior, Drizzle ORM é uma biblioteca moderna de mapeamento objeto-relacional (ORM) para desenvolvedores JavaScript. Ele foi projetado para fornecer uma maneira intuitiva e segura de interagir com bancos de dados SQL, mas, mais do que isso, também está resolvendo o que acredito ser um grande problema: não existem dois clientes iguais.

Clientes JavaScript e SDKs

A solução geralmente aceita para fornecer segurança de tipo para consultas de banco de dados em projetos JavaScript é não escrever SQL bruto. Em vez disso, somos incentivados a usar um cliente ou SDK JavaScript com segurança de tipo.

A princípio, isso pode parecer resolver o problema de segurança de tipo – o que realmente acontece. No entanto, isso não ajuda com aquele incômodo problema de “não há dois clientes iguais”.

Ter vários clientes e SDKs no ecossistema com sua própria sintaxe exclusiva faz com que os desenvolvedores gastem tempo aprendendo métodos específicos para o provedor escolhido. Se você não é um “hacker independente” ou um “solopreneur”, é bem provável que trabalhe com vários provedores de banco de dados SaaS a qualquer momento – o que só agrava o problema.

Além disso, ao usar o cliente ou SDK de um provedor, muitos desenvolvedores de JavaScript nunca aprenderão SQL. Acho que isso não é apenas uma pena (é uma linguagem bonita), mas também é uma visão limitada. O provedor de banco de dados de sua escolha pode não estar disponível nos próximos anos, mas o SQL estará. Isso sugere uma pergunta: por que os provedores de banco de dados têm seus próprios clientes ou SDKs?

Fiz exatamente essa pergunta a Brayden Wilmoth, da Outerbase. Outerbase, entre outras coisas, permite criar, editar, visualizar e explorar os dados em seu banco de dados — tudo sem precisar escrever SQL. Wilmoth explicou que “ter fornecedores evitando a criação de suas próprias bibliotecas pode ser complicado, pois eles desejam tornar suas propostas de valor exclusivas facilmente acessíveis a seus usuários (e) não precisam depender de uma biblioteca de código aberto, sendo o guardião absoluto delas. .”

E esse é um ponto justo: os provedores de banco de dados SaaS querem avançar em seu próprio ritmo e fazer as coisas à sua maneira. Mas muitos desses clientes e SDKs, na minha opinião, não seguem fielmente os objetivos do SQL e estão potencialmente desviando os desenvolvedores do aprendizado de habilidades fundamentais.

Os objetivos do SQL

Já mencionei esses objetivos em um artigo recente, mas se você perdeu esse, aqui estão eles novamente. Conforme descrito por Don Chamberlin (um dos principais designers do SQL), o design da linguagem foi guiado por quatro objetivos principais:

1. Queríamos usar o termo tabelas em vez de relações…
2. Queríamos basear o idioma em palavras comuns do inglês, como select.
3. O idioma não deve ter símbolos especiais e deve ser fácil de digitar no teclado.
4. Queríamos que tivesse algo que chamássemos de propriedade walk up and read. Ou seja, em casos simples, um usuário sem treinamento especial deve ser capaz de entender uma consulta apenas lendo-a.

A abordagem ORM da garoa

Idealmente, então, o que é necessário é uma forma padronizada para desenvolvedores de JavaScript que precisam de segurança de tipo ao escrever sintaxe baseada em método, que não esteja vinculada a um provedor, mas siga fielmente os objetivos do SQL.

Wilmoth explica: “Provavelmente a decisão mais importante que uma biblioteca ORM pode tomar hoje é ter um relacionamento o mais próximo possível com a escrita (ou leitura semelhante) de SQL. Drizzle é uma daquelas bibliotecas que certamente acerta.”

Depois de passar algum tempo investigando o Drizzle ORM, concordo que ele é muito parecido com o SQL – a tal ponto que nem acho que realmente aprendi o Drizzle ORM. Acabei de escrever SQL usando sintaxe baseada em método JavaScript. E eu fui para as corridas.

No entanto, a preocupação inicial permanece: os fornecedores de bases de dados podem estar sujeitos às decisões tomadas por um mantenedor de ORM, mas felizmente, a Drizzle ORM já pensou nisso (dica) e está a trabalhar em estreita colaboração com os fornecedores de bases de dados para lhes permitir implementar os seus requisitos específicos. enquanto deixa os métodos de consulta semelhantes ao SQL intactos.

“Por exemplo”, explicou Andrew Sherman da equipe Drizzle ORM, “@xata enviou um PR para Drizzle e adicionou o driver xata. Nós revisamos e ajudamos um pouco nos testes. A lógica específica do driver é feita de forma que você possa replicar. Adicionar um driver leva algumas horas e todo o resto deve ser feito pelo Drizzle.”

Drizzle ORM é de código aberto e colaborativo

Ao acolher os provedores de banco de dados e permitir que eles contribuam para o Drizzle ORM, nós, como desenvolvedores, podemos interagir com bancos de dados relacionais de uma forma padronizada e segura, e os provedores de banco de dados são capazes de implementar mudanças que atendam aos seus requisitos específicos.

Andrew continua explicando que: “Sim, as pastas ‘*-core’ contêm lógica específica do dialeto, que explica como o banco de dados funciona e qual sintaxe e recursos um banco de dados específico possui. Todo o resto consiste em drivers, que explicam como o Drizzle deve se comunicar com um banco de dados, provedor de banco de dados ou serviço específico.”

Se você está curioso para saber quais provedores já estão adotando a “abordagem Drizzle ORM”, dê uma olhada no que estou chamando de “a pasta dos sonhos” no GitHub.

Os provedores que você vê aqui já estão trabalhando com a equipe Drizzle ORM. Alguns estão até dando um passo além e patrocinando o projeto, o que é uma ótima notícia.

No entanto, há um fornecedor que quero mencionar particularmente, porque, tal como o Drizzle ORM, demonstra uma consciência do seu impacto no ecossistema e presta homenagem à tecnologia subjacente.

Destacando-se em um espaço lotado

Há muito tempo sou fã de Neon, que, para mim, se destaca na multidão. Eles nunca tiveram seu próprio cliente ou SDK. Em vez disso, a proposta de valor é simples: PostgreSQL para desenvolvedores JavaScript. Eles sempre incentivaram o uso do PostgreSQL “comum”, mas abordaram o enigma cliente/SDK de uma maneira um pouco diferente.

Em vez de criar sua própria maneira nova e sofisticada de consultar um banco de dados, eles a mantiveram à moda antiga com SQL – mas o que eles têm é um driver sem servidor.

Driver sem servidor do Neon

O driver serverless é o que permite aos desenvolvedores JavaScript consultar um banco de dados PostgreSQL em vários ambientes e também em vários tempos de execução: Node, Deno e Bun. O driver sem servidor é o que permite ao Neon fornecer sua abordagem exclusiva em bancos de dados sem servidor. Ao usar o driver sem servidor, você não estará mais consultando um banco de dados PostgreSQL por TCP/IP; você está consultando o proxy Neon por HTTP. Isso, por sua vez, se conecta a uma instância do PostgreSQL (implantada na mesma região do proxy), que permite aos desenvolvedores usar o PostgreSQL em ambientes de borda, bem como em ambientes de nós “comuns”.

Naturalmente, Neon também pode ser usado com Drizzle ORM. Isso demonstra como um provedor pode avançar em seu próprio ritmo e ainda oferecer aos usuários recursos exclusivos — tudo isso sem interferir nos objetivos fundamentais da própria linguagem.

Infelizmente, nem todo provedor de banco de dados SaaS opera dessa forma.

Um padrão está surgindo

Portanto, parece que os fornecedores de bases de dados SaaS já estão a convergir para um padrão comum, o que só pode ser uma coisa boa.

Na minha opinião, os provedores de banco de dados SaaS não deveriam ter seus próprios clientes ou SDKs e não deveriam levar os desenvolvedores ao caminho errado. Eu sou um defensor da educação para desenvolvedores. Se você trabalha com bancos de dados, você deve (no mínimo) ter um conhecimento básico de SQL. Depois de fazer isso, acho que você adotará o Drizzle ORM como um pato na água.

Mesmo que você não concorde com minha opinião, dê uma estrela ao repositório no GitHub – e se você tiver um pouco de dinheiro de VC para gastar, Drizzle ORM é um projeto que merece.

A postagem Por que precisamos de um ORM JavaScript padrão para bancos de dados SQL apareceu pela primeira vez em The New Stack.