Le cas de Prisma dans le Jamstack

L’approche Jamstack est née d’un discours prononcé par le PDG de Netlify, Matt Biilmann, lors de la Smashing Conf de Smashing Magazine en 2016.

Les sites Jamstack diffusent du contenu pré-rendu statique via un CDN et génèrent du contenu dynamique via des microservices, des API et des fonctions sans serveur. Ils sont généralement créés à l’aide de frameworks JavaScript, tels que Next.js ou Gatsby, et de générateurs de sites statiques, Hugo ou Jekyll, par exemple. Les sites Jamstack utilisent souvent un flux de travail de déploiement basé sur Git via des outils tels que Vercel et Netlify. Ces services de déploiement peuvent être utilisés en tandem avec un CMS sans tête, tel que Strapi.

L’objectif de l’utilisation de Jamstack pour créer un site est de créer un site hautement performant et économique à gérer. Ces sites atteignent des vitesses élevées en pré-affichant autant de contenu que possible et en mettant en cache les réponses sur « le bord » (AKA s’exécutant sur des serveurs aussi proches que possible de l’utilisateur, par exemple en servant un utilisateur basé à Mumbai à partir d’un serveur à Singapour au lieu de San Fransisco).

Les sites Jamstack sont plus économiques à gérer, car ils ne nécessitent pas l’utilisation d’un serveur dédié en tant qu’hôte. Au lieu de cela, ils peuvent provisionner l’utilisation à partir de services cloud (PAAS) / hôtes / CDN pour un prix inférieur. Ces services sont également configurés pour évoluer de manière rentable, sans que les développeurs ne modifient leur infrastructure et ne réduisent leur charge de travail.

L’autre outil qui compose cette combinaison est Prisma – un ORM open source (mappage relationnel d’objet) conçu pour TypeScript et JavaScript.

Prisma est un outil JavaScript / TypeScript qui interprète un schéma écrit dans les normes de Prisma et génère un module de type sécurisé qui fournit des méthodes pour créer des enregistrements, lire des enregistrements, mettre à jour des enregistrements et supprimer des enregistrements (CRUD).

Prisma gère les connexions à la base de données (y compris la mise en commun) et les migrations de base de données. Il peut se connecter à des bases de données qui utilisent PostgreSQL, MySQL, SQL Server ou SQLite (en outre, la prise en charge de MongoDB est en préversion).

Pour vous aider à vous faire une idée de Prisma, voici quelques exemples de code de base pour gérer le CRUD des utilisateurs :

import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

const user = await prisma.user.create({
  data: {
    name: Sam,
    email: 'sam@sampoder.com',
  },
})

const users = await prisma.user.findMany()

const updateUser = await prisma.user.update({
  where: {
    email: 'sam@sampoder.com',
  },
  data: {
    email: 'deleteme@sampoder.com',
  },
})

const deleteUser = await prisma.user.delete({
  where: {
    email: 'deleteme@sampoder.com',
  },
})

Le schéma Prisma du projet associé ressemblerait à :

datasource db {
  url      = env("DATABASE_URL")
  provider = "postgresql"
}

generator client {
  provider = "prisma-client-js"
}

model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  name      String?
}

Les cas d’utilisation de Prisma

Armés d’une connaissance du fonctionnement de Prisma, explorons maintenant où nous pouvons l’utiliser dans les projets Jamstack. Les données sont importantes dans deux aspects de Jamstack : lors du pré-rendu des pages statiques et sur les routes de l’API. Ce sont des tâches souvent réalisées à l’aide d’outils JavaScript, tels que Next.js pour les pages statiques et Cloudfare Workers pour les routes d’API. Certes, ceux-ci ne sont pas toujours atteints avec JavaScript — Jekyll, par exemple, utilise Ruby ! Donc, je devrais peut-être modifier le titre pour le cas de Prisma dans Jamstack basé sur JavaScript. Quoi qu’il en soit, en avant !

Un cas d’utilisation très courant pour le Jamstack est un blog, où Prisma sera utile pour un blog pour créer un système de réactions. Vous l’utiliseriez dans les routes d’API avec une qui récupèrerait et renverrait le nombre de réactions et une autre qui pourrait enregistrer une nouvelle réaction. Pour y parvenir, vous pouvez utiliser le create et findMany méthodes de Prisma !

Un autre cas d’utilisation courant pour le Jamstack est une page de destination, et il n’y a rien de mieux qu’une page de destination avec des statistiques impressionnantes ! Dans le Jamstack, nous pouvons pré-rendre ces pages avec des statistiques extraites de nos bases de données que nous pouvons obtenir en utilisant les méthodes de lecture de Prisma.

Parfois, cependant, Prisma peut être légèrement exagéré pour certaines tâches. Je recommanderais d’éviter d’utiliser Prisma et les bases de données relationnelles en général pour les solutions qui ne nécessitent qu’une seule table de base de données, car cela ajoute une complexité de développement supplémentaire et souvent inutile dans ces cas. Par exemple, il serait exagéré d’utiliser Prisma pour une boîte d’inscription à une newsletter ou un formulaire de contact.

Alternatives à Prisma

