Webapplikation von Grund auf

Hi

Ich arbeite seit 6 Jahren als Softwareentwickler, hatte aber noch nie die Möglichkeit in meinem Beruf eine Webapplikation von Grund auf mitzugestalten. Sprich mir fehlen ein wenig die Kenntnisse wie alles zusammenspielt und vertiefte Kenntnisse in einzelnen Bereichen.

Und da ich schon lange mal ein eigenes Projekt starten wollte frage ich euch mal was ihr von der Zusammenstellung haltet.

• Java
• Apache Wicket
• Jetty
• Maven
• NoSQL Database
• Lucene
• jQuery, HTML5

Damit möchte ich eine Webapplikation entwickeln mit der ich meine Filmsammlung pflegen kann. Java ist gesetzt, damit kenne ich mit seit 6 Jahren aus. Ansonsten vielleicht noch Python, da habe ich aber null Erfahrung.

Mit Apache Wicket kenne ich mich gar nicht aus, ich kenne bisher Tapestry 4, Play 2, ZK. Aber Wicket reizte mich schon immer. Und ich suche vor allem ein gut dokumentiertes Framework und eine grosse Community.

Jetty habe ich auch keine Erfahrung, wird aber an meinem neues Arbeitsort eingesetzt, insofern vielleicht nicht so schlecht wenn ich mich damit mal etwas befasse.

Zu Maven muss ich wohl nicht viel sagen

Am unsichersten bin ich mir bei der Wahl der Datenbank. NoSQL Datenbanken würden mich reizen, weiss aber noch nicht genau inwiefern sie für mein Vorhaben geeignet sind.

Lucene für die Suche, damit kenne ich mich schon ein bisschen aus.

Naja und der Rest ist Beigemüse


Was haltet ihr davon? Passt irgendwas gar nicht zusammen? Was würdet ihr für eine DB empfehlen? Bin für fast alles offen


greez
Hendoul

NoSQL wird quasi nur eingesetzt, um Buzzword-Complete zu sein... NoSQL ist ein Key-Value-Store. Wenn du immer einen definierten Key hast, zu dem du Werte willst, dann ist das toll und schnell. Ich verwende z.B. Memcached um vorberechnete Bilder aus dem RAM über einen Hash (Bild-ID+Bildoptionen) schnell aufrufen zu können. Das ist typische NoSQL-Anwendung... hast du hier aber nicht. Du hast Relationen, also nimm ein RDBMS. IRgend eins. MariaDB wäre ne gute Idee.

Und insgesamt: Was schwebt dir genau vor? Eine "Webapplikation" kann alles mögliche sein. Es kann etwas einfaches sein, das im Browser läuft, oder etwas, dass gleichzeitig Daten für ne Handy-App bereitstellt...
Wenns wirklcih rein browserbasiert ist: Such dir ein x-beliebiges komplexes CMS und pass es dir an.

Lucene, Java,.... Kanonen vs. Spatzen anyone?

Daaron schrieb:

NoSQL wird quasi nur eingesetzt, um Buzzword-Complete zu sein...

Zum Vergrößern anklicken....

stümmt in 95% der Fälle. wobei auch gerne das Argument "Web-Scale" herhalten muss

Daaron schrieb:

NoSQL ist ein Key-Value-Store.

Zum Vergrößern anklicken....

nein. KV-Stores sind ein kleiner Teil von NoSQL, und in der Praxis auch nur 1/3 der Anwendung von NoSQL-Datenbanken. Es gibt davon zwar am meisten Datenbanken (weil am einfachsten zu entwickeln), aber Column Family Stores und Document Databases sollte man nicht unter den Tisch fallen lassen. Apache Cassandra hat beispielsweise vollkommen seine Daseinsberechtigung, da eine "Nische" gefüllt wird, die keine relationale Datenbank abdeckt.

Daaron schrieb:

IRgend eins. MariaDB wäre ne gute Idee.

Zum Vergrößern anklicken....

