DEV Community: Afonso Pacifer

Criando componentes para Web #01: Acessibilidade (a11y) na prática com WAI-ARIA

Afonso Pacifer — Sun, 16 Jun 2024 16:28:03 +0000

O que abordaremos nessa série?

Olá, nessa série de artigos vamos abordar todos as especialidades que uma pessoa profissional de Front-End precisa compreender para criar componentes acessíveis, performáticos, responsivos, manuteníveis, reutilizáveis, documentados, customizáveis, testados e que atendem as reais necessidades de produtos e times de desenvolvimento, independente da tecnologia escolhida, seja React.js, Angular, Vue.js ou qualquer outra.

Como vamos abordar cada assunto?

Pensei em seguirmos um roteiro para que cada assunto possa ser abordado com o mesmo padrão, dessa forma não perdemos nenhum ponto importante e ainda me ajuda na hora de escrever hehe.

Roteiro genérico:

Introdução
Qual a importância?
Principais referências
Aplicando na prática
Como testar
Dicas de especialista
Próximos passos

Ok, agora que estamos alinhados com as ideias por trás dessa série, vamos partir para o primeiro assunto. Bem vindos ao mundo da a11y ❤️.

Introdução

Primeiro precisamos entender o que significa o tal a11y. Basicamente é a abreviação da palrava em inglês accessibility (acessibilidade), sendo a + 11 letras no meio + y. Apenas abreviamos o termo para facilitar o uso no dia a dia.

Dica: Fazemos o mesmo com a palavra internationalization (internacionalização), sendo i + 18 letras no meio + n, logo temos como resultado o tão famoso termo i18n (Que será assunto de um próximo artigo).

Dentre todos os aspectos relacionados a acessibilidade web, hoje abordaremos o famoso WAI-ARIA, mas antes, precisamos conhecer a WAI.

WAI ou Web Accessibility Initiative (Iniciativa de Acessibilidade na Web), é uma iniciativa da W3C para desenvolver padrões e materiais de apoio que nos ajudam a compreender e implementar a acessibilidade.

Já o WAI-ARIA nós podemos definir como uma especificação que traz uma extensão para o HTML, adicionar muito mais dinamismo e controle sobre a semântica.

Qual a importância da a11y?

Antes de demonstrar o WAI-ARIA em ação, e para nivelar o conhecimento, precisamos abordar a importância da acessibilidade na web, e para isso, eu trouxe alguns links de experts que já explicaram muito bem o assunto na comunidade Front-End ❤️.

Referências sobre a11y na Web

Aplicando na prática

Antes de aplicarmos o WAI-ARIA, para que tudo faça sentido precisamos entender de forma prática a importância da semântica e ir muito além de simplesmente dizer que "HTML semântico é o certo", sem um critério objetivo.

Vamos começar com um simples componente de toggle button, e para facilitar o exemplo vamos trabalhar apenas com HTML + CSS + JS:

<span class="toggle">
  <span> OFF </span>
  <button class="toggle__button"></button>
  <span> ON </span>
</span>

Resultado:

PS: O código completo desse exemplo, incluindo CSS e Javascript, pode ser acessado no meu Codepen.

Conseguem perceber os graves problemas de semântica dessa botão? Não?

Do ponto de vista de um usuário comum, o comportamento está bem claro e bem fácil de entender, mas a semântica não foi feita para um usuário "comum".

A principal função da semântica no HTML é ser interpretada por robôs, sejam mecanismos de busca (tentando entender sua página para rankea-la) ou leitores de tela (transcrevendo o conteúdo, iterações e estados para um usuário com deficiência visual).

O WAI-ARIA em especial é extremamente importante para adicionar significado para a interface através da semântica, afinal, entender que uma interface na web não é algo apenas visual, faz parte das bases para um pessoa verdadeiramente profissional em Front-End.

Para ficar mais claro, vamos testar esse botão com um software leitor de tela e analisar os resultados:

Como podemos perceber, o toggle-button não indica o estado de ON ou OFF, em outras palavras, não sabemos se o botão está clicado ou não.

Para corrigir isso, podemos adicionar a propriedade aria-pressed, que tem como valores possíveis:

