Client Architektur

Moin zusammen,

ich komme gerade nicht so richtig weiter. Aber der Reihe nach.

Der gedbas4all-wikibase Prototyp zeigt, wie Daten aus wikibase, direkt oder mit SPARQL, gelesen und angezeigt werden können.
Man könnte hier noch untersuchen, wie man Bilder über die JSON Schnittstelle transportiert und anzeigt.
Datenstrukturen um Beziehungen anzuzeigen fehlen noch (Eltern, Kinder, Ehepartner).
Habe ich noch etwas übersehen? Gibt es noch mehr, was ‚prinzipiell‘ untersucht werden soll?

Bei dem Einbau der Errorhandling bin ich bei der Suche auf das Thema Architektur gestoßen.
Dabei wurde mit klar, dass ich bereits einige Architektur Entscheidungen, eher unbewußt, getroffen habe.
Ausgangspunkt war vue ui: Paketverwaltung Standard; [Vue 3] less, babel, typescript, router, vuex, eslint, unit-jest, e2e-nightwatch
Inzwischen habe ich noch i18n hinzugefügt.

Die Verzeichnisstruktur habe ich entsprechend der Artikelserie angepasst.
Bei der Umsetzung vom 4. Artikel (exception handling) bin ich dann gescheitert.
Weitere Recherchen stießen mich dann auf Boilerplats.

Davon habe ich mir vue-enterprise-boilerplate und Vuesion näher angesehen.

vue-enterprise-boilerplate gefällt mir sehr gut. Allerdings hat sich dort schon länger nichts mehr getan. Es hat zwar einen Wechsel von chrisvfritz zu bencodezen gegeben, aber das war es auch schon.
Fragen zu einer Portierung auf Vue 3 bleieben unbeantwortet und typescript wird nicht unterstützt (Begründung).
Von vue-enterprise-boilerplate gibt es einen Clone, der Vue 3, typescript und i18n unterstützt. Dort gibt es aber noch Fehler, die Portierung ist also nur bedingt einsetzbar.

Vuesion gefällt mir auch gut, bietet einiges. Bei manchem bin ich mir allerdings nicht sicher ob wir es einsetzen (wollen). Zum Beispiel Progressive-Web-App oder SEO und SSR.
Vuesion wird gerade auf einem eigenen Branch nach Vue 3 portiert. Gleichzeitig wird nuxt als Basispaket verwendet.

Sämtliche Versuche, ein Boilerplate zu verwenden und in Richtung gedbas4all voranzutreiben, aber auch Features aus den Boilerplates in gedbas4all umzusetzen sind über kurz oder lang an grundsätzlichen Fragestellungen gescheitert.
Wohin soll sich gedbas4all entwicklen? Lang- aber auch mittelfristig.
Was brauchen wir bei gedbas4all? Was wollen wir nicht?
Wie sollen die Prioritäten gesetzt werden?
Soll ich gedbas4all mit einem der Boilerplates neu starten? Wenn ja, mit welchem? Vue 2 oder 3? Typescript oder Javascript? less oder scss? npm oder yarn?
Soll gedbas4all produktifiziert werden? Welche der in den Boileplates umgesetzten Features wollen wir einsetzen? Je länger wir damit warten, um so aufwändiger wird die Implementierung.

Ich hänge jedenfalls gerade fest. Vielleicht habt ihr ein paar Antworten, die mir weiter helfen.

Ich kann euch auch noch schreiben, was mir bei den verschiedenen Ansätzen gefällt und was nicht. Im Moment spare ich mir das, um euch in euren Antworten nicht zu sehr zu beeinflussen.

Viele Grüße

Jörg

Hallo Jörg,

offenbar ist sonst niemand hier so tief in der Entwicklung drin, wie wir beide. Wobei ich in der Client-Entwicklung ja auch nicht wirklich tief drinstecke. Bei der Frage nach dem besten Ansatz für das Vue-Frontend kann ich daher nur wenig behilflich sein.

Vue.js ist mir immer wieder positiv aufgefallen. Das kann aber auch meine eingeschränkte Wahrnehmung sein. Wenn es schon eine Version 3 gibt, dann sollte man auch die besser gleich verwenden. Das Problem hatte (und habe) ich bei den Java-Webanwendungen auch. In Grails 2 geschrieben. Es kam Grails 3, das aber so inkompatibel war, dass eine eine Neuentwicklung erfordert hätte. Da ich bei Grails 2 geblieben bin, bin ich von allen neuen Features abgehängt. Daher baue ich bekanntlich seit einiger Zeit auf Plain-Java und Spring um.

Wirklich hilfreich ist meine Antwort vermutlich nicht, aber gar keine Antwort ist noch blöder.

Moin Jesper,

vielen Danke für deine Antwort.

Vue.js habe ich nicht in Frage gestellt. Lediglich das Grundgerüst drum herum. Macht es evtl. Sinn auf so einem Grundgerüst aufzubauen?

Und deine Antwort hat mich auf den richtigen Weg (zurück) gebracht. Vue.js 3.x ist die die richtige Wahl. Durch deine Antwort wurde ich daran erinnert, wieviel Mühe und Nachforschung ich investiert habe um den Client, wie er ist zum Laufen zu bringen.
Für Vue 3.x findet man noch nicht viele Informationen und noch weniger Module, die damit funktionieren. Das hat auch zu meinem Frust geführt. Ich mache dort weiter und werde gleichzeitig die Boilerplates im Auge behalten und ggf. einzelne Features in gedbas4all umsetzen.

Derzeit liebägele ich mit den Code-Generatoren und dem Design (scss statt less). Mal schauen ob ich davon etwas bei uns integriere.

Jörg