Architecture JSONAPI

Architecture JSONAPI

  • Contexte
  • Choix
  • Mise en oeuvre

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

Q/A

Made with Slides.com