true: para indicar que está "clicado".
false: indicando que "não esta clicado".
mixed: para indicar que está entre os dois estados.

<span class="toggle">
  <span> OFF </span>
  <button class="toggle__button" aria-pressed="false"></button>
  <span> ON </span>
</span>

Resultado:

Bem melhor, porém ainda temos um grave problema na experiência do usuário. Apesar do comportamento do botão estar claro, como não existe conteúdo de texto dentro do elemento button, não é possível saber o que o botão faz, a única informação que o leitor de tela tem é um toggle-button sem descrição.

Vamos adicionar um aria-label para resolver esse problema.

<span class="toggle">
  <span> OFF </span>
  <button
    class="toggle__button"
    aria-pressed="false"
    aria-label="Alterna entre os modos ON e OFF">
  </button>
  <span> ON </span>
</span>

Resultado:

Ainda podemos ir além, caso o toogle-button abra dropdown, podemos vincular os componentes usando o atributo aria-haspopup, e assim por diante.

Na categoria States and Properties (Estados e propriedades) do WAI-ARIA, temos uma longa lista de atributos possíveis para adicionar semântica em nossas aplicações, recomendo a consultar a lista completa na documentação da Mozilla Developer Network.

Indo além com `WAI-ARIA Roles`

Quando falamos em componentes, na maioria das vezes criamos elementos que não existem no HTML, e mesmo quando existem, é bem comum ignorar o elemento nativo e criar um comportamento personalizado, como exemplo ignorar a tag <dialog>e criar um modal do zero utilizando apenas <div>. Não há nada de errado com essa pratica, desde que deixe claro para o leitor de tela que o papel (em inglês: role) daquela <div> é se comportar como modal, ai entram os atributos da categoria WAI-ARIA Roles.

Vamos nos aprofundar com um exemplo mais crítico

Sabe quando utilizamos elementos semânticos do HTML para construir algo? Podemos, por exemplo, criar a estrutura de uma página da seguinte forma não semântica:

<div>
  <div></div>
  <div>
    <div></div>
    <div></div>
  </div>
  <div></div>
</div>

Ou seguindo um HTML semântico:

<div>
  <header></header>
  <main>
    <section></section>
    <section></section>
  </main>
  <footer></footer>
</div>

Até aí tudo bem, aprendemos que devemos escrever de forma semântica e os motivos da sua importância. Mas e quando não encontramos uma tag HTML perfeita para nossa necessidade? Ai entra o atributo role.

Vamos ao exemplo de um alerta de erro:

<div class="snackbar-error">
  Ouve um problema ao enviar sua solicitação
</div>

Parando para pensar com calma, entendemos que simplesmente jogar um alerta visual na tela não alerta um usuário de leitor de tela, certo?

Para que o papel de alerta seja realizado corretamente pelo componente, precisamos adicionar esse papel:

<div class="snackbar-error" role="alert">
  Ouve um problema ao enviar sua solicitação
</div>

Dessa forma o leitor de tela avisa ao usuário que existe um alerta e lê a mensagem assim que o alerta for disparado ❤️.

Mais uma vez eu recomendo consultar a lista completa de roles na documentação da Mozilla Developer Network .

Como testar

Nos exemplos acima, eu usei o leitor de tela chamado Voice Over, que já vem instalado por padrão nos computadores com sistema operacional macOS, mas obviamente existem leitores de tela para Windows, Linux, Android, etc... Recomendo pesquisar, instalar e aprender bem a usar ao menos um leitor de tela, afinal, seria no mínimo estranho projetar interfaces visuais sem monitor, logo, pensar em semântica sem se quer testar o que você esta fazendo, beira o absurdo! (desculpem a falta de decoro, me exaltei rsrsrs).

Dicas de especialista

Na hora de criar um componente, não pule etapas por achar que HTML é simples. Planeje a semântica, pesquise e teste.
Durante sua analise de requisitos, crie uma tarefa para pesquisar e construir a semântica do componente antes mesmo de começar a trabalhar no CSS.
Tente recriar um botão sem usar a tag <button>, o aprendizado vai trazer bons insights, confia.

Conclusão

Lembre-se! Se você se considera uma pessoa boa com HTML, mas nunca abriu um leitor de tela, repense, saber como o HTML funciona e ser profissional são coisas diferentes.

