Comment gérer les inconnus et formuler des hypothèses lors de la conception d'une base de données cloud

Photo de Chance Anderson via Unsplash

Scénario: Shoebox ou application sociale?

Dites que vous êtes un développeur qui souhaite créer une application de prise de notes. Examinons un détail de fonctionnalité avec des implications énormes sur votre back-end. Pour écrire une note, votre application devra pouvoir sauvegarder les données.

L'enregistrement d'un enregistrement dans une base de données est simple. Les questions clés sont:

  • Qui aura besoin d'accéder à cet enregistrement?
  • S'agira-t-il uniquement de votre utilisateur, ou votre utilisateur le partagera-t-il avec d'autres?
  • Votre produit sera-t-il une application de type boîte à chaussures ou une application sociale?

Si vous souhaitez que les notes soient confidentielles pour l'auteur, vous pouvez en conclure que vous créez une application de type boîte à chaussures. Cela signifie que toutes les données vont dans une base de données privée.

Si vous souhaitez que votre application partage des notes avec d'autres personnes, vous pouvez en conclure qu'il devrait s'agir d'une base de données publique.

Mais saurez-vous qui c'est avant de commencer?

Et que ferez-vous si vous devez modifier votre produit au fur et à mesure? Les bases de données publiques et privées ne sont pas la première chose à laquelle la plupart des développeurs pensent avant de créer une application. Nous avons rencontré ces questions lors de la construction de notre produit principal pour nos développeurs, Skygear.

En raison de notre expérience dans la création d'applications pour les clients, nous avons supposé que le choix de la base de données était judicieux. Et que notre utilisateur sache choisir.

Comment construisez-vous un back-end pour les développeurs qui ne sont pas encore sûrs de leurs besoins en produits?
 Ou pour ceux qui veulent garder leurs options ouvertes à l'avenir?

En tant que responsable technique du projet, je voudrais partager avec vous notre processus de prise de décision d’il ya 2 ans. J'espère que cela aidera les équipes de développement futures à aborder les inconnues et les hypothèses.

Pourquoi avons-nous commencé à penser aux DB privées par rapport aux DB publiques?

De nombreuses applications nécessitent un back-end pour stocker et interroger les données utilisateur. Le back-end demande beaucoup de travail et, avouons-le, n’est pas si agréable à créer. Skygear est notre back-end sans serveur open-source. Il aide à aborder les fonctionnalités de développement communes pour les applications mobiles et Web.

La fonctionnalité dont je vais parler est notre base de données Cloud, dans laquelle vous stockez et interrogez les données des utilisateurs. Lorsque nous avons commencé à concevoir Cloud DB, nous nous sommes demandé comment différentes applications stockent et interrogent les données des utilisateurs.

Nous nous sommes inspirés du portefeuille d’applications mobiles de notre société. Notre société fait tout, des applications grand public aux applications de commerce électronique. Nous les avons donc regroupés dans des applications «boîte à chaussures» et «sociales».

Les applications Shoe-Box stockent des données personnelles que l'utilisateur souhaite garder confidentielles. Par exemple, notre projet parallèle Spentable aide un utilisateur à suivre ses dépenses quotidiennes. Les données stockées dans l'application sont destinées à être privées, dans une boîte à chaussures.

Mais, il y a des choses que nous voulons partager publiquement ou avec des amis. Cela signifie également que l'utilisateur doit pouvoir contrôler qui peut lire ses données. Ces deux types d’applications représentent un défi dans la conception de la base de données Cloud de Skygear. Nous voulions rendre le stockage de données dans Cloud DB aussi simple que possible. Pour les applications de type boîte à chaussures, les développeurs ont besoin d’une base de données où chaque utilisateur ne peut voir que les données qu’il est en train d’entrer. Pourtant, dans les applications sociales, les développeurs ont besoin de fonctionnalités telles que ACL (contrôle d’accès). Comment pouvons-nous simplifier les choses pour les développeurs des deux types d'applications?

Avoir notre gâteau et le manger aussi

Nous avons décidé de résoudre ce problème en introduisant le concept de plusieurs bases de données dans la base de données Cloud: base de données privée et base de données publique. Chaque utilisateur dispose d'une base de données privée pour y insérer des données, qui ne sont disponibles que pour le même utilisateur. L'application dispose également d'une base de données publique partagée par tous les utilisateurs.

Un développeur d'applications de type boîte à chaussures peut se concentrer sur la sauvegarde et l'extraction des données sans se soucier des autorisations, car les données de la base de données privée sont toujours privées.

Mais la base de données privée ne fonctionne pas du tout pour les applications sociales. Les développeurs d’applications sociales doivent placer les données dans la base de données publique, car elles doivent être partagées.

Avant d’ajouter la prise en charge d’ACL, cette distinction simple entre données publiques et privées nous servait (et très bien à nos utilisateurs). Tout ce qui se trouve dans la base de données privée est réellement privé, alors que tout est public. La base de données est vraiment publique.

«Tout est public» n'est pas suffisant. La plupart des applications sociales ont des cas d'utilisation où les données ne sont partagées que par un groupe d'amis.

ACL est un autre sujet difficile et intéressant qui devrait être son propre article.

Nous ne pourrions pas avoir le meilleur des deux bases de données

Séparer la DB des comptes privés et publics était une bonne idée. Nous pensions qu'ils prenaient en charge le cas d'utilisation de la majorité des applications.

