Technologiestack für eine lokal speichernde Webanwendung

[alexber]

Hallo an alle,

ich bin neu hier und habe - nachdem ich schon überall und lange gesucht habee - keine Kraft mehr und stelle nun meine Fragen. Über Antworten von Euch würde ich mich sehr freuen.

Ich habe vor, eine Website zu erstellen, über die (auch sehr große) Textdateien verarbeitet werden können - diese jedoch nicht erst auf den Webserver geladen werden müssen. Es erfolgt eine zeilenbasierte Bearbeitung und eine Datenbank muss nicht involviert sein.

Und nun stehe ich beim Thema der Technologien vor lauter Fragen. Ich selbst kenne mich ganz gut mit der rudimentären Webprogrammierung PHP, CSS usw. aus - denke aber, dass es was anderes sein muss. So ein paar Stichworte sind mir bei meiner Recherche schon untergekommen und ich werde sie auch im weiteren verwenden. Ich denke, dass es in Richtung eines Javascript-Frameworks gehen wird.

Folgendes soll möglich sein bzw. muss berücksichtigt werden:

• keiner soll Zugriff auf den eigentlichen Business-Code haben bzw. diesen sehen (außer mir natürlich)
• lokale Daten sollen ausgewählt werden können und müssen dann wohl in die Browser-Sandbox übernommen werden können (ist über HTML5 implementiert) sowie auch wieder lokal abgelegt werden können (per "Download" aus Sandbox nach lokal?) --> eventuell schon ein Knackpunkt
• die Bearbeitungen sollen komplett auf dem Client erfolgen (Einsatz von Regex usw.)
• da clientseitig ausgeführt wird, wird's wohl nicht Javascript/Typescript gehen
• ob SPA oder sonst ist nicht der Schwerpunkt (viel UI-Kram ist eh nicht erhalten) - wird sich zwangsweise aus der mir noch unbekannten Technologie ergeben
• einen entsprechenden Webserver muss ich dann wohl auch aufsetzen - oder gibt's hier schon "fertige" Angebote (also wie sowas wie vorkonfigurierte Images)?

Vielen Dank für Eure Hilfe und "Einnordung"

 

[konkretor]

Definiere große Text Dateien, 5 MB waren vor 30 Jahren auch sehr groß.

 

[alexber]

Stimmt - dem war damals so. Heute mache ich aus dem "MB" mal "GB". Also 5 GB, ggf. auch mehr - wahrscheinlich aber meist weniger. Wäre das sehr wichtig?

 

[Dalek]

Das muss eigentlich eine SPA sein, wenn die ganze Logik Client-seitig sein soll. Oder zumindest musst du so viel von dem Code in JS haben das ich gleich auf eine SPA setzen würde, bei diese sehr spezifischen Anforderungen.

Bei 5 GB pro File musst du aufpassen das du es nie komplett in den Speicher lädst, aber ansonsten gibt es da kein grundsätzliches Problem sowas in Javascript direkt im Browser zu machen.

Wenn das auf dem Client passieren soll, kannst du aber den Code auch nicht wirklich geheim halten. Du kannst den etwas obfuscaten, aber mehr nicht. Ich würde einfach Javascript/Typescript nehmen, theoretisch geht aber auch was anderes das zu WASM kompiliert werden kann.

Das Backend ist in diesem Fall praktisch egal, da kannst du alles nehmen. Einfach einen klassischen Webserver wie Apache und die HTML + JS ausliefern müsste da gehen.

 

[netzgestaltung]

Du kannst mit JS auch private Funktionen bauen die zur Laufzeit im Browser nicht erkennbar sind.
(Stichwort Revealing Modules).

Mittels minifier wird es dann schwierig(aber nicht unmöglich), dein JS reverse zu enginieren (aber schwieriger als zb eine jar datei auszulesen).

Daten im Browser kannst du mittels localstorage oder sessionstorage per JS speichern ohne Server/DB kommunikation. Von dort kann der user mit der passenden JS Funktion auch einen "Download" machen.

 

[BeBur]