ich setz als Gegenpol einfach nochmal PostgreSQL dazu, ist noch ne Ecke cooler weil es mehr kann, was man aber nicht nutzen muss, wenn man nicht will.

Daaron schrieb:

Wenns wirklcih rein browserbasiert ist: Such dir ein x-beliebiges komplexes CMS und pass es dir an.

Zum Vergrößern anklicken....

da es hier um den Lerneffekt geht, finde ich eine Eigenentwicklung auch sinnvoller. Sonst ist man mehr damit beschäftigt ein CMS auf etwas anzupassen, wofür es nie gedacht war. Und übrig bleibt nur die Funktionalität die Startseite schön per CMS konfigurieren zu können.

Daaron schrieb:

Lucene, Java,.... Kanonen vs. Spatzen anyone?

Zum Vergrößern anklicken....

ja und nein. Jede moderne Datenbank hat ne eigene Volltextsuche (ja endlich auch InnoDB in MySQL - wurde auch Zeit), die kommen aber nicht ganz an Lucene und Sphinx ran. Aber in der Realität wird ihm die Suchfunktionalität der Datenbank wirklich vollkommen reichen...

ice-breaker schrieb:

stümmt in 95% der Fälle. wobei auch gerne das Argument "Web-Scale" herhalten muss

Zum Vergrößern anklicken....

Ich wollts nicht sagen....

ich setz als Gegenpol einfach nochmal PostgreSQL dazu, ist noch ne Ecke cooler weil es mehr kann, was man aber nicht nutzen muss, wenn man nicht will.

Zum Vergrößern anklicken....

Mag sein, dafür findest du deutlich schwerer einen Hoster als für MySQL. Wenn man auf die neuen Features von MariaDB 10 (NoSQL-Ansätze) verzichtet, ist etwas,d as man für MariaDB entwickelt auch zu 100% auf jedem MySQL-Server lauffähig.

ja und nein. Jede moderne Datenbank hat ne eigene Volltextsuche (ja endlich auch InnoDB in MySQL - wurde auch Zeit), die kommen aber nicht ganz an Lucene und Sphinx ran.

Zum Vergrößern anklicken....

Ich habe erst eine einzige Situation erlebt, wo die Fähigkeiten von MySQL an ihre Grenzen stoßen: bei Magento. Bei großen Produktkatalogen geht quasi nix ohne SOLR (das ist dann auch der Punkt, wo man mit Magento Community Edition gegen dei Wand fährt)

Vieles kann man über einen guten internen Indexer lösen. Contao hat z.B. einen verdammt gutes Index-System. Natürlich scheitert es, wie jedes (außer SOLR & Co), an Singular/Plural oder Rechtschreibfehlern (obwohl es "fuzzy" ist). Aber es ist schnell und umfangreich.

Wenn hier aber nicht gerade 10.000 Nutzer durch 1Mio "Objekte" suchen sollen, dann ist Lucene echt übertrieben.

Richtig, es geht um den Lerneffekt, daher alles von Grund auf selber machen. Ok, NoSQL scheint wohl nicht das richtige zu sein bzw. ich muss mich da mal mehr einlesen um vergleichen zu können.

Lucene einfach deshalb, weil ich damit schon 3-4 Jahre Erfahrung sammeln konnte.

Achja, Spring habe ich vergessen, wobei das ja mehr oder weniger selbstverständlich ist.

Netter Stack. Allerdings würde ich für dein Vorhaben wohl die DB ganz weglassen und nur auf elasticsearch arbeiten (basiert auf lucene). Schließt sich aber natürlich nicht gegenseitig aus.

Für kleine Projekte finde ich Maven ok, ansonsten ist es aber dabei abgelöst zu werden von Gradle. Könntest du mal als Option betrachten.

Ich würde grundsätzlich noch auf Spring aufbauen, schon um einen netten DI-Unterbau zu haben. Da kannst du problemlos Wicket draufsetzen. Bei Spring kann man seit ~3.1 auch wunderbar per "Java Config" (also ohne das hässliche XML Geschwurbel) konfigurieren. Dummerweise findet man noch viele Beispiele, die nur mit XML arbeiten.

