DEV Community: William Cunha Cardoso

Developer: From Technician to Product Architect

William Cunha Cardoso — Fri, 03 Jul 2026 12:26:18 +0000

There's a widespread discomfort in the development field. A feeling that the ground has shifted, but no one handed out the new map. Generative AI entered the daily routine, and suddenly what used to take hours, writing functions, building queries, creating components, solving trivial bugs, now takes minutes. Sometimes seconds.

The most common reactions are either "AI will replace everyone" or "nothing changes, it's just another tool." Both are wrong. The first is alarmism. The second is denial.

What happened was a role shift. The developer didn't become unnecessary. The type of contribution expected from a developer changed. And understanding this change early, especially for those at the beginning of their career, is the difference between becoming a low-impact professional and an indispensable one.

The model we knew

For a long time, the industry operated with a reasonably clear division of responsibilities:

The traditional cycle of a demand:

Someone identifies a problem → someone from product investigates and defines scope → an architect or senior developer designs the solution → a developer implements.

Each stage had its people, its ceremonies, its rituals. Refinement, sprint planning, design review, code review. Not that it was bad, it was just a structure that made sense when each stage was costly.

Within this model, career progression looked roughly like this:

Junior received small, well-defined tasks. Coded, tested, fixed. Most of the time was spent on execution: the manual labor.
Mid Level took on more complex demands, started thinking about how the code fits into the system. Refactored, participated in technical decisions.
Senior defined architecture, evaluated trade-offs, mentored. Coded less, thought more.

AI compressed this. Much of the manual labor that served as training for juniors is now automated. And this raised the question hanging in the air: "If AI does what I used to do, what do I do now?"

What actually changed

To understand the new role, we need to decompose what AI actually affected. It wasn't just the code. It was the entire cycle.

Execution became trivial

Writing code was never the end goal, but the means. AI turned the means into something almost trivial. CRUD functions, UI components, basic unit tests, automation scripts, all of this can be generated in seconds with reasonable quality.

This didn't eliminate the need to know how to program. It eliminated the need to spend most of your time programming trivial things.

Research and understanding became accessible

Before, to understand a problem domain, you needed to: read extensive documentation, talk to stakeholders, attend meetings, study the market. Everything took days.

Today, with AI tools we can:

Quickly explore a technical domain you're unfamiliar with
Generate architecture sketches to validate ideas
Prototype solutions in minutes to test concepts
Simulate scenarios and anticipate problems

The boundary between Product and Development blurred

And here is one of the most profound and least discussed changes.

The Developer as Product Thinker

There's an uncomfortable truth in the industry: much of the ceremony surrounding the product cycle exists because execution was expensive.

Think of the classic process: understand the problem, refine the problem, do research, model the solution, execute. Each stage required different people, different meetings, different time. Everything needed to be well-defined before moving to execution, because execution was the bottleneck. Getting the definition wrong meant wasting weeks of development work.

AI didn't eliminate these stages, but made each of them cheaper and faster. What used to take a week of discovery can now be explored in an afternoon with the right tools. What required a 20-page requirements document before touching code can now be validated with a functional prototype in hours.

This means developers can and should participate more actively in product stages:

Question the problem itself. Don't just receive a ticket and execute, but ask: "Is this really the problem that needs to be solved? What's the impact? Is there a simpler way to tackle this?"
Do micro-research autonomously. Explore the domain, understand the user context, compare with existing solutions. All without needing to wait for an alignment meeting.
Prototype to validate, not just to deliver. Create quick, imperfect versions that serve to test hypotheses before investing in robust implementation.
Model solutions with a product vision. Think not only about "how does this work technically" but also "how does this solve the user's problem" and "how does this sustain itself over time."

It's not that the Product Manager role ceased to exist. It's that the overlap between what a PM does and what a dev does has grown significantly. The developer who can operate in that overlap with the differentiator of understanding both technology and product has become the most valuable professional in the market.

The ceremony hasn't disappeared. But the need to rigidly separate who thinks and who executes has decreased. The same person can now cover a much larger slice of the cycle.

The New Role: Orchestrator, Architect, Product Thinker

If before the question was "how do I make this work?", now the questions that define a good developer are:

About architecture:

"What's the best way to structure this?"
"How does this communicate with the rest of the system?"
"What trade-offs are we assuming with this decision?"

About product:

"Are we solving the right problem?"
"Is there a simpler version that already validates the hypothesis?"
"How does this impact the experience of whoever uses it?"

About execution:

"Does what AI generated here make sense?"
"Which edge cases were ignored?"
"Does this scale? Is this secure? Is this maintainable?"

