Contexte

Pass Mobilité

• Parcours passager via API
  • API stable
  • Documentation
• Délégation d'identitée
• Actions de code différentes du parcours Ecov
  • Paiement
  • Notifications
• Points d'attention
  • Performances
  • Authorisations
  • Réutilisation

Besoins

Pass Mobilité

• Identification
• Authorisations
  • Limiter les actions possibles
  • Limiter le scope DB visible
• Versionning
• Format API "standard"
• Pagination
• Documentation agréable et maintenue

Fonctionnalités API requises

On aurait pu s'arrêter là ...

Mais ...

• Maintenance de deux API
• Pas de réutilisabilité

Donc ...

• En profiter pour régler/anticiper d'autres problèmes
  • Refacto dette technique
  • Réutilisabilité
    • Authorisations
    • Sécurité
    • Performance
  • Équipe Data
  • Refonte BO
  • Problématiques API GraphQL actuelle
  • API parcours SMS

Une seule API pour les gouverner toutes

Refacto dette technique

• Structurer l'architecture afin de permettre :
  • Extraction des validations depuis les modèles
  • Unification des "lib" + "services" + "helpers"
• Première utilisation de cette architecture avec l'API PM
• Pas de refacto de l'existant aujourd'hui

Réutilisabilité

• Structurer l'API afin de permettre
  • Authorisation modulaires (AM + code)
  • Sécurité globale (APIM)
  • Performance pour toutes les requêtes possibles
    • Pagination automatique
    • Prévention des requêtes n+1

Équipe Data

• Cohérence historique des données
  • Ex : migration Lane
  • Les changement de code impactent les KPI
• Partage des règles métiers
  • enums
  • visible?
• Pouvoir mettre à jour les données
  • Interdit aujourd'hui
• Indépendance du modèle de stockage
  • Redis
  • Hstore
  • Versions (paper_trail)

Besoins

Équipe Data

• Visibilité totale sur les datas
  • Soft-delete
  • Versions
  • Redis
• Filtres très permissifs
• Possibilité de création/édition

Fonctionnalités API requises

BO

• Extraire la partie Front du BO

Besoins

BO

• Visibilité totale sur les datas
  • Soft-delete
  • Versions
  • Redis
• Filtres très permissifs
• Accès aux objets associés
• Possibilité très permissive de création/édition

Fonctionnalités API requises

GraphQL Actuel

• Améliorer certains points techniques
  • Sécurité
  • Gestion des erreurs
  • Performance (n+1 en particulier)
• Améliorer certains points de gouvernance
  • Dépendance Front & Back
• Conserver certains mécanismes appréciés
  • Visibilité sur les associations
  • Sélection des champs de retours
  • Scope de la DB par marque blanche
  • Documentation auto générée
  • Les objets sont typés
  • Filtres personnalisés

Besoins

GraphQL Actuel

• Identification
• Authorisations
  • Limiter les actions possibles
  • Limiter le scope DB visible
• Pagination
• Filtres restreints
• Filtres personnalisés
• Accès aux objets associés
• Sélection des champs de retour
• Objets typés
• Documentation agréable et maintenue

Fonctionnalités API requises

API Parcours SMS

• Identification
• Authorisations
  • Limiter les actions possibles
  • Limiter le scope DB visible

Fonctionnalités API requises

Choix

JSONAPI.ORG

• Spécification standard d'API
• Nombreux wrappers dans différents languages
• Plusieurs fonctionnalités dont on a besoin font partie de la spec jsonapi.org : 
  • Pagination
  • Inclusion des association
  • Filtres
  • Sélection des champs de retour

Nouvelle architecture : jsonai.rb

• Ajout dans le code backend
  • Serializers
    • permet d'appliquer un filtre d'autorisation sur les types renvoyés

Nouvelle architecture : Rectify

• Ajout dans le code backend
  • CommandObjects
    • permet un chemin de code différent
    • permet d'unifier les "lib/services/helpers"
  • FormObjects
    • permet un chemin de code différent
    • permet d'extraire les validations du modèle
    • permet d'appliquer un filtre d'autorisation sur les actions "create" et "update"
  • QueryObjects
    • permet des filtres personnalisés, et complexes
    • permet d'exposer les scopes via API

Nouvelle architecture : Pundit

• Ajout dans le code backend
  • Policies
    • permet d'appliquer un filtre d'autorisation sur les endpoint accessibles
    • permet d'appliquer un filtre d'autorisation sur le scope DB visible
    • permet d'appliquer un filtre d'autorisation sur les filtres API disponibles

Nouvelle architecture : act_as_jsonapi

• On crée un module "act_as_jsonapi"
  • le code est complexe
    • il gère tous les mécanismes "standards" d'un endpoint (pagination, authorisations, filtres, etc)
  • le code ne doit pas être modifié ou maintenu
    • il définit le fonctionnement standard
    • si le fonctionnement standard change, on créera un nouveau module
• Les fichiers qu'on devra maintenir sont simples
  • forms, policies, serializers, ...

Nouvelle architecture : AM

• Gestionnaire d'authentification
  • Sécurisation des tokens
  • Délégation d'identitée

Nouvelle architecture : APIM

• Gestionnaire d'api
  • Sécurisation des accès aux apis
  • Monitoring d'activité
  • Accès à la documentation

Architecture Code

Index

Controller

HTTP GET

1

Index

Controller

HTTP GET

Policy

• Action authorized?
• Filters authorized ?

1

2

Index

Controller

HTTP GET

Policy

• Action authorized?
• Filters authorized ?

QueryObject

• Apply Custom Filters

1

2

3

Index

Controller

HTTP GET

Policy

• Action authorized?
• Filters authorized ?

QueryObject

• Apply Custom Filters

1

2

3

• Apply DB scoping

4

PolicyScope

Index

Controller

HTTP GET

Policy

Serializer

• Action authorized?
• Filters authorized ?

• Apply Simple Filters
• Apply Pagination
• Apply Sorting
• Apply Inclusions
• Apply return attributes selection

QueryObject

• Apply Custom Filters

1

2

3

5

• Apply DB scoping

4

PolicyScope

• Whitelist visible attributtes
• Whitelist visible relations

Create

Controller

HTTP POST

1

Create

Controller

HTTP POST

Policy

• Action authorized?
• Wich Command to use ?

1

2

Create

Controller

HTTP POST

Policy

• Action authorized?
• Wich Command to use ?

CommandObject

• Run "create" specific code

1

2

3

Create

Controller

HTTP POST

Policy

• Action authorized?
• Wich Command to use ?

• Run specific validations
• Whitelist allowed fields

CommandObject

• Run "create" specific code

1

2

3

4

FormObject

Create

Controller

HTTP POST

Policy

Serializer

• Action authorized?
• Wich Command to use ?

• Run specific validations
• Whitelist allowed fields

CommandObject

• Run "create" specific code

1

2

3

4

• Serialize object

5

FormObject

Point Maintenabilité

• Les blocs bleus
  • C'est le code "produit"
  • qu'on voudra maintenir
• Les liens qui organisent le flow d'un objet à l'autre
  • C'est le module "act_as_jsonapi"
  • qu'on voudra ne jamais toucher
  • Il est possible de bypass totalement ce module