DEV Community: Rodrigo Castro

Você sabe como funcionam os super apps chineses? Um estudo com Flutter

Rodrigo Castro — Sun, 13 Sep 2026 22:35:32 +0000

Você já deve ter ouvido que "o WeChat é seu WhatsApp, seu banco e seu Uber, tudo no mesmo app". Essa comparação vende bem a ideia pra quem nunca usou um super app chinês, mas é só a superfície. Por trás dela existe uma decisão de arquitetura de software bem específica, que a maioria dos artigos sobre "super apps em Flutter" nunca chega a explicar: como um único aplicativo consegue rodar dezenas de milhares de serviços de terceiros sem que cada atualização passe pela App Store?

Neste artigo eu saio do discurso de produto e vou direto pra arquitetura: como o WeChat, o Alipay e o Douyin resolvem isso tecnicamente, por que essa solução não é replicável com Flutter puro, e o que dá pra construir de fato quando o objetivo é ter vários serviços dentro do mesmo app.

Sumário

O que é, tecnicamente, um super app
Por que não existe "Flutter dinâmico" dentro de um super app
A arquitetura real: shell nativo, engine e JSBridge
O que dá (e o que não dá) pra fazer com Flutter
O que já existe pronto (e em produção) no ecossistema Flutter
Quatro caminhos 100% Flutter pra mini-apps dinâmicos
Conclusão

O que é, tecnicamente, um super app

Um super app não é só "um app grande com muitas telas". É uma plataforma com três camadas bem definidas:

Host / shell: o app que o usuário baixa da loja. Cuida de autenticação, pagamentos, permissões de sistema (câmera, localização) e a navegação de topo.
Runtime de mini-programs: um motor embarcado dentro do shell, capaz de executar código de terceiros de forma isolada e segura.
Mini-programs: os "apps dentro do app", desenvolvidos por times internos ou parceiros externos, publicados e atualizados sem passar pela App Store ou pela Play Store.

A peça que faz tudo funcionar é o runtime, e é exatamente aí que mora a pegadinha.

Por que não existe "Flutter dinâmico" dentro de um super app

A primeira pergunta que todo dev Flutter faz é: dá pra empacotar cada mini-app como um módulo Dart e carregar isso dinamicamente, tipo dynamic feature modules do Android?

Não, e o motivo não é técnico, é de política de loja. A Guideline 2.5.2 da Apple determina que um app precisa ser autocontido e não pode baixar, instalar ou executar código que introduza ou altere funcionalidades depois da revisão. Historicamente, a única brecha aceita era pra scripts interpretados rodando dentro do WebKit ou do JavaScriptCore embutidos no próprio iOS, desde que não mudassem o propósito principal do app declarado na loja. Um binário Dart compilado em AOT não se encaixa nessa brecha porque é código nativo, não interpretado por uma engine do sistema. Vale registrar que essa é uma área juridicamente sensível: a Apple já entrou em atrito público com a categoria de mini-programs mais de uma vez, e a fiscalização sobre esse tipo de download de código só ficou mais rígida nos últimos anos.

É por isso que nenhum super app chinês executa Flutter, React Native ou qualquer framework compilado nativamente dentro dos seus mini-programs. Cada gigante resolveu isso com sua própria engine de script embarcada:

WeChat (framework MINA): separa a aplicação em duas threads. A camada de renderização (WXML/WXSS) roda dentro de uma WebView, enquanto a camada lógica (o JS do desenvolvedor) fica isolada numa thread JSCore, um motor JS puro, sem acesso a DOM ou window. Essa separação existe por segurança, já que o código de terceiros nunca toca a UI diretamente, e por performance, porque a UI não trava esperando o JS de negócio processar.
Alipay (framework APPX + V8 Worker): foi além. Cada mini-program roda seu próprio script de renderização (index.js, executado em WebView) e seu próprio script de lógica de negócio (index.worker.js, executado como Worker sobre uma engine V8 dedicada). Essa arquitetura permite inicializar a WebView e a engine V8 em paralelo, isola o JS do framework do JS do desenvolvedor em contextos V8 separados, e ainda expõe uma JSAPI pra plugins nativos se conectarem ao contexto de execução.
Já o Douyin usa a mesma arquitetura de base do WeChat: a documentação oficial da plataforma de mini-programs do Douyin descreve o framework como dividido em camada lógica (JS Core) e camada de renderização (WebView), com uma linguagem de marcação própria (TTML/TTSS) equivalente ao WXML/WXSS do WeChat. Vale um adendo importante aqui: a ByteDance também abriu o código de um framework chamado Lynx, com uma arquitetura de duas threads mais sofisticada (motor JS PrimJS, camada declarativa ReactLynx, bundler Rspeedy em Rust), e a própria empresa o posiciona como concorrente direto do React Native e do Flutter. Mas o Lynx resolve outro problema: ele é usado pra construir os próprios apps nativos da ByteDance (o TikTok e o Douyin em si), não é o runtime que executa os mini-programs de terceiros dentro do Douyin.

O padrão que aparece nesses três casos é o mesmo: renderização e lógica de negócio rodam em threads ou contextos separados, e o código do mini-program é sempre interpretado em runtime por uma engine embarcada no shell. Nunca compilado nativamente e instalado como um binário à parte. Vale notar que Douyin e WeChat convergem quase pro mesmo modelo (JS Core + WebView), enquanto o Alipay foi o que mais se diferenciou tecnicamente, com a arquitetura V8 Worker rodando em paralelo.

