Bessere UX dank ausgereifter Backend-Infrastruktur

No Backend needed?

Dirk Dorsch

© istockphoto.com / bgblue

App, Web, Mobil, Desktop – who cares? Softwareportale für Endkonsumenten haben sich in den letzten Jahren dahingehend entwickelt, dass neben einer Mobile-First- bzw. responsiven Webseite für die einzelnen Smartphoneplattformen korrespondierende Apps in den jeweiligen Stores zur Verfügung stehen. Wegen dieser Vielfalt an Clients ist es essenziell, bestimmte Funktionalitäten wie Benutzeraccounts und Datensynchronisation allen Plattformen zur Verfügung zu stellen. Mit (m)BaaS, MEAP oder noBackend haben sich ähnliche Konzepte entwickelt, die es dem Entwickler einfach machen wollen, diese Anforderungen zu bedienen.

Facebook, Twitter, Flickr und all die anderen Social-Media-Dienste haben es vorgemacht: In allen Lebenslagen, auf allen Geräten und Plattformen sind ihre Dienste mit einem ähnlichen Funktionsumfang verfügbar. Die klassische Desktopwebsite wird durch responsive Ansätze um einen mobil tauglichen Output-Channel ergänzt. Neben diesem (responsiven) Webauftritt erwartet man heute aber auch native Applikationen für Tablets und Smartphones. Bei der täglichen Nutzung von Xing, Facebook, Twitter und Co. ist dies bereits zur Selbstverständlichkeit geworden: Im Zug werden schnell die neuesten Xing-Kontakte bestätigt, ausführlichere Geschäftsanbahnungen werden dann im Büro vom PC aus erledigt, und am Abend wird auf der Couch noch das Profil mit dem Tablet gepflegt. Die Daten sind selbstverständlich auf allen Plattformen synchron und mit dem Benutzeraccount verknüpft.

Während die Daten sozialer Netzwerke aufgrund ihrer starken Dynamik inhärent online abgerufen werden müssen, haben andere Anwendungen höhere Anforderungen, was die Offlinefähigkeit betrifft. Als Beispiel können digitale Kongressplaner dienen. Auch diese bieten ein klassisches Webangebot und ebenso die obligatorischen Apps. Ein typisches Nutzungsszenario ist hier das Zusammenstellen des persönlichen Konferenzprogramms am heimischen PC und dessen Überarbeitung – wie das Leben so spielt, vermutlich in einem Funkloch – während der Zugfahrt. In solch einem Scenario sind das Synchronisieren der Programmdaten und der Austausch des persönlichen Programms zwischen PC und Smartphone unabdingbare Funktionen. Als noch trivialeres Beispiel kann eine To-do-Applikation dienen. Auch hier ist die Erwartungshaltung, dass, je nachdem, welches Device verfügbar ist, die To-dos auf dem Smartphone ebenso wie in einem Internetcafé im Netz verfügbar sind. Bereits diese beiden einfachen Anwendungsfälle benötigen eine minimale Backend-Infrastruktur. Mindestanforderungen hier sind eine zentrale Datenhaltung, die eine Datensynchronisation ermöglicht, und eine Nutzerverwaltung, die sicherstellt, dass personalisierte Daten (hier die To-dos bzw. das persönliche Kongressprogramm) nur vom angemeldeten Nutzer selbst gelesen und bearbeitet werden können.

Entwicklungsansätze wie Design-First oder Behaviour-driven Development prägen einen Trend zum „Frontend-First“-Ansatz. Insbesondere bei Apps im Endkonsumentensegment steht eine gelungene User Experience immer stärker im Vordergrund. Eingefleischte Smartphonenutzer erwarten von einer App ein Höchstmaß an „Joy-of-Use“. Als Entwickler genügt es also nicht mehr, eine App oder eine Webseite am Reißbrett zu entwerfen. Lean Startup und Rapid Prototyping werden angewandt, um schnellst möglich mit Benutzertests Feedback über das Konzept einzuholen. Es bleibt wenig Zeit, sich über eine ausgereifte Backend-Infrastruktur Gedanken zu machen, will man doch schnellstmöglich die UX-Konzepte verifizieren.

