Reprise du message précédent :
merci. C'est juste que y'a un mec qui m'en a parlé autour d'une offre d'emploi et que leur site web est pas clair.

Je viens de découvrir Flif : si c'est pas un fake, c'est prometteur !

Je partirai plus sur webp:
 
https://fr.wikipedia.org/wiki/WebP
 
Google qui supporte en background, ca aide pas mal faut dire...
 
Cela dit, le taux de compression n'est pas le seul metrics important, la vitesse de traitement l'est tout autant...

Question API REST:
 
On utiilse un webservice GET de listing d'entitéA qui a des paramètres de filtrages non obligatoires. Les résultats sont obligatoirement paginés par 25/50/100 car quand on a crée ces webservices, on réfléchissant en terme d'IHM
 
Maintenant, on veux utiliser ce webservice en dehors de nos IHMs pour faire un traitement périodique (CRON) et forcément, on a besoin de beaucoup plus de data que 25/50 ou 100...
 
Et là, on nous dit "utilisez la pagination" ... Genre si on a 20000 lignes à récupérer, ils veulent qu'on fasse 200 appels récupérant 100 entités.. à la suite.. (simulation de clique utilisateur sur les liens de pagination quoi ...) au lieu d'en faire un seul en oneshot  qui nous retourne les 20000 entités..
 
Ça me parait aberrant mais d'un autre coté, c'est vrai qu'il y a des risques :
- de saturer la base de données où sont stockées les entités
- que notre serveur à nous arrive pas à traiter en one shot 20000 entités complexes  
 
Bref je suis paumé, un avis ? merci

Moi ce qui m'a ticker, c'est d'avoir une image "responsive". Utiliser un seul fichier pour afficher les thumbnail et l'images dans différentes dimensions, en limitant le nombre d'octet téléchargé en fonction du besoin bien sûr, j'ai trouvé ça prometteur. Fini la galère des multiples fichiers de la même image dans différentes dimensions !

C'est sûr qu'avoir un système de pagination aussi limité, c'est pas terrible. M'enfin, dans l'absolu, j'ai déjà vu pire, c'est pas non plus aberrant.
Pis, à la rigueur ça peut permettre de distribuer les appels, de les paralléliser. Il y a de fortes chances que le traitement de la requête qui te retourne tes 100 enregistrements ne le soit pas, lui, parrallélisé

Je connais pas bien le détail de l'impl, mais webp supporte le multi images embed.
 
Maintenant, un truc comme ca, ca veut dire qu'a un moment ou un autre, le serveur passe un algo pour te sortir ca, ya rien de magique en informatique hein, donc on retourne sur le pb: transiter moins, oui, tout le monde veut ca, mais quel cout CPU pour...
 

Si tu connais la taille de la liste totale, ou est le soucis ? C'est même un avantage: tu peux répartir le cron sur une plage de temps donnée, pour gérer le traitement sans surcharger le serveur... En gros, ton cron, à un système de buffer en interne...

 
Pas nécessairement, ça peut être le client qui ne télécharge que ce dont il n'a besoin. Ca dépend de l'implémentation du format par le client.

Merci pour vos avis

Ca répond pas uniquement à ta question, mais sur mon projet, on a "esi-iser" le rendu json d'une entité.
 
Du coup après peu importe la taille du listing, ce n'est qu'on assemblage de morceaux de json precalculés.

C'est à dire ?

Regarde ESI (Edge Side Includes) et Varnish (qui permet, entre autre chose, de stocker des ESI)
 
Par exemple http://blog.jeremm.fr/?p=188
Édit: et plus dans le cas présent : https://dutchweballiance.nl/techblo [...] -rest-api/
 
C'est aussi une bonne piste pour faire une recherche qui dépote.

Ha tres interessant merci ! Le premier lien me rappele clairement le Full Page Cache de magento, pas de très bon souvenirs
 
Mais l'idée d'une passerelle de cache devant la bdd est super !

Dites, vous connaissez une méthode rock stable pour déclencher du JS quand une animation css est finie ?
 
Une sorte de mini lib ou je ne sais quoi ? car je faisais à la main avec les animationend / webkitAnimationEnd + Modernir.prefixed, ça me renvoie 1 event pour chaque animation finie... donc pas top. J'ai testé un plugin jQuery aussi pour pouvoir faire un $elem.onAnimEnd(function(){ // Do something }); mieux mais on dirait qu'il me prend pas en compte les delays de chaque animation.. donc j'en appelle à votre savoir

quelqu'un a vu un workerpool intéressant en JS ? s'il surveillait les morts, qu'il savait interrompre un worker en cours et qu'il avait un système de priorité pour choisir qui expédier quand il a un slot de libre, ça serait cool.