Naja und ob nun Jetty oder Tomcat… hauptsache Italien. Embedded bietet sich für so eine einzelne Anwendung an und das können beide inzwischen.

Hättest du nicht gesagt, dass du Play schon benutzt hast, hätte ich wohl dazu geraten, weil es schön leichtgewichtig ist. Aber wenn du Wicket noch gar nicht kennst, ist das auch eine gute Wahl und du musst ja wahrscheinlich nicht krampfhaft stateless bleiben, um ENTERPRISE SCALABILITY zu wahren.

Daaron schrieb:

NoSQL ist ein Key-Value-Store.

Zum Vergrößern anklicken....

Möchte dir bei der Empfehlung für ein RDBMS klar zustimmen, aber die Aussage kann man so nicht stehen lassen. MongoDB als dokumentenorientierte Datenbank beispielsweise würde sich für eine kleine Filmdatenbank kaum schlecht machen, und Volltextsuche ist mittlerweile auch dabei.

Der Gartner Hype Cycle hatte in der Vergangenheit ja nicht selten unrecht, in 2-3 Jahren werden die meisten geblickt haben, für was man NoSQL besser nicht einsetzt, gleichermaßen werden die "NoSQL = Hype-Schreier" verschwinden. Zumal Dinge wie Memcached die "Ebene der Produktivität" imho schon längst erreicht haben.

Wenn du von deiner Liste 4-5 Dinge noch nie verwendet hast rate ich recht stark davon ab.
Bleib bei deinem Fall erst mal bei einer relationalen Datenbank, die sind in der Regel um einiges leichter im Handling.

Ich werf im Allgemeinen noch die eine oder andere Technology / Framework in den Raum -> gradle, AngularJS, Tomcat, Spring Boot,..

Daaron schrieb:

Wenn man auf die neuen Features von MariaDB 10 (NoSQL-Ansätze) verzichtet

Zum Vergrößern anklicken....

du meinst die Version, die noch immer Beta ist? *gg*
Ich glaube mitlerweile, dass das Original-MySQL mit den Json-Funktionen noch vor Maria final wird, traurig aber wahr.

Daaron schrieb:

Ich habe erst eine einzige Situation erlebt, wo die Fähigkeiten von MySQL an ihre Grenzen stoßen [...] Natürlich scheitert es, wie jedes (außer SOLR & Co), an Singular/Plural oder Rechtschreibfehlern (obwohl es "fuzzy" ist).

Wenn hier aber nicht gerade 10.000 Nutzer durch 1Mio "Objekte" suchen sollen, dann ist Lucene echt übertrieben.

Zum Vergrößern anklicken....

du hast doch selbst den Einsatzzweck gefunden: Wenn es auf die Qualität der Suchergebnisse ankommt, führt eben kein Weg an einer richtigen Lösung vorbei.

carom schrieb:

MongoDB als dokumentenorientierte Datenbank beispielsweise würde sich für eine kleine Filmdatenbank kaum schlecht machen, und Volltextsuche ist mittlerweile auch dabei.

Zum Vergrößern anklicken....

Uargh, ich hatte geahnt, dass die am maßlosesten gehypte NoSQL-Datenbank noch genannt wird... Einer der schlechtesten Einflüsse für NoSQL
Ich warte noch auf den Tag an dem jemand MongoDB-on-PostgreSQL präsentiert. Dann wird dem letzten klar werden, dass das einzig "gute" an dieser Datenbank die Abfragesprache ist. Und der Rest einfach austauschbar ist, zumal mit Transaktionen das ganze ne Ecke nutzbarer wird.

carom schrieb:

Der Gartner Hype Cycle hatte in der Vergangenheit ja nicht selten unrecht, in 2-3 Jahren werden die meisten geblickt haben, für was man NoSQL besser nicht einsetzt, gleichermaßen werden die "NoSQL = Hype-Schreier" verschwinden.

