PBExpress - Lightweight FastCGI Framework

Anwendungen, Tools, Userlibs und anderes nützliches.
Benutzeravatar
TroaX
Beiträge: 659
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Pop_OS! | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Pop_OS!
Wohnort: NRW
Kontaktdaten:

PBExpress - Lightweight FastCGI Framework

Beitrag von TroaX »

Nabend,

ich war Krankheitsbedingt eine ganz ganz ganz lange Weile nicht mehr hier. Doch so langsam wird es mal wieder Zeit ^^

Ich arbeite Momentan an einem Framework, welches die Arbeit mit FastCGI deutlich erleichtern soll. Ich habe noch nicht lange daran gearbeitet, bin aber mit den ersten Ergebnissen schon sehr zufrieden. Zuerst habe ich das Routing implementiert und das erfassen des Requestbodys bzgl. Formulardaten umgesetzt. Das Framework soll allerdings noch viel viel größer werden und neben dem Kernmodul auch viele Nebenläufige Module bekommen.

Den Code zusammen mit einem Beispiel sowie Screenshots gibt es bei Github: https://github.com/reVerBxTc/PBExpress

Hier ein Examplacode für die Nutzung:

Code: Alles auswählen

; ---- Load The Framework ---- ;
IncludeFile "pbexpress.pb"

; ---- Init CGI ---- ;
If Not InitCGI()
  End
EndIf

; ---- Init FastCGI ---- ;
If Not InitFastCGI(2005)
  End
EndIf

; ---- A Demonstration Page-Procedure ---- ;
Procedure DefaultTest(Map Request.s(),Map Post.s())
  WriteCGIHeader(#PB_CGI_HeaderContentType, "text/html", #PB_CGI_LastHeader)
  ReturnStr.s = "<h2>Header-Data</h2><pre>"
  ForEach Request()
    ReturnStr + MapKey(Request()) + ": " + Request() + "<br>"
  Next
  ReturnStr + "</pre>"
  If MapSize(Post()) > 0
    ReturnStr + "<h2>Post-Data</h2><pre>"
    ForEach Post()
      ReturnStr + MapKey(Post()) + ": " + Post() + "<br>"
    Next
    ReturnStr + "</pre>"
  EndIf
  WriteCGIStringN(ReturnStr)
EndProcedure  

; ---- The PBExpress Options ---- ;
PBExpress::SetDefaultPage(@DefaultTest()) ; Set Default Page-Procedure
PBExpress::AddRouteKey("mod")             ; Set a Parameterkey for Routings
PBExpress::AddRouteKey("action")          ; A Second one
PBExpress::AddRoute("mod=users&action=view",@DefaultTest()) ; Create a Route with Values to the defined Keys (In the Routingtable the Pointer saves under the combined Values ex. usersview)
PBExpress::RunServer()                    ; Execute the Server
Und noch einmal Screenshots der Rückgaben des Beispiels.
Get:
Bild

Post:
Bild

Das ganze ist übrigens noch nicht für die Nutzung im Produktivbetrieb geeignet. Ich stehe noch ganz ganz weit am Anfang. Trotzdem wollte ich das bisherige Ergebnis einmal vorstellen.

PS: Der Name PBExpress wurde von express.js abgeleitet, da ich mich bzgl. dem Routing dort ein wenig inspirieren lassen habe.

CHANGELOG:
18.12.2016 - 14:27:
  • EnableExplicit
  • Optionen für die maximale Content-Länge seitens des Users eingefügt
  • Optionen für die Datenstruktur der übertragenden Daten eingefügt (JSON, Post, Raw-String)
  • Bessere Überprüfung der Parameter für den Request
  • Die Routen werden jetzt über ein MD5 Hash als Schlüssel gespeichert und in diesem sind auch die Parameter-Schlüssel selbst enthalten, um Kollisionen vorzubeugen
Gruß TroaX :)
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Pop_OS!
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Pop_OS!
NAS: Fritz.Box :lol:
Coding: Purebasic 6.04 | PHP | HTML | CSS | Javascript
Benutzeravatar
dige
Beiträge: 1179
Registriert: 08.09.2004 08:53

