Blog

Nuclino-Backup mit Mojolicious - Teil 2

22.09.2020 // Renée Bäcker

Im ersten Teil habe ich gezeigt, wie wir mit Mojolicious das Login umsetzen und die sogenannten Brains von Nuclino als zip-Archiv holen. Jetzt geht es zum einen darum, die Inhalte als einzelne Markdown-Dateien abzulegen und in unserem Gitlab zu speichern und zum anderen die Abarbeitung zu beschleunigen.

Fangen wir mit dem Entpacken an... Hier nutzen wir Archive::Zip

# siehe Blogpost vom 15.08.2020
my ($info,@brains) = _get_brains( $ua );
my @zips           = _download_backups( $ua, \@brains );

# ab hier ist es neuer Code
_extract_backups( \@zips );
_commit_and_push( $home_dir );

sub _extract_backups {
    my $zips = shift;

    say 'Extract backups ...';

    my $obj = Archive::Zip->new;

    for my $zip ( @{ $zips || [] } ) {
        $obj->read( $zip->to_string );
        $obj->extractTree('', $zip->dirname->to_string );
    }

    $_->remove for @{ $zips || [] };
}

Jedes einzelne zip-Datei wird eingelesen und der Inhalt wird in den backups-Ordner entpackt. Wir verzichten auf das Kommandozeilentool unzip, weil wir die Perl-Abhängigkeiten in einem cpanfile beschreiben können und nicht daran denken müssen das Tool zu installieren.

sub _commit_and_push {
    my $home_dir = shift;
    my $git = Git::Repository->new(
        work_tree => $home_dir->to_string,
    );

    say "commit the changes";
    $git->run(qw/add --all backups/);

    my $date = Mojo::Date->new->to_datetime;
    $git->run("commit", "-m", "nuclino backup $date") ;
    $git->run(qw/push origin master/);
}

Zur Interaktion mit git nehmen wir Git::Repository, damit wir uns nicht um das Wechseln in Verzeichnisse etc. kümmern müssen. Die einzelnen run-Befehle enthält die gleichen Parameter wie git-Kommandos im Terminal.

Damit hätten wir ein Backup unserer Nuclino-Dokumente in einem git-Repository. Jetzt kümmern wir uns um Kleinigkeiten.

Die Laufzeit spielt in diesem Skript nicht wirklich eine Rolle, da der aktuelle Stand nur einige Male am Tag geholt wird, ist es dann egal ob das Skript 10 oder 20 Sekunden läuft. Wir wollen aber die Möglichkeiten von Mojolicious nutzen.

Um die Zeit optimal zu nutzen, sollen mehrere Brains parallel abgeholt werden. Mit dem Committen der Änderungen muss allerdings gewartet werden, bis die zip-Dateien aller Brains abgeholt und entpackt wurden.

Zum Parallelisieren und wieder zusammenführen, nutzen wir Promises. Der Mojo::UserAgent hat schon entsprechende Methoden parat, mit denen Promises erzeugt werden können. Auf Promises werde ich auch in einem späteren Blogpost noch näher eingehen.

Bildlich dargestellt, soll das Ergebnis sich folgendermaßen verhalten:

4df9581e-7546-499d-8052-3903a2f0f4f3.png

Durch die Promises stößt man das Herunterladen des Archivs an und ohne auf das Ergebnis zu warten, geht man zum nächsten Brain weiter. Damit das Programm aber nicht weitermacht bis alle Archive heruntergeladen und entpackt sind, benötigt man einen Mechanismus, der auf die ganzen Promises wartet.

Um parallel zwei URLs abzurufen und die Titel der Seiten auszugeben, kann man dieses einfache Programm nehmen.

#!/usr/bin/perl

use Mojo::Base -strict;
use Mojo::UserAgent;

