caencamp / api-caencamp Goto Github PK

Cards can be added to your board to track the progress of issues and pull requests. You can also add note cards, like this one!

Une fois la gestion des événements en place (api public et api d'administration), ce devrait être assez simple d'ajouter à ces deux apis une partie offre d'emploi.

Les offres d'emplois définies sur schema.org correspondent bien au besoin, et nous ne devrions pas avoir à gérer un modèle différent pour l'api public et l'api d'administration.

JobPosting - Schema.org Type

Une partie des objets "impliqués" dans une offre d'emploi sont déjà implémentés (Organizations, ...), et une première implémentation réalisée avec API Plateform : https://github.com/gaelreyrol/jobs-caen-camp

L'API publique des CaenCamp est ... publique (voir l'issue Reprendre le mapping des objets métier sur l'api publique · Issue #18) :)
Par contre on a/aura une API privée/métier (voir l'issue #20 ) qui permet l'édition des données, qu'il faut donc protéger avec un mécanisme d'authentification.

Il ne s'agit pas ici de mettre en place une gestion des membres des CaenCamp, mais juste de gérer quelques administrateurs et leur authentification afin de sécuriser l'édition des contenus du site.

API Platform prévoit plusieurs solution pour répondre à ce besoin :

• API Platform: SecurityAPI PlatformAPI Platform
• API Platform: JWT AuthenticationAPI PlatformAPI Platform

Ayant une API CRUD métier (voir les issues #19 et #20) permettant de gérer les contenus du site des CaenCamp, il ne nous manque plus qu'une interface d'administration.

C'est là qu'intervient React-admin \o/

Hello @CaenCamp/front-team ,
avant de commencer le vif du sujet, j'aimerais savoir si vous avez des préférences sur les différents type d'écriture proposés par VueJS, à savoir :

• Options API (VueJS 2 classique)
• Composition API (à venir sur VueJS 3)
• Class API (principalement dans l'écosystème typescript)

Je suis plutôt retissant sur l'utilisation de l'API Class, car elle est potentiellement vouée à disparaitre avec l'arrivée de VueJS 3 et donc potentiellement sur Nuxt3.

Le but est donc de trouver le bon compromis entre appétence des principaux intervenants côté front et la pérennisation du code.

ADR

Installation du projet sur mon laptop

En quoi est codé le projet, que dois-je installer comme dépendance ....

Nous avons une API publique (en lecture seule) intégralement mise en place avec API Platform. Cette API public s'alimente en données depuis des objets métiers n'ayant pas la même structure (voir l'issue Reprendre le mapping des objets métier sur l'api publique · Issue #18).

Il faut exposer une autre API reste CRUD d'administration au-dessus de ces objets métier afin de pouvoir gérer les contenus du site.
Cette API nécessitera une authentification. (voir l'issue #19 )

Je pense que l'on devrait pouvoir profiter d'API Platform pour cette mise en place.

ADR

Nous avons pris le partie faire une api la plus standard et ouverte que possible. C'est pour cela que nous avons choisi API Plateforme afin d'exposer facilement une API respectant la spécification Hydra

Hydra simplifies the development of interoperable, hypermedia-driven Web APIs

Nous avons donc aussi respecté un schéma de données suivant les modèles définis dans schema.org . Et cela marche plutôt bien du point de vue respect des standards.

Vous pouvez tester en choppant de la donnée en curl :

curl -X GET "https://api.caen.camp/api/events?page=1&itemsPerPage=30" -H  "accept: application/ld+json"

Et en la testant à cette adresse : https://search.google.com/test/rich-results

Sauf que le modèle des événements décrit sur schema.org ne correspond pas à notre modèle métier de gestion des CaenCamp !

Pas grave, ce problème est standard et d'ailleurs très vite abordé dans la documentation d'api plateforme : https://api-platform.com/docs/core/design/

Nous avons donc mis en place un modèle de données persisté en base correspondant à notre modèle métier que nous mappons ensuite sur le schéma des événements exposé par l'API.

Mais c'est là qu'est le problème ! Pour avancer et par méconnaissance, ce mapping a été implémenté assez salement via des Data Providers : https://github.com/CaenCamp/api-caencamp/blob/main/src/DataProvider/EventItemDataProvider.php

Si cela nous a permis d'exposer les données existantes, nous avons perdu au passage la capacité de paginer, de trier et de filtrer les listes de résultats retournées par l'API !

Il faut donc maintenant mettre en place un mécanisme propre nous permettant d'avoir pour les événements une liste :

• paginable
• triable par date
• filtrable par date, lieu, organisateur, speaker et titre

A priori, l'utilisation de Dtos semble une approche préconisée par API Platform.