Re: PBExpress - Lightweight FastCGI Framework

Beitrag von dige »

Danke und willkommen zurück an Bord! :-)

Bin gespannt was aus deinem Framework noch wird. Momentan mache ich einiges viel mit CGI, dass lässt sich so wunderbar einfach in Pb2Web als Serverkomponente integrieren.

Ciao dige
"Papa, mein Wecker funktioniert nicht! Der weckert immer zu früh."
Benutzeravatar
TroaX
Beiträge: 659
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Pop_OS! | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Pop_OS!
Wohnort: NRW
Kontaktdaten:

Re: PBExpress - Lightweight FastCGI Framework

Beitrag von TroaX »

Danke :)

Naja CGI ist da nicht ganz so mein Fall. Bei FastCGI gefällt mir eben, das der Prozess durchweg im Hintergrund läuft und Ready-for-Request ist. Außerdem bleibt die Datenbankverbindung konstant aufrecht. ;)

Ich habe mit dem Framework noch so einiges vor. Der aktuelle Status gefällt mir schon sehr. Es kommt aber ins Basismodul noch ein Cookie-Handling, die Response soll optimiert werden. Mein Ziel ist es, neben dem Baismodul keine PB eigenen CGI-Prozeduren verwenden zu müssen. Als Nebenläufige Module sind dann noch so Dinge wie Template-Engine, Security-Modul (Passwort Hash and Verify, XSPF usw.), Session-Modul, ein auf JSON basierender Formulargenerator, eine dokumentorientierte Datenbank mit RAM-Caching usw. geplant. Allerdings wird das meiste eher in Richtung FastCGI optimiert sein.

Aber das wichtigste ist schonmal drin. Das Routen voN Request's auf Page-Prozeduren und die einfache Möglichkeit, direkt auf die Daten zuzugreifen, die der Server vom Client bekommt.
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Pop_OS!
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Pop_OS!
NAS: Fritz.Box :lol:
Coding: Purebasic 6.04 | PHP | HTML | CSS | Javascript
Benutzeravatar
HeX0R
Beiträge: 2954
Registriert: 10.09.2004 09:59
Computerausstattung: AMD Ryzen 7 5800X
96Gig Ram
NVIDIA GEFORCE RTX 3060TI/8Gig
Win10 64Bit
G19 Tastatur
2x 24" + 1x27" Monitore
Glorious O Wireless Maus
PB 3.x-PB 6.x
Oculus Quest 2
Kontaktdaten:

Re: PBExpress - Lightweight FastCGI Framework

Beitrag von HeX0R »

TroaX hat geschrieben:[...]Außerdem bleibt die Datenbankverbindung konstant aufrecht. ;)
[...]
Dieses Argument hört man ja immer mal wieder, aber mal ganz ehrlich:
Wie lange kann es wohl dauern sich zu einer Datenbank zu verbinden?
I.d.R. liegt der Datenbankserver doch auch auf dem gleichen Server und man sollte vernachlässigbar schnell verbunden sein.

Ich hatte auch erst mit FastCGI experimentiert, und bin dann auf CGI übergegangen, weil ich keinen großartigen Vorteil erkennen konnte (in meinem speziellen Fall jetzt, wohlgemerkt).
Mal abgesehen davon, dass mein Bottleneck das abartig langsame Stringhandling von PB war, da musste ich dann auch erst mal draufkommen, aber das ist eine andere Geschichte...
Benutzeravatar
TroaX
Beiträge: 659
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Pop_OS! | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Pop_OS!
Wohnort: NRW
Kontaktdaten:

Re: PBExpress - Lightweight FastCGI Framework

Beitrag von TroaX »

