Reprise du message précédent :
Hello, des gens qui utilisent knex Js dans le coin ?

Je n'arrive pas à trouver la façon dont je dois récupérer de la data dans mon code.

Par exemple une query du genre SELECT * FROM "events", ne fonctionne pas de cette manière knex("events" ).select().
Ca me retourne toutes les fonctions dispo dans knex --'

tu as bien intialiasé ta connexion

const pg = require('knex')({
  client: 'pg',
  connection: process.env.PG_CONNECTION_STRING,
  searchPath: ['knex', 'public'],
});

 
ensuite la syntaxe est plutôt

knex.select('title', 'author', 'year').from('books')

const pg = require('knex')({
  client: 'pg',
  connection: process.env.PG_CONNECTION_STRING,
  searchPath: ['knex', 'public'],
});

knex.select('title', 'author', 'year').from('books')

La connexion c'est bon, tout était déjà fait dans le fichier fourni, le problème c'est pour la récupération.

La BDD créée est faite de cette manière.

J'avais essayé un truc du genre mais il bloque directement dès que j'utilise knex.select(), il me dit que .select() pas dispo dans knex, donc j'ai tenté un knex("events).select() pour un select all mais ça ne me retourne toujours pas ce qu'il y a en BDD mais la liste des fonctions...

C'est quoi ce truc, avec le SQL visible en front ?  

En fait en 2021 on peut faire du JavaScript du côté serveur, grâce à un truc qui s'appelle node.

Et en fait ça existe depuis 2010.

Non mais
Juste que c'est visible en front, ça ?

@chrispc : la table avec des accents ?  
 
@skylight : non

 
 
 
Edit: grillé.

 
J'ai modifié le nom étant donné que c'est un exercice et qu'il est indiqué qu'il ne faut pas le partager en public
Je le supprimerai ou le modifierai une fois que ça fonctionnera

C'est du back

 
C'est du front avec NodeJs plus besoin de back, on devient fullstack et ça permet de payer 1 dév en moins (pour les entreprises radines )

 
?
 
Ça s'appelle toujours du back hein... Et de plus, quand tu dis que ce sont les mêmes devs... c'est juste plus pratique pour les dev fullstack qui existent depuis longtemps, et au final, ça change pas grand chose. Et un dev purement front va pas devenir back comme par magie uniquement parce que c'est du JS.

Tiens d'ailleurs en 2021, on a quoi comme hébergeur (je parle pas d'infra dédiée) qui accepte du Node ?

O2switch ?

Gandi sur son offre hosting (à partir de 7.20€),  
OVH sur son offre cloud web (9.99€),
 
un peu tous en fait

Ouaip, du coup ça a bien évolué, c'est cool

Ça va dépendre du protocole choisi: quand le serveur commence à écrire une réponse il est pas obligé de la terminer (tant qu'il choisit les bons headers), il peut juste garder le socket ouvert et continuer à écrire dessus, donnant un stream du client vers le serveur.
 
Au delà de ça, le HTTP définit rien, c'est juste un flux d'octet, donc il faut que le framework spécifie un protocole qui est utilisé par dessus, généralement un truc message-oriented, ou bien qu'il te fasse / laisse en choisir un.
 
Ici dans streaming la doc mentionne spécifiquement  

Donc probablement que tu peux choisir et qu'il supporte au moins ceux là. text/event-stream c'est le media-type de SSE donc il y a une sémantique très limitée (ça fournit un framing et des évènements nommés, mais le content-type des évènements est pas spécifié) et application/x-ndjson c'est semi-standard, mais très simple: chaque message est une valeur JSON complète, avec un passage à la ligne pour signifier la fin de valeur. Tu mets ce que tu veux dans ton JSON.

Cf au dessus, je sais pas si on peut parler de standard mais genre si tu fais du ndjson tout le monde sait le parser, pire des cas c'est une boucle de `readline; json_parse` (il y a même des libs JSON "standard" qui supportent ce genre de format OOTB, genre StreamDeserializer dans serde_json).

Je regarde ça, merci pour les pointeurs  

Le problème classIque de garder la connection ouverte est la nécessité de changer le timeout sur le serveur ce qui ouvre la possibilité d’attaque.

La méthode habituelle c’est juste d’avoir un heartbeat qui garde la connection ouverte. Surtout que changer le timeout côté serveur ça va pas empêcher le client de timeouter la connection.

Merci pour votre aide, j'arrive à avancer.
Problème avec Knex c'était simplement que je n'utilisais pas la const qui avait été créé pour lancer la connexion à la BDD...
 
Bref, pour finir je cherche à filtrer un tableau d'objets et à supprimer toutes les itérations qui sont identique.  
 
Par ex : [1,2,2,3] => résultat [1,3]
 
J'utilise un reduce pour filtrer ça mais pour le moment je n'arrive pas à supprimer toutes les itérations qui étaient en double.
 
Vous avez une solution en JS pas mal pour ça ?

stocker les objets par lesquelles tu es déjà passé, dans une map avec leur id ou une clé qui dépend des critères qui te permettent de déterminer si c'est un boublon, et vérifier si l'objet existe déjà dans la liste.
Et du coup tu peux passer d'un reduce à un filter.
 
 

Thanks, ça fonctionne bien

 
Ca supprime les doublons juste ca non ? Son exemple fonctionne pas [1,2,2,3] -> [1,3]

nan mais il parlait de supprimer les doublons, donc à mon avis garde un seul unique.
Alors oui s'il faut suppriler les doublons tu adaptes le count pour coller un compteur dans la map et compter dans ce cas mais alors il faut faire une deuxième passe.

J'ai trouvé avec un double filter donc ça me convenait déjà avec ce que tu m'avais envoyé la première fois + légère modif

I guess tu as une bien meilleure solution que mon truc fait à l'arrache durant une réunion à la con chiante

Je n'arrive pas à voir comment tu l'utiliserais dans son cas

Pour un projet perso, Vue ou Svelte ?
C’est pour mon projet avec des fragments markdown, pour chercher / assembler les fragments.
Je connais pas trop JS vanilla, mais j’ai fait un peu de Typescript  
React me fait un peu peur, Angular idem (même si ce serait pas idiot de l’apprendre vu mon employeur )

Vue pour la comu, Svelte pour le fun

React / Vue : même courbe d'apprentissage . Mais j'ai trouvé qu'ecrire du code vue était un peu plus plaisant , communauté sympa mais un peu moins de ressources classes prête à l'emploi
 
J'ai adoré Nuxt au passage pour guider le démarrage

hyperapp

Je dois rater un truc. Les deux libs ont pas du tout la même portée ootb, comment tu peux dire ça sans inclure des libs en plus surtout côté react, ce qui logiquement rendra plus pentue la courbe de cet ecosystème?

plus de cours, plus de recettes toutes prêtes, plus de librairies, plus d'aide sur SO  que côté vue

je pense qu'au final, c'est similaire , même si vue est intrinsèquement plus simple

Mais de toutes manières React est exclu d'office à cause du JSX non ?

tu crois que tu écris du HTML en vue ?

Troll mis à part, j'avoue préférer d'assez loin la méthode de Vue, avec une section "template" dans les SFC (après je sais que les SFC sont compilés en JS)

Sachant que tu n'as pas deux implem similaires entre deux projets dans deux sociétés différentes c'est pas vraiment un avantage en soit, si? Après le fait que vue soit un peu plus opiniated ça doit compenser une partie.