Ich bin jetzt seit einigen Monaten mit Python unterwegs und habe seit Anfang des Jahres an einem persönlichem Projekt gearbeitet. Es handelt sich um eine cli Anwendung mit direkten Query Anfragen an eine lokale MySQL Datenbank. Ich habe viel gelernt und bin froh die Applikation jetzt fertig zu haben. Es ist ein Saatkalender mit angebundener Pflanzendatenbank.
Ich möchte das Programm unbedingt weiter entwickeln und damit einem Refactoring unterziehen. Es soll weniger Tabellen und mehr Grafiken beinhalten und auch von anderen Personen genutzt werden können. Eine Benutzerverwaltung habe ich schon implementiert.
Jetzt meine Frage: ich liebäugle mir QT (Mit Designer) anzusehen und damit die nächste Stufe meiner bisherigen CLI Anwendung grafisch zu erklimmen. Habe da schon ganz nette Sachen gesehen, die ich gut gebrauchen kann. Jetzt möchte ich aber dass andere Nutzer das Programm auch nutzen und an zentralen Daten partizipieren können. Eigentlich spricht das Jetzt für eine Webanwendung. Soweit ich verstehe ist QT aber für lokale Applikation gedacht. Ich müsste also jetzt meine Lokal App mit einer zentralen Datenbank verbinden. Das macht man aber nicht direkt. Hier fängt mein Unwissen an und würde mich über ein paar klärende Schlagworte freuen, damit ich mich dann in die Materie einarbeiten kann. Ich werfe mal Flask REST API ins rennen. Bin ich damit auf dem richtigen Weg ?
Oder doch alles neu und mit Django eine reine Webentwicklung erstellen . ? Da würde mir aber auf anhieb der flexiblere und modernere GUI Ansatz wie mit QT aber fehlen oder bin ich jetzt noch tiefer im Wald ? Zaubert man mit DJANGO auch GUIs die nicht nach schnöder Tabellen Webseite aussehen, wie mit QT? Wobei ich nochmal denn DESIGNER anspreche. Finde das schon sehr fein , sich ne GUI zu bauen und 100te Zeilen von Code sich dann generieren zu lassen.
Ich weiß ich bekomme mit meinen Anfänger Fragen jetzt einen auf den Deckel. Aber wo anfangen ……
VG Gomez
.
Eine Frage der Technologien
Du überbewertest die Nützlichkeit des Designers, und unterschätzt die Komplexität einer GUI-Anwendung. Auch das paketieren und ausrollen an Benutzer will bedacht werden, und was passiert, wenn wer mit einem alten Client auf eine neue Version der REST Schnittstelle zugreift? Geht das, oder zwingst du erst zum Update? Dann gibt es um Qt Lizenz-Fragen, weil die schon hart pushen, das man ihnen Geld zahlt.
Auch die Modernität und Flexibilität von GUIs vs Web bewerte ich andersherum. Anwendungen wie slack, discord, Facebook etc pp sind im Grunde Browser, die man installiert. Die Grafik-Engines von Chrome & Co sind hoch beeindruckend und fähig. Frameworks wie react oder vue sind die speerspitze des Interaktiven Designs. Qt versucht da mit QML sogar etwas davon nachzuholen.
Ich würde darum ganz klar zur Webanwendung raten. Und wahrscheinlich Django, ja.
Was nicht heißen soll, dass Qt nicht gut, und der Designer nicht hilfreich sind. Das ist - wenn gui, und man Plattform-unabhängig sein will - schon die beste Wahl. Aber heutzutage ist Web First schon der Weg.
Wenn dich das alles nicht überzeugt: ja, Rest mit flask ist eine gute Wahl für ein backend.
Auch die Modernität und Flexibilität von GUIs vs Web bewerte ich andersherum. Anwendungen wie slack, discord, Facebook etc pp sind im Grunde Browser, die man installiert. Die Grafik-Engines von Chrome & Co sind hoch beeindruckend und fähig. Frameworks wie react oder vue sind die speerspitze des Interaktiven Designs. Qt versucht da mit QML sogar etwas davon nachzuholen.
Ich würde darum ganz klar zur Webanwendung raten. Und wahrscheinlich Django, ja.
Was nicht heißen soll, dass Qt nicht gut, und der Designer nicht hilfreich sind. Das ist - wenn gui, und man Plattform-unabhängig sein will - schon die beste Wahl. Aber heutzutage ist Web First schon der Weg.
Wenn dich das alles nicht überzeugt: ja, Rest mit flask ist eine gute Wahl für ein backend.
-
sls
- User
- Beiträge: 480
- Registriert: Mittwoch 13. Mai 2015, 23:52
- Wohnort: Country country = new Zealand();
@gomez72: die Applikation als Webanwendung umzubauen ist schon der richtige Ansatz wenn du mehrere Benutzer auf eine gemeinsame Datenbasis zugreifen lassen willst. Die Applikation sollte dann sinnigerweise von einem Webserver bereit gestellt werden der aus dem Internet erreichbar ist. Statt einer GUI-Applikation würde man dann aber auf eines der Webframeworks wie eben Django oder Flask setzen (wobei Django nochmal deutlich umfangreicher und der Einstieg etwas schwieriger ist), auch sollte man berücksichtigen dass du dann für die Darstellung (Frontend) HMTL/CSS (ggf. auch Javascript)-Kenntnisse benötigst. Hier gibt es mit Bootstrap einen seichteren Einstieg und viele Vorlagen die man verwenden kann, um nicht direkt beim Urschleim beginnen zu müssen.
Neben obigen Technologien wirst du dann einen Webprovider benötigen der dir im besten Fall ein Rundumpaket zur verfügung stellt, so dass du dich nicht um das ganze Setup (Netzwerk, Infrastruktur etc.) kümmern musst, sondern das Front- und Backend entwickeln kannst. Damit nicht jeder Hinz und Kunz die Daten manipulieren kann, wirst du eine Authentifizierung implementieren und dich grundsätzlich mit dem Thema Security beschäftigen müssen.
Das ist eine Tonne Stoff, aber imho gut machbar, zumal alle gängigen Technologien frei verfügbar sind und man lokal das ganze entwickeln kann, ehe man es dann ans Netz bringt.
Neben obigen Technologien wirst du dann einen Webprovider benötigen der dir im besten Fall ein Rundumpaket zur verfügung stellt, so dass du dich nicht um das ganze Setup (Netzwerk, Infrastruktur etc.) kümmern musst, sondern das Front- und Backend entwickeln kannst. Damit nicht jeder Hinz und Kunz die Daten manipulieren kann, wirst du eine Authentifizierung implementieren und dich grundsätzlich mit dem Thema Security beschäftigen müssen.
Das ist eine Tonne Stoff, aber imho gut machbar, zumal alle gängigen Technologien frei verfügbar sind und man lokal das ganze entwickeln kann, ehe man es dann ans Netz bringt.
When we say computer, we mean the electronic computer.
Nur der Vollständigkeit halber sei darauf hingewiesen, daß relationale Datenbank-Managementsysteme wie PostgreSQL und MySQL natürlich feingranulare Authentifizierungs- und Autorisierungmöglichkeiten und auch verschlüsselte Verbindungen mit zertifikatsbasierter Benutzerauthentifizierung mittels Transport Layer Security (TLS, ehemals SSL) unterstützen. Das heißt: jeder FatClient erhält ein Zertifikat, das von einer eigenen Certificate Authority (CA) erstellt wurde, und die Datenbank-Serversoftware wird so konfiguriert, daß sie nur Zugriffe mit TLS und einem von der eigenen CA signierten Client-Zertifikat zuläßt. Optional könnten zusätzlich für eine echte Zwei-Faktor-Authentifizierung die Credentials (Benutzername und Paßwort) vom Client abgefragt werden -- das wäre aus Sicherheitssicht dann der aktuelle Stand der Technik, in der Umsetzung aber ziemlich aufwändig.
Erschwerend kommt hinzu, daß Netzwerk- und insbesondere Internetverbindungen häufig nicht besonders stabil und performant sind. Webbrowser sind daher häufig sehr fehlertolerant und ihre Benutzer sind, sagen wir mal, entsprechenden Kummer gewöhnt. Bei einem FatClient ließe sich zwar eine ähnliche Fehlertoleranz einbauen, aber die Erwartungshaltung der Benutzer ist eine andere, und dieser Erwartungshaltung ließe sich nur mit weiteren hohen Aufwänden wie Caching und Synchronisation und auch dann nur teilweise begegnen.
Und dann kommt noch ein dritter Punkt hinzu: FatClients müssen auf jeden Clientrechner deployt und auf jedem Clientrechner gepflegt und gewartet werden, während es im Falle von Web First nur eine Installation auf dem Webserver und damit auch nur eine Instanz gibt, die deployt, gepflegt und gewartet werden muß. Dies ist einer der wichtigsten Gründe dafür, weswegen sich der Web First-Ansatz aktuell durchzusetzt -- und ein ähnlicher Grad der Sicherheit läßt sich auch damit realisieren, ist dann allerdings kaum weniger aufwändig.
Erschwerend kommt hinzu, daß Netzwerk- und insbesondere Internetverbindungen häufig nicht besonders stabil und performant sind. Webbrowser sind daher häufig sehr fehlertolerant und ihre Benutzer sind, sagen wir mal, entsprechenden Kummer gewöhnt. Bei einem FatClient ließe sich zwar eine ähnliche Fehlertoleranz einbauen, aber die Erwartungshaltung der Benutzer ist eine andere, und dieser Erwartungshaltung ließe sich nur mit weiteren hohen Aufwänden wie Caching und Synchronisation und auch dann nur teilweise begegnen.
Und dann kommt noch ein dritter Punkt hinzu: FatClients müssen auf jeden Clientrechner deployt und auf jedem Clientrechner gepflegt und gewartet werden, während es im Falle von Web First nur eine Installation auf dem Webserver und damit auch nur eine Instanz gibt, die deployt, gepflegt und gewartet werden muß. Dies ist einer der wichtigsten Gründe dafür, weswegen sich der Web First-Ansatz aktuell durchzusetzt -- und ein ähnlicher Grad der Sicherheit läßt sich auch damit realisieren, ist dann allerdings kaum weniger aufwändig.