Zum Vergrößern anklicken....

Früher war es der Begriff "Data Warehouse", gestern war es "NoSQL" heute ist es "Big Data", wüargh. Aber hey die NoSQL-Datenbanken meinen ja sie müssten auch im "Big Data" Feld mitspielen, MongoDB mit seiner Definition von 100GB als Big Data, süüüüß.
Wie soll man eine Datenbank ernst nehmen, die bei so geringen Datenmengen schon zickt.

carom schrieb:

Zumal Dinge wie Memcached die "Ebene der Produktivität" imho schon längst erreicht haben.

Zum Vergrößern anklicken....

Memcached gab es schon viele Jahre vor dem NoSQL-Begriff! Und Memcached erfüllt auch einen ganz anderen Zweck, niemand wird dir ernsthaft erzählen, dass du deine Datenbank gegen Memcached eintauschen sollst...

Funart schrieb:

Wenn du von deiner Liste 4-5 Dinge noch nie verwendet hast rate ich recht stark davon ab.

Zum Vergrößern anklicken....

full ack!

Funart schrieb:

Ich werf im Allgemeinen noch die eine oder andere Technology / Framework in den Raum -> gradle, AngularJS, Tomcat, Spring Boot,..

Zum Vergrößern anklicken....

oh ja, ihm erst den guten Hinweis geben, dass er nicht zuviel neues nutzen soll und dann ne Menge neues hinterherwerfen, sehr sinnvoll...

Naja die hab ich primär deswegen erwähnt, weil ich der Meinung bin dass seine Auflistung eher schlecht ist. Wollte da nur ein paar Alternativen aufzählen ohne dass jemand sein lieblings Framework verteidigen muss.

Was ist denn an meiner Auflistung schlecht?

Ich suche mir jetzt noch eine SQL-DB aus, lese mich kurz bei Gradle ein und dann steht doch das Paket? Das einzig wirklich neue wird Apache Wicket und Jetty sein. Aber ich will ja kein Profi bei Jetty werden, ich will damit nur meine Applikation laufen lassen und nicht irgendwelche HighEnd Configuration. JBoss hätte ich schon ein wenig Erfahrung, der ist mir aber zu überladen.

ice-breaker schrieb:

Uargh, ich hatte geahnt, dass die am maßlosesten gehypte NoSQL-Datenbank noch genannt wird... Einer der schlechtesten Einflüsse für NoSQL

Zum Vergrößern anklicken....

Ist in der Tat interessant, was man in diversen Blogeinträgen so lesen kann. Zustimmen muss man nicht immer, vor allem wenn man sich längere Zeit ernsthaft damit auseinandergesetzt hat - leider gibt es in den Weiten des Internets meist nur schwarz oder weiß.

Es ist schon lustig, da lernt man in jedem 0815 Bindestrich-Informatikstudiengang (no offense) im Grundstudium bereits Dinge wie Normalisierung in Datenbanken, hat später noch 1-2 dedizierte Datenbank-Vorlesungen, liest sich bei eventuellem Interesse durch das ein oder andere Buch aus der Bibliothek, macht bei entsprechendem Angebot irgendwelche Zertifizierungen zum Thema, nur um dann später im Beruf erst richtig etwas über den Einsatz von SQL-Datenbanken zu lernen.
Und dann erwartet man, ohne die Bereitschaft aufzubringen, vergleichbare zeitliche Investitionen zu tätigen, dass relativ junge Lösungen im NoSQL-Sektor out-of-the-box alle Probleme der Datenbankwelt lösen und wird natürlich enttäuscht. Dass man aufgrund mangelnder Literatur und Erfahrungen selbst eher Profiling und Testbeds betreiben muss, anstatt existierendes Wissen nutzen zu können, das liegt halt in der Sache der Natur.

