DEV Community: Kamila Santos Oliveira

Microsserviços com Spring Cloud: Introdução

Kamila Santos Oliveira — Sat, 10 Apr 2021 14:48:09 +0000

O que são microsserviços?

São uma abordagem de arquitetura na qual o software consiste de pequenos serviços independentes que se comunicam entre si e são organizados de acordo com seus domínios de negócio.

Em arquiteturas monolíticas, os processos são extremamente acoplados e são executados como um único serviço , sendo assim se uma parte do sistema tiver a necessidade de escalar será necessário escalar o sistema todo.

Microsserviços são autônomos, cada serviço pode ser desenvolvido, implantado e escalado sem interferir em outros serviços.

Microsserviços são especialistas, cada serviço é desenhado para resolver um problema específico, se for necessário adicionar código de outras responsabilidades é recomendável separar em outro serviço.

Microsserviços são resilientes, a independência do serviço aumenta a resiliência a falhas na arquitetura, se um deles tiver problema , só afetará a parte do fluxo pela qual ele é responsável.

Microsserviços facilitam a reutilização de código, a divisão em módulos com responsabilidades bem definidas possibilita que funções específicas de um serviço possam ser utilizadas para complementar features sem outros sem a necessidade de escrever um código novo.

Microsserviços permitem ter liberdade na escolha da stack, pois n microsserviços de n linguagens diferentes podem se comunicar via endpoints sem problemas.

Spring Cloud

Fornece uma série de ferramentas que facilitam a criação de aplicações distribuídas e escaláveis.

Dentre as funcionalidades podemos citar:

Service Discovery

Que permite que outros serviços "descubram" facilmente a rota dos serviços que precisam acessar

Mais conhecidos do Spring Cloud:

Gateway

Tem o papel de ser um intermediário nas requisições para outros serviços.

Mais conhecidos do Spring Cloud:

Config server

Permite armazenar configurações de aplicações de modo centralizado fora da aplicação (por ex, em um repositório que centralize todas as configurações de todos os microsserviços.

Config Server

Load Balancer

É responsável por distribuir de forma eficiente o tráfego de requisições dentre as instâncias de um mesmo serviço.

Mais conhecidos no Spring

Ribbon
Spring Cloud Load Balancer

Feign

Facilita a criação e utilização de Clients HTTP.

Feign

Circuit Breaker

Facilita o acompanhamento e controle de falhas e altas taxas de latências entre os serviços.

Mais conhecidos no Spring:

Hystrix

Resilience4J

Referências e dicas de onde estudar mais sobre:

O que são microsserviços?

Spring Cloud

The Beginner’s Guide To Spring Cloud - Ryan Baxter

Introduction to Spring Cloud in 10 Minutes

Microservices com Spring Cloud

Spring Cloud | Introduction | Simple Programming

01 Agenda - Spring Boot Microservices Level

1 Agenda and prerequisites - Spring Boot Microservices Level 2

Microservices Architecture - What is Service Discovery with Eureka?

What is service discovery really all about? - Microservices Basics Tutorial

Spring Cloud Service Discovery: Netflix Eureka Server

Spring Cloud Netflix Eureka Baeldung

Service Discovery com o Eureka

How to configure SpringCloud Zuul – Routing and Filtering using SpringBoot | Java Techie

Spring Boot Microservices 03 - Service discovery Eureka e Gateway Zuul

Spring Cloud Gateway Baeldung

Spring Cloud Gateway DevGlan

Spring Cloud | Cloud Config Server | Simple Programming

What is Spring Cloud? | Tech Primers

Spring Cloud Feign - Declarative REST Client

11 Understanding the circuit breaker pattern - Spring Boot Microservices Level 2

Spring Tips: Spring Cloud Circuit Breaker

Alguma dúvida ou sugestão? Deixa aqui nos comentários :)

[Série do Instagram - Primeiros passos como backend] Programação orientada a objetos

Kamila Santos Oliveira — Mon, 25 Jan 2021 11:07:27 +0000

Olar, no primeiro artigo dessa série listei os posts sobre lógica de programação que escrevi como parte da série, e nesse artigo vamos rever os posts sobre orientação a objetos da última semana:

Primeiros passos como backend #5 - Objeto, atributo, método, o que é isso?

Primeiros passos como backend #6 - O que é programação orientada a objetos

Primeiros passos como backend #7 - O que é abstração?

Primeiros passos como backend #8 - O que é encpasulamento?

Primeiros passos como backend #9 - O que é herança?

Primeiros passos como backend #10 - O que é polimorfismo?

Algumas recomendações para aprender mais sobre programação orientada a objetos:

Curso de poo - Curso em vídeo

O que é Programação Orientada a Objetos - Conceitos Básicos de POO - Bóson Treinamentos

Abstração, Herança e Polimorfismo a base de um bom código

Curso de Java - Loiane Gronner

ORIENTAÇÃO A OBJETOS em 8 minutos: Encapsulamento - DevMedia

Até o próximo artigo :D

[Série do Instagram - Primeiros passos como backend] Lógica de Programação

Kamila Santos Oliveira — Sat, 09 Jan 2021 15:05:13 +0000

Olar, recentemente iniciei uma série de posts no instagram com conteúdos e dicas de estudos para quem quer começar a carreira de backend, focando principalmente em Java e Spring (mais detalhes nesse post), semanalmente estarei escrevendo um artigo para centralizar os posts da semana e indicar alguns links complementares de estudo, a primeira semana foi sobre lógica de programação e tivemos quatros posts sobre esse assunto:

