[Ervaringen] Web application frameworks

[susscorfa]

Ik wil voor een eigen project een web applicatie ontwikkelen voor het beheer van foto's. Het gaat om een specialists doel waar nog geen applicaties voor bestaan. Ik heb zelf al een keer een applicaties ontwikkeld voor dit doel, maar die is nooit gebouwd voor breder gebruik of onderhoud (en kost nu dus veel tijd in onderhoud), ik zou het graag een keer goed over doen. Het doel is twee zijdig zowel me zelf verder ontwikkelen in het programmeren als een werkbaar iets produceren.

Als database zit ik te overwegen postgresql te gebruiken dit omdat ik toch te vaak quirks in mysql tegen ben gekomen.

Waar ik nog niet uit ben is wat voor een taal ik zou gebruiken. Ik heb ervaring met php, c++ en wat script dingen zoals bash en R maar totaal geen bezwaar om iets nieuws te leren. Voor de ontwikkeling zou ik graag een framework gebruiken om zo min mogelijk tijd en hassel kwijt te zijn aan implementatie en interfaces. ik zal eerst een aantal eigenschappen van de applicatie op noemen

• Multi file upload om snel veel fotos te uploaden
• Rechten beheer en user authentication
• Opties om eigenschappen aan fotos toe te voegen wat er op te zien is

Ik heb al een keer met Zend lopen spelen en dat lijkt redelijk te doen wat ik wil maar ik zat eigenlijk te denken om niet php te gebruiken. Ik wou geen php gebruiken omdat delen van de applicatie redelijk intensief kunnen zijn en ik eigenlijk wel naar een iets nettere taal zou willen.

Een taal die ik graag zou leren in me geschikt lijkt is java tot nu toe ben ik twee frameworks/libraries tegen gekomen die ik heb verkend namelijk GWT, grails en tapestry. GWT lijkt meer op een toolkit zoals de naam al zegt en me minder geschikt omdat het een groot deel van views, database abstractie enz als nog zelf moet worden geimplementeerd. Grails ziet er uit als of je snel iets kunt doen maar ik vraag me af hoe flexible het is als ik zelf nog dingen wil aanpassen. Tapestry ziet er opzich wel goed uit maar toch ben ik wel benieuwd naar ervaringen van anderen en tips of adviesen of ideen voor andere frameworks

[Nexopheus]

Rails !

Multifile upload : http://www.webyfi.com/?p=222
Authentication : http://github.com/thoughtbot/clearance
Authorization : http://github.com/be9/acl9

Eigenschappen uitlezen via EXIF : http://github.com/remvee/exifr/

Succes!

[HuHu]

PHP is net zo netjes als je het zelf maakt. En wat is "redelijk intensief"?

[susscorfa]

Redelijk intensief houd in dat er gewerkt zal worden tot 10.000 fotos waar idd exif info van af moet worden gehaald. De database die ik nu heb heeft over 500.000 image records maar ik denk dat als ik het promote het makkelijk in de miljoenen kan lopen

Rails klinkt goed. Als ik ruby / rails zou leren voor dit project is dat ook een taal die je makkelijk voor andere doelen kunt gebruiken dan web development.

Werkt rails ook handig met files?

Hoe zit het met de schaalbaar heid van rails kom je snel in memory of performance problemen?

Zijn er ook goede ajax libs voor rails?

[rrrandy]

Je zou ook eens naar het Wicket framework kunnen kijken

[HuHu]

Je wil een webapp waarin je 10.000 foto's tegelijk gaat verwerken? Dat gaat je in geen enkele taal goed lukken.

Het lijkt me beter dat je goed gaat nadenken over het ontwerp van je applicatie. EXIF data inlezen en opslaan in een database, daarop je bewerkingen uitvoeren, enz...

De taal die je kiest is slechts een hulpmiddel.

[wackmaniac]

Ik mag toch aannemen dat ts al bedacht heeft dat hij de exif data eenmalig dient uit te lezen en op te slaan. Verder met HuHu eens; als je met zulke data hoeveelheden dan maakt de taal niet zoveel uit, want dan is je bottleneck waarschijnlijk je database. Zorg dat je die goed ontworpen en geïndexeerd hebt dan kan je vrijwel elke taal gebruiken, inclusief PHP en RoR.

[mithras]

Je kan het ook scheiden. Het procesintensieve gedeelte verwerk je door een gecompileerde binary. De frontend kan je dan in elke willekeurige taal maken. Je kan gemakkelijk in php/rails/whatever een frontendje klussen wat de uploads van foto's afhandelt en deze in een queue zet. Je (C++, daar heb je al ervaring mee) programma doorloopt de queue en leest de afbeeldingen uit en zet ze in de database.

