Technologiën

From WOSI
Jump to: navigation, search

MySQL / MariaDB

MariaDB is een grotendeels compatible fork van de MySQL database server. We hebben deze keuze vooral gemaakt voor de integratie van de Galera cluster technologie. Galera maakt het mogelijk een multi-master cluster te maken. Iedere node in een Galera cluster heeft dezelfde gegevens en het is mogelijk naar iedere node te schrijven. Dat maakt de server-architectuur flexibel. Andere redenen zijn de TokuDB database engine, GIS functies en INNODB Fulltext index.

MongoDB

De belangrijkste rol van MongoDB in onze architectuur is het bewaren van bestanden in de GridFS extensie. Dit maakt vooral geografische distributie en backup gemakkelijker. Als de omvang van de bestanden sterk groeit, boven 500GB per database, is dit misschien niet meer de beste oplossing. Dan kunnen we kijken naar OpenStack Swift or Ceph. Met de ontwikkeling van de viewer voor gebouwen en de daaraan gekoppelde bestanden en eigenschappen zijn er steeds meer gegevens waarvan de structuur sterk uiteenloopt. In de toekomst zullen we MongoDB hier waarschijnlijk vaker gaan inzetten.

Web service / data layer

Spring

Spring is de basis van al onze webapplicaties. Het framework bind de verschillende onderdelen van de applicatie aan elkaar met dependency injection. Het zorgt voor de toegangscontrole met spring-security. Database transacties, url mapping, request binding en view resolution worden door spring afgehandeld.

Spring is een stabiel framework waar de ontwikkelaars bij updates veel aandacht besteden aan compatibiliteit met voorgaande versies. Het framework wordt veel gebruikt voor grote bedrijfsapplicaties. Dat betekend ook dat ontwikkeling en beveiligingsupdates niet zomaar zullen stoppen.

JPA/Hibernate

Bijna alle applicaties die wij maken zijn gebaseerd op een relationele database. Om de gegevens in de relationele vorm in de database om te zetten naar Java objecten in de applicatie gebruiken we een ORM. JPA is in de Java wereld de meest gebruikte interface voor ORM's. Hibernate is de implementatie die we gebruiken voor WOSI projecten. Dit is één van de meest uitgebreide en gebruikte ORM implementatie voor Java.

We proberen zo min mogelijk Hibernate specifieke uitbreidingen te gebruiken en ons te beperken tot de functies die JPA ons biedt. We gebruiken nu nog vooral JPA 2.0, maar we zijn bezig met updates naar 2.1 en Hibernate 5. Deze update brengt een aantal nuttige uitbreidingen, zoals @NamedEntityGraph.

QueryDSL

QueryDSL is een Java framework dat je in staat stelt type-safe query's te schrijven in een syntax die veel weg heeft van sql. QueryDSL genereert Java objecten die gebruikt kunnen worden om query's te bouwen. Dit zorgt er voor dat je bijna geen syntaxfouten meer kan maken. Je kunt geen fouten maken namen van velden en objecten. En het is gemakkelijk incrementele query’s op te bouwen.

Frontend / view layer

Server side

JSP

JSP is de view technologie achter het grootste deel van onze projecten. Wij gebruiken JSP puur als view. We staan niet toe om (complexe) logica op te nemen, daarom gebruiken we ook nooit scriptlets of andere manieren om Java code op te nemen.

JSP is een oude technologie die op veel verschillende manieren is gebruikt. Het is geen echte template engine, maar de jsp wordt gecompileerd naar een servlet. Die servlet dan wordt uitgevoerd voor elk request. In oude webapplicaties wordt alle logica ook in de jsp opgenomen. Dit zorgt voor applicaties die moeilijk zijn te onderhouden omdat ze de logica en de presentatie niet los van elkaar houden. Dit is echter geen inherente eigenschap van jsp, het is goed mogelijk om het te gebruiken in een MVC architectuur.

Thymeleaf

Thymeleaf is een moderne template engine waar we gebruik van maken in een aantal nieuwere applicaties, zoals Students Come & Go. Thymeleaf templates zijn over het algemeen iets beter leesbaar, omdat het dichter bij de html blijft die je uiteindelijk wil tonen. Thymeleaf is ook strikter dan JSP in wat toegestaan is. Losse variabelen aanmaken en toewijzen is bijvoorbeeld niet mogelijk. Dit is een voordeel, omdat dit een bron van fouten kan zijn. Vooral omdat deze variabelen in jsp een globale scope hebben.

Client side

React

Voor nieuwe Javascript componenten gebruiken we meestal de React library. In theorie is het natuurlijk altijd mogelijk geweest om Javascript-applicaties zonder framework te schrijven, maar de complexiteit bij grote applicaties loopt dan al snel uit de hand. Een framework zoals React biedt hulpmiddelen en een vaste structuur om een grote Javascript-applicatie te kunnen schrijven. Net als MVC frameworks aan de server-kant helpt om domein logica en view logica te scheiden, doen Javascript frameworks het vergelijkbare aan de client-kant.

