Forem: Rodrigo Castro

[Boost]

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

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

Shayan ・ Sep 4

#webdev #programming #javascript #ai

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.

Forem: Rodrigo Castro

[Boost]

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

Shayan ・ Sep 4

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`