The developer of the new model is someone who navigates the entire spectrum, from the problem to the code. They don't need to be a specialist in everything, but they need the discernment to know when they're in product territory, when they're in architecture territory, and when they're in execution territory. Having critical thinking, and this part is important, because we can't delegate this fundamental part to AI: the thinking, the reflection, the discernment.

Do fundamentals still matter? More than ever!

There's a real risk here. With AI tools generating functional code in seconds, a dangerous temptation emerges: accepting anything that "works."

And "working" is not the same as "being good."

Code generated by AI often:

Has generic, ambiguous variable names
Mixes responsibilities in a single function
Ignores proper error handling
Uses approaches that don't scale
Creates unnecessary coupling
Passes the happy path test but fails on the first real edge case

Without fundamentals, the developer becomes a tool operator who accepts any output without questioning. It's like an architect who doesn't understand structures: they can design the most beautiful floor plan, but if they don't know that the vault needs a beam, the building collapses.

The orchestra analogy still holds: the conductor doesn't need to play violin with the same technique as the first violinist, but they need to know how to hear when the violin is out of tune. And for that, they need a trained ear.

Fundamentals are the developer's trained ear.

What to study: a practical path

In short:

The foundation

Programming logic and data structures: understand code structure like: arrays, if/else, switch, and so on. Not to memorize algorithms, but to evaluate whether AI delivered an efficient solution or a time bomb.
Debugging: reading stack traces, using breakpoints, understanding execution flow, isolating problems. When code is broken, whether AI-generated or not, you have to know how to debug to fix it. Those who don't know end up re-prompting until it works by chance.
Git: branches, merge, rebase, code collaboration. Seems basic, but it's the foundation.
HTTP and how the web works: requests, responses, status codes, headers, authentication. Without this, the system becomes a black box.

Patterns and critical code thinking

Design patterns: Strategy, Observer, Factory, Repository, Dependency Injection, and so on.
SOLID: the Single Responsibility Principle alone changes how code is read. When AI generates an 80-line function doing five things, it becomes obvious it needs to be decomposed.
Tests: unit, integration, end-to-end. AI can generate tests, but knowing what to test and why is exclusively human.
Clean Code: meaningful names, small functions, avoiding side effects.

It's important to emphasize that these code patterns are not "silver bullets", each has a context where it works. It's also worth considering the application of each one.

Architecture and systems

Software architecture: monolith vs. microservices, Clean Architecture, event-driven. Understand trade-offs, not dogmas.
Data modeling: normalization, indexes, SQL vs. NoSQL, domain-driven design. If the data model is wrong, no query saves it.
Basic infrastructure: Docker, CI/CD, deployment concepts. You don't need to be DevOps, but you need to understand how code gets to production.

Product thinking

Questioning requirements: it's important to understand the limits and expectations of the demand.
MVP mindset: deliver the smallest functional piece that validates a hypothesis, instead of building the perfect system from the start. Agile philosophy.
Business context reading: Understand the impact of the demand, who the users are, what the success metric is. You don't need to become a PM, but you need to think like one.
Communication: writing good PR descriptions, documenting technical decisions, explaining problems clearly, clear git commits. With AI in the mix, the ability to articulate what's needed has become even more central.

AI orchestration

Applied prompt engineering: being precise in context, constraints, and expected results. This is an extension of technical thinking, not a magical skill.
Code review of AI-generated code: Develop a critical eye for what the tool produces. Hidden edge cases, disguised inefficiencies, solutions that seem right but aren't.
Discernment on when to use AI: Not every task benefits from it. Sometimes, for simple problems, writing directly is faster. Sometimes, for learning, trying before asking for help is more valuable.

The shift in the learning cycle

Before, juniors learned by doing repetitive work. Made mistakes, fixed them, repeated. It was slow, but it built intuition.

The cycle now is different:

Define what needs to be done
AI generates a starting point
Evaluate, refine, correct
Understand why each decision was made

Step 4 is where real learning happens. Every time AI generates something, the right questions are:

"Why this approach and not another?"
"What happens if I change this parameter?"
"What are the limits of this solution?"

These questions transform a tool operator into a software engineer.

On the ceremony that's being left behind

To close this point about Product: I'm not saying that refinement, discovery, and planning stopped being important. They remain fundamental. What changed was the granularity and formality.

It's no longer necessary to wait a week of meetings to understand if an idea makes sense. A developer with product thinking and AI tools can:

Explore the problem in an afternoon
Prototype a solution in hours
Validate with quick data
Arrive at refinement already with a concrete proposal