Es kommt eben immer auf die Infrastruktur an.

Aber es gibt auch jede Menge andere Argumente, die für FastCGI sprechen. Du hast ja selbst geschrieben, das die String-Funktionalität von PB "abartig" langsam ist (wobei ich noch jede Menge andere Sprachen und Interpreter kenne, die noch viel lahmer sind). Durch den durchweg laufenden Prozess lässt sich vieles überaus einfach optimieren. Zum Beispiel eine Template-Engine kann bei Prozess-Start bereits die Templates verarbeiten und Performance-Freundlich im RAM cachen. Somit wird diese Arbeit garnicht erst bei den Requests ausgeführt.

Man kann Sessions in einer Map ablegen und somit das Einlesen von Dateien oder einen zusätzlichen überflüssigen Datenbankrequest pro Aufruf sparen. Man kann Durch eine Datenbankabstraktion sogar Datensätze im RAM vorhalten. Das Optimierungspotenzial ist riesig, da du durch den persistenten Prozess den gesamten Arbeitsspeicher zum Cachen hast und Routinen die Abhandlung von Requests vorbereiten können.

Klar kannst du einen BBCode-Parser oder ein Äquivalent zu PHP's HTMLSpecialChars nicht aus der Seiten-Routine nehmen. Aber das ganze Werk drumherum. Die ganze Metaaufgaben sozusagen, kannst du meist vorab abarbeiten.

Du kannst weitere Threads zur Überwachung einsetzen. Damit könntest du zum Beispiel Templates im laufenden Betrieb wechseln, da ein zusätzlicher Thread überprüft, ob die Dateien aktualisiert wurden und ob die Engine das ganze neu verarbeiten muss.

Da gibt es so unfassbar viele Möglichkeiten, die es mit CGI nicht gibt. Denn nach jedem Request geht der Prozess der CGI-Anwendung und somit auch alles im RAM verloren.

Generell also sagen, das FastCGI keine Vorteile bringt, kann man nicht. Es kommt immer auf die Anforderungen und die Infrastruktur an. ;)
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Pop_OS!
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Pop_OS!
NAS: Fritz.Box :lol:
Coding: Purebasic 6.04 | PHP | HTML | CSS | Javascript
Benutzeravatar
TroaX
Beiträge: 659
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Pop_OS! | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Pop_OS!
Wohnort: NRW
Kontaktdaten:

Re: PBExpress - Lightweight FastCGI Framework

Beitrag von TroaX »

Kurze aktuelle Wasserstandsmeldung

Das Modul hat 2 Prozeduren für das Cookie-Handling bekommen. Eine zum setzen und eine zum Abfragen. Gerade die zum setzen ist wichtig, da man über die CGI-Funktionen den SetCookie-Header nur mit einem einzelnen String definieren kann. Die Prozedur des Frameworks erzeugt ihn durch ein paar Parameter und bastelt für den Header im Hintergrund den passenden String zusammen. Die Attribute Secure und HTTPOnly werden ebenfals unterstützt.

Desweiteren habe ich auch ein Sessionmodul auf Dateibasis im Test bzw. eine Prozedursammlung, die nach Erfolgreichen Tests in ein Modul umgewandelt wird. Aber auch hier gab es bisher mit dem Code keine Probleme. Ich habe mich mit JSON um Kopf und Kragen gekloppt, da ja die Funktionalitäten so dynamisch wie Möglich Einsetzbar sein sollen. Aber was für die eine Lösung ein Segen ist, ist für andere Lösungen ein Fluch. Die strikte Typisierung von Variablen, Maps, Listen und Arrays benötigen für eine umfangreiche Dynamik leider auch eine extrem Umfangreiche Abstraktion. Während zum Beispiel PHP seine Sessions als serialisiertes Array speichert (Welche dort vollkommen dynamisch sind), muss in einer so stark typsicheren Sprache mit Listen für jeden einzelnen Datentyp gearbeitet werden sowie eine Map mit Struktur, um eine Relation herzustellen. Das ist bei einer Dimension schon die Hölle. Man muss ja auch bedenken, das man für jeden Datentyp auch noch eine eigene Prozedur brauch, um das Ergebnis im richtigen Datentyp zu erhalten.

