Explorando o driver PHP com Jeremy Mikola - Episódio de podcast
Avalie esse Podcast
Jeremy Mikola é engenheiro de equipe no MongoDB e ajuda a manter o driver e a extensão PHP do MongoDB. Neste episódio do podcast, Jesse Hall e Michael Lynn sentam-se com Jeremy para falar sobre o PHP Driver e um pouco da história do PHP e do Mongodb.
Michael: [00:00:00] Ei, Jesse, como você está hoje?
Jesse: [00:00:02] Ok. Como você está?
Michael: [00:00:02] Fantástico. É bom ter você de volta no podcast. Ei, qual é a sua experiência com PHP?
Jesse: Já trabalhei um pouco em PHP no passado. Embora principalmente JavaScript, não muito, mas hoje temos um convidado especial. Jeremy Mikola é engenheiro de equipe da Mongo DB e sabe tudo sobre o driver PHP. Por que você não nos conta um pouco sobre há quanto tempo você está no MongoDB?
Jeremy: [00:00:26] Olá, que bom estar aqui. Então, entrei no MongoDB há pouco mais de nove anos. Então, em meados de maio, foi meu aniversário de nove anos. E durante toda a época do ano, muitos funcionários estavam aqui há tanto tempo. Eles tendem a se deslocar em departamentos diferentes e obter novas experiências. Eu estive na equipe de pilotos o tempo todo. Então, quando eu encontrar um lugar com o qual você se sinta confortável, você fica lá. Então, quando entrei, a equipe era talvez 10 ou 12 pessoas, talvez uma ou duas pessoas por idioma. Não tínhamos quase tantos idiomas oficialmente suportados quanto temos hoje. Mas o driver PHP foi um dos primeiros.
Na verdade, foi desenvolvido por alguns dos engenheiros do servidor. cristina, ela foi uma das primeiras funcionárias, não está mais no MongoDB agora, mas. Então, sim, na época era PHP, Python, Ruby, C# Java e, na verdade, Node. E nós meio que crescemos desde então.
Michael: [00:01:05] Fantástico. E qual é a sua experiência pessoal com PHP? Como você se envolveu com PHP?
Kerry: [00:01:11] Então, aprenderam o PHP como passatempo no colegial. O meu date aqui na formatura do colegial foi por volta 2001. É meio que em meados dos anos 90, chegar da escola, carregar o trabalho do Napster em um personal, ter um site pessoal do SimCity. Começamos nessa época do PHP. O Nuke foi uma das primeiras estruturas do CMS na época.
E muito disso era só mexer, copiar/colar e descobrir como as coisas funcionam, meio que autodidata até chegar à faculdade e depois ter aulas reais de ciência da computação e entender que há matemática por trás da programação e de todas essas outras coisas, conceitos. Então é definitivamente um hobby durante a maior parte da faculdade.
Meu currículo da Universidade não era PHP. E depois consegui, acabei conseguindo um emprego em tempo integral no qual estava trabalhando, que foi com um Symfony 1.0 na época, por volta de 2007, e acompanhei algumas empresas na função depois disso. Acabou sendo o Symfony 2.0 framework, eu estava acabando de lançar e foi nessa época que o PHP realmente começou a amadurecer com gerenciadores de pacotes e muito mais orientado a objetos, meio que abandonando alguns dos antigos
má publicidade teve dos primeiros anos. E a partir dali, também foi nesse segundo trabalho PHP que iniciei com o MongoDB. Então, na verdade, estavamos do outro lado da rua do escritório do MongoDB em Centro, Nova York, no distrito de ferro de Go e o suporte ao cliente na época era Go , atravesse a rua e suba até a escrivaninha de Eliot e os escritório do Go e o mongo antigos escritório 10gen. E você faria Go pergunta. Isso funciona quando você tem apenas alguns clientes oficiais.
Michael: [00:02:36] Estou falando sobre Eliot Horowits.
Kerry: [00:02:37] Sim, como Eliot Horowits, o cofundador era muito mais acessível do que quando a empresa era muito menor. E dessa função acabou pulando para um segundo tipo de empresa PHP com o mesmo framework, também usando MongoDB. Foi a mesma pilha de tecnologia. E depois dessa função, foi abordado por um antigo colega de trabalho da primeira empresa que usou o MongoDB. Ele acabou na equipe de pilotos, Steve Franzia. Ele foi um dos primeiros gerentes de engenharia, a equipe de motoristas ajudou a construir a inicial, muitos dos funcionários que ainda estão na equipe de motoristas
Agora, muitas das pessoas que lideram as equipes foram contratadas por ele ou chegaram na mesma época. Então, os primeiros desenvolvedores do Python, do driver Java, e então ele, quando recebemos uma entrevista, não tinham permissão para me recrutar para sair do primeiro emprego, independentemente da papelada que você assinou, você não pode recrutar seus antigos colegas de trabalho.
Mas depois que passei algum tempo em outro lugar, ele ficou feliz em me trazer para cá. Fiquei sabendo da oportunidade de entrar para a equipe de motoristas. E eu estava realmente empolgado por deixar de trabalhar com aplicativos e passar a desenvolver bibliotecas adequadas para outros desenvolvedores, em vez de um produto voltado para o cliente. E essa tem sido a história desde então, apenas realmente aproveitei para trabalhar em APIs, bem como para trabalhar na biblioteca ODM na época, sobre a qual podemos falar um pouco mais tarde. Então meio que já estava envolvido em muito ecossistema MongoDB PHP.
Jesse: [00:03:46] Legal. Então, vamos falar mais sobre isso, esse driver PHP. Então, o que é, por que é útil para nossos ouvintes? Como funciona?
Jeremy: [00:03:54] ok. Sim. Portanto, o nível definido para a explicação básica. Portanto, todas as linguagens desde o MongoDB não expõem um ... são. Não é como alguns bancos de dados, que podem ter um protocolo REST ou você apenas tem um cliente web acessando-o. Portanto, você precisa de um driver para falar a linguagem do protocolo de conexão, e os drivers do MongoDB são particularmente diferentes de alguns outros drivers de banco de dados.
Fazemos grande parte do monitoramento de servidores e muito mais pesados do que você pode encontrar em um equivalente como o driver SQL, especialmente como os drivers PHP SQL. Portanto, a biblioteca dos drivers é muito mais intensiva, com grande parte da programação de rede. Também somos responsáveis pela conversão, como o MongoDB armazena documentos em um formato JSON binário BSON convertendo-o para qualquer que seja a representação natural do idioma. Então, posso Java que pode ser apenas mapeando as aulas de Java com PHP. O driver original transformaria tudo em arrays associativas. Certifique-se de que uma string MongoDB se torne uma string PHP, vice-versa. E então o driver PHP original que você tinha conceitos familiares em todos os drivers.
Você tem seu objeto cliente com o qual se conecta ao banco de dados e, em seguida, tem seu banco de dados, sua coleção. E o objetivo é fazer de qualquer idioma para os usuários. Ao executar o aplicativo, torne os drivers o mais idiomáticos possível. E isso meio que nos incomodou desde o início, porque os drivers podem ser muito idiomáticos e inconsistentes entre si, o que se torna um problema para alguém que está escrevendo um aplicativo MongoDB, digamos, C# e PHP.
Pode haver duas experiências muito diferentes em Python e NodeJS. E a única coisa que não escrevemos desde então foi escrever especificações para codificar quais são as áreas que queremos que sejam idiomáticas, mas também queremos ter APIs consistentes. E isso também tem sido uma dádiva para nossa equipe de suporte porque, se os drivers podem se comportar de forma previsível, ambos têm uma API familiar externa com a qual nossos usuários se desenvolvem. E também internamente, como eles se comportam quando se conectam ao MongoDO, então poder impor isso e ter testes internos compartilhados entre todos os diferentes drivers tem sido uma grande vantagem para nossa equipe de suporte. Michael: [00:05:38] Então fale, fale um pouco sobre isso, o equilíbrio entre uma abordagem baseada em padrões e a abordagem idiomática, como isso funciona?
Jeremy: [00:05:48] Certo. Portanto, esse foi, sem dúvida, um processo de aprendizado em relação a algumas das primeiras especificações. Uma das primeiras especificações que tivemos foi para a API CRUD, que significa criar, ler, atualizar, excluir. E esse foi um dos, que é um componente essencial de cada API. Como se faz para inserir dados no MongoDB e lê-los de volta? E, com essa API, vamos padronizar esse é um método ótimo. Quais são as opções que devem levar como isso mapeia para os servidores? E a API do shell do MongoDB também. Esse foi outro projeto que existe fora do controle da equipe do motorista. Mas, do ponto de vista do cliente, o shell Mongo também é algo que eles são comuns de usar. Então, tentamos impor alguma consistência com isso também. E as especificações que queremos, a nível funcional, proporcionam uma experiência consistente.
Mas em termos de honra que toda linguagem deve ser idiomática. Faremos permissões para dizer que em C# você tem tipos especiais para representar unidades de tempo de tempo. Enquanto outras linguagens, como C ou Python, você pode usar apenas números inteiros ou tipos numéricos. Então, ter as especificações informando se você vai Express
como o tempo de consulta ou um limite de tempo na consulta permitirá que, como o driver C# dirá, se você tiver um objeto de tempo, certamente poderá usar esse tipo. E outro idioma ou alunos que fornecem orientação e também nomes consistentes. Então, diremos que esse método deve ser chamado find ou findOne em seu idioma, se você usar camel case ou snake case como Python com sublinhados, vamos permitir que você use essa variação. E isso manterá as coisas idiomáticas, para que um usuário que usa uma biblioteca Python não espere ver nomes de método no estilo Pascal em seu aplicativo. Eles vão querer que ela se integre a outras bibliotecas do ecossistema de linguagens. Mas os comportamentos devem ser previsíveis. E deve haver um senso comum de qual funcionalidade é suportada em todos os diferentes drivers.
Michael: [00:07:26] Isso é suportado por meio de sinônimos no próprio idioma? Então, para o que você mencionou, encontre e encontre um e talvez algumas pessoas estejam acostumadas com outras, outras palavras que representam a funcionalidade de leitura no CRUD.
Jeremy: [00:07:41] Então, esse é um ponto sobre o qual precisamos opinar, porque isso também se sobrepõe à documentação do MongoDB. Portanto, se você acessar o manual do servidor MongoDB que a equipe do driver não mantém, encontrará exemplos de linguagem lá. Uma iniciativa que iniciamos há alguns anos, e esse código que mantemos no projeto do driver, que a equipe de Docs analisará e poderá incorporar, será manual.
Portanto, para obter o benefício de um, podemos testá-lo em ambientes de CI. E, em seguida, o manual MongoDB que você está navegando. Você pode dizer, eu uso esta linguagem e, em seguida, todos os exemplos de código, em vez da shell MongoDB pode estar em seu, em C# ou Java ou PHP. Portanto, tendo consistência e sendo capazes de impor os nomes reais, precisamos ter a opinião de que queremos um método que leia o banco de dados em vez de chamá-lo de consulta ou seleção.
Queremos que isso seja chamado de encontrar. Então, queremos que isso seja nomeado de forma consistente e deixaremos a flexibilidade em termos de maiúsculas e minúsculas ou se você precisar de prefixos ou algo parecido, mas há certas palavras comuns ou certas principais. Queremos que os usuários pensem: oh, isso é uma descoberta, essa é uma operação de busca.
Ele também mapeia para o comando find no banco de dados. O mesmo acontece com inserções e atualizações. Uma das outras mudanças com os drivers antigos. Teríamos um método de atualização e, no MongoDB, de maneiras diferentes de trabalhar com documentos, você pode atualizá-los no local ou substituir o documento.
E ambos na perspectiva do servidor passaram a ser chamados de comando de atualização. Então você tinha drivers originais que teriam apenas um método de atualização com várias opções. E, dependendo das opções que você passar, eles podem ter uma infinidade de comportamentos diferentes. Você pode estar substituindo o documento inteiro.
Você pode estar incrementando um valor dentro dele. Então, uma das coisas que a API CRUD implementou foi dizer, vamos tipo de, é um tipo de padrão de design ruim ter um nome de método sobrecarregado que muda muito o comportamento com base nos argumentos. Então, vamos criar um método updateOne Substitui um método e o método updateMany.
Para obter mais informações sobre a implementação do CRUD no driver PHP, consulte a série PHP Quickstart.
Então agora que quando os usuários escrevem seus aplicativos em vez de ter que inferir, quais são as opções que estou passando para esse método? O próprio nome do método leva a mais informações por meio da autodocumentação do código no aplicativo desse usuário.
Jesse: [00:09:31] demais. Então, como os usuários começam a usar o driver?
Jeremy: [00:09:35] Sim, então acho que muitos usuários talvez tenham interagido pela primeira vez por meio dos cursos de educação on-line que temos na MongoDB University. Nem todos os drivers, não considero que haja uma classe de PHP para isso. Definitivamente, há um nó Python Java, alguns outros e apenas uma espécie de lista prioritária de recursos limitados para produzir esse conteúdo.
Mas muitos usuários são apresentados, eu direi, por meio da MongoDB University. provavelmente também ao voltar nove anos no início da empresa. O MongoDB teve uma presença enorme em hackathons universitários, indo a conferências e fazendo estandes, experimente o MongoDB e isso é definitivamente mais apropriado quando éramos uma empresa menor, menos pessoas tinham ouvido falar do MongoDB agora, onde é uma abordagem diferente para capturar os desenvolvedores.
Acho que, neste caso, muitos desenvolvedores já ouviram falar sobre o MongoDB e talvez seja menos do que isso. Talvez o foco tenha mudado para descobrir como esse banco de dados funciona para mudar talvez os equívocos que eles possam ter sobre isso ou fazer com que eles aprendam sobre alguns novos recursos que estamos implementando. Acho que outra maneira de os usuários aprenderem a usar bancos de dados é, às vezes, por meio de projetos que têm integrações com o MongoDB. Então, na primeira empresa em que usei MongoDB e Symfony em ambos, era muito cedo para usar ambas as tecnologias juntas. Havia o conceito de bibliotecas ORM para PHP, que meio que mapeavam suas classes PHP para o banco de dados relacional.
E na época eu não sei quem tomou essa decisão, mas no início da inicialização, a pior coisa que você pode fazer é usar duas tecnologias muito novas que estão mudando constantemente e são indiscutivelmente não comprovadas. Uma pessoa mais alta do que eu decidiu usar o MongoDB com esse novo framework da web. Ele ainda estava sendo desenvolvido ativamente e ainda não foi lançado oficialmente.
E precisamos de uma biblioteca ORM para o MongoDB porque não queremos apenas escrever consultas brutas de banco de dados de um lado para o outro. Por isso, desenvolvemos uma biblioteca ODM, mapeador de documentos de objetos em vez de mapeador relacional de objetos. E isso foi baseado nas mesmas interfaces comuns da biblioteca ORM correspondente. Então essa era a Doutrina ODM.
E então era muito cedo para escrever isso. Mas se integrou tão bem. Foi no framework e, desde o início, que muitos usuários, ao escolherem o framework Symphony two, perceberam que, oh, temos essa biblioteca ORM integrada a uma biblioteca ODM. Ambos têm
basicamente o mesmo tipo de suporte para todos os recursos comuns, tanto em termos de integração com os formulários da Web quanto para todos os pacotes, como armazenamento de contas de usuário, sessões de usuário e coisas do gênero. Portanto, em todas essas frotas ou funcionalidades, é uma espécie de substituto imediato. E talvez esses usuários disserem, oh MongoDB novo.
Eu gostaria de tentar. E para que isso seja possível. Tenha uma barreira de entrada muito baixa para entrar nela. Provavelmente levou alguns usuários a experimentá-lo e a continuar com ele. Nós definitivamente é isso. A segunda empresa estava usando-a na mesma linha. Ele estava disponível como uma substituição pontual e eles estavam ansiosos por não estarem vinculados a um esquema relacional. Então, definitivamente, teve seu uso como primeira empresa. Foi um produto de e-commerce. Então, definitivamente, ele fez uso do armazenamento como flexível, o design de esquema flexível para armazenar informações e outras coisas do produto. E então, nós usamos o banco de dados SQL lado a lado apenas para fazer todo o pedido, coisas transacionais.
Porque seguramente na época o MongoDB não tinha o mesmo tipo de nível de transações e coisas que tem hoje. Portanto, essa foi a minha experiência de usar a ferramenta certa para o trabalho e as diferentes partes da empresa, como usar o MongoDB para representar produtos e usar o relational database para fazer o processamento de pedidos e transações com o tempo.
Sem dúvidas me deixou com uma experiência positiva ao usar o MongoDB versus tentar enfiar tudo no banco de dados na época e perceber que não funciona para esse caso de uso. Vou escrever um post furioso sobre isso.
Michael: [00:12:53] Sim, posso me identificar. Então, se os ouvintes querem começar hoje, você mencionou o ODM, mencionou o driver, qual é a melhor maneira de começar hoje?
Kerry: [00:13:04] Então, com certeza, gostaria de sugerir que os usuários não pulem direto para uma biblioteca ODM. Porque, embora isso ajude você a acelerar e desenvolver rapidamente um aplicativo, também extrairá muitos dos componentes do banco de dados de você. Então você não vai entender como a linguagem de query funciona completamente, ou talvez como interagir com pipelines de agregação, que são alguns dos recursos mais avançados do MongoDB.
Dito isso, haverá alguns usuários que, quando você precisa, está desenvolvendo algo rapidamente, você não quer pensar nisso. Por exemplo, você está decidindo que é desconfortável e talvez eu queira usar o Atlas e usar toda a infraestrutura por trás dele com o dimensionamento e a capacidade de configurar facilmente backups e todas essas funcionalidades.
E então eu só quero começar a escrever meu aplicativo, gerar essas classes de modelo e apenas tocá-las e armazená-las no MongoDB. Casos de uso tão diferentes, eu gostaria de dizer, mas se você realmente quer aprender MongoDB, instale o driver PHP vem em duas partes. Há a extensão PHP, que é implementada em C.
Então essa será a primeira coisa que você vai instalar. E isso é publicado como um pacote de pickle, como muitas extensões PHP de terceiros. Então você instalará isso e isso fornecerá uma API muito básica além disso. Temos um pacote de nível superior escrito no próprio código PHP. E esse é o tipo de transferência, como qual é o código de trabalho pesado essencial que temos que fazer em C e qual é a API de alto nível que podemos implementar em PHP? É mais fácil de manter. Além disso, os usuários também podem ler o código ou contribuir facilmente com ele, se desejarem. E assim, esses dois componentes juntos formam o que chamamos de driver PHP. Assim, depois de instalá-los, familiarize-se com a API em termos de nossa documentação para que a biblioteca de alto nível passe por todos os métodos.
Nós não, gostaria de dizer onde nunca há tutoriais suficientes, mas há um monte de tutoriais para introduzir os métodos CRUD. Tipo de explicar o básico de inserção e leitura e escrita de documentos. O MongoDB escreve queries em pipelines pacientes iterando cursores. Quando você faz uma query, você obtém este objeto de cursor de volta, como você lê seus resultados de volta.
Espero que isso ofereça aos usuários uma espécie de plataforma de lançamento suficiente para começar. E eu realmente estava enviesado por ter sido exposto ao MongoDB por tanto tempo, mas acha que as APIs do driver são em sua maioria intuitivas. E esse certamente tem sido o objetivo de muitas das especificações que escrevemos. E eu vou dizer isso, isso desmorona
quando abordamos coisas como, por exemplo, a criptografia do lado do cliente, esses recursos avançados estamos sendo até mesmo um funcionário de longo prazo. Alguns desses recursos não fazem todo o sentido para mim porque não estou escrevendo aplicativos com eles da mesma forma que nossos usuários. Nós meio que, como engenheiros de pilotos, poderíamos ter uma parte da equipe média trabalhando em um novo recurso, em uma nova especificação para ela. Portanto, nem todo engenheiro de driver tem o mesmo benefício de ser, ter a mesma experiência global da plataforma de banco de dados que era fácil de fazer, então não anos atrás, onde vai dizer oh, entrei, estava familiarizado com todos esses aspectos do MongoDB , e agora há componentes do MongoDB com os quais nunca interagi.
Como alguns dos mecanismos de autenticação. Parte disso, como o Atlas, um recurso de Full Text Search, parece demais para entendermos.
Jesse: [00:15:49] Incrível. Sim. E se os usuários quiserem começar, não deixe de conferir as notas do programa. Incluiremos links para tudo lá. Vamos falar sobre o processo de desenvolvimento. Então, como isso funciona? E há alguma participação da comunidade aí?
Jeremy: [00:16:02] Sim. Então, o processo de especificação dos drivers Isso é algo que definitivamente mudou ao longo do tempo é que eu mencionei as especificações. Então, todo o trabalho a que MEAN meio que divide a carga de trabalho do motorista em duas coisas diferentes. Temos o trabalho downstream que vem do servidor ou de outras equipes como o Atlas tem uma nova funcionalidade.
O servidor tem um novo recurso, algo como criptografia do lado do cliente ou Full Text Search. Portanto, para que isso seja usado por nossa comunidade, precisamos de apoio para isso no driver. Certo? Então, vamos criar tickets downstream e um ou dois engenheiros de driver, uma pequena equipe irá especificar qual deve ser a API do driver para esse recurso.
E isso estará no nosso caminho para o próximo, se você considerar como MongoDB 5.0, Eu estava saindo em breve. Ou então, se olharmos para eles, MongoDB 5.0, que deve ser lançado no verão e terá vários novos recursos que precisam ser incluídos na API do driver. E estamos no processo de projetá-los e escrever nossos testes para eles.
E haverá outro punhado de recursos que talvez estejam totalmente contidos no driver ou talvez em uma única linguagem, como um novo recurso que queremos escrever, vamos dar um exemplo, um PHP, desejamos aprimorar a API em torno do mapeamento desses recursos para as classes PHB e vice-versa.
Então, isso é algo que está vinculado à biblioteca ODM do curso. Isso foi algo que foi. O trabalho pesado e isso foi feito. Esse médico fez inteiramente no PHB há maneiras de usarmos a extensão C para fazer isso. E é uma questão de escrever código C suficiente para fazer o trabalho de que a dita Doutrina possa confiar totalmente nela, em vez de ter que fazer muito disso ainda por conta própria.
Então, nós dois trabalhando no driver PHP agora, eu e Andres Bronan, ambos temos um histórico de trabalho no projeto Doctrine, ODM. Então sabemos quais são as necessidades dessa biblioteca.
E estamos em uma boa posição para especificar o tipo de recursos. E o mais importante, neste caso, envolve muita prototipagem para descobrir o equilíbrio certo de quanto código queremos escrever. E qual é a melhoria de desempenho que poderemos dar à terceira, as bibliotecas de nível superior que podem usar o driver.
Isso é algo que seremos. Outro exemplo para outros drivers é a implementação de um tempo limite de operações do lado do cliente. Então, este é um exemplo de um projeto de driver cruzado que consiste principalmente nos drivers de linguagem. E isso é para oferecer aos usuários uma API melhor. Então, agora mesmo MongoDB
tem um monto de opções. Se você quiser usar o tempo limite do soquete. Portanto, podemos dizer que essa operação deve ser executada por um período X, mas, em termos do que queremos dar aos nossos usuários e ao driver, basta pensar em um período lógico de tempo em que você deseja que algo seja concluído e não ter que definir cinco opções diferentes de tempo limite em vários níveis baixos.
E isso é algo que está sendo desenvolvido por dentro. Estamos especificando uma API de driver comum para fornecer isso, e esse recurso realmente depende inteiramente dos drivers e do dinheiro, e não é realmente um recurso de servidor ou Atlas. Esses são dois exemplos de tickets que não são alterações downstream.
Somos os criadores desse recurso. E então você tem, temos uma mistura de ambos, e é sempre uma falta de pessoas suficientes para fazer todo o trabalho. E então, o que priorizamos? O que é chutado? E, felizmente, geralmente são os projetos de impulsionadores orgânicos que precisam ficar em segundo plano em relação aos projetos posteriores vindos de outros departamentos, porque precisamos pensar em termos do ecossistema global do MongoDB.
E, se uma equipe do Atlas for desenvolver um novo recurso e o pessoal não puder usá-lo a partir dos drivers, alguém escreverá seu aplicativo diretamente com o shell do MongoDB. Então, se precisarmos, há certas coisas que precisamos ter e motoristas, e então resolvemos isso encontrando recursos e pessoal suficientes para realizar o trabalho.
Micael: [00:19:12] Estou interessado em saber o envolvimento da comunidade. Há muitos desenvolvedores que contribuem com código?
Jeremy: [00:19:19] Então, posso dizer definitivamente sobre o driver PHP, olhamos para o lado da extensão e vemos que há uma grande barreira de entrada em termos de quando entrei na empresa, Eu não sabia escrever extensões C e veja, não é só uma questão de conhecer C. É conhecer todas as macros que o próprio PHP utiliza.
Nós, com certeza, fizemos contribuições menores para a biblioteca escrita em PHP. Mas eu gostaria de dizer que mesmo assim não é o mesmo que se o compararmos com o projeto Symfony ou outros frameworks da web, como o Laravel, onde há muito envolvimento da comunidade. Por exemplo, as pessoas não estão executando um aplicativo, elas querem um recurso específico.
Ou há uma lista enorme de bugs. Que não há tempo suficiente para os desenvolvedores principais trabalharem. E assim os usuários pegam os frutos mais fáceis e/ou os projetos maiores, dependendo da hora. E eles fazem uma contribuição de volta à estrutura e é isso que eu estava fazendo. E isso para a primeira empresa, quando você usa o Symphone e o Mongo. Mas eu direi que, em termos de drivers falando em nome do PHP, não há muito envolvimento da comunidade em termos de nós.
Definitivamente, temos problemas relatados, mas em termos de envio de patches ou solicitação de novos recursos, não vejo a mesma atividade. E não me recordo disso. Eu diria que, em relação ao driver PHP, não vejo o mesmo tipo de atividade de contribuição do usuário que você veria em estruturas da Web populares e outras coisas.
Não sei se isso é um fator do motorista fazer o que precisa fazer ou se as pessoas são consideradas uma caixa preta. É essa a API que vou fazer funcionalmente aqui e não tentar adicionar novos recursos. De vez em quando, recebemos solicitações de recursos, mas não acho que elas se materializem em contribuições de código.
Pode ser que alguém queira essa funcionalidade. Eles não têm certeza de como iríamos projetá-lo. Ou eles não têm certeza, tipo, quais refatorações internas ou o quê, o que é? Qual é o escopo completo do trabalho necessário para realizar esse recurso? Mas eles nos disseram que, ah, seria bom se talvez o tipo de data do MongoDB fosse mais utilizável com fusos horários ou algo parecido. Então, você pode nos fornecer uma maneira melhor de isso ser identificável, identifique um ponto de problema para nós, e isso nos apontará para dizer, desenvolver alguns recursos para refletir sobre isso. E talvez isso se torne uma especificação geral dos drivers. Talvez isso se torne apenas um projeto para o driver PHP. Poderia dizer um pouco de ambos.
Eu gostaria de destacar a participação da comunidade em drivers versus drivers existentes. Sem dúvidas, temos muitos drivers desenvolvidos pela comunidade, de modo que o MongoDB, como empresa, limita o número de funcionários. Temos talvez uma dezena de idiomas que apoiamos ativamente com os drivers. Há muito mais do que isso em termos de drivers desenvolvidos pela comunidade.
E esse é um dos benefícios de publicarmos especificações para desenvolver nossos drivers, como abrir o código aberto do nosso processo de desenvolvimento. Também é uma benção para os motoristas da comunidade, quer eles tenham os recursos para acompanhar todos os recursos ou não, eles podem decidir alguns desses recursos, como os recursos mais corporativos, talvez um motorista da comunidade não se importe com isso. Mas se estivermos atualizando a API CRUD ou um dos recursos mais essenciais e geralmente úteis, eles podem acompanhar os processos de desenvolvimento e ver quais alterações estão por vir para novas versões do servidor e implementar isso no driver da comunidade. Então, essa é a maneira mais eficiente que criamos para apoiá-los sem ter os recursos para realmente contribuir em todos esses projetos comunitários.
Porque eu acha que se pudermos, seria ótimo ter funcionários do MongoDB trabalhando em um driver para todas as linguagens possíveis. Não é possível fazer isso. Portanto, é a segunda melhor coisa que podemos fazer. E talvez em vez de jogar dinheiro de capital de risco neles e patrocinar o trabalho, o que fizemos no passado com alguns motoristas em diferentes graus.
Mas será que esse processo de design é de fonte aberta, mantendo-o tanto quanto o produto acabado, mas também a comunicação, o processo de revisão e mantendo-o nele para ceder o máximo possível de jardas para que as pessoas possam seguir o raciocínio do design que entra nas especificações e se manterem atualizadas com as mudanças de driver.
Michael: [00:22:46] Estou curioso sobre o queda da comunidade PHP, obviamente houve vários fatores em torno disso, certo? O Advento do Node JS e a Popularidade das Estruturas em torno do JavaScript, provavelmente estão Contribuindo para Isso. Mas estou curinga como alguém que trabalha no espaço PHP, o que você acha do, o recuo geral do, ou também direi a diminuição do número de novos programadores que utilizam o PHP, você vê que continua ou você acha que talvez o PHP tenha um pouco de vida restante?
Kerry: [00:23:24], então é difícil para eu identificar realmente essa causa. Há muito tempo que parei de desenvolver aplicativos PHP. Mas, no meu tempo no MongoDB, eu gostaria de dizer que talvez nos primeiros sete ou oito anos do meu tempo aqui, a CoVid meio que interrompeu tudo, mas eu era relativamente ativo em participar de conferências na comunidade e observar as mudanças no ecossistema PHP com os frameworks como Symfony e Laravel, particularmente o Laravel. E alguns deles são focados em regiões onde você pode dizer que o Symfony é definitivamente mais ativo na Europa. Laravel: Se você observar os usuários do USB Hp e eles podem estar lá em comparação com o que se passou nos EUA da mesma forma que o Laravel, estou tipo, com licença, onde a comunidade Symfony talvez não tenha t desenvolvido em
no mesmo passo que o laravel fez nos Estados Unidos. Então, se você Go a essas conferências, verá que há uma grande quantidade de pessoas entusiasmadas com a linguagem e que ainda testemunham ativamente que gostam de aprender programação sozinhas, escreveram sua primeira inscrição em uma dessas estruturas e apoiaram suas famílias, ou fizeram a transição de um emprego não técnico para um desses. Então, com certeza, você ainda tem pessoas aprendendo PHP. Eu direi que não tem a mesma história que obtemos ao pensar no Node JS, onde há esses Bootcamps que existem. Não estou certo de que você tenha a mesma experiência com PHP. Mas, com certeza, ainda há muitas pessoas aprendendo PHP e fazendo Carreiras com ele.
E mesmo na mudança de, em termos de maturidade linguística, pode-se dizer. Talvez seja um pouco estereotipado que você diz que o PHP é uma relíquia do início dos anos 90. E quando as pessoas pensam nas plataformas CMS mais antigas e talvez em projetos como WordPress ou Drupal, que, se focarmos nos números, ainda usam números incríveis em termos do número de sites que eles alimentam.
Mas também é, eu não acho que as pessoas necessariamente, elas olham para as implantações do WordPress e coisas como, oh, isso é o que eles podem ver isso como uma plataforma de mais dados e isso é um WordPress. Foi mais um software que você implementa, bem como uma estrutura da web. Mas, como em termos de suporte a instalações e coisas mais antigas do PHP, e, em seguida, olhando para as estruturas mais recentes onde eles podem fazer de ponta, como se só fossemos oferecer suporte ao PHP.
Os últimos lançamentos de PHP de três anos, o que não é um luxo que uma plataforma estabelecida como WordPress ou Drupal possa ter. Mas mesmo se considerarmos o Drupal ou o último, no tempo em que estive no MongoDB, eles deixaram de ser uma espécie de estrutura própria para se desenvolverem novamente em cima da estrutura Symphony e meio que modernizaram suas entranhas.
E isso gerou muito disso. Poderíamos dizer as comunidades isoladas onde alguém pode se identificar como um desenvolvedor Drupal e apenas trabalhar no ecossistema Drupal. E então ter essa mudança de framework agora sendo desenvolvida em um Symfony e tendo mais interoperabilidade com outras frameworks web e pacotes PHP.
Alguns desses únicos desenvolvedores triplos passaram a se tornar uma espécie de pau para toda obra, desenvolvedores de PHP e, mais ainda, uma espécie de engenheiro de software bem equilibrado nesse aspecto. E acho que você encontrará pessoas em ambos os campos, como se você certamente pudesse ser incrivelmente bem-sucedido, escrevendo plugins do WordPress.
Portanto, você poderia ser incrivelmente bem-sucedido escrevendo sites para clientes em estruturas da Web. Da mesma forma que você pode ingressar em uma empresa em tempo integral que assina que toda essa plataforma será construída em uma estrutura web específica.
Jesse: [00:26:28] Sim, essa é uma pergunta carregada. Não estou achando que o PHP vai a lugar algum. Isso porque o JavaScript recebe muita publicidade. Mas o PHP tem uma forte presença na comunidade e é aí que tenho alguma experiência com o WordPress. Foi lá que também me introduziram ao PHP.
Mas o PHP é, sim, não vai a lugar nenhum.
Kerry: [00:26:49] Pense que, da nossa perspectiva sobre os drivers, também podemos observar muitas das novas versões do PHP que são lançadas. Então, como agora eles estão trabalhando em uma espécie de API para suporte assíncrono, muitas das novidades que temos digitando sistemas de tipo muito mais estrito, que como engenheiro de software, você aprecia, você percebe em termos de flexibilidade de um linguagem de script, você não quer digitar, mas dependendo de como você está abordando, como diz.
Trabalhando no driver do MongoDB, há muitos recursos novos que queremos usar. E estamos meio limitados em termos de clientes que ainda usam versões anteriores do PHP, sete definitivamente ainda são alguns clientes, talvez no PHP cinco. Então, temos que dançar em termos de quando cortamos o suporte para versões mais antigas do PHP ou até mesmo para versões mais antigas do MongoDB?
Portanto, não é exatamente a mesma luta que talvez o WordPress tenha a ver com a possibilidade de ser implantado em todos os lugares. Mas acho que quando você está desenvolvendo um projeto para sua própria empresa e tem controle total da pilha de tecnologia, você pode usar os novos recursos mais recentes e curtir o surgimento de novas tecnologias.
Você deseja integrá-lo, você controla sua pilha de tecnologia completa. Quando você está escrevendo uma biblioteca, você meio que precisa equilibrar qual é o menor denominador comum que razoavelmente apoiaremos? Porque ainda temos uma base de usuários. E é aí que a equipe de motoristas que usamos, nossos gerentes de produto, nos ajuda a fazer essa pesquisa.
Coletamos estatísticas sobre os usuários do Atlas para descobrir quais versões do PHP eles estão usando e quais versões do MongoDB também estão usando. E isso nos dá algum tipo de inteligência para dizer se ainda devemos oferecer suporte a essa versão antiga do PHP enquanto temos um, um ou 2% de usuários? Isso vale a quantidade de tempo ou o sacrifico de recursos?
Que não estamos conseguindo aproveitar.
Jesse: [00:28:18] Certifique-se. Então, acho que você já falou um pouco sobre isso, mas o que está no roteiro? O que está por vir?
Jeremy: [00:28:24] Então, Andreas e eu definitivamente estamos ansiosos para nos concentrar apenas no desenvolvimento do projeto PHP. Revisitar parte da integração do BSON para criar uma API melhor não é apenas beneficiar a doutrina, mas eu diria que qualquer biblioteca que integre etapas fornece um mapeador de objetos além do driver.
Encontre algo geralmente útil. Há também integrações de framework que, então, mencionei que aludi ao Laravel anteriormente. Então, para o Laravel, como um framework é uma espécie de PDA por aí ou que vem com o framework é baseado em bancos de dados relacionais. E há uma integração do MongoDB para o Laravel que é um tipo de comunidade desenvolvida e que lida com o problema do mínimo denominador comum. Não podemos aproveitar todos os recursos do MongoDB porque temos que fornecer uma API consistente com o relacional ORM que vem com o Laravel. E este é um desafio semelhante quando, no passado, dentro da equipe de pilotos ou pessoas de fora, os outros departamentos do MongoDB disseram, oh, por que não fazemos o WordPress funcionar neles? Com o MongoDB por perto, temos o Drupal em execução no MongoDB, e não é tão fácil quanto parece, porque se toda a plataforma assumir porque... a mesma coisa surgiu antes com muito tempo atrás com a estrutura Django Python. Foi como, ah, vamos colocar o Django para executar no MongoDB. E isso foi como 10 anos atrás. E eu acho que é certamente um desafio quando a estrutura em si tem você não pode lutar contra a inércia das decisões opinativas da estrutura.
Então, no caso do Laravel, eles têm essa integração com o MongoDB suportada pela comunidade e ele luta para implementar muitos recursos do MongoDB que meio que não podem ser encaixados nisso. E esse é um projeto que não está mais nas mãos dos desenvolvedores originais. É como uma equipe por trás dele, de pessoas na comunidade que têm níveis variáveis de tempo para focar nesses recursos. Então, esse projeto está agora nas mãos de uma equipe, não do mantenedor original. E lá, eu pensa, MEAN, todos eles têm trabalhos. Todos eles têm outras coisas que estão fazendo em seu tempo livre, ofereça gratuitamente. Então, isso é algo sobre o qual podemos fornecer algumas orientações no passado, por exemplo, participamos de revisões de código e tentamos responder a algumas perguntas difíceis sobre o MongoDB.
“Acho que a direção que eles estão seguindo agora é: eles querem remover recursos para a próxima versão futura e simplificar as coisas e obter o que têm de realmente estável. Mas se isso é algo quando, se pudermos construir nossa equipe aqui e dedicar mais tempo, porque. Observamos nossas estatísticas internas.
Com certeza, temos muitos clientes do MongoDB que usam o Laravel com o framework PHP ou Symfony. Então, dado o número de usuários PHP que usam coisas como Drupal e wordpress, não os estamos vendo no MongoDB da mesma forma que as pessoas que usam frameworks brutas e aplicativos em desenvolvimento podem escolher isso, nesse caso, eles' estão no controle total do que eles implantam. E quando eles optarem por usar o MongoDB, queremos ter certeza de que o façam. Pode não ser a primeira classe porque não pode ser a mesma experiência que a aura que acompanha a estrutura. Mas acho que definitivamente existe se traçarmos uma estratégia e pensarmos em quais recursos podemos oferecer suporte.
Mas para isso, e isso provavelmente exigirá que nos familiarizemos com a estrutura, porque eu direi que quanto mais tempo passarmos no MongoDB trabalhando diretamente no driver. Ficamos mais desconectados da época em que éramos desenvolvedores de aplicativos. E assim podemos abordar isso de duas maneiras.
Podemos dedicar nosso tempo gastando tempo executando aplicativos de exemplo e encontrando esses pontos problemáticos por nós mesmos. Podemos tentar contratar alguém familiarizado com a biblioteca, o que é como o benefício de quando fui contratado ou Andreas foi contratado saindo de um emprego em um aplicativo PHP. E então você traz essa experiência e é uma questão de tempo até que eles se desconectem nos próximos 10 anos.
Ou sim. Recrutar alguém com experiência ou gastar tempo para experimentar a estrutura e descobrir os pontos problemáticos ou entrevistar usuários é outra coisa que nossos gerentes de produto fazem. E isso nos dará alguma orientação em termos de uma das coisas que queremos focar para permitir que o tempo permita e onde podemos ter o maior impacto para proporcionar aos nossos usuários uma experiência melhor?
Michael: [00:31:59] As pessoas que estão escutando querem dar feedback. Qual é a melhor maneira de fazer isso? Você está envolvido nos fóruns, os fóruns community.MongoDB.com?
Jeremy: [00:32:09] então nós monitoramos isso. Eu diria que muitas das perguntas de suporte lá porque a própria equipe de pilotos é composta por apenas algumas pessoas para o idioma versus toda a nossa equipe de suporte da comunidade e o departamento de serviços técnicos. Portanto, certamente não vou lá todos os dias para verificar se há perguntas de um novo usuário.
E para dar crédito à nossa equipe de suporte da comunidade. Como se eles próprios fossem capazes de responder a muitas das perguntas sobre o idioma. Isso é algo, e então eles vêm, eles escalam coisas para nós. Se houver uma dúvida maior, assim como nossa equipe de suporte comercial paga, eles também sentem muitas coisas.
E então, talvez uma ou duas vezes por mês, recebamos uma pergunta sobre o idioma. E é só que estamos, estamos meio perdidos aqui. Você pode explicar o que o motorista está fazendo aqui? Diga-nos que isso é um bug. Mas eu diria que os fóruns da comunidade são a melhor maneira de fazer isso se você estiver postando lá. As informações com certeza chegarão até nós porque, seguramente, nossos gerentes de produto, as pessoas que estão focados em tempo integral em lidar com a comunidade, verão o primeiro em termos de, para os drivers que estamos usando no JIRA e em nossos vários Projetos do GitHub. E acho que eles são mais bem usados para relatar bugs reais em vez de consultas gerais de suporte. Eu sei que, como alguns outros projetos de código aberto, eles usarão o GitHub para rastrear ideias semelhantes e, em seguida, tudo mais, não apenas relatórios de bugs e coisas assim. Em nosso caso, nós meio que, para fazer o melhor uso do nosso tempo, meio que tudo bem, queremos manter o JIRA e o GitHub para bugs e problemas de suporte ao cliente.
Se houver uma discussão aberta, temos esses fóruns da comunidade e isso nos ajuda a manter as informações no melhor fórum, sem trocadilhos, para discuti-las.
Michael: [00:33:32] Sim, esta foi uma ótima discussão. Muito obrigado por compartilhar todos os detalhes sobre o driver PHP e a extensão. Perdemos alguma coisa? Há algo que você queira garantir que os ouvintes saibam sobre PHP e Mongo DB?
Jeremy: [00:33:46] Acho que é um incentivo compartilhar um feedback. Se houver, se houver pontos problemáticos, definitivamente gostamos de nós, eu definitivamente digo que outros idiomas têm mais pessoas vocais. E por isso é sempre incerto. É que simplesmente não tivemos pessoas falando conosco ou é uma questão de ou os usuários não acham que deveriam estar levantando as preocupações, então apenas reitere e incentive as pessoas a compartilhar o feedback?
Jesse: [00:34:10] Ou não há preocupações. Jeremy: [00:34:12] Sim. Ou talvez eles estejam realmente em termos de nossos. Nossos relatórios de bugs são muito, temos muito poucos relatórios de bugs em comparação com alguns outros drivers.
Michael: [00:34:19] Isso é uma coisa boa. Sim.
Incrível. Jeremy, muito obrigado mais uma vez, realmente agradeço seu tempo, Jesse. Obrigado por sua ajuda com a entrevista.
Jesse: [00:34:28]Obrigado por me receber.
Jeremy: [00:34:29] Foi ótimo conversar com vocês. Obrigado.
Esperamos que você tenha aproveitado este capítulo do podcast. Se você estiver interessado em saber mais sobre o driver PHP, visite nossa páginade documentação e o repositório do GitHub. Também recomendamos que você visite nossos fóruns, onde temos uma categoria específica para PHP.
Também gostaria de incentivá-lo a verificar os artigos do PHP Quickstart que escrevi recentemente em nosso Hub do Desenvolvedor. O feedback é sempre bem-vindo!