Ainsi, nous pourrions utiliser Prisma pour ces tâches, mais nous pourrions utiliser une pléthore d’autres outils pour les réaliser. Alors, pourquoi Prisma ? Passons en revue trois alternatives Prisma, et j’essaierai de vous convaincre que Prisma est préférable.

Bases de données/services cloud

Des services comme Airtable sont incroyablement populaires dans l’espace Jamstack (je l’ai moi-même utilisé une tonne), ils vous fournissent une base de données (comme une plate-forme) à laquelle vous pouvez accéder via une API REST. Ils sont très amusants à utiliser et à prototyper, cependant, Prisma est sans doute un meilleur choix pour les projets Jamstack.

Premièrement, le coût étant un facteur majeur dans l’attrait de Jamstack, vous voudrez peut-être éviter certains de ces services. Par exemple, au Hack Club, nous avons dépensé 671,54 $ sur un abonnement Airtable Pro le mois dernier pour notre petite équipe (yikes !).

En revanche, l’hébergement d’une base de données PostgreSQL équivalente sur la plateforme Heroku coûte 9 $ par mois. Il y a certainement un argument à faire valoir pour ces services cloud basés sur leur UI et leur API, mais je répondrais en vous orientant vers Prisma’s Studio et le client JavaScript/TypeScript susmentionné.

Les services cloud souffrent également d’un problème de performances, d’autant plus que vous, en tant qu’utilisateur, n’avez pas la possibilité de modifier / améliorer les performances. Les services cloud fournissant la base de données placent un intermédiaire entre votre programme et la base de données qu’ils utilisent, ce qui ralentit la vitesse à laquelle vous pouvez accéder à la base de données. Cependant, avec Prisma, vous effectuez des appels directs à votre base de données à partir de votre programme, ce qui réduit le temps d’interrogation/modification de la base de données.

Écrire du SQL pur

Donc, si nous allons accéder directement à notre base de données PostgreSQL, pourquoi ne pas simplement utiliser le module node-postgres ou, pour de nombreuses autres bases de données, leurs pilotes équivalents ? Je dirais que l’expérience du développeur d’utiliser le client de Prisma vaut la charge légèrement accrue.

Là où Prisma brille, c’est avec ses frappes. Le module généré pour vous par Prisma est entièrement sécurisé – il interprète les types de votre schéma Prisma – ce qui vous aide à éviter les erreurs de type avec votre base de données. De plus, pour les projets utilisant TypeScript, Prisma génère automatiquement des définitions de type qui reflètent la structure de votre modèle. Prisma utilise ces types pour valider les requêtes de base de données au moment de la compilation afin de s’assurer qu’elles sont de type sécurisé.

Même si vous n’utilisez pas TypeScript, Prisma propose également la saisie semi-automatique / Intelli-sense, le linting et le formatage via son extension Visual Studio Code. Il existe également des plugins créés/maintenus par la communauté pour Emacs (emacs-prisma-mode), neovim (coc-prisma), Jetbrains IDE (Prisma Support) et nova (le plugin Prisma) qui implémentent Prisma Language Server pour réaliser la validation du code. La coloration syntaxique est également disponible pour un large éventail d’éditeurs via des plugins.

Autres ORM

Prisma n’est bien sûr pas le seul ORM disponible pour JavaScript / TypeScript. Par exemple, TypeORM est un autre ORM de haute qualité pour les projets JavaScript. Et dans ce cas, cela dépendra de vos préférences personnelles, et je vous encourage à essayer une gamme d’ORM pour trouver votre préféré. Personnellement, j’ai choisi Prisma pour mon projet pour trois raisons : la documentation complète (en particulier cette page CRUDqui est une bouée de sauvetage), les outils supplémentaires au sein de l’écosystème Prisma (par exemple Prisma Migrate et Prisma Studio) et la communauté active autour de l’outil (par exemple Prisma Day et Prisma Slack).

Utilisation de Prisma dans les projets Jamstack

Donc, si je cherche à utiliser Prisma dans un projet Jamstack, comment puis-je faire ?

Suivant.js

Next.js est en train de devenir un framework très populaire dans l’espace Jamstack, et Prisma lui convient parfaitement. Les exemples ci-dessous serviront d’exemples assez standard que vous pourrez transférer dans d’autres projets à l’aide de différents outils JavaScript / TypeScript Jamstack.

La règle principale d’utilisation de Prisma dans Next.js est qu’il doit être utilisé dans un environnement côté serveur, cela signifie qu’il peut être utilisé dans getStaticProps, getServerSidePropset dans les routes d’API (par exemple api/emojis.js).

Dans le code, cela ressemble à ceci (exemple tiré d’une application de démonstration J’ai fait une conférence au Prisma Day 2021 qui était un mur d’autocollants virtuel) :

import prisma from '../../../lib/prisma'
import { getSession } from 'next-auth/client'

function getRandomNum(min, max) {
  return Math.random() * (max - min) + min
}