Wenn man 10gen etwas vorwerfen kann, dann, dass sie ihre Marketingtrommel bzgl. MongoDB etwas zu stark beansprucht haben und den Mund weniger weit aufmachen sollten. Trotzdem ist die Datenbank, wenn die Anforderungen und das Szenario stimmen, absolut brauchbar. Dazu unten mehr.

ice-breaker schrieb:

Ich warte noch auf den Tag an dem jemand MongoDB-on-PostgreSQL präsentiert. Dann wird dem letzten klar werden, dass das einzig "gute" an dieser Datenbank die Abfragesprache ist. Und der Rest einfach austauschbar ist, zumal mit Transaktionen das ganze ne Ecke nutzbarer wird.

Zum Vergrößern anklicken....

Dem kann ich mich nicht so nicht anschließen, siehe unten. Transaktionen sind übrigens etwas, das man hier gar nicht haben möchte. Wenn man Transaktionsfähigkeit baucht, dann sollte man etwas verwenden, was Transaktionen unterstützt.

ice-breaker schrieb:

Früher war es der Begriff "Data Warehouse", gestern war es "NoSQL" heute ist es "Big Data", wüargh. Aber hey die NoSQL-Datenbanken meinen ja sie müssten auch im "Big Data" Feld mitspielen, MongoDB mit seiner Definition von 100GB als Big Data, süüüüß.
Wie soll man eine Datenbank ernst nehmen, die bei so geringen Datenmengen schon zickt.

Zum Vergrößern anklicken....

Genau das meinte ich oben, danke dafür. Ein gefundenes Fressen für alle Hobby-Kritiker und enttäuschten Seelen.
Bei einem Kunden läuft MongoDB seit längerer Zeit ganz easy mit mehr als 10TB, und von diversen Events und Mailinglisten weiß ich, dass andere Firmen auch keine Probleme mit der Datenbankgröße haben. Das Profiling für Queries und Datenstruktur hat Zeit gekostet und erfordert definitiv Wissen über die Art und Weise, wie MongoDB funktioniert... aber das wäre bei SQL wohl nicht gänzlich anders gewesen. Es geht kurz gesagt um eine Anwendung aus der biologischen Forschung, bei der Milliarden an Proteinen in Bündeln von Hierarchien angeordnet sind und ständig von einem Cluster herausgezogen werden, der dann Merkmalvergleiche anstellt und die Hierarchien analog anpasst.
In eine erste SQL-Lösung floss viel Zeit und Know-How, wobei sogar externe Leute herangezogen wurden. Aber der Knackpunkt war eben die Struktur der Daten (Hierarchie und Bündel), wobei die finale MongoDB-Lösung bei kritischen Abfragen und in-Place Updates um die 500% schneller ist. Und mit heutigen CPUs hat man in vertretbarer Zeit schnell mal mehrere TB an Testdaten erzeugt, Überraschungen wird es so schnell nicht geben.
Kurz: ich wüsste nicht, welche Technologie hier eine bessere Wahl dargestellt hätte. Man muss eben die Anforderungen verstehen und wissen, was diverse Technologien können und was sie nicht können.

Ich bin kein Verfechter von MongoDB und wollte eigentlich noch mehr dazu schreiben, aber das hier ist wohl eh bereits zu viel Text. Oben habe ich für den Fall des TS zu einem RDBMS geraten, aber das mit NoSQL wollte ich so nicht stehen lassen, das war alles.

ice-breaker schrieb:

Memcached gab es schon viele Jahre vor dem NoSQL-Begriff! Und Memcached erfüllt auch einen ganz anderen Zweck, niemand wird dir ernsthaft erzählen, dass du deine Datenbank gegen Memcached eintauschen sollst...

Zum Vergrößern anklicken....

