Welche Technologie soll es denn nun sein?

Ich finde es zunehmend schwierig, Technologie-Entscheidungen für anstehende Projekte zu treffen. Handelt es sich um ein Projekt für Kunden, werden oft schon entsprechende Vorgaben gemacht, oder sie ergeben sich aus der vorhandenen Infrastruktur. In meinem Fall geht es nun um ein privates Projekt. Hierfür suche ich eine solide Grundlage auf der sich alles umsetzen lässt.

Wieso aber nun dieser Beitrag? Ganz einfach, ich möchte dich um Rat fragen. Worauf würdest du setzen, welche Plattform, welche Technologie, Services usw.

Damit man sich vorstellen kann worum es geht, ein paar allgemeine Informationen zum Projekt:

  • Angedacht sind Apps für iOS, Android und Windows Phone (Benachrichtigungen sind wichtig; Zugriff auf Kamera, Mikrofon etc. wird nicht benötigt)
  • Zugriff via Web soll ebenfalls möglich sein
  • Daten werden über APIs von Drittanbietern abgegriffen
  • Eigene API für Einstellungen, Daten etc.
  • Riesige Datenmengen sind anfangs nicht zu erwarten

Ich persönlich tendiere im Backend zu ASP.NET vNext oder Go. Für Web könnte AngularJS ganz gut passen. Was mobile Geräte betrifft weiß ich nur, dass ich keine drei nativen Lösungen pflegen möchte (und für iOS gar nicht die notwendige Ausrüstung habe). Hinsichtlich Storage wäre herkömmlich ein RDBMS angedacht. Was “die Cloud” betrifft bin ich mir ganz unsicher. Manchen gefällt ja Microsoft Azure, zunehmend sehe ich aber auch Projekte auf Basis Google App Engine. Hierzu fehlt mir das Gefühl hinsichtlich der Kosten.

Frage: Worauf würdest du aktuell bauen? Bitte hinterlasse mir einen Kommentar mit deiner Meinung zum Thema.

Auch wenn ich aus dem Microsoft-Lager komme, muss es nicht Microsoft sein. Gerne auch andere Produkte. Wichtig ist, dass ich eine produktive und einfach zu betreuende Entwicklungsumgebung zusammen bekomme.

PS: Ich bin mir sicher, dass sich sehr viele da draußen diese Frage auch stellen und keine wirklich zufriedenstellende Antwort haben. Meist gibt es auch bestehende Strukturen, Plattformen etc. an die man gebunden ist. Ist ist für dieses Projekt nicht der Fall. D.h. vollkommen von der grünen Wiese auf soll dies entstehen. Dafür verlasse ich auch gerne gewohnte Pfade, kein Problem.

Veröffentlicht von Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.

Beteilige dich an der Unterhaltung