my $ua = Mojo::UserAgent->new;
for my $url ( qw/perl-academy.de perl-services.de/ ) {
    $ua->get_p( "https://www." . $url )->then( sub {
        my ($tx) = @_;

        say $tx->res->dom->find('title')->first->text;
    })->wait;
}

An die bekannten Methoden wie get, post usw. wird einfach das _p angehängt und man bekommt ein Objekt vom Typ Mojo::Promise zurück. Wird kein Fehler geworfen, wird die Subroutine ausgeführt, die man der Methode then übergibt. Möchte man einen Fehler abfangen, muss man die Methode catch verwenden.

Um die Mojo-eigene Eventloop zu starten (und zu stoppen wenn der Promise erfüllt wurde) wird anschließend noch wait aufgerufen.

In dem Callback, den ich hier der Methode then übergebe wird einfach aus der Antwort ($tx->res) das DOM geholt, dort nach dem title-Tag gesucht und den Text des ersten Treffers ausgegeben.

Übertragen auf unser Nuclino-Backup rufen wir das Archiv des Brains nicht mehr mit get ab, sondern mit get_p. Wir warten nicht, bis alle Archive geholten wurden, bis diese entpackt werden. Das machen wir für das jeweilige Archiv wenn der Promise erfolgreich aufgelöst wurde (then).

Allerdings wollen wir den commit erst machen, wenn alle Archive geholt wurden.

Unser obiges Beispiel sieht entsprechend angepasst so aus:

#!/usr/bin/perl

use Mojo::Base -strict;
use Mojo::UserAgent;
use Mojo::Promise;

my $counter = 0;
my $ua      = Mojo::UserAgent->new;

my @promises;
for my $url ( qw/perl-academy.de perl-services.de/ ) {
    my $promise = $ua->get_p( "https://www." . $url )->then( sub {
        my ($tx) = @_;

        say $tx->res->dom->find('title')->first->text;
        $counter++;
    });

    push @promises, $promise;
}

Mojo::Promise->all( @promises )->then( sub {
   say "Found $counter titles";
})->wait;

Um zu zeigen, dass wirklich auf beide Abfragen gewartet wird, habe ich einen Zähler eingebaut. Wir nutzen auch kein wait beim get_p-Aufruf. Um auf eine Reihe von Promises zu warten nutzen wir all von Mojo::Promise. Das selbst wieder ein Promise zurückliefert. Wenn dieses all-Promise erfolgreich ist, wird der Callback ausgeführt, der bei then übergeben wird.

Der angepasste Code in unserem Programm sieht dann so aus:

# siehe Blogpost vom 15.08.20
my ($info,@brains) = _get_brains( $ua );

my @promises = _download_backups( $ua, \@brains );
Mojo::Promise->all( @promises )->then( sub {
    _commit_and_push( $home_dir );
})->wait;

sub _download_backups {
    my $ua     = shift;
    my $brains = shift;

    say 'Download backups...';

    my @promises;

    my $backup_path = path(__FILE__)->dirname->child('..', 'backups')->realpath;
    $backup_path->remove_tree({ keep_root => 1 });

    for my $brain ( @{ $brains || [] } ) {
        say '... for brain ' . $brain;

        my $url     = sprintf 'https://files.nuclino.com/export/brains/%s.zip?format=md', $brain;
        my $promise = $ua->get_p(
            $url
        )->then( sub {
            my ($tx_backup) = @_;

            my $dir = $backup_path->child( $brain );
            $dir->make_path;

            my $zip_file = $dir->child( $brain . '.zip' );

            $tx_backup->res->save_to( $zip_file->to_string );
            _extract_backups( $zip_file->to_abs );
        });

        push @promises, $promise;
    }

    return @promises;
}

Es wird noch einen dritten Teil der Reihe geben, weil wir mittlerweile das Backup als Datenquelle für andere Anwendungen nutzen und dafür weitere Arbeiten nötig waren.


Permalink:

Nuclino-Backup mit Mojolicious - Teil 1

