Kleine Ergänzung: Falls jemand von euch mit mir arbeiten möchte, ich bin ab ungefähr Mitte des Jahres wieder für neue Projekte zu haben. Konkrete Fragen zu dem Thema beantworte ich aber auch gerne per Mail. Andere Leute mit Erfahrungen in dem Bereich in Hamburg sind Manuel Wiedenmann und Adam Hawkins.

EmberJS mit Rails

EmberJS

• Opinionated JS Framework
• Wird verwendet von:
  • Yahoo
  • Netflix
  • Travis CI
  • Zendesk
  • Bustle
  • NBC News
  • Runtastic
  • Code School
  • Discourse
  • Ghost
  • Living Social
  • Vine.co
  • Harvest
  • Nest (gekauft von Google)
  • ...
  • Beispiel:
• Viele unabhängige Unternehmen, die mit Ember Apps schon heute Geld verdienen
• Qualität für den Produktionseinsatz bewiesen
• Weiterentwicklung sichergestellt, Ökosystem vorhanden

EmberJS

• Framework für Single Page Apps
• Aus einem Guss
• Convention over Configuration
• Man findet sich schnell zurecht
• Aus einem Guss
• In Ember sind zig Probleme, die einem als Entwickler begegnen, schon gelöst, z.B. Routing (State), Datei-Organisation, asynchroner Datenaustausch mit Assoziationen etc.
• Relativ groß
• Framework lock-in
  
• Verwendet eigene Getter/Setter
  • Unschöner als POJOs (object.get('attribute') vs. object.attribute)
  • Man bekommt dafür tolle Features und alles ist rock solid
  • Schneller und oft stabiler als Angular (das watcher/notifier verwendet)
  • Man kann alles mit Ember.Object wrappen, z.B. LocalStorage

EmberJS vs. Angular

• EmberJS:
  • "A framework"
• Angular:
  • "A framework to build frameworks"
  • "Angular isn't a framework; it's an HTML compiler"

Angular

• Klein (der Code selbst, Abhängigkeiten)
• Weniger Konventionen
• Macht weniger als Ember
• Viele Wege
• Google hat bis jetzt keine User-facing-App mit Angular entwickelt
• Angular 2.0 wird ein kompletter Rewrite, Kompatibilität mit aktuellen Anwendungen unbekannt
• Supportet Google nach Erscheinen von v2.0 noch 1.0, obwohl sie es selbst nicht nutzen?

Wie geht Ember?

Router

• State
• URL kopieren, Tab zu, URL pasten, alles wie vorher
• Sorgt dafür, dass Models verfügbar sind
• Unterstützt History-API ("/foo" anstatt "/#/foo")

Template

• Handlebars
• Wie Rails Views
• Schnurrbart-Platzhalter

Component

• Eigene HTML-Tags (naja, Web Components)
• Logik geschrieben in JS
• Viele vorgefertigte, z.B. für Formularelemente, Links…
• Können geerbt (angepasst) werden

Model

• Repräsentieren Daten
• POJOs, Ember.Objects, Ember Data…

Controller

• View-Controller (wie iOS, nicht wie Rails)
• Repräsentieren Daten, die nur für den View gebraucht werden
  • z.B. PostController#hasComments
• Repräsentieren nicht-persistente Daten, z.B. Panel expand/collapsed-Status

View

• Setzen DOM-Events in semantische Events um
• Z.B. Element in Viewport -> Formulardaten nachladen
• So selten wie weiße Raben

EmberJS mit Rails

• Datenaustausch mit JSON-Backend
• Backend-Seite: rails-api + active_model_serializers
• Frontend-Seite:
  • $.getJSON
  • Ember Data
• Token Based Authentication (z.B JWT)

Ember Data

• Definiert Models
• Austausch mit JSON-API
  • 
  • 
• Finding
• Persisting
• Metadata (z.B. Pagination)
• Für Dev/Test:
  • FixtureAdapter
  • Toll, aber hat Macken
• Real Thing: ActiveModelAdapter
• Anmerkung von Manuel Wiedenmann: Wenn man erst mal ohne Backend entwickeln will (zu empfehlen), der Fixture-Adapter aber Bugs hat, dann ist der Local Storage Adapter sehr zu empfehlen.

Build-Prozess

• Concat, Minify, develepment/production versions, cache busting…
• Backend und Frontend in einer App oder getrennt?
• Getrennt hat Vorteile:
  • UI-Entwickler brauchen keine Ruby/Rails-Installation
  • Entwicklung mit FixtureAdapter, Local Storage Adapter, API-Stub oder API-Staging-Server
• Mit Sprockets
  • Rails Asset Pipeline
  • Rake Pipeline
• Mit Grunt
  • Ember App Kit
  • Brunch etc.
• Mit Broccoli
  • ember-cli
  • Neuer offizieller Weg
  • Ergänzung für Grunt, kein Ersatz

Deployment

• Separate Apps empfehlenswert
• API-Namespace (z.B. "/api/v1")
  • 
  • 
• Load Balancer:
  • Alles mit "/api" auf die Backend-Server
  • Alles andere auf den Static Assets Host
  • Bei History-API: Alles ohne API im Pfad, das keine statische Datei ist, auf die index.html auf dem Static Assets Host
• Einfaches Deployment mit Heroku
  • gem 'rails_12factor', group: :production
  • dist bauen
  • ins public-Verzeichnis vom Backen syncen
  • rsync -av --delete dist/ ../backend/public
  • backend deployen
  • Nachteil: Backend-Prozess wird neu gestartet

Entwicklungsprozess

• Frontend-getrieben
• Fangt nicht mit der API an!
  • Die API passt nicht zum Frontend
  • Das Frontend passt nicht zum Product Owner und damit auch nicht zum Backend
• Erst mal nur Frontend machen
• Daten mit POJOs oder Ember.Objects repräsentieren
• Dann FixtureAdapter
• SO LANGE WIE MÖGLICH OHNE API/BACKEND !!!
• Nochmal: NICHT MIT DER API ANFANGEN!
• Dann API-Anbindung

SEO/Crawling

• Yahoo kann Ember (ein bisschen)
• Dünne HTML-Schicht zwischen JSON und Crawler (z.B. Discourse)
• Mit PhantomJS HTML generieren
• Externe Services
• NBCNews, Bustle etc. zeigen, dass es geht

Fazit

• Ember ist toll und ausgereift
• Ember Data ist ok bis gut, aber besser als alles andere
• Rails nur als API vereinfacht den Backend-Part enorm
  • Anzahl Gems/Plugins… (Prozessgröße)
  • Code-Komplexität
• Frontend-first erzeugt schnelleres Feedback
• Komplexer Frontend-Code sauberer als bei vielen Rails-Apps