In der mobilen Softwareentwicklung ist dieses Vorgehen schon lange verbreitet. Apps können zunächst mit ausgemockter Serverlogik entwickelt und so schnellstmöglich ersten Nutzertests unterzogen werden. Da viele mobile Applikationen zumindest grundlegende Backend-Dienste benötigen, hat sich in den vergangenen Jahren eine Reihe von Mobile-Backend-as-a Service-(mBaaS-)Projekten etabliert. Mit noBackend wird dieser Ansatz zu einer Bewegung und hält nun auch Einzug in die Webentwicklung.

Immer mehr Webprojekte haben einen ebenso hohen Anspruch an die User Experience wie mobile Apps. Die hohen Latenzzeiten klassischer Multipage-Anwendungen stehen dieser jedoch entgegen. Durch JavaScript Data Binding und MVC-Frameworks wie AngularJS, Ember oder Backbone haben es Webentwickler mittlerweile leicht, das serverseitige Templating auf den Client zu verlagern und nur noch Daten über (REST) Services vom Server zu beziehen. Die Reaktionszeiten auf Benutzerinteraktionen werden so minimiert. Die Konsequenz des clientseitigen Templating ist, dass das klassische Webframework nun kein HTML mehr ausliefert, sondern nur noch Backend-Dienste als API zur Verfügung stellen muss.

Das minimale Funktionsset ist bei nahezu allen Out-of-the-box-Lösungen, unabhängig davon, ob sie unter (m)BaaS oder noBackend firmieren, die zentralisierte Datenhaltung sowie eine Benutzerverwaltung. Einige Anbieter gehen weit über diese Funktionen hinaus und bieten Push-Services, Messaging und Conversation-Funktionen oder Enterprise-Konnektoren. Doch wie weit kommt man damit wirklich, und wo liegt mit Blick auf das gesamte Projekt der Mehrwert? Im Folgenden werden einige alternative Ansätze skizziert, die für unterschiedlich komplexe Aufgaben genügen können. Abschließend soll ein kurzer Ausblick auf die Do-it-yourself-Alternative gegeben werden.

Datenbank in der Cloud

Die Anforderung, Daten über die unterschiedlichen Devices eines Nutzers hinweg zu synchronisieren, ist bereits mit einer zentralisierten Datenbank möglich. Ein „as-a-Service“-Ansatz für die Datensynchronisierung muss in der Lage sein, unterschiedlichste Daten verarbeiten zu können. Diese Anforderungen legen den Einsatz von schemalosen NoSQL-Technologien nahe.
JavaScript-Bibliotheken und ebenso die Ökosysteme der mobilen App-Entwicklung bieten eine abstrahierte Form der Datenübertragung zwischen Client und Server. Im Web schon immer das Standardaustauschformat, haben die wichtigsten Mobile-Plattformen ebenso JSON als Format der Wahl etabliert. REST und JSON-over-HTTP ermöglichen eine leichtgewichtige Anbindung serverseitiger Datensynchronisationsschnittstellen. Für einen ersten Ansatz genügt es also, eine dünne Schnittstelle zur Verfügung zu stellen, um JSON zu speichern und auszuliefern. Dies ist beispielsweise mit CouchDB out of the box möglich.

CouchDB ist eine dokumentenorientierte Datenbank, die sich neben einem bereitgestellten REST-API insbesondere durch ihr integriertes Replikationsprotokoll auszeichnet. Obwohl dieses maßgeblich für serverseitige Skalierungsaspekte eingesetzt wird, lässt es sich auch instrumentieren, um eine Datensynchronisation über mehrere Devices zu implementieren. Mit PouchDB steht eine JavaScript-Implementierung des Couch-Protokolls zur Verfügung, die das Replikationsprotokoll in JavaScript zur Verfügung stellt. Auf Basis von Web SQL oder IndexedDB lassen sich mit PouchDB somit offlinefähige, synchronisierte Webanwendungen realisieren. Eingebettet in einen JavaScript-basierten Cross-Platform-Ansatz lässt sich PouchDB als vollständige, dokumentenorientierte Persistenzlösung mit Synchronisationsmechanismus auch in mobilen Applikationen einsetzen. Listing 1 zeigt den für eine Synchronisation/Replikation hierfür benötigten Code.