Heavy ceremony existed because each stage was expensive. Now that stages are cheap, the structure needs to keep up. And the developer who knows how to operate in this lean cycle, from problem to solution, will stand out.

The programmer didn't die. The role changed. From executor to architect. From typist to orchestrator. From ticket receiver to technical product thinker.

There's no risk of AI replacing those who program, but rather those who only program.

The fundamentals that support this transition are the same as always: logic, patterns, architecture, debugging, critical thinking. But now, added to a new dimension: product vision, the ability to navigate from problem to code, and discernment to know what to accept, what to refine, and what to reject from what the machine delivers.

The future belongs to those who understand the entire system, not just one piece of it.

Desenvolvedor: de técnico a arquiteto do produto

William Cunha Cardoso — Wed, 01 Jul 2026 00:10:35 +0000

Existe um desconforto generalizado na área de desenvolvimento. Uma sensação de que o chão mudou, mas ninguém deu o mapa novo. A IA generativa entrou no dia a dia, e de repente aquilo que antes levava horas: escrever funções, montar queries, criar componentes, resolver bugs triviais. Agora passou a levar minutos. Às vezes, segundos.

A reação mais comum é: ou "a IA vai substituir todo mundo", ou "não muda nada, é só mais uma ferramenta". As duas posições estão erradas. A primeira é alarmismo. A segunda é negação.

O que aconteceu foi uma mudança de papel. O desenvolvedor não deixou de ser necessário. O tipo de contribuição que se espera de um desenvolvedor mudou. E entender essa mudança cedo, especialmente para quem está no início da carreira, é a diferença entre se tornar um profissional de pouco impacto e um profissional indispensável.

O modelo que conhecíamos

Durante muito tempo, a indústria funcionou com uma divisão razoavelmente clara de responsabilidades:

O ciclo tradicional de uma demanda:

Alguém identifica um problema → alguém de produto investiga e define o escopo → um arquiteto ou pleno projeta a solução → um desenvolvedor implementa.

Cada etapa tinha suas pessoas, suas cerimônias, seus rituais. Refinamento, sprint planning, design review, code review. Não que isso fosse ruim, só era uma estrutura que fazia sentido quando cada etapa era custosa.

Dentro desse modelo, a progressão de carreira era mais ou menos assim:

Junior recebia tarefas pequenas e bem definidas. Codificava, testava, corrigia. A maior parte do tempo era gasto na execução: a parte braçal.
Pleno pegava demandas mais complexas, começava a pensar em como o código se encaixa no sistema. Refatorava, participava de decisões técnicas.
Senior definia arquitetura, avaliava trade-offs, mentorava. Codava menos, pensava mais.

A IA comprimiu isso. Muito do trabalho braçal que servia como treinamento para o junior agora é automatizado. E isso gerou a pergunta que paira no ar: "Se a IA faz o que eu fazia, o que eu faço agora?"

O que de fato mudou

Para entender o novo papel, é preciso decompor o que a IA realmente afetou. Não foi só o código. Foi o ciclo inteiro.

A execução ficou prática

Escrever código nunca foi o objetivo final, mas sim o meio. A IA transformou o meio em algo quase trivial. Funções CRUD, componentes de interface, testes unitários básicos, scripts de automação, tudo isso pode ser gerado em segundos com qualidade razoável.

Isso não eliminou a necessidade de saber programar. Eliminou a necessidade de passar a maior parte do tempo programando coisas triviais.

A pesquisa e o entendimento ficaram acessíveis

Antes, para entender um domínio de problema, era preciso: ler documentação extensa, conversar com stakeholders, participar de reuniões, estudar o mercado. Tudo levava dias.

Hoje, com as ferramentas de IA podemos:

Explorar rapidamente um domínio técnico que não se conhece
Gerar esboços de arquitetura para validar ideias
Prototipar soluções em minutos para testar conceitos
Simular cenários e antecipar problemas

A fronteira entre Produto e Desenvolvimento embaçou

E aqui está uma das mudanças mais profundas e menos discutidas.

O Desenvolvedor como Pensador de Produto

Existe uma verdade incômoda na indústria: boa parte da cerimônia que envolve o ciclo de produto existe porque a execução era cara.

Pense no processo clássico: entender o problema, lapidar o problema, fazer pesquisa, modelar a solução, executar. Cada etapa exigia pessoas diferentes, reuniões diferentes, tempo diferente. Tudo precisava ser bem definido antes de ir para a execução, porque a execução era o gargalo. Errar na definição significava desperdiçar semanas de trabalho de desenvolvimento.