22 Kommentare

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

  1. Guten Morgen,

    beim Lesen der Kommentare musste ich ein bisschen schmunzeln – wie eine selbsterfüllende Prophezeiung. Wärst du ein Java-Entwickler, hätten dir vermutlich alle Spring & Co. empfohlen :-).

    Wobei ich voll zustimme: Wenn es um Produktivität geht und du die Chancen erhöhen willst, dein Projekt (nach Feierabend, wenn die Kids im Bett sind?) durchzuziehen, dann solltest du auf Tools setzen, in denen du schon fit bist.

    Wenn du aber, wie es mir zuletzt ging, leichte Zweifel daran hegst, ob nicht noch was Besseres draußen ist, und du den Drang verspürst, dir mal etwas frischen Wind um die Nase wehen zu lassen, dann mach dich frei von .NET.

    Ich selbst hatte mich schlussendlich für Node.js entschieden, weil es a) in der Industrie angekommen ist, b) eine wahnsinnig dynamische Community hat und ich c) die Sprache schon beherrscht habe. Bereut habe ich es nicht (*).

    Letztlich könntest du gerade bei deinen Anforderungen aus der Not auch eine Tugend machen: JavaScript everywhere.

    Xamarin ist gut und schön, in deinem Fall würde ich aber zu einer HTML5-App tendieren, die du mit Cordova (the way to go!) in App-Container gießt. Wenn du es geschickt anstellst, dann verwendest du für die Webanwendung und die Apps dieselbe Code-Basis, bei der sich im wesentlichen nur die API-Endpunkte unterscheiden und mobil ein paar System-Funktionen dazukommen (wie eben für Push-Notifications).

    Der Vorteil: Du kannst die Anwendungen vollkommen am Desktop deiner Wahl entwickeln und musst nur die system-nahen Funktionen auf den Geräten testen, vieles kannst du zu Entwicklungszeit im Desktopbrowser bequem wegmocken. (Beispiel: in einer Kunden-Anwendung nutze ich sowohl einen Barcodescanner als auch NFC – zum Testen reicht ein prompt()).

    Womit du die Apps baust, kannst du würfeln. AngularJS ist sicher eine solide und mächtige Wahl, ich mag es. Dazu noch Ionic fürs UI und du bist gut dabei.

    Probleme an dem Setup bzw. deinem Vorhaben: am Mac zum Deployen und Testen für iOS wirst du nicht vorbeikommen. Im Zweifel tun es am Anfang aber auch virtuelle Maschinen, die du online irgendwo kurz mietest. Und solltest du dich für Node.js entscheiden (glaube mal nicht ;)), ist Windows definitiv keine erste Wahl. Microsoft schießt sich mit seiner Pfadlängenbegrenzung auf 260 Zeichen hier selbst raus.

    Hosting: Habe dazu vorgestern was geschrieben (thomasbandt.com/hosting-nodejs-and-mongodb). DigitalOcean ist eine schöne und vor allem kalkulierbare Lösung, Azure & Co. kannst du später immer noch machen.

    (*) Nachdem ich intensiv mit Node gearbeitet habe, bin ich noch unentschiedener: Denn ich weiß nun, dass ASP.NET mit MVC und Web API + C# definitiv ein saugutes Setup ist. Aber es ist halt weder cool (niemand, der die Wahl hat, wird damit anfangen), noch ist wirklich klar, wie schnell die Reise vorangeht und wohin sie am Ende gehen wird. Die Open-Source-Initiative von Microsoft ist schön, aber es wird sicher wenigstens noch 2015 brauchen, bis das wirklich brauchbar überall läuft.

    1. Vielen Dank für deinen ausführlichen Kommentar. Du triffst den Nagel auf den Kopf. Ich bin mit .NET (am Backend) eigentlich ganz zufrieden, bin aber unschlüssig und sehe mich daher nach Alternativen um. Node.js kenne ich und ich habe damit auch einige Projekte gemacht. Der Vorteil ist natürlich JavaScript und mittlerweile gibt es hier auch zahlreiche Angebote, was Hosting betrifft. Da habe ich bei .NET aufgrund meiner bisherigen Erfahrungen eher Bauchweh.

      Ich bin zwar gerade dabei, einen Nachfolgeeintrag zu verfassen, aber ein paar Worte kann ich ja schon verlieren: Am Client bin ich mir mittlerweile sicher. Das wird die von dir angesprochene HTML5-App. Zum Zug kommen AngularJS, Ionic, Cordova. Mit Angular arbeite ich ja bereits seit einem Jahr, das andere ist neu für mich, möchte ich mir aber ansehen. Dieselbe Code-Basis wäre natürlich das Optimum.

      Ziel: Das muss alles auf Linux laufen (können), wird also vorzugsweise auch auf Linux von mir entwickelt.

      Danke für den Hosting-Hinweis, sehe ich mir an.

  2. Also an sich hast du ja ein typisches Setting, das früher oder später in jedem Projekt so zu Stande kommt.
    Nachdem du dich ja schon für eine gut unterteilte Struktur entschieden hast, bist du in der Tat recht frei in der Entscheidung.

    Backend: Du kommst aus der .net Welt, also mach doch .net. Du hast ein tolles Toolstack, kannst wunderbar REST Services damit bauen und alles umsetzen. Als Datenbank würde ich irgendwas einfaches nehmen. Persönlich würde ich ein Postgres nehmen, Azure ist natürlich auch eine Möglichkeit.
    Wir sind ja aus dem Alter raus, jeden Trend mitzumachen und dauernd was Neues zu lernen aus meiner Sicht. Und wenn man eine gute Geschwindigkeit und Erfahrung mit Lösungen in einer Technologie hat, ist das toll für kleine und große Projekte.

    Frontend Apps: Eigentlich tendiere ich zu Xamarin. Bin mir aber nicht sicher. Das hat auch viele Nachteile und gerade Versionswechsel von iOS machen es teilweise nicht angenehm, den Code anzupassen aus meiner Sicht. Aber hier ist auch wieder Geschwindigkeit ein Thema und in .net tut man sich leichter.
    Da Mobile immer wichtiger wird, würde ich mir hier tatsächlich native Entwicklung antun. Man kann alles lösen damit und ist am flexibelsten. Natürlich mit etwas Overhead im Betrieb. Das kann man insgesamt aber zukaufen, denn in allem gut sein ist auch schwer ;)

    Frontend Web: Du greifst eh schon nur über REST Services zu, also entweder .net (MVC, vNext, WebAPI, was auch immer) oder Angular.

    1. Danke für dein Feedback.

      Vermutlich hast du wohl recht. Ich denke ich werde das Backend in .NET machen (REST Service ist natürlich klar). Beim Frontend bin ich mir weiter nicht ganz sicher. Native Entwicklung für iOS ist für mich irgendwie blöd, da ich die Umgebung einfach nicht habe und auch keine Lust habe, da fett Geld für einen Mac auszugeben. D.h. da werde ich jedenfalls noch mal genauer schauen.

  3. Für das Backend sollte die Technologie möglichst leicht und einfach auf verschiedenen Infrastrukturlösungen einsetzbar sein um sie schnell auf andere Anbieter umzuziehen ( Wechsel zwischen verschiedenen Cloudanbietern und/oder dedizierte Server). Das bietet Flexibilität, besonders am Anfang eines Projekts. So lässt sich einfacher auf Kostenänderungen reagieren.
    Das Selbe auf den mobilen Geräten bzw. dem Frontend. Ich halte eine SPA (Vielleicht mit AngularJS) die nativ von einem WebView-Container geladen wird, am geschicktesten. Geringer Aufwand auf den mobilen Geräten selbst und die SPA lässt sich mit einem responsive Design auch auf jedem Gerät einsetzen sowie im normalen Browser. 4 Fliegen mit einer Klappe!

    1. Danke für dein Feedback. Ja, das denke ich mir auch, aber was ist denn das Wunderding, dass du innerhalb kürzester Zeit von einem Anbieter auf einen anderen bringst? Das ist für mich z.B. die Schwierigkeit.

  4. Für einfache backends in .NET benutze ich gerne Nancy. Nicht so aufgeblasen wie ASP.NET, läuft auch schon heute problemlos mit OWIN unter Mono/Linux und falls du für die App Xamarin verwendest kannst du dort auch ganz einfach deinen Code im Backend verwenden.

    Für Frontend benutze ich gerne AngularJS. Falls du Lust auf was neues hast vielleicht das ganze in TypeScript?

    Bezüglich Hosting, DigitalOcean hat prima Angebote. Und wenn du im BuzzWord-Bingo ganz hoch punkten willst:Pack dein Nancy-Backend zusammen mit Mono in einen Docker Container.

    Viel Spaß! :)

  5. Hallo Norbert,
    ich hatte vor ein paar Monaten die selbe Entscheidung wie du zu treffen. Meine Anforderungen entsprachen ungefähr deinen, wobei Push Notification ein wichtiger Punkt war. Außerdem bin ich .NET Entwickler.

    BackEnd: Azure, Mobile Services zusammen mit den Notification Hubs sind einfach genial und sehr leicht zu erlernen.
    FrontEnd: Apache Cordova. Seit letztem Jahr existiert auch in Visual Studio die unterstützung für diese Art von Projekten. Man entwickelt damit eine Hybride App, native Container (WebControl) in dem eine lokale Webanwendung (SPA) gehostet wird. Als sprachen stehen reinen Html+JavaScript oder Html+TypeScript zur Verfügung. Ich habe mich für letzteres entschieden, weil ich eher auch der StaticTyped Welt komme

    1. Apache Cordova habe ich bis dato nur so am Rande mitbekommen, klingt jetzt aber grundsätzlich nicht so verkehrt. Kannst du da eventuell Ressourcen empfehlen (abgesehen der ersten Treffer in der Suchmaschine meiner Wahl)?

  6. Ich stehe “Cross-Platform-Apps” traditionell skeptisch gegenüber, mit zweien hatte ich aber widererwarten relativ gute Erfahrungen gemacht. 1. XAMARIN, wurde schon genannt, 2. Titanium von Appcelerator.

    Bei letzterem war ich begeistert wie schnell man loslegen kann und fand klasse, dass native UI-Elemente verwendet werden. Theoretisch kann man eine Codebase für alle Plattformen haben, meine Gefühl nach einem kleineren Projekt war, dass es dennoch sinnig ist, die UI’s für jede Plattform gebaut wird. Mein Erfahrung war, dass man bei XAMARIN etwas weniger Code wiederverwenden kann, dafür hat man den C#, was ich deutlich netter als JS finde :).

  7. Wenn du eine Codebase für alle drei mobilen Plattformen haben möchtest, dann kommt entweder eine mobile Webseite, HTML5 App oder eine App auf Basis von Xamarin(.Forms).

    Wie immer gilt “it depends”. Alle drei Vorgehensweisen haben Ihre Vor- und Nachteile.

      1. OK, also nicht nur “Daten anzeigen”, sondern auch etwas mehr an nativen Funktionen verwenden. Da ich bis heute mit Xamarin gut gefahren bin, würde ich dir das empfehlen.
        Das neueste von Xamarin nennt sich Xamarin.Forms und da kannst du z.B. via XAML und MVVM Pattern die Wartung um einiges vereinfachen. Nachteil ist, dass du Custom Controls erstellen musst, falls irgendwas dem Standard abweicht. Wenn du das nicht verwendest dann kannst du jeglichen nicht UI Code wiederverwenden.

        Falls du da weitere Informationen benötigst, helfe ich gerne weiter.

  8. Da Go für dich in Frage kommt scheint Produktivität nicht an oberster Stelle zu stehen. Was sind denn deine Ziele bei dem Projekt? Lernen, Spaß oder Geld?

    1. In erster Linie geht es mir darum, meine Idee bestmöglich umzusetzen. Da steht Lernen ganz groß im Vordergrund. Zielführend wäre zudem zumindest eine Deckung der Kosten. Ich habe im Hinterkopf ein weit größeres Projekt und möchte dafür Erfahrung sammeln.

      1. “bestmöglich” ist sehr unkonkret. Wenn es ums Lernen geht, dann musst Du festlegen, mit welchem Ziel Du lernst.

        Willst Du lernen, wie man eine größere Anwendung möglichst produktiv erstellt? Dann ist ASP.NET MVC (egal welcher Version) doch eine sehr gute Wahl. Tolle Sprache, tolle IDE, tolle Libs, tolle Dokumentation. Was kann das noch übertreffen? Mit Xamarin dann die Apps.

      2. Ich war recht unkonkret, ja. Hauptsächlich um die möglichen Antworten nicht zu sehr einzuschränken :)

        Produktivität ist nicht so das Thema, mit diesem Thema beschäftige ich mich jeden Tag. Vielmehr war ich mir ob der wirklich vielen Möglichkeiten sehr unsicher, wie ich das Projekt technologisch angehen soll.

        Die vielen Kommentare haben einige meiner Sichtweisen bestätigt, bei anderen überlege ich noch. Blogpost mit meiner Entscheidung folgt, da möchte ich das noch einmal zusammenfassen.

Cookie-Einstellungen
Auf dieser Website werden Cookie verwendet. Diese werden für den Betrieb der Website benötigt oder helfen uns dabei, die Website zu verbessern.
Alle Cookies zulassen
Auswahl speichern
Individuelle Einstellungen
Individuelle Einstellungen
Dies ist eine Übersicht aller Cookies, die auf der Website verwendet werden. Sie haben die Möglichkeit, individuelle Cookie-Einstellungen vorzunehmen. Geben Sie einzelnen Cookies oder ganzen Gruppen Ihre Einwilligung. Essentielle Cookies lassen sich nicht deaktivieren.
Speichern
Abbrechen
Essenziell (1)
Essenzielle Cookies werden für die grundlegende Funktionalität der Website benötigt.
Cookies anzeigen