• react.js

    Mit der JavaScript-Bibliothek React.js lassen sich komplexe Single-Page-Webanwendungen realisieren. React basiert auf der Kapselung einzelner Komponenten. Dies garantiert eine hohe Wiederverwendbarkeit und erhöht die Effizienz bei der Entwicklung. Zudem bietet React mit React-Native die Möglichkeit auch mobile Anwendung für WebAndroid und iOS zu erstellen. Dabei genügt die Programmierung einer einzelnen App, die ohne großen Mehraufwand auf Google’s und Apple’s mobilem Betriebssystem lauffähig ist. Durch diese Technologie ist eine erhebliche Kostenreduktion und Verkürzung der Projektlaufzeiten möglich.
    React ist somit die erste Wahl für plattformübergreifende, mobile Apps.

  • Für unser Produkt innCart benötigten wir eine mobile App für Android und iOS. Aufgrund der guten Erfahrungen mit React-Native haben wir uns für dieses Framework entschieden. Da unser Backendservice in Scala programmiert wird, galt es zu evaluieren, ob wir bei der Programmierung auf Scala mit ScalaJS setzen. Dieser Artikel soll das Ergebnis darstellen.

    React-Native

    Das JavaScript-Framework "React" von Facebook ist neben Angular eines der beliebtesten und spannendsten Frameworks für Webapplikationen, die es derzeit in der JavaScript-Welt gibt.

    React bietet mit der Ausprägung "React-Native" auch die Möglichkeit Mobile Apps in JavaScript zu schreiben - und zwar plattformübergreifend! Dies funktioniert in der Praxis so gut, dass zahlreiche Hersteller Ihre Apps mit dieser Technologie umsetzen. Facebook, Instragram, Airbnb oder auch MieterCast sind nur einige der bekannteren Beispiele. Auch die Community rund um React-Native wächst derzeit stark an. Es gibt mittlerweile für fast alle Bedürfnisse Bibliotheken und Beispiele. Und wenn es doch mal zu einem Problem kommt, hilft die React-Native Usergroup in München weiter.

    Eigentlich alles super - wäre da nur nicht JavaScript! Mit ES6 hat sich JavaScript zwar wieder ein großes Stück in die richtige Richtung bewegt, aber für größere Projekte wünscht man sich die Vorteile einer typisierten Sprache, auf die nachfolgend noch näher eingegangen wird.

    Scala

    Als Alternative zu TypeScript haben wir Scala genauer unter die Lupe genommen. Beide Sprachen ermöglichen eine typisierte Entwicklung. Der TypeScript bzw. Scala Sourcecode wird nach JavaScript transcompiliert und ist somit von jedem Browser interpretierbar und in Kombination mit React-Native auch als Smartphone App nutzbar. Wie eingangs erwähnt lassen wir TypeScirpt außen vor und beschäftigen uns nur mit der Frage, ob es für uns Sinn macht, bei der App-Entwicklung in React-Native auf Scala zu setzen oder stattdessen lieber direkt in JavaScript zu entwickeln.

    Um Scala-Code nach JavaScript zu übersetzen ist der Transcompiler Scala.js notwendig. Damit man in Scala auch React-Native verwenden kann, haben wir das Framework SRI (Scala React Interface) verwendet. In folgender Grafik wird der Technologie-Stack mit Scala (links) und ohne Scala (rechts) dargestellt:

    ScalaJS vs JavaScript React-Native Stack 

    Nach einer ausgiebigen Versuchsreihe mit der Verwendung von Scala in Kombination mit React-Native haben sich folgende Vor- und Nachteile herauskristallisiert:

     

    Vorteile

    Starke Typisierung

    Die Unterstützung von Typen, Klassen und Interfaces (bzw. Traits) wirkt sich besonders bei großen Projekten in Form von robusterer und besser wartbarer Software aus. Des Weiteren ist durch die Typisierung eine bessere IDE-Integration möglich, was erheblich zum Komfort bei der Entwicklung beiträgt und ein nicht zu unterschätzender Faktor ist.

    Optimierter JavaScript-Code

    Der Scala.js-Compiler optimiert den bei der Übersetzung den JavaScript-Output. Dies ergibt in der Regel eine bessere Performance.

    Scala als Sprache für Back- und Frontend

    Speziell bei innFactory setzen wir für Cloud- und Serveranwendung zunehmend auf Scala. Mit Scala und React-Native könnten wir ein Teil dieses Know-Hows auch in der Frontendentwicklung der mobilen Clients nutzen.

     

    Nachteile

    Viele Abhängigkeiten

    Wie die obige Grafik zeigt, ergeben sich neben React-Native noch zwei zusätzliche Abhängigkeiten, Scala und SRI. Zudem kommen noch externe Bibliotheken hinzu, die für Scala angepasst werden müssen. Bei einer neuen Version von nur einer einzelnen Komponente im Stack kann es zu Konflikten bei den anderen Abhängigkeiten kommen. Das Auffinden von Fehlerquellen ist nur dann leicht gegeben, wenn es sich um eine schlanke Architektur mit nur wenigen externen Bibliotheken handelt. 

    Kleine Community

    Da die Technologien bisher nur wenige Unterstützer auf github haben, wäre eine Einstellung des Supports ein weitaus größeres Risiko. Abgesehen von Scala.js steckt hinter dem Stack kein professioneller Support, sondern lediglich sehr gute Freizeitprojekte. Vor allem bei SRI besteht hier eine sehr große Unsicherheit, da es nur wenige Entwickler gibt. 

    Benötigtes Wissen in beiden Technologien (Scala und React-Native)

    Gute Scala-Entwickler sind schwer zu finden. Für React gibt es inzwischen etwas mehr. Aber Programmierer aufzuspüren, die beide Technologien beherrschen ist fast ein Ding der Unmöglichkeit.

    Während die Einarbeitungszeit für einen JavaScript-Entwickler in React-Native nur wenige Tage bis Wochen beträgt, erhöht sie sich in Kombination mit Scala auf einige Monate. Für Scala-Programmierer beträgt die Zeit zum Aufbau des Know-Hows nicht ganz so lange, aber auch hier müssen die Konzepte von React, wie z.B. die Redux-Architektur, erstmal verinnerlicht werden.

     

    Fazit

    Für uns hat Scala einen festen Platz, wenn es um Backend- und Cloudentwicklungen geht. Die Idee mit Scala auch JavaScript zu erzeugen ist sehr spannend. Aber für das anstehende Projekt überwiegen in unserem Fall die Nachteile eindeutig. Der Technologie-Stack ist leider noch zu wackelig. Auch die Aufstockung des Entwicklerteams könnte sich als extrem schwierig erweisen. Allein letzterer Punkt würde für uns als K.O.-Kriterium ausreichen.

    Wir finden, dass sich das Scala.js-Projekt in die richtige Richtung bewegt und werden es sehr genau im Auge behalten. Für unsere Produktentwicklung aber, werden wir auf reines React-Native für die App setzen und Scala als primäre Technologie im Backend verwenden.

     

  • Heute haben wir ein neues Projekt auf der github Seite von innFactory und auf dem npm innFactory Account veröffentlicht. Mithilfe von „react-native-aws-mobile-analytics“ lässt sich AWS Mobile Analytics kinderleicht in react-native Apps integrieren. 

    Das SDK wurde von Anton für unsere croGoDeal App in Anlehnung an das originale AWS Mobile Analytics JS SDK entwickelt und jetzt OpenSource veröffentlicht. Der Einstieg sollte auch für neue Entwickler sehr einfach sein. Bei Fragen und Problemen stehen wir euch natürlich über den Issue-Tracker in github zur Verfügung. 

    SDK in croGoDeal

    Wie bereits erwähnt verwenden wir das SDK selbst für die Analyse und das UI/UX Tracking unserer User in croGoDeal. Neben den gängigen KPI wie "Daily Active User" oder "Monthly Users", können wir mit AWS Mobile Analytics auch A/B Tests und UI/UX Tests über das Toolkit auswerten. Die Tests sind für unsere croGoDeal App und die Strategie der Softwareentwicklung sehr wichtig, damit wir in unsere Hypothesen aus unseren Minimal Viable Products (MVP - Lean Startup) schnell verifizieren oder falsifizieren können. Eine ausführliche Studie, ob sich der geplante Nutzen so eingestellt hat wie erhofft, veröffentlichen wir zu einem späteren Zeitpunkt nach den ersten paar Releases der App.

    Projekt auf github:

    https://github.com/innFactory/react-native-aws-mobile-analytics

     

    Komplettes Beispiel:

    https://github.com/innFactory/react-native-aws-mobile-analytics-demo

     

    NPM Package:

    https://www.npmjs.com/package/react-native-aws-mobile-analytics

     

  • Je natürlicher und intuitiver eine Software oder Applikation bedienbar ist, desto höher ist die Akzeptanz und Zufriedenheit der Kunden. Gerade für Apps, die ein kurzes On-Boarding verlangen und die „schnell, nebenbei“ verwendet werden, ist eine einfache Bedienung in Kombination mit einer flachen Navigation durch die einzelnen Funktionen elementar. Entgegen diesem Paradigma soll eine App trotz ihrer trivialen Bedienbarkeit (Stichwort Usability) einen angemessenen Funktionsumfang bieten und möglichst alle Bedürfnisse des Nutzers abdecken. Erschwerend kommt hinzu, dass bei Mobile Apps bedingt durch die Displaygröße der Platz für Informationen und Funktionselemente sehr beschränkt ist und die Applikation dadurch sehr schnell „überladen“ wirkt. Fühlt sich infolgedessen ein Nutzer überfordert und kann die gewünschte Funktion nicht innerhalb weniger Augenblicke finden, so stellt sich eine geiwsse Ablehnung gegenüber der App ein. Dieses Phänomen behandelt auch Yu-Kai Chou in seinem Buch „Actionable Gamification“:

    "Far too often, Onboarding experiences for products feel confusing, too hands off, or too complex. This results in the user feeling stupid. If your user feels stupid during Onboarding, then you’ll be fighting an uphill battle along with the user (think Google+)." http://yukaichou.com/gamification-study/4-experience-phases-gamification-2-onboarding-phase/

    Um diesem Problem entgegenzuwirken setzen wir verstärkt auf die Verwendung von Sprachsteuerung in Apps. Damit kann eine Applikation zentral bedient werden, ohne dass das Userinterface zu überladen wirkt. Beispielsweise kann man dadurch eine komplexe Filterfunktion einer Shopping App für den Nutzer stark vereinfachen. Mit dem Satz: „Ich will Angebote von Lebensmitteln im Umkreis von 10 km“ oder „Obst von Edeka, Rewe und Netto“ können sehr schnell die Filterparameter für Kategorie, Ort oder Markt gesetzt werden.

    Eine intuitive Sprachsteuerung lässt sich für weitaus mehr Use Cases nutzen. Besonders interessant ist ein Arbeitsumfeld, welches durch hohe Fluktuation, Saisonarbeit oder eine geringe Vertrautheit mit den IT-Prozessen gekennzeichnet ist. Hier kann durch Sprachsteuerung eine einfache und schnelle Bedienung komplexer Aufgaben bewerkstelligt werden. Ein Lagermitarbeiter könnte ohne genauere Kenntnisse in der Logistik mit dem Worten „Zeige mir Wareneingangsschein für Bestellnummer 123“ die entsprechenden Daten auf einem stationären oder mobilen Display angezeigt bekommen - ohne vom Stapler absteigen zu müssen.

    Ein weiterführender Artikel in diesem Zusammenhang beschäftigt sich mit der Entwicklung einer Sprachsteuerung und der Integration in einer React-Native App: Sprachsteuerung mit Api.ai in einer React-Native App

     

  • In dem Artikel "Das Potential von Sprachsteuerung" haben wir die Bedeutung von Sprachsteuerung erläutert. Nun wollen wir uns der technischen Seite widmen und erklären, wie man mit Hilfe von Api.ai Sprachsteuerungen entwickelt. Api.ai hat sich seit 2014 auf Sprach- und Chatbots spezialisiert und gehört seit 2016 zu Google. Mit der angebotenen Technologie lassen sich Konversationen zwischen Mensch und Maschine designen und in verschiedenste Dienste wie Alexa, Slack, Twitter, Facebook und viele weitere integrieren. Api.ai setzt im Hintergrund Maschine Learning ein, um die genaue Intension einer Sprach- oder Texteingabe zu verstehen. Dadurch bietet Api.ai eine erstaunliche Interpretationssicherheit und bildet eine ideale Basis auch für unternehmerische Anwendungsfälle.

    Umsetzung eines UseCases in Dialogflow (Api.ai)

    Für die ersten Schritte in Api.ai Dialogflow, wie die Erstellung eines Projekts bzw. eines „Agents“ wird eine ausführliche Dokumentation angeboten. (https://api.ai/docs/getting-started/basics)

    Richtig spannend wird es bei der Erstellung sog. „Intents“. Ein Intent ist gewissermaßen die Definition einer Funktionssignatur. Wird ein Sprach- bzw. Textbefehl von einer Benutzeranwendung an Api.ai gesendet, findet Api.ai mit Hilfe seiner Machine Learning Algorithmen die entsprechende Signatur und sendet den Namen der Funktion und ggf. die zugehörigen Parameter zurück an die Benutzeranwendung. Die Benutzeranwendung kann danach die Funktion ausführen und dem Benutzer das gewünschte Ergebnis liefern.

    Um den Ablauf zu veranschaulichen nehmen wir als UseCase eine Shopping App, in der der Benutzer Angebote von unterschiedlichen Märkten einsehen kann. Im folgenden Screenshot sieht man, wie ein Intent in Api.ai aussehen kann:

    Als erwarteter Sprachbefehl wird „Angebote von Rewe“ festgelegt, wobei Rewe einen Parameter darstellt und somit variabel ist. Durch das Machine Learning versteht Api.ai auch verwandte Aussagen, wie z.B. „Deals von Rewe“ oder auch „Schnäppchen bei Rewe“. Als Rückgabe wird der zugehörige Funktionsname (Action) „search_deals“ mit dem Parameter „Shop = Rewe“ zurückgegeben.

     

    ApiAi.setConfiguration("4xxxxxxxe90xxxxxxxxc372", ApiAi.LANG_GERMAN);

    Neben Englisch und Deutsch werden viele weiter Sprachen unterstützt. Eine Auflistung befindet sich in unserer GitHub-Dokumentation: https://github.com/innFactory/react-native-api-ai#supported-languages Als nächstes wird mit dem simplen Aufruf von „startListening“ der Sprachbefehl aufgenommen und direkt mit Api.ai verarbeitet:

    ApiAi.startListening(result=>{ console.log(result); }, error=>{ console.log(error); }); 

    Fazit

    Mit Api.ai ist es möglich professionelle Sprachsteuerungen zu entwickeln. Unsere React-Native Library „react-native-api-ai“ liefert dazu eine einfache Integration für entsprechende Mobile Apps. 

  • Das Team von innFactory war vergangene Woche in Lissabon auf der größten Technologie Messe der Welt. An drei Tagen präsentierten sich hier Startups in sämtlichen Wachstums- und Finanzierungsphasen mit ihre Ideen in Form von Messeständen und Pitches. Der beste Pitch gewann dabei ein Preisgeld von 50000 EUR, das von Mercedes Benz zur Verfügung gestellt wurde. Auch wir hatten als Startup am Dienstag einen Messestand für unseren Chatbot croGo. 

    Neben den vielen Startups waren auch die meisten großen etablierten Big-Player wie Amazon Web Services, Facebook, Google, Uber, Slack, Microsoft, BMW, Mercedes Benz und noch viele weitere aus allen möglichen Branchen auf der Websummit vertreten. Sie präsentierten sich ebenfalls mit Messeständen.

    Zusätzlich wurde die Messe durch eine Vielzahl von Vorträge von über 1200 internationale Topspeaker begleitet. Thematisch deckten die Talks alle erdenklichen Themenfelder die für Startups relevant sind ab. Von sehr technischen Schulungen für Cloud-Computing und modernen progressive Web Apps mit React und React-Native, über die Zukunft von Methoden wie Lean-Startup, bis hin zu futuristischen Ankündigungen, wie den fliegenden Taxis von Uber war auf der Messe alles vertreten.

    Da auf der Messe tausende Investoren aus allen Länder unterwegs waren, hatte auch wir als junges Startup die Chance auf eine 4-Augen Gespräch mit einem Topinvestor und konnte somit unser persönliches Profil weiter schärfen und uns durch Mentoring verbessern.

    Die Messe konnte uns somit in vielerlei Dingen unterstützen und wir planen auch 2018 wieder teilzunehmen.

    Weiter Bilder zum Messebesuch befinden sich auf unserer Instagram Seite (innfactory)

  •  

    Wir bei innFactory setzen von Beginn an auf Microservices im Backend. Die technologische Unabhängigkeit und die flexible Skalierbarkeit zwischen den einzelnen Services sind in unseren Augen unschlagbar. Zusätzlich lassen Frameworks wie Lagom (Scala) das „Mehr-Overhead“ Argument verstummen.

    Letzte Woche war ich im Rahmen der Veranstaltung „Microservices“ als Dozent zu Gast an der Hochschule Rosenheim und habe mich der Frage gewidmet, inwiefern sich das Frontend an die Microservice Architektur im Backend anpassen und integrieren lässt.

    Der "klassische" Ansatz

    Das Frontend wird beim klassischen Ansatz als Monolith belassen. Nach unserer Erfahrung ist das auch bislang der gängigste Weg, um ein Frontend an ein Backend mit Microservice Architektur anzubinden. Das Entwickler Team besteht dabei meist ausschließlich aus Frontend Spezialisten, die das Backend über einen sogenannten „Aggregation Layer“ (das Backend) einbinden. Der Aggregation Layer sorgt für eine spezielle API, zugeschnitten auf die jeweiligen Bedürfnisse. So kann beispielweise die App und die Website mit einer genau passenden Schnittstelle bedient werden, um den Datentransfer gering und die Klarheit hoch zu halten. Um dieses sogenannte „Backend for Frontend Pattern“ dynamischer umzusetzen, verwenden wir bei innFactory überwiegend GraphQL als Abfragesprache für die API.

    Single Page Microservice UI
    Klassische Microservice UI

    Der "FullStack" Ansatz

    Im Gegensatz zur klassischen Architektur führt der FullStack Ansatz die Idee hinter den Microservices weiter bis in das Frontend. Zwar sind die einzelnen Services nach wie vor zwischen Back- und Frontend getrennt, jedoch ergeben sich technologisch gemischte Entwickler Teams, die auf einen bestimmten Use Case gerichtet sind. Meist wirkt sich das sehr positiv auf den Knowhow-Transfer innerhalb des Entwickler-Teams aus, allerdings entstehen im Frontend auch erhebliche Hürden, die weiter unten unter „Probleme bei der UI-Ausarbeitung mit einer Microservice-Architektur“ erklärt werden.

     

    FullStack Microservice UI
    FullStack Microservice UI

    Vergleich: Klassisch – FullStack

    Folgender Vergleich soll die Tendenzen aufzeigen, nach denen sich die beiden Ansätze unserer Erfahrung nach unterscheiden:

    "Klassisch"

    • Best Practise – geringes technisches Risiko
    • Schnellere Einarbeitung neuer Entwickler
    • One team, one user experience

     

    "FullStack"

    • Größerer Wissenstransfer im Team
    • Flexiblere Entwickler (+ oft höhere Eigenmotivation für FullStack Projekte)
    • Fokus komplett auf einen Service gerichtet

    Technische Probleme bei der UI-Ausarbeitung mit einer Microservice-Architektur

    Eine besondere Herausforderung stellt der Austausch von UI-Komponenten zwischen den einzelnen Teams dar. Dies liegt allen voran daran, dass, wie in einer Microservice Architektur üblich, jedes Team unabhängig ihre Komponenten warten und deployen können soll. Einen interessanten Ansatz verfolgt OpenTable mit ihrem serverless GUI-Framework OpenComponents (https://github.com/opentable/oc).

     

    Microservice UI Problems
    Microservice UI Probleme

     

    Im Backend sind die einzelnen Microservices technisch vollkommen unabhängig. Diese Unabhängigkeit auch im Frontend bereit zu stellen und jedem Team frei zwischen Frameworks oder Libraries, wie React, Angular oder Ember wählen zu lassen, ist nur schwer realisierbar. Hinzu kommen darüber hinaus viele verschiedene Versionen der genannten Frameworks sowie anderen Javascript Erweiterungen. Der Browser wäre bei clientseitigem Rendering gezwungen unzählige Javascript Dateien zu laden, was die Geschwindigkeit auf einen inakzeptablen Wert drücken würde. Aber auch serverseitiges Rendering mit z.B. next.js ist mit unterschiedlichen Libraries und Versionen aus Gründen der Kompatibilität nicht umsetzbar.

    Different UI Libs
    Unterschiedliche UI Frameworks

     

    Um trotzdem eine Microservice Architektur zu realisieren bleibt nur eine einheitliche technische Basis aller Teams. Dies kann ein einziges Framework sein oder auch die Entwicklung in reinem Javascript, CSS und HTML. Ein vielversprechender Ansatz ist der WebComponents Standard, auf den sich die großen Browserhersteller derzeit vorbereiten.

    Fazit

    Die Frontend Architektur der Microservices anzupassen verspricht gerade bei sehr großen Projekten Vorteile in der Teamstrukturierung sowie klare Verantwortlichkeiten der Services. Technologisch wird diese Herausforderung am besten mit dem Verzicht auf externe Frameworks und Libraries bewältigt. Eine Überlegung ist, in naher Zukunft eigene HTML-Tags mit WebComponents zu implementieren, um die gewünschte Unabhängigkeit zu erreichen.