O bază SQLite de 66MB este partea cu adevărat interesantă aici. Nu povestea despre AI-assisted coding, nu trucul cu GitHub Actions și nici măcar apropierea de MCP. O copie locală, interogabilă, a datelor MDN despre compatibilitatea browserelor este partea pe care inginerii chiar o pot folosi.
Acesta este un scurt project note de la Simon Willison, deci nu are rost să îl umflăm artificial. Dar cred că direcția este corectă: iei un set de date public util, îl pui într-un format banal, îl publici într-un loc ușor de consumat și îi lași pe alții să construiască deasupra.
Ce este browser-compat-db?
Proiectul convertește repository-ul mdn/browser-compat-data de la Mozilla într-o bază de date SQLite. Baza generată are aproximativ 66MB și este publicată dintr-un branch obișnuit de GitHub repository, astfel încât poate fi descărcată cu open CORS headers. Asta contează pentru că datele nu sunt doar descărcabile; pot fi consumate ușor și direct din tool-uri care rulează în browser.
Exemplul practic din sursă este Datasette Lite, care poate deschide de la distanță baza găzduită. Asta este mult mai util decât să arunci niște JSON într-un repo și să spui că ai terminat.
Celălalt detaliu util este operațional, nu arhitectural: GitHub releases nu s-au potrivit din cauza comportamentului CORS, așa că workflow-ul construiește baza și face force-push într-un branch db de tip orphan. Este un workaround pragmatic și exact genul de detaliu care decide dacă un dataset chiar poate fi refolosit.
De ce este mai util decât pare
Mult prea multă discuție despre MCP este încă orientată spre demo-uri. Lumea este impresionată că un model poate apela un tool, dar întrebarea mai importantă este dacă datele de dedesubt sunt portabile, inspectabile și ieftin de mutat.
Proiectul acesta nimerște bine partea asta. SQLite este banal în cel mai bun sens:
- ușor de replicat
- ușor de interogat
- ușor de versionat într-un build pipeline
- ușor de folosit din tool-uri locale, scripturi și exploratoare care rulează în browser
Asta are și efecte de ordinul doi. Odată ce datele de compatibilitate sunt un simplu fișier de bază de date, devine mult mai simplu să le alimentezi în tool-uri interne pentru dezvoltatori, joburi de validare, sisteme de documentație sau într-un setup de MCP server development fără să obligi fiecare consumator să treacă printr-un API făcut special.
În practică, este și mai sănătos din punct de vedere al guvernanței. Un tool intern poate fixa o copie cunoscută, poate revizui schimbările și poate decide când face refresh. De multe ori asta este mai bine decât să depinzi de un endpoint live care își poate schimba comportamentul în tăcere.
Verdictul meu: alegerea formatului este câștigul real
Cred că acesta este un pattern bun și mai bun decât multe povești despre "AI data access" fiindcă începe cu produsul de date în sine. Dacă materialul sursă este public și structurat, livrarea ca fișier de bază de date este adesea răspunsul corect.
Limitarea este evidentă: nu este un managed service. Tot trebuie să știi ce schemă interoghezi, cât de des se face refresh și cum vrei să consumi update-urile. Pentru echipele care vor policy, auditability sau utilizare downstream controlată, tot ai nevoie de propriile guardrails în jurul lui, la fel ca pentru orice componentă de AI workflow automation sau integrare internă cu Microsoft Copilot and AI agents.
Și nu aș ignora unghiul strategic: odată ce inginerii se obișnuiesc cu artefacte SQLite portabile, găzduite deschis, o parte din prețurile pentru produse vândute ca API încep să pară slabe. Dacă un dataset public poate fi livrat ca fișier de 66MB, atunci wrapper-ele tarifate la consum trebuie să justifice ceva real, nu doar comoditatea.
Concluzia practică este simplă: dacă construiești tool-uri MCP sau utilitare de developer care rulează în browser, acesta este un pattern care merită copiat. Publică datele într-un format pe care oamenii îl pot inspecta și muta. Interfața mai sofisticată poate veni după.