Ich habe diesen Versuch dann jetzt irgendwann begraben und beschlossen, den Datentyp String (da man dort fast alles an Informationen speichern kann) als einzigen Datentyp zu supporten. Ich habe ein eigenes Dateiformat gebastelt, das eine spezielle Auszeichnung hat. Zur Unterstützung verwende ich URLDecoder und URLEncoder. In der Session ist es also möglich, entweder einzelne Schlüssel-Wertpaare zu speichern oder unter einem Schlüssel eine ganze Liste an Werten zu setzen. Realisiert wird dies durch Trennzeichen, die per URLEncoder kodiert werden und somit in der gespeicherten Datei nur dann da sind, wenn an dieser Stelle etwas definiert wird. Das Zeichen > bedeutet Schlüssel verweist auf Inhalt, das + bedeutet "Und", deutet optisch eine Verknüpfung an, dient dem "Parser" aber als Trennzeichen für Datensätze. Der Paragraph § steht grundsätzlich direkt vor dem Schlüssel einer Liste und der Balken | trennt die einzelnen Listenwerte. Die Schlüssel dürfen nur Buchstaben und Zahlen beinhalten. Die Werte werden alle mit URLEncoder kodiert. So sieht eine Session-Datei zum Beispiel aus.

Code: Alles auswählen

test>Test1234+test2>Test6748392+Mocca>Chino+§testlist>Huhu|Huhu|Huhu|Huhu|Huhu|Huhu|Huhu
Dieses Vorgehen funktioniert extrem gut, obwohl es so banal einfach ist. In den Schlüsseln speichert man so Dinge wie Account-ID, Benutzername, gewisse Einstellungen etc. In einer Liste kann man zum Beispiel die Produkt-ID's eines Warenkorbs in einem Shop speichern.

Als nächstes kommt das Output-Handling. Was mir allerdings noch massive Kopfschmerzen bereitet ist das Thema Dateiupload. So wie es aussieht scheint die Bibliothek rund um FastCGI nicht alle Informationen über den Request auszuliefern. Und das macht die Handhabung sehr schwer.
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Pop_OS!
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Pop_OS!
NAS: Fritz.Box :lol:
Coding: Purebasic 6.04 | PHP | HTML | CSS | Javascript
Benutzeravatar
TroaX
Beiträge: 659
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Pop_OS! | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Pop_OS!
Wohnort: NRW
Kontaktdaten:

Re: PBExpress - Lightweight FastCGI Framework

Beitrag von TroaX »

Hohoho

Erst einmal allesn ein frohes Fest. Und pünktlich dazu habe ich nach einer sehr schmerzhaften Erkenntnis dem PBExpress-Modul auch noch das Outputhandling optimiert und und den Zugriff auf hochgeladene Dateien vereinfacht.

Neue Version ist also auf Github zu finden: https://github.com/reVerBxTc/PBExpress

Den Examplecode habe ich ebenfalls mal aktualisiert:

Code: Alles auswählen

EnableExplicit

; ---- Load The Framework ---- ;
IncludeFile "pbexpress.pb"

; ---- Init CGI ---- ;
If Not InitCGI()
  End
EndIf

; ---- Init FastCGI ---- ;
If Not InitFastCGI(2005)
  End
EndIf