Ah, se você gostou do conteúdo e quer que essa série continue, comente com um feedback e compartilhe com seus amigos Devs.

E claro! Me siga para mais dicas 😎:

Obrigado por ler e te vejo na próxima ❤️.

5 ideas for personal projects using vanilla javascript

Afonso Pacifer — Wed, 02 Sep 2020 20:58:03 +0000

Building personal projects is one of the must-have habits for any developer, but a big question appears for many developers that make the process stop: What project am I going to do?

If your objective is to create a new personal project to improve your technical skills, the project doesn't have to change the world or be useful to other people. Your project needs to change your world of possibilities and be useful to your technical background improvement.

Tip: Spend time thinking in names or other side things that don't help you to improve your skills.

For tips and tricks, I recommend my last blog post about: How you can stay motivated to work in personal projects.

Cool ideas

Okay, let me show you some ideas for cool projects you can do with pure javascript to improve your technical skills.

A web framework for creating Back-End API's

Start an HTTP server, handle all request types, and send the correct response to the client.

This is good for learning how the Node.js works with web applications under the hoods.

A front-end Single Page App

Fetch and replace a piece of code, recreate the browser workflow using the history API and improve the application performance.

This is good for understanding the default browser experience.

A Command Line Tool (CLI) to control your GitHub account

Run your application only in the CLI, add parameters for fetch data from Github API and show them.

This is good for learning how the Node.js works without a web server and how to integrate it with the operational system.

A Chrome extension boilerplate

Create a chrome extension is cool, but the answer for: What extension should I create? Is hard.

My tip? Create a todo app and extract the core files and concepts to a new repository. When you have an idea, reuse the boilerplate and save time.

This is good for learning about DOM.

A Github Chat Bot

Handle inputs, process your data, and respond like a real user.

This is good for understanding APIs integrations.

The gold rule

At this point, you may be probably asking yourself: What do I need to learn to start any of these projects?

Enjoy all content created by the javascript community around the world. Search for: "How you create a [complete here]", open 2 or 3 tabs in your browser, read/watch and just start the code.

Follow the tutorials to get started! When you become more confident, implement your ideas.

The real gold rule

If you can't understand anything in your search, don't worry, you probably need to take a step back and learn the basics. It's normal for developers at all levels. If you feel lost when learning any new content, don't give up. Keep calm, ask the community and restart.

I found a list of resources to help you when creating the projects suggested in this post:

Conclusion

The real value in the process of creating personal projects is priceless but don't feel bad if you can't spend time working on side projects. Take your time, learn the most you can. If you keep studying, the same amount of time you spend on reading articles, you’ll be able to use it to code your own projects. Keep calm and keep studying.

If you liked this content, follow me on Github and/or Twitter 💛.

Cheers.

How you can stay motivated to work on personal projects

Afonso Pacifer — Mon, 17 Aug 2020 14:33:30 +0000

After my last post (How I became a senior javascript developer with personal projects), I received a good question that got me thinking:

What keeps you motivated?

I believe this is a simple but deep question. Many people start new side projects and get very excited at the beginning, but after a few days, the energy is gone. WTF happen?

Recently I’ve read an excellent book called 14 Habits of Highly Productive Developers (by my friend Zeno Rocha) which has a complete discussion about the side projects’ topic. I recommend all developers to read the entire book. But, in this blog post, I’ll try to explain how I’m still motivated by my personal projects in the last years. Starting by demystifying an idea.

I don't complete all of my side projects!

Yes, you read correctly. I have many unfinished side projects in my Github account and everything is fine.

The process is the same:

First: I have an awesome idea (in my mind).
Second: I create a repository and start the project in my code editor.
Third: I abandon the project.

Tips to complete your side project

I have a list of private empty repositories, but I also have a list of projects that are done. If you have more drafts (or ideas) than finished projects, I have some tips that may help you.

Think hard if you really want to do a project

During the first moments after an idea, you are full of motivation, but how do you know if this motivation will exist tomorrow? Simple, wait for tomorrow! If you still want to work on the new project, just START.

I create a Meditation Timer to keep calm before important decision moments (and learning Vue.js better).