export async function getRedemptions(username) {
  let allRedemptions = await prisma.user.findMany({
    where: {
      name: username,
    },
    select: {
      Redemptions: {
        select: {
          id: true,
          Stickers: {
            select: { nickname: true, imageurl: true, infourl: true },
          },
        },
        distinct: ['stickerId'],
      },
    },
  })
  allRedemptions = allRedemptions[0].Redemptions.map(x => ({
    number: getRandomNum(-30, 30),
    ...x.Stickers,
  }))
  return allRedemptions
}

export default async function RedeemCodeReq(req, res) {
  let data = await getRedemptions(req.query.username)
  res.send(data)
}

Comme vous pouvez le voir, il s’intègre très bien dans un projet Next.js. Mais vous remarquerez peut-être quelque chose d’intéressant : '../../../lib/prisma'. Auparavant, nous importions Prisma comme ceci :

import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

Malheureusement, cela est dû à une bizarrerie du système d’actualisation en direct de Next.js. Ainsi, Prisma vous recommande de coller cet extrait de code dans un fichier et importez le code dans chaque fichier.

Séquoia

Redwood est un peu une anomalie dans cette section, car ce n’est pas nécessairement un framework Jamstack. Cela a commencé sous la bannière d’apporter une pile complète au Jamstack, mais a évolué pour s’inspirer de Jamstack. J’ai choisi de l’inclure ici, cependant, car il adopte une approche intéressante consistant à inclure Prisma dans le cadre.

Cela commence, comme toujours, par la création d’un schéma Prisma, cette fois en api/db/schema.prisma (Redwood ajoute ceci à chaque nouveau projet). Cependant, pour interroger et modifier la base de données, vous n’utilisez pas le client par défaut de Prisma. Au lieu de cela, dans Redwood, les mutations et les requêtes GraphQL sont utilisées. Par exemple, dans l’exemple d’application de tâches de Redwood, il s’agit de la mutation GraphQL utilisée pour créer une nouvelle tâche :

const CREATE_TODO = gql`
  mutation AddTodo_CreateTodo($body: String!) {
    createTodo(body: $body) {
      id
      __typename
      body
      status
    }
  }
`

Et dans ce cas, le modèle Prisma pour une tâche est :

model Todo {
  id     Int    @id @default(autoincrement())
  body   String
  status String @default("off")
}

Pour déclencher la mutation GraphQL, nous utilisons le useMutation fonction basée sur le client GraphQL d’Apollo importé de @redwoodjs/web:

const [createTodo] = useMutation(CREATE_TODO, {
    //  Updates Apollo's cache, re-rendering affected components
    update: (cache, { data: { createTodo } }) => {
      const { todos } = cache.readQuery({ query: TODOS })
      cache.writeQuery({
        query: TODOS,
        data: { todos: todos.concat([createTodo]) },
      })
    },
  })

  const submitTodo = (body) => {
    createTodo({
      variables: { body },
      optimisticResponse: {
        __typename: 'Mutation',
        createTodo: { __typename: 'Todo', id: 0, body, status: 'loading' },
      },
    })
  }

Avec Redwood, vous n’avez pas à vous soucier de la configuration du schéma GraphQL / des SDL après avoir créé votre schéma Prisma, car vous pouvez utiliser celui de Redwood. scaffold commande pour convertir le schéma Prisma en SDL et services GraphQL — yarn rw g sdl Todopar exemple.

Travailleurs Cloudfare

Cloudfare Workers est une plate-forme populaire pour l’hébergement des API Jamstack, car elle place votre code à la « périphérie ». Cependant, la plate-forme a ses limites, notamment un manque de prise en charge TCP, que le client Prisma traditionnel utilise. Bien que maintenant, grâce à Prisma Data Proxy, c’est possible.

Pour l’utiliser, vous aurez besoin d’un Plate-forme cloud Prisma compte qui est actuellement gratuit. Une fois que vous avez suivi le processus d’installation (assurez-vous d’activer Prisma Data Proxy), vous recevrez une chaîne de connexion qui commence par prisma://. Vous pouvez utiliser cette chaîne de connexion Prisma dans votre .env fichier à la place de l’URL de la base de données traditionnelle :

DATABASE_URL="prisma://aws-us-east-1.prisma-data.com/?api_key=•••••••••••••••••"

Et puis, au lieu d’utiliser npx prisma generateutilisez cette commande pour générer un client Prisma :

PRISMA_CLIENT_ENGINE_TYPE=dataproxy npx prisma generate

Vos demandes de base de données seront transmises par procuration et vous pourrez utiliser Prisma Client comme d’habitude. Ce n’est pas une configuration parfaite, mais pour ceux qui recherchent des connexions de base de données sur Cloudfare Workers, c’est une solution relativement bonne.

Conclusion

Pour conclure, si vous cherchez un moyen de connecter les applications Jamstack à une base de données, je ne chercherais pas plus loin que Prisma. Son expérience de développeur, son outillage complet et ses performances en font le choix idéal. Next.js, Redwood et Cloudfare Workers – chacun d’eux a une façon unique d’utiliser Prisma, mais cela fonctionne toujours très bien dans chacun d’eux.

J’espère que vous avez aimé explorer Prisma avec moi. Merci!

Lectures complémentaires sur Smashing Magazine

(vf, yk, il)