15.08.2020 // Renée Bäcker

Wir bei Perl-Services.de nutzen seit längerem Nuclino als Wissensdatenbank. Natürlich wollen wir unser Wissen auch gut gesichert wissen. Zum einen falls Nuclino irgendwann mal dicht machen sollte, zum anderen aber auch, damit wir jederzeit den Anbieter wechseln könnten.

Aus diesem Grund haben wir uns die Frage gestellt, wie wir ein Backup der Nuclino-Seiten umsetzen können. Aktuell gibt es leider noch kein API, über das wir das Backup erstellen und herunterladen können. Also müssen wir irgendwie anders an die Daten kommen. Jede einzelne Seite besuchen und herunterladen? Da bräuchten wir eine Liste der Seiten. Das muss doch auch anders gehen...

Was ist Nuclino?

Nuclino ist eine Webanwendung, in der man schnell viel Texte ablegen kann. Diese Texte werden in hierarchischer Form abgelegt. Man kann sogenannte Workspaces zu den verschiedensten Themen anlegen. Innerhalb dieser Workspaces kann man die Texte wiederum in Clustern gruppieren.

Das sieht dann beispielsweise so aus:

Unser Perl-Academy Workspace

Zur Formatierung wird Markdown eingesetzt. Die Markdown-Syntax wird auch direkt umgesetzt und gerendert. Ein Vorteil der Anwendung ist, dass mehrere Personen gleichzeitig an einem Dokument arbeiten können und man bekommt die Änderungen gleich mit. So ist es z.B. möglich, direkt während eines Telefonats Dokumente zu ändern und über die Änderungen zu sprechen.

Die Gliederung der Texte ist erstmal - wie bereits gezeigt - hierarchisch. Man kann aber auch andere Darstellungen wählen, z.B. als Graphen oder als Board:

Der Workspace als Graph

Der Workspace als Board

In den Texten selbst können Inhalte aus verschiedenen Diensten wie zum Beispiel Prezi oder Draw.io eingebettet werden.

Wie arbeitet die Anwendung?

Doch zurück zum Backup. Da es keine API gibt, mussten wir uns anschauen, wie die Anwendung arbeitet. Welche Funktionalitäten gibt es in der Webanwendung? Wie werden diese erreicht? Welche Requests werden ausgelöst?

Wer in der Anwendung etwas stöbert oder einfach die Hilfeseiten besucht, wird bei den Workspace-Settings die Funktion Workspace exportieren finden:

"Workspace exportieren" in den Workspace settings

Man sieht beim Browser die Zieladresse des Links. Man bekommt also ein Zip-Archiv mit den Dokumenten im Markdown-Format – allerdings nur, wenn man die UUID des Workspaces (oder wie im Link bezeichnet des Brains) kennt.

Eine Liste der Workspaces händisch pflegen? Kommt nicht in Frage, das muss auch anders gehen! Die Anwendung selbst muss ja auch irgendwoher wissen, welche Workspaces (oder Brains) es gibt. Also mal die Developertools des Browsers geöffnet und dann schauen was passiert...

Wenn man sich die Netzwerkanalyse anschaut, fällt beim Login auf, dass neben Google-Analytics und Google-Fonts einige Requests an api.nuclino.com geschickt werden. Unter anderem der Login an sich, aber auch etwas mit inital-state.