Tip: If you have energy and time, enjoy the moment and do it. Only wait for tomorrow if the project scope is large!

Create a checklist and follow it

Don't spend time/energy thinking or trying to remember common things for all projects.

If your project needs a Readme, take note.
If your project needs to publish in npm (or similar package registry), take note.
If your project needs a .gitignore file, take note. And etc...

My checklist for open source projects.

Tip: If your project needs a cool name, use a beta name, and rename when you decide it, don't spend time overthinking the name instead of starting the project.

Have a generic boilerplate

Don't spend time/energy creating the same files all time.

Tip: Get ideas from your old projects or ask your friends: how files are commons in all projects.

Yes, creating a boilerplate is a cool first project for you to start.

My generic boilerplate.

Don't try to learn more than one new technology at the same time

Starting a new project for learning a new technology is the best decision you can make. But you need to consider the learning curve for any new thing you want to implement. If you add multiple learning curves in your project, you’ll probably spend more time on the project and increase your chances to be demotivated due to all problems related to the learning process.

I don't conclude this calendar project because I try to learn (and implement) a lot of new technologies at the same time.

Dedicate time (with quality) to your project

Don't wait for the inspiration moment, organize your time to work in your project as if it was your main job. Turn off all notifications and previously select an inspirational playlist to help you focus.

I created a Pomodoro Timer for you to focus on your tasks (and learning React.js better).

Define a scope for the project and follow it

In my previous blog post, I shared big projects, but this project was created for one year. Within this period, I worked in a lot of small projects and the most powerful trick for all size projects is to determine a scope of features and follow them.

During the working, if you have a new incredible idea, take note and get back to the scope. Believe me, big companies have problems when spending more energy than necessary on their MVPs.

Post your project on twitter, Instagram, Facebook, write a blog post about the process or share with a friend.

My personal Github profile.

Don't worry about possible critics about your code, serious developers will help you, not attack you. Share your project and grow with the comments.

Conclusion

To be exposed to new challenges is scary, but great rewards await for people who can take great steps. Creating and sharing your side projects are one of the greatest steps in a developer career.

I'm from Brazil and in my country only 5% of the population speak English (The official Brazilian language is Portuguese), and I was always part of the 95%.

Writing in English is hard for me, but this is my new side project: to improve my English skills to meet new people and friends around the world!

Now, I'll share some of the places where people were reached by my first English blog post a week ago:

I received many responses, I couldn't compile all the places on this map! Thanks a lot 💛.

I cannot express my emotion when I see this result after my effort to learn English.

Remember, open source is not only about sharing code but is also about sharing experiences and solutions for different people regardless of the nationality or the background!

Thanks a lot for reading my second English blog post.

If you liked this content, follow me on Github and/or Twitter 💜.

Cheers.

How I became a senior javascript developer with personal projects

Afonso Pacifer — Mon, 10 Aug 2020 20:39:48 +0000

Everything can be summed up in short words

One of the best decisions in my developer career was to go beyond just using tools.

I decided to create my tools, not for commercial propose, but to know how these technologies actually work and to improve my tech skills.

This is a short story about how this decision changed my life.

My first big challenge with a personal project

I've always been the CSS guy. In 2015 my passion for CSS took me quickly to the status of "reference" in my country (Brazil).

At this time, inspired by my friend Raphael Amorim, I accepted the Write Code Every Day challenge. Basically I worked in open source projects every day for 1 year.

Okay, but in my first days of coding, my javaScript skills were extremely limited.

Everything has changed when I received an invite to talk in Front in Valle (a big front-end conference in my country) that I could talk about any topic. So I had an idea as naive as it was brilliant. I decided to learn about javascript creating my own CSS preprocessor.

Banana CSS

🍌 The Brazilian CSS superset.

In 2016 I created the CSS preprocessor called banana CSS, the objective of this project was to learn javascript, but I ended up learning about Node.js, how to creating CLIs, lint, unit tests, JSDocs, continuous integration, data structures, AST, how to create gulp plugins, and more.

Link to Banana CSS project.

Going deep in front-end development.

Okay, at this point I felt the necessity to learn more about javascript in the browser, so I thought about the main tool I daily use and came to the conclusion that it was React.js.