A IA não eliminou essas etapas, mas sim tornou cada uma delas mais barata e mais rápida. O que antes levava uma semana de discovery, hoje pode ser explorado em uma tarde com ferramentas certas. O que exigia um documento de requisitos de 20 páginas antes de tocar código, hoje pode ser validado com um protótipo funcional em horas.

Isso significa que o desenvolvedor pode e deve participar mais ativamente das etapas de produto:

Questionar o problema em si. Não apenas receber um ticket e executar, mas perguntar: "Esse é realmente o problema que precisa ser resolvido? Qual o impacto? Existe uma forma mais simples de atacar isso?"
Fazer micro-pesquisa de forma autônoma. Explorar o domínio, entender o contexto do usuário, comparar com soluções existentes. Tudo isso sem precisar esperar uma reunião de alinhamento.
Prototipar para validar, não apenas para entregar. Criar versões rápidas e imperfeitas que sirvam para testar hipóteses antes de investir em implementação robusta.
Modelar soluções com visão de produto. Pensar não só em "como tecnicamente isso funciona", mas em "como isso resolve o problema do usuário" e "como isso se sustenta ao longo do tempo".

Não é que a função de Product Manager deixou de existir. É que a sobreposição entre o que um PM faz e o que um dev faz cresceu significativamente. O desenvolvedor que consegue operar nessa sobreposição com o diferencial de entender de técnica e de produto se tornou o profissional mais valioso do mercado.

A cerimônia não desapareceu. Mas a necessidade de separar rigidamente quem pensa e quem executa diminuiu. Uma mesma pessoa agora consegue cobrir uma fatia muito maior do ciclo.

O Novo Papel: Orquestrador, Arquiteto, Pensador de Produto

Se antes a pergunta era "como faço isso funcionar?", agora as perguntas que definem um bom desenvolvedor são:

Sobre arquitetura:

"Qual a melhor forma de estruturar isso?"
"Como isso se comunica com o resto do sistema?"
"Quais trade-offs estamos assumindo com essa decisão?"

Sobre produto:

"Estamos resolvendo o problema certo?"
"Existe uma versão mais simples que já valida a hipótese?"
"Como isso impacta a experiência de quem usa?"

Sobre execução:

"O que a IA gerou aqui faz sentido?"
"Quais edge cases foram ignorados?"
"Isso escala? Isso é seguro? Isso é manutenível?"

O desenvolvedor do novo modelo é alguém que navega o espectro inteiro, desde o problema ao código. Não precisa ser especialista em tudo, mas precisa ter o discernimento para saber quando está no território de produto, quando está no território de arquitetura, e quando está no território de execução. Ter criticidade, e essa parte é importante, pois não podemos delegar essa parte fundamental para a IA: o pensamento, a reflexão, o discernimento.

O básico ainda importa? Mais do que nunca!

Existe um risco real aqui. Com ferramentas de IA gerando código funcional em segundos, surge uma tentação perigosa: aceitar qualquer coisa que "funciona".

E "funcionar" não é o mesmo que "ser bom".

Código gerado por IA frequentemente:

Tem variáveis com nomes genéricos e ambíguos
Mistura responsabilidades numa única função
Ignora tratamento de erros adequado
Usa abordagens que não escalam
Cria acoplamentos desnecessários
Passa no teste feliz, mas falha no primeiro edge case real

Sem fundamentos, o desenvolvedor vira um operador de ferramenta que aceita qualquer resposta sem questionar. É como um arquiteto que não entende de estrutura: pode desenhar a planta mais bonita, mas se não souber que aquele vão precisa de uma viga, o prédio desaba.

A analogia do orquestra continua válida: o maestro não precisa tocar violino com a mesma técnica do primeiro violinista, mas precisa saber ouvir quando o violino está desafinado. E para isso, precisa ter ouvido treinado.

Fundamentos são o ouvido treinado do desenvolvedor.

O que estudar: um caminho prático

De forma sucinta:

A base

Lógica de programação e estrutura de dados: entender de estrutura de código como: arrays, if/else, switch e afins. Não para decorar algoritmos, mas para avaliar se a IA entregou uma solução eficiente ou uma bomba.
Debugging: ler stack traces, usar breakpoints, entender fluxo de execução, isolar problemas. Quando o código está quebrado, seja ele gerado por IA ou não, tem que saber debugar para resolver. Quem não sabe fica refazendo prompt até funcionar por acaso.
Git: branches, merge, rebase, colaboração em código. Parece básico, mas é alicerce.
HTTP e funcionamento web: requests, responses, status codes, headers, autenticação. Sem isso, o sistema se torna uma caixa-preta.