keiner soll Zugriff auf den eigentlichen Business-Code haben bzw. diesen sehen (außer mir natürlich)

Das geht nicht. Entweder es passiert extern auf (d)einem Server oder der Nutzer kann Zugriff auf den Code erhalten. Wenn das ganze beim Nutzer passieren soll, dann kann er immer auch Zugriff auf den Code erhalten.

 

[alexber]

Vielen Dank erstmal für die bisherigen Antworten. Also für die Funktionalität definitiv Javascript bzw. ein Javascript-Framework. Mit der Einschränkung eines nicht/eingeschränkt schützbaren Codes.

• Also ist der Code auch bei einem React mit Node oder Angular oder Vue oder ... einsehbar? Und wenn also nicht direkt, dann über den Entwicklermodus der Browser?
• Wenn ich es richtig recherchiert hatte, ist dem Webbrowser die Arbeit in einem lokalen Verzeichnis nicht erlaubt. Deshalb wohl die Sandbox. In die lädt der Benutzer vom lokalen Verzeichnis quasi per "Upload" und kann in ein lokales Verzeichnis wieder zurückspielen per "Download"? Je nach Dateigröße muss also auch entsprechender physischer Platz vorhanden sein (Quelle, Sandbox, Ziel).
• Zur Anmerkung mit "5 GB nicht komplett in Speicher laden": Hat das mit localstorage und sessionstorage zu tun oder allgemein mit der Tatsache, dass die meisten Arbeiten im Hauptspeicher laufen?

 

[kim88]

Also ist der Code auch bei einem React mit Node oder Angular oder Vue oder ... einsehbar? Und wenn also nicht direkt, dann über den Entwicklermodus der Browser?

Code der im Browser läuft ist grundsätzlich immer einsehbar, da der Browser ja den Code herunterladen muss um ihn ausführen zu können.
Bei React & Co ist kann auch der Serverteil, also das Teil das auf dem Server läuft JavaScript sein -> diese Teil ist nicht einsehbar. (muss aber nicht man kann auch reines HTML ausliefern und alles Client-seitig machen).

Wenn man React&Coe (ich bin Fan von vue.js) Serverseitig nutzen will muss man sich vorher Gedanken um das Hosting machen. ein 0815 Webhoster lässt in der Regel kein Node JS auf dem Server zu, und kann solche Seiten nicht hosten.

Zur Anmerkung mit "5 GB nicht komplett in Speicher laden": Hat das mit localstorage und sessionstorage zu tun oder allgemein mit der Tatsache, dass die meisten Arbeiten im Hauptspeicher laufen?

Wenn ich die Spezifikationen richtig im Kopf habe kann ein localStorage maximal 5MB gross sein.
Ein session.Storage kann so gross sein wie der Arbeitsspeicher vom Client.

 

[Dalek]

Ist egal welches Framework du nimmst, am Ende ist das alles Javascript das im Browser läuft, und daher auch sichtbar für den Benutzer ist. Allzu viele Gedanken würde ich mir da nicht machen, wenn das minimiert und obfuscated ist dann ist das schon recht nervig da zu verstehen wie das funktioniert.

Der Browser kann nicht einfach auf lokale Dateien zugreifen. Es gibt da eine neue Chrome-only API die das begrenzt erlaubt, aber ich hab mir die noch nicht wirklich angesehen. Was du machen kannst sind ganz normale Formularelemente mit Dateiupload. Die öffnen den Dateibrowser und der Benutzer kann eine Datei auswählen. Mit Libraries kannst du da auch einfach Drag&Drop machen. Auf diese Datei kannst du dann mit Javascript zugreifen und die verarbeiten.

Die File APIs können streamen, d.h. du bekommst dann einfach Stücke der Datei und musst die verarbeiten. Die Datei wird dabei nicht ganz in den Speicher geladen, dann hast du keine Probleme mit Resourcen. Localstorage und Sessionstorage würde ich gar nicht verwenden bei den Dateigrößen, da werden typische Browser einfach nein sagen. Die brauchst du aber nicht um lokale Dateien zu verarbeiten.