; ---- A Demonstration Page-Procedure ---- ;
Procedure DefaultTest(Map Request.s(), Map Get.s(), Map Post.s(), Map Files.PBEFiles())
  PBExpress::SetCookie("DO_IT","RUN!",Date()+3600,#False,#True)
  PBExpress::Header(#PB_CGI_HeaderContentType, "text/html", #PB_UTF8 | #PB_CGI_LastHeader)
  Define ReturnStr.s
  ReturnStr = "<!DOCTYPE html>"
  ReturnStr + "<html lang="+Chr(34)+"de"+Chr(34)+">"
  ReturnStr + "<head>"
  ReturnStr + "<meta charset="+Chr(34)+"utf-8"+Chr(34)+">"
  ReturnStr + "<title>PBExpress Example</title>"
  ReturnStr + "</head>"
  ReturnStr + "<body>"
  ReturnStr + "<h2>Header-Daten</h2><pre>"
  ForEach Request()
    ReturnStr + MapKey(Request()) + ": " + Request() + "<br>"
  Next
  ReturnStr + "</pre>"
  ReturnStr + "<h2>Anzahl übergebene Daten</h2><pre>"
  ReturnStr + "GET: " + Str(MapSize(Get())) + "<br>"
  ReturnStr + "POST: " + Str(MapSize(Post())) + "<br>"
  ReturnStr + "Files: " + Str(MapSize(Files())) + "<br>"
  ReturnStr + "</pre>"
  ReturnStr + "</body>"
  PBExpress::Output(ReturnStr)
EndProcedure  

; ---- The PBExpress Options ---- ;
PBExpress::SetDefaultPage(@DefaultTest())                   ; Set Default Page-Procedure
PBExpress::AddRouteKey("mod")                               ; Set a Parameterkey for Routings
PBExpress::AddRouteKey("action")                            ; A Second one
PBExpress::AddRoute("mod=users&action=view",@DefaultTest()) ; Create a Route with Values to the defined Keys (In the Routingtable the Pointer saves under the combined Values hashed with MD5)

; ---- Start the Server ---- ;
PBExpress::RunServer()                                      ; Execute the Server
Mit der Option #PBExpress_OutputBuffer auf #True gesetzt werden alle Ausgaben über die Prozedur Output() in einen String Zwischengespeichert und erst nach Beendigung der Page-Procedure an den Browser übermittelt. Dadurch kann man an jeder Stelle (zum Beispiel bei einem Login) einen Cookie setzen, auch wenn bereits "eine Ausgabe erfolgte", da diese ja nicht schon an den Browser geschickt wurde. Die Funktion zum setzen des Headers ist allerdings nur ein Alias für WriteCGIHeader(), da diese ja sowieso nach Möglichkeit zuerst gesetzt werden muss. Aber dafür bleiben alle Schritte bzgl. des Requests in einem Modul.

Die Page-Procedures müssen mit 4 Maps angelegt werden (Siehe Example-Code). In diese Maps werden alle Request-Header (Request), alle URL-Parameter (Get), alle Formular-Daten (Post) und alle Datei-Informationen (Files) abgelegt. Files leitet sich aus einer Struktur ab, die aus 3 Variablen besteht. PBEFiles\Size.i gibt die Größe der Datei in Bytes an. PBEFiles\Buffer.i gibt die Speicheradresse des Puffern der Datei zurück und PBEFiles\Filename.s den Dateinamen. Den Dateityp muss man allerdings momentan noch aus dem Dateinamen mit GetExtensionPart() extrahieren, da irgendwie zwar bei mehreren Dateien die Dateien selbst hochgeladen werden, ich aber aus dem Buffer des Requests noch versuchen muss, den echten MIME-Type herauszuholen. Aber da suche ich noch nach einer Lösung. Denn wo zum Beispiel .png hinten dran steht, muss ja nicht zwingend .png drin sein ;)

Allen ein frohes Fest :)

NACHTRAG: Sessionmodul hinzugefügt: https://github.com/reVerBxTc/PBExpress/ ... session.pb
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Pop_OS!
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Pop_OS!
NAS: Fritz.Box :lol:
Coding: Purebasic 6.04 | PHP | HTML | CSS | Javascript
Benutzeravatar
TroaX
Beiträge: 659
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Pop_OS! | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Pop_OS!
Wohnort: NRW
Kontaktdaten:

