Kategorien
Allgemein Code

Wie man ohne eigene Infrastruktur und mit wenig Aufwand eine Web-App mit “CMS” betreibt – kostenlos.

Ja, klar, alter Hut. CMS SaaS gibts ja auch wie Sand am Meer, aber, wenn man wirklich nur ne kleine API aus einer Tabellenartigen Struktur erzeugen will, ist das meist mit Kanonen auf Spatzen geschossen.

Ich bin ja Freund des Lean-Ansatzes. Also schnüren wir mal folgende Dinge:

  1. Einen Account bei GitLab (oder Github)
  2. Einen Account bei Netlify, Vercel o.ä.
  3. Einen Account bei Google.

Die meisten Web-Entwickler haben Punkt 1 und 3 schon erfüllt, schätze ich. Netlify oder Vercel hat vielleicht nicht jeder, am Ende tut es auch ein eigener Webspace, aber ich habe mich mit Netlify für den wenigsten Aufwand entschieden, da sie auch Cloud-Functions bieten. Das ist hier zwar nicht notwendig, aber ein nettes Feature, welches API-Calls sicherer macht.

Die Datenbank

Eine Tabelle der Dinge, die ich darstellen wollte, gab es schon:

Übersicht über Gamingbooster am deutschen Markt

Auf Youtube habe ich eine sehr coole Einführung in Google Apps Script, welches im Kontext von Spreadsheet ausgeführt wird, gefunden.

Komprimiert ist das die Funktion die ihr im App Script einbauen wollt:

function doGet() {
  const spreadSheet = SpreadsheetApp.getActiveSpreadsheet()
  const workSheet = spreadSheet.getSheetByName('Übersicht Gaming Booster');
  const data = workSheet.getRange("A1").getDataRegion().getValues();
  const fieldNames = data.shift();

  let jsonArray = data.map((row, i) => {

    // remap header fieldname to create new object
    // makes api more robust on table changes
    const obj = row.reduce((acc, curr, idx) => {
      acc[fieldNames[idx]] = curr;
      return acc
    }, {id: i});
    return obj
  })

  return ContentService
    .createTextOutput(JSON.stringify(jsonArray))
    .setMimeType(ContentService.MimeType.JSON)
}

Damit wird aus Zeilen ein Array von Objekten gemacht, die man in einer Web-App gut verarbeiten kann. Die erste Zeile wird dabei als Property-Name für die Objekte genutzt. Wie man an die einzelnen Stellen herankommt, kann man in den Youtube-Videos gut sehen.

Das Frontend.

Das ist eine einfache Vue-App, in der zentralen App.vue Komponente werden die Daten von der Google-API abgerufen und im LocalStorage abgelegt. Durch Nutzung des Vue-PWA Plugins ist die App damit offline-fähig, nachdem sie das erste Mal geladen wurde.

Der automatische Build

Die Versionierung des Frontends liegt in einem privaten Repository auf Gitlab. In meinem Fall habe ich Netlify und Gitlab verknüpft. Damit bekomme ich in Netlify mit, wenn sich mein stabiler Entwicklungszweig ändert und fängt an, meine Anwendung neu aufzubauen.

Diese wird bei Netlify gehostet, dort wird ein npm install && npm run build ausgeführt und das Build-Artefakt als neue Homepage eingesetzt.

Anstelle von Netlify kann man auch Vercel oder Heroku nutzen, eigenen Webspace, Gitlab Pages via Gitlab CI, Github, Github Actions und Github Pages, die Liste an Möglichkeiten ist lang. Meine gewählte Kombi ist aus Bequemlichkeit entstanden (bekannter Workflow, Netlify bietet noch ein paar interessante Zusatzfunktionen, die ich gerne ausprobieren möchte). Und in dieser Form ist das einzige, was ich machen muss, entwickeln und versionieren, der Rest läuft automatisch. Wenn ich schon ein just-for-fun-Projekt mache, muss sich der Management-Overhead auch schon gegen 0 bewegen.

Bonuspunkte

Ich habe die Google-API in meinem Fall durch eine Netlify Function geproxyd, damit die URL immer gleich bleibt und von der App aus immer nur die neueste Funktion genutzt werden kann. Andernfalls könnte jemand die verschiedenen Stadien der API sehen und nutzen, auch wenn diese z.b. durch Änderungen in der Tabelle gar nicht mehr funktionieren oder Daten ausgeben, die ich gar nicht ausgeben will.

Wie lange dauert sowas?

Die erste Version der App hat ca. 3 halbe Tage (nach dem Feierabend) gebraucht. In der Zeit habe ich mit Vite und TypeScript angefangen, aufgrund wirklich merkwürdiger Fehler, die TS im Template-Teil einer Vue-Component das ganze noch mal mit Vue-CLI neu aufgesetzt, dann auf Vue-CLI 5-beta geupgraded und nach einer Auseinandersetzung damit, dass Typescript Sortierfunktionen gar nicht mag, wenn man nach einem dynamisch gewählten Feld sortiert (auch wenn es korrekt getyped wurde), fast einfach alles weggeworfen und auf Javascript umgebaut.

