Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
© 2019 synetics GmbH
© 2019 synetics GmbH
Devday auf der i-doit AWK 2019
Begrüßung
© 2019 synetics GmbH
© 2019 synetics GmbH
Moderation
Moderator
● Jens Dörnenburg
● Teil des i-doit Teams seit 2011
● Tätig in Support/Care
© 2019 synetics GmbH
Das Entwickler-Team
Pavel Abduramanov Leonard Fischer
Kevin Mauel Van Quyen Hoang
Architektur
Frontend
Frontend
Architektur
API
Kategorien
Beziehungen
© 2019 synetics GmbH
Devday → Agenda
Agenda
● i-doit 2.0 Systemvoraussetzungen
● i-doit 2.0 Technisches Leitbild & Architektur
● i-doit 2.0 Verwendete Technologien
● i-doit 2.0 API
● Im Anschluss: Fragerunde
© 2019 synetics GmbH
i-doit 2.0Systemvoraussetzungen
Referent: Kevin Mauel
© 2019 synetics GmbH
i-doit 2.0 → Mindestsystemvoraussetzungen
● CPU: 2 CPU Kerne
● RAM: 2 GB
● Storage: 10 GB
● DBMS:
○ MySQL: 5.7.8, 8.x
○ MariaDB: 10.2+
○ PostgreSQL: 9.5+
● PHP >= 7.2
● Browser: letzte stabile Version und ESR/LTS von
Firefox, Chrome, Safari, Edge
© 2019 synetics GmbH
i-doit 2.0Technisches Leitbild & Architektur
Referent: Pavel Abduramanov
© 2019 synetics GmbH
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Agenda
Agenda
● Ziele
● Architektur von i-doit 2.0
● Wie funktioniert i-doit 2.0 von Login bis Objektlisten
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Ziele
● Verbesserung der Datenstruktur
● Übernahme von Business Logik
● Zukunftsfähiges i-doit Framework
● Erweiterbare und modulare Struktur
● Standardisierte API
● Trennung Frontend und Backend
● Migration von i-doit 1.x Daten
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Architektur
Backend
Auth API
Frontend Routes
DataLayer
Objekt Modell
Param Converter
Search Search Sources
DataAPI
Preset
...
Module
Dashboard
Finder
...
Preset Sources
Suggestion
Object Table
...
Text Control
Select Control
...
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Common Service Struktur
● Interfaces zur Beschreibung von Logik
● Austauschbar durch Interfaces
● Facade Service
● Erweiterbarkeit durch tagged Services
Facade
Interface
Class1Collection Class1
public service.id
tag service.id
Result Interface
Result Class1
Result Class2
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Login in i-doit
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Aufbau von i-doit Core
Konfiguration
Vorbereitung
Add-ons
Lizenzen
KonfigurationProvider
Add-onsProvider
LizenzenProvider
Aufbau
Registrieren Core
Registrieren Add-ons
i-doit
Services
Endpunkte
Übersetzung
usw
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Add-ons
Add-on
Endpunkte
Übersetzungen
Frontend Komponenten
Eigene Services
Erweiterungen für Kern
Erweiterungen für Data Modell
Add-on● hat eine vordefinierte Struktur● hat Zugriff zu public Services von i-doit● erweitert i-doit an bestimmten Punkten● registriert eigene Services● registriert eigene Frontend Komponenten:
Seiten, Module, Controls
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Login in i-doit
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Authentication
Authentification ChainLogin/Authentifizierung● ist mit standard Symfony Authentifizierung
Service (UserProviderInterface) gebaut● Findet einen entsprechenden i-doit User während
Matching Prozess● erweiterbar● Standard Implementierung mit eigener User
Tabelle
AuthenticationMethod
UserProvider
User
Matcher
i-doit User
AuthenticationMethod
...
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Authentication mit Ldap
Ldap Verbindung Einstellungen
AuthenticationMethod
LdapUserProvider
LdapUser
LdapUserMatcher
IdoitUser
Ldap Matcher Einstellungen
Ldap Server
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Dashboard
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Suche
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Search Service
Finder
FinderSource
RecentObjects Source
FulltextSearch Source
Search
Engine Interface
DoctrineSearch Engine
FinderItem[] SearchIndex Item[]
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Finder Page
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → DataLayer. Überblick
DataLayer
Category Info
Property Info
DataLayer Request
DataLayer Request
Event
DataLayer Response
DataLayer Handler
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → DataLayer. Info Klassen
Info
Class CollectionInfo
Classification Info Category Info Property Info
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → DataLayer. InfoFactory
InfoFactory
InfoProducer
Category InfoProducer
CustomCategory InfoProducer
...
InfoCollector
Properties InfoCollector
UiConfiguration InfoCollector
...
CategoryInfo CategoryInfo
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → DataLayer. Request Flow
Verarbeitung
Daten in DB aktualisieren
Nachbearbeitung
Daten von DB abholen
...
Vorverarbeitung
Vorbereitung Daten in Request
Rechte prüfen
Werte konvertieren
...
Durchführungdes Requests
Überprüfung und Modifikation von
Request
Vorbereitung des Responses
Relations erneuern
Logbuch aktualisieren
...
Triggern von Subprozessen
Aufrufen Subprozesse mit Information von
Request und Response
© 2019 synetics GmbH
i-doit 2.0 → Technisches Leitbild & Architektur → Zusammenfassung
Backend
Auth API
Frontend Routes
DataLayer
Objekt Modell
Param Converter
Search Search Sources
DataAPI
Preset
...
Module
Dashboard
Finder
...
Preset Sources
Suggestion
Object Table
...
Text Control
Select Control
...
© 2019 synetics GmbH
i-doit 2.0Verwendete Technologien
Referent: Kevin Mauel Leonard Fischer
© 2019 synetics GmbH
i-doit 2.0 → Verwendete Technologien → Agenda
Agenda
● Backend
○ PHP 7.2
○ Symfony
○ Doctrine
● Frontend
○ React
○ Redux
○ Sagas
○ SCSS
Verwendete TechnologienBackend
i-doit 2.0 → Verwendete Technologien → Backend → PHP 7.2
● Performance Optimierungen
● Scalar Type declarations
function sum(int ...$ints) {}
● Return type declarations
function sum(int ...$ints): int {}
i-doit 2.0 → Verwendete Technologien → Backend → Symfony
● Lange Historie (2.0 released im Juli 2011)
● Große und erfahrene Community
● Viele sinnvolle Erweiterungen
● Effiziente Entwicklung
● Bereits Erfahrung gesammelt durch i-doit 1.x
● Semantic Versioning
i-doit 2.0 → Verwendete Technologien → Backend → Symfony - Dependency Injection
● Bessere Strukturierung von Code
● DI Container Caching
● Ermöglicht u.a. tagged services
● Lazy Loading von Services
i-doit 2.0 → Verwendete Technologien → Backend → Symfony - Security
● Genutzt in Rechtesystem
○ Verwendet für User, Rechte, API
● Verschiedene Firewalls konfigurierbar
● Erweiterbar via Voter Interface
○ genutzt für Rechtesystem
● Password Encryption: Argon2i
i-doit 2.0 → Verwendete Technologien → Backend → Symfony - Messenger
● Library für Message Queues, auch synchron nutzbar
● Leicht erweiterbar für andere Queues
● Genutzt für indexierung von Suchergebnissen
i-doit 2.0 → Verwendete Technologien → Backend → Doctrine
● Nahtlose Integration in Symfony Ökosystem
● Erweiterbarer ORM für diverse Plattformen
● Migrationen für Updates
● i-doit 2.0 unterstützt:
○ MySQL: 5.7.8, 8.x
○ MariaDB: 10.2+
○ PostgreSQL: 9.5+
Verwendete TechnologienFrontend
● Wir nutzen 16.8.6 (16.0 wurde im September 2017 veröffentlicht)
● Semantic Versioning
● Große und erfahrene Community
● Effiziente Entwicklung durch Komponentenbasierte Entwicklung
● Saubere trennung von Frontend und Backend
React Angular Vue
i-doit 2.0 → Verwendete Technologien → Frontend → React
i-doit 2.0 → Verwendete Technologien → Frontend → Redux
● Umfangreicher Stand-Alone Store (oder “State Container”)
● Zentrale Stelle für Daten (State) - “one-way-binding”
● Sinnvolle Erweiterung zu React
● Entkoppelt Komponenten vom globalen State
● Konsistentes Verhalten durch strikt definierten Output
● Hervorragend Debug- und Testbar
i-doit 2.0 → Verwendete Technologien → Frontend → Sagas
● Middleware Bibliothek für Redux
● Sorgt (unter anderem) für asynchrone Anfragen an das Backend
● Vereinfacht Business Logik und Abhängigkeiten untereinander
○ (Redux) Reducers bleiben simpel
i-doit 2.0 → Verwendete Technologien → Frontend → SCSS
● CSS Compiler
● Durch Variablen eine einheitliche Definition
○ Schneller und einfacher anzupassen
● Übersichtliche Struktur: je Komponente, Container und Seite eine SCSS Datei
● Vererbung und Sinnvolle Funktionen, z.B. transparentize() , lighten() , darken() , …
● Durch Bootstrap v4.3 eine solide Grundlage (so viel wie nötig, so wenig wie möglich)
i-doit 2.0 → Verwendete Technologien → Frontend → Storybook
● Storybook ist “Styleguide 2.0”
● Interaktive Dokumentation / Spielwiese für React Komponenten
● Hilfreich für Designer und Entwickler
○ Lifecycle Events und Actions werden im Log dargestellt
© 2019 synetics GmbH
i-doit 2.0API
Referent: Kevin Mauel
© 2019 synetics GmbH
i-doit 2.0 → API → Agenda
Agenda
● Zielsetzung
● Unterschiede zu i-doit 1.x API
● Open API v3
● REST vs. JSON-RPC
i-doit 2.0 → API → Zielsetzung
● Vollständige und standardisierte API Spezifikation
● Einheitliches Verhalten bei Frontend und API
● Klare Strukturen bei API Design
i-doit 2.0 → API → Unterschiede zu i-doit 1.x API
● Teil von i-doit Kern
● Versionierung
● i-doit Frontend nutzt aktuellste Version von API
● Anstatt JSON-RPC nun REST
● Design folgt Spezifikation OpenAPI v3
● Dokumentation mittels OpenAPI v3
i-doit 2.0 → API → Open API v3
● Open API ist eine Spezifikation für API Beschreibungen
● Von OpenAPI Initiative
● Angaben von:
○ Server
○ Authentifizierung
○ Operationen
○ Request Parameter, Responses, Schemas
○ Media Typen JSON, XML
● Formate: YAML, JSON
i-doit 2.0 → API → i-doit 2.0 und Open API v3
● Command generiert Open API v3 Spezifikation (json, yaml)
● Alternativ: /api/openapi.json
● Spezifikation kann z.B. genutzt werden für:
○ Generierung von
■ API Dokumentation
■ User Interface
■ API Client (z.B. für PHP, Python, Java)
○ Prototyping z.B. mit Postman
i-doit 2.0 → API → Open API v3 → Spezifikation
49
i-doit 2.0 → API → Open API v3 → User Interface
50
i-doit 2.0 → API → Open API v3 → Client
51
i-doit 2.0 → API → Open API v3 → Postman
52
i-doit 2.0 → API → REST vs. JSON-RPC
REST
● CRUD api/v1/object/{id}
● Ergebnis entspricht Resource
z.B. api/v1/object = i-doit Objekt
● Z.b. 404 Response mit Response Body:
code: HTTP Status Code
message: z.B. Object not found.
● Subresources zur Strukturierung
z.B. api/v1/category/model/entry
JSON-RPC
● POST src/jsonrpc.php mit Request Body
● Ergebnis besteht aus:
JSON-RPC Version, beliebiges Result, id
● HTTP 200 mit error im Response Body
● POST src/jsonrpc.php
Vielen Dank!
Vielen Dank für eure Aufmerksamkeit!