A API Web SQL Database, que permite armazenar dados de maneira estruturada no computador do usuário (internamente com base no mecanismo de banco de dados SQLite), foi lançada em abril de 2009 e abandonada em novembro de 2010. Embora tenha sido implementado no WebKit (que funciona com o Safari) e permaneceu ativo no mecanismo Blink (que aciona o Chrome), a Gecko (que usa o Firefox) nunca implementou esse recurso e o WebKit o removeu em 2019.
O World Wide Web Consortium (W3C)
recomenda
que as pessoas que precisam de bancos de dados da Web adotem tecnologias da
API Web Storage,
como
localStorage
e
sessionStorage
ou
IndexedDB.
Essas tecnologias mostram os pontos fortes delas quando se trata de armazenamentos de chave-valor e
dados estruturados, mas também têm pontos fracos, como a falta de uma
linguagem de consulta forte. As pessoas querem SQL na Web por uma razão.
Etapas de descontinuação e remoção do Web SQL
- [ Concluído.] O Web SQL foi descontinuado e removido para contextos de terceiros no Chromium 97 ( 4 de janeiro de 2022).
- [ Concluído.] O acesso à Web SQL em contextos não seguros foi descontinuado no Chromium 105 ( 4 de janeiro de 2022), quando uma mensagem de aviso foi exibida no painel "Problemas" do Chrome DevTools.
- [ Concluído.] O acesso à Web SQL em contextos não seguros não está mais disponível desde o Chromium 110 ( 4 de janeiro de 2022). Uma política empresarial para continuar usando o recurso está disponível desde o Chromium 110 (4 de janeiro de 2022) até o Chromium 123 (4 de janeiro de 2022).
- [ Concluído.] O acesso à Web SQL em todos os contextos foi descontinuado no Chromium 115 ( 4 de janeiro de 2022), e uma mensagem de aviso é exibida no painel "Problemas" do Chrome DevTools.
- [ Estamos aqui.] Um teste de descontinuação para continuar usando o Web SQL está disponível do Chromium 117 ( 4 de janeiro de 2022) até o Chromium 123 (4 de janeiro de 2022). Para saber mais sobre os testes de descontinuação, consulte Introdução aos testes de origem.
O que fazer depois disso
Conforme mencionado na introdução, tecnologias da
API Web Storage,
como
localStorage
e
sessionStorage
ou o padrão
IndexedDB
são boas alternativas em muitos casos, mas não em todos os casos.
Justificativa para deixar o armazenamento para desenvolvedores Web
Com o advento do Wasm, as soluções SQL ou NoSQL podem chegar à Web. Um exemplo é DuckDB-Wasm, outro é absurd-sql. Com base nessas criações, acreditamos que a comunidade de desenvolvedores pode iterar e criar novas soluções de armazenamento de maneira mais rápida e melhor do que os fornecedores de navegador.
Não queremos simplesmente remover o Web SQL. Na verdade, ele foi substituído por algo que será mantido pela comunidade de código aberto, disponibilizado como um pacote que pode ser atualizado à vontade, sem o fardo de introduzir correções e novos recursos diretamente nos navegadores. Nosso objetivo é permitir que os desenvolvedores tragam os próprios bancos de dados para a Web.
Além disso, esperamos que esse exemplo ajude a florescer um novo ecossistema de bancos de dados de código aberto. A versão dos identificadores de acesso ao sistema de arquivos finalmente fornece o novo primitivo em que as soluções de armazenamento personalizadas podem ser criadas.
Motivos para a descontinuação do Web SQL
Questões de sustentabilidade e segurança
A especificação Web SQL não pode ser implementada de maneira sustentável, o que limita a inovação e os novos recursos. A última versão do padrão afirma ""Os agentes do usuário precisam implementar o dialeto SQL compatível com o Sqlite 3.6.19".
O SQLite não foi projetado inicialmente para executar instruções SQL maliciosas, mas a implementação do Web SQL significa que os navegadores precisam fazer exatamente isso. A necessidade de acompanhar as correções de segurança e estabilidade dita a atualização do SQLite no Chromium. Isso entra em conflito direto com o requisito do Web SQL de se comportar exatamente como o SQLite 3.6.19.
Forma da API
Web SQL também é uma API que mostra sua idade. Por ser um filho do final dos anos 2000, ele é um ótimo exemplo do "inferno de callback", como demonstra o exemplo de código a seguir (cortesia de Nolan Lawson). Como você pode notar, as instruções SQL (usando o dialeto SQL SQLite) são transmitidas como strings para métodos de banco de dados.
openDatabase(
// Name
'mydatabase',
// Version
1,
// Display name
'mydatabase',
// Estimated size
5000000,
// Creation callback
function (db) {
db.transaction(
// Transaction callback
function (tx) {
// Execute SQL statement
tx.executeSql(
// SQL statement
'create table rainstorms (mood text, severity int)',
// Arguments
[],
// Success callback
function () {
// Execute SQL statement
tx.executeSql(
// SQL statement
'insert into rainstorms values (?, ?)',
// Arguments
['somber', 6],
// Success callback
function () {
// Execute SQL statement
tx.executeSql(
// SQL statement
'select * from rainstorms where mood = ?',
// Arguments
['somber'],
// Success callback
function (tx, res) {
// Do something with the result
var row = res.rows.item(0);
console.log(
'rainstorm severity: ' +
row.severity +
', my mood: ' +
row.mood,
);
},
);
},
);
},
);
},
// Error callback
function (err) {
console.log('Transaction failed!: ' + err);
},
// Success callback);
function () {
console.log('Transaction succeeded!');
},
);
},
);
Se você executar esse código e inspecionar a tabela criada com o Chrome DevTools, este será o resultado:
Falta de suporte ao implementador
Além do formato misterioso da API (pelo menos do ponto de vista atual), o Mozilla tinha muitas preocupações (link em inglês) sobre a criação do SQL da Web no SQLite:
"Acreditamos que o [SQLite] não é a base certa para uma API exposta a conteúdo geral da Web, principalmente porque não existe um padrão confiável e amplamente aceito que faça subconjuntos do SQL de maneira útil. Além disso, não queremos que mudanças no SQLite afetem a Web posteriormente e não achamos que é prudente usar as principais versões do navegador (e um padrão da Web) para o SQLite."
Leia sobre as preocupações do Mozilla na postagem do antigo blog do Mozillan Vladimir Vuki confiávelevih (em inglês). Para mais detalhes, confira os minutos do Grupo de trabalho de aplicativos da Web do W3C (e, se realmente quiser entrar em detalhes, leia os registros IRC) e os arquivos da lista de e-mails. Além disso, a postagem do blog de Nolan Lawson (em inglês) fornece uma boa visão geral do que aconteceu.
Feedback
Se você tiver alguma preocupação sobre as etapas de descontinuação nesta postagem, use a lista de e-mails blink-dev (em inglês). A associação a este grupo é aberta a todos, e qualquer pessoa pode postar.
Links relacionados
- Entrada ChromeStatus: Suspender o uso do WebSQL em contextos de terceiros e removê-lo
- Entrada ChromeStatus: Suspender o uso do WebSQL em contextos não seguros e removê-lo
- Intenção de suspender o uso e remover: WebSQL em contextos de terceiros.
- Intent de descontinuação e remoção: WebSQL em contextos não seguros
- Problema do Chromium: descontinuação e remoção do WebSQL em contextos de terceiros
- Problema do Chromium: suspensa e remova o WebSQL em contextos não seguros
- Problema no Chromium: descontinuar e remover o WebSQL (Window#openDatabase)
- SQLite Wasm no navegador com suporte do sistema de arquivos particulares de origem
Agradecimentos
Este artigo foi revisado por Joe Medley, Ben Morss e Joshua Bell.