Primeiros passos como backend #1 - Lógica de programação parte 1

Nesse post expliquei o que é lógica de programação, o que são algoritmos e como podemos representar um algoritmo.

Primeiros passos como backend #2 - Lógica de programação parte 2

Nesse post expliquei o que é uma variável, o que é uma constante e como funcionam os desvios condicionais

Primeiros passos como backend #3 - Lógica de programação parte 3

Nesse post falei sobre o "escolha-caso" e sobre laços de repetição

Primeiros passos como backend #4 - Lógica de programação parte 4

Nesse post indiquei alguns canais no youtube para aprender mais sobre lógica de programação:

Algumas recomendações para aprender mais sobre lógica de programação:

Lógica de Programação - school of net

Lógica de programação - softblue

Lógica de programacao com java - algaworks

Lógica de Programação com JS

Se conhecer mais algum material gratuito sobre lógica de programação deixa aqui nos comentários :)

Segunda-feira iremos começar a falar de orientação a objetos, já segue o perfil lá no instagram para não perder nenhum conteúdo :)

Até o próximo post :)

Retrospectiva (?) das palestras que tive a oportunidade de realizar em 2020 <3

Kamila Santos Oliveira — Mon, 21 Dec 2020 10:59:07 +0000

Olar, tudo bem?

Nesse artigo vou reunir as palestras que realizei em 2020 (não seguindo a ordem cronológica rs), a ideia é ajudar alguém que esteja querendo aprender sobre algum tema que eu apresentei, rever algum vídeo ou slide de algumas delas e também para eu mesma ter elas concentradas em um só lugar slide e vídeo ( a maioria que o vídeo for público) para consultar algum conteúdo , vamos lá?:

Java Global Summit - Evolution of java: from object orientation to reactive applications with Webflux

Slides: https://speakerdeck.com/kamilahsantos/java-global-summit-evolution-of-java-from-object-orientation-to-reactive-applications-with-webflux

Demo: https://github.com/Kamilahsantos/Spring-Webflux-API-Java-Global-Summit

Jlove Conference - Clean Architecture? Clean Code? Refactoring? Tests? What does this change in my code?

Slides: https://speakerdeck.com/kamilahsantos/jlove-conf-clean-architecture-clean-code-refactoring-tests-what-does-this-change-in-my-code

Demo: https://github.com/Kamilahsantos/jloveconf-cleanarchitecture

Codecon 2020 - o seu código não é só pra você entender

Slides: https://speakerdeck.com/kamilahsantos/codecon-2020-o-seu-codigo-nao-e-so-pra-voce-entender

The Developers Conference Porto Alegre Online - Paradigma reativo? Por dentro da programação reativa com Spring Webflux e Projeto Reactor - Trilha Design de Código e XP

Slides: https://speakerdeck.com/kamilahsantos/thedevconf-2020-paradigma-reativo-por-dentro-da-programacao-reativa-com-spring-webflux-e-projeto-reactor-trilha-design-de-codigo-e-xp

CLOUD-CONFERENCE-DAY - Spring Cloud

Slides: https://speakerdeck.com/kamilahsantos/cloud-conference-day-spring-cloud

[LIVE SOUJAVA] Sistema de recomendação em Java - Kamila Santos

Slides: https://speakerdeck.com/kamilahsantos/02-sistema-de-recomendacao-com-java

Demo: https://github.com/Kamilahsantos/sistema-de-recomendacao-java-mahout

AngularSP Talks #26 Especial mês das Mulheres - RXJS, Lifecycle Hooks e Event Binding de um Angular Diferente

Slides: https://speakerdeck.com/kamilahsantos/angular-sp-rxjs-lifecyclehooks-e-eventbinding-de-um-angular-diferente

Springboot, APIs e carreira em tecnologia com Kamila Santos

Slides: https://speakerdeck.com/kamilahsantos/live-coding-dio-api-de-herois-com-spring-webflux

Demo: https://github.com/Kamilahsantos/Heroes-SpringWebflux-API

{LIVE} WoMakersCode: Java Reativo - Dia 1

{LIVE} WoMakersCode: Java Reativo - Dia 2

Meetup na Ame - 24º Cloud Girls: "The Future is Female" - Sistema de recomendação em Java

Slides: https://speakerdeck.com/kamilahsantos/2020-ia-com-java

Demo: https://github.com/Kamilahsantos/sistema-de-recomendacao-java-mahout

[Online] Nerdgirlz #35 - Desenvolvimento Back End - Junit: melhores práticas para testes unitários nas suas aplicações Java

Slides: https://speakerdeck.com/kamilahsantos/nerdgirlz-junit-melhores-praticas-para-testes-unitarios-nas-suas-aplicacoes-java

Demo: https://github.com/Kamilahsantos/springboot-junit-nerdgirlz-demo

"Design Thinking e a Maratona de Aplicá-lo em Hackathons" - Palestra de Kamila Santos

Slides: https://speakerdeck.com/kamilahsantos/design-thinking-e-a-maratona-de-aplica-lo-em-hackathons-ab771dbd-22d4-4fe9-b4be-01eb8c073ee9

Painel sobre o começo na carreira de Tecnologia

Perifacode + B2W Meetups | Start n' Tech | ONLINE - Back End

TheFemTech e Ame Digital - Primeiros passos na carreira de backend

Slides: https://speakerdeck.com/kamilahsantos/the-femtech-plus-ame-primeiros-passos-na-carreira-de-backend

Demo: https://github.com/Kamilahsantos/Divas-Reactive-App-The-Fem-Tech

