Reprise du message précédent :
Ok.
Et même en PHP/MySQL (faut gérer les clefs étrangères tout ça), un FW de prédilection ? Genre faut-il préférer Zend, Symfony, Laravel..
J’imagine que ça dépend des devs mais peut-être qu’un FW est plus sûr qu’un autre.

 
Il n'y a pas "mieux", il y a differentes technos pour differentes choses. Il vaut bien mieux coder en PHP avec des librairies qui ont fait leurs preuves depuis des années que de faire un truc avec node et d'utiliser des trucs trop récents sans réel support.  
Ce qui compte surtout, pour un très gros projet, c'est d'être parfaitement à l'aise avec les technos que tu utilises. C'est pas le moment de "bricoler".  
Idem pour les termes "costaux, fiable, etc..." Cela n'a rien à voir avec le langage, mais cela a tout à voir avec la maîtrise du stack que tu utilises.

 
Ce que je fais, c'est que j'utilise différentes librairies sans forcément utiliser le framework en entier. Par exemple, j'utilise certaines librairies symfony comme HttpFoundation, ou encore la partie session de HttpFoundation.
 
Example d'un composer sur un très gros projet sur lequel nous bossons depuis plusieurs années:
         
       

 
Comme tu peux le voir, on utilise pas mal de librairies mais aucun framework en entier. ça permet de rester très souple et de pouvoir évoluer dans plusieurs directions.
 
Pour d'autres projets, on utilise symfony entièrement, pour certains autres projets, wordpress, on a aussi des projets en python.
 
Tout dépend de ce que l'on veut faire.

En tout cas il n'y a aucun problème pour faire de gros projets en PHP/MySql. C'est mon quotidien (et celui de mes équipes) depuis plus de 15 ans

 
Ah non mais c'est clair.

Et il y en a qui sont fonctionnaires toute leur vie, ça n’en fait pas forcément quelque chose de bien

Oui, je suis passé par cette méthode. La CLI est vraiment bien foutu !

Merci pour vos messages
Au final, mes besoin seront d'avoir une app robuste et évolutive.
Je regarde donc les CV sur Malt

REACT, facile a développer, facile a recruter.

impossible à maintenir

Ce sont 2 caractéristiques qui ne sont pas liées au langages mais aux équipes qui font les projets

ce n'est pas le meilleur, mais c'est déjà mille fois mieux que beaucoup d'autres technos, à commencer par les frameworks maisons

 
Tu peux dire ça aux gens qui ont choisi Angular au début ?  

Un bouquin à conseiller sur VueJS (récent) ?
Les tutos et ressources en ligne sont très bien, mais j'aime bien avoir un annuaire dans les transports  

y'a un plugin VS Code qui permet de faire ce que fait le Live view de Adobe Brackets (à savoir je clique sur un élément d'une CSS, et ça highlight sur la page tous les éléments qui matchent le descripteur) ?
 
je voudrais me remettre au dev web (pour mon blog), et cette feature a l'air géniale pour tout ce qui est layout

Bonjour à tous,
 
 
 