So...

millenium.js

In 2017 I created a project called millenium.js, the description for this project is:

A javascript library for creating Functional Stateless Components and render with Virtual DOM. Ideal for creating ultra-light and fast applications with Redux.

Or my favorite description:

🚀 Render your front-end in less than 12 parsecs.

In this project, I learned about performance, good practices for creating front-end libraries, algorithms, JSX, and more. Of course, I kept all the good practices from the old projects.

See an online DEMO with Redux.

Link to millennium.js project.

Using my passions to explore new things

In 2018, after I watched the Ready Player One movie, I left the movie theater determined to create a game with javascript.

Creating a game with javascript is relatively simple, you can choose among a lot of tools, read the docs, experiment, and it’s done.

But, the natural decision (for me) was: Creating a new tool for creating games.

For this project, I decided to define some funny rules:

Don't use Canvas/WebGL.
Use only CSS to render animations.
Write a functional code.
Try to write the maximum of isomorphic/universal code as possible.

burnout.js

Finally, I created the burnout.js:

🎮 The 2D game engine for manage collisions.

In this project, I learned more about functional programming, DOM performance, algorithms (for calculating the elements collisions), and much more.

Link to burnout.js project.

Again, of course, I kept all good practices like unit tests, unit tests, unit tests, hum...

Triggers for projects from projects

At this point, I had a revelation:

OMG, why did I never think of creating my automated testing tool?

So...

N.O.M.s

🔮 Universal/isomorphic javascript unit tests for witches.

While working on burnout.js I built the N.O.M.s (my testing tool) and wrote 100% of the burnout.js unit tests using the N.O.M.s library.

What were the goals of creating my test library?

It should work in the browser and Node.js (isomorphic/universal).
Create all assertions in pure Javascript (not using browser APIs or Node.js modules).
Use Emojis.
Don't use a custom CLI for run tests.

Curiosity: I used mocha to write the N.O.M.s unit tests. Ironic but funny 😅!

Link to N.O.M.s project.

Was it worth reinventing the wheel?

After these personal projects (and a lot of others), in 2019/2020 I spend my time working on corporate products, creating complex Front-End applications, and leading a full-stack development team.

For my surprise, in the last years of open source development, I’ve improved my technical level a lot and I had no problems with implementing complex architectures using React.JS, immutable.js, web components, flux, tests, PRPL pattern, back-end APIs (node.JS/python), MongoDB, and a lot of tools/good practices for web applications!

Conclusion

I finish this blog post complementing the first paragraph:

One of the best decisions in my developer career was to go beyond just using tools, I decided to create them.

Thanks a lot for reading my first English blog post.

If you liked this content, follow me on Github and/or Twitter 💜.

Cheers.

Arquitetura para aplicações REST com express (node.js) #01: Cada escolha uma renúncia

Afonso Pacifer — Wed, 19 Feb 2020 21:22:40 +0000

Iniciar um projeto de API REST usando Node.js geralmente é algo rápido e relativamente fácil. Você escolhe um framework, lê um artigo e mete bronca no hello world. Simples assim 👍.

Porém, algo não muito difundido no mundo "javascripteiro" do Node.js é que, ao escolher um framework para trabalhar você meio que escolhe automaticamente uma filosofia de arquitetura para seguir. Mesmo que, no caso do Express, a escolha seja não ter arquitetura 👀.

É complicado entender a necessidade de algo que não temos, nunca vimos ou ouvimos falar. Para termos o que comparar, vou apresentar um conceito que é um dos pilares do famoso e super desenvolvido Ruby on Rails.

Convenção sobre configuração

Por definição:

Convenção sobre configuração ou programação por convenção (do inglês Convention over configuration - CoC) é um modelo de desenvolvimento de software que busca diminuir o número de decisões que os desenvolvedores precisam tomar. Visa ganhar simplicidade sem perder flexibilidade.

Fonte: wikipedia

Aplicação do conceito no mundo Rails

Diferente do processo padrão (que você aprende em tutoriais pela internet a fora), para iniciar uma API usando Express, ao iniciar um projeto usando Ruby on Rails você roda a ferramenta de linha de comando e faz scaffolding da base do projeto. Onde já temos toda a estrutura de pastas, padrões de nomenclatura e comunicação entre módulos pré definidos pelo framework:

