Généraliser le concept de Workspace

[thom4parisot]

Aujourd'hui on sélectionne les articles différemment selon qu'on soit dans un workspace ou non. C'est le cas à la fois pour le code côté front, et côté API.

Je propose qu'on soit toujours dans un workspace, et que ça soit transparent à la requête.

Une requête classique d'article ressemble à :

query getUserArticles ($user: ID) {
  user (user: $user) {
    articles {
      title
      workingVersion {
        md
      }
    }
  }
}

variables {
  "user": "1234"
}

Si on explicite le workspace par défaut :

query getUserArticles ($user: ID, $workspaceId: ID) {
  user (user: $user) {
    articles {
      title
      workingVersion {
        md
      }
    }
  }
}

variables {
  "user": "1234",
  "workspaceId": "default"
}

Si on explicite un identifiant de workspace :

query getUserArticles ($user: ID, $workspaceId: ID) {
  user (user: $user) {
    articles {
      title
      workingVersion {
        md
      }
    }
  }
}

variables {
  "user": "1234",
  "workspaceId": "5678"
}

Avantage : on peut mémoriser l'identifiant de workspace dans la session utilisateur (et revenir dessus par défaut quand on revient sur Stylo par exemple), factoriser tout le code en doublon, gérer moins de maintenance.

Qu'est-ce que vous en pensez ?

[RochDLY]

Au delà de la factorisation du code, ta proposition me semble cohérente sur le plan de la structuration de Stylo (en tant qu'espace) : avec ta proposition, que l'on soit dans un espace de travail partagé ou non, on identifie Stylo en tant qu'«espace de travail» alors qu'actuellement, l'espace personnel n'est pas explicitement formulé comme tel

[ggrossetie]

Les articles dans un espace de travail ne sont pas les articles de l'utilisateur. De mon point de vue, je ne sais pas si cela est correct de lister les articles d'un espace de travail avec le graphe user > articles. Si on veut un graphe commun peut être qu'il faut que article soit à la racine avec un filtre sur user et/ou workspace ?

[RochDLY]

Je ne comprends pas si vous parlez de la même chose ?
De ce que j'en comprends, la proposition de @thom4parisot est d'ajouter la notion de workspace à la structure de l'espace personnel pour avoir une structure similaire à celle du workspace justement.

Est-ce que quelque chose du type fonctionnerait aussi : 

Avec pour les articles personnels : 

query getUserArticles ($user: ID) {
  articles (workspaceId : ID) {
    title
    workingVersion {
      md
    }
  }
}

Et côté espace de travail : 

query getWorkspaceArticles ($user: ID, $workspaceId: ID){
    articles (owner: $user, workspaceId: $workspaceId) {
      title
      workingVersion {
        md
      }
    }
}

variables {
  "user": "1234",
  "workspaceId": "5678"
}

[ggrossetie]

Cette structure me convient mieux et ça rejoint le fait de dire que l'article est l'unité de travail dans Stylo (donc au premier niveau). Je ne sais pas la bonne pratique concernant le singulier/pluriel dans une API GraphQL mais ça me semble une bonne idée d'avoir la même structure 👍

[thom4parisot]

Les articles dans un espace de travail ne sont pas les articles de l'utilisateur.

Ah oui c'est vrai 😞

Dans ce cas je trouverais ça plus logique :

query getArticles ($user: ID, $workspaceId: ID) {
  articles (user: $user, workspace: $workspaceId) {
    title
    workingVersion {
      md
    }
  }
}

variables {
  "user": "1234"
}

Ou par workspace :

query getArticles ($user: ID, $workspaceId: ID) {
  articles (user: $user, workspace: $workspaceId) {
    title
    workingVersion {
      md
    }
  }
}

variables {
  "workspaceId": "5678"
}

En fait c'est que comme les interfaces sont vraiment identiques, je trouve ça dommage d'avoir en doublon du code côté API et front.

Ou alors on assigne un workspace par utilisateur (pas supprimable car "personnel" ; mais ça me semble plus "lourd" en terme de conception).

[ggrossetie]

Ou alors on assigne un workspace par utilisateur (pas supprimable car "personnel" ; mais ça me semble plus "lourd" en terme de conception).

On y avait pensé mais au final on avait pas retenu cette solution. De mémoire, parce que d'une part le concept d'espace de travail était nouveau donc potentiellement perturbant si on utilise pas ce concept d'avoir son espace personnel qui devient un espace de travail. Et part, ça fait des objets en plus dans la base de données et potentiellement des conditions en plus (je veux lister les espaces de travail mais pas les espaces personnels, etc...)

En fait c'est que comme les interfaces sont vraiment identiques, je trouve ça dommage d'avoir en doublon du code côté API et front.

Oui, je pense que c'est une très bonne idée d'uniformiser ça 👍🏻

[RochDLY]

Dans ce cas je trouverais ça plus logique :

query getArticles ($user: ID, $workspaceId: ID) {
  articles (user: $user, workspace: $workspaceId) {
    title
    workingVersion {
      md
    }
  }
}

variables {
  "user": "1234"
}

Ou par workspace :

query getArticles ($user: ID, $workspaceId: ID) {
  articles (user: $user, workspace: $workspaceId) {
    title
    workingVersion {
      md
    }
  }
}

variables {
  "workspaceId": "5678"
}

Si je comprends bien, les filtres sont optionnels dans cette requête et selon le filtre (workspaceId ou user) on fait la requête pour récupérer les articles d'un utilisateur (ce qui correspondrait à "l'espace personnel") si on renseigne seulement user ou les articles associés à un espace de travail si on renseigne user et workspaceId (pour récupérer un workspace auquel un user a accès) ?

Ou alors on assigne un workspace par utilisateur (pas supprimable car "personnel" ; mais ça me semble plus "lourd" en terme de conception).

Effectivement, je rejoins @ggrossetie sur ce point (heureusement que tu as une meilleure mémoire que la mienne !)

[thom4parisot]

Je fais des allers-retours sur comment penser l'aspect domaine des requêtes.

Je persiste à penser qu'on va requêter des choses par rapport à un workspace (implicite de l'utilisateur, ou avec un identifiant donné). Et que c'est seulement par rapport à ce workspace qu'on va en chercher un/des/les articles ou un/des/les corpus.

