Et DynamoDB vu que Amazon est quand meme un des pere du NoSQL avec son papier dynamo. Je linke pas vers MongoDB, vous pouvez essayer de deviner pourquoi tout seul!
Et si on veut vraiment faire de la veille, graph databases sur Cassandra: TitanDB.
Facebook tourne sur une version hautement modifiee de Giraph. Le logo paf,
Et il y a le bon vieux NEO4J meme si c’est pas vraiment “cloud”…
Pour l’indexing et le search sur vos DB NOSQL vu que le querying c’est tendu souvent, il y a le celebre Solr ou ElasticSearch qui est top en distributed:
Je lis votre topic, ca parle bcp de front-end. Je note, mais c’est plus trop mon domaine. Je fais que du backend desormais. Donc ce que parle GloP me correspond plus.
Pas mal Cassandra, manque un ODM correcte en PHP (le bundle php est pas complet), celui en node.js a l’air mieux branlé.
J’aime bcp les NoSQL mais les coupler à des bases relationnelles avec un RabbitMQ au milieu qui s’occupe de synchroniser le tout me parait plus pertinent. J’ai aps regardé depuis quelques temps, mais ont ils reglé le probleme des count/sum et autres recherches complexes sur les NoSQL ? Ca passe par les services de type ElasticSearch ???
Je bosse avec le fw Symfony2, je le kiffe mais c’est quand même assez complexe pour les néophytes.
J’avais regarde node.js, les webkit que je kiffe à mort et le moteur de templating mustache avec lequel je me suis bien marré (j’ai refait une galerie photo en full js).
Je propose de partager ici les dernières technologies, langages, trouvailles et autres informations liées à la génération de pages Web qui pourraient intéresser les gens qui s’intéressent au développement de sites Web.
L’aspect présentation (CSS et Javascript) est discuté dans un autre thread.
Ha bah non, si c’est pour y coller un ODM, ca casse la moitie de l’interet. L’ideal c’est de faire des transformation a la volee, si c’est pour le traiter comme une autre maniere de stocker ses POJOs, c’est que moyennement interessant d’avoir du NoSQL.
[quote="Donjohn, post:2, topic: 55657"][/quote]
Recherche complexe, index separe oui. Niveau count, si tu veux vraiment oui, mais c’est eventuellement consistant. La plupart des applications se passent sans probleme de count. Deja vu un count de quoi que ce soit chez Amazon, Google, Reddit, Facebook ou Twitter? Y en a jamais (le count google est une approximation completement a l’ouest la plupart du temps) et en regle generale les operations ou t’es oblige de parcourir un grand nombre d’entrees sont de toute facon a bannir: ca scale pas. Les SUM ca se fait offline en map reduce/hadoop, quand t’as besoin d’analytics une fois par jour, tu peux alors stocker le resultat dans la base avec le reste. C’est un mode de pensee et une approche differente, faut pas le prendre comme un remplacant de la BDR qui scale differement, sinon c’est se chercher la gallere parce que si tu veux modeler pareil et essayer de faire de que tu fais d’habitude avec une requete SQL en NoSQL, tu vas deguster…
Nouveau sur le forum je rajoute ma pierre à l’édifice en parlant du framework PHP Laravel :).
Crée par Taylor Otwell sur des composants largements testés tel que des packages Symphony, c’est un framework très puissant avec une syntaxe très inspiré KISS. Il y a des mécanismes d’abstraction très puissants (Facades, IoC etc …), un query builder pour du SQL plutôt efficace, un ORM (Eloquent) que j’adore etc etc.
Je l’utilise depuis 6 mois, j’en ai abandonné mon framework home-made ^^
[quote=“Ifnot, post:5, topic: 55657”][/quote]
Ca c’est normal, tu peux pas faire toi même un framework au niveau des framework “pro” faits pas des equipes entieres sur des années. Je le sais, j’ai aussi fait un framework maison. Quand j’ai découvert Zend (à l’époque), ma vie de développeur a changé. Je ne peux plus m’en passer maintenant : Symfony2. [quote=“GloP, post:4, topic: 55657”][/quote]
les perfs !!! les fuckings perfs en lecture. Ton process d’écriture passe pas un “odm” pour sécuriser les inputs mais la sortie se fait en raw pure.
Tu gagnes grave en perfs des lors que t’as pas un système nécessitant beaucoup d’inputs.
Pour moi l’interet des bases NoSQL, c’est vraiment pas les perfs optimisées sur la base de ce qui est present dans le nombre de couches pour un appel. A moins de faire un truc super stupide, les perfs par requete sont largement acceptables quel que soit la maniere de consommer la sortie (deserialization ou pas). Donc raw output out pas, AMA ca change rien, et ca justifie pas de creer un truc asymetrique sur les lectures et les ecritures qui cassent l’isolation du store.
[quote=« Donjohn, post:7, topic: 55657 »][/quote]
Totalement d’accord. Tout dépend de la motivation que tu a à faire un framework home made après.
Je veux dire par là, moi je l’avais crée à l’époque à cause des API lourdes et pompeuses de Zend, Symphony, Jelix. CodeIgniter était plus léger, mais toujours pas ça … Moi ce que je voulais c’etait un framework qui pense à l’API avant de penser aux fonctionnalités. Laravel c’est exactement ça, t’a l’impression de faire du légo
Quelqu’un a un retour sur NODEjs ? Je viens de refaire un site web pour une petite asso avec (avais plus rien fait en web depuis 5 ans… c’est “intéressant” les évolutions) et je ne sais pas trop si c’est complètement stupide ou génial.
Sinon, Heroku ( que j’ai aussi découvert de l’intérieur, plutôt qu’en titre de blog que je lis pas, le week-end passé) parle de laravel dans sa newsletter.
Faire des git push pour déployer des sites webs c’est quand même sympa :].
Heroku j’utilise pour du gwt et du django c’est bien cool, meme si les prix quand tu as un truc moyens / gros sont prohibtifs.
Mais bon c’est leur modele de te ferrer quand tu es petit. Laraval je ne connais pas. NOdejs j’ai testé mais y’a longtemps et a l’epoque c’etait trop le bordel au niveau des versions.
Ca a changé visiblement et ca semble du coup etre devenu pas mal mais je laisse plus parler donjohn la dessus.
manque un bon gros framework à la Zend/Symfony en NodeJS.
Mais sinon c’est classe, stable, tu peux tout faire, et c’est SUPER rapide.
Bon apres faut aimer le javascript ^^ Son principale probleme, à mon sens, c’est qu’il n’est pas “encore” fait pour des projets immenses mais plus pour des sous parties ou il officiera de maniere parfaite (ex : un serveur weboscket qui map les 2/3 tables dont t’as besoin et pas la base complete). Je l’utilise principalement en Webkit et c’est impeccable (petite appli legere et performante). De toute facon j’aime bcp la programmation évènementielle.
(et puis c’est un peu grace à NodeJS qu’on a le streaming via torrent vu que c’est un plugin nodejs de stream à la base ;))
Node.js le plus intéressant c’est d’avoir le même langage de programmation côté client et côté serveur. Et donc de pouvoir mutualiser certains modèles de données entre les deux (on peut stocker des JSON qui servent directement à la présentation, sans passer par X couches de mapping intermédiaires). Mais ça a aussi un très gros désavantage à mes yeux : Javascript. C’est un langage blindé de problèmes. Ce qui fait de Node.js un tel succès c’est que Javascript domine totalement le monde côté client, et qu’il n’y a aucune alternative viable à ce jour (sauf peut-être Dart…).
A titre personnel je préfère quand même faire du JS côté client, balancer mon JSON vers le serveur, et utiliser une API de sérialisation/désérialisation de JSON et un langage un peu plus maintenable (Jackson en Java par exemple, ou http://golang.org/pkg/encoding/json/#Unmarshal en Go).
Nodejs, c’est mignon pour les petits projets (tout est relatif…), les trucs perso ou les sites internes ou pour aller vite pour faire des mocks et tout. Le modele est interessant. En prod sur un gros projet, c’est niet.
Meme chose que GloP sur NodeJS. Aucun souci pour qu’un dev JS se fasse des mocks, mais je veux pas y toucher meme avec un baton. L’idée de base (ouais, balancons le language le plus pourri coté serveur) me donne des frissons.
Bah si le langage n’était pas aussi mauvais, ça serait une bonne idée. Mais il a la peau dure. Toutes les grosses boîtes se lancent dans des projets HTML5/CSS3/JS avec du Responsive Design en ce moment. Donc Javascript est là pour encore cinq ans dans tous les navigateurs comme langage n°1. La seule option serait qu’un langage n°2 émerge. Mon favori comme dit précédemment c’est Dart, qui est natif sur Chrome, et très bien d’utilisation (et notamment compatible avec les libs JS existantes). Mais aucun des gros du marché (Microsoft, Oracle, Apple, etc.) ne va accepter de choisir comme ça sans résister le langage de chez Google qui propulserait Chrome sur le devant de la scène comme étant le navigateur qui a un coup d’avance.
Par contre aux dernières nouvelles Dart se “compile” en JS très très bien, et avec des perfs qui font pâlir les programmes directement codés en JS. Le seul problème c’est cette phase de compilation, qui du coup rend difficile le debugging.
(Bah du coup je me demande s’il y a moyen de compiler du Dart en JS pour le faire tourner sur Node.js … :P)
En tant qu’amateur j’aime beaucoup JS même s’il y a beaucoup de cochonneries. Il faudrait juste que chaque développeur commence par lire un bon livre genre JavaScript: The Good Parts (existe en français) avant de commencer à prendre de mauvaises habitudes ou à copier-coller les premiers résultats trouvés sur Stack Overflow.
[quote=“Bussiere, post:19, topic: 55657”][/quote] Comme pour Go il y a Golang, pour Dart il y a Dartlang. Et comme d’habitude chez Google c’est extrêmement bien documenté je trouve.
etc etc.