Re: PBExpress - Lightweight FastCGI Framework

Beitrag von TroaX »

Nur eine kurze Zwischenmeldung.

Neben dem Sessionmodul habe ich jetzt auch noch ein kleines Security-Modul mit Passwort-Funktionen, String-Generatoren und Escapings eingefügt.

Außerdem habe ich angefangen, die Dokumentation ins Github-Wiki einzupflegen. Ich werde ebenfalls noch einen News-Bereich ins Git einbauen und dort alle Neuerungen auflisten. Dieser Thread wird dann nur noch für Majors oder größere Status-Änderungen verwendet. Denn so langsam werden mir die Doppel-Drei-Vierfach Spam-Posts etwas peinlich :D Immer doof, wenn man in eine uninteressante Niesche schlägt, die für einen selbst aber extrem interessant ist :mrgreen:

GitHub: https://github.com/reVerBxTc/PBExpress
Wiki: https://github.com/reVerBxTc/PBExpress/wiki
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Pop_OS!
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Pop_OS!
NAS: Fritz.Box :lol:
Coding: Purebasic 6.04 | PHP | HTML | CSS | Javascript
Benutzeravatar
uweb
Beiträge: 461
Registriert: 13.07.2005 08:39

Re: PBExpress - Lightweight FastCGI Framework

Beitrag von uweb »

"Net gmotzt isch globt gnug."
Als Badenser distanziere ich mich zwar von den Schwaben aber ich muß zugeben, dass ich mich, wie wohl viele andere auch, in der Beziehung nur wenig abhebe.
Ich lese viel und schreibe wenig - eigentlich fast nur wenn ich Fehler finde oder mich eine Frage anspricht.
Im englischen Forum tauchen viel mehr "Super, danke!"-Nachrichten auf. Das nervt zwar beim Lesen, aber motiviert zum Teilen im Board.
Deswegen nachträglich:
Super, danke!
Ich werde das sicher in der Zukunft gut gebrauchen können.
Benutzeravatar
TroaX
Beiträge: 659
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Pop_OS! | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Pop_OS!
Wohnort: NRW
Kontaktdaten:

Re: PBExpress - Lightweight FastCGI Framework

Beitrag von TroaX »

Naja ich habe das auch eigentlich nicht so ernst gemeint. Ich bin ja froh, wenn keiner motzt :lol:

Wenn das ganze irgendwann an dem Punkt angekommen ist, wo ich mir das vorstelle, dann denke ich schon, das es dann zu Gesprächsstoff führen kann. Ich denke es ist aktuell noch sehr schwer vorstellbar, das es wirklich nützlich sein wird. Aber wenn ich mein ToDo nach und nach durch und alles auch vernünftig getestet habe, dann kann man auch viel mehr mit FastCGI anfangen. Es ist ja schön, das es FastCGI ins PureBasic geschafft hat. Nur wenn die ganzen anderen Tools fehlen, die für andere Sprachen und dem Web verfügbar sind (Node <- Express und Pakete aus dem NPM, Python <- Django, PHP usw.), dann macht es kein Sinn, da jeder den Kram erst einmal selbst implementieren muss.

Jetzt springe ich eben in die Bresche und mach es einmal offen für alle. Vielleicht möchten es dann auch ein paar mehr nutzen ;)

Danke für die Rückmeldung ;)

PS: Bei Fragen einfach Fragen. Ansonsten steht bisher alles, was in den Modulen drin ist auch im Wiki. Zwar noch nicht als Referenz. Aber in den Tutorials ;)
Nur für den Fall, das du damit etwas rumspielen willst.
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Pop_OS!
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Pop_OS!
NAS: Fritz.Box :lol:
Coding: Purebasic 6.04 | PHP | HTML | CSS | Javascript
Antworten