Auf den Request sendet der Server als Antwort eine JSON-Struktur, in der auch die Brains zu finden sind:

  {
    "response":{
      "userId":"<user-uuid>",
      "teams":[
        {
          "id":"<team-uuid>",
          "data":{
            "name":"<team-name>",
            "brains":[
                "734eaf2c-b066-11ea-81bd-a36778484b6c",
                "820c6310-b066-11ea-9648-bbd09f732919",
                ...
            ],
  ...

Das passende Perl-Skript

Jetzt haben wir alle Informationen, um die Daten aus Nuclino zu sichern. Wir wollen aber mehr. Wir wollen auch die Änderungen sehen, die von Mal zu Mal vorgenommen wurden. Dafür verwalten wir unsere Datensicherung in einem Git-Repository.

Unser Skript muss also folgendes tun:

  • Sich bei Nuclino einloggen
  • Die UUIDs der Brains holen
  • Für jeden Brain ...
    • das Zip-Archiv herunterladen
    • das Archiv in das Git-Repository entpacken
  • Die Änderungen committen
  • Die Änderungen auf den Server pushen

Die ersten beiden Punkte werden wie folgt abgearbeitet:

use Mojo::File qw(path);
use Mojo::JSON qw(decode_json);
use Mojo::UserAgent;
use Mojo::UserAgent::CookieJar;

my $ua = Mojo::UserAgent->new(
    cookie_jar      => Mojo::UserAgent::CookieJar->new,
    max_connections => 200,
);

my $config = decode_json path(__FILE__)->sibling('nuclino.json')->slurp;

my $header = {
    # header wie in den Developertools zu sehen
};

my $base_url = 'https://api.nuclino.com/api/users/';
my $tx_init  = $ua->get('https://app.nuclino.com/login');
my $tx_login = $ua->post(
    $base_url . 'auth' => $header => json => $config,
);

my $tx_initial_state = $ua->get(
    $base_url . 'me/initial-state' => $header
);

my @brains = @{ $tx_initial_state->res->json('/response/teams/0/data/brains') || [] };

In $ua steckt ein Objekt von Mojo::UserAgent. Mit diesem wird erstmal die Login-Seite abgerufen, um ein initiales Cookie zu erhalten. Ohne dieses Cookie ist der Login nicht möglich.

Anschließend loggt sich das Skript bei Nuclino ein. Hier müssen die Header so gesetzt werden, wie es der Browser auch macht.

Mit dem Request an initial-state wird dann das JSON geholt, in dem die UUIDs der Brains stehen. Hier zeigt sich dann auch die Eleganz der Mojo-Klassen: Mit

$tx->res->json('/response/teams/0/data/brains');

kommt man sehr einfach an die Daten. Wenn die Gegenstelle in den HTTP-Headern den richtigen Content-Type setzt, kann man über das Response-Objekt (->res) auf ein Mojo::JSON::Pointer-Objekt (->json) und damit auf die JSON-Datenstruktur zugreifen. Dazu wird ein XPath-änlicher String übergeben.

Jetzt, wo wir die UUIDs der Brains haben, können wir die Zip-Archive einfach herunterladen:

my $backup_path = path(__FILE__)->dirname->child('..', 'backups');

for my $brain ( @brains ) {
    my $url = sprintf 'https://files.nuclino.com/export/brains/%s.zip?format=md', $brain;
    my $tx_backup = $ua->get(
        $url => {
            # header wie in den Developertools zu sehen
        },
    );

    my $dir = $backup_path->child( $brain );
    $dir->make_path;

    my $zip_file = $dir->child( $brain . '.zip' );

    push @zips, $zip_file->to_abs;

    $tx_backup->res->save_to( $zip_file );
}

Hier wird mit Mojo::File erstmal das Zielverzeichnis erstellt. Anschließend wird für jeden Workspace das Zip-Archiv geholt. Für jeden Workspace wird ein eigenes Verzeichnis erstellt, in das wir dann später die Dateien entpacken können.

Als Ergebnis des GET-Requests bekommen wir ein Mojo::Transaction-Objekt. Wie schon oben gesehen, wollen wir wieder etwas mit der Antwort (->res) anfangen. Wenn es keine Multipart-Antwort ist, kann der Inhalt der Antwort mit save_to in eine Datei gespeichert werden.

Im nächsten Teil vollenden wir das Skript, indem wir die Dateien im Git-Repository speichern und das Skript noch etwas schneller machen.


Permalink: