Um medo de toda equipe é escolher uma ferramenta que se tornará obsoleta rápido. Caso você esteja desenvolvendo aplicações há alguns anos, possivelmente já vivenciou isso. Por isso, a escolha de boas ferramentas é uma tarefa que envolve responsabilidade, pois pode guiar o projeto (e a empresa) para o sucesso ou para um mar de problemas e gastos. Neste artigo, vamos entender os usos e benefícios do framework Angular. Escolher um framework front-end não é diferente e também envolve pesquisas e estudos. A escolha de uma “stack”, como chamamos nesse mundo, é trivial tanto para o presente mas também para o futuro. No entanto, algumas perguntas irão surgir no meio dessa escolha:  Encontraremos profissionais capacitados para lidar com esse framework?  Conseguiremos manter um ritmo de atualizações?  Há um plano bem definido para a direção que o framework está indo?  Há uma comunidade (entendemos aqui também por grandes empresas apoiando) engajada?  Todas essas perguntas devem ser respondidas antes de começar qualquer projeto, pois negligenciar uma telas pode levar a cenários devastadores para o produto, e consequentemente para a empresa e seus lucros.  Motivações para se usar um framework  A resposta talvez mais direta seja que as vezes é bom não ficar reinventando a roda. Problemas rotineiros como lidar com rotas de uma aplicação web, ou mesmo o controle de dependências, geração do bundle otimizado para publicação em produção, todas essas tarefas já tem boas soluções desenvolvidas, e, por isso, escolher um framework que te entrega esse conjunto de ferramentas é perfeito para ganhar produtividade, solidez no desenvolvimento de uma aplicação e também manter a mesma sempre atualizada seguindo as melhores práticas.  Bem como as motivações diretas, posso citar também:  A facilidade de encontrar ferramentas que se integram com o framework  A busca por um software com qualidade, integrado a testes e outras ferramentas que irão tornar o processo de desenvolvimento maduro  Muitas situações e problemas já resolvidos (porque há muita gente trabalhando com a tecnologia)  Motivações para o uso do framework do Angular:  Construído usando Typescript, uma das linguagens mais populares do momento  Arquitetura MVC  Controle e Injeção de dependências  Modularização (com opção de carregamento lazy load)  Boas bibliotecas para integração  Comunidade grande e engajada  1835 contribuidores no repositório oficial  Oficialmente apoiada e mantida pelo time do Google  A solidez do Angular  Atualmente, podemos afirmar com clareza que o framework é estável, recebendo atualizações frequentes por sua natureza fundada no open-source. Isso porque é mantido pelo time do Google, que procura sempre deixar o roadmap do que está por vir o mais claro possível, o que é muito bom. Além disso, a comunidade Angular é bastante ativa e engajada. É difícil você ter um problema que já não foi resolvido.  Uma das preocupações de todo desenvolvedor é em relação a mudanças drásticas de uma ferramenta. Quem viveu a época da mudança da V1 para V2 do Angular sabe essa dor, praticamente a mudança foi total. Porém, o framework de forma correta se fundou com base no Typescript que trouxe robustez e mais um motivo para sua adoção: com o Typescript, temos possibilidades que o Javascript sozinho não consegue resolver: tipagem forte, integração com o IDE facilitando a vida dos desenvolvedores, reconhecimento de erros em tempo de desenvolvimento, e muito mais.  Atualmente, o framework está na versão 17 e vem ganhando cada vez mais maturidade e solidez, com o incremento de funcionalidades inovadoras como defer lançada recentemente.  Upgrade facilitado  O framework fornece um guideline para todo upgrade através do site https://update.angular.io, esse recurso ajuda muito a guiar a atualização do seu projeto.  CLI completo  O Angular é um framework. Logo, ao instalar seu pacote teremos o CLI pronto para inicializar novos projetos, gerar componentes, executar testes, gerar o pacote final e manter as atualizações da sua aplicação:  Para criar seu primeiro projeto, basta abrir o seu terminal, e rodar o comando a seguir:  Sólidos projetos de interface  Se você precisa de um design para sua aplicação que fornece componentes já prontos para uso como alertas, janelas de modal, avisos snackbar, tabelas, cards, uma das possibilidades mais populares é a escolha do Material Angular, um bom ponto para seguir o seu software com ele é porque é mantido pelo Google, logo sempre que o framework avança em versão o Material usualmente acompanha essa atualização.  Além do Material, existem outras opções na comunidade, como o PrimeNG, que trás um conjunto muito interessante (e grande) de componentes.  Suporte a biblioteca Nx  O Angular possui suporte completo ao projeto Nx, que possibilita escalar seu projeto de forma bastante consistente, garantindo principalmente cache e possibilidades avançadas para você manter e escalar sua aplicação local ou no seu ambiente de CI.  Aqui estão alguns exemplos específicos de como o Nx pode ser usado para melhorar um projeto Angular:  Você pode criar uma biblioteca Angular que pode ser reutilizada em vários projetos.  Você pode criar um monorepo que contenha todos os seus projetos Angular, o que facilita a colaboração entre equipes.  Você pode automatizar tarefas de desenvolvimento comuns, como a execução de testes e a implantação de seus projetos.  Testes (unitários e E2E)  Além do Karma e o Protactor que nasceram com o framework, agora você é livre para usar projetos populares como Jest, Vitest e Cypress.  State com Redux  Uma das bibliotecas mais utilizadas pela comunidade é a NgRx Store, que fornece gerenciamento de estado reativo para aplicativos Angular inspirados em Redux.  GDEs brasileiros  No Brasil temos atualmente dois GDEs Angular, o que é importante para nosso país e também para geração de conteúdo Angular em português, trazendo para nossa comunidade novidades e insights sempre atualizados direto do time do Google.  Loiane Gronner William Grasel Alvaro Camillo Neto Grandes empresas utilizando e apoiando  Talvez a mais notória seja o Google, mantenedor oficial do framework. A empresa possui diversos produtos construídos usando Angular e nos últimos anos vem apoiando ainda mais o desenvolvimento e evolução da ferramenta.  Um ponto importante ao escolher um framework é saber que grandes empresas estão utilizando, isso porque nos dá um sinal de que aquela ferramenta terá apoio para atualizações e evolução já que ninguém gosta de ficar reescrevendo produtos do zero, aqui vou citar algumas empresas globais que usam Angular em seus produtos, sites, serviços para a web:  Google  Firebase  Microsoft  Mercedes Benz  Santander  Dell  Siemens  Epic  Blizzard’s  No cenário nacional também temos exemplos de grandes empresas utilizando o framework com sucesso, podemos citar algumas:  Unimed Cacau Show  Americanas  Checklist Fácil  Picpay  Quer saber mais? Se interessou em começar com Angular? Acesse https://angular.dev/, a mais nova documentação do framework que trás tutoriais, playground e uma boa documentação bem explicada.  Bom código! 

