Design ou modelagem de tópicos

É uma experiencia muito legal modelar os tópicos para a sua solução usando IOT. Se você está começando agora, os dispositivos podem assinar e também publicar em um tópico ou vários tópicos ao mesmo tempo. Esses tópicos podem ser modelados para garantir uma lógica hierárquica, assim como também ajudar na reutilização e controle de acessos.
Por exemplo, supomos que vamos modelar tópicos para um MDM(Mobile Device Management) onde podemos para cada parceiro, separar vários dispositivos que vão receber e enviar dados via IOT:

• parceiro1/grupo1/serialequipamento1/apps - Os dispositivos do Parceiro 1 cadastrados no Grupo 1 podem cada um deles ter uma configuração de APPs permitidos.

• parceiro1/grupo2/serialequipamento2/location - O dispositivo com serial “serialequipamento2” poderá enviar sua localização de GPS para esse tópico, ou qualquer outro equipamento. Poderíamos também ouvir para alimentar uma base de dados por exemplo.

• Usar curingas (+, #):

  • parceiro1/grupo1/+/location → escuta todos os dispositivos.

  • pareceiro2/# → escuta tudo do parceiro.

QoS - Qualidade de Serviço

Um ponto importante é que o IoT do AWS não oferece suporte ao QoS 2, o que dificulta o uso em alguns cenários como por exemplo onde é necessário garantir entrega única das mensagens e sua aplicação não consegue descartar as duplicadas que podem acontecer no QoS 1. Se a sua solução não consegue lidar com mensagens duplicadas, o AWS IoT Core pode não ser a melhor opção. Nesses casos, alternativas como o HiveMQ podem ser mais adequadas.

Integração com outros serviços AWS

O AWS IoT Core é facilmente integrável a outros serviços da AWS. É possível utilizar desde Lambda e DynamoDB até OpenSearch, entre outros, o que abre um leque enorme de possibilidades. Basta configurar um gatilho (trigger) e a integração está pronta.

Na solução em que participei, integramos o processamento de alguns tópicos usando AWS Lambda, com funções escritas inteiramente em Golang.

Modelagem de payload

O IOT funciona bem com qualquer tipo de dado desde que você se atente aos limites de tamanho máximo por mensagem. Minha experiencia se limitou a enviar dados como JSON e Protobuf, onde o envio de Protobuf foi focado no ganho de eficiência e performance para um caso especifico.

Exemplo em JSON de um status report de equipamento:

• Tópico → parceiro1/grupo1/serialequipamento1/status

• Payload → {"batery": 78, "status": "ativo", "version": "1.2.0", "lat": -23.55, "lon": -46.63, "tempetature": 12.5, "timestamp": 1685423421 }

Conclusão

Se você está pensando em começar uma solução com IoT, vale a pena experimentar. É uma alternativa econômica, escalável e inteligente em relação a soluções tradicionais como WebSockets, especialmente no contexto de dispositivos móveis e ambientes com conectividade variável e imprevisível. Com os recursos certos e uma boa modelagem, o IoT pode entregar muita confiabilidade e eficiência para suas aplicações.

Para solucionar esse problema, você tem duas opções:

1. Atualizar a versão do Gradle do seu projeto: Consulte este guia para realizar a atualização.

2. Reverter para o JDK 17: Configure o JDK 17 no Flutter com os seguintes comandos:

   Para Unix/Linux/MacOS:
   flutter config --jdk-dir=jdk17path
   Para Windows:
   flutter config --jdk-dir "jdk17path"

Certifique-se de substituir jdk17path pelo caminho correto do JDK 17 no seu sistema.

No Flutter, estou tendo essa experiência e estou achando fantástica. Para quem não conhece o mercado de meio de pagamentos, na maioria dos casos, temos dispositivos Smart POS com versões Android um tanto quanto parecidas com o Axl Rose - com bastante idade, mas que ainda fazem um bom rock. Também temos dispositivos que usam um smartphone como ponte de pagamento, usando Bluetooth (tão amados pinpads).

Junto com os Smart POS, temos as bibliotecas das fabricantes do equipamento que possibilitam o uso da impressora interna, GPS, etc. Além disso, temos as bibliotecas para que possamos transacionar por uma adquirente (fazendo sub). Em sua maior parte, não temos bibliotecas oficiais em Flutter, por exemplo. Daí que começamos a saga.

Jnigen e Jni da nova geração

Jnigen nada mais é do que um gerador das ligações do JNI, o que facilita muito! Me lembrou muito o java2op do Delphi 11 (para Android, sim, eu também tive essa experiência). Para cada classe, temos um wrapper - JString, JInt, etc. Podemos separar nas configurações quais classes vamos gerar, o método de geração e mais. O desenvolvimento tem muito menos atritos e flui com mais velocidade.

Mas nem tudo são flores com o jnigen: apesar de evoluir a passos largos até a data desta postagem, ainda é considerado como "experimental", então não espere que funcione corretamente em 100% dos casos. Eu e meus "comparsas" de desenvolvimento tivemos um "crash" (Segmentation fault (11)) com dispositivos mais antigos rodando API level 23(foi corrigido aqui). Nos Androids mais novos, ficou supimpa!

Pigeon e os caminhos sagrados

Com Pigeon, o caminho é um pouco diferente, pois ele já usa o clássico "method channel". Existem algumas deficiências, como, por exemplo, não lidar com herança no código a ser gerado e talvez ficar um pouco confuso para você escolher entre FlutterApi ou HostApi. Você escreve o código Dart e, a partir daí, ele gera as conexões, mas sem mixins, interfaces e etc.

O lado bom é que você estará usando um método de comunicação com o código nativo muito mais testado, amplamente usado e estável.

Hoje, eu e meus comparsas partimos de Pigeon, mas continuamos de olho no Jnigen.

Com Flutter/Dart, temos a oportunidade ideal para criar projetos com essa arquitetura, devido à comunidade madura e ao excelente sistema de gerenciamento de pacotes e dependências disponível.

Modularizar 🧩

Ao pensar em microapps, é importante modularizar e especializar partes de um aplicativo maior. Para agilizar o desenvolvimento, é necessário buscar ferramentas que possam ajudar nesse processo.

Uma opção para modularização é o Flutter Modular, que é amplamente conhecido e robusto. Ele permite a modularização e oferece um sistema de Injeção de Dependência (DI) interessante, sem que seja necessário se preocupar com rotas. Outra opção é o Module Provider, que também é bastante robusto e ajuda a modularizar, a utilizar DI e a navegar entre as telas.

Mesmo que existam esses e outros pacotes para ajudar na modularização, em muitas situações pode ser necessário criar nossa própria solução para alcançar esse objetivo. Eu mesmo já gastei algumas horas desenvolvendo algo semelhante ao Flutter Modular e ao Module Provider, construindo uma fachada para o Go_router e um sistema de DI semelhante ao Kiwi ou ao Get_it (que, sim, funcionou! 🤣).

Vários microapps, um build 🔗

Ao contrário da arquitetura de micro serviços, a arquitetura de microapps muitas vezes requer que vários microapps sejam agregados em um único super app, que pode ser construido e distribuido em um único arquivo. Para isso, pode ser necessário ter um projeto ou pacote que sirva como "cola", contendo todas as dependências dos microapps e serviços e, talvez, inicializando o MaterialApp e outras configurações comuns no "void main()".

Com essa abordagem, é possível versionar cada microapp e distribuí-los para diferentes equipes que cuidam de contextos diferentes. Onde trabalho hoje, optamos por um projeto monorepo e gerenciamos as versões usando tags no Git, mas estamos avaliando se precisamos criar um pub.dev personalizado (como o https://pub.dev/packages/unpub ou jFrog, por exemplo) para nossas necessidades específicas.

Uma vantagem de versionar seus microapps é que um rollback seria muito mais rápido e fácil. Em teoria é só fazer downgrade da versão do microapp nas depedencias dentro do seu projeto "Build".

Dependências e resolução de dependências 🤝

Muitas pessoas optam por criar um pacote somente para gerenciar as versões de dependências globalmente, chamado de "shared_dependencies" na maioria das vezes. Todas as dependências comuns ficariam dentro deste pacote e seriam compartilhadas por todos os microapps.

Embora seja uma proposta interessante, na verdade é desnecessária. O próprio pub tool do Dart faz esse papel com maestria, como podemos ver em exemplos aqui e aqui.

Uma grande vantagem dessa abordagem arquitetural é que cada microapp pode ter suas próprias dependências. Por exemplo, um microapp pode usar somente o ValueNotifier/ChangeNotifier, enquanto outro pode usar MobX. No final, o pub tool resolve todas as dependências de forma eficiente e inteligente.

Como os microapps se comunicam? 📢

Aqui talvez tenha um ponto critico em sua arquitetura de microapps. Dependendo do ponto em que se quer chegar vários microapps podem ou não trocar dados, e como nós fazemos isso?

Uma das alternativas e uma das mais usadas é com Streams, talvez até usando o já conhecido EventBus, outra é usar um estado compartilhado encapsulado em um package separado, ou para ser mais simples também podemos enviar argumentos diretamente nas rotas, porém uma infinidade de alternativas podem ser desenvolvidas além destas.

Um ponto a ser destacado é que com Flutter Web dependendo da abordagem pretendida, a passagem de parâmetros via rotas(direto na URL) é muito melhor quando uma URL fica exposta ao publico ou pode ser compartilhada, com streams sua camada de apresentação e todo resto pode quebrar em algum momento.

Algumas vantagens escondidas 🛸

Embora muitos desenvolvedores tenham reclamado sobre o build_runner, eu também já tive minhas dificuldades com ele. No entanto, minha experiência com a arquitetura de microapps foi bastante positiva. É possível executá-lo isoladamente em cada microapp, que teoricamente é um pacote diferente, tornando-o muito mais rápido e eficiente.

Outra vantagem dessa arquitetura é a possibilidade de separar a lógica de negócios e os serviços da camada de apresentação. Por exemplo, podemos ter um pacote especializado para consumir uma API e conter as regras de negócio, enquanto outro microapp contém a camada de apresentação e suas reatividades.

Depois de contribuir para um package da comunidade(por ex. flutter_zxing) tive a curiosidade de me aprofundar mais em como chamar código nativo direto de um projeto Dart, e também estou tendo cada vez mais interesses em linguagens como Rust e Golang, elas me atraem como o mel atraem ursos 🍯.

Então me propus a usar Golang interpolado com Dart e trouxe aqui um pequeno guia para você desenvolvedor e sofredor.

Antes de tudo é bom ter o Golang corretamente configurado em seu ambiente de desenvolvimento, junto também o C.

Golang com Dart 🤝

Escrevi um código Golang básico que calcula a sequência fibonacci. Note para a importação import "C", o cgo é o responsável pela ajuda de chamar código C com Golang.

package main

import "C"

//export fibonacci
func fibonacci(n C.uint) C.uint {
    if n <= 1 {
        return n
    }
    return fibonacci(n-1) + fibonacci(n-2)
}

func main() {}

Indicamos a função a ser exportada usando o comentário //export nomefuncao como documentado aqui

Para usar o ffigen devemos gerar o build e ter no minimo o arquivo de cabeçalho C e o arquivo de objeto compartilhado, os famosos *.so compilados. Como vou usar o flutter no Android, usei o comando:

CGO_ENABLED=1 GOOS="android" GOARCH="amd64" GOARM="" go build -buildmode=c-shared -o lib.so fibonacci.go
// para ver as possibilidades rode o comando `$ go tool dist list`

Talvez você precise apontar para para o NDK adicionando CC=meu caminhoparandk/25.1.8937393/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android21-clang

Criando um projeto Flutter e tendo adicionado o ffigen as dependências de desenvolvimento podemos através do arquivo de cabeçalho gerar nosso código Dart para interpolar tudo isso.

flutter pub add -d ffigen

Para configurar o ffigen basta seguir a documentação aqui. Nesse nosso projeto adicionamos o seguinte ao final do pubspec.yaml:

# Meu sistema é um Linux Fedora
ffigen:
  name: "FibonacciGO"
  description: "Bindings to FibonacciGO"
  output: "lib/generated_bindings.dart"
  llvm-path:
    - "/usr/local/opt/llvm"
    - 'C:\Program Files\llvm'
    - "/usr/lib/llvm-11"
    - "/usr/lib64/libclang.so"
  headers:
    entry-points:
      - "lib.h"

Para gerar os binds basta executar o comando abaixo e o arquivo indicado no pubspec.yaml será gerado

flutter pub run ffigen

E para facilitar criei um arquivo para facilitar o bind

import 'dart:ffi';
import 'dart:io';

import 'package:fluttergo/generated_bindings.dart';

final FibonacciGO fibonacciGO = FibonacciGO(dylib);

DynamicLibrary _openDynamicLibrary() {
  if (Platform.isAndroid) {
    return DynamicLibrary.open('lib.so');  
  } else if (Platform.isLinux) {
    return DynamicLibrary.open('/dev/blog/fluttergo/lib.so');
  } else if (Platform.isWindows) {
    return DynamicLibrary.open('lib.dll');
  }
  return DynamicLibrary.process();
}

DynamicLibrary dylib = _openDynamicLibrary();

Caso tenha gerado os arquivos *.so para Android copie e cole cada um na respectiva pasta da arquitetura

• android/app/src/main/jniLibs/arm64-v8a
• android/app/src/main/jniLibs/armeabi-v7a
• android/app/src/main/jniLibs/x86
• android/app/src/main/jniLibs/x86_64

Performance 🏇

Criei uma função com a mesma implementação fibonacci em Dart. Usei o benchmark_harness para medir o desempenho Dart x Golang interpolado obtive o mesmo desempenho.

int fibonacci(int n) => n <= 2 ? 1 : fibonacci(n - 2) + fibonacci(n - 1);

Porém otimizando o código Golang o trem decolou

//export fibonacciSequential
func fibonacciSequential(n C.uint) C.uint {
    if n <= 1 {
        return C.uint(n)
    }

    var n2, n1 C.uint = 0, 1

    for i := C.uint(2); i < n; i++ {
        n2, n1 = n1, n1+n2
    }

    return n2 + n1
}

flutter: Run(RunTime): 388.61892877711654 us. //Dart

flutter: Run(RunTime): 2.5107325 us. //Golang

*µs => microsegundos

O código abaixo alcançou flutter: Run(RunTime): 0.3191476466012018 us.. Em contra partida não tentei mais otimizar o código Golang.

int fibonacciInLoops(int n) {
  if (n < 2) return n;
  var data = [0, 1];
  for (var i = 2; i < n + 1; i++) {
    data.add(data[i - 1] + data[i - 2]);
  }
  return data[data.length - 1];
}

Isso quer dizer que é muito mais provável que somente seja viável usar interpolação caso precise de grande poder computacional, grande volume de dados a ser tratados, algum código nativo especifico ou alguma solução em outra linguagem.

Considerações ✍️

Caso precise de um poder computacional grande talvez seja necessário interpolar com código nativo usando Golang, Rust, Java ou até C puro - tratamento de imagens e vídeos, criptografia, compressão de arquivos, IA, etc.

Repositório para você conferir

Fontes

• High-performance Fibonacci numbers generator in Go
• Coding Problem: Nth Fibonacci Number in Golang by Israel Miles
• Faster Fibonacci by Mustafa Naser

O Dart é por padrão uma linguagem type safe, no final sempre é garantido que o dado seja adequado ao seu tipo, aqui que entram os tipos genéricos garantindo que você possa ter um código reutilizável com menor duplicação ou segurança na tipagem caso precise.

Tudo no Dart vem de object mas nem todo Object recebe outro Object. Dynamic é tudo desde que se descubra quem ele é. Pt merd4... 🤣

Object 🤸‍♂️

Não é bem um tipo genérico mas a classe Odin -> pai de todos.

A classe Object é uma superclasse onde tudo no Dart deriva(menos null), em muitos casos usa-se Object para inferir que um tipo genérico não possa ser null.

  class Catiorro<T extends Object> {} // T não pode ser null
  class Bichano<T> {} // T pode ser null

Para fazer alguma operação em um tipo Object que referencia um outro tipo, só se dá através de casting.

  Object inteiro = 1;
  inteiro = inteiro + 1; // aqui temos um erro;
  inteiro = (inteiro as int) + 1; // já aqui não chora na neneca;
  print(inteiro.runtimeType.toString()); // por coincidência em tempo de execução é int, legal? 🧐

A classe Object quase não tem membros em sua composição e o casting deve ser obrigatório como por exemplo no codiguinho acima.

dynamic 🦸

Já o nosso amigo dynamic não esquenta com nada, mas em alguns casos pode se tornar menos seguro por que ele não reflete tudo.

Por padrão genéricos são de fato dynamics, então em um Catiorro<K, V> K e V são dynamics a não ser que tenha alguma inferência Catiorro<K extends Neneca, V extends String>

  class Neneca{}
  class Catiorro<K extends Neneca, V extends String>{}

   dynamic inteiro = 1;
   inteiro = inteiro + 1;
   inteiro.chorandoNaNeneca(); // nem tudo são flores

O Object te força ao casting inevitável já o dynamic não esquenta com a cabeça e por isso é recomendável que se analise o uso em seu código - Forçar o casting ou não? Sempre vai depender das suas abordagens

Velocidade ⌛

Em algumas medições usando o package benchmark_harness fica evidente uma vantagem do dynamic para dados em listas.

import 'package:benchmark_harness/benchmark_harness.dart';

class ListBenchmark extends BenchmarkBase {
  final String listName;
  final dynamic list;
  const ListBenchmark(this.list, this.listName) : super(listName);

  static void main(dynamic list, String listName) {
    ListBenchmark(list, listName).report();
  }

  @override
  void run() {
    list.sort();
  }

  @override
  void setup() {}

  @override
  void teardown() {}

  @override
  void exercise() => run();
}

void main() {
  final listDynamic = <dynamic>[5, 9, 1, 4, -11, 10, 300, 3, 4, 5, 9, 1, 4, -11, 10, 300, 3, 4, 5, 9, 1, 4, -11, 10, 300, 3, 4];
  final listInt = <int>[5, 9, 1, 4, -11, 10, 300, 3, 4, 5, 9, 1, 4, -11, 10, 300, 3, 4, 5, 9, 1, 4, -11, 10, 300, 3, 4];
  final listObject = <Object>[5, 9, 1, 4, -11, 10, 300, 3, 4, 5, 9, 1, 4, -11, 10, 300, 3, 4, 5, 9, 1, 4, -11, 10, 300, 3, 4];
  // Run Benchmark
  ListBenchmark.main(listDynamic, 'Lista com dynamic');
  ListBenchmark.main(listInt, 'Lista tipada com int');
  ListBenchmark.main(listObject, 'Lista tipada com Object');
}

Resultou em algo que talvez te deixe confuso mas que não tem impacto real dependendo da sua aplicação.

Lista com dynamic(RunTime): 0.29372134156476754 us.
Lista tipada com int(RunTime): 0.3137372864007163 us.
Lista tipada com Object(RunTime): 0.3100669393288707 us.
Exited

*µs => microsegundos

Legalzinho de ver 🌶

Meu amigo kmartins.dev pediu uma ajuda para lançar uma exceção caso um campo seja null sem precisar usar o Null assertion operator, parecido com o getOrThrow do Kotlin.

Em conjunto chegamos em uma solução usando genéricos:

  X getOrThrow<X>(X? x) => x ?? (throw Exception()); 🤔

Esquisito ou não? 😵‍💫

Com isso o kmartins.dev chegou na seguinte extension para Dart/Flutter

extension ObjectExt<T> on T?{
  T getOrThrow() => this ?? (throw Exception());
  T? getOrNull() => this;
}

Com isso temos:

  final int? valor = 2;
  final receber= valor.getOrThrow();
  final naoReceber = valor.getOrNull();

Como diria o Xaropinho, rapaaaaaaaaaaizzzzzzzzz 🐀

(Dá like ae!!!!!)

Fontes

• https://dart.dev/guides/language/language-tour#generics
• https://dart.dev/guides/language/type-system

De modo geral muitos destes packages vão além da função de ajudar no debug e mostrar logs de forma legível e organizada, chegam até ao ponto de ajudar em adicionar observabilidade e contexto em aplicativos já em produção. Desta vez vou apresentar o package Groveman.

Na voz do dev

Fiz três perguntas ao Kauê Martins, mantenedor e criador do package Groveman e ele dá um panorama de pôr qual razão o Groveman existe.

O Groveman basicamente é uma versão do Timber do ecossistema Android só que para Flutter, que visa melhorar o gerenciando dos logs de uma aplicação, cito como exemplo, a possibilidade de exibir determinados logs de acordo com o flavor do seu aplicativo.Groveman (Homem do bosque) é pra passar a ideia de realmente alguém está plantando uma árvore (Groveman.plantTree).Martins, Kauê; 2022.

Usando

Você pode começar adicionando as dependências do pubspec.yaml ou chamando o cli flutter pub add groveman. Depois disso só basta inicializar o logging. Uma coisa bem legal aqui, é que você pode adicionar várias trees e cada uma delas desempenhar um papel diferente.

void main(){  
    Groveman.plantTree(DebugTree()); // Mostra logs somente em debug...

Podemos usar 5 níveis de logging : fatal, error, warning, info, debug.

Groveman.debug(); 
Groveman.info('info', tag: 'info'); 
Groveman.warning('error', tag: 'info', 
  extra: <String, Object>{
     'name': 'Jungle',
     'trees': 50,
   }, ); 
Groveman.error('info', tag: 'info', error: Error());
Groveman.fatal('info', tag: 'info', stackTrace: StackTrace.current);

Segundo o readme.md : 'There are no Tree implementations installed by default because, second Timber, every time you log in production, a puppy dies.'

Estendendo

Também podemos usar outras Trees e enviar os logs para um serviço como o Sentry por exemplo, esses Trees adicionais são disponibilizadas em packages separados, temos o Groveman Sentry e o Groveman Crashlytics.

Caso em sua stack você use um outro serviço de logging como por exemplo o ElasticSearch ou Datadog você pode simplesmente implementar sua própria Tree e nela você decide o que é importante ou não.

Finalizando

O package Groveman encara e resolve bem os problemas comuns no desenvolvimento de apps Flutter com uma mensagem legal de consciência social. Não se esqueça, plante arvores. 🌳🌳🌳