Vale um adendo: desde 2019 existe um grupo de trabalho do W3C, o MiniApps Working Group, com Alibaba, Baidu, Huawei e Xiaomi entre os participantes, tentando padronizar esse ecossistema fragmentado, definindo um formato comum de empacotamento, manifest e ciclo de vida pra mini-apps. Ainda não existe interoperabilidade real entre WeChat, Alipay e Douyin, mas isso já mostra que o problema é reconhecido como grande demais pra cada vendor resolver sozinho.

A arquitetura real: shell nativo, engine e JSBridge

Descrevendo em camadas, um super app chinês típico se parece com isto:

O componente crítico é o JSBridge: uma camada de comunicação bidirecional entre o código JS do mini-program e o código nativo do shell. Quando um mini-program precisa abrir a câmera, ele não acessa o hardware diretamente. Ele chama uma função exposta pelo bridge, que delega pro código nativo, executa a operação e retorna o resultado de forma assíncrona, geralmente via postMessage ou um canal equivalente ao JavascriptChannel do webview_flutter.

Isso resolve dois problemas de uma vez:

Segurança: o mini-program nunca tem acesso irrestrito ao sistema, só ao que o bridge decide expor.
Atualização independente: como o mini-program é só um bundle JS/HTML baixado de um CDN, ele pode ser atualizado a qualquer momento sem passar por revisão de loja. É isso que permite ter dezenas de milhares deles rodando ao mesmo tempo.

O que dá (e o que não dá) pra fazer com Flutter

Aqui está a distinção mais importante do artigo, e que normalmente fica confusa: existem dois problemas diferentes escondidos atrás do termo "super app", e Flutter resolve muito bem um deles.

Problema 1: "quero um app só com muitos serviços internos, desenvolvidos e publicados pelo meu próprio time."

Isso é um monólito modular, e o Flutter é excelente nisso. Cada serviço vira um pacote Dart independente, organizado num monorepo com Melos, um formato de estrutura que já é padrão de mercado:

meu_super_app/
├── apps/
│   └── shell/              # app host
├── packages/
│   ├── core/               # DI, network, storage
│   ├── design_system/      # UI compartilhada
│   ├── carteira/
│   ├── chat/
│   └── perfil/
└── melos.yaml

Um contrato comum (abstract class Module { routes(); dependencies(); initialize(); }) define como cada módulo se registra no shell.
O roteamento é federado com GoRouter: cada módulo expõe suas próprias rotas, o shell as agrega numa GoRouter raiz, normalmente usando ShellRoute pra manter uma navegação comum.
A comunicação entre módulos nunca acontece por import direto, só por contratos definidos num pacote shared, navegação por rota nomeada e um event bus (Stream ou um Bloc global de eventos) pra avisos assíncronos entre módulos que não se conhecem.
Cada módulo mantém seu próprio escopo de estado (Bloc, Cubit ou Riverpod), evitando vazamento de estado global.

O resultado: você ganha modularização, times trabalhando em paralelo, testes isolados por pacote. Mas tudo ainda é compilado e publicado como um único binário, numa única versão, numa única submissão de loja.

Problema 2: "quero permitir que terceiros publiquem serviços dentro do meu app, atualizáveis sem passar pela loja."

Esse é o problema que o WeChat resolve, e o Flutter não resolve nativamente. Pra chegar perto disso você precisaria de:

Um shell Flutter (ou nativo) hospedando um WebView ou uma engine JS embarcada, algo como o flutter_js, que embute o QuickJS.
Mini-apps como bundles de HTML, CSS e JS baixados de um servidor próprio.
Um JSBridge implementado via JavascriptChannel do webview_flutter, expondo as APIs nativas que os mini-apps podem chamar.
Um sistema de catálogo controlando quais mini-apps existem, suas versões e permissões.

Nesse ponto a camada de UI dos seus mini-apps deixa de ser Flutter. Vira HTML e JS rodando dentro de uma WebView. Você está construindo, na prática, seu próprio mini runtime de mini-programs, não um app Flutter modular.

O que já existe pronto (e em produção) no ecossistema Flutter

Antes de fechar, vale mostrar que parte desse problema já tem solução real no mundo Flutter, só que resolvendo pedaços diferentes dele.

FlutterBoost, da Alibaba: é a peça que sustenta o "AliFlutter", a estratégia da própria Alibaba pra rodar Flutter em escala dentro do ecossistema de apps do grupo, incluindo o Xianyu (Idle Fish), um dos maiores apps Flutter em produção do mundo. A maioria dos apps da Alibaba usa uma pilha híbrida nativa mais Flutter, e o FlutterBoost existe justamente pra fazer telas nativas e telas Flutter conviverem no mesmo app, com uma única API de roteamento unificada e um canal de eventos (o BoostChannel) pra comunicação entre os dois lados. É o padrão mais próximo de "super app real em produção usando Flutter" que existe documentado, mas repare que ainda é modularização de containers dentro de um único binário, não mini-programs de terceiros publicados independentemente.
Shorebird: esse é o mais interessante pro debate da regra 2.5.2. Ele criou um mecanismo de code push pra Flutter, embarcando um Flutter engine modificado que roda o código Dart através da Dart VM de forma interpretada, permitindo enviar patches de código pro app em produção sem passar pela revisão da loja. Funciona porque, tecnicamente, o app "release" enviado pra loja já contém a engine capaz de interpretar bytecode Dart. O patch não instala um executável novo, só atualiza o que a VM interpreta, caindo na mesma exceção histórica que permite JS interpretado. É a prova de que essa exceção da Apple não é exclusiva de JavaScript. Mas hoje o Shorebird resolve "meu time quer atualizar meu próprio app sem esperar a loja", não "quero permitir que terceiros publiquem mini-apps dentro do meu app". São problemas parecidos na superfície, mas com modelos de confiança bem diferentes: um mexe no seu próprio código, o outro precisa de sandboxing de código de terceiros.

