Kenneth Freitas

Bora aprender sobre arquitetura de aplicações, alguns padrões, ideias e princípios usados quando estamos arquitetando nossas aplicações. Vamos falar sobre MVC, MVP, MVVC, Multi-camadas, Hexagon, Clean Architecture e várias outras coisas. Form de feedback! 

Alright, as you can see, recently I conquered both Nodejs certifications (JSNAD and JSNSD). So, let’s talk about these exams. As you already know, these exams are a little different because they are practical, this means that you have a VM to open the code editor of your preference and complete the challenges. The tip here, have a good pc and internet connection (MAC users, some keys will not work inside a VM, so you need to use a virtual keyboard). Node.js Services Developer (JSNSD) As you can check, on the Domains & Competencies from the official page of the exam , the topics are pretty simple and any tutorial from youtube with some framework gives you the ability to do that, but, security domain is harder and luckily represents only 30% (and of course is nothing advanced). The trick part of this exam is that it asks you to do practices that generally you don't execute on the application level. There are some questions that you don't have any idea how to implement because...

 Bem, todo mundo aqui sabe como funciona o típico Cliente-Servidor, onde o cliente manda uma requisição e o servidor responde, de uma maneira simples e unidirecional, em que o cliente sempre precisará informar o que necessita. Porém, tem casos que precisamos fazer o caminho inverso, onde o servidor notifica o cliente. Por exemplo: Notificar algum processo mais demorado, mostrando o quanto já foi realizado ou avisar sobre novos conteúdos. Depois desses exemplos, você já pode estar pensando “Ah, websockets”, mas não. E porque não? Então, websockets é uma comunicação bidirecional entre o cliente e o servidor, ou seja, quando uma conexão http (GET 1.1 upgrade) é realizada pelo cliente, irá mandar a solicitação ao servidor para a troca de protocolo (ws ou wss), criando uma conexão direta entre eles dois. Isso seria um caso perfeito para um chat, por exemplo. Então, como eu faço para ter essa conexão unidirecional do servidor para o cliente? Aí que entra Server-Sent Events (SSE). Com SSE...

Na rotina do trabalho é muito comum se deparar com o código dos outros, seja no projeto, em code reviews ou testes em processos seletivos e é aí que ter seu próprio estilo de código é tão importante, além do mais o "fit" não tem que acontecer apenas com a "empresa", mas também com a equipe de desenvolvimento. Já falei, mas vou repetir, tem muita vaga em desenvolvimento, mas pode ter certeza que tem bem mais candidatos. O grande problema de longe é o fator técnico (muitas vezes as empresas até desistem e pegam o "melhorzinho", pois a vaga está aberta há muito tempo) e ter seu próprio estilo de codar diz muito sobre suas habilidades e proficiência em uma tecnologia. Mas afinal, o que é "ter um estilo de código"? Não estou falando de style guides (entra também), estou me referindo ao jeito de codar em si. Por exemplo, para iterar um array em Javascript, podemos usar:  - while - for - for in - for of - forEach - e outros métodos que fazem outras cois...

Sempre que vamos começar um novo projeto, vem aquela velha discussão de começar pela interface, API, funcionalidade (shape up ou mais ágil) ou até pelo banco (galera mais antiga). Bem, cada uma tem suas vantagens e desvantagens já amplamente discutidas por aí. Mas e quando o seu produto é apenas uma API o que acontece? O problema com o desenvolvimento de serviços que são 100% por API para usuários finais é que geralmente fica muuuito a critério da parte técnica e isso tem alguns problemas. A API pode ficar com muitas abstrações (super simples, mas dificultando utilizações mais avançadas por parte do cliente) ou ela fica extremamente desacoplada (super complexa, com várias etapas até para coisas simples, fazendo com que o cliente precise construir muita coisa em cima) e às vezes com excesso de funcionalidades (que fogem do escopo ou que simplesmente ninguém vai usar, deixando mais trabalho para dar manutenção e podendo até abrir brechas na segurança. Ainda mais quando lançamos novas ver...

Programação funcional é um paradigma já bem conhecido e que nos últimos anos vem ganhando ainda mais força, principalmente depois do aparecimento do React e de algumas grandes empresas mostrando suas arquiteturas com linguagens 100% funcionais. Os “pilares” desse paradigma já são bem manjados, como: funções puras (uma função que sempre retornará o mesmo resultado, dado os mesmos argumentos, e claro, sem efeitos colaterais), imutabilidade, umas coisinhas mais avançadas como higher-order functions (uma função que recebe uma função como argumento ou também retorna uma função) e currying (que é uma função que recebe uma função e pode ir nessa várias vezes). Geralmente vemos a galera que trabalha com linguagens multiparadigma seguem apenas essas ideias, mas no mundo funcional podemos ir mais a fundo com o uso de Functors (basicamente uma função pega algum valor dentro de um contexto, aplica uma função, e devolve em um novo contexto), Applicatives (além de envolver um valor dentro de um novo...