Quelqu’un ici à de l’expérience côte back pour faire une api rest rapidement et simplement ?
Côté app, pas de soucis pour moi pour consommer une api rest, je code en Obj-c ou en Swift en tant que Dev pro depuis près de trois ans maintenant suite à beaucoup de travail perso (Merci Maxime d’avoir initié l’envie de faire des apps…). Avant cela j’ai fait près de 15 ans de dev windows (Delphi puis C#) et je gère encore des api rest faites en C#.
 
Aujourd’hui j’ai besoin pour une app de faire rapidement une api rest pour attaquer une database (non existante à ce jour) le plus simplement du monde et pouvoir consommer du json dans une app mobile ainsi qu’une app desktop…
Il me serais possible de faire cela en C# ou en Swift mais se pose le pb de l’hébergement en production et c’est pas simple avec ces technos… Du coup qu’est ce qui est le plus pertinent et facile à mettre en oeuvre ? php ? node.js ?
 
Je suis preneur de toutes vos suggestions et expériences
 
Merci d’avance.
Jc.
 
ps : je poste ça ici, je ne sais pas si c’est le + approprié ...  Un avis ?

prends un truc comme amazon dynamodb, firestore, ...
ca ne te coutera pas très cher et tu gagneras tellement de temps

 
N'importe quel langage adapté que tu maîtrises bien. Donc oui, PHP, node.js, Python ... ou autre, comme go ou ruby par exemple. ça va aussi dépendre de ce que fait ton API et à quoi elle se connecte, avec quoi elle s'interface et les librairies disponibles pour cela.
Un langage peut être super sexy, si il n'y a aucune librairie derrière et que son implémentation apache ou nginx est nulle, c'est pénible et inefficace.

Java

C’est séduisant, mais je code où mes règles de gestion du coup ? Côté client ?   pas glop...  
Et puis je redoute le jour, ou je vais vouloir exporter les datas vers une autre database...
 

Oui mais non ... le temps d’appréhendé l'eco-système c'est mort ...
 

 
Bon, je vais tenter le php pendant qq jours, pour voir si c'est réaliste de partir la dessus...
 
Jc

 
J’utilise bcp Aurora qui est du relationnel et qui me permet d’avoir une grande souplesse dans la gestion et surtout concernant l’aspect high availability, mais cela ne me dispense pas d’avoir des scripts cotés serveur pour parler à la database. Dynamodb ou Firestore permettent d’éviter cela ? Si oui, ça m’intéresse... mais je ne vois rien en ce sens sur les tutos Amazon.

Tu peux appeler directement l'API dynamodb. Ou mettre une API Gateway entre toi et l'API dynamo.

tu les mets côté serveurs, les deux ont des moteurs de règles  
 
Est ce que penser au changement de db avant de commencer n'est pas un peu de l'overenginerring ?

 
C’est intéressant, particulièrement pour des apps. Je vais me renseigner un peu mieux
 

question facturation (freelance).
 
Pour des prestas de maintenance, genre grosse mise à jour de wordpress (sécurité, plugins...), je suis souvent embêté pour décider comment procéder.
En théorie quand tout se passe bien, ça prend 15 minutes, donc je fais un devis pour "1h" pour inclure la réalité du temps passé (retrouver les identifiants, faire des backups, rédiger les mails, facture...)
En pratique, de temps en temps le truc qui devait prendre 15 minutes prend 4 heures parce que la nouvelle version du plugin X a pété le thème Y, ou qu'il faut aller modifier un CSS, reparamétrer une config qui a sauté ... voir réinstaller carrément wordpress from scratch parce que tout part en vrille (déjà vécu).
 
Du coup c'est quoi votre attitude dans ce genre de cas ? Vous laissez le site pété et vous contactez le client pour demander de rallonger ? Vous réglez le problème "à vos frais" ? Vous réglez le problème et présentez une facture 4 fois supérieure au devis ? Vous devisez systématiquement 4x le temps prévu dès le départ ? ...

 
Notre attitude est la suivante :
 
On propose toujours ce que l'on appelle un "retainer", c'est à dire une option de support que le client paye tous les mois et lui assure qu'on s'occupe de son site de manière "pro-active", qu'on fait les mises à jours, qu'on monitor la connexion au site, la vitesse etc...
 
Si le client décide de ne PAS prendre cette option, il est facturé à l'heure et on facture une heure minimum, on ne facture pas à la minute. Si on met 15 heures à faire une mise à jour parce que ça foire, que des plugins ne sont pas compatible etc... ben il paye 15 heures.
 
On est TRES clair avec les clients. c'est LEUR choix de ne pas prendre de retainer, et je pense que c'est un choix irresponsable, mais ce sont eux qui décident.

Ok, merci de l'info.
Donc pour un client qui n'a pas pris l'option et qui vient vous demander de faire les mises à jour, vous ne faites pas de devis et indiquez juste que vous facturerez le temps passé à x euros de l'heure et ce quel que soit le temps passé ?
Ils n'ont pas peur de se retrouver avec une facture de malade ?

ça me parait assez logique :  
- en tant que client tu payes le forfait maintenance : le presta assume le risque si ça prend 15h au lieu de 4h prévue
- si tu payes pas la maintenance, tu payes les heures au réel.
 
C'est l'incitation à prendre la maintenance d'ailleurs : c'est prédictible

 
Si, ils ont peur et ils ont raison d'avoir peur. On leur facture déjà une heure de diag et d'évaluation de la situation, ensuite on estime un certain nombre d'heures nécessaires, mais sans garantie qu'on ira pas au delà. Quand on atteint la limite des heures qu'on a annoncées, on leur dit qu'on a besoin de plus d'heures et on refait un devis et ainsi de suite... Généralement, quand on explique cela calmement à nos clients au moment où on leur fait un site, ils choisissent un retainer (notre clientèle est une clientèle exclusivement pro).
Le tout c'est d'être très honnête à la livraison du site et d'expliquer qu'un site basé sur wordpress, c'est un site en constante mutation avec des updates constantes sans garantie qu'un jour telle ou telle update ne va pas tout casser et qu'il faut un PROFESSIONNEL pour s'occuper d'un site internet.

 
Chez nous pour les retainers, on ne précise pas le nombre d'heures prévues par mois, car on a remarqué que sinon, des clients nous faisaient chier pour savoir si on pouvait pas leur faire tel ou tel truc et essayaient d'occuper ces 4 heures quand ils ne voyaient aucune mise à jour.
Le retainer est chez nous un ensemble de services et de garanties comme par exemple : mises à jour de sécurité immédiatement déployées, pour les autres mises à jour, évaluation du risque et délais pour laisser le temps à la veille tech de voir si des bugs ont été rapportés, monitoring fin des logs apaches, des logs de connection, réévaluation régulière des règles de filtrage etc... etc...
Ainsi, le client paye pour des services, et non pour un temps de disponibilité des devs ou du support.
 
Après on a aussi d'autres retainers qui permettent aux clients de nous demander d'ajouter du contenu, de chercher pour eux des images etc... Pour ce type de retainer, là, on précise un nombre d'heures maximum (mais pas d'heures minimum non plus).

