Cómo manejar incógnitas y hacer suposiciones al diseñar una base de datos en la nube

Foto de Chance Anderson vía Unsplash

Escenario: ¿Shoebox o aplicación social?

Supongamos que es un desarrollador que quiere crear una aplicación para tomar notas. Veamos un detalle de la función con grandes implicaciones en su back-end. Para escribir una nota, su aplicación deberá poder guardar los datos.

Guardar un registro en una base de datos es sencillo. Las preguntas clave son:

  • ¿Quién necesitará acceder a ese registro?
  • ¿Será solo tu usuario o tu usuario lo compartirá con otros?
  • ¿Su producto será una aplicación de caja de zapatos o una aplicación social?

Si tiene la intención de que las notas sean privadas para el autor, puede concluir que está haciendo una aplicación de caja de zapatos. Esto significa que todos los datos van a una base de datos privada (base de datos).

Si tiene la intención de que su aplicación comparta notas con otros, puede concluir que debería ser una base de datos pública.

¿Pero sabrás cuál es antes de comenzar?

¿Y qué harás si necesitas cambiar tu producto a medida que avanzas? La base de datos pública y la base de datos privada no es lo primero que piensan la mayoría de los desarrolladores cuando crean una aplicación. Nos encontramos con esta pregunta cuando estábamos creando nuestro producto de fondo para nuestros desarrolladores, Skygear.

Debido a nuestra experiencia en la creación de aplicaciones para clientes, asumimos que había una elección correcta de la base de datos. Y que nuestro usuario sabría elegir.

¿Cómo se crea un back-end para desarrolladores que aún no están seguros de las necesidades de sus productos?
 ¿O para aquellos que desean mantener sus opciones abiertas en el futuro?

Como líder tecnológico en el proyecto, me gustaría compartir con ustedes nuestro proceso de toma de decisiones de hace 2 años. Espero que ayude a los futuros equipos de desarrollo a abordar incógnitas y suposiciones.

¿Por qué comenzamos a pensar en bases de datos privadas y públicas?

Muchas aplicaciones requieren un back-end para almacenar y consultar los datos del usuario. El back-end es mucho trabajo duro de construir y, seamos sinceros, no es tan agradable de crear. Skygear es nuestro back-end sin servidor de código abierto. Ayuda a abordar características de desarrollo comunes para aplicaciones móviles y web.

La característica de la que hablaré es nuestro Cloud DB, donde almacena y consulta datos de usuarios. Cuando comenzamos a diseñar Cloud DB, nos preguntamos cómo las diferentes aplicaciones almacenan y consultan los datos de los usuarios.

Buscamos inspiración en la cartera de aplicaciones móviles de nuestra empresa. Nuestra empresa hace de todo, desde aplicaciones de consumo hasta aplicaciones de comercio electrónico. Entonces los agrupamos en aplicaciones de "caja de zapatos" y "sociales".

Las aplicaciones de caja de zapatos almacenan datos personales que el usuario desea mantener en privado. Por ejemplo, nuestro proyecto paralelo Spentable ayuda al usuario a realizar un seguimiento de sus gastos diarios. Los datos almacenados en la aplicación están destinados a ser privados, en una caja de zapatos.

Pero, hay cosas que queremos compartir públicamente o con amigos. Eso también significa que el usuario debe tener el control de quién puede leer sus datos. Estos dos tipos de aplicaciones presentan un desafío en la forma en que diseñamos el Cloud DB de Skygear. Queríamos hacer que el almacenamiento de datos en Cloud DB sea lo más fácil posible. Para las aplicaciones de caja de zapatos, todo lo que necesitan los desarrolladores es una base de datos donde cada usuario solo pueda ver los datos que están ingresando. Sin embargo, en las aplicaciones sociales, los desarrolladores necesitan características como ACL (control de acceso). ¿Cómo podemos simplificar las cosas para los desarrolladores de ambos tipos de aplicaciones?

Tener nuestro pastel y comerlo también

Decidimos resolver este problema introduciendo el concepto de múltiples bases de datos en la base de datos en la nube: base de datos privada y base de datos pública. Cada usuario tiene una base de datos privada para colocar datos, y esos datos solo están disponibles para el mismo usuario. La aplicación también tiene una base de datos pública que se comparte entre todos los usuarios.

Un desarrollador de aplicaciones de caja de zapatos puede centrarse en guardar y recuperar los datos sin preocuparse por los permisos porque los datos en la base de datos privada siempre son privados.

Pero, la base de datos privada no funciona en absoluto para las aplicaciones sociales. Los desarrolladores de aplicaciones sociales deben poner los datos en la base de datos pública porque los datos en las aplicaciones sociales están destinados a ser compartidos.