Listing 1
var localDb = 'myLocalDB';
var remoteDb = 'https://myIris.iriscouch.com/myRemoteDB';
// Download aus der Cloud
PouchDB.replicate(remoteDb, localDb, callback);
// Upload in die Cloud
PouchDB.replicate(localDb, remoteDb, callback)

Eine einfache Benutzerverwaltung inklusive Zugriffsberechtigung auf Datensätze kann über eine Couch ebenso implementiert werden. Nutzer können über HTTP in JSON-Dokumenten angelegt und bearbeitet werden. Die Zugriffsbeschränkung kann durch eine entsprechende Struktur der Dokumente realisiert werden. Betriebliche Aspekte einer Couch-Lösung können durch Rückgriff auf Cloud-Dienste wie IRIS oder Cloudant zunächst außer Acht gelassen werden.

Ist ein Projekt auf native Smartphone-Apps beschränkt, so kann ein ähnlicher Ansatz mit dem Couchbase Mobile Stack aufgebaut werden. Couchbase Mobile setzt sich aus dem Couchbase-Server, dem Couchbase Sync Gateway und der eingebetteten Datenbank Couchbase Lite für iOS, Android und Windows zusammen.

Darf’s ein bisschen mehr sein? – (m)BaaS/noBackend

Auf die Anwendungsfälle der serverseitigen Datenspeicherung und Authentifizierung fokussiert, hat sich eine breite Auswahl an (m)BaaS- und noBackend-Lösungen entwickelt. Ein Backend lässt sich sowohl aus Open-Source-, On-Premise-gehosteten-Systemen als auch aus kommerziellen Cloud-Diensten zusammensetzen. Ein wesentlicher Unterschied zwischen den kommerziellen und den Open-Source-Vertretern ist das Hosting-Modell. Hier sind die Open-Source-Lösungen stärker auf das On-Premise-Hosting ausgelegt, bieten jedoch teilweise ebenso kostenpflichtige Cloud-Dienste an. Entgegen den kommerziellen Anbietern bietet keine der Open-Source-Technologien eine integrierte Analytics Suite. Diese lässt sich jedoch beispielsweise in Form von Countly, Piwik oder Google Analytics nachrüsten.

Tabelle 1 und Tabelle 2 geben eine Übersicht über die wesentlichen Features einiger Technologien aus dem Open-Source- respektive dem kommerziellen Bereich. Die vorgestellten Lösungen bieten lediglich eine Auswahl aus vorhandenen Optionen, um die Vielfalt sowie das zu erwartende Funktionsspektrum vorzustellen. Insbesondere einige der kommerziellen Lösungen bieten ein weit über den vorgestellten Umfang hinausgehendes Featureset wie beispielsweise Media-Streaming. Welche der Out-of-the-box-Lösungen in Frage kommen, und ob diese überhaupt die Projektanforderungen befriedigen können, muss im Einzelfall projektabhängig entschieden werden.

Neben den Anwendungsfällen der Datensynchronisation und der Authentifizierung haben sich einige Plattformen stark spezialisiert. So bieten beispielsweise UserApp und Hull ein breites Featureset an nutzerzentrischen Anforderungen wie Nutzerprofile, Social-Login-Integrationen oder Messaging- und Konversationsfunktionen. Stärker auf die Aspekte der Datenhaltung/Synchronisation ausgelegt sind Firebase oder die Open-Source-Plattform hood.ie, die beispielsweise einen clientseitigen E-Mail-Versand mit JavaScript ermöglicht. Parse, 2013 von Facebook akquiriert, erweitert das Funktionsspektrum um Push Notifications und bietet SDKs für nahezu jede Plattform. Ein Open-Source-Vertreter, der ebenfalls Push Notifications bietet, ist BAASBOX. Ein ebenso für das On-Premise-Hosting zur Verfügung stehendes Open-Source-Projekt, das darüber hinaus die Integration eigener Geschäftslogik ermöglicht, ist deployd. Für den Einsatz in Enterprise-(Mobility-)Projekten positionieren sich beispielsweise Kinvey und Backendless. Als „Enterprise BaaS“ bieten diese, neben der Integration eigener Geschäftslogik, auch eine Reihe von vorgefertigten Enterprise-Konnektoren zur Integration existierender Systeme wie CRM- oder ERP-Systeme. Als deutscher Vertreter wartet apiOmat mit einem ebenso ausgereiften Featureset inklusive einer Vielzahl von Enterprise-Konnektoren auf.

Tabelle 1: Open-Source-(m)BaaS/noBackend-Projekte

Tabelle 1: Open-Source-(m)BaaS/noBackend-Projekte

Tabelle 2: Kommerzielle (m)BaaS-/noBackend-Projekte

Tabelle 2: Kommerzielle (m)BaaS-/noBackend-Projekte

Einmal alles, bitte: Mobile-Enterprise-Application-Plattform (MEAP)

Während sich (m)BaaS-Ansätze im Allgemeinen auf die Bereitstellung passender Clientbibliotheken zur Integration der Backend-Dienste beschränken, gehen MEAPs einen Schritt weiter: Sie verbinden die Konzepte von Mobile-Application-Plattforms (also Cross-Platform-Frameworks) mit den von (m)BaaS bzw. noBackend her bekannten Backend-Bedürfnissen von Enterprise-Mobility-Anwendungen. Mit OpenMobster, OpenMEAP und Convertigo sind in diesem Segment auch (Semi-)Open-Source-Lösungen vertreten. Etablierte Vertreter auf dem kommerziellen Sektor der MEAPs sind Appcelerator oder auch Motorolas Rhomobile. Auch die Großen scheinen den Markt für sich entdeckt zu haben. So bieten IBM, SAP und Oracle mit Worklight, SAP Mobile Platform und ADF mobile Komplettlösungen an. Hierbei finden sich aufeinander abgestimmte Client- und Serverbibliotheken, die in einer einheitlichen Entwicklungsumgebung die Entwicklung von Client- und Serverkomponente ermöglichen. MEAPs bieten ein abgestimmtes Rundumpaket aus (Enterprise-)mBaaS und (Cross-Platform-)Clientframework. Die bei mBaas bzw. noBackend noch im Wesentlichen auf die Serverseite beziehungsweise deren Anbindung beschränkte Technologieabhängigkeit weitet sich jedoch auf die Clientseite aus.

Genug oder schon zu viel?

Insbesondere die featurereichen mBaaS-Vertreter und MEAP-Ansätze stellen eine große Verlockung dar, bieten sie doch auf den ersten Blick 90 Prozent von allem, was eine App braucht. Aber braucht man das alles? Oder zählen die fehlenden 10 Prozent? Diese Fragen lassen sich sicher nur im projektspezifischen Einzelfall entscheiden. Eine kleine App mit Cloud-Datensicherung lässt sich wie beschrieben bereits mit dem Couch-Ansatz bewerkstelligen. Je nach Wahl kann ein mBaaS noch einiges mehr an Infrastrukturfunktionalität bieten, wie beispielsweise Push Notifications oder Enterprise-Konnektoren. Die Möglichkeiten, eigene serverseitige Geschäftslogik zu integrieren, ermöglicht es letztendlich, nahezu alle Anforderungen umzusetzen. An diesem Punkt, und insbesondere bei der Wahl eines MEAPs, verliert sich allerdings auch die Leichtigkeit des Ansatzes, da die eigene Geschäftslogik stark an das gewählte Framework gekoppelt wird. Es sollte sorgfältig geprüft werden, welcher infrastrukturelle Funktionsumfang wirklich benötigt wird und ob sich Lernkurven, Lizenzen und Abhängigkeiten bis hin zu einem schichtenübergreifenden Vendor-Lock-in lohnen.

Als leichtgewichtigere Alternative soll abschließend anhand eines einfachen Beispiels ein „herkömmlich selbstgestricktes“ Backend in Kombination mit einem PaaS-basierten Hosting betrachtet werden.

To-do-App – Mit „Hello World“ die Grenzen ausloten

Eine To-do-App soll auf einem Android-Smartphone funktionieren, sich mit einem iPad synchronisieren und, wenn alle Batterien leer sind, auch als Online-Web-App zur Verfügung stehen. Es gibt To-dos, die nicht selbst erledigt werden können und an die Community „outgesourct“ werden sollen. Übernimmt ein Communitymitglied ein To-do, soll eine E-Mail-Benachrichtigung verschickt werden, da diese, im Gegensatz zu Push Notifications, auf allen Plattformen, also auch auf einem Laptop, ankommt.

Das Synchronisieren über alle Geräte hinweg kann bereits mit dem ersten Ansatz realisiert werden. Eine CouchDB oder -Base synchronisiert über den Replikationsmechanismus und bietet ein REST-API für CRUD. Auch kann ich hier eine „Community“ aufbauen und diese ebenso über ein API als Datenbankuser anlegen. Das Zuweisen an andere ist prinzipiell ebenso einfach möglich. Selbstverständlich lassen sich diese Anforderungen auch mit den leistungsstärkeren mBaaS-, noBackend- oder MEAP-Konzepten realisieren.

Jedoch erfordert bereits der Mailversand nach Akzeptieren eines To-dos durch ein Communitymitglied die ersten Zeilen eigener Geschäftslogik. Auch das lässt sich mit den meisten genannten Ansätzen realisieren, jedoch muss diese als „Hook“ in die durch die Frameworks zur Verfügung gestellte Standardfunktion des To-do-Speicherns integriert werden. Der zur Integration in das Framework notwendige Code kann an Menge und Komplexität die eigentliche Geschäftslogik schnell übersteigen.

Zurück zu den Anfängen: PaaS

Insbesondere im frühen Stadium eines kleineren Projekts ist es wünschenswert, sich keine Gedanken über die operativen Aspekte machen zu müssen. Zu diesem Zweck haben sich schon seit Längerem PaaS-Lösungen in der Cloud etabliert. Pivotal, Bluemix, Heroku oder OpenShift bieten beispielsweise PaaS-Infrastrukturen, die das professionelle Hosting mit wenigen Kommandozeilenbefehlen ermöglichen. Je nach gewähltem Anbieter lassen sich die Basisfunktionen Persistenz und E-Mail-Versand aus unterschiedlichen Technologien und Dienstanbietern zusammenstellen. Auch Analytics Suiten oder ganze Big-Data-Cluster lassen sich den Anforderungen entsprechend hinzubuchen. Die Basisinfrastruktur steht somit schnell. Es fehlt noch das Backend für die Geschäftslogik. Für den Fall der beschriebenen To-do-App soll im Folgenden ein kurzer Überblick gegeben werden, wie sich die Anforderungen, funktionaler wie auch nicht funktionaler Art, in wenigen Stunden mit dem Webframework Grails umsetzen lassen.

Grails hat sich in den letzten Jahren als agiles und leichtgewichtiges Webframework in der Java-Welt etabliert. Das Ökosystem hat sich rasant entwickelt und bietet zu fast jeder bekannten Java-Technologie entsprechende Plug-ins, die die Integration erleichtern.

Briefe schreiben mit Grails

JavaMail ermöglicht die Integration von E-Mail-Versand, zwar nicht mit schönem, aber überschaubarem Code, in die eigenen Applikationen. BaaS-Lösungen bieten lediglich eine Abstraktion und einen vorkonfigurierten E-Maildienst. Während Letzterer auch über oben genannte PaaS-Lösungen zu haben ist, bietet das Spring Framework eine angenehme Abstraktion über das JavaMail-API. Das Versenden von E-Mails beschränkt sich so auf wenige Zeilen, und es kann sich auf die Erstellung des E-Mailinhalts konzentriert werden. Das Grails-Mail-Plug-in ermöglicht ein DSL-artiges Versenden von E-Mails. Nach der Installation in Build.groovy durch Setzen von compile „:mail:1.0.7“ als Plug-in Dependency kann das Plug-in wie in Listing 2 gezeigt in Config.groovy konfiguriert werden. Der Versand der E-Mail kann zusätzlich in einem Service, wie in Listing 3 gezeigt, gekapselt werden.

Listing 2
grails {
  mail {
    // Beispiel mit Nutzung eines Send-Grid-Accounts
    host = "smtp.sendgrid.net"
    port = 465
    username = "kryptischerusername"
    password = "kryptischespassword"
    props = 
      ["mail.smtp.auth": "true",
       "mail.smtp.socketFactory.port": "465",
       "mail.smtp.socketFactory.class": "javax.net.ssl.SSLSocketFactory",
       "mail.smtp.socketFactory.fallback": "false",
       "mail.smtp.starttls.enable": "true"]
  }
}
Listing 3
class MyMailService {
  // Service Bean des Plug-ins
  def mailService;

  void mail(User receiver, String subject, String from, String body) {
    if(receiver.email) {
      mailService.sendMail {
        async true
        to receiver.email
        from from
        subject subject
        body body
      }
    }
  }
}

Sicherheit mit Spring

Spring Security ist der De-facto-Standard für Sicherheitsaspekte in Spring-basierten Applikationen. Seit frühesten Versionen von Grails gibt es das korrespondierende Spring-Security-Core-Plug-in. Als Erweiterung gibt es mit Spring Security UI eine Oberfläche zur Benutzerverwaltung und mit Spring Security ACL eine Lösung für die eingeschränkte Zugriffskontrolle auf Datensätze. Durch die Integration von Spring Security lassen sich leicht Social-Logins wie „Login with Facebook“ in das eigene Backend einfügen. Fortgeschrittene Anforderungen wie Remember Me und rollenbasierte Zugriffsbeschränkungen werden ebenso unterstützt wie die Anbindung eines LDAPs im Enterprise-Umfeld. Die Installation erfolgt analog zum Mail-Plug-in über das Setzen der Plug-in Dependency compile „:spring-security-core:2.0-RC4“. Das Plug-in bietet Skripte für die Generierung der notwendigen Klassen für Rollen und Nutzer. Als Sicherheitsframework für Webapplikationen bietet das Plug-in bereits alle notwendigen Komponenten für ein formularbasiertes Login. Als Login-API können die Parameter j_username und j_password an den URL …/ j_spring_security_check als POST-Request geschickt werden. Der Logout geht intuitiv über einen POST an …/logout. Das Abrufen der Daten des aktuell angemeldeten Nutzers sowie ein API für eine Registrierung sind in Listing 4 skizziert.

Listing 4
class RegisterController {
def springSecurityService

def register() {
def user = new User(params);
if( user.validate( ) ) {
user.save(flush:true)
render user as JSON
} else {
def errors = user.errors.allErrors.collect{
["${error.field}":"${error.rejectedValue}"]
}
def map = ['error':errors]
response.setStatus(403)
render map as JSON
}
}

def current() {
def user = springSecurityService.currentUser
Map map = user ? ['username':user.username,
'email':user.email,
'id':user.id] : [:]
render map as JSON
}
}

Grails für den REST

Während E-Mail-Versand und Benutzerverwaltung durch vorhandene Plug-ins integriert werden können, kann das für die Datensynchronisation notwendige REST-API mit Grails-Bordmitteln realisiert werden. Der Scaffolding-Mechanismus von Grails ermöglicht neben Views für alle notwendigen CRUD-Operationen auch ein vollständiges REST-API für das Erzeugen, Lesen, Aktualisieren und Löschen von Daten. Es genügt, wie in Listing 5 gezeigt, die Domänenklasse Todo mit der Resource-Annotation zu versehen.

Listing 5
@Resource(uri='/todos')
class Todo {
  boolean done;
  String summary;
  String description;
} 

Die Definition dieser Domänenklasse ist bereits ausreichend und liefert alle benötigten URLs. Auf dieser Basis lässt sich eine erste serverseitige Datenhaltung bzw. Synchronisierung realisieren. Wie bei anderen Out-of-the-box-Lösungen auch, funktioniert das Scaffolding nur, solange man sich mit der Standardfunktionalität zufriedengeben kann. Soll, wie im beschriebenen Use Case gewünscht, weitere Logik integriert werden, muss der Pfad der Konventionen verlassen werden. Neben dem Scaffolding des REST-API bietet Grails auch eine Basisklasse für das Implementieren von eigenen REST-Controllern. Auf diese Art kann die gewünschte Funktionalität leicht integriert werden.

Zum einen soll nur der Erzeuger eines Todos diese ändern dürfen, und zum anderen soll bei der Zuweisung an einen anderen Benutzer dieser eine E-Mail-Benachrichtigung erhalten. Sofern die vorgestellten Plug-ins installiert sind, kann diese Anforderung ohne großen Aufwand umgesetzt werden. Der in Listing 6 gezeigte Controller implementiert eine erste Variante der Zugriffsberechtigung. Der bedingte E-Mail-Versand kann alternativ wie in Listing 7 veranschaulicht mit der AOP-Abstraktion von Grails realisiert werden. Über einen before-filter wird vor dem Aufruf der eigentlichen Updateaktion geprüft, ob ein Todo einem anderen Nutzer zugewiesen werden soll; entsprechend wird der E-Mail-Versand angestoßen.