Een typische jQuery applicatie werkt door middel van DOM manipulatie. Dus bijvoorbeeld, je controleert of het ingevoerde bedrag een juist formaat heeft, en maakt de input rood en schakelt de submit button uit. Of, een gebruiker typt iets in een zoekscherm, en vervolgens vul je een tabel met zoekresultaten door de rijen leeg te maken en daarna te vullen. Als de applicatie groter wordt, is het lastig om al dit soort interacties onder controle te houden. Het is makkelijk om bugs te introduceren. Bijvoorbeeld een script die om een andere reden de staat van de submit knop manipuleert, en daardoor de check voor het juiste bedrag overschrijdt. Of, als er een jQuery plugin is om een fancy popup te tonen, vergeten deze opnieuw te initialiseren bij nieuw aangemaakte zoekresultaten.

Een Javascript-framework helpt om de staat van de applicatie los te houden van de representatie ervan. Dus je definieert van te voren een datamodel van wat er in de UI kan veranderen, en bij het renderen gebruik je datzelfde datamodel (net als MVC). Ook wordt de flow van acties expliciet gemaakt (geen wirwar van event handlers).

Een React component is in feite een functie met argumenten en interne staat als invoer, en HTML als uitvoer. Hierdoor zijn de componenten eenvoudig te hergebruiken, en wijzigingen in hun staat makkelijk te volgen. Je kunt ze bv. ook eenvoudig nesten, iets wat lastig is met jQuery. Omdat het opnieuw renderen van het gehele component bij iedere wijziging erg zwaar zou zijn, gebruikt React intern een “virtual DOM” samen met een diffing algoritme. Hiermee worden alleen wijzigingen in het DOM direct gerenderd. Dit maakt React één van de snelste Javascript frameworks.

Het gebruik van state-management libraries voor React (bv. Redux of MobX) zijn we nog aan het onderzoeken. React heeft een ingebouwde state dat goed genoeg is voor veel "losstaande" componenten. Maar om interacties in kleine sub-componenten door te geven aan hoofdcomponenten (in een complexe app) is vaak veel code/boilerplate nodig. Hierbij helpen libraries zoals Redux of MobX.

Three.js / WebGL

WebGL is een Javascript API dat mogelijk maakt om interactieve 3D visualisaties te tonen binnen een browser. WebGL is gebaseerd op de OpenGL ES 2.0 standaard en heeft een vrijwel identieke API. OpenGL is een redelijk “kale” en op C gebaseerde API, er worden bijvoorbeeld geen functies geboden om een textures vanuit een afbeelding in te laden, of wiskundige functies om met vectoren of matrices te werken. Ook ben je in OpenGL ES geforceerd om shaders en vertex buffers te gebruiken, er bestaan geen functies om direct bv. een driehoek te tekenen. Omdat er relatief veel code nodig om een simpele 3D visualisatie in WebGL te maken, wordt meestal een library gebruikt. De meest populaire en uitontwikkelde library hiervoor is Three.js.

Three.js biedt een object-georiënteerde API om een 3D scene te maken en geometrie toe te voegen. Dit maakt het ontwikkelen van WebGL applicaties sneller. Je kunt er uiteraard nog steeds alle geavanceerde WebGL-features mee gebruiken, in de situaties waar dat nodig is.

Three.js wordt binnen OGDB gebruikt om 3D visualisaties te maken van IFC bestanden (IFC Foundation Classes). Dit is een open standaard voor het omschrijven van bouwkundige modellen. Deze worden gemodelleerd in programma’s zoals Autodesk Revit of ArchiCAD, en bevatten een vrijwel compleet informatiemodel over het gebouw zoals alle geometrie, elementcoderingen (NL-SfB), materialen en afmetingen. Het is zeer uniek dat we in staat zijn om dit binnen een webbrowser te visualiseren. Er zijn maar weinig andere viewers met vergelijkbare laadtijd en performance, om dit mogelijk te kunnen maken zijn diverse optimalisatietechnieken geïmplementeerd.

Er zijn nog veel mogelijkheden tot uitbreiding in de viewer die we nu onderzoeken. Zoals WebVR-support, verbeterde visualisaties (belichting, schaduw), en geavanceerde data-koppelingen.

Node.js / Webpack

Voor applicaties die React gebruiken hebben we Node.js en webpack geïntegreerd. Dat brengt een hoop voordelen met zich mee. Via npm (de package manager voor Node) kun je van een hele grote repository van javascript libraries gebruik maken (bijna een half miljoen). Je hoeft dan niet meer (minified) Javascript bestanden van libraries naar je projectmap te kopieëren, net zoals je dat (hoop ik 🙂) niet meer met jar bestanden doet. Daarnaast kunnen we allerlei build tools en preprocessors gebruiken. Webpack wordt gebruikt voor het samenvoegen en minifyen van alle Javascript bestanden. Bij dit build proces (via gulp) wordt Babel aangeroepen, een transpiler die je in staat stelt de meest recente Javascript standaard te gebruiken (ECMAScript 6), maar dit nog steeds te kunnen draaien op browsers die het nog niet ondersteunen (IE11). ECMAScript 6 heeft veel modernisaties en maakt het eenvoudig om object-georiënteerd Javascript te schrijven. Via hetzelfde build proces draaien we ook CSS preprocessors (SASS, Stylus) om beter CSS te kunnen schrijven (variabelen, mixins, etc.).

Overig

Python

OpenLayers / WFS / WMS

Raspberry Pi