O que é um Modelo Arquitetural e qual a sua importância?  Basicamente, um modelo arquitetural é a estrutura abstrata sobre a qual sua aplicação será implementada.  "A arquitetura de software de um programa ou sistema computacional é a estrutura ou estruturas do sistema que abrange os componentes de software, as propriedades externamente visíveis desses componentes e as relações entre eles.” (Bass, Clements, & Kasman, Software Architecture in Practice)  Para definir o modelo que mais irá se adequar ao seu projeto, precisamos conhecer bem as estratégias de curto, médio e longo prazo da empresa, os requisitos não funcionais e arquiteturais do software, assim como a curva de crescimento de usuários ao longo do tempo e a volumetria de requisições.  Bem como os pontos citados ao longo deste artigo, existem ainda outros a levar em conta na decisão de qual modelo arquitetural aplicar. Como exemplo, podemos listar:  Preocupações de segurança;  Armazenamento de dados;  Lockins;  Volume total de usuários;  Volume de usuários simultâneos;  TPS (transações por segundo);  Plano de disponibilidade/SLA;  Requisitos legais;  Disponibilidade em um ou mais tipos de plataformas;  Integrações.  O levantamento de arquitetura, RAs (requisitos arquiteturais), VAs (variáveis arquiteturais), RFs (requisitos funcionais), RNFs (requisitos não funcionais) e os critérios que definem cada um desses itens influenciam diretamente na escolha do modelo correto.  A escolha do modelo arquitetural pode impactar todo o life cycle da aplicação. Por isso, esse é um assunto que devemos tratar com grande atenção. O uso de MVPs (principalmente aqueles que não vão para produção), podem auxiliar muito nessa tarefa. Eles dão uma oportunidade única de errar, ajustar, errar novamente, provar conceitos, ajustar e errar quantas vezes forem necessárias para que no final o software possua a arquitetura na versão mais acertada, trazendo assim os verdadeiros ganhos dessa escolha.  Como estão divididos os modelos arquiteturais  É ideal deixar claro que como muitas definições no mundo do software, o que é, e quais são os modelos arquiteturais podem variar. Por isso, neste artigo procurei dividi-los em quatro grandes grupos: monolítico, semimonolítico (ou monolito modular), monolito distribuído (ou microlito) e microcomponentizado.  Monolítico  Modelo em que todos os componentes formam um único aplicativo ou executável integrados em um único código-fonte. Neste caso, todo ele é desenvolvido, implantado e escalado como unidade única.  Figura 1 – Exemplo de Modelo Monolítico. Prós  Simplicidade: como o aplicativo é tratado como uma unidade única e coesa, ele se torna mais simples, já que todas as partes estão contidas em um único código-fonte.  Maior aderência a Padrões de Projeto: levando em conta que temos um único código-fonte, outro fator que facilita é que os próprios padrões de projetos (Design Patterns, 01/2000) foram escritos em épocas de dominância dos monolitos, tornando a aplicação dos mesmos mais aderente.  Maior desempenho: devido à baixa latência na comunicação, os monolitos costumam ter um bom desempenho, mesmo utilizando tecnologias mais defasadas.  Menor consumo de recursos: a baixa complexidade, a simplicidade e a menor sobrecarga de comunicação entre camadas favorecem o menor consumo de recursos.  Troubleshooting facilitado: Criação dos ambientes de desenvolvimento e debugs são feitos de forma facilitada em monolitos, pois neles os componentes partilham dos mesmos processos. Outro fator que podemos levar em conta é que monolitos possuem menos pontos de falha externos, simplificando a busca por erros.  Contras  Tamanho de times limitados: quebras relacionadas a Continuous Integration e conflitos de merge acontecem com maior regularidade em monolitos, gerando dificuldades de trabalho paralelo para grandes times.  Escalabilidade: a escalabilidade pode ser limitada em certos aspectos. Mesmo com facilidade na escalabilidade vertical, muitas vezes a escalabilidade horizontal pode se tornar um problema que poderá afetar o crescimento da aplicação.  Disponibilidade de janelas: normalmente, para um monolito ocorrem trocas de executáveis, o que necessita de uma janela de disponibilidade sem que usuários acessem o aplicativo, o que não acontece com outros modelos arquiteturais que podem utilizar outras técnicas de deploy como o Blue-Green ou até mesmo trabalhar com imagens ou pods. Tecnologia única: a baixa diversidade tecnológica muitas vezes pode se tornar um impedimento para o crescimento da aplicação por atender somente um tipo de sistema operacional, por exemplo, ou não atender de forma integral novas features solicitadas pelos clientes por não possuir atualizações que tenham capacidade de solucionar problemas complexos.  Maior gasto com compilação e execução: grandes monolitos geralmente têm um tempo elevado para compilar e fazer a execução local, gerando um maior comprometimento de tempo de desenvolvimento.  Quando Usar  Escalabilidade e Disponibilidade Baixas: se a aplicação possui uma escala limitada em que, por exemplo, o número de usuários é baixo ou a alta disponibilidade não é mandatória, o modelo monolítico é uma boa solução.  Aplicações Desktop: o modelo monolítico é altamente indicado para aplicações desktop.  Times de baixa senioridade: modelos monolíticos, devido à sua simplicidade e localização dos componentes, possibilitam que times de baixa senioridade possam trabalhar com uma melhor performance.  Recursos limitados: para uma infraestrutura limitada com recursos escassos.  Semimonolítico (ou Monolito Modular)  Modelo em que as aplicações são compostas por partes de estruturas monolíticas. Neste caso, a combinação tenta equilibrar a simplicidade do modelo monolítico e a flexibilidade do microcomponentizado. Atualmente, esse modelo arquitetural costuma ser bastante confundido com microsserviços.  Figura 2 – Exemplo de Modelo Semimonolítico.  Prós  Traz benefícios dos modelos monolítico e microcomponentizado: com isso, é possível manter partes como estruturas monolíticas e microcomponentizar somente componentes que têm a real necessidade.  Diversidade tecnológica: possibilidade de usar diversas abordagens tecnológicas.  Infraestrutura diversificada: este modelo pode ser desenvolvido para utilizar tanto infra On-Premise quanto Cloud, favorecendo a migração entre ambas.  Suporta times maiores: a segmentação dos componentes favorece que vários times trabalhem paralelamente, cada qual em seu escopo. Especialidades Técnicas: devido à segmentação, aproveita-se melhor as hard skills do time, tais como frontend, UX, backend, QA, arquitetos, etc.  Contras  Padronização: devido ao grande número de componentes que podem surgir em um modelo semimonolítico, a padronização (ou falta dela) pode se tornar um grande problema.  Complexidade: a complexidade inerente a esse tipo de modelo também tende a aumentar com novas features. Logo, novos recursos como mensageria, cache, integrações, controle de transações, testes, entre outros, podem adicionar ainda mais complexidade ao modelo.  Budget: em modelos que amparam o uso de diversas tecnologias com times grandes, são necessários mais profissionais especialistas e com nível maior de senioridade, ocasionando muitas vezes um gasto maior com despesas de pessoal.  Troubleshooting complexo: a própria complexidade do modelo e a diversidade de tecnologias tornam cada vez mais difícil o troubleshooting da aplicação. Isso se dá devido à grande quantidade de pontos de falhas (inclusive externos à aplicação) que passam a existir e à comunicação entre eles.  Quando Usar  Aceito em Vários Cenários: é um modelo flexível que pode atender vários cenários, porém nem sempre da melhor forma.  Pouca Definição: em projetos que possuem incertezas ou até mesmo que não possuem a total definição de seus requisitos, este modelo é o mais indicado.  Em médias e grandes equipes: como dito, a divisão dos componentes em vários grupos facilita o trabalho paralelo de médias e grandes equipes. Normalmente, os grupos possuem seus próprios repositórios de código, o que torna o trabalho paralelo mais ágil.  Senioridade Diversa: este modelo se beneficia de times com essa formatação, pois softwares semimonolíticos apresentam desafios variados, tanto nas camadas de frontend e backend quanto em questões de infraestrutura (IaC – Infrastructure as a Code).  Infraestrutura: para uma infraestrutura Cloud-based ou híbrida, este modelo é mais aplicável. É um modelo que permite, por exemplo, uma adoção gradual entre On-Premise e Cloud, facilitando a adaptação e minimizando impactos operacionais.  Monolito Distribuído  Essa modelagem é uma modelagem "moderna" que também vem sendo implementada e confundida com o modelo microcomponentizado/microsserviços.   "You shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile." (Fowler, Martin. 2015)  Em resumo, neste modelo arquitetural o software é construído com bases do modelo monolítico, mas implantando conforme o modelo microcomponentizado. Atualmente, muitos o consideram um antipattern.  Figura 3 – Exemplo de Modelo Monolíto Distribuído. Não valeria à pena listarmos as características de prós (não sei se tem), mas ainda vale citar características que vão contra: este modelo arquitetural reúne pontos negativos dos outros dois estilos com o qual é confundido.   Nele, os serviços são altamente acoplados e também possuem vários tipos de complexidade, tais como: operacional,  testabilidade, deployment, comunicação e infraestrutura.  O alto acoplamento, principalmente entre os serviços de backend, traz sérias dificuldades no deployment, sem contar com o aumento expressivo de pontos de falha no software.  Microcomponentizado  Modelo de software em que todos os componentes são segmentados em pequenas partes totalmente desacopladas. Dentro de microcomponente, podemos citar:  Microfrontends  Microdatabases  Microvirtualizações  Microsserviços  Microbatches  BFFs  APIs  Figura 4 – Exemplo de Modelo Microcomponentizado. "A microservice is a service-oriented application component that is tightly scoped, strongly encapsulated, loosely coupled, independently deployable, and independently scalable" (Gartner, n.d.).  As opiniões se convergem a dizer que, todo o microsserviço que deu certo, primeiro foi um monolito que ficou grande demais para ser mantido e chegou a um ponto comum de ter que ser separado.  Prós  Escalabilidade: a escalabilidade neste modelo torna-se bastante flexível. Conforme a necessidade, escala-se os componentes de maneira específica. Desenvolvimento Ágil: as equipes podem trabalhar de forma independente em cada componente, facilitando a implantação contínua e acelerando o ciclo de desenvolvimento.  Resiliência: caso um componente falhe, não afeta necessariamente toda a aplicação. Isso melhora a resiliência geral do sistema. É importante salientar que existem abordagens de pontos únicos de falha a fim de evitar esse tipo de problema.  Tecnologia Diversificada: cada componente pode ser desenvolvido utilizando tecnologias diferentes, permitindo a escolha da melhor ferramenta para cada tarefa específica. Além disso, também favorece as skills existentes em cada time.  Facilidade de Manutenção: mudanças em um componente não afetam automaticamente outros, facilitando a manutenção e atualização contínua.  Desacoplamento: os componentes são independentes uns dos outros, o que significa que as mudanças em um serviço não afetam automaticamente outros, facilitando a manutenção.  Contras  Custo: custo elevado de todos os componentes deste modelo (input, output, requisições, armazenamento, ferramentas, segurança, disponibilidade, entre outros).  Tamanho: softwares microcomponentizados costumam ser maiores em sua essência. Não somente o tamanho da aplicação, mas todo o ecossistema que a permeia desde o commit até o ambiente produtivo.  Complexidade Operacional: existe um aumento exponencial da complexidade nesse modelo. Projetar bons componentes arquiteturais para que essa complexidade seja gerida é de grande relevância. É importante escolher e gerir bem ferramentas de logging, APM e Continuous Monitoring, por exemplo. Gerenciar muitos microsserviços pode ser complexo. É necessário um esforço adicional para monitorar, orquestrar e manter os serviços em execução.  Latência: a comunicação entre microsserviços pode se tornar complexa, especialmente em sistemas distribuídos, exigindo estratégias adequadas de comunicação e gerenciamento de API.  Overhead de Rede: o tráfego de rede entre microsserviços pode aumentar, especialmente em comparação com arquiteturas monolíticas, o que pode afetar o desempenho.  Consistência entre Transações: garantir consistência em operações que envolvem vários microsserviços pode ser desafiador, especialmente quando se trata de transações distribuídas.  Testabilidade:  testar interações entre microsserviços pode ser mais complexo do que testar uma aplicação monolítica, exigindo estratégias de teste eficientes.  Infraestrutura: pode ser necessário investir em uma infraestrutura robusta para suportar a execução de vários microsserviços, incluindo ferramentas de orquestração de contêineres e sistemas de monitoramento.  Dispersão Técnica: neste ponto, podemos dizer que existe uma ação da Lei de Conway "Reversa", pois os times, assim como tecnologias e ferramentas, tendem a seguir a dispersão e segregação. Nos times, cada um passa a ter conhecimento de uma pequena parte de um grande todo. Dessa forma, para tecnologias e ferramentas, cada desenvolvedor usa o framework ou ferramentas que mais lhe convém.  Domain-Driven Design: para aumentar as chances de sucesso desse modelo é necessário que os times tenham conhecimento de DDD. Quando Usar  Volumetria: a arquitetura de microsserviços/microcomponentes tem se mostrado eficaz em sistemas de alta volumetria, ou seja, aqueles que precisam lidar com grandes quantidades de transações, dados e usuários.  Disponibilidade: uma das principais razões para se adotar esse tipo de arquitetura é a disponibilidade. Quando bem construído, um software que adota microcomponentização não tende a falhar como um todo quando pequenas partes apresentam problema. Sendo assim, outros componentes continuam em operação enquanto o componente problemático se recupera.  Escalabilidade: se diferentes partes de sua aplicação têm requisitos de escalabilidade distintos, os microsserviços podem ser úteis. Você pode dimensionar apenas os serviços que precisam de mais recursos, em vez de escalar toda a aplicação.  Tamanho dos Times: times pequenos podem ser problemas. Configurações, boilerplates, ambientes, testes, integrações, processos de input e output.  Resiliência > Desempenho": em casos de incerteza, por exemplo, do volume de requisições e até onde ele pode chegar como grandes e-commerces em períodos de alto acesso (black friday) onde é necessário que o software seja mais resiliente e tenha um desempenho mediano.  Checklist Comparativo Figura 5 – Checklist Comparativo entre modelos. Conclusão  Em síntese, a escolha do modelo arquitetural é crucial para o sucesso do projeto, exigindo uma análise criteriosa das necessidades e metas. Cada modelo arquitetural tem suas vantagens e desvantagens e devemos guiar a decisão pelo alinhamento com os requisitos específicos do projeto. Ao considerar as estratégias da empresa, requisitos e levantamentos arquiteturais, é possível tomar uma decisão que impactará positivamente o ciclo de vida da aplicação.  O trabalho (e apoio) do time de arquitetura é de extrema importância. Sendo também de grande importância que a gestão e áreas correlatas apoiem disponibilizando tempo para o levantamento de toda essa gama de informações.   Ficou em dúvida ainda? A princípio, comece pelo semimonolítco/monolito modular. Da mesma forma, dê muita atenção a modelagem do banco de dados.  Referências  Gartner. (s.d.). Microservice. Recuperado de https://www.gartner.com/en/information-technology/glossary/microservice  Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.  Bass, L., Clements, P., Kazman, R. (2013). Software Architecture in Practice (3rd ed.). Addison-Wesley.  Microservices Architecture (12/2023). Recuperado de https://microservices.io/  Fowler, S. J. (2017). Microsserviços Prontos para a Produção. Novatec.  Treinamento ArchExpert. (s.d.). Conteúdo Premium. Recuperado de https://one.archoffice.tech/  Monolith First (06/2015). Recuperado de https://martinfowler.com/bliki/MonolithFirst.html  Microservices. Acessado em 01/2024. Recuperado de https://martinfowler.com/tags/microservices.html

