Uma das vantagens do código aberto é a capacidade de ficar perto dos usuários. Isso tem sido extremamente útil à medida que desenvolvemos o Couchbase ao longo dos anos. É claro que, como em qualquer projeto e comunidade em rápido crescimento, de vez em quando você precisa revisitar e reajustar a infraestrutura principal para ajudar a ir mais rápido.
Essa é a nossa intenção com SDK-RFCs e hoje gostaríamos de solicitar uma opinião.
TL;DR: Diga-nos o que você acha dos planos para o novo API de subdocumento e o novo Gerenciamento de índices interface.
Mais sobre o desafio
Quando o Couchbase Server 3.0 foi lançado, também lançamos uma série de novos SDKs que estavam nos preparando para futuras versões. Cada um deles quebrou intencionalmente a API. Enviamos prévias de que tudo é código aberto sob uma licença Apache 2.0, mas nunca sabíamos realmente até que uma versão "ponto O" fosse enviada e se tornasse recomendada se a alteração seria aceitável. Olhando para trás, isso funcionou muito bem, pois quase todos que escrevem código para o Couchbase fizeram a mudança.
Um dos nossos objetivos com essa mudança foi tornar a API mais comum e, ao mesmo tempo, permitir expressões idiomáticas nas plataformas individuais que os desenvolvedores escolheram. A primeira etapa foi determinar, de forma colaborativa, o que achávamos que era o nível certo de detalhes na API e, em seguida, obter feedback de outras pessoas.
Na verdade, estávamos elaborando as renderizações do artista com rascunhos de plantas.
Em geral, isso funcionou bem. Muitos dos artefatos nos ajudaram a chegar ao nível de detalhe e uniformidade que desejávamos. Ainda assim, sentimos que poderíamos melhorar, certificando-nos de que as interfaces que estavam sendo definidas para os coprojetos eram realmente aceitáveis para esses coprojetos. Isso parece óbvio, mas havia algumas áreas problemáticas. Também achamos que deveríamos abrir mais espaço para que todos pudessem fazer comentários. Embora a maioria das pessoas que desenvolvem no Couchbase não tenha tempo para participar de conversas sobre design, o fato de sermos abertos colocará mais olhos inovadores em nossos pensamentos e na discussão, e tanto as discussões quanto os artefatos poderão dar a outros uma visão do pensamento e das decisões de design por muitos anos.
A infraestrutura
Nossos objetivos eram que qualquer pessoa pudesse participar da discussão, que os artefatos estivessem disponíveis publicamente e pudessem ser descobertos, e que o processo seguisse padrões com os quais os desenvolvedores estivessem familiarizados.
Há um pouco de sobreposição aqui com RFCs da IETFmas com um toque moderno. A reviravolta moderna é que, em vez de as listas de discussão serem o campo de jogo social para o discurso, as conversas com desenvolvedores - especialmente as abertas - agora acontecem em Github.
Criamos um novo repositório na organização couchbaselabs chamado SDK-RFCs. O primeiro SDK-RFC é o processo SDK-RFC porque somos meta assim. De fato, abrimos um problema para rastrear a necessidade e, em seguida, criar um pull request para documentar a abordagem. Durante todo o tempo, mantemos um LEIAME que lista tudo o que está em desenvolvimento e completo.
Conforme mencionado no README, sabemos que não estamos sozinhos nisso. É claro que existem os conhecidos RFCs da IETF, RFCs do Rust e meu ex-colega da Sun Bryan Cantrill e o pessoal da Joyent tinha uma necessidade semelhante e está fazendo um ótimo trabalho inspirando discussões em RFDs da Joyent.
Sua vez
Duas SDK-RFCs, em particular, estão bastante avançadas e prontas para receber contribuições. Gostaríamos muito de ouvir sua voz.
O primeiro é sobre Subdocumento operações. Há ocasiões em que os desenvolvedores de aplicativos desejam modificar uma parte de um documento sem recuperá-lo e armazená-lo. Para esse fim, um conjunto de extensões de protocolo e uma API estão sendo desenvolvidos para o nível mais baixo de operações, e outras APIs e componentes do Couchbase poderão aproveitar essas primitivas de sua própria maneira no futuro. Este SDK-RFC abrange um conjunto comum de API que colocaremos nos SDKs. Ela fará parte diretamente da interface pública se você quiser a alta eficiência que essa interface lhe proporciona. Os novos recursos do sistema também servirão para acelerar outras partes do Couchbase, como o N1QL, ao longo do tempo.
A segunda está em Gerenciamento de índices. Ao criar uma integração contínua ou uma estrutura de teste, os índices são frequentemente necessários. Os API REST já está disponível, é claro, mas a sua disponibilização em uma API facilita o seu uso.
Leia essas RFCs e faça comentários sobre Subdocumento ou o Gerenciamento de índices solicitações pull!
O crédito pelo desenvolvimento do processo vai para todos da equipe de engenharia do SDK aqui na Couchbase. Michael deu o pontapé inicial na mudança de nossos onepagers para o SDK-RFC e Mark assumiu o primeiro com o Sub-Document. Foi uma boa opção para testar o sistema, devido ao seu amplo alcance. Brett e eu trabalhamos com a equipe para refinar um pouco o processo e as ferramentas, e toda a equipe (todos os que foram citados acima, além de Sergey, Jeff, Todd e Simon) contribuíram com contribuições e comentários.
