L'Agence serverless

Nuage est une agence spécialisée dans le Cloud, Web & Data. Nous accompagnons nos clients Startup & PME dans la réalisation de leur projet que ce soit en matière d'architecture Cloud, de développement web et d'exploitation de leurs datas en unissant ces 3 compétences pour délivrer des projets digitaux complets.

Development Process

Nos expertises

Du design à l'intelligence artificielle, en passant par les sites Web et applications mobiles, Nuage vous accompagne sur la totalité de votre projet digital.

  • Cloud

    Cloud

    Nos architectes Cloud vous accompagneront dans l'assemblage des meilleurs services Cloud afin de répondre à votre besoin. Nuage est partenaire officiel avec AWS et Snowflake.

  • Web

    Web

    Notre technologie de "web-first development" permet de construire des applications Web, mobiles (iOS, Android) et Desktop (Windows, MacOS) à partir d'une même base de code.

  • Data

    Data

    C'est l'enjeu majeur de tous nos clients. La maitrise des données pour comprendre, agir ou prédire. Nous mettons en place pour vous les meillesures solutions afin de regrouper la donnée facilement et permettre son exploitation

Choisissez le meilleur avec le serverless

Nous mettons à profit notre maîtrise des technologies Cloud, pour mettre le Cloud au service de votre réussite

  • Sécurité

    Sécurité

    Protection de vos utilisateurs et de votre activité, à tous les niveaux

  • Scalabilité

    Scalabilité

    Adaptation automatisée aux besoins de vos services pour suivre la croissance de votre activité

  • Green

    Green

    Préservez la planète en ne consommant que les ressources informatique dont vous avez besoin

  • Économique

    Économique

    Vous n'êtes facturés que pour le temps serveur réel à la milliseconde près, en toute transparence

Avantages

Bénéficiez d'avantages exclusifs en travaillant avec Nuage

  • AWS logo

    En tant que partenaire avancé avec AWS, nos clients obtiennent des crédits afin de tester gratuitement nos solutions techniques.

    En savoir plus
  • La marque de l'État

    Récupérez 20% du montant de notre prestation en crédit d'impôt !

    En savoir plus

Découvrez nos publications

