Una de las ventajas del código abierto es la capacidad de estar cerca de los usuarios. Esto ha sido muy útil en el desarrollo de Couchbase a lo largo de los años. Por supuesto, como cualquier proyecto y comunidad de rápido crecimiento, de vez en cuando necesitas revisar y reajustar la infraestructura central para ayudarte a ir más rápido.
Esa es nuestra intención con SDK-RFCs y hoy nos gustaría solicitar su opinión.
TL;DR: Díganos qué le parecen los planes para la nueva API de subdocumentos y el nuevo Gestión de índices interfaz.
Más sobre el Desafío
Cuando se lanzó Couchbase Server 3.0, también lanzamos un grupo de nuevos SDKs que nos preparaban para futuros lanzamientos. Cada uno de ellos rompió intencionadamente la API. Enviamos previsualizaciones de que todo es Open Source bajo una licencia Apache 2.0, pero nunca supimos realmente hasta que una versión "punto O" fue enviada y recomendada si el cambio sería aceptable. Mirando atrás, ha funcionado muy bien ya que casi todo el mundo que escribe código para Couchbase ha hecho el cambio.
Uno de nuestros objetivos en este cambio era hacer que la API fuera más común, sin dejar de permitir modismos en las plataformas individuales que los desarrolladores han elegido. El primer paso consistió en determinar, en colaboración, cuál creíamos que era el nivel adecuado de detalle en la API y, a continuación, recabar la opinión de los demás.
En efecto, elaborábamos los renders del artista con borradores de planos.
En general, esto funcionó bien. Muchos de los artefactos nos ayudaron a alcanzar el nivel de detalle y homogeneidad que deseábamos. Aun así, pensamos que podíamos mejorar si nos asegurábamos de que las interfaces que se definían para los coproyectos eran realmente aceptables para esos coproyectos. Parece obvio, pero había algunas áreas problemáticas. También pensamos que debíamos dejar más espacio para que todo el mundo pudiera hacer comentarios. Mientras que la mayoría de las personas que desarrollan en Couchbase no tendrán tiempo para entrar en conversaciones de diseño, ser Open pondrá más ojos innovadores en nuestros pensamientos y la discusión y tanto las discusiones como los artefactos pueden dar a otros una visión del pensamiento y las decisiones de diseño durante muchos años por venir.
Infraestructuras
Nuestro objetivo era que cualquiera pudiera participar en el debate, que los artefactos estuvieran a disposición del público y fueran accesibles, y que el proceso siguiera unos patrones con los que los desarrolladores estuvieran familiarizados.
Hay un poco de solapamiento aquí con RFC del IETFpero con un toque moderno. El giro moderno consiste en que, en lugar de que las listas de correo sean el campo de juego social para el discurso, las conversaciones de los desarrolladores -especialmente las abiertas- tienen lugar ahora en Github.
Hemos creado un nuevo repositorio bajo la organización couchbaselabs llamado SDK-RFCs. La primera SDK-RFC es el proceso SDK-RFC porque somos así de meta. En efecto, abrimos un problema para hacer un seguimiento de la necesidad y, a continuación, elaborar una solicitud de extracción para documentar el planteamiento. Todo el tiempo mantenemos un LÉAME que enumera todo lo que está en desarrollo y completo.
Como se menciona en el LÉEME, sabemos que no estamos solos en esto. Existen, por supuesto, los conocidos RFC del IETF, RFC de óxido y mi antiguo colega de Sun Bryan Cantrill y la gente de Joyent tenían una necesidad similar y están haciendo un gran trabajo inspirando el debate en RFD de Joyent.
Tu turno
Dos SDK-RFC en particular están bastante avanzadas y listas para recibir aportaciones. Nos encantaría conocer su opinión.
La primera es sobre Subdocumento operaciones. Hay veces que los desarrolladores de aplicaciones quieren modificar una parte de un documento sin recuperarlo y almacenarlo. Para ello se están desarrollando un conjunto de extensiones de protocolo y una API para el nivel más bajo de operaciones y otras APIs y componentes de Couchbase podrán aprovechar estas primitivas a su manera en el futuro. Este SDK-RFC cubre un conjunto común de API que pondremos en los SDKs. Formará parte directamente de la interfaz pública si se desea la alta eficiencia que esta interfaz permite. Las nuevas capacidades del sistema también servirán para acelerar otras partes de Couchbase como N1QL con el tiempo.
La segunda es sobre Gestión de índices. Cuando se construye una integración continua o un andamiaje de pruebas, a menudo se necesitan índices. El sitio API REST por supuesto ya está disponible, pero hacerla emerger en una API facilita su uso.
Le rogamos que lea detenidamente estas RFC y comente las Subdocumento o el Gestión de índices ¡pull requests!
El mérito del desarrollo del proceso es de todo el equipo de ingeniería del SDK aquí en Couchbase. Michael inició el cambio de nuestros onepagers a SDK-RFC y Mark se encargó del primero con Sub-Document. Fue una buena para probar el sistema, debido a su amplio alcance. Brett y yo trabajamos con el equipo para refinar un poco el proceso y las herramientas, y todo el equipo (todos los anteriores más Sergey, Jeff, Todd y Simon) se lanzaron con contribuciones y comentarios.