Elixir Brasil 2020 - Soft skills

Slides: https://speakerdeck.com/kamilahsantos/elixir-brasil-2020-soft-skills

Women Tech Makers Rio de Janeiro - O seu código não é só para você entender

Slides: https://speakerdeck.com/kamilahsantos/2020-fda7d87e-755d-4147-8def-5fe878763572

The Dev Conf Floripa - Melhorando a performance e legibilidade de aplicações Java com Spring Web Flux

Slides: https://speakerdeck.com/kamilahsantos/tdc-floripa-melhorando-a-performance-e-legibilidade-de-aplicacoes-java-com-spring-web-flux

Demo: https://github.com/Kamilahsantos/thedevconf-demo-SpringWebFlux-SuperHeroesApi

Jornada Java Summit: Java: da orientação a objetos a aplicações web reativas

https://speakerdeck.com/kamilahsantos/jornada-java-java-da-orientacao-a-objetos-a-aplicacoes-web-reativas

Demo: https://github.com/Kamilahsantos/thedevconf-demo-SpringWebFlux-SuperHeroesApi

GUOB Tech Day - SPRING WEBFLUX

Slides: https://speakerdeck.com/kamilahsantos/guob-tech-day-spring-webflux

Para inserir os vídeos dentro do artigo utilizei essa ferramenta: http://embedyoutube.org/

Até a próxima :)

Hacktoberfest : conheça os projetos open-source da WoMakersCode

Kamila Santos Oliveira — Wed, 14 Oct 2020 13:14:34 +0000

Todos os anos, no mês de outubro ocorre a Hacktoberfest, um evento que visa engajar mais pessoas a contribuirem para o open-source (para participar basta se cadastrar no link deles acima), e nós da WomakersCode não iríamos ficar fora dessa!

Temos diversos repositórios públicos e abertos para contribuição no nosso Github, com conteúdos sobre Workshops, tutoriais, dentre outros. Queremos que cada vez mais mulheres aprendam com esse conteúdo e você pode ajudar elas e ainda enriquecer seu currículo contribuindo com opensource.

Não conhece muito sobre Git e Github? temos uma série de posts aqui sobre isso!

A seguir a lista de projetos abertos para contribuição:

Guia de git e github: https://github.com/WoMakersCode/git-e-github

Curso de banco de dados: https://github.com/WoMakersCode/banco-de-dados

Workshop de Pwa: https://github.com/WoMakersCode/pwa-workshop

Desafios de backend: https://github.com/WoMakersCode/challenges-back-end

Desafios de frontend: https://github.com/WoMakersCode/challenges-front-end

Desafios de lógica/algoritmos: https://github.com/WoMakersCode/challenges-algorithms

React-bootcamp: https://github.com/WoMakersCode/react-bootcamp

Em cada repositório temos uma lista de issues disponíveis e uma guia de contribuição, qualquer dúvida podem entrar em contato conosco!!

Vamos juntas!

Spring Webflux - Reactive Java Applications - Part 2

Kamila Santos Oliveira — Wed, 29 Jul 2020 05:19:32 +0000

In part 1 we talk about some concepts used in reactive programming, now, in part 2 we will understand the reason for Webflux was created and how its architecture works :)

What is Spring WebFlux?

Spring WebFlux can be defined as a “parallel” version to the already known and widely used Spring MVC, with the main difference being the support for reactive NIO streams and for supporting the concept of backpressure and with Netty server coming by default embedded in its architecture.

Since version 5.0 of the Spring Framework we have a reactive part in addition to the Servlet structure that already existed, each module of these is optional, you can use the Servlet part to reactive part or even both in your applications.

This can be best exemplified through the image below:

Webflux is in the "reactive part" of the stack, where:

instead of servlet we work with Netty / Undertow as a server;
We do not use the Servlet API (which is blocking) and we use Reactive Streams;
we started using router functions instead of @Controller

It is important to note that we can use only one or even both architectures, using the best of both.

Spring Webflux was developed due to the need for non-blocking applications that were able to work with a small number of threads simultaneously and that could be run with a few hardware resources.

In Servlet 3.1 an NIO API was provided, but its use does not match the rest of the API and all the concepts behind Servlet, which has blocking contracts like getPart and getParameter for example and their contracts were defined in a way synchronous using Filter and Servlet as an example.

These factors were decisive for the development of a new API that would be used independently of the execution time and in a non-blocking way, which was possible with the servers that consolidated themselves in the asynchronous and non-blocking operation, for example Netty.

Another reason is that WebFlux makes it easier to understand and use functional / reactive programming concepts. With the addition of functional features from Java 8 (such as lambda expressions, streams, Optional ...). In terms of style / programming model, Java 8 allowed Spring WebFlux to have functional endpoints and annotated controllers in the applications.

How does it work?

In the MVC model, requests work as follows:

The client makes a request, which is received by TomCat and controlled by the thread pool, this is passed on to the Dispatcher Servlet that dispatches that request to the corresponding endpoint in RequestMapping, which will be received at the Controller, which will handle the service and by end will return a response. This whole process occurs in a blocking way, that is, another request will only enter when the previous one is completed.

In Webflux, this would be a little different:

The client makes the request that goes to our non-blocking server (Netty), which inside it has an event loop that manages these requests, then it passes to the reactor-netty (which makes this interface reactive with the application), it passes to the dispatcher handler, which through functionals endpoints will generate this response, and, throughout this process, new requests can be made, as it is a non-blocking architecture.

