 Oi, pessoal! Obrigado por me juntar. Netflix run uma plataforma Node.js que empurra todas as interfaces de usuário de devices. Como o negócio se desenvolve, a plataforma está crescendo para servir outros casos de uso, como as aplicações de web que suportam a produção de conteúdo. Meu nome é Guilherme Hermeto e eu sou um engenheiro e Netflix é um time-time team de Node.js. Eu explico a nossa plataforma revolvente enquanto maximizando a utilizabilidade de code. Para te dizer onde estamos indo, eu posso começar do início. Netflix começou usando Node.js no final de 2013 e a primeira aplicação de Node.js recebeu produção de trafico no ano de 2014, em que o trabalho de antes se desenvolveu para ser o seu currently serverless Node.js platform chamado Nodecork. A Nodecork service vive em um container que é aplicado em uma plataforma de manejamento de container chamado Titus e sinta por trás de um gato de aplicação level 7, chamado ZOO, que é responsável por autenticar, validar e routar regras dos clientes diversos para o serviço de Node.js. Ao recebendo um regras, o serviço de Node.js vai fazer um ou mais regras para os APIs de metade e formatar as respostas para enviar para o cliente.Both ZOO e Titus são projetos de Netflix open-source. Eu sugiro que você chegue agora no GitHub. A plataforma de Node.js o main goal foi para proporcionar uma experiência manejante onde clientes da rede poderiam criar experiências custom API feitas para seus específicos devices. Por exemplo, o Android Team poderia criar um API que melhor seria para o design do cliente. Sabe para iOS, TVY e outros clientes. Em outras palavras, o FF ou o Backend para o Frontend. Com a plataforma, o cliente pode se concentrar no seu objetivo enquanto abstraimos a infraestrutura complexa de oferecimentos e Netflix. Então, isso é o que você precisa para um serviço de Node.js. É um file de JSON de Node.js e um regras-regras. É isso. É tudo o que você precisa para ter um serviço de produção red. O file de Handler Rob pode retornar um regras-regras de funções. E você pode também especificar o Midoware ou Node.js. A plataforma será responsável para três áreas principais. Observabilidade Metrics, Distributor Tracing, Helping Dashboard e Centralized Logging. A bugabilidade com manegamento de excepção e funções diagnósticas. Exemplos de funções diagnósticas são grafes de flamengo e profissionais de heap. E, finalmente, disponibilidade com configuração, alertas, registração de serviço e cobertividade. Basicamente, tudo o que você espera para um serviço de produção red. Na plataforma decorada temos um aplicativo REST FI com o module REST both REST FI e o module REST são open source. Check them out on GitHub. O module REST é responsável para ler o file de JSON da aplicação custom e usar isso para localizar todos os Handlers. Quando lançamos uma versão da plataforma nós estamos publicando uma imagem docker com a run-time platform NodeCore e quando um cliente publica uma nova versão do serviço nós layermos essas imagens copiando a aplicação para a imagem da plataforma. Nós, como plataforma somos responsáveis para monitorar e mitigar os problemas com o processo de running. Quando a imagem da aplicação está aplicada o serviço está pronto para receber a aplicação de produção. Esse modelo permite para os clientes para construir aplicações que recebem grandes quantidades de aplicação e suporte de 182 milhões de subscritores. NodeCore é muito optimizado para esse caso de uso. Quando o negócio se desenvolve para empurrar um tipo diferente de aplicação como os que suportam os processos de produção de conteúdo e essas aplicações têm diferentes caracteristicas. Quando o streaming tem mais de 100 aplicações com grande footprint e às vezes requerem milhares de containers e servem dozens de milhões de usuários produtos de conteúdo têm um grande número de aplicações com uma pequena footprint e uma base muito limita de usuários. A segurança também é diferente quando um usuário streaming tem acesso a seus próprios accountos e todo o library de conteúdo produtos de conteúdo têm um jeito mais de uma autenticação e autorização. Nós temos que autenticar o serviço, os seus clientes e decidir o nível de acesso que cada usuário tem. E mesmo que ambos os tipos de serviços requerem distribuição, treinamento e login centralizado sample e retention não são os mesmos. Por exemplo em aplicações de streaming samplemos 0.1% de requerções enquanto em aplicações de produção faz sentido para samplemos 100%. E enquanto é só costa efetiva para continuar streamando logs rádiosamente disponíveis durante as últimas 24 horas provavelmente queremos aumentar a rendência de log para as outras aplicações em, digamos, um mês. As aplicações são diferentes, mas também compartilham muitas preocupações sobre a observabilidade com que o método realmente importa a divulgabilidade. Como eu rapidamente encontro o que é errado com o meu serviço? E a configuração. Como eu configuro a melhor configuração para running um serviço em produção? Isso é importante também. Afortunadamente a arquitetura original tinha suas limitações. O design original fez um monte de assuntos sobre a infraestrutura e outros casos eram apenas não no topo do ponto. E a estabilidade foi uma grande preocupação. Deixe-me expender isso. Então, a nossa equipe tenta realmente difícil não para romper Netflix em novas relícias platformas. É um processo low. Cada relícia platforma requer que ela possa marcar as mudanças, em vários serviços, comparando-se com a baseline. Se há any issues or performance degradation we search for the root cause we fix it then we rinse and repeat until we get a performance that is desirable. This model just won't fit well for the fast-paced new applications that we aim to support. It creates risk on one side and reduces velocity on the other. And one added piece of complexity. So when we took a step back and look at the whole customer base we saw that we have more differences than just content production and streaming applications. Some of those applications rely on Fallcore, some on REST, and most of the new ones, GraphQL. When I analyzed all the puzzle pieces I got to the conclusion that the best approach moving forward was to extract all those components from the platform into self-contained modules or plugins. Yeah, I went there, plugins. And what plugins solve our problem? How do they solve our problem? Well, plugins allow us to remove the fast-evolving pieces of the platform source code creating a much-needed stability for the streaming applications. And most of them can be reusing almost all applications with maximized code reusability and minimize our support burden. So we are going even further further than that. We are making everything plugins. Like everything. Except a tiny little piece of platform code that load plugins everything else is a plugin. Even the server. And that gives us a lot of flexibility. Right now our code is very intertwined with RESTFI. But if the server is a plugin with a stable interface it enables us to experiment with other application frameworks. Like FESTFI. When we were designing the plugins we researched a lot of other plugins. We researched different plugins implementations including how happy and FESTFI implement plugins. And we decided that we need a little bit more structure. So while happy and FESTFI plugins you pass application server back to the plugin. And let the plugin would find a server. We chose a format where the plugin actually provide hooks. And the platform control how and when those hooks are called. For comparison this is a FESTFI plugin. This is how you decorate FESTFI. This is how you add a pre-handler hook. And this is how you add a route from a plugin. Pretty simple. And this is how a Node-Cork plugin looks like. This is how you initialize a plugin and decorate the Node-Cork platform. The optional define-ski can be used for runtime type checking of the decorated object. This is how you define a pre-routing hook which is similar to the pre-handler hook of FESTFI. And finally this is how the plugin defines a route. So it's pretty simple too. This is the interface that I'm working with. Let's go check that out. In addition to the startup and shutdown hooks the plugins also provide the following lifecycle hooks before request pre-parsing pre-routing after request on air. These hooks are called during the different stages of the request lifecycle. We chose this structure to give us control now for instance in the future we might have a plugin which has different dependencies at startup and during the request lifecycle plugins are also responsible to provide a debug interface and a mocking interface. The debug interface is used by the platform debug server which runs in parallel with the customer servers and provides real-time for that instance. The mock interface allows our customers to mock a plugin during unit or integration test. And lastly, the route keys allow us to register platform defined routes. For instance a GraphQL or Apollo plugin could define a slash GraphQL route saving the user the trouble. This plugable architecture enable us to create another abstraction which we call application profiles. Application profiles are type of applications with similar characteristics meaning they use the same plugins. So an application profile can be seen as a list of plugins to load for a given application. We actually designed it as a module that imports the plugins portando um array of loaded plugins. In the future that will allow us to use the profiles to require different versions of plugins. We're not there yet we'll hope to be there soon. So since profiles only load specific plugins it reduces the risk of a plugin built for content production to break an application on the streaming path. For example if I just load the security for content production and I change that plugin very often as the profiles for streaming applications don't load that particular plugin it's fine that that plugin evolves fast. And not even limited plugins so the concept of application profiles cannot be leveraged through the platform. We can use it to load different dashboards, register different alerts and even load different sidecars or demons for each profile. As we remove all the moving pieces from the core platform its source code becomes very very stable and rarely needs to change. This allows us in the future to shift of focus from platform releases to profile releases. Interferently our tooling relies on platform versions but as we break the platform into smaller pieces it becomes less important in relation with profile versions. Where do we go from here? Well, for us the next step is to allow our partners teams to create application profiles and give to their customers enabling them to virtually build platforms on top of a platform. The interface that I show you its private to our team at this moment, but we plan to release that to our partner teams in the coming months. Right now we're trying to test validated and solidified before we make it a public interface to that. And it's all very open-ended but very excited. So we're very excited to see where this is going. And even beyond BFFs we are looking into serving federated graphs and server-side render applications. So possibilities, possibilities, possibilities. Today I touch some subjects like distributed tracing centralized logging and metrics. Some of what we use on Netflix is internal, so I can't really recommend everything you use. But if you just need a place to start I have options that I personally like to recommend and which are open source. For metrics and alerting there is Atlas, which use Netflix and Prometheus, which is very well known. For centralized logging I always liked Fluent D and some of the elastic products especially file bits to send your logs to Elasticsearch. For distributed request tracing Zipkin is definitely the way to go. For diagnostics there's Flamescope which use Linux Perf so you can use the Linux Perf package available on NPM. We use the same package on Nodecork. And lastly, for exception management Centro is very well known and easy to use. And I also always liked Airbreak. Muito obrigado por estar aqui com eu hoje e para me compartilhar ou trabalhar com você. Eu vejo você na QA.