Padrões e pensamento crítico de código

Padrões de projeto: Strategy, Observer, Factory, Repository, Dependency Injection e afins.
SOLID: o Single Responsibility Principle sozinho muda como código é lido. Quando a IA gerar uma função de 80 linhas fazendo cinco coisas, vai ficar óbvio que precisa decompor.
Testes: unitários, integração, ponta a ponta. A IA pode gerar testes, mas saber o que testar e por quê é exclusivamente humano.
Clean Code: nomes significativos, funções pequenas, evitar side effects.

É importante salientar que esses padrões de códigos não são "bala de prata", cada qual tem um contexto em que funciona. Também cabe ponderar a aplicação de cada.

Arquitetura e sistemas

Arquitetura de software: monolito vs microsserviços, Clean Architecture, event-driven. Entender trade-offs, não dogmas.
Modelagem de dados: normalização, índices, SQL vs NoSQL, modelagem orientada a domínio. Se o modelo de dados está errado, nenhuma query salva.
Infraestrutura básica: Docker, CI/CD, conceitos de deploy. Não precisa ser DevOps, mas precisa entender como o código vai parar em produção.

Pensamento de produto

Questionamento de requisitos: é importante entender os limites e expectativas da demanda.
Mentalidade de MVP: entregar o menor pedaço funcional que valida uma hipótese, em vez de construir o sistema perfeito de primeira. Filosofia agile.
Leitura de contexto de negócio: Entender que impacto a demanda tem, quem são os usuários, qual a métrica de sucesso. Não é necessário virar PM, mas é necessário pensar como um.
Comunicação: escrever boas descrições de PR, documentar decisões técnicas, explicar problemas de forma clara, git commits claros. Com IA no meio, a capacidade de articular o que se precisa ficou ainda mais central.

Orquestração com IA

Prompt engineering aplicado: ser preciso no contexto, nos constraints, no resultado esperado. Isso é extensão do pensamento técnico, não uma habilidade mágica.
Code review de código gerado: Desenvolver olhar crítico para o que a ferramenta produz. Edge cases escondidos, ineficiências disfarçadas, soluções que parecem certas mas não são.
Discernimento sobre quando usar IA: Nem toda tarefa se beneficia. Às vezes, para problemas simples, escrever direto é mais rápido. Às vezes, para aprender, tentar antes de pedir ajuda é mais valioso.

A mudança no ciclo de aprendizado

Antes, o junior aprendia fazendo trabalho repetitivo. Errava, corrigia, repetia. Era lento, mas construía intuição.

O ciclo agora é diferente:

Define-se o que precisa ser feito
A IA gera um ponto de partida
Avalia-se, refina-se, corrige-se
Entende-se por que cada decisão foi tomada

O passo 4 é onde o aprendizado acontece de verdade. Toda vez que a IA gerar algo, as perguntas certas são:

"Por que essa abordagem e não outra?"
"O que acontece se mudar esse parâmetro?"
"Quais são os limites dessa solução?"

Essas perguntas transformam um operador de ferramenta em um engenheiro de software.

Sobre a cerimônia que está ficando para trás

Para encerrar esse ponto sobre Produto: não estou dizendo que refinamento, discovery e planejamento deixaram de importar. Continuam fundamentais. O que mudou foi a granularidade e a formalidade.

Não é mais necessário esperar uma semana de reuniões para entender se uma ideia faz sentido. Um desenvolvedor com pensamento de produto e ferramentas de IA consegue:

Explorar o problema em uma tarde
Prototipar uma solução em horas
Validar com dados rápidos
Chegar no refinamento já com uma proposta concreta

A cerimônia pesada existia porque cada etapa era cara. Agora que as etapas ficaram baratas, a estrutura precisa acompanhar. E o desenvolvedor que souber operar nesse ciclo enxuto, do problema à solução, se destacará.

O programador não morreu. O papel mudou. De executor para arquiteto. De digitador para orquestrador. De receptor de tickets para pensador de produto técnico.

Não corre-se o risco da IA substituir quem programa, mas sim quem apenas programa.

Os fundamentos que sustentam essa transição são os mesmos de sempre: lógica, padrões, arquitetura, debugging, pensamento crítico. Mas agora, somados a uma nova dimensão: visão de produto, capacidade de navegar do problema ao código, e discernimento para saber o que aceitar, o que refinar e o que rejeitar do que a máquina entrega.

O futuro pertence a quem entende o sistema inteiro, e não apenas uma peça dele.