Bonjour, depuis que j'ai pu jouer avec Postgres je ne peux pas considérer sérieusement un job listant MySQL. Est-ce soignable ?

Non
Je n'ai pas trouvé d'usage de stockage structuré pour lequel je me dis que postgres est pourri. Y compris du nosql avec les champs json

 
Moi je trouve ça plutôt sain comme réaction

et je suis carrément amoureux de pg_notify, j'use et j'abuse de postgresql comme bus de données  
(un peu de socket.io dessus, et un event de ma base de données provoque une réaction immédiate de l'UI)

moi je préfère SQlite, mais au pire postgres

listen/notify a été un poil superchargés en 9.0 entre le payload et pg_notify
 
(en 8.4 t'avais que NOTIFY channel, donc genre tu devais aller insérer ton payload dans une table de notifications et le listener devait aller fouiller dedans pour voir s'il y avait des trucs pour lui)

c'est à ce moment que je l'ai découvert  
 
Je l'ai utilisé avec backbone, mais c'est le genre de truc trivial a intégrer dans flux / react

https://github.com/hmlb/phpunit-vw

Déja vu hier

Accelerated Mobile Pages.
Je trouve ça intéressant. J'espère que ça ne va pas sombrer comme tant d'autres.

Des libs JS de lazy-loading d'images à conseiller ?

Du home Made

dites les gens, je songe à remplacer ember, c'est quoi votre truc préféré ?
 
handlebars peut éventuellement être remplacé aussi, mais le truc doit tourner sans aucun appel à eval() ou à new Function() (actuellement le handlbars est pré-compilé).

Elm, ou un truc à base de React si tu dois rester en JS pur.

 
Des raisons pour le remplacement de Ember ?

ça me pète les couilles, j'ai passé 1an dessus et je suis toujours pas à l'aise et je sais jamais prédire son comportement, la greffe ne prend pas.
J'arrive pas à prédire les chaines d'évènements et c'est crucial pour faire la première lecture des attributs synthétisés qu'on observe, j'arrive pas à capter et retenir tout ce qui tourne autour des lifecycles ember-data, mes sauvegardes d'objets fail de temps à autre parce que j'ai tenté de faire un truc interdit pendant une certaine fenêtre de temps durant la sauvegarde (je suppose que c'est un retour de worker, je sais pas trop, ça me gonfle). Bref je passe ma vie à me battre contre le truc au lieu de bosser avec. Alors que j'ai des problèmes bien plus importants auxquels je veux me consacrer autour du webgl multi-résolution et des maths un peu relous genre courbe de Cornu et trochoïdes, passer 2-3h à capter pourquoi un observateur se déclenche pas me saoule.
 
Le problème c'est qu'évidemment, j'en ai foutu partout, donc ça va être un peu le bordel à changer. Mais j'ai 2 petits trucs qui sont indépendants qui me permettrons de me faire une idée sur le remplaçant. Après, je crois que j'aurai pas le choix que de faire un big bang.

Pars sur du ultra light : backbone, ampersand , ...
Tu auras toujours de la magie si tu prends un autre des grosses usines à la mode : angular1 (j'aime pas, mais c'est d'une efficacité redoutable), meteor,  angular2

D'un autre côté, te connaissant, si tu prends un truc de bas niveau, tu vas réimplémenter un truc par dessus

Aujourd'hui, si je devais partir de zéro, j'utiliserai backbone + react, et probablement des données immutables . Pas sur que react apporte quoi que ce soit dans ton use case

merci, je vais googler tout ça.

Moi j'utilise mithril en ce moment. Très peu de magie (en gros l'algo de diff du DOM) et tu retiens toute l'API en 1 jour !

Justement je me demandais ce qu'apportait un gros framework genre Ember par rapport à mithril/Vue..etc..

un pack prêt a l'emploi, et des choix déjà fait.

 
J'avais testé des libs spécialisées genre LazyLoadXT (mieux que Lazyload), au final je suis parti sur onScreen.js qui fait aussi du lazyload

Finalement je vais sans doute partir sur https://github.com/vvo/lazyload

HALP
 
quelqu'un peut me dire pourquoi le site publique du taf (nepasquote) www.sdis71.fr se charge sous chrome , mais plante sous IE et FF :  
 
Erreur d'encodage de contenu
 
La page que vous essayez de voir ne peut être affichée car elle utilise un type de compression invalide ou non pris en charge.
 
    Veuillez contacter les propriétaires du site pour les informer de ce problème.

chez moi ça faile aussi sous chrome, t'as peut-être le truc en cache.