@tomazfernandes.dev.bsky.social
Bits and bites 🤓
Boa, e porque está indo pro Java agora?
Querendo migrar de stack mesmo? Ou é algo mais pontual?
Boa, agora que entendi melhor o que você queria, ficou massa.
Um padrão que eu curto pra options é passar um Consumer<Options> como 3o parâmetro, e o Options ter um builder.
Aí ficaria:
target.addEventListener(“submit”, event -> {}, options -> options.xxx().yyy())
Mas é firula, já está ótimo!
Interface Funcional em Java pode ter apenas um método sem implementação.
Me parece que o que você quer é uma interface comum com 3 métodos.
Se fizer questão de usar lambda, precisa prover implementações default para dois métodos e deixar apenas um pra implementar (que será o lambda).
Faz sentido?
Eu sei que vocês não gostam de vídeos técnicos com #Java Spring, mas esse é o tema de hoje. Quem puder entrar e forçar o like, agradeço! Assim a plataforma me recomenda.
youtu.be/rAnkCj8OefI?...
No meu trampo a gente usa esse aqui:
bazel.build
É interessante até, depois que você entende a ideia.
Pra deixar claro - esse tipo de problema em uma escala beeeeeeeeem menor né 😅😅
Mas os problemas em si são esses, log fica excessivo, algo de arquitetura tb é overkill, acho que metrics podem resolver bem.
Maneiro!
Essa questão me interessa à beça porque não tenho uma solução na ponta da língua.
O que estou pra experimentar agora no início do ano pra esse tipo de problema são as métricas do OpenTelemetry ou similar, já viram isso?
Mais lightweight que logs e não precisa fazer sampling.
Finalmente postamos! Quer entender mais sobre o meu trampo? Leia o nosso post no tech blog da firma :)
netflixtechblog.com/title-launch...
echo "🎉🎊 PARABÉNS!!! 🎊🎉"
15.12.2024 14:53 — 👍 1 🔁 0 💬 1 📌 0What if we could convert these offices to apartments and let people work from home? 🤔
14.12.2024 20:25 — 👍 4 🔁 1 💬 1 📌 0
Depois de assistir às palestras do Gavin Bierman e do Adam Bien, fiquei ainda mais animado com o futuro do Java. Eles mostraram como a linguagem tá evoluindo e simplificando nossas vidas. Segue o fio 🧵 youtu.be/t03DOhiTPkc?... e www.youtube.com/watch?v=3T0g...
13.12.2024 17:22 — 👍 6 🔁 2 💬 1 📌 0
Assisti o vídeo do Balkrishna Rawool sobre continuations e virtual threads no Java, e, sério, foi um mix de devaneios temporários que tive aqui...viagens... youtu.be/HQsYsUac51g?...
13.12.2024 15:54 — 👍 8 🔁 3 💬 1 📌 1Cc: @vepo.dev @omurilo.dev @marcelojscosta.bsky.social
13.12.2024 17:15 — 👍 1 🔁 0 💬 0 📌 0Boa, valeu!
Qual schema registry vocês usam?
Tem esses limites tipo 10K versões como o Glue?
Hehehe, pois é…
Dá uma pesquisada pra ver se mudou, mas da última vez que vi ele cansava sim 🫠
A opção seria tentar ter um schema só para “OrderEvent” e desambiguar por um field “type”.
O listener teria que ter um “if” pra rotear a mensagem, e o “Deleted” não poderia ter só o id por exemplo, teria que ter todos os outros campos nulos.
O que acham?
A questão mais uma vez são os limites - no AWS Glue Schema Registry há um limite de 10.000 versões de schema por conta por região.
A conta dev da firma por exemplo tem dois schemas registries, então seriam 5K versões pra cada um.
Parece um número baixo a longo prazo… (+)
Kafka Questions 2: Schemas
Me parece que o ideal seria ter um schema por tipo de evento: OrderCreatedEvent, OrderUpdatedEvent, OrderDeletedEvent
Desse modo eu consigo enviar e receber as mensagens fortemente tipadas, e posso ter métodos específicos para cada tipo no meu listener.
(+)
Tenta esse aqui antes:
aistudio.google.com/live
O CGPT “cansa” sim com o advanced voice mode, tem um limite.
O Gemini até onde eu sei não tem limite.
De quebra, você ainda pode apontar a câmera pra alguma coisa e conversar sobre aquilo.
Sem usar esses recursos, pra comunicação entre MS, o Kafka acaba virando uma fila capenga né, porque não traz muitas vantagens sobre um MQ ou SQS, mas traz uma série de complexidades.
13.12.2024 15:27 — 👍 0 🔁 0 💬 0 📌 0É, o Kafka tem essa proposta do broker ser o mais simples possível né, faz sentido eles não tratarem isso.
Tem duas features do Kafka que eu gostaria de usar mas que quebram com aumento de partição: ordem e topic compaction.
(+)
Sim, ou você zera as mensagens do tópico e começa de novo, ou cria um tópico novo.
De ambas as formas não parece algo simples de fazer sem downtime…
Boa, valeu!
É, aleatório não foi uma palavra bem escolhida. Quis dizer que durante um período, do ponto de vista do consumidor, as mensagens vão vir numa ordem inesperada.
Uma coisa é se preparar pra uma eventual mensagem fora de ordem, outra é se preparar pro caos total.
Outro ponto importante que o @leandronsp.com trouxe é a granularidade dos MS.
Se a app precisa emitir NF, boleto, e sabe-se lá mais o que, faz sentido cada parte dessas ter um MS separado?
Já trampei em um lugar que cada parte de um fluxo era um MS, trevas total 😓
Acho que um ponto importante é ver se quando uma mudança de cadastro é realizada a propagação precisa ser imediata, ou se há tolerância.
Poderia avisar para o usuário: “sua alteração foi enviada e estará disponível em breve”. Aí faz uma série de validações, e eventualmente aplica a alteração.
(+)
Humm, porque você diz isso?
Se pra responder a uma requisição um MS tem que fazer requisições http pra 5 outros MS isso não vai levar a um tempo de resposta maior e menor disponibilidade já que se qualquer serviço desses cair o MS não vai funcionar?
Hehe, boa!
Pois é, eu entro de férias essa terça, até lá o negócio é não fazer muita marola 😅
Vai dar muito bom isso aí do curso, tu é fera d+, vai ajudar bastante o pessoal 🤓
Boa, valeu!
Você tem ideia de quantos tópicos tem no total?
Tem tópicos com menos que 5?
Esclarecendo - vai ficar desordenado até serem processadas todas as mensagens roteadas quando tinham 3 partições.
Passado esse período normaliza com as 4 partições até ter que mexer de novo.
Massa, bem bacana isso do dev+eficiente!
Como está isso, você já gravou algumas aulas?
Se você não acertar fácil como usar o non-blocking é sinal que eu errei rude hehe.