Juntando os dois: hoje, com ferramentas maduras do próprio ecossistema Flutter, já dá pra montar um monólito modular com atualização mais rápida que o ciclo normal de loja. Isso cobre muito bem o primeiro problema. O segundo, mini-programs de terceiros de verdade, continua exigindo uma camada de engine de script separada, como fazem WeChat, Alipay e Douyin.

Quatro caminhos 100% Flutter pra mini-apps dinâmicos, e o trade-off de cada um

Se o objetivo é ter mini-apps atualizáveis sem passar pela loja, mas sem sair do ecossistema Flutter, existem quatro caminhos reais.

Abordagem	Como funciona	Segurança jurídica (Apple)	Performance/peso	Consistência visual	Maturidade
Pacotes Dart (monólito modular)	Módulos compilados junto no binário, via monorepo e Melos	Nenhum risco, é código nativo revisado normalmente	Nativa, sem overhead	Perfeita, é tudo Flutter nativo	Alta, padrão de mercado
UI dirigida por dados (SDUI / GenUI SDK)	Servidor envia um JSON descrevendo a tela, montado sobre um catálogo de widgets já compilados no app	Nenhum risco, não há código sendo baixado, só dados (mesma categoria de remote config)	Leve, só trafega JSON	Perfeita, mas limitada ao catálogo de widgets já existente no app	Padrão testado há anos fora do Flutter (Airbnb, Spotify); dentro do Flutter, oficializado pelo Google via GenUI SDK, ainda em alpha
Interpretador Dart (`dart_eval`/`flutter_eval`)	Bytecode Dart baixado e interpretado dentro do próprio app, renderizando widgets reais	Zona cinzenta, os próprios mantenedores admitem incerteza e se apoiam no precedente do Hermes (React Native)	De 10 a 50 vezes mais lento que Dart AOT, comparável a Ruby, só no código interpretado	Perfeita, widgets Flutter reais	Baixa/média, projeto jovem, cobertura parcial da linguagem
Flutter Web dentro de WebView	Mini-app compilado pra Flutter Web (CanvasKit/Wasm), carregado via `webview_flutter` mais JSBridge	Sólida, é exatamente a exceção nomeada na Guideline 2.5.2 pra conteúdo web em WebView	Pesada, CanvasKit adiciona de 1.5 a 2MB de Wasm antes do primeiro pixel	Alta, mas com as costuras clássicas de WebView (scroll, teclado, gestos)	Alta, usa infraestrutura web madura, mas incomum nesse uso específico

O padrão que aparece na tabela não é uma linha reta simples entre "seguro e pesado" e "leve e arriscado". A UI dirigida por dados quebra essa lógica: ela é ao mesmo tempo a mais segura juridicamente e a mais leve tecnicamente, só que paga o preço em liberdade de expressão, não em performance ou compliance. Um mini-app SDUI não pode ter lógica de negócio própria nem widgets que o host não conhece de antemão. É ótimo pra telas guiadas, formulários, catálogos, checkouts simples, mas não serve pra um mini-program livre e arbitrário como os do WeChat.

Pra um MVP ou uma POC de portfólio, isso muda a decisão. Pacotes Dart continuam sendo o caminho certo pro primeiro problema, o de modularização interna. Se a ideia é demonstrar o segundo problema, o de mini-apps de terceiros, de forma defensável e com esforço razoável, a UI dirigida por dados é provavelmente o ângulo mais interessante pra mostrar hoje: é recente (o GenUI SDK do Google é literalmente de 2026), resolve o problema de compliance de forma elegante, e ainda dá gancho pra falar de IA generativa compondo UI, que é assunto quente. Flutter Web em WebView continua sendo a opção mais robusta quando o mini-app precisa de liberdade total de lógica.

Conclusão

"Super app" virou clichê de pitch de startup, mas por trás dele existem arquiteturas radicalmente diferentes. Se o objetivo é organizar um app grande com múltiplos serviços internos, o caminho é modularização séria: pacotes Dart, contratos, roteamento federado, event bus. Isso é 100% Flutter, sem gambiarra.

Se o objetivo é replicar o modelo chinês de verdade, com um ecossistema de mini-programs de terceiros atualizáveis sem loja, você está resolvendo um problema de plataforma: engine de script embarcada, bridge nativo, sandboxing. E o Flutter vira só a camada do shell, não a camada onde os serviços rodam.

Entender essa diferença antes de começar a arquitetar evita meses de decisões erradas. É esse tipo de clareza que separa uma implementação de portfólio de uma implementação de produção.

Este artigo é parte de um estudo prático que venho construindo em Flutter, explorando na prática os limites entre modularização de monólito e arquitetura real de mini-app.

