Pare pra pensar: o core do trabalho do front-end se resume em duas partes:

• implementação do layout: produção da primeira camada de código, onde replicamos o layout criado em algum programa gráfico, para código estático em HTML, CSS e JS.
• integração com API: depois (ou junto, tanto faz) de feito o código estático, a interface é integrada com a API, que geralmente carrega boa parte da lógica, já que essa mesma API é usada para alimentar outras plataformas como mobile, robôs etc.

As outras “responsabilidades” que orbitam em volta do front-end como acessibilidade, SEO, performance, compatibilidade entre browsers, código semântico, entre outras coisas que você pode julgar serem de responsabilidade de um front-end são um mero apetrecho. Elas podem existir ou não em um projeto. Mas um projeto não sobrevive sem o código front-end do layout e sem o conteúdo integrado à interface.

Um observação: acessibilidade é algo que as máquinas podem fazer muito melhor que um ser humano. Embora eu tenha colocado como algo que possa existir ou não em um projeto, é importante demais que você faça um esforço para que todos os seus projetos sejam acessíveis. Eu sei que isso não é a realidade até hoje no mercado e provavelmente nunca será até que esse processo seja automatizado.

Existem uma série de tarefas manuais que nós delegamos para ferramentas criadas afim de economizar parte do nosso tempo evitando a execução de tarefas repetitivas, automatizando o workflow do front-end. Só para citar algumas:

• Pre-processadores CSS: Sass, Less, Stylus
• Task runners: Gulp, Grunt , Make, NPM Scripts
• Scaffolding: Yeoman, Slush
• Dependências/Module Bundles: Bower, NPM, Yarn, Webpack, Duo, RequireJS, Browserify, JSPM, Rollup
• SPA/Libraries/Frameworks: React, Angular, Vue.js, Backbone, EmberJS, todomvc, Polymer, Lodash, Aurelia, MeteorJS
• CSS Frameworks/Libraries: SemanticUI, Bootstrap, Foundation, UiKit, YUI, Susy
• JS Test: Mocha, Jasmine, QUnit, Ava, Tape, Jest
• JS Templates: Underscore, Mustache, Handlebars, DoT, Dust, EJS

Mas mesmo com todas essas ferramentas, o core da responsabilidade de um front-end ainda continua sendo implementar layout original e integrar a interface com o back-end. Você ainda continua replicando o layout que alguém passou dias desenhando e integra o conteúdo que está numa API, que outra pessoa criou. Seu dia se resume em alternar entre as janelas do Sublime / Sketch / Browser / Sublime / API / Browser / Sublime.

“Automation isn’t about being lazy. It’s about being efficient.” — Addy Osmani

Esse processo se torna tedioso e a lista de requisitos para tentar tornar o trabalho de front-end eficiente só aumenta. Toda tarefa mecânica, repetitiva e manual tende a ser automatizada e na minha opinião, em pouco tempo, não vamos precisar de alguém executando o trabalho de front-end de ponta a ponta.

Okay, respira. Isso é a minha opinião. Dado que o front-end é a parte mais operacional de todo o processo, mais cedo ou mais tarde todo o trabalho executado no front-end vai ser automatizado. A parte mais difícil são essas duas tarefas que nós fazemos desde os primórdios. Contudo, elas já podem estar com seus dias contados.

Trabalhando com dados reais direto no Design

Você pode não ser designer, mas há uma premissa no mundo dos designers que diz que você deve trabalhar sempre com conteúdo real. Isso quer dizer que entregar um layout com texto em Lorem Ipsum Dolor é coisa de designer júnior.

“If your site or application requires data input, enter real and relevant words and type the text, don’t just paste it in from another source.” — Jason Fried

A ideia é que você crie um layout da forma mais fiel possível usando os termos, palavras, nomes, datas etc, a fim de chegar mais perto da experiência do usuário.

Atualmente a maioria dos programas visuais utilizados para criar layouts para web tem alguma feature ou plugin que permite a integração com alguma fonte de dados que contenha o conteúdo real.

Por exemplo o Sketch, que é o programa de criação visual mais querido do momento, conta com plugins que permitem a integração direta entre API e layout. Veja por exemplo o vídeo abaixo demonstrando a utilização do plugin Craft (também disponível para Photoshop):

Ou essa demonstração que usa a API do Stackoverflow:

Em pouco tempo, não vamos precisar de alguém executando o trabalho de front-end de ponta a ponta.

O ponto aqui é: nós só precisamos criar o layout uma vez, usando o programa desejado (Sketch/Photoshop/Figma/Adobe XD etc) e pronto. Não precisamos de uma pessoa para refazer esse layout com HTML/CSS/JS de forma alguma. Isso nos leva para uma segunda discussão: mesmo com o design pronto, usando dados reais de uma API, nós ainda precisamos que ele seja acessível pelos browsers. Como resolvemos isso?

Obs.: E aquele movimento do “Design in the Browser”? Esse é um movimento criado exatamente para evitar o trabalho de produzir duas vezes o mesmo layout. Mas é MUITO melhor fazer um design usando um programa visual do que escrever direto no código. IMHO.

https://tableless.com.br/carreira-de-front-end-vai-morrer/

Graceful Service Degradation

One of the best advantages of a microservices architecture is that you can isolate failures and achieve graceful service degradation as components fail separately. For example, during an outage customers in a photo sharing application maybe cannot upload a new picture, but they can still browse, edit and share their existing photos.

Change Management – Rolling Deployment

Health-check and Load Balancing

Modern service discovery solutions continuously collect health information from instances and configure the load-balancer to route traffic only to healthy components.

Self-healing

Failover Caching

Retry Logic

As a retry is initiated by the client (browser, other microservices, etc.) and the client doesn’t know that the operation failed before or after handling the request, you should prepare your application to handle idempotency. For example, when you retry a purchase operation, you shouldn’t double charge the customer. Using a unique idempotency-key for each of your transactions can help to handle retries.

Rate Limiters and Load Shedders

Fail Fast and Independently

Bulkheads

Circuit Breakers

Testing for Failures

Outro

Key Takeways

https://blog.risingstack.com/designing-microservices-architecture-for-failure/