Sending Emails with Dart and Appwrite Serverless Functions

William Cunha Cardoso — Sat, 09 Sep 2023 15:35:26 +0000

Introduction
Identifying Requirements
Preparing the Environment
Hands-On
- Create or Link to a Project
- Create a Function
- Code the Function
  - Using the http Package
  - Wrapping with Try/Catch
  - Response Class
  - Email Dispatch Method
  - Handling Requests
  - Code mounted
  - Set Up Variables in Functions
  - Deployment
- Testing
  - Testing via Appwrite Console
  - Testing via CURL Request
Conclusion
Considerations
Additional Resources

Introduction

Sending emails is a common requirement for various business and project purposes. Whether it's for user authentication, sending invoices, or notifying customers, having a flexible and modular email dispatch solution is essential. In this tutorial, we'll explore how to create a serverless email dispatch function using Dart and Appwrite. This solution not only sends emails but also adheres to principles like modularization and the Open/Closed Solid Principle.

Identifying Requirements

Before we start building our email dispatch service, let's identify the key requirements:

Sender: The email address from which the email will be sent.
Recipients: The list of email addresses and names of the recipients.
Body: The content of the email.
Subject: The subject line of the email.

These requirements will help us define the contract for our service.

Preparing the Environment

For this tutorial, we'll need the following tools:

Appwrite CLI
Brevo Account
Dart
Visual Studio Code

Feel free to use alternative tools, but ensure they are properly configured in your environment. In this tutorial, I'll be using Appwrite Console version 1.1.2.

Hands-On

Create or Link to a Project

To get started, we need a project to host our functions. You can create a new project or link to an existing one using the Appwrite CLI:

appwrite init project

Follow the CLI prompts to either link to an existing project or create a new one.

Create a Function

Now, let's create a Dart runtime function using the following command:

appwrite init function

Answer the questions prompted by the CLI to configure your function. Remove all the comment and initial code. At the end, your function might look like this:

Future<void> start(final req, final res) async {

}

Code the Function

Using the http Package

We'll use the http package to perform HTTP requests for sending emails. To add it to your project, navigate to your functions directory and run:

dart pub add http

Wrapping with Try/Catch

To handle errors gracefully, wrap your code with a try/catch block like this:

Future<void> start(final req, final res) async {
  try {
    // Your code goes here
  } catch (error) {
    return res.send('Error: ${error.toString()}', status: 400);
  }
}

Response Class

Create a response class to define the structure of the response:

class ResponseMap {
  final String message;
  final int statusCode;

  ResponseMap(this.message, this.statusCode);
}

Email Dispatch Method

Now, create a method that sends the email:

Future<ResponseMap> sendTransactionalEmail({
  required List<Map<String, dynamic>> recipients,
  required String apiKey,
  required String body,
  required String host,
  required String senderEmail,
  required String subject,
}) async {
  if (recipients.isEmpty) {
    throw ArgumentError('Recipients list cannot be empty');
  }
  if (apiKey.isEmpty) {
    throw ArgumentError('API Key cannot be empty');
  }
  if (body.isEmpty) {
    throw ArgumentError('Email body cannot be empty');
  }
  if (host.isEmpty) {
    throw ArgumentError('Email host cannot be empty');
  }
  if (senderMail.isEmpty) {
    throw ArgumentError('Sender email cannot be empty');
  }
  if (subject.isEmpty) {
    throw ArgumentError('Email subject cannot be empty');
  }

  final url = Uri.parse(host);
  final headers = {
    'Content-Type': 'application/json',
    'api-key': apiKey,
  };

  final sender = {'email': senderMail};

  final to = recipients;

  final data = {
    'sender': sender,
    'to': to,
    'htmlContent': body,
    'subject': subject
  };

  final response = await http.post(
    url,
    headers: headers,
    body: jsonEncode(data),
  );

  return ResponseMap(
    'Email sent successfully! ${response.reasonPhrase}',
    response.statusCode,
  );
}

Handling Requests

Handle incoming requests in your function:

Future<void> start(final req, final res) async {
  try {
    final apiKey = req.variables['BREVO_API_KEY'];
    if (apiKey == null) {
      throw ArgumentError('Missing API Key');
    }

    final emailHost = req.variables['EMAIL_HOST'];
    if (emailHost == null) {
      throw ArgumentError('Missing Email Host');
    }

    if (req.payload == null) {
      throw ArgumentError('Missing payload');
    }

    final payload = jsonDecode(req.payload);
    if (payload == null) {
      throw ArgumentError('Missing payload');
    }

    final senderMail = payload['sender'];
    if (senderMail == null) {
      throw ArgumentError('Missing sender email');
    }

    final subject = payload['subject'];
    if (subject == null) {
      throw ArgumentError('Missing email subject');
    }

    final body = payload['body'];
    if (body == null) {
      throw ArgumentError('Missing email body');
    }

    final recipients = <Map<String, dynamic>>[];

    for (var recipient in payload['recipients']) {
      recipients.add({"email": recipient['email'], "name": recipient['name']});
    }

    final result = await sendTransactionalEmail(
      apiKey: apiKey,
      body: body,
      host: emailHost,
      recipients: recipients,
      senderMail: senderMail,
      subject: subject,
    );

    res.send(result.message, status: result.statsCode);
  } catch (error) {
    res.send('Error: ${error.toString()}', status: 400);
  }
}

Code mounted

In the end, your code should look like this

import 'package:http/http.dart' as http;
import 'dart:convert';

Future<void> start(final req, final res) async {
  try {
    final apiKey = req.variables['BREVO_API_KEY'];
    if (apiKey == null) {
      res.send('Missing API Key', status: 400);
    }

    final emailHost = req.variables['EMAIL_HOST'];
    if (emailHost == null) {
      res.send('Missing Email Host', status: 400);
    }

    final payload = jsonDecode(req.payload);
    if (payload == null) {
      res.send('Missing payload', status: 400);
    }

    final senderMail = payload['sender'];
    if (senderMail == null) {
      res.send('Missing sender email', status: 400);
    }

    final subject = payload['subject'];
    if (subject == null) {
      res.send('Missing email subject', status: 400);
    }

    final body = payload['body'];
    if (body == null) {
      res.send('Missing email body', status: 400);
    }

    final recipients = <Map<String, dynamic>>[];

    for (var recipient in payload['recipients']) {
      recipients.add({"email": recipient['email'], "name": recipient['name']});
    }

    final result = await sendTransactionalEmail(
      apiKey: apiKey,
      body: body,
      host: emailHost,
      recipients: recipients,
      senderMail: senderMail,
      subject: subject,
    );

    res.send(result.message, status: result.statsCode);
  } catch (error) {
    res.send('Error: ${error.toString()}', status: 400);
  }
}

Future<ResponseMap> sendTransactionalEmail({
  required List<Map<String, dynamic>> recipients,
  required String apiKey,
  required String body,
  required String host,
  required String senderMail,
  required String subject,
}) async {
  if (recipients.isEmpty) {
    throw ArgumentError('Recipients list cannot be empty');
  }
  if (apiKey.isEmpty) {
    throw ArgumentError('API Key cannot be empty');
  }
  if (body.isEmpty) {
    throw ArgumentError('Email body cannot be empty');
  }
  if (host.isEmpty) {
    throw ArgumentError('Email host cannot be empty');
  }
  if (senderMail.isEmpty) {
    throw ArgumentError('Sender email cannot be empty');
  }
  if (subject.isEmpty) {
    throw ArgumentError('Email subject cannot be empty');
  }

  final url = Uri.parse(host);
  final headers = {
    'Content-Type': 'application/json',
    'api-key': apiKey,
  };

  final sender = {'email': senderMail};

  final to = recipients;

  final data = {
    'sender': sender,
    'to': to,
    'htmlContent': body,
    'subject': subject
  };

  final response = await http.post(
    url,
    headers: headers,
    body: jsonEncode(data),
  );

  return ResponseMap(
    'Email sent successfully! ${response.reasonPhrase}',
    response.statusCode,
  );
}

class ResponseMap {
  final String message;
  final int statsCode;

  ResponseMap(this.message, this.statsCode);
}

Set Up Variables in Functions

In the Functions Variables settings, configure the following variables:

BREVO_API_KEY
EMAIL_HOST

You'll obtain these values from your Brevo Account panel. These should remain secret and not be included in your request payloads.

Deployment

Deploy your Appwrite function. Ensure you are in the same directory as your functions:

cd ../..

appwrite deploy function

Select your function and deploy it.

Testing

You can test your function via the Appwrite Console or by making an HTTP request. Here's an example JSON payload for testing:

{
  "sender": "your-brevo-senders-option@mail.com",
  "body": "<!DOCTYPE html><html><head><title>Simple HTML Message</title></head><body><h1 style=\"color: blue;\">Simple HTML Message</h1><p>This is a sample HTML email.</p><p>You can customize it as needed.</p></body></html>",
  "subject": "Testing Email Sending with Functions",
  "recipients": [
    {
      "email": "recipient@mail.com",
      "name": "Recipient Name"
    }
  ]
}