Und trotzdem fällt es heute in die Kategorie NoSQL - da wurde weiter oben NoSQL auf Key-Values stores reduziert, es war von "Buzzword-Complete" als Einsatzgrund die Rede. Das dort im gleichen Atemzug erwähnte Memcached habe ich nur nochmals aufgegriffen, weil diesbezüglich genau das Gegenteil der Fall ist, mit Buzzword und Hype hat Memcached nichts zu tun und ist aus vielen Szenarien nicht wegzudenken.

Mir ging es explitiz darum, dass sich das, was der TE für sein bisschen Applikation an Werkzeugen vorlegt, wirklich nach "Buzzword-Complete" anhört, nichts anderes.
Sowohl umfangreichere NoSQL-Lösungen als auch das schlichte Memcache(d) haben ihre Daseinsberechtigung... aber nicht in diesem Projekt.

carom schrieb:

[...]

Zum Vergrößern anklicken....

das ist warum ich ich Darron zu 95% Recht gegeben habe, dass NoSQL-Datenbanken nur genutzt werden um "Buzzword Complete" zu sein, es gibt durchaus mehr als genug Anwendungszwecke für Datenbanken, die nicht auf Relationen setzen.
Aber es wird eben fast immer einfach so genommen, ohne dass sich da jemand größere Gedanken gemacht hat oder einfach weil die bisherige Datenhaltung Schrott war.
Da gibts dann immer die "tollen" Artikel "Why whe switched from X to X and gained x% performance".

Bei NoSQL muss ich auch immer irgendwie an Pornos denken... Youporn läuft auf Redis *G*
http://www.golem.de/news/nosql-youporn-wechselt-von-mysql-zu-redis-1202-89929.html

Puuuh, was man sich so alles vornimmt und dann doch nicht dazu kommt
Aber ich werde noch einen Versuch starten. Und zwar habe ich mich für Vaadin als Webframework entschieden. Und als DB vermutlich MariaDB.

Aber irgendwie habe ich "Angst" zu beginnen. Denn ich weiss gar nicht wo. Sollte ich einfach versuchen mal ein "Hello World" mit Vaadin hinzukriegen. Und von dort dann weiter? Ich denke ich muss gleich zu Beginn mit Maven mein Projekt aufsetzen damit ich überhaupt die Struktur kriege?

Warum dann überhaupt einen so aufgeblasenen Stack? KISS - Keep It Simple, Stupid
Der aller-einfachste Stack reicht zum lernen, und der einfachste Stack ist und bleibt ein LAMP. Kann im Endeffekt auch alles, lässt sich mit n paar Klicks in ner VM einrichten, ist unglaublich gut dokumentiert,...

PHP mag nicht die schönste Sprache der Welt sein, aber sie hat ein paar unschätzbare Vorteile:
- läuft quasi auf jedem Taschenrechner
- unglaublich gut dokumentiert, inklusive der ungeschlagenen Spitze an Threads bei Stackoverflow
- verzeiht ne Menge Fehler
- man sieht schnell mal Erfolge, auch wenn man evtl. eigentlich totalen Mumpitz geschrieben hat

Nö, mit PHP will ich mich wirklich nicht befassen, das bringt mich nicht wirklich weiter, da ich in Zukunft privat und auch beruflich nicht auf PHP umsteigen werde. Der Stack mag aufgeblasen sein, aber mit all dem habe oder hatte ich schon täglich zu tun. Die Herausforderung besteht darin, von Grund auf mal alles selber zusammenzustellen und zum laufen zu bringen.

Mein Vorschlag:

• Java 8
• Apache Wicket, alternativ Play oder Vaadin (http://zeroturnaround.com/rebellabs...-usage-data-of-spring-mvc-vaadin-gwt-and-jsf/)
• Jetty via DropWizard
• Gradle anstatt Maven (übersichtlicher, erweiterbar, bequemes scripting, kein XML)
• PostgreSQL anstatt NoSQL (Wozu brauchst du NoSQL eigentlich?)
• Lucene (cooles Tool, aber wozu?)
• jQuery, HTML5 (würde ich auf ein absolutes Minimum reduzieren und stattdessen lieber so viel wie möglich im Java erledigen)