Bei React & Co ist kann auch der Serverteil, also das Teil das auf dem Server läuft JavaScript sein -> diese Teil ist nicht einsehbar. (muss aber nicht man kann auch reines HTML ausliefern und alles Client-seitig machen).

Das ist kein Muss, kann man so machen aber man kann auch jedes andere Backend nehmen. Und nach der Beschreibung bisher sehe ich nicht das es überhaupt irgendein aktives Backend braucht, bisher ist alles auf der Client-Seite.

 

[kim88]

@Dalek

Das wollte ich mit meinem Text in der Klammer ausdrücken. Kann, nicht muss.

 

[alexber]

So langsam wird vieles klarer.

- Ist es tatsächlich möglich, die Javascript-Frameworks auf "clientseitig" einzustellen und somit das Hosting zu umgehen? Ich habe die verfügbaren Beschreibungen so gedeutet, das das Besondere und eben Ausschließliche wie bei node.js das serverseitige Rendering ist.

@Dalek

- Auch wenn ich Stück für Stück Streamen kann, muss ich die Ergebnisse doch irgendwo hin zwischenspeichern? Und bin dann auf entsprechend ggf. große Speichermöglichkeiten angewiesen. Oder "greift" dann eben der Arbeitsspeicher? Wenn das nicht so geht und ich nur mit 5 MB rumhantieren kann, ist alles gestorben. Oder ich habe Glück und einer der Browser erlaubt mir mehr (Arbeitsspeicher, Festplatte).

Vielen Dank

 

[andy_m4]

Warum muss es eigentlich unbedingt eine Web/Browser-Anwendung sein?
Weil damit fängst Du Dir natürlich viele Probleme ein die Du dann umständlich lösen musst (bzw. teilweise auch gar nicht zu lösen sind). Vor dem Hintergrund wäre es vielleicht eine Überlegung wert das irgendwie eher als klassisches Programm zu lösen.

 

[alexber]

Die Idee ist, dass auch andere dieses Werkzeug benutzen können. Und aufgrund der iterativen Entwicklung stets von der aktuellen Version partizipieren, ohne ständig Produktaktualisierungen herunterladen zu müssen. Eine einzige zentral zu wartende Applikation ist dann einfacher zu handhaben als eine klassische Anwendung und ich bin unabhängig vom Betriebssystem des Anwenders.

 

[andy_m4]

Und aufgrund der iterativen Entwicklung stets von der aktuellen Version partizipieren, ohne ständig Produktaktualisierungen herunterladen zu müssen.

Das hat natürlich potentiell auch Nachteile. Zum Beispiel bei Bugs, wenn eine bisher funktionierende Applikation dann plötzlich nicht mehr funktioniert.

und ich bin unabhängig vom Betriebssystem des Anwenders.

Gut. Plattformunabhängig programmieren ist ja heutzutage kein Hexenwerk mehr.

Letztlich nützen Dir aber alle Vorteile einer Web-Anwendung nix, wenn diese nicht zu realisieren ist. :-)

Wobei es ja nur zwei Knackpunkte gibt. Der Dateizugriff (den Denkansatz mit dem den klassischen Upload/Download-Mechanismus zu nutzen ganz spannend finde ob es möglich ist statt das zum Webserver zu schicken lokal irgendwie zumindest im RAM zu "empfangen"). Aber ich dachte immer dafür gibts die Filesystem-API. Hab aber selbst noch nix damit gemacht, um das einschätzen zu können.

Der zweite Knackpunkt ist der Schutz des Source-Codes. Das ließe sich über WebAssembly (WASM; wurde hier ja auch schon genannt) machen. Da wird der Code nach Bytecode übersetzt den der Browser direkt ausführen kann. Wie gut dadurch der Bytecode geschützt wird (bezüglich Disassemblierung) ist halt immer die Frage, aber es ist deutlich besser als bei Javascript (wobei man auch hier mit Obfuscation-Tools Verwirrung stiften kann).

 

[BeBur]

- Ist es tatsächlich möglich, die Javascript-Frameworks auf "clientseitig" einzustellen und somit das Hosting zu umgehen?