Alternatively, you can use CURL to make an HTTP request:


curl --request POST \
  --url https://cloud.appwrite.io/v1/functions/YOUR-FUNCTION-ID/executions \
  --header 'Content-Type: application/json' \
  --header 'X-Appwrite-Key: YOUR-API-KEY' \
  --header 'X-Appwrite-Project: YOUR-PROJECT-ID' \
  --data '{
  "data": "{\"sender\":\"sender@mail.com\",\"body\":\"<!DOCTYPE html><html><head><title>Simple HTML Message</title></head><body><h1 style=\\\"color: blue;\\\">Simple HTML Message</h1><p>This is a sample HTML email.</p><p>You can customize it as needed.</p></body></html>\",\"subject\":\"Testing Email Sending with Functions\",\"recipients\":[{\"email\":\"recipient@mail.com\",\"name\":\"Recipient Name\"}]}"
}
'

Conclusion

In this tutorial, we've learned how to create a serverless email dispatch function using Dart and Appwrite. By following modularization principles and adhering to the Open/Closed Solid Principle, you can build a flexible and reliable email service for your applications.

Considerations

When creating serverless functions, consider the pros and cons. These functions provide a RESTful interface to specific services, making it language-agnostic and location-independent. However, ensure proper error handling, security, and scalability for production use.
In addition, by reading some posts on internet I tried to identify how properly return errors in the request but I could not handle it. Appwrite docs only teachs to current version. If you test it, you'll see my request, on error, it will return the proper message, but still gives a 200 status code. It can be properly resolved on latest appwrite version with proper documentation.

Additional Resources

Stateless e Stateful Widgets

William Cunha Cardoso — Fri, 05 Jun 2020 00:47:23 +0000

O que são Widgets?

São componentes que o Flutter utiliza para poder construir a interface para o usuário.

StatelessWidget

O que é?

São widgets que não possuem estados mutáveis. Permanecem o mesmo desde a sua construção.

Quando usar?

São úteis quando utilizados para apenas dispor de informação estática, sem alteração de estado e sem mudança de comportamento.

StatefulWidget

O que é

São widgets que possuem estados mutáveis. Onde, mesmo após sua construção, após algum gatilho ser disparado, este precisa atualizar o estado.
Um exemplo de atualização de estado para o StatefulWidget é o método setState, que irá reconstruir o Widget em questão.
Vale lembrar que este não é a única forma de gerenciar estados no Flutter, existem outras opções como MobX e Bloc.

Quando usar?

Considere usá-lo quando este Widget precisa mudar de comportamento de acordo com algum gatilho. Seja quando algum sensor disparar, quando uma lista de variáveis carregar, quando o usuário clicar e algo ser performado.

Referências

https://api.flutter.dev/

DEV Community: William Cunha Cardoso

Developer: From Technician to Product Architect

The model we knew

What actually changed

Execution became trivial

Research and understanding became accessible

The boundary between Product and Development blurred

The Developer as Product Thinker

The New Role: Orchestrator, Architect, Product Thinker

Do fundamentals still matter? More than ever!

What to study: a practical path

The foundation

Patterns and critical code thinking

Architecture and systems

Product thinking

AI orchestration

The shift in the learning cycle

On the ceremony that's being left behind

Desenvolvedor: de técnico a arquiteto do produto

O modelo que conhecíamos

O que de fato mudou

A execução ficou prática

A pesquisa e o entendimento ficaram acessíveis

A fronteira entre Produto e Desenvolvimento embaçou

O Desenvolvedor como Pensador de Produto

O Novo Papel: Orquestrador, Arquiteto, Pensador de Produto

O básico ainda importa? Mais do que nunca!

O que estudar: um caminho prático

A base

Padrões e pensamento crítico de código

Arquitetura e sistemas

Pensamento de produto

Orquestração com IA

A mudança no ciclo de aprendizado

Sobre a cerimônia que está ficando para trás

Sending Emails with Dart and Appwrite Serverless Functions

Table of Contents

Introduction

Identifying Requirements

Preparing the Environment

Hands-On

Create or Link to a Project

Create a Function

Code the Function

Using the http Package

Wrapping with Try/Catch

Response Class

Email Dispatch Method

Handling Requests

Code mounted

Set Up Variables in Functions

Deployment

Testing

Conclusion

Considerations

Additional Resources

Stateless e Stateful Widgets

O que são Widgets?

StatelessWidget

O que é?

Quando usar?

StatefulWidget

O que é

Quando usar?

Referências