Como a qualidade dos aplicativos móveis pode ser melhorada com IA
7 de maio de 2024
O passado de Cilium aponta para seu futuro
7 de maio de 2024
Ultimamente, tenho trabalhado muito no PostgreSQL para desenvolvedores de JavaScript e meu entendimento geral é que os desenvolvedores de JavaScript farão absolutamente qualquer coisa para evitar escrever código que não seja JavaScript. Eles colocarão CSS em JavaScript, HTML em Jsx e agora SQL em JavaScript!
É disso que estou falando.
Veja o código no Gist.
Esta sintaxe não possui nome oficial e, no caso do Supabase, é uma abstração sobre o PostgREST. No entanto, gostaria de propor que chamemos essa sintaxe SamQL-Jackson.
Há vários motivos pelos quais os desenvolvedores de JavaScript escolheriam essa sintaxe em vez do “SQL bruto” e, pelas minhas observações, eles se enquadram em três categorias:
- Não tenho tempo para aprender SQL.
- Eu não quero aprender SQL.
- SQL não é seguro para tipos.
1. “Não tenho tempo para aprender SQL.”
Isso é subjetivo e não pode ser discutido. Se você está muito ocupado para aprender coisas novas, eu entendo perfeitamente.
2. “Não quero aprender SQL.”
O ponto 2 também é um tanto subjetivo – aprender algo em que você tem pouco interesse geralmente é mais difícil. No entanto, minha única ressalva até esse ponto seria que o SQL é amplamente utilizado, então pode ser uma boa flecha para se ter em sua aljava.
3. “SQL não é seguro para tipos.”
O ponto 3 é um pouco difícil de resolver, então aqui está uma explicação de Jiri Cincura: Digite segurança dos comandos SQL.
“Os comandos SQL são de tipo seguro, mas apenas no servidor. Escrito no código do seu aplicativo, ele ainda é seguro para o tipo, mas não do ponto de vista da segurança do tipo do seu código e das regras do compilador”
O que isso significa é que, se as consultas SQL não forem digitadas, não haverá visualização de tipo disponível no editor de código. Por exemplo:
Não ter definições de tipo disponíveis pode dificultar o trabalho com respostas do banco de dados.
Além de inspecionar manualmente o esquema da tabela ou usar um console.log(), não há uma maneira fácil de ver quais valores estão contidos em uma resposta ou tabela. Há também a mudança mental de entender como, mentalmente, converter o esquema Postgres; por exemplo VARCHAR(255) para um tipo TypeScript, por exemplo, string. Você talvez pudesse usar um typeof na tua console.log()mas ainda não é uma ótima solução.
Resumindo, há absolutamente uma necessidade de fornecer definições de tipo ao usar SQL em uma base de código “JavaScript”, mas criar esses tipos manualmente pode ser demorado e provavelmente mudará com o tempo — exigindo mais intervenção manual e mais tempo gasto.
É compreensível, então, por que muitos desenvolvedores de JavaScript escolheriam usar SamQL-Jackson em vez de “SQL bruto”, já que muitos desses fornecedores de bancos de dados JavaScript possuem segurança de tipo integrada em seus clientes e SDKs. Mas nesses cenários, você ainda precisará aprender a sintaxe específica do fornecedor, porque, infelizmente, cada fornecedor lida com essa sintaxe de maneira um pouco diferente.
Aqui está um exemplo de uma consulta SQL simples que seleciona os valores first_name, country e email de uma tabela chamada users.
Veja o código no Gist.
E aqui está a mesma consulta para Supabase e Xata.
Dezessete
Veja o código no Gist.
Xata
Veja o código no Gist.
Você notará que ambas as consultas são diferentes uma da outra, o que pode ser bom se você estiver planejando usar apenas o Supabase. Mas se você precisar trocar de provedor de banco de dados, terá que aprender uma sintaxe totalmente nova — sem mencionar a reescrita de um monte de consultas.
Naturalmente, se você escrever SQL, as consultas funcionarão com todas as soluções PostgreSQL e, embora eu não possa dizer com certeza, esses motivos desafiam um pouco os pontos 1 e 2 acima.
É importante notar que tanto o Supabase quanto o Xata também podem ser consultados usando SQL “comum”, para sua informação!
De qualquer forma, se você decidir seguir o caminho do “SQL bruto” e precisar de tipos, aqui estão algumas opções para você.
Geração automática de tipo
Experimentei duas soluções: kysely-codegen e pg-to-ts. Ambos funcionaram muito bem para mim, então veja como usá-los.
Como usar o kysely-codegen
kysely-codegen gera definições de tipo Kysely de seu banco de dados. É isso.
Instalação Kysely
Execute o seguinte para instalar o pacote principal do Kysely. Verifique também as instruções de instalação, pois no meu caso também precisei instalar o pg.
Veja o código no Gist.
Você também precisará executar o seguinte para instalar o pacote codegen.
Veja o código no Gist.
Script Kysely package.json
Por conveniência, adicionei um script ao meu package.json. Usando o -out-file sinalizar este script criará um arquivo chamado kysely-db.d.ts e a raiz do meu projeto.
Veja o código no Gist.
Kysely .env
Kysely requer que você tenha uma variável de ambiente chamada DATABASE_URL na tua .env arquivo.
Veja o código no Gist.
Gerar Kysely
Agora você pode executar o script a seguir e deverá ver um novo arquivo .d.ts na raiz do seu projeto, contendo todos os tipos de todas as tabelas e colunas do seu banco de dados.
Veja o código no Gist.
Aqui está um trecho da aparência do meu banco de dados de teste. Ele contém apenas uma tabela nomeada Usuários.
Veja o código no Gist.
Consulta digitada por Kysely
E aqui está como usei os tipos gerados em minha consulta PostgreSQL, mas essas definições de tipo também podem ser usadas como parte da interface props de um componente.
Veja o código no Gist.
Como usar pg-to-ts
pg-to-ts gera tipos TypeScript que correspondem ao esquema do seu banco de dados Postgres. Ele funciona consultando o esquema de metadados do Postgres (pg_catalog) e gerando tipos TypeScript equivalentes, bem como alguns valores JavaScript que podem ser úteis para gerar consultas em tempo de execução.
Instalação pg para ts
Execute o seguinte para instalar o pacote pg-to-ts principal.
Veja o código no Gist.
Script pacote.json pg-to-ts
Por conveniência, adicionei um script ao meu package.json. Usando o -c flag você pode referenciar o DATABASE_URL, que você pode repassar ao executar o script em seu terminal. Este script criará um arquivo chamado pg-to-ts-db.d.ts e a raiz do meu projeto.
Veja o código no Gist.
geração de pg para ts
Agora você pode executar o seguinte script fornecendo seu DATABASE_URL antes do comando npm run, e você deverá ver um novo arquivo .d.ts na raiz do seu projeto contendo todos os tipos de todas as tabelas e colunas do seu banco de dados.
Veja o código no Gist.
Aqui está um trecho da aparência do meu banco de dados de teste. Ele contém apenas uma tabela nomeada Usuários.
Veja o código no Gist.
consulta digitada pg-to-ts
E aqui está como usei os tipos gerados em minha consulta PostgreSQL, mas essas definições de tipo também podem ser usadas como parte da interface props de um componente.
Veja o código no Gist.
Finalizado
Então aí está, SQL pode ser digitado (no sentido JavaScript da palavra). É automatizado, portanto não é um grande problema quando ocorrem alterações de esquema. Mas, mais do que isso, espero que agora você esteja um pouco menos relutante em trabalhar com “SQL bruto”. Afinal, é a linguagem dos bancos de dados.
A postagem Gerar tipos automaticamente para seu banco de dados PostgreSQL apareceu pela primeira vez em The New Stack.