Nesse artigo falarei sobre GraphQL com enfoque em aplicações dotNet. Aqui, mostrarei como os problemas inerentes de REST motivaram a criação do GraphQL. Em seguida, apresentarei os conceitos básicos da especificação desta linguagem. Depois, apresentarei a biblioteca Hot Chocolate, que é uma das muitas bibliotecas que implementam a especificação do GraphQL. Finalmente, mostrarei um pequeno exemplo de uso da referida biblioteca em uma aplicação dotNet.  REST Antes de falarmos sobre GraphQL é necessário falar sobre REST. O termo foi cunhado por Roy Thomas Fielding (2000) em sua tese de doutorado. Neste trabalho, Fielding apresenta REST como um padrão arquitetural para aplicações web definido por cinco restrições:  Client-server: Essa restrição define que a interface com o usuário deve estar separada dos componentes do sistema que processam e armazenam os dados.  Stateless: Essa restrição diz que o cliente não precisa estar ciente do estado do servidor, bem como o servidor não precisa ter ciência do estado do cliente.  Cache: Essa restrição indica que, quando possível, a aplicação servidora deve indicar à aplicação cliente que os dados podem ser armazenados em cache.  Layered system: Essa restrição indica que a aplicação deve ser construída pelo empilhamento de camadas que adicionam funcionalidades umas às outras.  Uniform interface: Essa restrição indica que os recursos da aplicação devem ser disponibilizados de maneira uniforme, de modo que, ao aprender a acessar um recurso, automaticamente sabe-se como acessar os demais. Segundo o trabalho de Fielding, essa é uma das características centrais que distinguem REST dos demais padrões arquiteturais. No entanto, o próprio autor afirma que isso degrada a eficiência da aplicação, pois não há a disponibilização dos recursos de uma maneira que atenda as necessidades específicas de uma determinada aplicação.  Como é o REST na prática Na Figura 1 pode-se ver parte da API do OneDrive da Microsoft. Nessa imagem percebe-se a uniformidade no acesso aos recursos. Isso é perceptível quando notamos que, para obter dados, basta enviar uma requisição GET para um endpoint que começa com o termo drive e é seguido pelo nome do recurso e o seu ID. A mesma lógica vale para a criação de recursos (POST), a modificação de recursos (PUT) e a remoção deles (DELETE).  Acessando a documentação do Google Drive, podemos ver o típico retorno de uma API REST. Percebe-se, na referida documentação, o grande volume de dados que uma única requisição REST pode trazer. Apesar de grande, uma aplicação cliente ainda pode precisar fazer requisições extras para obter mais dados sobre o dono de um arquivo, por exemplo.  Considerando-se as restrições determinadas por Fielding e os exemplos mostrados, é fácil perceber dois problemas inerentes à REST. O primeiro deles é o tráfego de dados que o consumidor não precisa e o segundo é a eventual necessidade de fazer várias requisições para se obter os dados necessários para se montar uma página web.  Figura 1 - Acesse o artigo completo aqui. Entendendo o GraphQL O GraphQL surgiu em 2012 no Facebook como uma solução para os problemas encontrados no padrão REST. Em 2015, a linguagem tornou-se open source e em 2018 criou-se a GraphQL Foundation que passou a ser responsável pela especificação da tecnologia.  É importante destacar que GraphQL não é uma biblioteca ou ferramenta. Assim como SQL, GraphQL é uma linguagem para busca e manipulação de dados. Enquanto usamos o SQL em banco de dados, utiliza-se o GraphQL em APIs. O quadro 1 mostra uma expressão em SQL para recuperar o número de um pedido e o nome do cliente de um banco de dados. Analogamente, o quadro 2 mostra uma expressão GraphQL para obter os mesmos dados de uma API que suporta GraphQL. Nos exemplos, podemos perceber duas grandes vantagens de GraphQL sobre REST. A primeira está presente no fato de GraphQL permitir que o consumidor busque apenas os dados de que necessita para montar sua página web. A segunda está presente no fato de que o consumidor poderia buscar os dados do pedido e do cliente em uma única chamada.  Quadro 1: Exemplo de um select em um banco de dados relacional.  Quadro 2: Exemplo de uma expressão GraphQL. Considero interessante mencionar mais duas características de uma API GraphQL. A primeira delas é a existência de um único endpoint. Ao contrário de REST, em que cria-se um endpoint para cada recurso, em uma API GraphQL todas as queries e mutations são enviadas para o mesmo endpoint.   A segunda é o fato de uma API GraphQL suportar apenas o verbo POST. Essa é mais uma diferença com relação a uma REST, onde deve-se usar verbos HTTP diferentes em função da intenção da requisição. Portanto, enquanto em uma API REST devemos usar os verbos GET, POST, PUT e DELETE, em uma API GraphSQL usaremos o verbo POST para obter, criar, alterar e remover dados.   Schema Definition Language Vamos, agora, falar um pouco sobre a SDL (Schema Definition Language). Ao usar-se um banco de dados relacional é necessário, primeiramente, definir-se o esquema do banco, ou seja, é necessário definir as tabelas, colunas e relacionamentos. Com GraphQL ocorre algo semelhante, ou seja, a API precisa definir um esquema para que os consumidores possam fazer buscas dos dados. Para criar este esquema, usa-se a SDL.   O site oficial do GraphQL tem uma seção dedicada à SDL. Na referida seção pode-se encontrar uma descrição completa da linguagem para criação de esquemas GraphQL. Nesse texto, apresentarei a sintaxe básica para a criação de um esquema GraphQL. Na Figura 2 pode-se ver parte de um esquema GraphQL criado a partir do uso do Apollo. Podemos ver que o esquema inicia-se com a definição de dois tipos fundamentais: Query e Mutation. No primeiro tipo definimos todas queries que nossa API possuirá. No nosso exemplo, os consumidores poderão buscar por customers, products e orders. O tipo Mutation define quais operações de manipulação de dados estarão disponíveis para o consumidor. No exemplo apresentado, o consumidor poderá criar, alterar e remover customers e products. Porém, quando se trata de pedidos (orders), ele poderá criar, adicionar um item, cancelar e fechar o pedido.  Além dos tipos Query e Mutation pode-se perceber a presença dos tipos Customer e Product. Em ambos, existem propriedades do tipo ID, String e Float. Esses três tipos, juntos com os tipos Int e Boolean, são chamados de tipos escalares. O esquema também mostra a definição de um enumerado chamado OrderStatus. Já a Figura 3 mostra a definição de tipos Input que são usados para fornecer dados de entrada para queries e mutations.  Acho importante salientar que a forma de criar-se o esquema varia de acordo com a biblioteca que você escolher. Ao usar-se a biblioteca Apollo para javascript, a definição do esquema pode ser feita através de uma string passada como parâmetro para a função gql ou através da criação de um arquivo (geralmente chamado de schema.graphql). Porém, ao usar-se bibliotecas como Hot Chocolate para dotNet, a definição do esquema é feita pela criação de classes e da configuração de serviços na aplicação. Portanto, a forma de criação do esquema GraphQL pode variar bastante em função da linguagem e da biblioteca escolhida.   Figura 2. Figura 3. Elementos básicos da linguagem GraphQL Como mencionado anteriormente, GraphQL é uma linguagem e, portanto, possui uma sintaxe. Você pode encontrar o guia completo com sintaxe da linguagem no site oficial do GraphQL. No entanto, neste artigo, descreverei os elementos básicos dela.   Realiza-se a busca de dados através de queries, que devem iniciar com a palavra-chave query seguida do nome da query. Se ela possui parâmetros, deve-se abrir parênteses e, dentro deles, deve-se colocar o nome de cada parâmetro seguido do seu valor. Os dois pontos (:) devem ser usados para separar o nome do parâmetro do seu valor. Tendo-se finalizado a lista de parâmetros, deve-se fechar os parênteses. Em seguida, deve-se abrir chaves ({) e colocar dentro delas o nome dos campos que se deseja. Com a lista de campos finalizada, deve-se fechar a chave  (}). O quadro 3 mostra um exemplo simples de query.  Quadro 3: Exemplo de query. Existem cenários onde os parâmetros da query podem ser complexos. Quando um parâmetro é complexo, ou seja, é um objeto com um ou mais campos, deve-se abrir chaves logo depois dos dois pontos. Dentro das chaves, deve colocar o valor de cada campo do objeto e o seu respectivo valor, sendo que ambos devem ser separados por dois pontos (ver quadro 4).  Também existem cenários onde os campos da query podem ser complexos. Nesses casos, deve-se abrir chaves logo depois do nome do campo. Dentro das chaves, deve-se colocar os nomes do campo do objeto (ver quadro 5).  Quadro 4: Exemplo de query. Quadro 5: Exemplo de query. As regras descritas até aqui também servem para mutations. No entanto, essas devem ser iniciadas com a palavra chave mutation em vez de query. É interessante notar que existem outros elementos na sintaxe do GraphQL, mas os elementos descritos até aqui são suficientes para a execução da maior parte das queries e mutations.  Sendo uma linguagem, GraphQL precisa ser implementado por alguma aplicação ou biblioteca. Para que nossa API suporte queries e mutations, precisamos, geralmente, de uma biblioteca. Evidentemente que poderíamos implementar a especificação da linguagem por conta própria, mas isso seria muito improdutivo. A seção “Code” do site GraphQL.org mostra uma lista de bibliotecas que implementam GraphQL para as mais variadas linguagens. Para o mundo dotNet, por exemplo, existem as bibliotecas “GraphQL for .NET”, “Hot Chocolate” e outras.  Quando fala-se sobre as implementações de GraphQL, é necessário falar-se sobre o conceito de “resolvers”. Um resolver é uma função que é acionada pela biblioteca que implementa GraphQL. Essa função é a responsável por efetivamente buscar os dados solicitados pela query. O mesmo ocorre com as mutations, ou seja, quando a biblioteca recebe a solicitação de execução de uma mutation, a biblioteca identifica o resolver que executará as mudanças no banco de dados (insert, update e delete). Perceba, então, que na maioria das bibliotecas a execução das buscas e das alterações nos dados é feita pelo seu próprio código. Percebe-se, então, que as bibliotecas que implementam GraphQL encarregam-se por interpretar a query/mutation enviada pelo chamador e descobrir qual a função adequada para resolver a query/mutation solicitada. Para ver um exemplo de uma API simples que usa Hot Chocolate, acesse o meu GitHub.  Resumindo tudo, GraphQL é uma linguagem criada pelo Facebook com o objetivo de superar os problemas inerentes a REST. A linguagem fornece uma sintaxe simples para se obter dados de uma API bem como alterar dados da mesma. Ela é implementada por uma grande variedade de bibliotecas para as mais diversas linguagens, permitindo que o desenvolvedor crie uma API GraphQL usando a sua linguagem predileta. Referências “GraphQL.” Wikipedia, 9 June 2022, en.wikipedia.org/wiki/GraphQL. Acessado em 6 Nov. 2023.  The GraphQL Foundation. “GraphQL: A Query Language for APIs.” Graphql.org, 2012, graphql.org/.  Thomas Fielding, Roy. “Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST).” Ics.uci.edu, 2000, ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. Acessado em 6 Nov. 2023. 

O que são multi-brand design systems  Os multi-brand design systems são sistemas com atributos que os tornam flexíveis para o uso em diferentes contextos, padrões visuais e de design de interfaces. São desenvolvidos para os casos nos quais uma única biblioteca visa atender a produtos de diferentes marcas.  Geralmente, esse tipo de design system também é independente de frameworks, plataformas ou tecnologias — são os chamados tech-agnostic design systems.  Atualmente, o design system agnóstico mais popular é o Lightning, desenvolvido pela Salesforce, também criadora do conceito.  Benefícios  Além de ser uma fonte única de verdade, o multi-brand design system compartilha o custo da operação, tornando o trabalho verdadeiramente colaborativo entre times. Segundo designers do grupo Volkswagen, a implementação do GroupUI trouxe os seguintes resultados:  Aumento da agilidade, eficiência e redução de custos são alguns dos benefícios dos multi-brand design systems. Escalabilidade  Desenvolvidos com base no conceito de design tokens, viabilizam que a mesma biblioteca seja replicada em diferentes produtos, independentemente do framework em que são desenvolvidas. Ao mesmo tempo, permitem que cada um desses produtos use seus próprios padrões visuais. Outro ponto muito relevante é o compartilhamento de características como boas práticas, responsividade, acessibilidade, performance, UX e ergonomia.  Uso em diferentes tecnologias  Atualmente, é comum encontrar em design systems, mesmo naqueles que atendem a uma única marca, diferentes bibliotecas para produtos web, iOs e Android. Isso acontece devido à existência de diferentes especificações para navegadores desktop e mobile, bem como entre dispositivos com sistemas operacionais nativos, como Apple e Google. Trabalhando de forma independente dessas tecnologias, é possível instanciar um mesmo design system em componentes de bibliotecas distintas para atender a essas particularidades.  Ganho de eficiência  Segundo dados divulgados por lideranças de UX e design systems do Grupo Volkswagen, por meio da apresentação Multibrand Design System within the Volkswagen group & its brands, há um grande aumento de agilidade, produtividade e eficiência ao trabalhar com o conceito multi-brand.  Eficiência operacional com o uso de multi-brand design systems. (Fonte: YouTube)  Comparando o esforço necessário entre um produto sem design system, passando por um que possui seu design system, e chegando a um que adota a metodologia multi-brand, é possível perceber uma redução incremental e considerável dos esforços de UI (design de interfaces) e desenvolvimento. Essa implementação possibilita uma forma de trabalho mais orientada à experiência do usuário e discovery, ao liberar recursos para estas atividades, que até então estavam sendo consumidos na design e implementação de interfaces.  Padronização  Um design system detalhado e bem especificado torna-se uma fonte única da verdade. Quando compartilhado dentro da organização, além de facilitar muito o trabalho das equipes, viabiliza uma padronização consistente, evitando a necessidade das mesmas discussões, descobertas e definições, que passam a estar prontas para serem reusadas como resultado  do desenvolvimento constante de um design system.  Fácil personalização  Segundo especialistas, a principal característica de um sistema de design multi marcas é a flexibilidade. Neste contexto, tornar personalizável significa permitir que cada produto possa aplicar suas decisões de design visual. Para que isto seja possível, criam-se bibliotecas de design tokens. Elas que podem ser facilmente duplicadas e personalizadas, gerando padrões visuais distintos para cada marca e produto.   Design tokens podem ser interpretados como variáveis que carregam atributos de estilo, como por exemplo uma cor da marca, que aplicada como token, permite que, ao trocar-se o valor carregado pela variável, reflita a mudança em todos os lugares onde a cor é apresentada na interface.   No exemplo acima, temos especificações de cores de marca para três diferentes design systems, sendo que na coluna da esquerda temos o token, que permanecerá o mesmo em todos os produtos. Já o valor carregado pela variável é diferente em cada um dos casos. Essas definições se aplicam a qualquer outro atributo visual, como tipografia, espaçamentos, bordas, sombreamento e até animações.    Estrutura de design systems multi-marcas  Segundo Brad Frost, um dos mais influentes consultores de design systems da atualidade e autor do livro Atomic Design, recomenda-se que design systems multi-marcas possuam três camadas:  Estrutura de três níveis de um design system. (Fonte: Brad Frost)  Tech-agnostic (1ª camada)  O nível agnóstico de um design system é a base para os demais, por isso, ele contempla apenas os códigos html, css e java script, com o intuito de renderizar componentes no navegador. Essa camada é importantíssima a longo prazo, já que permite o reaproveitamento futuro de um design system. Por exemplo, no cenário atual, pode-se dizer que a linguagem mais popular é o React. Porém, nem sempre foi assim e não se sabe qual será a próxima tecnologia a se destacar. Por esse motivo, é importante haver uma camada base, que tenha sua aplicação possibilitada em novas tecnologias, sem que seja necessário iniciar um novo design system a partir do zero.  Nessa primeira camada, designers e desenvolvedores constroem os componentes do design system em um ambiente de oficina, documentados em alguma ferramenta como Figma e Zeroheight. O resultado desse trabalho são componentes renderizados no navegador, tendo em vista que o framework adotado hoje pode não ser o mesmo adotado no futuro.  Tech-specific (2ª camada)  O nível específico de tecnologia é onde já existe uma dependência com alguma tecnologia e/ou plataforma e, além disso, encontra-se a oportunidade de gerar uma camada de design system para todos os produtos que usam a mesma tecnologia. Um bom exemplo desse tipo de design system é o Bayon DS, que atende aos produtos SAJ. Também é possível utilizá-lo para para desenvolver qualquer outro produto que use a tecnologia React.  Prod-specific (3ª camada)  A terceira camada é onde tudo se torna muito específico e todo o esforço é feito para um determinado produto. Nesse nível, podem ser criadas documentações referentes a padrões bem singulares e que se aplicam apenas àquele determinado contexto. Seguindo o conceito de Atomic Design, nessa camada são criados os componentes de maior complexidade e menor flexibilidade, como páginas e templates, a fim de gerar padrões de produto.  Na terceira camada, aplicações individuais consomem a versão específica da tecnologia selecionada, via gerenciadores de pacotes como npm e yarn.  Como estamos colocando em prática esses novos conceitos  Há alguns meses, após a divulgação da iniciativa Inner Source, começamos a estudar uma forma de transformar o Bayon, para que pudesse "receber" esse novo conceito. Pessoalmente, iniciei uma pesquisa aprofundada sobre os temas discutidos neste artigo. Além disso, meus gestores me proporcionaram a oportunidade de participar de um bootcamp avançado sobre design systems, que me trouxe muito aprendizado.  Em paralelo à pesquisa, reunimos alguns profissionais com conhecimento sobre o Bayon, representados por colegas dos times de arquitetura e design de produto das verticais JUS, para debatermos as possibilidades de atuação para converter o nosso design system para os padrões mais recentes.  Juntos, diagnosticamos qual a forma mais correta para criação e aplicação de uma biblioteca de design tokens, permitindo-nos remover nosso atual framework, o Material UI, para que, em seu lugar, haja a implementação do novo design system agnóstico da Softplan.  Web components e Stencil  Através de encontros recorrentes com representantes das empresas do Grupo Softplan, discute-se a possibilidade de desenvolvermos uma biblioteca de web components. Nela, aplica-se cada atributo visual ou decisão de design através de design tokens, permitindo uma completa personalização que garante que cada componente apresentará as características visuais do produto correspondente.   Web components são um conjunto de APIs que permitem a criação de tags HTML personalizadas, reutilizáveis e encapsuladas para uso em páginas e aplicativos Web. Possuem muitas vantagens, como compatibilidade com aplicações que usam ou não frameworks, compatibilidade com todos os principais navegadores e disponibilidade de bibliotecas open source que reduzem o custo da operação.   Somando a esta tecnologia, utiliza-se também o Stencil.js, um compilador open source que compartilha conceitos encontrados nos frameworks mais populares e que simplifica ainda mais o desenvolvimento de componentes, bem como a aprendizagem por parte de desenvolvedores.  Referências  Multibrand Design System within the Volkswagen group & its brands  Design tokens — What are they & how will they help you?  Design Systems Should be JavaScript Framework Agnostic  Creating multi-brand design systems  Managing technology-agnostic design systems  Salesforce Lighning DS  Managing technology-agnostic design systems  Multibrand Design System within the Volkswagen group & its brands (Vídeo)  In the file: Creating multi-brand design systems (Vídeo)  Atomic Design by Brad Frost—An Event Apart Austin 2015  Webcomponents.org  MDN Web Docs  Stenciljs  Criando Web Components com StencilJS (Youtube)  Construindo web components com Stencil JS

Segurança da informação refere-se ao conjunto de práticas, medidas e procedimentos adotados para proteger as informações e dados sensíveis de uma organização ou indivíduo contra ameaças, acessos não autorizados, perda, roubo, danos ou alterações indesejadas. O objetivo é garantir a confidencialidade, integridade e disponibilidade dos dados, bem como preservar sua autenticidade e evitar que caiam em mãos erradas.  A segurança da informação é essencial em um mundo altamente conectado e dependente de sistemas computacionais, redes e tecnologias digitais. Ela abrange várias áreas, incluindo:  Confidencialidade: Garantir que as informações estejam acessíveis apenas a pessoas autorizadas, impedindo o acesso não autorizado por meio de autenticação, criptografia e controle de acesso.  Integridade: Assegurar que os dados sejam precisos, completos e não sofram alterações não autorizadas durante o armazenamento, transmissão ou processamento.  Disponibilidade: Certificar-se de que as informações estejam disponíveis e acessíveis quando necessário, evitando interrupções causadas por falhas, ataques ou desastres.  Autenticidade: Garantir que as informações sejam atribuídas corretamente a seus autores e que a origem dos dados seja verificável.  Não repúdio: Garantir que o autor de uma ação não possa negar a autoria ou a realização de uma transação.  Gerenciamento de riscos: Identificar, analisar e mitigar ameaças e vulnerabilidades para proteger as informações de possíveis incidentes de segurança.  Impactos da ausência de segurança da informação A falta de segurança da informação pode ocasionar uma série de impactos negativos significativos para indivíduos, organizações e até mesmo para a sociedade como um todo. Alguns dos principais impactos incluem:  Roubo de dados: Hackers e criminosos cibernéticos podem invadir sistemas desprotegidos e roubar informações confidenciais, como dados pessoais, números de cartões de crédito, informações bancárias e outros dados sensíveis. Esse tipo de roubo pode levar a fraudes financeiras, roubo de identidade e extorsão.  Vazamento de informações: Vazamento de informações sensíveis, como segredos comerciais, propriedade intelectual ou informações governamentais confidenciais. Como resultado, esses vazamentos podem prejudicar a competitividade das empresas, a segurança nacional e a privacidade das pessoas.  Prejuízo à reputação: Quando uma organização sofre uma violação de segurança, sua reputação pode ser seriamente comprometida. A percepção pública da falta de cuidado com os dados dos clientes pode afetar negativamente a confiança de clientes e parceiros comerciais.  Interrupção dos negócios: Ataques cibernéticos, como ransomware ou negação de serviço (DDoS), podem deixar sistemas inoperantes e interromper as operações de empresas. Essa interrupção pode causar perda de produtividade, danos financeiros e frustração dos clientes.  Perda financeira: Como o custo de reparar sistemas comprometidos, pagar resgates de ransomware ou enfrentar litígios relacionados a violações de dados.  Violações regulatórias e legais: Em muitos países, existem leis e regulamentos que exigem proteção adequada dos dados dos clientes e das informações sensíveis. A falta de segurança pode levar a violações dessas leis, o que pode resultar em multas, penalidades e ações legais.  Espionagem e ciberguerra: Facilitar a espionagem cibernética e até mesmo ataques cibernéticos de larga escala entre países, prejudicando a segurança nacional e a estabilidade geopolítica.  Danos à confiança digital: Minar a confiança geral nas tecnologias digitais, o que pode desacelerar a adoção de novas tecnologias e prejudicar a economia digital.  Medidas de Segurança Para mitigar tais impactos, é fundamental que indivíduos e organizações invistam em medidas de segurança da informação, como criptografia, autenticação forte, treinamento em conscientização de segurança, atualizações regulares de software e auditorias de segurança. Além disso, é essencial que governos e setores industriais trabalhem em conjunto para desenvolver políticas e padrões de segurança cibernética mais robustos.  Alguns elementos comuns para garantir a segurança da informação incluem firewalls, sistemas de detecção e prevenção de intrusões (IDS/IPS), antivírus, criptografia, backups regulares, políticas de senha fortes, treinamento de conscientização de segurança e monitoramento de atividades suspeitas.  É dever de cada um de nós zelar pela segurança da informação, reconhecendo a importância de uma postura vigilante em nossas ações cotidianas. A responsabilidade não recai apenas sobre especialistas em tecnologia ou departamentos específicos, mas sim sobre cada indivíduo. Por isso, desconfiar, verificar e validar as informações recebidas é uma prática fundamental para evitar cair em armadilhas de engenharia social. Afinal, essa forma de ataque cibernético pode se originar de fontes inesperadas e aparentemente confiáveis. Somente ao assumirmos o papel de nosso próprio aliado na segurança digital, poderemos construir uma base sólida para proteger nossa privacidade, dados pessoais e informações sensíveis. Ao fortalecermos nossa consciência e a adoção de medidas preventivas, podemos contribuir significativamente para um ambiente online mais seguro e confiável para todos.  É importante ter atenção com ferramentas de inteligência artificial como Chat GPT ou Google Bard. Jamais coloque e-mail corporativo para acessar essas ferramentas, pois pode representar um risco significativo para a segurança de informações sensíveis da empresa em que você trabalha. Ao utilizar essas plataformas, opte sempre por utilizar um e-mail pessoal. Além disso, é essencial estar ciente das políticas de privacidade e segurança das ferramentas de inteligência artificial utilizadas.  Conclusão A segurança da informação é fundamental para proteger dados pessoais, informações financeiras, segredos comerciais, propriedade intelectual e outros ativos valiosos de indivíduos e organizações, especialmente em um cenário onde a ameaça de ciberataques e violações de dados é cada vez mais constante. 