Antes de agregar soporte para ACL, esta simple distinción para los datos públicos y privados nos sirvió (y a nuestros usuarios muy bien. Todo en DB privado es verdaderamente privado, mientras que todo es público DB es verdaderamente público.

"Todo es público" no es lo suficientemente bueno. La mayoría de las aplicaciones sociales tienen casos de uso en los que los datos solo se comparten entre un grupo de amigos.

ACL es otro tema difícil e interesante que debería ser su propio artículo.

No podríamos tener lo mejor de ambas bases de datos

Separar el DB en privado y público fue una buena idea. Pensamos que apoyaban el caso de uso para la mayoría de las aplicaciones.

Pero los primeros usuarios encontraron nuestras opciones públicas y privadas confusas.

Nuestros primeros usuarios nos dieron comentarios invaluables. También prestamos atención a las preguntas de soporte que recibimos. Esto es lo que aprendimos de los comentarios de los desarrolladores cuando utilizaron nuestro Cloud DB:

  1. Al principio no es obvio para los desarrolladores lo que están construyendo.
    Si bien puede ser obvio qué tipo de desarrollador de aplicaciones hizo al mirar el producto de manera retroactiva, no es obvio desde el principio. Obligar al desarrollador a decidir si está haciendo una caja de zapatos o una aplicación social al principio es difícil, si no imposible.
  2. Los desarrolladores solo quieren comenzar rápidamente
    Queremos que los desarrolladores aprendan los conceptos básicos lo más rápido posible. Tener que aprender un concepto más para elegir qué base de datos usar antes de que realmente puedan guardar y recuperar datos es demasiado para pedir nuevos usuarios.
  3. La decisión de DB pública o privada, una vez tomada, no es fácil de revertir
    Supongamos que un desarrollador comenzó con una idea de una aplicación de caja de zapatos y lo puso todo en la base de datos privada. Más tarde pueden darse cuenta de que deberían hacer que la aplicación sea social. No es fácil migrar datos una vez que se colocan en una base de datos particular.
  4. Los permisos son generalmente un pensamiento posterior
    La seguridad de los datos es una prioridad en nuestra empresa. Pero la seguridad de los datos no es lo primero que le viene a la mente a un desarrollador. Especialmente cuando solo están haciendo un prototipo de prueba de concepto. Quieren centrarse primero en la funcionalidad y cuidar de la seguridad más adelante.

Nuestras comida para llevar

Siempre estamos pensando en cómo podríamos mejorar nuestros productos. Podríamos mejorar en términos de arquitectura de software, documentación del usuario y facilidad de uso. A veces hacemos una lluvia de ideas sobre lo que haríamos si pudiéramos rebobinar el reloj dos años para comenzar de nuevo. Pero esto es lo que le diríamos a nosotros mismos:

  1. Si los desarrolladores ya están familiarizados con un concepto existente, adoptelo
    La mayoría de los desarrolladores están familiarizados con el concepto de una base de datos. Es un contenedor de algún tipo donde los desarrolladores pueden guardar contenido. También pueden recuperar datos y admitir la propiedad CRUD (Crear, Leer, Actualizar y Eliminar).
    Debido a que los desarrolladores ya están familiarizados con el concepto de una base de datos, encontrarían una única base de datos en Cloud DB fácil de usar.
  2. Introducir nuevos conceptos cuando los desarrolladores estén preparados para ellos.
    Esta idea es en realidad otra forma de decir que debemos hacer que la curva de aprendizaje sea lo más fácil posible. Skygear era un prototipo a su manera. ¡Acabamos de lanzar V1.0 !.
    Nunca querrás hacer que la vida de tus primeros usuarios sea difícil. Tener que aprender todo antes de que los desarrolladores puedan hacer algo no funciona bien desde la perspectiva del producto. Hasta que los desarrolladores deban pensar en el permiso de datos, no deberían saber la diferencia entre una base de datos privada y una base de datos pública. Deberíamos permitir que nuestros usuarios comiencen con los conceptos comunes primero para familiarizarse con una nueva plataforma.
    Solo después de que se sientan cómodos debemos introducir nuevos conceptos para proporcionar más opciones. En este caso, no hay ningún daño para un desarrollador en descubrir que necesita ACL, por lo que el nuevo concepto es el siguiente paso natural después de haber aprendido a usar Cloud DB.

Lo que aprendimos

Cuando comenzamos a trabajar en Skygear hace dos años, queríamos construir un producto increíble con 2–4 de nuestros desarrolladores senior. Teníamos probadores listos de nuestros propios desarrolladores internos, que dieron muchos comentarios críticos. Pensamos que estábamos usando nuestra experiencia en el desarrollo de aplicaciones web y móviles para tomar mejores decisiones sobre cómo diseñar herramientas para otros desarrolladores.

Pero nuestra experiencia también creó suposiciones sobre qué esperar que nuestros usuarios sepan antes de usar nuestro producto.

Lo bueno de recibir comentarios de los usuarios sobre Cloud DB a medida que avanzábamos fue que aprendimos que nuestras suposiciones eran incorrectas. Nuestra lección más valiosa fue el humilde recordatorio de un principio básico de inicio. No importa nuestra experiencia, a menudo no sabemos exactamente qué estamos construyendo.

Por supuesto, eso no nos impide tratar de construir la piedra filosofal para facilitarles la vida a nuestros compañeros desarrolladores. Como dijo mi cofundador, Ben, uno de sus días más productivos fue cuando arrojó 1000 líneas de código.

Me gustaría dar crédito a mi colega cheungpat que trabajó en Cloud DB conmigo y ayudó a escribir este artículo.

A mi equipo le encantaría escuchar sus comentarios críticos sobre Skygear. Consulte también nuestra documentación y los repositorios de GitHub para ver cómo discutimos las características de Skygear.