Fontes técnicas: documentação oficial do WeChat Mini Program, documentação oficial da plataforma de mini-programs do Douyin, artigo da Alibaba Cloud sobre o V8 Worker do Alipay, repositório oficial do FlutterBoost no GitHub, site oficial do Lynx, MiniApps Working Group do W3C, documentação do Shorebird sobre code push em Flutter e documentação oficial do GenUI SDK for Flutter.

[Boost]

Rodrigo Castro — Fri, 05 Sep 2025 17:26:33 +0000

Shayan

Sep 4 '25

Stop Building for "Scale." You Don't Have Users Yet.

#webdev #programming #javascript #ai

6 min read

Microserviços Everywhere? Talvez seja hora de conhecer o Monólito Modular

Rodrigo Castro — Mon, 11 Aug 2025 20:35:20 +0000

A arquitetura que combina o melhor dos dois mundos e pode salvar seu próximo projeto

O Hype dos Microserviços

Vivemos em uma era onde falar de microserviços virou quase obrigatório em qualquer conversa sobre arquitetura de software. Netflix fez, Uber fez, então obviamente seu projeto também deveria começar com microserviços, certo?

Spoiler alert: Provavelmente não.

A realidade é que muitas empresas estão criando "microserviços distribuídos monolíticos" - sistemas complexos, difíceis de debuggar e manter, que herdam as desvantagens dos microserviços sem colher os benefícios.

A Síndrome do "Microserviços First"

Vamos ser honestos: quantos projetos você conhece que começaram "fazendo a coisa certa" com microserviços e acabaram assim:

❌ 5 serviços para um MVP que poderia ser uma única aplicação

❌ Transações distribuídas para operações que deveriam ser atômicas

❌ Debugging infernal espalhado por múltiplos logs

❌ Deploy complexo desde o dia 1

❌ Time perdido configurando infraestrutura ao invés de validar produto

"Premature optimization is the root of all evil" - Donald Knuth

Começar com microserviços é otimização prematura de arquitetura.

Por Que NÃO Começar com Microserviços?

1. Você Não É a Netflix (Ainda)

Netflix tem milhões de usuários simultâneos
Você provavelmente tem dezenas ou centenas
Eles têm centenas de desenvolvedores
Você tem 2-10 pessoas no time

2. Complexidade Desnecessária

Monólito: 1 deploy, 1 banco, 1 log
Microserviços: N deploys, N bancos, N logs, N configurações

3. Debugging Nightmare

Bug no monólito: Stack trace completo
Bug em microserviços: "Qual serviço quebrou? Em que ordem?"

4. Over-engineering do MVP

Você deveria estar validando seu produto, não configurando Kubernetes.

Conheça o Monólito Modular

E se eu te disser que existe uma arquitetura que combina:

✅ Simplicidade do monólito para desenvolver e deployar

✅ Organização dos microserviços para manter e escalar

✅ Flexibilidade para evoluir gradualmente

✅ Performance de transações locais

Essa arquitetura existe e se chama Monólito Modular.

Como Funciona?

Imagine uma aplicação Laravel organizada assim:

app/
├── Domains/
│   ├── User/          # Módulo de usuários
│   ├── Product/       # Módulo de produtos  
│   ├── Order/         # Módulo de pedidos
│   └── Payment/       # Módulo de pagamentos
├── Shared/            # Código compartilhado
└── Infrastructure/    # Concerns técnicos

Características Principais:

🔹 Um único aplicativo - Deploy simples, debugging fácil

🔹 Módulos bem definidos - Separação clara de responsabilidades

🔹 Comunicação via interfaces - Baixo acoplamento

🔹 Banco de dados compartilhado - ACID transactions

🔹 Migração gradual - Evolução para microserviços quando necessário

Vantagens Práticas

Para o Time

Onboarding rápido - Nova pessoa entende a estrutura em horas
Desenvolvimento ágil - Mudanças rápidas sem coordenação entre times
Debugging simples - Stack trace completo, logs centralizados

Para o Negócio

Time to market menor - Foco no produto, não na infraestrutura
Custos reduzidos - Menos complexidade = menos recursos
Validação rápida - Iterar rapidamente sobre features

Para a Arquitetura

Testabilidade - Testes integrados simples
Consistência - Transações ACID entre módulos
Flexibilidade - Migration path claro para microserviços

Quando Evoluir para Microserviços?

O monolito modular oferece um migration path natural:

Fase 1: Monólito modular
├── Validar produto
├── Crescer time
└── Identificar gargalos

Fase 2: Extração gradual
├── Módulo Payment → Microserviço
├── Módulo Notification → Microserviço  
└── Core continua monólito

Fase 3: Microserviços completos
└── Quando realmente justificar

Sinais de que é hora de extrair:

Módulo tem problemas de performance específicos
Time grande trabalhando no mesmo módulo
Escalabilidade diferente entre módulos
Tecnologia específica seria melhor para um módulo

Empresas que Usam (e Recomendam)

Shopify - Monólito modular gigante que atende milhões
GitHub - Rails monólito que escala massivamente
Basecamp - Defensores ferrenhos do monólito bem estruturado
Laravel (próprio framework) - Monólito modular por design

"The monolith isn't dead. It's just well-designed." - DHH, Basecamp

Implementação Prática

Estrutura de um Módulo:

app/Domains/Order/
├── Models/           # Entidades do domínio
├── Services/         # Regras de negócio
├── Repositories/     # Acesso a dados
├── Events/           # Eventos do domínio
├── Http/
│   ├── Controllers/  # Controllers REST
│   └── Livewire/     # Componentes TALL
└── Tests/           # Testes do módulo