$ rails new projeto

OBS: O exemplo abaixo é um resumo simplificado da estrutura do Rails. Para uma explicação melhor consulte a documentação oficial.

.
├── app/
|  ├-- assets/
|  ├── controllers/
|  ├── helpers/
|  ├── mailers/
|  ├── models/
|  └── views/
├── bin/
├── config/
├── db/
├── public/
├── test/
├── tmp/
├── vendor/
└── assets/

Isso traz algumas vantagens e desvantagens:

Vantagens

Como descrito na definição do conceito, ao ter uma arquitetura pré definida, o desenvolvedor não gasta seu tempo e energia decidindo coisas que não influenciam nas regras de negócio do projeto. Ou seja... Você consegue focar "no que importa" e ganha de brinde uma ótima arquitetura, testada por milhares de pessoas e amplamente documentada.

Exemplo da vida real

Imagine que você estude Ruby on Rails por cerca de 1 ano. Após esse período você inicia em um trabalho novo onde sua tarefa é ajudar no produto da empresa (que usa Ruby on Rails).

Eu garanto que, em poucos minutos, você consegue (a partir do seu conhecimento prévio) saber exatamente o que cada tipo de arquivo faz, como estão organizados e cada comando para executar o projeto.

Nesse cenário, você consegue "pular" a etapa de entender o projeto e consegue partir para uma entrega de valor em um tempo bem curto.

Desvantagens

Posso ser radical e dizer coisas como:

Em regimes ditatoriais é tirado o poder de escolha da população em prol de coisas como sua segurança e eficiência 👎.

Na China, por exemplo, a população escolheu abrir mão da própria "liberdade" em favor da segurança. Isso é uma boa troca? Para nosso caso é irrelevante! Mas entender que tirar o poder de escolha de alguém em prol de um ganho qualquer, sempre gera uma troca. Se vale a pena adotar essa escolha, só você pode responder 😱.

Sendo mais amigável posso dizer coisas como:

A partir do momento em que você aceita usar uma arquitetura pré pronta, você aceita uma listinha de desvantagens que vem junto. Temos como a mais notável a seguinte afirmação:

Cada projeto é um projeto, assumir que a mesma fórmula atende todos os casos é no mínimo ingenuidade 😑.

E o Express com isso?

Basicamente aprendemos a criar uma API de forma muito simples em um único arquivo ou, no máximo, com dois ou três tipos de arquivos (geralmente seguindo um MVC) que nos apresenta à uma filosofia totalmente oposta à escolhida pelo Rails. Finalmente lhes apresento o que torna a curva de aprendizado do Express tão interessante:

Definição do Express:

Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

fonte: expressjs.com

ou seja,

Aqui temos um framework totalmente flexível, que permite e estimula que o desenvolvedor crie e implemente sua própria arquitetura. Não importa o tamanho ou objetivo do projeto, você tem as ferramentas para organizar seu projeto da forma que melhor te atende.

Instale o Express:

$ npm install express

Crie um arquivo index.js:

const express = require('express')
const app = express()

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(3000, () => {
  console.log('Example app listening on port 3000!')
})

Execute o projeto:

$ node index.js

Pronto, temos uma API rodando plenamente.

OBS: Existe uma ferramenta de linha de comando que faz scaffolding no Express, porém ela não é focada em APIs e quase não é utilizada.

Com Express você tem o poder de fazer do seu jeito. Isso é incrível! Mas é aqui que mora o principal problema:

Desvantagens

Ter o poder de fazer as coisas do seu jeito, pode ser lido como: "Ter o poder de fazer merda" 💩.

Sim, é isso mesmo que você leu, a partir do momento em que você não delegou o trabalho de arquitetura para alguém que sabe o que está fazendo (mesmo que no caso do Rails tentando ser genérico para atender a todos os casos), fica muito fácil construir uma aplicação sem levar em consideração vários aspectos estruturais que são extremamente importantes. Principalmente se você pretende dar manutenção no projeto a longo prazo e em equipe.

Exemplo da vida real:

Imagine que você estude Express por cerca de 1 ano, após esse período, você inicia em um trabalho novo onde sua tarefa é ajudar no produto da empresa (que usa Express).

Eu garanto que o projeto está organizado de forma diferente do que você fez durante seus estudos, o que aumenta muito a curva de aprendizado para entregar algo de valor.

Vantagens

Obviamente, se você entende do que está fazendo, o poder de construir uma aplicação da forma que quiser é extremamente eficiente. É possível criar verdadeiras obras de arte em forma de arquitetura que vão poupar muitas horas e "dinheiros" a longo prazo. Isso inclui uma boa documentação, o que vai diminuir muito a curva de aprendizado de alguém novo no projeto, mitigando a principal desvantagem de um arquitetura "personalizada" 💚.

Claramente esse processo não é trivial, o que nos leva ao próximo tópico:

Requisitos

Chegamos à conclusão de que precisamos estudar bastante para entender o que estamos fazendo a nível de arquitetura.

Para criar um projeto que atende aos requisitos estruturais de uma boa arquitetura, primeiro precisamos saber quais são esses requisitos.

Vou compartilhar com vocês alguns dos meus objetivos ao criar um novo projeto:

Escalabilidade
- Separação de responsabilidades.
- Responsabilidade única.
Manutenibilidade
- Maior facilidade para criação de error handlers.
- Maior facilidade para escrita de testes automatizados.
Controllers isolados
- Todos os controllers são assíncronos.
- Facilidade para escrever validações.
Iterações em serviços de forma isolada
- Serviços síncronos e assíncronos.
- Múltiplos serviços para diferentes bancos de dados.
Error handler automático para todas as rotas

Essa listinha já é um bom ponto de partida para criar uma
aplicação com excelente qualidade (a de nível de arquitetura).

Agora precisamos entender cada um desses requisitos e como implementá-los na prática usando Express. Mas como esse texto já está muito longo vamos deixar isso para a parte 2.

Conclusão

"Cada escolha uma renúncia" é uma ótima frase para explicar esses processos de decisão.

Espero que eu tenha conseguido trazer algo de relevante para você que chegou até esse momento da leitura 😁.

Se você ficou animado ao ler esse artigo, deixe um comentário e um ❤️ para eu saber que tem alguém interessado e que vale a pena continuar a compartilhar esse tipo de conteúdo.

Um abraço e até a próxima.

DEV Community: Afonso Pacifer

Criando componentes para Web #01: Acessibilidade (a11y) na prática com WAI-ARIA

O que abordaremos nessa série?

Como vamos abordar cada assunto?

Roteiro genérico:

Introdução

Qual a importância da a11y?

Referências sobre a11y na Web

Aplicando na prática

Indo além com WAI-ARIA Roles

Vamos nos aprofundar com um exemplo mais crítico

Como testar

Dicas de especialista

Conclusão

5 ideas for personal projects using vanilla javascript

Cool ideas

A web framework for creating Back-End API's

A front-end Single Page App

A Command Line Tool (CLI) to control your GitHub account

A Chrome extension boilerplate

A Github Chat Bot

The gold rule

The real gold rule

Conclusion

How you can stay motivated to work on personal projects

What keeps you motivated?

Tips to complete your side project

Think hard if you really want to do a project

Create a checklist and follow it

Have a generic boilerplate

Don't try to learn more than one new technology at the same time

Dedicate time (with quality) to your project

Define a scope for the project and follow it

Share

Conclusion

How I became a senior javascript developer with personal projects

Everything can be summed up in short words

My first big challenge with a personal project

Banana CSS

Going deep in front-end development.

millenium.js

Using my passions to explore new things

burnout.js

Triggers for projects from projects

N.O.M.s

Was it worth reinventing the wheel?

Conclusion

Arquitetura para aplicações REST com express (node.js) #01: Cada escolha uma renúncia

Convenção sobre configuração

Aplicação do conceito no mundo Rails

Vantagens

Exemplo da vida real

Desvantagens

Posso ser radical e dizer coisas como:

Sendo mais amigável posso dizer coisas como:

E o Express com isso?

Desvantagens

Exemplo da vida real:

Vantagens

Requisitos

Conclusão

Indo além com `WAI-ARIA Roles`