L'utilisateur est un concept annexe, et découle du jeton passé à l'API.

Du coup en réfléchissant, je me dis plusieurs trucs :

• le concept paramètre user n'a pas de sens
• le workspace devrait optionnellement encapsuler les article / articles / corpus

query getArticles () {
	  articles {
		article {
			title
		    workingVersion {
		      md
		    }
		}
	  }
}


variables {
}

Équivalent à :

query getArticles ($workspace: ID) {
	workspace (id: $workspace) {
	  articles {
		article {
			title
		    workingVersion {
		      md
		    }
		}
	  }
	}
}

variables {
  "workspace": null
}

Et s'il y avait une prochaine étape suite à ça :

query getArticles ($workspace: ID, $articleFilters: ArticleFilters, $articleSort: ArticleStort) {
	workspace (id: $workspace) {
	  articles (filters: $articleFilters, sort: $articleSort) {
		article {
			title
		    workingVersion {
		      md
		    }
		}
	  }
	}
}

variables {
  "workspace": null,
  "articleSort": {
    …
  },
  "articleFilters": {
    "users": [ … ],
    "tags": [ … ]
  }
}

[RochDLY]

Avec ton commentaire suivant, ça fait sens que le paramètre user soit considéré comme une redondance. La question que je me pose si on le rend implicite et discret (par la présence du jeton) on ne risque pas de l'invisibiliser complètement ?

Je me pose également une question similaire pour l'espace de travail personnel (implicite, de l'utilisateur) et l'espace de travail. Jusqu'à maintenant on a voulu distinguer les deux aspects notamment parce que l'espace de travail n'est pas "propriétaire" des articles, c'est l'utiliateur qui l'est.
Pour préserver cette distinction et ce comportement, est-ce qu'on aurait pas tout intérêt à signaler cette distinction dans la formulation de la requete ?

Par exemple : si un espace de travail partagé est signalé par un id et que l'on part du principe que sans id il s'agit de l'espace personnel (en se reposant à nouveau sur le jeton de l'utilisateur pour l'identifier ou un autre id), est-ce qu'on ne peut pas passer l'information "personnel" comme paramètre de la requête ?

Autre façon de le formuler de façon encore plus explicite, on pourrait passer un paramètre type à l'espace de travail, ce paramètre pourrait prendre deux valeurs 1) commun ou partagé et 2) personnel.

Qu'en dites-vous ? Est-ce que ce serait fonctionnel ?

[ggrossetie]

L'utilisateur est un concept annexe, et découle du jeton passé à l'API.

C'est vrai mais pas dans le cas où on utilise un jeton admin, on a besoin de préciser l'utilisateur pour lequel on veut récupérer les articles.

[RochDLY]

Qu'est-ce qu'un tel changement pourrait avoir comme effet de bord ? Si on change la racine du graphe ('articles' à la place de 'user') est-ce qu'il y aurait des comportements non souhaités en cascade ?

[thom4parisot]

On peut déjà requêter directement les articles sans encapsuler dans un user {} ; ça utilise les permissions liées au user du jeton.