Met php (daar heb je ook ervaring mee) kan je prima uitlezen welke foto's dan wel en nog niet geprocessed zijn. Kijk maar eens naar Flickr. Als je een hele batch upload zie je dat ze niet meteen verwerkt zijn. Dat processen kost even tijd. Ik weet verder niet wat ze daar intern doen, maar in ieder geval kan het nuttig zijn daar eens naar te kijken (hetzelfde voor Picasa)

[HuHu]

wackmaniac schreef op zaterdag 07 november 2009 @ 16:44:
Ik mag toch aannemen dat ts al bedacht heeft dat hij de exif data eenmalig dient uit te lezen en op te slaan. Verder met HuHu eens; als je met zulke data hoeveelheden dan maakt de taal niet zoveel uit, want dan is je bottleneck waarschijnlijk je database. Zorg dat je die goed ontworpen en geïndexeerd hebt dan kan je vrijwel elke taal gebruiken, inclusief PHP en RoR.

Als hij zegt dat er "gewerkt zal worden tot 10.000 foto's", dan vraag ik me af hoe die applicatie in elkaar steekt.

[WouZz]

HuHu schreef op zaterdag 07 november 2009 @ 17:55:
[...]

Als hij zegt dat er "gewerkt zal worden tot 10.000 foto's", dan vraag ik me af hoe die applicatie in elkaar steekt.

Als je 10.000 simultane uploads bedoelt kom je aardig in de buurt van Flickr / Picassa. Ik kan me voorstellen dat een partij die met dergelijke nummers werkt niet met een vraag komt welk framework te gebruiken. Als je zover bent moet je aandacht gaan naar de architectuur, en dan met name loadbalancing, gedistribueerde opslag, queueing etc. Waarschijnlijk gebruik je dan ook meerdere frameworks.

Dus om even in te gaan op het andere scenario, namelijk ''gewoon" een schaalbare oplossing bouwen voor foto opslag:

Belangrijkste is dat je de foto's asynchroon gaat verwerken om een "dos" op je server te voorkomen. Dus upload -> opslaan -> in queue zetten. Door een ander proces queue laten uitlezen en upload verwerken. Wat betreft storage: denk aan gerepliceerd, op meerdere servers dus, opslaan. Backuppen met dergelijke grote datasets gaat gewoon niet werken, dus zorg ervoor dat bij een HD /server crash je data ook nog op minstens 1 andere server staat. Wat betreft delivery: Cachen en kies een andere webserver dan apache.

Wat betreft framework keuze, kies voor een script taal als je snel / eenvoudig wijzigingen door wil kunnen voeren. Persoonlijk ben ik wel een fan van Python / Django, maar Zend Framework is ook een goed alternatief.

[Cartman!]

Wij gebruiken altijd Zend Framework voor 'normale' websites maar voor high-performance applicaties gebruiken we de frontcontroller/dispatcher niet omdat deze erg langzaam is. In plaats daarvan maken we een versimpelde structuur die altijd controller/action is zodat je ze direct kunt doormappen naar de juiste controller. Zo heb je wel de structuur maar niet de slome dispatcher

Rails kampt overigens met het grote gerucht dat t niet schaalbaar is, in hoeverre dat klopt weet ik niet zeker maar wellicht kun je dat eens opzoeken.

[CMG]

Qua upload zou ik in C++ een ActiveX in elkaar knutselen, dan heb je volledige controle over de ervaring van de gebruiker en kun je dingen doen zoals stukken opsplitsen en progress, etc.

Voor je web app zou ik kiezen voor ASP.NET MVC. Je kan dan in C# je backend schrijven (lijkt ook weer op C++ maar dan meer RAD). Nadeel is wel dat qua DB je vast zit aan MSSQL (scheelt heel veel tijd door integratie in het framework) en dure hosting (MSSQL + ASP.NET). Als je nog iets van performance wilt hebben zou je dan al zelf een servertje moeten huren voor +/- 50 euro ex btw per maand van Leaseweb.com (shared .NET hosting servers worden veel te zwaar belast, heb er genoeg geprobeerd).

Suc6!

[Cartman!]

CMG schreef op zaterdag 07 november 2009 @ 20:00:
Qua upload zou ik in C++ een ActiveX in elkaar knutselen, dan heb je volledige controle over de ervaring van de gebruiker en kun je dingen doen zoals stukken opsplitsen en progress, etc.

Werkt ActiveX al in firefox, opera en webkit dan?

[Nexopheus]