Olá a todos, me chamo Douglas Dourado e este é meu primeiro artigo no Tech Writers. Abordarei os meus aprendizados na carreira como Business Analyst (ou Analista de Negócios). Para poder elucidar esse assunto, primeiramente preciso voltar um pouco no tempo. Ingressei na empresa Softplan em maio de 2013 para participar do Projeto Puma do nosso cliente Tribunal de Justiça do Estado de São Paulo (TJSP), mais especificamente para os processos digitais de Segunda Instância. Esse projeto foi de suma importância para nosso cliente pois, com ele, os processos que eram morosos foram otimizados dia a dia tanto para os serventuários quanto para todas as outras pessoas envolvidas naquele período. Comecei minha carreira como Analista de Sistemas e, nesse tempo, com a ajuda de várias pessoas envolvidas no meu ciclo profissional, consegui absorver muitas coisas até chegar aonde estou hoje, atuando como Business Analyst. Este artigo irá trazer algumas dicas de quem já percorreu o caminho e será interessante para quem busca seguir carreira na área de produto. Em todos esses anos, destaco 3 importantes habilidades que aprendi e que considero pilares importantes para quem quer trilhar essa carreira. São elas: Resiliência, Comunicação entre Equipes e Sinergia com o cliente. Habilidades essenciais para um Business Analyst Resiliência De acordo com o dicionário virtual, o termo Resiliência pode ser definido resumidamente como: a capacidade de enfrentar e superar adversidades. Ao longo da sua carreira algumas adversidades podem aparecer, mas a resiliência nos ajuda a percorrer os acontecimentos, aprender com eles e ter mais tranquilidade e confiança para conduzir os próximos passos. Portanto, aprenda a recalcular a rota, reorganizar e seguir em frente. Comunicação entre equipes A comunicação entre as equipes é algo também muito importante. Isso porque, para estarmos em um nível de segurança, dependemos de outras equipes e pessoas. Como diria o saudoso Chacrinha: “Quem não se comunica, se trumbica”. Em alguns momentos nesse cargo você vai precisar encaminhar demandas, negociar e conduzir reuniões com clientes e equipe. Aprenda técnicas de comunicação assertiva, storytelling, busque ser claro e objetivo, adequando sua comunicação para cada ouvinte, se o seu cliente for formal, adeque-se. Caso o ambiente exija mais termos técnicos, utilize-os ou até mesmo o contrário: aprenda a explicar cenários complexos com palavras e exemplos simples. Mas, lembre-se que o primeiro passo para uma boa comunicação é saber ouvir e entender a necessidade do outro. Sinergia com o cliente Existe diversos formatos e fluxos de trabalho dentro do cargo de Business Analyst, inclusive aqui dentro da Softplan. No projeto em que ingressei, o Analista de Negócio tem contato direto com o cliente em alguns momentos, para, por exemplo, mapear requisitos e necessidades. Caso esse for seu caso, busque seguir essas dicas: eu sempre me atentava em absorver o máximo de informação possível do que os usuários tinham a dizer para conseguir analisar o cenário. Foco no seu cliente, entender a necessidade dele, fazer perguntas adequadas e estar com uma visão dinâmica é essencial. Não saia de uma reunião com dúvida, tenha clareza sobre o que você precisa entregar para aquele cliente, isso é essencial para uma entrega de qualidade. Quer seguir a carreira de Business Analyst? Portanto, para você que quer seguir carreira na área de Business Analyst busque desenvolver habilidades de resiliência, comunicação e foco no cliente. Essas habilidades são pilares essenciais que eu aprendi ao longo da minha carreira e utilizo diariamente. E para você que quer trabalhar conosco na Softplan, não deixe de conferir nossas vagas!