Stack-Wahl wider den Reflexen

Hallo zusammen,

bei mir steht in absehbarer Zeit nach sehr langer Pause endlich ein neues Projekt ins Haus. Nun ist man oft geneigt, sich einfach reflexartig den Stack zu nehmen, auf dem man schon seit Jahren arbeitet, und loszulegen.

Da ich aber eigentlich noch keine Eile habe, wollte ich mal etwas über den Tellerrand schauen und hören/lesen, was andere für ihre BGs momentan so einsetzen. Besonderes Augenmerk liegt dabei auf der Wahl der Datenbank, weil gerade hier oft reflexartig zu (My-)SQL gegriffen wird, ohne überhaupt über evt. mittlerweile verfügbare Alternativen nachzudenken. 

Geplant ist ein "klassiches" Browsergame mit HTML(5)/AJAX-basiertem Front-End.

Damit es nicht allzusehr in einen Flamewar ausartet: Bitte Begründungen mitliefern ;-)

PS: Ich bin auf Macs zuhause und auf den Servern läuft Linux. Daran würde ich bei allen Vorsätzen doch gerne bleiben ;-)

Ich habe für das Winterprojekt mongoDB ausgewählt, weil die Anforderungen gut darauf passen, denn:

• nur sehr kleine Teilen der DB müssen strukturiert durchsuchbar sein (in RDBMS viele Tabellen, die nur über Joins benutzt werden, wenige unterschiedliche Queries)
• Daten werden meist gesammelt und auf einmal gelesen (in RDBMS viele Joins)
• Transaktionalität ist nicht nötig (meist nur eine Änderung pro Aufruf)
• einfach einzusetzender geospatial Index (nix plugingedöns...einfach so out of the box)
• schemalos...keine Constraints...dadurch schnelles schreiben

Das waren für mich erstmal die Haupgründe, warum ich mongoDB ausprobieren wollte. Alles weitere wird sich zeigen...

Clientseitig evaluiert Rederick grade CAAT http://labs.hyperandroid.com/static/caat/ ... CAAT ist ein Szenengraphmanager :) Da ich damit noch nicht viel gemacht habe, kann ich nicht wirklich was dazu sagen...eber vielleicht sagt er ja was dazu.

Ansonsten bin ich eher technologiekonservativ und setze Dinge ein, die sich bewährt haben und die ich beherrsche, bzw von denen ich weiss, dass sie funktioneren und skalieren.

Na denne...

Maxx

Ich schwöre zurzeit immer noch auf Rails, Github und Heroku als ultimative Technologieplattform für "klassische" Webanwendungen.

Grund... Weiß nicht. Liebe auf den ersten Blick.

Falls du wie Maxx auch mit mongoDB arbeiten willst, gibt es extrem viele Gems dafür. Sowohl low-level als auch high-level ORMs

@MrMaxx: CAAT sieht sehr interessant aus...werde ich mir auf jeden Fall auch mal genauer anschauen.

Darf ich fragen, wie du Mongo verwendest? Einfach "vanilla" über den Java-Treiber oder mit irgendeiner zusätzlichen ORM-Schicht?

 @buhrmi: Heroku sieht elegant aus, aber wird das nicht sehr schnell sehr teuer? Für eine Hand voll "Prozesse" kann man sich bei einem 08/15 Hoster mehrere Root-Server holen. Und wenn ich es richtig verstehe ist da noch keine Datenbank dabei. Also nutzt du das auch im größeren Stil oder nur "zum rumspielen" im Rahmen der Freikontingente?

Es kommt auf die Definition von "teuer" an. Ich - als jemand der keine Ahnung von Systemadministration hat - kann ohne ende skalieren, Datenbanken herumverschieben wie ich lustig bin, Mailserver mit einem einzigen Klick einrichten, bei Systemausfall wird automatisch ein neuer Server hochgefahren, ... dafür zahlen Firmen zig tausende Euros für Angestellte, die sich darum kümmern.

Mit den Freikontingenten kommt man aber auch recht weit. Du kriegst einen Prozess (Web Dyno) gratis auf extrem leistungsfähiger Hardware. Und wenn du MongoDB nutzen willst, kannst du mit einem Klick eine kostenlose 240MB Datenbank einrichten http://addons.heroku.com/mongolab

Aber ja, wenn man sich persönlich um Serverkram kümmern will, ist man mit einem 08/15 Hoster billiger dran.

Ich bin ja Comet-Fan. Mittlerweile gibt es mit Jetty/Cometd/Dojo wohl auch recht professionelles Equipment. Wenn es für Deine Applikation passt, würde ich es mir auf jeden Fall mal angucken. NoSql DBs würde ich mir auch auf jeden Fall angucken.

Ich benutze Spring Data als Aufsatz für MongoDB: http://www.springsource.org/spring-data/mongodb

• Biete mir die Annotationen, die ich erwarte, um meine Dokument-Objekte anzureichern (Indexe, Ids, Collections...)
• macht das ganze Mapping für mich
• liefert mir ne Query-API und versteckt so die mongoDB-Query-Syntax
• Spring hab ich eh an Bord
• lässt sich sogar in JTA-Transaktionen einhängen (das habe ich nur in den Beispielen gestriffen)

Das Ganze bietet sich für mich an, weil ich eh nicht vor habe die BSON-Objekte in irgendeiner Art direkt an den Client auszuliefern. Dafür setze ich wiederum auf google-gson http://code.google.com/p/google-gson/ , mit dem ich z.B. die Sichtbarkeit bestimmter Variablen/Objekten besser regulieren kann über die gewählten Serialisierer.

So long...

Maxx

Original von Todi42

Ich bin ja Comet-Fan. Mittlerweile gibt es mit Jetty/Cometd/Dojo wohl auch recht professionelles Equipment.

Meiner Meinung nach lässt sich das mittlerweile mit nodeJS und der Bibliothek socket.io (Websockets) wesentlich eleganter und vor allem performanter umsetzen. socket.io funktioniert hierbei wunderbar, da es für jeden Clienten die bestmögliche Verbindungsmöglichkeit ermittelt und somit wesentlich flexibler ist.

MfG

für socket.io gibt es noch ein workaround nowjs http://nowjs.com/examples und mit http://expressjs.com/ kann man dann gleich komplette seite in JS machen:D

Hat zufällig schonmal jemand mit dem Play! Framework für Java gearbeitet? 

Original von D4rk5in

Meiner Meinung nach lässt sich das mittlerweile mit nodeJS und der Bibliothek socket.io (Websockets) wesentlich eleganter und vor allem performanter umsetzen. socket.io funktioniert hierbei wunderbar, da es für jeden Clienten die bestmögliche Verbindungsmöglichkeit ermittelt und somit wesentlich flexibler ist.

Bayeux unterstützt auch die Verwendung verschiedener Transport-Protokolle.  Hast Du irgend wo eine Messung gesehen, aus der hervor geht, dass node.js  / socket.io performanter ist? Hast Du ein Beispiel, an dem man die elegantere Umsetzung mit node.js / socket.io erkennen kann? Wenn ich mal so einen ganz schnellen Blick auf die Startseite von Socket.IO werfe, dann scheinen die ja vor allem nur das Problem des Transport-Protokolls zu lösen.

mfg Todi