Ach ja, und die API habe ich sehr schnell von einem statischen Row-Index auslesen (MVP lässt grüßen) auf das dynamisch erweiterbare Schema welches oben schon erwähnt ist, umgestellt.

Fazit: Was gelernt und Spaß dabei

Wie eben schon erwähnt: Es ist eigentlich so ziemlich alles schief gelaufen, was hätte schief gehen können. Aber: ich habe Dinge über Typescript gelernt (das war mein erstes TypeScript Projekt). Ich habe eine Menge über Google App Scripts gelernt (die Funktion ist bei mir deutlich anders mittlerweile), mit Parametern und Co. und einem Mini-Counter als Mini-Statistik. Netlify und Gitlab und das automatische Bauen von Anwendungen kannte ich schon, Netlify Functions habe ich in diesem Projekt auch das erste Mal genutzt.

Was ich auf jeden Fall noch vorhabe: Einen Service-Worker bauen, der das Datenmanagement im Hintergrund macht und ggf. die PWA-Notification API nutzen um auf neu hinzugefügte Produkte aufmerksam zu machen. Das wird allerdings komplettes Neuland für mich.

Kategorien
Wochenbericht

Wochenbericht 2021.32

  1. Apple’s Plan to “Think Different” About Encryption Opens a Backdoor to Your Private Life
  2. GitHub’s Engineering Team has moved to Codespaces
  3. For programmers, remote working is becoming the norm (Economist article)
  4. There Is No Benefit or Incentive for Developers to Create Quality Code on Software Projects
  5. The State Of Mobile First and Desktop First

Was zum Lachen: Astronauts use Linux…

Kategorien
Wochenbericht

Wochenbericht 2021.31

  1. Vue.js has been selected as Wikimedia Foundation’s future JavaScript framework
  2. Falsehoods Programmers Believe About Phone Numbers
  3. Ignorant managers cause bad code and developers can only compensate so much
  4. Apple’s Plan to “Think Different” About Encryption Opens a Backdoor to Your Private Life
  5. Webdriver und das Problem mit dem unsichtbaren Text.

Was zum Lachen: Outcome variables

Kategorien
Allgemein Webentwicklung Werkzeuge

Webdriver und das Problem mit dem unsichtbaren Text.

Neulich stand ich vor einem Problem, in dem ich mittels PHP-Webdriver versuchte, portentiell versteckten Inhalt aus einer Seite auszulesen.

Leider ist es so, dass das ganze nicht funktioniert, wenn der Inhalt versteckt ist. Dann wird zwar das Element gefunden, wenn man $element->getText() nutzt, wird aber null bzw ein leerer String ausgegeben. Das ist natürlich unschön und Webdriver selbst hat auch keine Möglichkeit, das DOM selbst zu verändern.

Aber natürlich gibt es einen Weg, dafür zu sorgen, dass man die Inhalte auslesen kann, immerhin muss das Element einfach nur sichtbar sein. Aber was, wenn das Element selbst nicht unsichtbar ist, sondern ein Eltern-Element das verursacht?

Hier die mögliche Lösung

PHP-Webdriver hat die Möglichkeit, einen Javascript-Codeblock an den Browser zu senden (analog zu browser.execute), der zweite Parameter von executeScript wird als arguments[] an die JS-Funktion übergeben. Damit bekommen wir das zu untersuchende Element.

In einer While-Schleife geht es dann (wenn ein Element nicht sichtbar ist) Element für Element nach oben. Dabei bekommt jedes einzelne Element ein display: block !important gesetzt.

Sobald ein überordnetes Element sichtbar ist, sind wir fertig. Eine while-Schleife stellt hier eine einfache Möglichkeit dar, den DOM-Tree rekursiv hochzuwandern.

Es besteht dabei auch die Möglichkeit, ein Element aus diesem Codeblock, der in eine Lambda-Funktion (auch “anonyme Funktion”) gepackt wird, zurückzugeben und das Element in PHP weiterzuverarbeiten. Allerdings müsste das Element dann zwischen den beiden Umgebungen ständig das Element für meine Schleifen hin- und hergereicht werden, das ist vermutlich weniger performant, als das einmal am Stück durchzugehen und das komplett in Javascript durchzuziehen, ohne vorher zurückzuspringen.

    /**
     * @param Client $client
     * @param RemoteWebElement $element
     * @throws \Exception
     */
    private function makeElementTreeVisible($client, $element): void
    {
        if (!$element->isDisplayed()) {
            $response = $client->executeScript('
                var element = arguments[0];

                function isVisible(elem){
                    return !!( elem.offsetWidth || elem.offsetHeight || elem.getClientRects().length )
                    && window.getComputedStyle(elem).visibility !== "hidden";
                }

                while (!isVisible(element) ) {
                    element.setAttribute("style", "display: block !important")
                    element = element.parentNode;
                }
            ', [$element]);
        }
    }

Vermutlich nicht die super-perfomanteste Weise, aber zumindest sollten damit alle Edge Cases abgebildet sein.

Andere Möglichkeiten wären noch: den Style für alle Elemente setzen oder versuchen alle CSS-Styles zu entfernen (hilft halt nicht gegen Inline-Styles).

Habt ihr dieses Problem schon einmal gehabt? Wie habt ihr das gelöst?