Modernisierung von Legacy-Anwendungen

[Phoenix]

Zitat:

Zitat von TigerLilly (Beitrag 1503393)

Aber vorher sind halt ein paar Grundsatzentscheidungen zu treffen:
- Als Web-Anwendung umsetzen? Native Anwendungen je Plattform? Saas?
- Welche Datenbank bei Stand-Alone bzw bei MultiUser
- Deployment und Installer bei Multiplatform
- Reporting und Ausgabe
- Import/Export/Replikation/Cloud
- Aktualisierung großer Datenmengen beim Kunden draußen

Und ja. Die Punkte waren als Ziele gedacht.

Datenbank: Für standalone / Single-User reicht in aller Regel Sqlite. Andernfalls kommts drauf an was an Lizenzkosten bezahlt werden soll ;)
Im Falle von OpenSource geht schon seit Jahren sehr vieles in Richtung PostgreSQL.

Oberfläche: Wir machen Grundsätzlich nur Web-basierte Anwendungen. Läuft wirklich problemlos überall: Link öffnen und App benutzen. That's it. In einigen Fällen installierbar als PWA (Progressive Web App), in den allerwenigsten Fällen und nur wenn es wirklich sein muss gewrapped in sowas wie Corodova.
Der Grund ist dass man mit einer einheitlichen Code-base wirklich alle Plattformen und vor allem auch alle Form-Faktoren (kleine hochkant Screens auf Smartphones über Tablet-Layouts bis hin zu Ultra-Wide Screens am Desktop) bedienen kann.
Schaut man sich z.B. Spotify an, Slack, MS Teams, Discord, Google Office, O365, Whatsapp, an (und viele viele andere Anwendungen), merkt man in den meisten Fällen noch nichtmal das das hintendran eigentlich alles nur Webseiten sind. Selbst 3D-Animationen mit 60FPS bekommt man damit problemlos hin.
Und wenn man ehrlich ist: Bei Geschäftsanwendungen ist es in aller Regel auch vollkommen egal wenn es Web-ig aussieht, hauptsache der Benutzer hat überall ein einheitliches Look & Feel und findet sich schnell zurecht.
Bei Consumer-Anwendungen sieht das allerdings ggf. anders aus, hier mag es unter Umständen sinnvoll sein, das man für eine möglichst breite Akzeptanz Plattform-Nativ aussehen will.

PWA's kann man bei Android auch einfach von der Webseite aus installieren. Will man das auf iOS in den Appstore bringen bleibt leider nichts anderes über als es zu Wrappen (z.B. Cordova), aber auch das ist in aller Regel kein Problem.

Die logische Schlussfolgerung daraus ist: Wenn man das Backend für das Web-Frontend sinnvoll ver-API-fiziert, ist es ein superkleiner Schritt das als SaaS bereitzustellen.

Sync-Thematiken mit lokalen Installationen sind meistens nur ein kleines technisches Detail (das haben wir auch schon etliche male gebaut).

[Maliko]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1503397)

Die sollen auf jeden Fall weg.
Damit bemerkst du nicht mehr wenn neue Meldungen rein kommen da ob nun 400 oder 410 Meldungen kommen keinen Mehr interessiern.

Wem sagst du dass? Leider sind der großteil der Meldungen vom Datenbanksystem (genauer gesagt den Transactions). Die komplette Datenbankanbindung läuft über ein System des ursprünglichen Entwicklers (wir haben das System damals übernommen) und ein umbau bei diesem betrifft ca 600 Units. Daher ignorieren wir diese momentan und sind stattdessen derzeit dabei eine komplett neue Datenbankanbindung via Aurelius zu schreiben und die Units nach und nach umzustellen. Das dauert halt leider, vor allem da wir ja auch noch neue Features entwickeln müssen.

[TigerLilly]

Zitat:

Zitat von Phoenix (Beitrag 1503403)

Oberfläche: Wir machen Grundsätzlich nur Web-basierte Anwendungen. Läuft wirklich problemlos überall: Link öffnen und App benutzen. That's it. In einigen Fällen installierbar als PWA (Progressive Web App), in den allerwenigsten Fällen und nur wenn es wirklich sein muss gewrapped in sowas wie Corodova.

Ja, das ist gut entschieden. Aber da reden wir nicht mehr von Delphi, oder was nutzt Ihr da für Front End und Back End/API?

[Bernhard Geyer]

Zitat:

Zitat von Maliko (Beitrag 1503405)

Wem sagst du dass? Leider sind der großteil der Meldungen vom Datenbanksystem (genauer gesagt den Transactions). Die komplette Datenbankanbindung läuft über ein System des ursprünglichen Entwicklers (wir haben das System damals übernommen) und ein umbau bei diesem betrifft ca 600 Units. Daher ignorieren wir diese momentan und sind stattdessen derzeit dabei eine komplett neue Datenbankanbindung via Aurelius zu schreiben und die Units nach und nach umzustellen. Das dauert halt leider, vor allem da wir ja auch noch neue Features entwickeln müssen.

OK. Also nicht ignoriert sondern es wird schon was gemacht.

[Phoenix]

Zitat:

Zitat von TigerLilly (Beitrag 1503406)

Zitat:

Zitat von Phoenix (Beitrag 1503403)

Oberfläche: Wir machen Grundsätzlich nur Web-basierte Anwendungen. Läuft wirklich problemlos überall: Link öffnen und App benutzen. That's it. In einigen Fällen installierbar als PWA (Progressive Web App), in den allerwenigsten Fällen und nur wenn es wirklich sein muss gewrapped in sowas wie Corodova.

Ja, das ist gut entschieden. Aber da reden wir nicht mehr von Delphi, oder was nutzt Ihr da für Front End und Back End/API?

