{"id":1662,"date":"2022-11-10T10:55:18","date_gmt":"2022-11-10T09:55:18","guid":{"rendered":"https:\/\/informatik.htwk-leipzig.de\/seminar\/?p=1662"},"modified":"2023-02-05T20:57:20","modified_gmt":"2023-02-05T19:57:20","slug":"appwrite","status":"publish","type":"post","link":"https:\/\/informatik.htwk-leipzig.de\/seminar\/lehrveranstaltungen\/betriebliche-informationssysteme\/2022\/appwrite\/","title":{"rendered":"Appwrite"},"content":{"rendered":"

Gliederung<\/h1>\n
    \n
  1. Motivation<\/li>\n
  2. Features<\/li>\n
  3. Installation<\/li>\n
  4. Architektur<\/li>\n
  5. Gesch\u00e4ftsprozess<\/li>\n
  6. Alternativen<\/li>\n
  7. Quellen<\/li>\n<\/ol>\n

    Motivation<\/h1>\n

    Die Backendentwicklung f\u00fcr eine im produktiven Umfeld genutzte Anwendung ist eine zeitaufw\u00e4ndige Angelegenheit. Damit die Anwendung sinnvoll genutzt werden kann, ist es meist n\u00f6tig eine Datenbank zu betreiben, verschiedene Nutzer mit verschiedenen Zugriffsrechten zu verwalten, und eine sinnvolle REST-API bereitzustellen. Dies sind alles Schritte die in den meisten Backends \u00e4hnlich gel\u00f6st werden m\u00fcssen. Damit nicht jedes mal von neuem eine L\u00f6sung geschaffen werden muss gibt es sogenannte Backends-as-a-Service (BaaS). Diese haben das Ziel die Modellierung, das Hosting und die Integration in die Anwendung deutlich zu vereinfachen. Bereits bekannte und weit verbreitete BaaS sind zum Beispiel Firebase von Google oder Amplify von den Amazon Web Services. Diese sind jedoch propriet\u00e4r und haben somit die Eigenschaft, dass wenn man einmal sich f\u00fcr einen der beiden Anbieter entscheidet, der Wechsel zu einem Alternativprodukt sich sehr schwer gestalten kann. Als Quelloffene Alternative bietet sich das in diesem Blog-Beitrag behandelte Appwrite. Dies ist ein noch relativ junges Startup welches im Jahr 2021 an den Mark gekommen ist und im Oktober 2022 die Version 1.0 erreicht hat. Bei Appwrite werden ausschlie\u00dflich Quelloffene Technologien eingesetzt welches das Produkt zum einem selbst-hostbar und zum anderen einfach zum wechseln zu eventuellen alternativen macht. In Appwrite werden die meisten f\u00fcr ein Backend ben\u00f6tigten Features bereitgestellt. Dies geschieht indem verschiedene Docker-Container f\u00fcr einzelne verf\u00fcgbare Services bereitgestellt werden, welche dann miteinander zusammenarbeiten. So gibt es bei Appwrite eine Datenbank f\u00fcr die Persistierung von Daten, welche gleichzeitig eine REST-API bereitstellt. Um die Business-Logik des Backends darzustellen k\u00f6nnen einerseits Cloud-Functions oder bereitgestellte Server-SDKs verwendet werden. F\u00fcr die Client Anwendungen werden ebenfalls SDKs f\u00fcr alle weit verbreiteten Programmiersprachen bereitgestellt.<\/p>\n

    Features<\/h1>\n

    Datenbank<\/h2>\n

    Im Appwrite k\u00f6nnen belibig viele Datenbanken angelegt werden. Verwendet wird dabei eine NoSQL-Abstraktion \u00fcber bereits existierenden Datenbanksystemen. Es sind Treiber f\u00fcr MariaDB (welches auch standardm\u00e4\u00dfig voreingestellt ist), MySQL und MongoDB vorhanden.<\/p>\n

    In einer Datenbank k\u00f6nnen verschiedene Tabellen erstellt werden welche dann Dokumente enthalten. Die einzuf\u00fcgenden Dokumente k\u00f6nnen mithilfe von Filterkriterien auf Zul\u00e4ssigkeit gepr\u00fcft werden. F\u00fcr einen h\u00f6here Effizienz der Datenbank k\u00f6nnen au\u00dferdem selbst erstellte Datenbank-Indexe erstellt werden. Relationen werden von der Appwrite-Datenbankabstraktion nicht unterst\u00fctzt. Sollten diese ben\u00f6tigt werden, m\u00fcsses diese \u00fcber selbst erstellte Functions implementiert werden.<\/p>\n

    Bei der Erstellung von Datenbanken und Tabellen ist der Zugriff auf die Dokumente standardm\u00e4\u00dfig nur den Administratoren erlaubt. Mithilfe von Security Regeln k\u00f6nnen Zugriffsregeln entweder Tabellenweit oder f\u00fcr jedes einzelne Dokument konfiguriert werden. Alle Erstellten Tabellen und Dokumente sind f\u00fcr die Zugriffsberechtigten Nutzer sofort mittels einer automatisch Generierten REST- und GraphQLschnittstelle abrufbar.<\/p>\n

    Authentifizierung<\/h2>\n

    Um den komplizierten und oft auch fehleranf\u00e4lligen vorgang der Authentifizierung von Nutzern zu vereinfachen bietet Appwrite einen Authentifizierungsservice an. Mithilfe dieses Services k\u00f6nnen Accounts erstellt und verwaltet werden. Die Accounterstellung ist hierbei zum Beispiel mittels Email und Passwort, diversen OAuth-Anbietern, einer magic-URL oder weiteren Alternativen m\u00f6glich. Auch Anonyme Benutzer k\u00f6nnen erstellt werden. Mithilfe von Teams k\u00f6nnen Benutzer in verschiedene Gruppen mit eigenen Zugriffsberechtigungen eingeteilt werden.<\/p>\n

    Functions<\/h2>\n

    Mithilfe von Appwrite-Functions kann die Funktionalit\u00e4t von Appwrite erweitert werden. Diese bieten die M\u00f6glichkeit auf alle internen Appwrite-Events zu reagieren. Zudem k\u00f6nnen Functions mittels einer bereitgestellten REST-Schnittstelle aktiviert werden. Auch das zyklische Ausf\u00fchren von Functions mittels einem in der CRON-Syntax beschriebenen Zeitplanes ist m\u00f6glich.<\/p>\n

    F\u00fcr die Erstellung von Appwrite-Functions stehen SDKs in diversen Programmiersprachen zur Verf\u00fcgung. Eine Auswahl von unterst\u00fctzten Programmiersprachen ist: Python, Node.js, PHP, Deno, Dart, Swift, .NET, Kotlin, Java, C++, Rust.<\/p>\n

    Die Ausf\u00fchrung der Functions wird realisiert indem jede einzelne Function ein eigener von Appwrite gemanagter Dockercontainer ist. Das deployen von Functions geschieht am einfachsten \u00fcber ein von Appwrite bereitgestelltes Kommandozeilenwerkzeug namens Appwrite-CLI. Es ist jedoch auch \u00fcber die Appwrite-Console oder manuell \u00fcber die Appwrite-Server-API m\u00f6glich. W\u00e4hrend des deployments wird der Dockercontainer f\u00fcr die Function gebaut. Nach dem erfolgreichen Bauprozesses einer Function kann diese sofort ausgef\u00fchrt werden. Wie bei der Datenbank ist es hier ebenfalls eine Konfiguration der Ausf\u00fchrungsberechtigten Accounts m\u00f6glich.<\/p>\n

    Storage<\/h2>\n

    Der Appwrite-Storageservice ist f\u00fcr die Verwaltung von Dateien zust\u00e4ndig. Der Hauptanwendungszweck ist dabei die Verarbeitung von Bildern, Videos und anderen Dokumenten.<\/p>\n

    Der Storageservice ist in verschiedene Bereiche aufgeteilt. Einerseits gibt es einen allgemeinen Speicher und andererseits die Speicherung von Dateien in Buckets.<\/p>\n

    Die Buckets diesen zur besseren Verwaltung von spezifischen Dateien. Ein weit verbreitetes Szenario ist zum Beispiel das Erstellen eines Buckets f\u00fcr Bilddateien. In dem Bucket kann dann unter anderem die maximal zul\u00e4ssige Aufl\u00f6sung und Dateigr\u00f6\u00dfe festgelegt werden. Zudem k\u00f6nnen automatisch nach dem Hochladen eines Bildes, weitere Versionen dieses Bildes mit verschiedenen konfigurierten Aufl\u00f6sungen automatisch generiert werden. F\u00fcr eine erh\u00f6hte Sicherheit der Daten ist kann zudem bei Bedarf eine Verschl\u00fcsselung von Dateien stattfinden. Je nach Konfiguration sind auch automatische Vierenscans auf den Dateien m\u00f6glich.<\/p>\n

    Realtime<\/h2>\n

    Auf jedes interne Appwrite Event kann mittels Websocktes \u00fcber die bereitgestellte Realtime-API von au\u00dfen in Echtzeit reagiert werden. Am H\u00e4ufigsten wird dieser Service f\u00fcr das automatische Bereitstellen von \u00c4nderungen in der Datenbank verwendet. Die Realtime-Funktionalit\u00e4t ist nur \u00fcber die Client SDKs von Appwrite m\u00f6glich. Client SDKs sind f\u00fcr Web (Node.js), Flutter, Android (Kotlin) und Apple (Swift) verf\u00fcgbar.<\/p>\n

    Console<\/h2>\n

    Die Appwrite-Console ist eine Weboberfl\u00e4che zur grafischen Verwaltung von Appwrite. Alle f\u00fcr Appwrite Kritischen Funktion k\u00f6nnen hier aus \u00fcberwacht und ver\u00e4ndert werden. In der Console k\u00f6nnen neue Datenabnken angelegt, Benutzer verwaltet werden oder Functions ausgef\u00fchrt werden.<\/p>\n

    Als Alternative zur Appwrite Console existiert die Appwrite-CLI. Dies ist ein Kommandozeilenwerkzeug welches die Entwicklung von Anwendungen mit Appwrite erleichtert. Auch hier sind alle Appwrite Funktionen abgedeckt.<\/p>\n

    Installation<\/h1>\n

    F\u00fcr eine Installtion von Appwrite ist ein installiertes Docker und Docker-Compose zwingend Notwendig.<\/p>\n

    docker run -it --rm \\
    \n--volume \/var\/run\/docker.sock:\/var\/run\/docker.sock \\
    \n--volume \"$(pwd)\"\/appwrite:\/usr\/src\/code\/appwrite:rw \\
    \n--entrypoint=\"install\" \\
    \nappwrite\/appwrite:1.2.0<\/code><\/p>\n

    Mithilfe dieses Kommandos wird Appwrite mittels Docker auf dem System bereitgestellt. Die w\u00e4hrend der Installtion vorgenommenenn Konfigurationen werden in einer docker-compose-Datei festgehalten. Weitere Konfiguration findet \u00fcber eine automatisch bei der Installation erstellte Umgebungsvariablen-Datei statt.<\/p>\n

    Architektur<\/h1>\n

    Appwrite benutzt eine Microservice Architektur, die speziell auf gute Skalierbarkeit und geteilte Zust\u00e4ndigkeiten ausgelegt ist. Au\u00dferdem werden verschiedene APIs wie REST, WebSocket und bald auch GraphQL unterst\u00fctzt. Auf diese Weise wird dem Anwender erlaubt auf verschiedenen Wegen mit seinen Ressourcen zu Interagieren und dabei seine bevorzugten Protokolle zu verwenden.<\/p>\n

    Die Appwrite API wurde so konzipiert, dass sie extrem schnell ist, indem sie In-Memory-Caching nutzt und alle komplexen Aufgaben an Background Worker delegiert. Durch diese Background Worker ist es m\u00f6glich die Rechenkapazit\u00e4t und -kosten, mithilfe einer Message Queue pr\u00e4zise zu steuern.<\/p>\n

    Appwrite benutzt eine Reihe weiterer Technologien um seine Funktionen umzusetzen (Redis, InfluxDB, MariaDB, Telegraf, ClamAV\/SMTP, Letsencrypt). Die bereits genannte Message Queue sowie der Cache der Datenbank wird mit Redis umgesetzt. Die Datenbank selbt wird in einem anderen Kapitel beschrieben, die daf\u00fcr angewandten Technologien sind InfluxDB f\u00fcr Zeitreihen und eine Abstraktion \u00fcber MariaDB f\u00fcr sonstige Daten. Zum Sammeln von Metriken zur Applikation wird Telegraf verwendet. So werden dem Nutzer verschiedenen Informationen \u00fcber sein Sytem zur Laufzeit zur Verf\u00fcgung gestellt. F\u00fcr Mails wird ein SMTP Server genutzt. Abh\u00e4ngig von der Version ist auch ClamAV als Virenschutzprogramm enthalten. Zertifikate k\u00f6nnen in Appwrite per Letsencrypt erstellt werden.<\/p>\n

    \"\"<\/p>\n

    Gesch\u00e4ftsprozess<\/h1>\n

    Der hier dargestellte Gesch\u00e4ftsprozess zeigt das Verfahren beim hinzuf\u00fcgen einer neuen Funktion. Dabei gilt es zun\u00e4chst die Funktion zu initialisieren. Dies ist beispielsweise \u00fcber die Konsole mit dem Befehl appwrite init function<\/code>, oder \u00fcber die Benutzeroberfl\u00e4che m\u00f6glich. Anschlie\u00dfend wird die Funktion implementiert. Da Appwrite sprachunabh\u00e4ngig ist kann dies mit einer beliebigen Programmiersprache geschehen. Sind diese grundlegenden Schritte erledigt m\u00fcssen einige Entscheidungen getroffen werden, welche den weiteren Ablauf bestimmen.<\/p>\n

    Die erste dieser Entscheidungen befasst sich mit dem Bedarf an externen Informationen. Denn wenn dieser Bedarf besteht muss eine Umgebungsvariable angelegt werden, \u00fcber welche die Funktion auf die Informationen zugreifen kann. Ist dies erledigt, besteht die M\u00f6glichkeit weitere Besonderheiten, wie zum Beispiel einen Timeout oder spezielle Zugriffsberechtigungen, festzulegen. Des Weiteren wird bestimmt auf welche Art und Weise die Funktion ausgel\u00f6st werden soll. Standardm\u00e4\u00dfig erfolgt die Ausl\u00f6sung \u00fcber HTTP-Request, doch es gibt auch die M\u00f6glichkeit die Ausl\u00f6sung \u00fcber Cron-Jobs oder spezielle Events zu definieren. Soll dies geschehen ist die entsprechend ein Cron-Job zu erstellen bzw. das ausl\u00f6sende Event festzulegen.<\/p>\n

    Damit ist die Funktion fertig konfiguriert und kann nun deployed werden. Dies ist wie oben schon auf verschiedenen Wegen m\u00f6glich, beispielsweise mit dem Befehl appwrite deploy function <\/code> in der Konsole. Zu diesem Zeitpunkt ist die Funktion bereit zur Ausf\u00fchrung. <\/p>\n

    Die Ausf\u00fchrung kann je nach den zuvor getroffenen Einstellungen auf verschiedenen Wegen geschehen. Diese beeinflussen der Ablauf der Funktion allerdings nicht weiter. Anschlie\u00dfend ist die Funktion wieder zur Ausf\u00fchrung bereit. Ab dem Zeitpunkt der Bereitstellung der Funktion kann sich der beschriebene Ablauf beliebig h\u00e4ufig wiederholen. <\/p>\n

    \"\"<\/p>\n

    Alternativen<\/h1>\n

    Firebase<\/h2>\n

    Mit Blick auf die zur Verf\u00fcgung stehenden Features k\u00f6nnen Appwrite und Firebase nahezu als gleichwertig angesehen werden. Der Hauptunterschied liegt hier in der Art und Weise in der das Backend zur Verf\u00fcgung gestellt wird. W\u00e4hrend Firebase nur in der Google Cloud Platform verf\u00fcgbar ist, wird Appwrite selbst gehosted. Dadurch ist die Konfiguration und das Bereitstellen von Appwrite deutlich anspruchsvoller als bei Firebase. Allerdings hat man auf diese Weise umgekehrt auch eine bedeutend h\u00f6here Kontrolle \u00fcber das Backend. Au\u00dferdem ist zu bedenken, dass Appwrite, abgesehen von den entstehenden Kosten f\u00fcr das Hosting, kostenlos ist. Bei Firebase ist hingegen eine Geb\u00fchr zu entrichten.<\/p>\n

    Supabase<\/h2>\n

    Supabase ist ebenfalls eine direkte Alternative zu Appwrite und Firebase. Im Hosting wird hier eine Mittelweg gegangen. Das hei\u00dft es ist sowohl m\u00f6glich Supabase \u00fcber eine Cloud-L\u00f6sung zu beziehen, als auch es direkt selbst zu hosten. Jedoch ist hierbei zu bedenken, dass die selbst gehostete Variante weniger robust und einfach zu handhaben ist, als das \u00c4quivalent von Appwrite. Ein weiterer Unterschied ist die Datenbank, denn bei Supabase wird auf eine Postgres DB gesetzt. Bei Appwrite wird hingegen auf einen Ansatz gesetzt, der stark von NoSQL Datenbanken gepr\u00e4gt wird. Dadurch findet mehr Abstraktion statt und die Einbindung in die Rest API ist sehr einfach m\u00f6glich.<\/p>\n

    Quellen<\/h1>\n

    https:\/\/appwrite.io\/docs\/
    \nhttps:\/\/medium.com\/appwrite-io\/announcing-console-2-0-2e0e96891cb0
    \nhttps:\/\/medium.com\/@tkarmakar27112000\/appwrite-vs-supabase-vs-firebase-48d1dd79bdc2
    \nhttps:\/\/github.com\/open-runtimes\/open-runtimes
    \nhttps:\/\/dev.to\/appwrite\/take-your-serverless-functions-to-new-speeds-with-appwrite-013-5868
    \nhttps:\/\/dev.to\/appwrite\/it-s-here-announcing-appwrite-0-10-and-the-new-appwrite-realtime-api-lbm
    \nhttps:\/\/res.cloudinary.com\/practicaldev\/image\/fetch\/s–38oSSm4b–\/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880\/https:\/\/dev-to-uploads.s3.amazonaws.com\/uploads\/articles\/sj7mmouviy03u0nct7u5.png
    \nhttps:\/\/www.linode.com\/docs\/guides\/getting-started-appwrite\/<\/p>\n","protected":false},"excerpt":{"rendered":"

    Gliederung Motivation Features Installation Architektur Gesch\u00e4ftsprozess Alternativen Quellen Motivation Die Backendentwicklung f\u00fcr eine im produktiven Umfeld genutzte Anwendung ist eine<\/p>\n","protected":false},"author":117,"featured_media":1667,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-1662","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-betriebliche-informationssysteme"],"_links":{"self":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/1662","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/users\/117"}],"replies":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/comments?post=1662"}],"version-history":[{"count":32,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/1662\/revisions"}],"predecessor-version":[{"id":3015,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/1662\/revisions\/3015"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/media\/1667"}],"wp:attachment":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/media?parent=1662"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/categories?post=1662"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/tags?post=1662"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}