Ici, je demande déjà tous les mots de passe pour accéder à l'install de WP avant tout intervention, ça permet de filtrer, puis d'après ce que je vois, je fais un devis (généralement je pose 3 heures) et j'indique que tout est sous réserve de bon fonctionnement et de normalité
Si je découvre que telle chose est petée, que ça commence à tourner mal, c'est que la situation de base cachait quelque chose, je préviens le client et refais un devis + je propose un contrat de maintenance.
C'est comme au garagiste, tu y vas pour une vidange, et le mec te montre que ton roulement est mort, tu te dis bien que ça sera pas le même tarif que juste la vidange.

 
Nous, le contrat de maintenance, on le propose APRÈS la réparation payée à l'heure, car sinon, on a des petits malins qui tentent juste de payer un mois de maintenance...
 
Ils ont été prévenus à la livraison du site. Ils ont pas voulu du retainer ? Ils payent.

 
 
c'est ce que je voulais dire : tu factures un service, mais tu prends le risque que le service prenne plus de temps que ce que tu avais calculé. Si je paye pour que tu me fasse les MAJ, que la MAJ prenne 2h ou 24h c'est pas mon problème

Donc ça te dérange pas de payer pour 12h de boulot, sachant que je mettrai sûrement 1h, mais je prévois le risque et facture plus cher.

on peut tourner autour du pot 1000 ans, y'a 2 grandes façons d'acheter du service : forfait, et régie

La régie, du point de vue du client :
+ je paye que ce que je consomme, strictement
- je porte le risque de surconsommation (si ça prend 10h au lieu de 1h, ben je vais payer 10h), mais j'ai aussi le risque positif que si ça prend 1h au lieu de 10, ben je paye que 1h)
- la facture est imprévisible

Le forfait :
+ c'est prédictible, je sait à l'avance ce que je paye
+ je suis protégé contre l'imprévue : si ça prend 10h au lieu de 1h, c'est pas mon problème, je paye pour un résultat. je prends note que je fais porter ce risque à mon fournisseur, donc j'évalue qu'il soit en mesure de supporter ce risque.
- je prend le risque de payer trop cher si la réalité du travail est moindre

Après, et c'est vrai pour tout, il faut savoir ce que tu achètes. Si chaque fois il y a entre 30min et 1h de boulot, si tu me vends un forfait qui coute l'équivalent de 4h de régie / Time&material, tu essayes de me rouler. Soit je le sais et ça va dégrader nos relations, soit je le sais pas et tu vas t'enrichir sur mon dos. Si y'a 10h de boulot en moyenne et que tu me vends un forfait 4h : soit il y a croquette et tu vas me facturer ça autrement, soit t'es un clown et tu connais pas ton job et je fais une bonne affaire, soit tu veux vraiment me garder comme client.

par expérience, un forfait marche mieux si il est équilibré et que le prix correspond assez près à la réalité du travail effectué, de sorte que le fournisseur gagne sa vie, et le client paye un prix raisonnable. Toute déviation conduit à des meetings tendus. Déjà vécu, pas aimé (et des deux cotés en plus )

 
Avec un retainer bien foutu, tu ne payes pas pour tant d'heures de boulot, mais pour une garantie de sécurité, d'update et de monitoring. C'est bel et bien le "service" que tu payes et non le temps dévolu à assurer ce service.
Après, oui, cela peut prendre 15 minutes par mois seulement et le jour où il y a un gros problème, cela peut prendre 48 heures, voire même plus dans les cas les plus graves.

Oui enfin, entre 15min et 48h, ya un sacré gap, sur tous mes contrats de maintenance je spécifie bien qu'en cas d'avarie exceptionnelle un devis sera fait dans tous les cas avant.
Mes clients le prennent pas mal, au contraire "c'est normal" et plus juste

Ouais donc faut faire de la régie

 
Ben nous on ne fait pas comme cela. On fait payer un vrai retainer qui correspond à une vraie garantie, avec des response times, y compris week-end pour ceux qui payent extra. on fait du 2h response time business hours jusqu'à 4h response time out of business hours pour tous les incidents "critical". Nos clients sont tous des pros qui veulent une vraie garantie qu'on va s'occuper d'eux et ils ne veulent absolument pas partir dans une négo le jour où un gros problème arrivera.

Et vive le franglais