We can say that Spring WebFlux uses the best of the servlet stack along with its reactive features, as we can see in the image below the documentation of the Spring:

On the MVC side we have imperative programming, JDBC / JPA and other blocking dependencies / processes.

On the Spring Webflux side, we have funcitonal endpoints, event loop, Netty and some features that already existed in MVC but who in Webflux started to have greater support, such as Reactive Clients.

This article introduced the reason for creating WebFlux and its differences from MVC, in the next article we will talk about Project Reactor!

Thanks,

Spring Webflux - Reactive Java Applications - Part 1

Kamila Santos Oliveira — Wed, 18 Mar 2020 13:36:57 +0000

In recent times reactive programming has been expanding more and more, it is already being addressed by several languages, but in Java is it something new for you? Then this series of articles is for you!

In this series of articles I will address issues such as reactive programming, Spring Webflux, Project Reactor and Netty.

In this first I will cover some general concepts before delving into each one of them, here we go:

The Problem:

We expect our applications to be scalable, we need to use resources more and more efficiently, latency time must be minimal, we need quick responses to our requests, we handle competing requests (each thread consumes a little memory), traditional APIs work in a synchronous and blocking way.

To solve this, we had the creation of Callbacks and Futures:
Callbacks are not easy to read and difficult to maintain, they are complex (they can form a hell callback), through which it is not possible to return any value.

Future: returns an instance of the future type and it is difficult to scale for multiple asynchronous operations, as an alternative, from Java 8 came the Completable Future that supports functional and easy programming the use of multiple asynchronous operations, however, as nothing is perfect , is not a good option for asynchronous calls with multiple items.

Alternative way to develop APIs

Asynchronous and non-blocking
Outside the on-demand thread model
Decreases the number of threads created

And there comes reactive programming, ok, but what is different about it?

asynchronous and non-blocking
Data flow as an event / message driven flow
Code maintains functional programming style.
BackPressure in data streams

Let us turn more attention to the data flow part:

The data can come from databases, external files, integrated services, other applications, etc. For each item of this data source, we have an event or message that is triggered, after the execution of that event / message, we have an error message or that it was complete.
For a request to save data for example, we have an onNext(Product) event:

List <Product> products= productRepository.getAllProducts();

When we call data from a database for example, the call returns and for each item an onNext(Product) is launched and when we finish the listing we have an onComplete() event to inform that our request has ended.

What if our request has an error?
Instead of returning the onComplete() event, we will have the OnError() event and we will not have the expected content.

Reactive Stream Specification

is a set of specifications for the use of streams, created by companies like Pivotal and Netflix, among these specifications, we have:

Publishers: The Publisher interface is a provider of an unlimited number of elements in a sequential manner and publishes them according to the demand it receives from its Subscribers (I will explain what is next). The same publisher can serve several Subscribers dynamically at different times. Publishers are our data sources.

public interface Publisher<T>{ public void subscribe (Subscriber<? super T> s); }

Subscriber: You only receive a call to OnSubscribe after you pass an instance of Subscriber to Publisher.subscribe (Subscriber). No notification will be received until Subscription.request (long) is called. After the call is initiated: One or more onNext(Object) calls are launched until the maximum number defined by Subscription.request(long) is reached. A single onError(Throwable) error call or complete onComplete() request. This demand can be signaled through Subscription.request(long) whenever the Subscriber instance can handle more.

public interface Subscriber<T>{ public void onSubscribe(Subscription s); public void onNext (T t); public void onError(Throwable t); public void onComplete(); }

And the Subscription:

public interface Subscription{ public void request (long n); public void cancel (); }

Processor: It represents a processing step, which is both a Subscriber and a Publisher that accepts both standards.

public interface Processor <T,R> extends Subscriber <T>,Publisher <R>{ }

being that :
T- type of element that is signaled to the Subscriber.
R- type of element that is signaled to Publisher.

This was the first part of the series of articles, in which we talked about some points and advantages of reactive programming, in the next I will address the reasons that led to the creation of Webflux and its differences from Spring MVC
Questions or feedbacks?

Below are some interesting references and content on this subject:

Reactive Manifest

Reactive Streams

WebFlux Course

Image from: https://docs.spring.io/spring-framework/docs/5.0.0.M1/spring-framework-reference/html/images/web-reactive-overview.png

See you in the next articles!

Do you have a minute or two to talk about Code Smells? - Part 1

Kamila Santos Oliveira — Sun, 15 Mar 2020 08:15:01 +0000

Hello, you probably have already studied a lot about what are good programming practices, in this series of articles I will explain in more detail what NOT to DO in software development, explaining what are some Code Smells that maybe most of the developers people have ever done in your life.

First of all, what are Code Smells?

They are symptoms of superficial errors of a deeper problem in your code, you can see a more complete definition in this article by Martin Fowler: Code Smells

This series of articles will demonstrate some Code Smells that can occur in different programming languages and give some tips on how to solve them.
In this first article I'm going to talk about Code Smell's Bloaters:

Bloaters are codes, methods and classes that over time have taken on gigantic proportions that make the system difficult to maintain and scale. We usually only notice this type of smells when the system grows and makes a change or adds a new feature. These are the codes that are written “in the wrong way”, and become a technical debt that, over time, only increases.

The first example of a Code Smell of the Bloater type is Data Clumps (Grouping of all):

Often different parts of code contain identical groups of variables (configuration parameters, access routes, etc.), ideally these groups should be transformed into classes to be accessed without repeating these same parameters in various parts of the code.

It usually occurs due to the lack of a modularized structure and frequent “copy and paste” throughout development.