Cartman! schreef op zaterdag 07 november 2009 @ 19:36:
Rails kampt overigens met het grote gerucht dat t niet schaalbaar is, in hoeverre dat klopt weet ik niet zeker maar wellicht kun je dat eens opzoeken.

Rails schaalt prima! Kijk maar eens hier voor meer achtergrond informatie : http://railslab.newrelic.com/

[CMG]

Cartman! schreef op zaterdag 07 november 2009 @ 20:39:
[...]

Werkt ActiveX al in firefox, opera en webkit dan?

C# Silverlight plugin dan Het kan iig niet met HTML/JS

[Cartman!]

Dat is niet waar volgens mij, als ik me niet vergis hebben ze bij Hyves fileuploads met statusinfo gewoon via HTML waarbij er een soort 2e connectie wordt opgebouwd met de webserver. Ik kan het topic bij hyves even niet vinden alleen

edit: dit is em: http://technologie.hyves....rking_van_de_file_upload/

[ Voor 16% gewijzigd door Cartman! op 07-11-2009 22:01 ]

[susscorfa]

Ten eerste bedankt voor alle replies, er zitten zeker een aantal zeer zinvolle tips bij.

Exif data gaat idd in de database en database ontwerp heb ik wel genoeg ideeen over en ervaring mee.

Ik zal iets meer uitleg geven waar het mee te maken heeft. De fotos waar het overgaat zijn fotos van camera vallen, dat zijn digitale cameras die een foto maken als er een beest passert zulke camera's staan meestal in het bos. Deze cameras maken meestal 1 tot 10 fotos als er een beest passeert, gedurend de tijd dat ze uit staan kunnen ze soms wel tot 1000 keer getriggerd worden daar is de 10000 op gebasseerd, maar dat is dus een maximum waar je niet al te vaak mee te maken zal hebben, meestal ligt het ergens rond de 500 tot 1000 fotos. Het doel is om de informatie van de fotos af te kunnen halen en te zorgen dat later ook beesten op fotos geidentificeerd kunnen worden.

Over de schaalbaarheid verwacht ik niet direct problemen maar ik wil niet gelijk weer in de val vallen van vorige keer waar ik alles quick en dirty had gedaan en nu met een onderhouds nachtmerrie zit.

Over een queue dat heeft als nadeel dat gebruikers niet gelijk met de fotos zouden kunnen werken. Zou het niet mogelijk zijn om gedurende de upload de fotos die binnen zijn te verwerken zodat je relatief snel klaar bent als de laatste foto binnen is?

ASP .NET valt voor mij een beetje af omdat mijn voorkeur echt wel uitgaat naar linux.

[CMG]

Cartman! schreef op zaterdag 07 november 2009 @ 22:00:
Dat is niet waar volgens mij, als ik me niet vergis hebben ze bij Hyves fileuploads met statusinfo gewoon via HTML waarbij er een soort 2e connectie wordt opgebouwd met de webserver. Ik kan het topic bij hyves even niet vinden alleen

edit: dit is em: http://technologie.hyves....rking_van_de_file_upload/

offtopic:
errug nice, maar eens kijken of ik ook zo iets kan bouwen (had ik helemaal niet aan gedacht om het op die manier te proberen!)

[mithras]

susscorfa schreef op zondag 08 november 2009 @ 00:10:
Over een queue dat heeft als nadeel dat gebruikers niet gelijk met de fotos zouden kunnen werken. Zou het niet mogelijk zijn om gedurende de upload de fotos die binnen zijn te verwerken zodat je relatief snel klaar bent als de laatste foto binnen is?

Op het moment dat je foto 3 upload kan je al foto 1 gaan bewerken, dat is juist het handige van die gesepareerde processen. Dat uitlezen kan je met deze hoeveelheid trouwens ook best in php doen; daar zie ik niet heel veel problemen in.

Zolang je maar goed bedenkt dat uploaden != processen != uitlezen. De losgekoppelde systemen kan je dan later makkelijker onderhouden. Werkt het processen niet snel genoeg? Schrijf wat anders. Toch over naar multiple file uploads, doe daar dan wat aan. Imho moet je met dat laatste lekker een js of flash oplossing gebruiken. Silverlight werkt echt nog lang niet altijd even lgoed en ActiveX is uberhaupt het overwegen niet waard...

[Cartman!]

Het handige aan queue's is ook dat je makkelijk kunt schalen, gewoon een extra server in de poule die ook requests van de queue gaat verwerken als ie te groot wordt. In feite werkt youtube (en vele andere tubes) ook op die manier, daarom duurt zoiets de ene keer een minuut en een andere keer een kwartier bij wijze van.