Listing 6
class TodoController extends RestfulController {
  static responseFormats = ['json', 'xml']
  def springSecurityService;

  TodoController() { super(Todo) }
  
  // Automatisches Setzen des angemeldeten Users als Owner und Assignee
  @Override
  protected Todo createResource() {
    if( springSecurityService.currentUser == null ) return null;
    Todo todo = super.createResource()
    todo.owner = springSecurityService.currentUser
    todo.assignee = springSecurityService.currentUser
    return todo;
  }
  // Gibt das angeforderte Objekt nur zurück, wenn der angemeldete User
  // Owner oder Assignee ist. Schützt vor unerlaubtem Lesen oder Schreiben.
  @Override
  protected Todo queryForResource(Serializable id) {

    def userId = springSecurityService.currentUser.id
    return Todo.where {
      id == id && (assignee.id == userId || owner.id == userId )
    }.find()
  }
  protected List listAllResources(Map params) {
    def userId = springSecurityService.currentUser.id
    Todo.where {
      id == id && (assignee.id == userId || owner.id == userId )
    }.findAll()
  }
}
Listing 7
class ReassignedFilters {
  def springSecurityService;
  def simpleMailService;

  def filters = {
    all(controller:'todo', action:'update') {
      before = {
        def userId = springSecurityService.currentUser.id
        Todo todo = Todo.where {
          id == id && (assignee.id == userId || owner.id == userId )
        }.find()
        if( todo && params.assignee) {
          if(todo.assignee.id != params.assignee) {
            simpleMailService.reassignedMail(…);
          }
        }
      }
    }
  }
}

Fazit

Zweifellos bieten mBaaS- und noBackend-Ansätze in Frontend-getriebenen Entwicklungsprojekten ein stark beschleunigtes Projekt-Set-up. Auch ist der Weg zu einem ersten echten Prototyp mit Backend-Integration kurz. Insbesondere in einfachen Projekten bieten diese klare Vorteile hinsichtlich der Time to Market. Andererseits sind gerade die Basisfeatures solcher Lösungen auch mit geringem Aufwand selbst zu realisieren. Ein Hosting in einer PaaS-Cloud-Plattform ermöglicht auch bei einem DIY-Ansatz ein schnelles „Go-live“ und eine dynamische Skalierung der Ressourcen im Verhältnis zum Wachstum des Geschäfts. Werden fortgeschrittene Anforderungen, beispielsweise an die Datensicherheit, an ein Projekt gestellt, lassen sich Alternativen wie beispielsweise der E-Mail-Versand nicht mehr so leicht nachrüsten. Kleinere Projekte mögen den Einsatz eines schwergewichtigen MEAPs auf den ersten Blick nicht rechtfertigen. Der richtige Ansatz ist also im projektspezifischen Einzelfall sorgfältig auszuwählen.

Geschrieben von
Dirk Dorsch
Dirk Dorsch
Dirk hat seit 2008 nahezu alle Rollen in der Java-basierten (mobile) Enterprise-Entwicklung durchgemacht. In den Jahren als Entwicklungsleiter vermisste er das Hands-on und legt nun den Fokus wieder auf die Entwicklung.
Kommentare

2
Hinterlasse einen Kommentar

avatar
4000
2 Kommentar Themen
0 Themen Antworten
0 Follower
 
Kommentar, auf das am meisten reagiert wurde
Beliebtestes Kommentar Thema
2 Kommentatoren
Dirk DorschMichael Reiserer Letzte Kommentartoren
  Subscribe  
Benachrichtige mich zu:
Michael Reiserer
Gast

Ein interessanter Vergleich – und sehr umfangreich. Als Vertreter von apiOmat noch folgende Ergänzung: bei apiOmat gibt es SDKs für Java, PhoneGap, Titanium, cURL, PHP und Python ebenfalls…

Dirk Dorsch
Gast
Dirk Dorsch

Hallo Herr Reiserer,
vielen Dank für Ihren Hinweis, diese habe ich offensichtlich leider übersehen. Insbesondere PhoneGap und Titanium sind natürlich bei einem Fokus auf mobile Clients eine Erwähnung wert.