How to fix this problem?

Here are some suggestions of what to do in these cases:

Realize Preserve Whole Object (when we have several values of an object and pass it as a parameter to a method, we can pass it as an object containing this data, more details about this technique at: Preserve Whole Object.

Apply Introduce Parameter Object (when your methods contain a group of repeated parameters, we can replace it with an object, somewhat similar to the previous one, more details at:Introduce parameter object .

If the repetition of these fields makes sense to be in a separate class to access this data through ** Extract Class ** (when one class is doing the work of two, it is not following the principle of single responsibility (SRP), we can extract these methods for a new class and insert all the methods and fields related to its functionality, more details at: Extract class.

This was a type of Code Smell, in the next articles I will address others, here are some references I used and study tips on the subject:

Preserve Whole Object

Introduce Parameter Object

Introduce Parameter Object
https://refactoring.guru/extract-class

Extract Class

Solid Principles

SOLID

Spring Webflux - Aplicações reativas em Java - Parte 1

Kamila Santos Oliveira — Sun, 15 Mar 2020 06:41:34 +0000

Nos últimos tempos a programação reativa tem se expandido cada vez mais,já está sendo abordada por diversas linguagens, mas em Java é algo novo para você? Então essa série de artigos é para você!

Nesta série de artigos irei abordar assuntos como programação reativa, Spring Webflux, Projeto Reactor e Netty.

Neste primeiro vou abordar alguns conceitos gerais antes de me aprofundar em cada um deles, vamos lá :)

O problema:

Esperamos que nossas aplicações sejam escaláveis, precisamos usar os recursos de forma cada vez mais eficiente, o tempo de latência deve ser mínimo, precisamos de respostas rápidas à nossas solicitações, lidamos com solicitações concorrentes (cada thread consome um pouco de memória), APIs tradicionais funcionam de modo síncrono e bloqueante.

Para solucionar isso, tivemos o surgimento dos Callbacks e dos Futures:
Callbacks não tem uma leitura fácil e manutenção dificil, são complexos (podem formar um callback hell), por meio deles não é possível retornar nenhum valor.

Future: retorna uma instância do tipo future e é dificil de escalar para múltiplas operações assíncronas,como alternativa, a partir do Java 8 surgiu o Completable Future que suporta a programação funcional e facílita o uso de múltiplas operações assíncronas, porém, como nada é perfeito, não é uma boa opção para chamadas assíncronas com multiplos items.

Forma alternativa de desenvolver APIs

Assíncrona e não bloqueante
Fora do modelo de thread por solicitação
Diminui o número de threads criadas

E ai entra a programação reativa, ok, mas o que ela tem de diferente?

assíncrona e não bloqueante
Fluxo de dados como um fluxo orientado a eventos/mensagens
Código mantém estilo da programação funcional.
BackPressure nos Streams de dados

Voltemos uma atenção maior para a parte de fluxo de dados:
Os dados podem vir de banco de dados, arquivos externos, serviços integrados, outras aplicações, etc, para cada item dessa fonte de dados, temos um evento ou mensagem que é disparado, após a execução desse evento/mensagem, temos uma mensagem de erro ou de que foi completa.
Para um requisição para salvar dados por exemplo,temos um evento de onNext(Product):

List <Product> products= productRepository.getAllProducts();

Quando chamamos os dados de uma banco de dados por exemplo,a chamada retorna e para cada item é lançado um onNext(Product) e ao terminarmos a listagem temos um evento de onComplete() para informar que nossa requisição terminou.

E se a nossa requisição tiver algum erro?
Em vez de retornar o evento onComplete() teremos o evento de OnError() e nao teremos o conteúdo esperado.

Reactive Stream Specification

Consiste de um conjunto de especificações para utilização de streams, criada por empresas como Pivotal e Netflix, dentre essas especificações, temos:

Publishers: A interface Publisher,é um provedor de um número ilimitado de elementos de forma sequencial e os publica de acordo com a demanda que recebe dos seus Subscribers (explicarei o que é a seguir). Um mesmo publisher pode atender a diversos Subscribers dinamicamente em diversos momentos. Os publishers são as nossas fontes de dados.

public interface Publisher<T>{ public void subscribe (Subscriber<? super T> s); }

Subscriber: Recebe somente uma chamada para o OnSubscribe, depois que passar uma instância do Subscriber para Publisher.subscribe(Subscriber). Nenhuma notificação será recebida até que Subscription.request(long) seja chamado. Depois que a chamada for iniciada: Uma ou mais chamadas do onNext(Object) são lançadas até que o número máximo definido por Subscription.request (long) seja atingido. Uma única chamada de erro onError(Throwable) ou de que foi completa a requisição onComplete(). Essa demanda pode ser sinalizada através da Subscription.request (long) sempre que a instância do Subscriber puder lidar com mais.

public interface Subscriber<T>{ public void onSubscribe(Subscription s); public void onNext (T t); public void onError(Throwable t); public void onComplete(); }

E a Subscription:

public interface Subscription{ public void request (long n); public void cancel (); }

Processor: Representa uma etapa de processamento, que é tanto um Subscriber quanto um Publisher que aceita as normas de ambos.

public interface Processor <T,R> extends Subscriber <T>,Publisher <R>{ }

sendo que :
T- tipo de elemento que é sinalizado para o Subscriber.
R- tipo de elemento que é sinalizado para o Publisher.

Esta foi a primeira parte da série de artigos, na qual falamos sobre alguns pontos e vantagens da programação reativa, no pŕoximo irei abordar os motivos que levaram à criação do Webflux e suas diferenças do Spring MVC

Dúvidas ou feedbacks?

Segue abaixo algumas referências e conteúdos interessantes sobre esse assunto:

Manifesto Reativo

Streams Reativos

Curso de WebFlux

Até a próxima!

TDD em Nodejs : conhecendo o Jest

Kamila Santos Oliveira — Wed, 05 Feb 2020 20:15:50 +0000

Neste artigo, irei dar uma introdução ao TDD com os testes feitos em Jest e aplicá-los na fase inicial da construção de uma aplicação com Koa.js.
Primeiramente, o que é TDD?
No TDD, escrevemos os testes e desenvolvemos o código para que ele passe neste teste, ele se divide em três etapas:
Vermelho : o teste vai falhar, porque não temos nenhuma lógica construída só as suítes e casos de teste.
Verde: escreve o código para que passe no teste, baseada na descrição e no resultado esperado em cada um dos testes.
Roxa (refatora): melhore o código que já passou nos testes, eliminando redundâncias e duplas responsabilidades em suas funcionalidades.

Como adotar o TDD em um projeto?

Os testes devem ser feitos de modo unitário, testando cada funcionalidade separadamente, como são executados automaticamente, não precisamos ficar abrindo a aplicação e testar manualmente cada uma dessas funcionalidades.
Em testes manuais, deveríamos subir nossa aplicação e realizar cada caso de teste “na mão” e evidenciar cada resultado, em testes automáticos ele irá subir a aplicação, executar cada testes, exibir o resultado esperado e o que foi obtido SOZINHO.

Vantagens de adotar o TDD?

Qualidade de código
Se um código não pode ser testado por uma máquina, talvez ele não esteja tão “limpo” e bem estruturado assim.
Raciocínio
Sabendo exatamente o que esperar de cada parte do seu código, você já desenvolve focado na responsabilidade de cada parte dele e inserindo o resultado que é exatamente esperado. Segurança
Em casos emergenciais, é possível em alguns casos recorrer aos testes para ver o que cada funcionalidade faz e executar a manutenção de forma mais rápida, sem ter que analisar o código inteiro. -Trabalho em equipe
A integração de novos membros na equipe é facilitada pelo uso de testes bem documentados para conhecer o seu sistema.
Documentação
Fazendo os testes antes do código, sempre que for lançada uma nova funcionalidade, ela já estará documentada antes de ser laçada, pelo método “convencional”, quando se faz a documentação após a conclusão da última versão da sua aplicação, temos o grande risco de esquecer de documentar algo e não terminar esta documentação até o lançamento na nova versão.

O que vamos utilizar neste exemplo?

Node.js

Pode ser descrito como o javascript server-side , trabalha de forma assíncrona, não bloqueante, orientado a eventos (fluxo é controlado por ações/requsições externas) e open-source.
Ideal para aplicações real-time

KOA.js

Desenvolvido pela equipe do Express, é uma versão “menor’ e com mais funcionalidades para aplicativos web e APIs, com suas funções assíncronas, pode eliminar retornos de chamadas e facilitar o tratamento dos erros. Por não usar middlewares em várias partes do código, torna os servidores mais rápidos e com código mais limpo.

Jest

Criado pelo facebook, pode ser usado em Node, Javascript puro, React, Angular, Vue e outros frameworks.
É bem completo, rápido e precisa de pouca configuração para usar, quando os testes não passam, fornece um contexto rico do porque falhou.
Dependências a serem utilizadas na escrita dos testes:

Configuração dos testes

npm install   jest --save-dev

será responsável por configurar e executar nossos testes

npm install supertest --save-dev

o supertest nos fornece uma melhor abstração e compreensão do resultado e execução dos testes. agora escrevemos os testes.

Crie uma pasta tests nesta pasta irão nossas suítes de teste que o Jest irá executar, crie um arquivo routes.test.js com o seguinte conteúdo:

//importa os módulos e aqruivos necessários
const request = require('supertest');
const server = require('../app.js');
const sayTDD = require('../helloJest');

//o que será executado antes de todos os testes
beforeAll(async () => {
   console.log('Iniciando TDD com jest!');
});

//o que será executado após todos os testes
afterAll(() => {
   //o server close irá encerrar nossa aplicação, evitando problemas da porta já estar em uso
server.close();
console.log('servidor fechado');
});


describe('inicio dos testes', () => {
   //descrição do caso de testes
   test('acessa a rota da home e verifica o conteúdo que é exibido ', async () => {
      //qual a rota que ele deve acessar e qual requisição deve fazer
      const response = await request(server).get('/');
      //qual o status esperado 
      expect(response.status).toEqual(200);
      //se todos esses passos passarem, verifica o conteúdo exibido dentro desta rota
      expect(response.text).toContain('<h1>Você está na Home!</h1> <p> vamos começar os testes </p>');

   });

   test('acessa a rota /tdd e então será apresentada a seguinte defiição de tdd:', async () => {
      const response = await request(server).get('/TDD');
      expect(response.status).toEqual(200);
      expect(response.text).toContain('<h4>no tdd primeiro fazemos os testes e depois desenvolvemos o sistema para que ele passe nos testes</h4>');
   });

   test('acessa a rota /koa e então será apresentada a seguinte definição de Koa.js', async () => {
      const response = await request(server).get('/KOA');
      expect(response.status).toEqual(200);
      expect(response.text).toContain('<h4>O Koa é uma nova estrutura da Web criada pela equipe do Express, que pretende ser uma base menor, mais expressiva e mais robusta para aplicativos da Web e APIs</h4>');

   });
   //aqui não iremos testar uma rota e sim o retorno de uma função.
   test('irá verificar o retorno da função saytdd', () => {
      //é esperado que o retorno da função saytdd seja:
      expect(sayTDD()).toMatch('TDD é o Desenvolvimento Orientado por Testes');
   });

Testes modelados, agora vamos instalar as dependências necessárias para iniciarmos nosso desenvolvimento:

dependências da aplicação

npm install koa

vai gerenciar a nossa parte de rotas e requisições

npm install nodemon -g

quando se sobe a aplicação sem ser nos testes, o nodemon garante que toda alteração salva vai ser atualizada em tempo real na nossa aplicação sem necessitar parar o servidor e subir de novo para ver a alteração

npm install koa-logger

nos fornece um status detalhado do que acontece na nossa aplicação, qual a rota acessada, o status obtido, o tempo de resposta e quantos dados foram transmitidos.

 npm install koa-router

faz o direcionamento das rotas

Criamos o arquivo app.js que será nosso servidor para que passe nos nossos testes:

//esse arquivo é o nosso servidor
const Koa = require('koa');
const Router = require('koa-router');
const logger = require('koa-logger');
//iniciamos uma nova aplicação Koa
const app = new Koa();
//iniciamos as rotas
const router = new Router();

//habilitamos o uso do Koa Logger
app.use(logger());

//faz um get na rota home, o ctx é um espécie de método acessor que pega o contexto de uma parte do código e o next informa ao 
//middleware que após terminar esa operação pode ir para a próxima requisição de forma não bloqueante
router.get('/', (ctx, next) => {
    ctx.body = '<h1>Você está na Home!</h1> <p> vamos começar os testes </p>';
});

router.get('/TDD', (ctx, next) => {
    ctx.body = '<h4>no tdd primeiro fazemos os testes e depois desenvolvemos o sistema para que ele passe nos testes</h4>';
   });

router.get('/KOA', (ctx, next) => {
    ctx.body = '<h4>O Koa é uma nova estrutura da Web criada pela equipe do Express, que pretende ser uma base menor, mais expressiva e mais robusta para aplicativos da Web e APIs</h4>';
   });
//cria as rotas
app.use(router.routes());
//permite todos os tipos de requisição,get,post,put,delete
app.use(router.allowedMethods());
//cria o servidor para rodar na porta 3000
const server = app.listen(3000);
//exporta o server para que seja possivel acessá-lo em outras partes do programa
module.exports = server;

O último caso de testes, era sobre retorno de uma função, vamos criá-la em um arquivo helloJest.js à parte do nosso server

function sayTDD(){
    //criamos a função com exatamente o retorno que foi descrito nos testes
    return 'TDD é o Desenvolvimento Orientado por Testes'
}
module.exports = sayTDD;

Antes de executarmos os testes, verifique se o seu package.json está semelhante à este:

{
  "name": "koatesting",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "jest --watchAll",
    "dev": " nodemon app.js "
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "koa": "^2.7.0",
    "koa-logger": "^3.2.0",
    "koa-router": "^7.4.0"
  },
  "devDependencies": {
    "jest": "^24.1.0",
    "supertest": "^3.4.2"
  }
}

Algumas observações:

Caso tenha algum erro com porta em uso, execute o seguinte comando no seu prompt como administrador:

taskkill /F /IM node.exe

para instalar as dependências

npm install

para rodar no modo de desenvolvimento:

npm run dev

para executar os testes (jest):

npm run test

plugin para o vscode para facilitar a visualização dos resultados do teste, eu indico o plugin Jest Test Explorer

Agora é só executar

npm run test

dentro da pasta da aplicação e ver os testes passando com sucesso, experimente fazer algo errado mo código para ver como é apresentado o erro no teste (com o jest — watchAll, toda alteração salva já é testada automaticamente, não precisa executar este comando a cada alteração).

http://blog.sciensa.com/tdd-test-driven-development-guia-rapido/
http://nodebr.com/o-que-e-node-js/
https://koajs.com/#introduction
https://jestjs.io/pt-BR/
http://tdd.caelum.com.br/
https://treinamento.nodebr.org/
https://github.com/koajs/logger
https://github.com/ZijianHe/koa-router
https://github.com/koajs/workshop
https://jestjs.io/
https://github.com/facebook/jest

WoMakersCode oferece curso de programação gratuito para mulheres

Kamila Santos Oliveira — Mon, 06 Jan 2020 21:53:49 +0000

O mercado de tecnologia possui mais de 160 mil postos de trabalho no Brasil, oferecendo oportunidades em diversas áreas, como Cloud Computing, Inteligência Artificial e Desenvolvimento de Software, mas ainda há uma grande desigualdade entre homens e mulheres na ocupação de vagas do setor. De acordo com a pesquisa “Quem Coda o Brasil”, realizado pelo coletivo Preta Lab, 21% das equipes não possuem nenhuma mulher no time.

A capacitação de mulheres é de extrema importância para aumentar a diversidade nas empresas e fomentar a inovação tecnológica. Pensando em acelerar a formação de mulheres na área de programação, a WoMakersCode, em parceria com a Fundação 1Bi e Stone, lançou o React Bootcamp em São Paulo.

O React Bootcamp irá começar no dia 01 de Fevereiro e você tem até o dia 19 de Janeiro para realizar a sua inscrição. Este é um curso totalmente gratuito, com mais de 40 horas de formação, para todas as pessoas que se identificam como mulheres e que tenham conhecimentos básicos em HTML, CSS e JavaScript.

O React é uma lib que vem se tornando cada vez mais popular no mercado de tecnologia, é uma lib com uma curva de aprendizado pequena, possui uma API de fácil manipulação e utiliza Javascript puro, não há a necessidade de aprender nenhuma sintaxe específica, durante o desenvolvimento utilizando React temos contato com conceitos como programação declarativa, programação funcional e imutabilidade.

Aprendendo React fica bem mais fácil aprender React Native, que é uma tecnologia para desenvolvimento de aplicativos mobile, ampliando mais ainda suas possibilidades no mercado de trabalho.
Quanto à suporte e comunidade, ele foi criado pelo Facebook e possui uma ampla comunidade ativa sempre desenvolvendo novas features e resolvendo eventuais problemas.É utilizada por grandes empresas, como LivUp, Nubank, Boticário, C6 Bank, entre outras.

Durante o bootcamp, as alunas irão aprender sobre:

-Revisão de Fundamentos de Desenvolvimento para Web e Lógica de Programação
-Boas práticas em criação de projetos web
-Trabalhando com ecossistema NPM & Node
-Promises, protocolo HTTP e Requisições
-Introdução ao ecossistema React & estruturação de projetos
-Trabalhando com APIs

Ao final, as alunas irão desenvolver projetos e terão a oportunidade de participar de uma feira de carreiras. Os projetos de conclusão do curso serão especiais, pois irão ajudar ONGs, projetos sociais e empreendedoras, previamente selecionados pela coordenação do curso.

Como participar:

As interessadas, deverão realizar a sua inscrição no portal da WoMakersCode (https://womakerscode.org/react-bootcamp) e realizar um teste de conhecimentos prévios até o dia 19 de Janeiro. Depois do encerramento das inscrições, as candidatas que forem pré-selecionadas serão chamadas para entrevistas online e no dia 27 de Janeiro, o resultado da seleção será anunciado.

Você tem um minuto ou dois, para falar de Code Smells? — Parte 1

Kamila Santos Oliveira — Sat, 16 Nov 2019 18:39:45 +0000

Olar, provavelmente você já tenha estudado muito sobre o que são boas práticas de programação, nesta série de artigos irei explicar de forma mais detalhada o que NÃO FAZER no desenvolvimento de software, explicando o que são alguns Code Smells que talvez grande parte das pessoas desenvolvedoras já tenha feito alguma vez na vida.

Primeiramente, o que são Code Smells?

São sintomas de erros superficiais de um problema mais profundo no seu código, você pode ver uma definição mais completa neste artigo do Martin Fowler: https://martinfowler.com/bliki/CodeSmell.html

Esta série de artigos irá demonstrar alguns Code Smells que podem ocorrer em diversas linguagens de programação e dar umas dicas de como resolvê-los.
Neste primeiro artigo vou falar do tipo Bloaters do Code Smell:

Bloaters são códigos,métodos e classes que com o decorrer do tempo tomaram proporções gigantescas que dificultam o sistema de ser manutenível e escalável. Geralmente só percebemos esse tipo de smells quando o sistema cresce e fazer uma alteração ou adicionar uma nova feature. São aqueles códigos que são escritos “da forma errada”, e viram um débito técnico que, com o decorrer do tempo só aumenta.

O primeiro exemplo de Code Smell do tipo Bloater é o Data Clumps (Agrupamento de todos):

Muitas vezes partes diferentes de código contém grupos idênticos de variáveis (parâmetros de configurações, rotas de acesso, etc), o ideal é que esses grupos sejam transformados classes para serem acessados sem a repetição desses mesmos parâmetros em várias partes do código.

Geralmente ocorre pela falta de uma estrutura modularizada e frequentes “copy and paste” ao longo do desenvolvimento.

Como corrigir esse problema?

Aqui algumas sugestões do que fazer nesses casos:

Realizar Preserve Whole Object (quando temos vários valores de um objeto e o passamos como parâmetro para um método, podemos passá-lo como um objeto contendo esses dados, mais detalhes sobre essa técnica em: https://refactoring.guru/preserve-whole-object).

Aplicar Introduce Parameter Object (quando seus métodos contêm um grupo de parâmetros repetidos,podemos substituir ele por um objeto, um pouco semelhante ao anterior, mais detalhes em: https://refactoring.guru/introduce-parameter-object).

Se a repetição desses campos fazer sentido estar em uma classe separada para acesso a esses dados através de Extract Class (quando uma classe está fazendo o trabalho de duas, não está seguindo o princípio da responsabilidade única (SRP),podemos extrair esses métodos para uma nova classe e inserir todos os métodos e campos referentes a sua funcionalidade, mais detalhes em: https://refactoring.guru/extract-class).

Esse foi um tipo de Code Smell, nos próximos artigos irei abordar outros, segue algumas referências que utilizei e dicas de estudo sobre o assunto:

https://martinfowler.com/bliki/CodeSmell.html

https://refactoring.guru/refactoring/smells/bloaters

https://refactoring.guru/smells/data-clumps

https://martinfowler.com/bliki/DataClump.html

https://refactoring.guru/preserve-whole-object

https://refactoring.com/catalog/preserveWholeObject.html

https://refactoring.guru/introduce-parameter-object

https://refactoring.com/catalog/introduceParameterObject.html

https://refactoring.guru/extract-class

https://scrutinizer-ci.com/docs/refactorings/extract-class

https://refactoring.com/catalog/extractClass.html