Comunicação Entre Módulos:

// Via Service (síncrono)
$this->orderService->createOrder($data);

// Via Events (assíncrono) 
OrderCreated::dispatch($order);

Conclusão: Comece Simples, Escale Gradualmente

A pergunta não é: "Microserviços ou Monólito?"

A pergunta é: "Qual arquitetura me permite validar meu produto mais rápido?"

O monólito modular oferece:

Simplicidade para começar
Estrutura para crescer
Flexibilidade para evoluir

Seu próximo projeto provavelmente deveria começar como um monólito modular.

Depois, quando você tiver:

✅ Produto validado
✅ Time maior
✅ Problemas reais de escala

Aí sim considere microserviços.

E você, já experimentou o monólito modular? Compartilhe sua experiência nos comentários! 👇

Observers no Laravel

Rodrigo Castro — Sat, 26 Jul 2025 14:50:02 +0000

Se você já trabalhou com Laravel, provavelmente já precisou executar algumas ações automaticamente quando algo acontece com seus models. Criar logs quando um usuário é cadastrado, enviar emails quando um pedido é finalizado, ou limpar cache quando um produto é atualizado.

A solução mais óbvia seria colocar essa lógica diretamente nos controllers ou nos próprios models. Mas convenhamos, isso vira uma bagunça rapidinho.

Laravel Observers

Os Observers são como aquele amigo atento que sempre sabe quando algo acontece e age automaticamente. Eles "observam" os eventos do Eloquent (created, updated, deleted, etc.) e executam código específico para cada situação.

Na prática, como funciona?

Imagine que você tem um model User e quer enviar um email de boas-vindas sempre que alguém se cadastra:

Depois é só registrar no AppServiceProvider:

Por que usar Observers?

Primeiro, seu código fica muito mais organizado. Toda a lógica relacionada aos eventos do model fica concentrada em um lugar só. Segundo, você segue o princípio da responsabilidade única - o controller cuida da requisição, o model cuida dos dados, e o observer cuida dos efeitos colaterais. Terceiro ponto: testabilidade. É muito mais fácil testar um observer isoladamente do que toda a stack junta.

Dica de ouro

Use observers para ações que sempre devem acontecer, independente de onde o model foi alterado. Se a ação é específica de um contexto (tipo "enviar email só quando o admin cadastra"), talvez seja melhor manter no controller mesmo.

Conclusão

Os Observers são uma ferramenta poderosa para manter seu código Laravel limpo e organizável. Eles transformam aqueles "lembretes mentais" de executar certas ações em código automático e confiável.

Design System no Flutter

Rodrigo Castro — Mon, 22 Jul 2024 18:01:57 +0000

O desenvolvimento de aplicativos móveis eficazes requer não apenas uma base sólida em termos de funcionalidades, mas também uma abordagem coesa e consistente para o design da interface do usuário. Um Design System é fundamental para atingir esse objetivo, oferecendo um conjunto de padrões reutilizáveis e modularizados que promovem a consistência, eficiência e escalabilidade.

O que é um Design System?

Um Design System é um conjunto de padrões e componentes reutilizáveis que auxiliam no desenvolvimento de UIs padronizadas, bonitas e obviamente garantindo uma experiência consistente todas as partes de um produto Digital. No Flutter (ou em qualquer outro frontend), o design system faz com que nós devs foquemos mais em solucionar os requisitos funcionais e menos em construir as mesmas telas padronizadas para o nosso aplicativo.

1 - Configurando o projeto

Primeiro vamos criar um novo projeto, podemos criar dentro da pasta principal do app e/ou criar um package externo para ser reutilizável.

flutter create --template=package design_system

Isso cria a estrutura básica do package onde você pode começar a adicionar seus componentes e estilos.

2 - Definindo as diretrizes de design

Antes de começar a codar, defina as diretrizes de design que seu sistema seguirá. Isso inclui:
- Paleta de Cores: Defina cores primárias, secundárias, de fundo, de texto, etc.
- Tipografia: Escolha fontes, tamanhos e estilos de texto.
- Componentes Personalizáveis: Flutter permite criar componentes altamente personalizáveis e reutilizáveis.

3 - Estruturando o package

Organize seu package de maneira que seja fácil de entender e manter. Uma estrutura comum pode ser:

lib/
├── src/
│   ├── components/
│   │   └── button.dart
│   ├── theme/
│   │   ├── colors.dart
│   │   ├── text_styles.dart
│   │   └── theme.dart
│   └── utils/
│       └── spacing.dart
└── design_system.dart

4 - Criando paleta de cores

No arquivo lib/src/theme/colors.dart, defina sua paleta de cores:

import 'package:flutter/material.dart';

class AppColors {
  static const Color primary = Color(0xFF6200EE);
  static const Color primaryVariant = Color(0xFF3700B3);
  static const Color secondary = Color(0xFF03DAC6);
  static const Color secondaryVariant = Color(0xFF018786);
  static const Color background = Color(0xFFFFFFFF);
  static const Color surface = Color(0xFFFFFFFF);
  static const Color error = Color(0xFFB00020);
  static const Color onPrimary = Color(0xFFFFFFFF);
  static const Color onSecondary = Color(0xFF000000);
  static const Color onBackground = Color(0xFF000000);
  static const Color onSurface = Color(0xFF000000);
  static const Color onError = Color(0xFFFFFFFF);
}