Retrouvez nos actualités et les articles de nos experts sur les nouveautés en matière de web, cloud & data

  • GraphQL vs REST : quelle API choisir pour ma startup ? hero image

    GraphQL vs REST : quelle API choisir pour ma startup ?

    Pour construire une API, vous avez le choix entre SOAP, gRPC, REST, GraphQL… mais comment choisir ? SOAP, protocole avec des exigences spécifiques, est aujourd’hui totalement déprécié et utilisé uniquement dans de très grosses sociétés qui ont plus de difficultés à opérer un virage dans leur stack technologique. gRPC, peu adapté à l’usage web c’est un service dont l’usage se tourne plutôt vers la technique pour faire communiquer des applications utilisant des langages différents entre elles. Concentrons-nous aujourd’hui sur le choix entre REST et GraphQL. Souvent étiqueté comme un meilleur REST, GraphQL aide en effet à résoudre certaines problématiques auxquelles les développeurs sont confrontés lors de la création d’API REST. Alors est-ce vrai ? Dans les faits REST et GraphQL sont deux méthodes bien différentes qui ont chacune des avantages et des inconvénients. Explorons alors la différence qui existe entre ces deux technologies. 1. Qu’est-ce qu’une API RESTful ? REST ou (Representational State Transfer) est un ensemble de normes et de principes architecturaux qui structurent la façon dont vos données doivent transiter au sein de votre application ou avec les services externes. Les API RESTful se basent sur le protocole HTTP pour transférer de la donnée. NB :  Le terme RESTful est utilisé pour parler des API REST, néanmoins toutes les API REST sont des API mais toutes les API ne sont pas RESTful. REST est généralement préférée à d'autres technologies similaires car REST utilise moins de bande passante. a. Comment fonctionne une API RESTful ? Comme nous l’avons déjà évoqué, les API REST se basent sur le protocole HTTP. Les méthodes les plus courantes sont les suivantes : GET L’utilisation de GET par le client, lui permet d'accéder aux ressources se trouvant à l’URL spécifié sur le serveur. Si vous souhaitez obtenir la liste de vos utilisateurs vous utiliserez donc la requête suivante : GET /users De la même manière si vous souhaitez obtenir les détails sur un utilisateur en particulier alors vous utiliserez :  GET /users/1 POST L’utilisation de POST par le client, lui permet d’envoyer des données au serveur. Si vous souhaitez créer un nouvel utilisateur vous utiliserez donc la requête suivante :  POST /users PUT L'utilisation de PUT par le client, lui permet de mettre à jour des ressources existantes sur le serveur. Pour mettre à jour un utilisateur existant vous utiliserez donc : PUT /users/1 DELETE L’utilisation de DELETE par le client, lui permet de supprimer des ressources existantes sur le serveur. Pour supprimer un utilisateur vous devrez donc utiliser : DELETE /users/1 NB : Si l’utilisateur ne possède pas les droits appropriés alors la requête échouera. 2. Les avantages de REST a. Courbe d’apprentissage Par rapport aux autres types d’API, les API RESTful ont l’avantage d'être plus facile à apprendre. b. Meilleurs temps de chargement La mise en cache et le stockage des données permettent de réduire le nombre d'interactions entre le client et le serveur. Ainsi le temps de chargement s’en trouve amélioré. NB : L’utilisation du “caching” n’est pas conseillée. En effet, le risque est que vous fassiez un appel API vous retournant des données périmées s’il n’y a pas eu de refresh du cache. De plus avec les technologies actuelles telles que le Serverless il est facile d’obtenir des temps de chargement aussi rapide voir meilleurs sans utilisation de cette méthode. c. Maintenabilité La structuration des requêtes imposée par le fait que les API RESTful soient stateless vous permet en tant que développeur de comprendre facilement une ancienne requête API déjà existante le code. d. Indépendance Les API REST sont décorrélées de la technologie utilisée. Vous pouvez donc écrire vos applications client-serveur dans le langage de votre choix sans affecter votre API. De la même manière, si vous changez la technologie sous-jacente d’un côté ou de l’autre cela n’aura pas d’impact. 3. Les inconvénients de REST a. Allers-retours multiples Les API REST sont constitués de points de terminaison nombreux. Vous devrez donc augmenter le nombre de requêtes pour obtenir l’ensemble des ressources dont vous avez besoin. b. Over-fetching et Under fetching En plus de devoir faire plusieurs requêtes pour obtenir les ressources dont vous avez besoin, vous serez aussi confronté à l’une des plus grosses limitations de REST. De par sa conception, REST permet l’accès aux données uniquement via des points de terminaisons qui renvoient des ensembles de données fixes. Cela se traduit donc par l’obtention d’un surplus d’informations dans certains cas ou à l’inverse un manque d’informations. c. Hiérarchie Les API REST fonctionnent avec des identifiants de ressource uniforme (URI) ce qui les rends moins adaptées pour fonctionner avec des ressources organisées de manières différentes. d. Stateless Par sa condition stateless, le serveur ne stocke pas les requêtes ou réponses précédentes. Cela implique qu’il ne sait pas si une requête est faite pour la première fois ou non. Elle doit donc être traitée à partir de zéro à chaque fois. 4. Qu’est-ce qu’une API GraphQL ? GraphQL est un langage de requête et de manipulation de données open source pour les API, ainsi qu'un moteur d'exécution permettant d'effectuer des requêtes avec des données existantes. GraphQL a été créé par Facebook, et rendu public en 2015, dans le but d’améliorer l’expérience des développeurs d’applications mobiles travaillant avec des API REST. Les API GraphQL se basent également sur le protocole HTTP pour transférer de la donnée. La différence notable avec REST est que GraphQL permet de faire du temps réel. Ce qui fait le succès de GraphQL est la possibilité de demander et recevoir uniquement les données dont vous avez besoin et rien d’autre. Cela facilite l’évolution de vos API au cours du temps. 5. Les avantages de GraphQL a. Le data Fetching Contrairement à REST, avec GraphQL vous pouvez requêter uniquement les ressources dont vous avez besoin. Cela vous offre un gain en terme de nombres de requêtes à effectuer pour récupérer l’ensemble des données recherchées. Prenons un exemple dans lequel vous souhaitez afficher les détails d’un produit : query webProductQuery { product(id: 1) { namecolorsize category price imageURL } } Cette requête peut aussi être simplifié si le viewport est plus petit (mobile) : query mobileProductQuery {   product(id: 1) {     name     price     imageURL   } } Vous pouvez mieux comprendre la différence de récupération des ressources avec une API REST vs GraphQL avec l’illustration suivante. b. Pas d’over-fetching ou under-fetching Conséquence directe du Data fetching, avec GraphQL, fini l’over et l’under fetching puisque vous pouvez demander les ressources exactes dont vous avez besoin dans vos requêtes. c. Maintenabilité accrue GraphQL offre une maintenabilité accrue grâce à un ensemble d’outils intégrés : Le playground, vous permet de tester vos requêtes sur deux environnements (Sandbox et production). La documentation intégrée. Les schémas de données. Le Voyager, qui vous offre la possibilité de visualiser vos points de terminaisons. Vous pouvez tester l’outil en cliquant ici. d. Le temps réel GraphQL offre la possibilité d’obtenir des mises à jour en temps réel du serveur avec les subscriptions. A l’aide d’une fonction comme celle-ci dessous : subscription {   online_users {     id     last_seen     user {       name     }   } } Vous pourrez visualiser l’ensemble des utilisateurs en ligne à chaque fois que celui-ci changera. Cela s’avère particulièrement utile lorsque vous travaillez à plusieurs pour éviter les conflits de version. e. Batching Avec GraphQL vous pouvez encapsuler plusieurs requêtes en une. Prenons un exemple dans lequel vous souhaitez afficher le nom et prénom d’un utilisateur et le prénom d’un second.  Avec REST vous devrez effectuer deux requêtes comme suit : query { user (id:1) { id firstName lastName } } Puis une seconde pour le second utilisateur query { user (id:2) { id firstName } } Tandis qu’avec GraphQL vous pourrez les encapsuler comme ceci : query { user (id:1) { id firstName lastName } } user (id:2) { firstName } f. Flexibilité GraphQL étant flexible par nature grâce au schéma, vous pouvez apportez des modifications côté client sans besoin d’effectuer des actions côté serveur. Ceci est une conséquence directe du data fetching. En effet, la possibilité de spécifier les données dont vous avez besoin, permet de moins avoir à modifier votre back-end si le besoin de données de votre front-end évolue. 6. Les inconvénients de GraphQL a. Courbe d’apprentissage GraphQL nécessite des connaissances de base, surtout concernant la conception du schéma. Néanmoins les gains en performance et la complexité des API que vous pouvez construire valent l’investissement. b. Mise en cache web GraphQL ne s'appuie pas sur les méthodes de mise en cache HTTP. Il reste néanmoins possible et simple de mettre en place un système de cache via la mise en place d’un “unique identifier" par exemple. 7. Pourquoi avons-nous choisi GraphQL chez Nuage ? a. Performances Il ne fait aucun doute que GraphQL est plus performant que les API RESTful en raison de sa capacité à ne requêter que les données effectivement souhaitées par le client : les appels aux bases de données ou APIs sous-jacentes ainsi évitées génèrent un gain substantiel à l’échelle. b. Complexité des requêtes Avec GraphQL, les requêtes étant réunies en un seul point de terminaison, ces requêtes peuvent devenir plus complexes au fil du temps. Pour REST, les points de terminaisons étant multiples, les requêtes doivent rester simples et il va falloir les multiplier pour récupérer les données que vous souhaitez. Il n’est d’ailleurs pas rare de constater dans les entreprises utilisant les API RESTful, un cumul de centaines d’API dont on ne sait plus bien à quoi elles servent. c. Popularité et support de la communauté Avec un taux d’adoption grandissant, GraphQL est en pleine expansion et devrait continuer son ascension dans les années à venir. REST, implanté depuis plus longtemps possède une communauté bien implantée et il est par conséquent plus facile de trouver des développeurs maîtrisant la technologie des API REST. d. Courbe d’apprentissage En ce qui concerne la courbe d’apprentissage, REST étant intégré dans la plupart des principaux langages de programmation et des frameworks populaires, il est assez simple à prendre en main et nécessite moins de connaissances au départ. En toute logique GraphQL exige de meilleures connaissances pour se lancer. Néanmoins les gains en performance et la complexité des API que vous pouvez construire valent l’investissement. e. Schéma typé Avec GraphQL, les API exposées au client sont écrites en SDL. Ces schema définissent les règles d’accès au serveur par le client. Ce mode de fonctionnement permet d’éviter les incohérences de données qui peuvent parfois survenir avec les API RESTful. f. L’over fetching ou l’under fetching Comme nous l’avons exposé précédemment, la construction des API RESTful en plusieurs points de terminaisons et la multiplicité des requêtes entraîne parfois une remontée de données excessive ou insuffisante. GraphQL résout ce problème avec le Data Fetching et le point de terminaison unique. Vous obtenez les données dont vous avez besoin, rien de plus, rien de moins. g. Les points de terminaison Comme nous l’avons évoqué plusieurs fois, GraphQL réunit les informations en un seul point de terminaison. Ce qui est un très gros avantage sur les API REST. Prenons un exemple dans lequel vous souhaitez afficher les détails d’un produit avec son numéro d’identifiant. Avec REST vous devrez utiliser un point de terminaison comme suit :  /users/1/ Maintenant pour afficher les avis concernant ce produit, vous devrez envoyer votre requête à un autre point de terminaison comme suit : /users/1/reviews Supposons que vous souhaitiez maintenant afficher les photos du produit : /users/1/photos Pour réunir ces informations en un seul point de terminaison il vous faudrait donc développer :  /users/1/photos_and_reviews Et soyons honnête cela serait du bricolage. Avec GraphQL et le Data Fetching, vous pourrez récupérer ces informations sans aucun soucis en seul point de terminaison : query webProductQuery { product(id: 1) { namesize category photos { url } reviews { date body } } } h. Rapidité de développement Avec une API REST vous devez construire vos points de terminaison en fonction des vues de votre application. Le problème avec cette approche est que dès que vous souhaitez apporter une modification à votre Front-end vous risquez de récupérer plus de données ou moins de données qu’avec votre requête antérieure. Vous devrez donc également modifier votre Back-end pour que les modifications apportées au Front soient prises en compte. Grâce au Data Fetching, GraphQL est plus flexible ce qui vous permet d’apporter des modifications à votre Front sans vous préoccuper de votre Back. 8. Résumé Alors GraphQL ou REST ? Vous l’aurez bien compris, donner une réponse ferme et définitive n’est pas chose aisée puisque les deux technologies offrent leur lot d’avantages et d’inconvénients.  Néanmoins chez Nuage, nous avons fait notre choix, et c’est GraphQL. Même s’il est plus récent et possède par conséquent une communautée moins grande, GraphQL représente un choix judicieux car il permet notamment de résoudre les problèmes rencontrés lors de la construction d’API RESTful tout comme le fut REST en son temps face à SOAP. GraphQL est aujourd’hui une option de choix pour construire des API complexes, rapides avec un schéma strict permettant un accès cohérent à vos données, le tout réuni en un seul point de terminaison.

    The photography of Vincent Le Gentil
    Vincent Le Gentil 02/01/2023 - 11 min
  • Qu’est-ce que le "serverless" ? hero image

    Qu’est-ce que le "serverless" ?

    Le Serverless est un modèle de cloud-computing dans lequel le client peut créer et exécuter ses applications sans avoir à se soucier de la partie serveur. Contrairement à ce que son nom peut laisser penser, le code des applications continue de s'exécuter sur des serveurs mais la gestion de ses derniers incombe désormais au fournisseur de la solution cloud. Le modèle Serverless face aux modèles de cloud computing standards type IaaS (Infrastructure as a Service) ? Avec un modèle IaaS, le client achète ou loue des serveurs auprès d'un fournisseur cloud. Il va donc payer pour faire tourner en permanence des composants d’un serveur actif. Dans ce cas, c’est au client de gérer la mise à l’échelle de l’infrastructure en cas de montée en charge. “ Avec une offre IaaS l’infrastructure cloud reste active même lorsqu’aucune sollicitation n’est en cours.” A contrario avec un modèle Serverless, lorsqu’un événement déclenche l'exécution d’un code d'application, le fournisseur cloud fournit les ressources nécessaires à la charge de travail correspondante. Cela engendre deux choses, l’infrastructure cloud se met en route que lors d’un besoin et le client ne paie que pour cette durée de consommation. “Avec le Serverless vous ne payez que pour les ressources utilisées et votre solution tourne uniquement en cas de besoin. Une solution économique et écologique.” Les avantages du modèle Serverless Gain de temps Traditionnellement les équipes techniques, développent et déploient les applications web sur des serveurs dont ils sont responsables ce qui nécessite un entretien régulier : Maintien des serveurs disponibles (Même non utilisés) Maintenance de serveurs et management de leurs ressources Application des patches de sécurité Ajustement de la charge en fonction de l’évolution … En bref, c’est un travail complexe et chronophage pour les équipes, qui vient s’ajouter à la mission initiale : construire et maintenir des applications. Avec le Serverless, c’est terminé ! C’est le fournisseur du service cloud qui est responsable de l’infrastructure cloud et de la mise à l’échelle des applications. Ainsi les développeurs peuvent se concentrer sur leur mission principale et ils n’ont plus qu’à compiler leur code dans des conteneurs pour déployer les applications. Scalabilité Comme évoqué précédemment, c’est le déclenchement du code de votre application qui déclenche chez le fournisseur cloud, l’allocation des ressources nécessaires à l'exécution de votre charge de travail. Ce qui permet une mise à l’échelle quasi infinie et instantanée.  Pour faire simple, si vous recevez 20000 requêtes en même temps (Suite à un passage télé par exemple) alors le fournisseur cloud met à disposition de votre application les ressources nécessaires en face de cette charge afin de pouvoir l’absorber durant le temps nécessaire au traitement de cette dernière. Économie Contrairement aux services d’hébergement classiques ou de cloud computing standards, avec le Serverless, fini de faire tourner des serveurs en permanence (même quand aucune ressource n’est nécessaire) et de payer pour ce service.  Avec une Architecture Serverless, les ressources nécessaires sont allouées et mises à l’échelle automatiquement, par le fournisseur de service cloud, en fonction de la charge de travail correspondante.  Vous êtes ainsi facturé à la milliseconde et la facturation s’arrête aussitôt la charge de travail réalisé. Écologie Si avec le Serverless vous ne payez que pour ce que vous consommez c’est simplement car vos applications ne sont lancées qu’en cas de besoin. Concrètement, lorsqu’un événement déclenche l'exécution d’une tâche, alors les ressources nécessaires se mettent en place pour exécuter cette charge de travail. Une fois le code exécuté vous n’avez plus besoin de ressources et ne faites donc tourner aucune machine.  “Sans charge de travail votre infrastructure possède un bilan carbone à 0”.

    The photography of Vincent Le Gentil
    Vincent Le Gentil 20/10/2022 - 3 min

Nos partenaires

  • Nouvelle Aquitaine
  • AWS
  • La French tech
  • Snowflake
  • BPI Finance