Kategorie: 2022

UI5 + wdi5 – Framework Entwicklung im Spannungsfeld “Enterprise”, Open Source und Zukunftstechnologien

UI5 (https://openui5.org) ist bei SAP strate­gisch geset­zt zur Erstel­lung von Weban­wen­dun­gen, wdi5 (https://js-soft.github.io/wdi5/) als zuge­höriges Tool entsprechend für end-to-end Tests.
Bei­de müssen sowohl SAP Stan­dards genü­gen (Stich­worte z.B. Rück­wärt­skom­pat­i­bil­ität und Bar­ri­ere­frei­heit), aber auch tech­nol­o­gisch auf Trends und (Brows­er-) Entwick­lun­gen reagieren. Die Zusam­me­nar­beit mit der Com­mu­ni­ty in Form von Erstel­lung und Wartung von Open Source Soft­ware Kom­po­nen­ten ist hier­für ein Schlüssel.
Der Vor­trag zeigt Tech­niken, Tools und Maß­nah­men, der­er sich UI5 und wdi5 bedi­enen, um mit Ansprüchen an Geschäftssoft­ware umzuge­hen, aber gle­ichzeit­ig Offen­heit gegenüber der Entwick­ler­com­mu­ni­ty zu wahren. Sodass die Koop­er­a­tion vorteil­haft für sowohl SAP, wie auch die Com­mu­ni­ty, bleibt.

So führen dich Tools zum Testen auf Barrierefreiheit hinters Licht

In den gängi­gen JavaScript-Frame­works wie Angu­lar, React oder Vue wird Bar­ri­ere­frei­heit von vie­len Teams nur auf der Kom­po­nen­ten-Ebene getestet. Dabei kann es trotz­dem noch zu automa­tisch erkennbaren Bar­ri­ere­frei­heit­sprob­le­men kom­men, wie wir in einem prak­tis­chen Beispiel sehen wer­den.  Daraufhin erweit­ern wir das Beispiel mit mehreren Test­stufen, damit ein Großteil der Prob­leme in der nicht zugänglichen App­lika­tion gefun­den und gelöst wer­den kann. Zum Schluss wis­sen wir, welche Fall­stricke es beim automa­tis­chen Testen gibt und wie wir mit diesen umgehen.

Ein vollständiges JavaScript Anwendungssystem

In diesem inter­ak­tiv­en Work­shop leit­et Oliv­er Sie inner­halb eines Tages durch die notwendi­gen Schritte, um selb­st ein voll­ständi­ges Anwen­dungssys­tem in JavaScript zu erstellen. Das erar­beit­ete Microser­vices-Sys­tem ver­wen­det mehrere ver­schiedene Ele­mente und Pat­terns: eine NoSQL-Daten­bank, CQRS- und Event Sourc­ing-Architek­tur auf dem Serv­er, Optio­nen wie React, Redux und Svelte auf dem Client, und alles das durch bidi­rek­tionale Kom­mu­nika­tion­swege über das Web ver­bun­den. Auf diese Weise ler­nen Sie die Details der Architek­turkom­po­nen­ten Schritt für Schritt, so dass Ihre eige­nen Pro­jek­te unmit­tel­bar davon prof­i­tieren kön­nen. Brin­gen Sie Ihren Lap­top mit und machen Sie mit!

Entwicklung einer Web-Components-Library: Lessons Learned

Wir entwick­eln eine unternehmensin­terne Kom­po­nen­ten-Bib­lio­thek um ein ein­heitlich­es Look-and-Feel über ver­schiedene Anwen­dun­gen hin­weg sicherzustellen. Um die ver­schiede­nen Fron­tend-Frame­works in unter­schiedlichen Teams abdeck­en zu kön­nen, haben wir uns für den Web-Com­po­nents-Stan­dard entschieden.
In diesem Vor­trag möchte ich unsere Erfahrun­gen nach 2 Jahren Entwick­lungszeit teilen. Dabei geht es natür­lich vor allem um die Prob­leme und Schwierigkeit­en, die wir zu lösen hat­ten, unter anderem Kom­pat­i­bil­ität­sprob­le­men mit SPA-Frame­works, Brows­er-Unter­stützung, For­mu­la­re und Accessibility.
Im Faz­it erk­läre ich, warum wir uns den­noch für Web-Com­po­nents entsch­ieden haben, warum wir diese Entschei­dung wieder so tre­f­fen wür­den, aber auch warum ich den­noch nicht pauschal für jeden Ein­satzz­weck zu Web-Com­po­nents rat­en würde.

Svelte Stores A bis Z

Zus­tandsver­wal­tung braucht jedes Frame­work, und in Svelte wird dies haupt­säch­lich mith­il­fe von Stores umge­set­zt. Es find­en sich einige Stan­dard­funk­tio­nen, die auf Stores basieren, und für’s eigene Pro­jekt benöti­gen Sie ver­mut­lich einige, die schnell selb­st imple­men­tiert sind. Das Pat­tern ist allerd­ings sehr flex­i­bel und kann auch für ganz andere Auf­gaben wie etwa die ele­gante Ver­wal­tung von Promis­es ver­wen­det wer­den. In diesem Talk präsen­tiert Oliv­er einen Überblick der Tech­niken und Möglichkeit­en, bis hin zur Kom­pat­i­bil­ität mit RxJS — so sind Sie für Svelte Stores bestens gerüstet!

Einführung in SvelteKit

Als Kom­po­nen­ten­frame­work stellt Svelte eine Lösung dar, die für voll­w­er­tige Anwen­dun­gen nicht allein aus­re­ichend ist. Aus densel­ben Hän­den gibt es nun Svel­teK­it, das vieles der Funk­tion­al­ität bietet, die Sie “son­st noch” brauchen: Rout­ing und Seit­en­lay­out­struk­turen, Daten­di­en­ste, SSR und andere Deploy­men­top­tio­nen, und einige andere Fea­tures. Dieser Talk ist ein Ein­stieg in Svel­teK­it, auf dessen Basis Sie selb­st sofort mit ein­er eige­nen Anwen­dung begin­nen können!

Impressionen aus der Praxis: Funktionale Ansätze in JavaScript

Das The­ma “Funk­tionale Pro­gram­mierung” ist umfan­gre­ich und nur schw­er in einem Talk abzudeck­en. Allerd­ings lässt sich eines machen: in prak­tis­chen Auszü­gen aus echt­en Pro­jek­ten zeigt Oliv­er, was er mith­il­fe funk­tionaler Ideen beson­ders effizient umset­zen kon­nte. Es gibt über­sichtlich gestal­tete Algo­rith­men, hil­fre­iche Laufzeit­typ­isierung für wiederver­wend­bare Bib­lio­theken und selek­tive Ein­bet­tung von Rescript-Code. Achtung: es beste­ht die Gefahr, dass Sie als Zuschauer Inter­esse an funk­tionaler Pro­gram­mierung entwick­eln und manche objek­to­ri­en­tierte Prax­is als nut­z­los erken­nen. Sagen Sie nicht, wir hät­ten Sie nicht gewarnt!

Nx Monorepo: Frontend-Architekturen effizienter entwickeln und visualisieren

Die Art des Pro­jek­ts, an dem man arbeit­et, wirkt sich auf die Pro­jekt Entschei­dun­gen aus.
Kom­pliziert­er wird es, wenn man an mehreren zusam­men­hän­gen­den Pro­jek­ten arbeitet.
Wie verän­dert dies die Verze­ich­nis­struk­turen des Pro­jek­tes? Wie sollte der Code zwis­chen Pro­jek­ten geteilt wer­den? Nx ist ein Tool, das darauf abzielt, diese Prob­leme zu lösen. Wir gehen in diesem Vor­trag die Kern­funk­tion­al­itäten von Nx durch, sowie die Vorteile und Her­aus­forderun­gen die sich aus dem Ein­satz von Monore­pos im all­ge­meinen und Nx im beson­deren ergeben können.

Endlich Skalierbar dank Micro Frontend Discovery

Micro Fron­tends wer­den häu­fig als die Lösung für Skalierung­sprob­leme im Bere­ich der Webapp-Entwick­lung ange­priesen. Doch in der Real­ität kommt es nicht sel­ten zu Her­aus­forderun­gen, die nicht so ein­fach gelöst wer­den kön­nen. Eine Lösung ist die Entkop­plung der ver­schiede­nen Micro Fron­tends dank eines sog. Micro Fron­tend Dis­cov­ery Mechanismus.

In diesem Vor­trag stellt Micro Fron­tend Experte Dr. Flo­ri­an Rap­pl die Micro Fron­tend Dis­cov­ery über einen Back­end Ser­vice vor. Er zeigt wie eine Micro Fron­tend Lösung mit einem Dis­cov­ery Mech­a­nis­mus aus­ges­tat­tet wer­den kann, welche Vorteile das bietet und welche Hür­den dazu genom­men wer­den müssen.

Extrahieren von Micro-Frontends aus einer monolithischen Frontend-Anwendung

Das Konzept von Microser­vice-Architek­turen in der Soft­wa­reen­twick­lung gewin­nt zunehmend an Aufmerk­samkeit. Diese Architek­turen entste­hen oft aus dem Refac­tor­ing mono­lithis­ch­er Anwen­dun­gen. Viele Microser­vice-Architek­turen küm­mern sich wenig um das Fron­tend beziehungsweise um die Benutze­r­ober­fläche. Oft führt die Zer­schla­gung zu vie­len kleinen, lose gekop­pel­ten Dien­sten, die in einem weit­er­hin mono­lithis­chen Fron­tend zusam­menge­fasst sind. Mit ein­er Micro-Fron­tend-Architek­tur kön­nen diese lose gekop­pel­ten Sys­teme systematisch/dynamisch in ein­er Benutze­r­ober­fläche zusam­menge­führt wer­den. Ich gebe in diesem Vor­trag einen Überblick über ver­schiedene Migra­tionsan­sätze zu Micro-Fron­tend-Architek­turen und zeige einen Migra­tionsansatz am Beispiel des Soft­ware-Visu­al­isierung­spro­gramms ExplorViz.