No flutter 0xFF representa uma cor hexadecimal

5 - Definindo estilos de texto

No arquivo lib/src/theme/text_styles.dart, defina seus estilos de texto:

import 'package:flutter/material.dart';

class TextStyles {
  static const TextStyle headline1 = TextStyle(
    fontSize: 96,
    fontWeight: FontWeight.bold,
    color: Colors.black,
  );
  static const TextStyle bodyText1 = TextStyle(
    fontSize: 16,
    color: Colors.black,
  );
  // Adicione mais estilos conforme necessário
}

6 - Criando um tema

No arquivo lib/src/theme/theme.dart, defina seu tema:

import 'package:flutter/material.dart';

import 'colors.dart';
import 'text_styles.dart';

class AppTheme {
  static ThemeData get lightTheme {
    return ThemeData(
      primaryColor: AppColors.primary,
      primaryColorLight: AppColors.primaryVariant,
      textTheme: const TextTheme(
        displayLarge: TextStyles.headline1,
        bodyLarge: TextStyles.bodyText1,
      ),
      colorScheme: ColorScheme.fromSwatch().copyWith(
        secondary: AppColors.secondary,
        surface: AppColors.background,
      ),

      // Adicione mais customizações conforme necessário
    );
  }
}

7 - Criando componentes reutilizáveis

No arquivo lib/src/components/button.dart, crie um componente de botão personalizado:

import 'package:flutter/material.dart';

import '../theme/colors.dart';

class CustomButton extends StatelessWidget {
  final String label;
  final VoidCallback onPressed;

  const CustomButton({super.key, required this.label, required this.onPressed});

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      style: ElevatedButton.styleFrom(
        backgroundColor: AppColors.primary,
        padding: const EdgeInsets.symmetric(vertical: 16, horizontal: 32),
        // Adicione mais propriedades de estilo conforme necessário
      ),
      onPressed: onPressed,
      child: Text(
        label,
        style: const TextStyle(color: AppColors.onPrimary),
      ),
    );
  }
}

8 - Exportando seu design system
No arquivo lib/design_system.dart, exporte todas as suas definições:

library design_system;

export 'src/components/button.dart';
export 'src/theme/colors.dart';
export 'src/theme/text_styles.dart';
export 'src/theme/theme.dart';

9 - Usando o Design System em um projeto

dependencies:
  flutter:
    sdk: flutter
  design_system:
    path: ./design_system

Em seu projeto, importe e utilize o Design System:

import 'package:flutter/material.dart';
import 'package:design_system/design_system.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: AppTheme.lightTheme,
      home: Scaffold(
        appBar: AppBar(title: Text('Design System Example')),
        body: Center(
          child: CustomButton(
            label: 'Press Me',
            onPressed: () {},
          ),
        ),
      ),
    );
  }
}

Conclusão

Criar um Design System no Flutter permite uma estrutura modular e reutilizável. Isso facilita a manutenção e a escalabilidade do seu aplicativo, garantindo uma experiência de usuário consistente e de alta qualidade. Com as diretrizes e componentes bem definidos, você pode rapidamente aplicar seu Design System em diferentes projetos e manter a uniformidade visual e funcional.

Server Driven UI no Flutter?

Rodrigo Castro — Wed, 29 May 2024 11:04:15 +0000

O Server Driven UI (SDUI) no Flutter surge como um game-changer no cenário do desenvolvimento de aplicativos. Ao transferir a lógica da interface para o servidor, abre-se um universo de possibilidades para criar interfaces mais dinâmicas, personalizadas e eficientes. Imagine um app que se adapta em tempo real às suas necessidades, sem a necessidade de constantes atualizações. É isso e muito mais que o SDUI no Flutter oferece!

game-changer se refere a um “divisor de águas”, ou seja, algo que revoluciona e muda completamente um determinado mercado ou situação.

O que é Server Driven UI?

Em contraste com a abordagem tradicional, onde a interface do usuário (UI) é definida no cliente (aplicativo móvel), o SDUI transfere a responsabilidade para o servidor. Isso significa que o servidor gera e envia a estrutura da UI para o aplicativo, que a renderiza na tela do dispositivo. Essa inversão de controle traz diversos benefícios:

Maior Agilidade e Flexibilidade:

Desenvolvimento e testes mais rápidos: Alterações na UI podem ser implementadas no servidor e propagadas instantaneamente para todos os usuários, sem a necessidade de atualizações de aplicativos.
Experiência do usuário aprimorada: A UI pode ser personalizada em tempo real, de acordo com o perfil e contexto de cada usuário.
Redução de custos de desenvolvimento: O código da UI é centralizado no servidor, diminuindo a duplicação de esforços e otimizando o processo de desenvolvimento.

Mas nem tudo são flores...

Desafios e Considerações:

Implementação
- Arquitetura robusta: O servidor precisa ter capacidade de processar e enviar as informações da UI de forma eficiente, especialmente para um grande número de usuários simultâneos.
- Comunicação confiável: A comunicação entre o servidor e o aplicativo deve ser segura e resiliente a falhas de rede.
- Segurança de dados: É crucial implementar medidas de segurança rigorosas para proteger os dados dos usuários e evitar acessos não autorizados.
Experiência do usuário
- Latência: A latência na comunicação entre o servidor e o aplicativo pode afetar a fluidez da UI.
- Conectividade: O SDUI depende de uma conexão de internet estável para funcionar corretamente.
- Acessibilidade: É importante garantir que a UI gerada pelo servidor seja acessível a todos os usuários, incluindo aqueles com deficiências.