Nein, nicht im engeren Sinne. Wie soll sonst ein Nutzer zu dir finden bzw. deinen Code erhalten? Er gibt doch eine URL ein und die liefert dann dein Javascript-Projekt aus. Dafür braucht es schon Hosting.
Was du aber nicht zwangsläufig brauchst ist nodejs/react/vue/... irgendein Web-Framework willst du am Ende haben, aber für einen Prototypen kannst du auch auf alles verzichten und einfach statisches HTML+Javascript ausliefern. Das ist dann sehr nah an dem, was du schon kennst, selbst PHP brauchst du nicht zwangsläufig, nur HTML, CSS und eben dein JS Code wegen dem es das Projekt überhaupt gibt.

Du darfst dann nur nicht die Transition "vergessen", sonst hackst du dir nachher händisch alles mögliche zusammen und baust nen Haufen Fehler und Probleme ein (im schlimmsten Fall sowas wie ein Kontaktformular oder gar ein User-Login).

 

[EyeSeaTee]

Das muss eigentlich eine SPA sein, wenn die ganze Logik Client-seitig sein soll.

SPA hat doch damit überhaupt nichts zu tun!

 

[Dalek]

Ist es tatsächlich möglich, die Javascript-Frameworks auf "clientseitig" einzustellen und somit das Hosting zu umgehen? Ich habe die verfügbaren Beschreibungen so gedeutet, das das Besondere und eben Ausschließliche wie bei node.js das serverseitige Rendering ist.

Die modernen Javascript Frameworks wie React und Vue sind nur clientseitig, man kann dann auch node.js auf dem Server verwenden, aber das ist optional.

Auch wenn ich Stück für Stück Streamen kann, muss ich die Ergebnisse doch irgendwo hin zwischenspeichern? Und bin dann auf entsprechend ggf. große Speichermöglichkeiten angewiesen. Oder "greift" dann eben der Arbeitsspeicher? Wenn das nicht so geht und ich nur mit 5 MB rumhantieren kann, ist alles gestorben. Oder ich habe Glück und einer der Browser
erlaubt mir mehr (Arbeitsspeicher, Festplatte).

Die Datei lesen ist kein Problem, das habe ich schon gemacht auch für Dateien die hunderte MB groß sind. Es ist halt besser wenn du sie nicht komplett im Hauptspeicher behältst, aber richtig ein Problem wird das erst mit einigen Gigabyte.

Download aus JS habe ich keine direkte Erfahrung ob man das streamen kann. Kommt jetzt aber auch darauf an was du machst, und ob die Ausgabe ähnlich groß ist wie die Eingabedatei.

Im Browser hast du erstmal nur den Arbeitspeicher, sowas wie Local Storage ist nicht für diese Datenmengen gedacht.

SPA hat doch damit überhaupt nichts zu tun!

Ich habs ja noch dazu geschrieben, ist nicht zwingend aber wenn man so viel auf den Client legt und evtl. gar kein aktives Backend braucht dann passt eine SPA hier besser.

 

[###Zaunpfahl###]

keiner soll Zugriff auf den eigentlichen Business-Code haben bzw. diesen sehen (außer mir natürlich)

Und warum? Soll damit die Sicherheit erhöht werden?

 

[alexber]

@###Zaunpfahl###

Nein - nicht die Sicherheit. Ich möchte einfach nicht, dass mein Code einfach so ohne mein Zutun kopiert werden kann.

 

[JP-M]

Wenn die "Nicht Einsehbarkeit" so wichtig ist, dann bleibt dir aber bei dem favorisierten Technologiestack "Webanwendung" nur die Möglichkeit doch einen Server einzubinden, auf dem die wirklich wichtige Geschäftslogik ausgeführt wird oder auf Frameworks / Technologien wie Webassembly / Electron / Node-Webkit umzusteigen, um die Hürde zum Mitlesen möglichst hoch zu legen.

Wenn Code, in egal welcher Form auf einem Client angekommen ist, ist es am Ende nur eine Frage der Zeit und des Wollens, wenn wirklich jemand da ran kommen möchte ;-).