Appwrite 2.0 släpper in dig direkt i PostgreSQL

Appwrite 2.0 låter dig ansluta till din databas med vanlig `psql`, ladda upp filer med AWS CLI och logga in användare via OAuth 2.1. Ingen proprietär SDK i mitten. Det är den största förändringen plattformen gjort sedan den lanserades och den handlar mindre om nya funktioner än om vem som äger din kod när du vill flytta.

Tidigare tvingade backend-as-a-service dig till ett val: använd leverantörens abstraktioner och kom igång på en eftermiddag eller bygg din egen plumbing och äg allt själv. Version 2.0 försöker ta bort valet genom att bygga tjänsterna på protokoll som redan finns, enligt Appwrites egna releaseanteckningar.

Fem databastyper, varav två pratar rent SQL

Plattformen stöder nu fem sorters databaser. Native PostgreSQL och native MySQL är de intressanta för den som funderat på inlåsning, eftersom de ansluts direkt via standardprotokoll. Din ORM ser en vanlig Postgres-server. Din migreringsfil fungerar som den gör lokalt. Appwrite ligger inte emellan och översätter.

De tre övriga täcker andra behov: DocumentsDB för schemafritt JSON, VectorsDB för vektordata när du bygger något med embeddings och den gamla Appwrite-hanterade databasen som funnits sedan tidigare versioner. De nativa SQL-databaserna erbjuds som dedikerade molntjänster på betalplanerna.

Tabellen döljer en poäng värd att säga rakt ut: bara de två översta raderna ger dig en databas du kan ta med dig någon annanstans utan att skriva om datalagret.

Lagringen svarar på S3-API, så rclone fungerar direkt

Filhanteringen exponerar ett S3-kompatibelt API. AWS CLI, AWS:s egna SDK:er, rclone och i princip vilket S3-medvetet verktyg som helst pratar med Appwrite-buckets utan adapter. Komprimering, kryptering, bildtransformationer och åtkomstkontroll ligger kvar ovanpå.

För dig som byggt något som redan laddar upp till S3 betyder det att bytet blir en ändring av endpoint och nycklar. För dig som inte gjort det betyder det att du lär dig ett API du kommer ha nytta av oavsett var du hamnar sen.

Appwrite blir identitetsleverantör med OAuth 2.1, inte bara inloggningsknapp

Autentiseringsdelen har funnits länge med e-post, SMS, sociala inloggningar, anonyma sessioner och magic URLs. Nyheten är att Appwrite nu implementerar OAuth 2.1 och OpenID Connect som en standardkomplett identitetsleverantör. Alltså: andra tjänster kan använda Appwrite som sin identitetskälla, inte tvärtom.

Det öppnar för att låta flera appar dela ett användarkonto utan att du bygger ett eget SSO-lager. Handlar du med tokens och inloggningsflöden är det värt att förstå hur signerade URL:er fungerar i samma andetag, eftersom principerna överlappar.

Konsolen har fått terminal och en API-utforskare

Nya Console IV innehåller en terminal som kör Appwrite CLI direkt i webbläsaren, med session och projektkontext redan ifyllda. Vid sidan av ligger Appwrite Explorer, som läser projektets OpenAPI-specifikation och bygger förfrågningar åt dig via formulär.

Det låter som bekvämlighet och det är det. Men det tar också bort ett vanligt hinder för nybörjare, nämligen att förstå ett API innan man vet vilka anrop som finns. Explorer visar ytan.

Brandväggen kan neka, utmana eller strypa trafik per regel

Nätverksdelen har fått en brandvägg på organisationsnivå. Regler kan villkoras på IP, hostname, path, metod, headers, query-parametrar, user agent och plats. Åtgärderna är deny, bypass, challenge, rate limit och redirect.

Det är funktionalitet som normalt kräver en separat tjänst framför applikationen. Att den ligger i plattformen sänker tröskeln för att faktiskt sätta upp den. Och trösklar avgör: mycket av den säkerhet som aldrig implementeras uteblir för att den kostar en extra leverantör och en eftermiddags konfiguration. Missbrukskontroller, DDoS-skydd och ett globalt CDN hör till samma paket.

Hur det står sig mot Supabase och Firebase

Supabase byggde hela sin identitet på just det Appwrite nu gör: du får en riktig Postgres-databas och kan prata med den som vilken Postgres som helst. På den punkten har Appwrite kommit ikapp snarare än gått om. Skillnaden ligger i bredden. Appwrite paketerar serverless-funktioner, frontend-hosting för statiskt, SSR och CSR direkt från Git, enhetlig messaging för e-post, SMS och push samt brandvägg i samma konsol.

Firebase går åt andra hållet. Där är abstraktionerna hela poängen och Firestore har ingen standardersättare att flytta till. Kommer du igång snabbast med Firebase? Ofta. Kan du flytta därifrån utan att skriva om datalagret? Sällan.

Så: bygger du något där Postgres är rätt databas och du vill kunna byta värd senare, står Appwrite 2.0 och Supabase nära varandra och valet avgörs av hur mycket av resten du vill ha från samma leverantör. Bygger du en mobilapp med realtidssynk och tänker stanna hos Google, är Firebase fortfarande vettigt. Är portabilitet ett uttalat krav i projektet väger Appwrites nya standardstöd tungt, inte minst för att plattformen är open source och går att självhosta.

Molnprojekt rör sig inte vid uppgradering, självhostade gör det

Befintliga molnprojekt fortsätter fungera vid uppgradering till 2.0 utan migrering. Kör du självhostat från version 1.9 krävs däremot en migrering, vilket också heise.de rapporterar i sin genomgång av releasen. Version 2.1 finns tillgänglig för självhostad installation.

Under huven kör 2.0 på en ny coroutine-motor som Appwrite kallar Hyperloop B. Den är inget du behöver förhålla dig till som utvecklare men den förklarar varför omskrivningen tog tid.

FAQ

Kan jag ansluta med min vanliga ORM?

Ja, till native PostgreSQL och MySQL. Prisma, Drizzle, SQLAlchemy och liknande ser en standardserver och behöver ingen Appwrite-specifik adapter.

Måste jag migrera mina data när jag uppgraderar?

Inte om du kör på Appwrite Cloud. Självhostade installationer från 1.9 kräver migrering vid uppgradering.

Vad kostar native PostgreSQL?

De nativa SQL-databaserna erbjuds som dedikerade molntjänster på betalplanerna. Aktuella nivåer varierar över tid, så jämför direkt hos Appwrite innan du budgeterar.

Är S3-stödet en verklig ersättning för AWS S3?

Till stor del, om ditt användningsfall är uppladdning, hämtning och åtkomststyrning av filer. Verktyg som AWS CLI och rclone fungerar mot Appwrite-buckets. Däremot får du inte AWS omgivande ekosystem av lagringsklasser och integrationer.

Det verkligt intressanta med 2.0 är inte funktionslistan utan att frågan ”vad händer om jag vill flytta?” plötsligt har ett tråkigt svar. Tråkiga svar är bra svar i infrastruktur.