Exemplos de Bibliotecas SDUI para Flutter:

Mirai
server_driven_ui

Exemplo utilizando o Mirai:

Servidor:

{
"type": "scaffold",
"appBar": {
"type": "appBar",
"title": {"type": "text", "data": "Cards"}
},
"body": {
"type": "column",
"mainAxisAlignment": "start",
"crossAxisAlignment": "center",
"children": [
  {"type": "sizedBox", "height": 12},
  {
    "type": "card",
    "elevation": 20,
    "borderOnForeground": true,
    "margin": {"top": 20, "bottom": 20, "right": 20, "left": 20},
    "child": {
      "type": "listTile",
      "leading": {
        "type": "image",
        "src": "https://avatars.githubusercontent.com/u/31713982?v=4",
        "width": 50,
        "height": 50
      },
      "title": {
        "type": "padding",
        "padding": {"top": 10},
        "child": {
          "type": "text",
          "data": "Rodrigo Castro",
          "align": "center",
          "style": {"fontSize": 21}
        }
      },
      "subtitle": {
        "type": "padding",
        "padding": {"top": 10, "bottom": 10},
        "child": {
          "type": "text",
          "data":
              "Desenvolvedor de Software com foco em Laravel e Flutter. (Open to Work)",
          "align": "center",
          "style": {"fontSize": 12}
        }
      }
    }
  }
]
}

Flutter:

Conclusão:

O SDUI no Flutter se apresenta como uma ferramenta poderosa para impulsionar a inovação e criar experiências de usuário excepcionais. Ao abraçar essa abordagem com cautela e planejamento estratégico, os desenvolvedores terão a oportunidade de revolucionar o cenário de desenvolvimento de aplicativos.

Para se aprofundar no assunto:

Como abstrair sua aplicação flutter para não depender de packages

Rodrigo Castro — Fri, 17 May 2024 15:52:45 +0000

Flutter, o framework de UI do Google para criar aplicativos multiplataforma, é conhecido por sua extensa coleção de pacotes que simplificam o desenvolvimento. No entanto, confiar demais em pacotes pode tornar seu projeto vulnerável a problemas como descontinuação de pacotes, falta de manutenção ou incompatibilidades futuras. Abstrair sua aplicação para minimizar a dependência de pacotes pode aumentar a longevidade e a estabilidade do seu projeto. Neste artigo, vamos explorar estratégias para alcançar isso.

Tópicos

Entenda suas Necessidades
Use Interfaces para Abstração
Implementação Própria de Funcionalidades Simples
Módulos de Serviço
Conclusão

Entenda Suas Necessidades

Antes de decidir abstrair seu aplicativo, é crucial entender as necessidades específicas do seu projeto. Nem todos os pacotes são iguais e alguns fornecem funcionalidades complexas que podem ser difíceis de replicar. Avalie se a funcionalidade fornecida pelo pacote é algo que você pode ou deve implementar por conta própria.
Pergunte-se:

Este pacote é crucial para a funcionalidade principal do meu aplicativo?
A funcionalidade é complexa ou pode ser implementada com uma solução personalizada?
O pacote tem uma alta probabilidade de ser descontinuado?

Com essas informações em mãos, podemos elaborar algumas estratégias para o seu desacoplamento:

Use Interfaces para Abstração

Uma das melhores práticas para reduzir a dependência de pacotes é usar interfaces para definir a funcionalidade necessária. Em vez de depender diretamente de uma implementação de um pacote, você pode definir uma interface que descreve o comportamento necessário e, em seguida, fornecer uma implementação concreta que utiliza o pacote.

Exemplo

// Definindo a interface
abstract class LocalStorage {
  Future<void> saveData(String key, String value);
  Future<String?> getData(String key);
}

// Implementação usando um pacote (por exemplo, SharedPreferences)
class SharedPreferencesStorage implements LocalStorage {
  final SharedPreferences _prefs;

  SharedPreferencesStorage(this._prefs);

  @override
  Future<void> saveData(String key, String value) async {
    await _prefs.setString(key, value);
  }

  @override
  Future<String?> getData(String key) async {
    return _prefs.getString(key);
  }
}

Dessa forma, você pode facilmente substituir SharedPreferencesStorage por outra implementação sem alterar o restante do código que depende de LocalStorage.

Implementação Própria de Funcionalidades Simples

Para funcionalidades simples, considere implementar você mesmo em vez de usar um pacote. Por exemplo, se você precisa apenas de uma solução simples de cache ou armazenamento local, pode ser mais fácil escrever sua própria implementação do que depender de um pacote.

Exemplo de Cache Simples

// Define a classe SimpleCache
class SimpleCache {
// Cria um mapa privado para armazenar pares de chave-valor  
  final Map<String, String> _cache = {};
// Método para adicionar dados ao cache
  void saveData(String key, String value) {
    _cache[key] = value;
  }
// Método para recuperar dados do cache
  String? getData(String key) {
    return _cache[key];
  }
}

Módulos de Serviço

Separar a lógica de negócios em módulos de serviço pode ajudar a reduzir a dependência de pacotes. Esses módulos podem fornecer abstração sobre qualquer funcionalidade de terceiros, permitindo que você mude facilmente a implementação sem impactar outras partes do código.

Exemplo

// Define a classe AuthService
class AuthService {
  // Cria uma instância privada de FirebaseAuth
  final FirebaseAuth _firebaseAuth;

  // Construtor que aceita uma instância de FirebaseAuth
  AuthService(this._firebaseAuth);

  // Método para autenticar um usuário com email e senha
  Future<User?> signIn(String email, String password) async {
    try {
      // Tenta autenticar o usuário com email e senha
      UserCredential userCredential = await _firebaseAuth.signInWithEmailAndPassword(email: email, password: password);
      // Se a autenticação for bem-sucedida, retorna o User
      return userCredential.user;
    } catch (e) {
      // Se ocorrer um erro, imprime o erro e retorna null
      print("Error: $e");
      return null;
    }
  }

  // Método para deslogar o usuário atual
  Future<void> signOut() async {
    await _firebaseAuth.signOut();
  }
}

Aqui, AuthService abstrai a implementação do FirebaseAuth, permitindo que você substitua facilmente _firebaseAuth por outra solução de autenticação no futuro.

Gerenciamento de Estado Independente de Pacotes

O gerenciamento de estado é uma área onde muitos desenvolvedores dependem de pacotes como Provider, Bloc ou Riverpod. No entanto, é possível gerenciar o estado de forma eficiente sem depender de pacotes externos, utilizando apenas as funcionalidades nativas do Flutter, como InheritedWidget, ChangeNotifier e ValueNotifier.

Exemplo usando `ChangeNotifier`

// Define a classe Counter que notifica os ouvintes quando o valor do contador muda
class Counter with ChangeNotifier {
  // Inicializa o contador como 0
  int _count = 0;

  // Getter para obter o valor atual do contador
  int get count => _count;

  // Método para incrementar o contador
  void increment() {
    _count++;  // Incrementa o contador
    notifyListeners();  // Notifica os ouvintes sobre a mudança
  }
}

// Define a classe CounterProvider que fornece uma instância de Counter para seus descendentes
class CounterProvider extends InheritedWidget {
  // Mantém uma referência para a instância de Counter
  final Counter counter;

  // Construtor que aceita um filho e uma instância de Counter
  CounterProvider({Key? key, required Widget child, required this.counter}) : super(key: key, child: child);

  // Método para obter a instância mais próxima de CounterProvider na árvore de widgets
  static CounterProvider? of(BuildContext context) {
    return context.dependOnInheritedWidgetOfExactType<CounterProvider>();
  }

  // Método para determinar se este widget deve notificar seus descendentes quando é reconstruído
  @override
  bool updateShouldNotify(CounterProvider oldWidget) {
    // Retorna true se a instância de Counter mudou
    return counter != oldWidget.counter;
  }
}

Conclusão

Abstrair sua aplicação Flutter para não depender de pacotes envolve um equilíbrio entre reutilização de código e a criação de uma base sólida e independente. Usando interfaces, implementando funcionalidades simples por conta própria e separando a lógica em módulos de serviço, você pode reduzir a dependência de pacotes externos e aumentar a flexibilidade e a longevidade do seu projeto. Adotar essas práticas pode exigir um esforço adicional no início, mas os benefícios a longo prazo de um código mais limpo e sustentável valem a pena.

DEV Community: Rodrigo Castro

Você sabe como funcionam os super apps chineses? Um estudo com Flutter

Sumário

O que é, tecnicamente, um super app

Por que não existe "Flutter dinâmico" dentro de um super app

A arquitetura real: shell nativo, engine e JSBridge

O que dá (e o que não dá) pra fazer com Flutter

O que já existe pronto (e em produção) no ecossistema Flutter

Quatro caminhos 100% Flutter pra mini-apps dinâmicos, e o trade-off de cada um

Conclusão

[Boost]

Stop Building for "Scale." You Don't Have Users Yet.

Microserviços Everywhere? Talvez seja hora de conhecer o Monólito Modular

O Hype dos Microserviços

A Síndrome do "Microserviços First"

Por Que NÃO Começar com Microserviços?

1. Você Não É a Netflix (Ainda)

2. Complexidade Desnecessária

3. Debugging Nightmare

4. Over-engineering do MVP

Conheça o Monólito Modular

Como Funciona?

Características Principais:

Vantagens Práticas

Para o Time

Para o Negócio

Para a Arquitetura

Quando Evoluir para Microserviços?

Sinais de que é hora de extrair:

Empresas que Usam (e Recomendam)

Implementação Prática

Estrutura de um Módulo:

Comunicação Entre Módulos:

Conclusão: Comece Simples, Escale Gradualmente

Observers no Laravel

Design System no Flutter

O que é um Design System?

Conclusão

Server Driven UI no Flutter?

O que é Server Driven UI?

Maior Agilidade e Flexibilidade:

Desafios e Considerações:

Exemplos de Bibliotecas SDUI para Flutter:

Exemplo utilizando o Mirai:

Conclusão:

Para se aprofundar no assunto:

Como abstrair sua aplicação flutter para não depender de packages

Tópicos

Entenda Suas Necessidades

Use Interfaces para Abstração

Exemplo

Implementação Própria de Funcionalidades Simples

Exemplo de Cache Simples

Módulos de Serviço

Exemplo

Gerenciamento de Estado Independente de Pacotes

Exemplo usando ChangeNotifier

Conclusão

Exemplo usando `ChangeNotifier`