Mais les premiers utilisateurs ont trouvé confuses nos options privées et publiques.

Nos premiers utilisateurs nous ont donné des commentaires précieux. Nous avons également prêté attention aux questions d'assistance que nous avons reçues. Voici ce que nous avons appris des développeurs en utilisant notre base de données Cloud:

  1. Il n’est pas évident pour les développeurs de savoir ce qu’ils construisent au début.
    Bien que le type de développeur d’application créé en regardant le produit rétroactivement soit évident, cela n’est pas évident dès le départ. Il est difficile, voire impossible, de forcer le développeur à décider s’il créera au départ une boîte à chaussures ou une application sociale.
  2. Les développeurs veulent juste démarrer rapidement
    Nous voulons que les développeurs apprennent les bases le plus rapidement possible. Avoir à apprendre un concept de plus pour choisir la base de données à utiliser avant de pouvoir réellement enregistrer et récupérer des données est trop demander à de nouveaux utilisateurs.
  3. La décision pour une base de données publique ou privée, une fois prise, n’est pas facile à inverser
    Supposons qu'un développeur a commencé avec une idée d'application de boîte à chaussures et qu'il a tout mis dans la base de données privée. Plus tard, ils se rendront peut-être compte qu'ils devraient plutôt faire de l'application une application sociale. Il n'est pas facile de migrer les données une fois qu'elles sont placées dans une base de données particulière.
  4. Les autorisations sont généralement une pensée après
    La sécurité des données est une priorité dans notre entreprise. Mais la sécurité des données n'est pas la première chose qui préoccupe le développeur. Surtout quand ils font juste un prototype de preuve de concept. Ils veulent d’abord se concentrer sur les fonctionnalités, puis sur la sécurité.

Nos plats à emporter

Nous réfléchissons toujours à la manière dont nous pourrions améliorer nos produits. Nous pourrions faire mieux en termes d'architecture logicielle, de documentation utilisateur et de facilité d'utilisation. Nous pensons parfois à ce que nous ferions si nous pouvions remonter l’horloge deux ans pour recommencer. Mais voici ce que nous dirions à nous-mêmes:

  1. Si les développeurs connaissent déjà un concept existant, adoptez-le.
    La plupart des développeurs connaissent bien le concept de base de données. Il s’agit d’un conteneur dans lequel les développeurs peuvent enregistrer du contenu. Ils peuvent également récupérer des données et prendre en charge la propriété CRUD (Créer, Lire, Mettre à jour et Supprimer).
    Les développeurs étant déjà familiarisés avec le concept de base de données, ils trouveraient facilement une base de données unique sur Cloud DB à utiliser.
  2. Introduire de nouveaux concepts lorsque les développeurs sont préparés pour eux
    Cette idée est en réalité une autre façon de dire que nous devrions simplifier au maximum la courbe d’apprentissage. Skygear était un prototype à sa manière. Nous venons de lancer la V1.0 !.
    Vous ne voulez jamais rendre la vie difficile à vos premiers utilisateurs. Devoir tout apprendre avant que les développeurs puissent faire quoi que ce soit ne fonctionne pas bien du point de vue du produit. Tant que les développeurs n'ont pas besoin de réfléchir à l'autorisation des données, ils n'ont pas besoin de connaître la différence entre une base de données privée et une base de données publique. Nous devrions laisser nos utilisateurs se familiariser avec les concepts communs avant de se familiariser avec une nouvelle plate-forme.
    C’est seulement après qu’ils se sentent à l'aise que nous devrions introduire de nouveaux concepts pour offrir plus d'options. Dans ce cas, le développeur n’a pas de mal à découvrir qu’il a besoin de la liste de contrôle d’accès. Le nouveau concept est donc une étape naturelle après avoir appris à utiliser Cloud DB.

Ce que nous avons appris

Lorsque nous avons commencé à travailler sur Skygear, il y a deux ans, nous voulions créer un produit exceptionnel avec 2 à 4 de nos développeurs expérimentés. Nous avions des testeurs prêts de nos propres développeurs internes, qui ont donné beaucoup de commentaires critiques. Nous pensions utiliser notre expérience de développement d'applications Web et mobiles pour prendre de meilleures décisions concernant la conception d'outils pour d'autres développeurs.

Mais notre expérience a également permis de créer des hypothèses sur ce que nos utilisateurs devraient savoir avant d’utiliser notre produit.

La bonne chose à propos de l’obtention des commentaires des utilisateurs sur Cloud DB au fur et à mesure est que nous avons compris que nos hypothèses étaient incorrectes. Notre leçon la plus précieuse a été le rappel humiliant d'un principe de base de démarrage. Quelle que soit notre expérience, nous ne savons souvent pas exactement ce que nous construisons.

Bien sûr, cela ne nous empêche pas d’essayer de construire cette pierre de philosophe pour faciliter la vie de nos collègues développeurs de toute façon. Comme mon co-fondateur, Ben, a déclaré que l'un de ses jours les plus productifs a été celui où il a jeté 1000 lignes de code.

Je voudrais remercier mon collègue cheungpat qui a travaillé sur la base de données Cloud avec moi et qui a contribué à la rédaction de cet article.

Mon équipe aimerait entendre vos commentaires critiques sur Skygear. Consultez également notre documentation et les référentiels GitHub pour savoir comment nous discutons des fonctionnalités de Skygear.