Für die Frontend-Apps nehmen wir meistens Angular, aktuell wird aber auch viel nach Blazor nachgefragt.
Im Backend setzen wir auf .NET (Core) 5+, was seit der .NET Core-Reinkarnation deutlich schlanker, moderner und performanter unterwegs ist.

[TigerLilly]

Ja, Angular soll recht cool sein. Aber da hab ich kein projekttaugliches Know-How.

Am liebsten wär mir, wenn sich 2,3 finden, die vor derselben Hürde stehen wie ich. Dann einigt man sich auf einen technischen Unterbau, einer macht das reporting, einer das Benutzermanagement etc. Die Core-Logik macht wieder jeder selber + nutzt die Bausteine der anderen.

[Bernhard Geyer]

Zitat:

Zitat von TigerLilly (Beitrag 1503457)

Ja, Angular soll recht cool sein.

Eine wichtige/schwierige Entscheidung ist auf dem (für einem) RICHTIGEN Framework-Stack zu setzen.

Angular ist hier fast schon wieder "Schnee von Gestern" und die neuen Frameworks sind Vue und React (und noch ein 2-3 andere). Welche in 5 Jahren noch aktiv gepflegt wird oder "untergeht" ist offen.
Wir haben auch mal auf ein Framework von google gesetzt, welches aber mittlerweile als aussterbendes Framework gilt.

[haentschman]

Zitat:

Welche in 5 Jahren noch aktiv gepflegt wird oder "untergeht" ist offen....welches aber mittlerweile als aussterbendes Framework gilt.

...siehste, deshalb Delphi. :cheer: Das geht nicht unter. :zwinker:

[ConstantGardener]

Ja das ist eine schwere Entscheidung mit den JavaScript/CSS Frameworks. Wir haben mittlerweile 3 WebApps mit verschiedenen Bootstrap Varianten am Start, der Rest ist halt Javascript/Typescript. Aber schon das ist nervig.

Ich fand die Aussage von Herrn Suer (deutscher Entwickler/SymCom glaube ich) beim TMS WebCore Seminar vorgestern bei TMS interessant: Sie setzen WebCore (also Pascal --> Javascript Transpiler mit entsprechender Pascal RTL) ein um nicht bei einem falschen Javascript Framework zu landen. Werde da jetzt auch mal intensiver reinschauen, lizensiert haben wir es schon länger aber nur kleinere Sachen probiert.

[Phoenix]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1503459)

Eine wichtige/schwierige Entscheidung ist auf dem (für einem) RICHTIGEN Framework-Stack zu setzen.

Angular ist hier fast schon wieder "Schnee von Gestern" und die neuen Frameworks sind Vue und React (und noch ein 2-3 andere).

React ist älter als Angular ;)

Und es gibt tatsächlich relativ einfache, fachliche Gründe die einem bei der Entscheidung helfen, wann man welches Framework nehmen sollte.
React kommt von Facebook, und ist primär für Anwendungen gedacht, die viel anzeigen und viele, aber dafür immer die gleichen Eingabemöglichkeiten haben. Also eine Ellenlange Timeline von Posts und unter jedem das immer gleiche Kommentar-Eingabefeld und Reaktionsmöglichkeiten (daher der Name: React), auf die Posts.

Baust Du also das neue Facebook: React it is. React ist ausserdem mehr eine Sammlung von Bibliotheken als wirklich ein Framework.

Angular wurde von Google als der neue Unterbau von deren Geschäftsanwendungen wie die GSuite gebaut. Komplexe und schnelle Interaktionen, und dabei den Entwicklern eben nicht nur Tools an die Hand geben, sondern auch Guidelines WIE etwas zu machen ist. Angular setzt dabei stark auf Komponenten (wie Delphi und z.B. Winforms / WPF auch) und lenkt den Entwickler sehr stark in die Richtung das ganze State-Handling über RX (reactive Extensions) zu machen, weil es hiermit sehr effizient wird genau herauszufinden, welche Teile des UIs neu gerendert werden müssen und welche eben nicht (Change detection), was zu einer deutlich besseren UI-Performance führt wenn man eben nicht in einer endlosen Timeline nur virtualisiert scrollen muss.

Schreibst Du also Business-Anwendungen mit einer gewissen Komplexität wirst Du mit React früher oder später an die technischen Grenzen der Bibliotheksammlung kommen.

Vue ist so ein zwischending und kann beides, aber weder das eine noch das andere so richtig gut. Dafür ist es leichtgewichtiger. Wenn Du also eine kleine Anwendung mit einer kleinen Handvoll Ansichten und nur begrenzten Interaktionsmöglichkeiten brauchst kann das funktionieren. Aber wehe die Anwendung wird dann irgendwann deutlich komplexer.

Und ob ein Projekt morgen noch existiert kann Dir sowieso keiner verläßlich sagen. Da müssen nur die zwei, drei Hauptentwickler abends einen Trinken gehen und auf dem Weg dahin vom Bus überfahren werden....

Bei den Web-Frameworks und dem neuen .NET 5+ hat man den Vorteil, das das alles Open Source ist und jeweils sehr viele Firmen da ihre Anwendungen drauf aufbauen. Wenn Google morgen sagt, Angular wird nicht mehr weitergemacht (unwahrscheinlich, die schmeissen ihre neue GSuite eher nicht weg ;) also Busfaktor..., dann haben alleine wir in unserer Firma 3 Kollegen die Angular so im Detail kennen, dass sie in der Lage wären das weiter zu pflegen. Und viele unserer Kunden würden uns dann wahrscheinlich sogar dafür bezahlen wollen, weil deren Invest hoch genug ist um das nicht im Sande verlaufen lassen zu wollen.