Normalização de Dados de Formulário de Chatbot e Integração Prática com Banco de Dados Serverless
TuBrief 편집팀
2026년 8월 21일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Inserir envios de formulários vindos de bots de mensageiros corporativos em um banco de dados é mais trabalhoso do que parece. Isso acontece porque a estrutura de payload do Slack e do Discord é completamente diferente. Gastar tempo toda vez com a integração de API olhando a documentação do SDK acaba gerando frustração como desenvolvedor backend.
O Slack envia dados em um objeto aninhado em três níveis quando um modal é enviado. O Discord envia os valores no formato de um array de componentes. Tudo isso somado à pressão de ter que responder em até 3 segundos após receber o webhook.
Combinamos o padrão Adapter com o Zod para criar uma camada de normalização de domínio.
SlackPayloadAdapter e DiscordPayloadAdapter, respectivamente.`typescript
import { z } from 'zod';
export const CommonFormSchema = z.object({
platform: z.enum(['SLACK', 'DISCORD']),
userId: z.string().min(1),
formId: z.string().min(1),
submittedAt: z.date(),
fields: z.object({
applicantName: z.string().min(2),
contactEmail: z.string().email(),
category: z.enum(['BUG', 'FEATURE', 'INQUIRY']),
description: z.string().max(2000),
}),
});
export type NormalizedFormData = z.infer;
export class SlackPayloadAdapter {
static adapt(rawPayload: any): NormalizedFormData {
const values = rawPayload.view?.state?.values || {};
return CommonFormSchema.parse({
platform: 'SLACK',
userId: rawPayload.user?.id,
formId: rawPayload.view?.callback_id,
submittedAt: new Date(),
fields: {
applicantName: values['name_block']?.['name_action']?.value,
contactEmail: values['email_block']?.['email_action']?.value,
category: values['category_block']?.['category_action']?.selected_option?.value,
description: values['desc_block']?.['desc_action']?.value,
},
});
}
}
export class DiscordPayloadAdapter {
static adapt(rawPayload: any): NormalizedFormData {
const components = rawPayload.data?.components || [];
const fieldMap: Record<string, string> = {};
for (const row of components) {
for (const comp of row.components || []) {
if (comp.custom_id) {
fieldMap[comp.custom_id] = comp.value || comp.values?.[0];
}
}
}
return CommonFormSchema.parse({
platform: 'DISCORD',
userId: rawPayload.member?.user?.id || rawPayload.user?.id,
formId: rawPayload.data?.custom_id,
submittedAt: new Date(),
fields: {
applicantName: fieldMap['applicant_name'],
contactEmail: fieldMap['contact_email'],
category: fieldMap['category'],
description: fieldMap['description'],
},
});
}
}
`
Ao separar os adapters, você não precisa alterar a lógica de negócios mesmo se um novo mensageiro for adicionado. O esforço de manutenção é reduzido.
As funções serverless da Vercel iniciam uma instância a cada requisição. Se você se conectar diretamente ao Postgres usando a abordagem tradicional, o limite de conexões máximas (max connections) será excedido e ocorrerão erros.
O uso do pooler serverless da Neon reduz drasticamente a latência de conexão e permite lidar com requisições concorrentes. É necessário evitar salvamentos duplicados utilizando uma chave de idempotência.
`typescript
import { Pool } from '@neondatabase/serverless';
const pool = new Pool({ connectionString: process.env.POSTGRES_URL });
export async function insertNormalizedFormsBulk(forms: NormalizedFormData[]) {
const client = await pool.connect();
try {
await client.query('BEGIN');
const insertQuery = `
INSERT INTO form_responses (
idempotency_key,
platform,
user_id,
form_id,
payload,
created_at
)
VALUES ($1, $2, $3, $4, $5, $6)
ON CONFLICT (idempotency_key)
DO UPDATE SET
payload = EXCLUDED.payload,
created_at = EXCLUDED.created_at
RETURNING id;
`;
for (const form of forms) {
const idempotencyKey = `${form.platform}:${form.userId}:${form.formId}:${form.submittedAt.getTime()}`;
await client.query(insertQuery, [
idempotencyKey,
form.platform,
form.userId,
form.formId,
JSON.stringify(form.fields),
form.submittedAt,
]);
}
await client.query('COMMIT');
} catch (error) {
await client.query('ROLLBACK');
throw error;
} finally {
client.release();
}
}
`
É mais seguro responder rapidamente com um status 200 ao webhook e processar a inserção real de forma assíncrona. Esse é o único caminho para evitar o timeout de 3 segundos.
Os usuários se esgotam se fecharmos o modal e retornarmos um erro só porque digitaram algo errado. O feedback deve ser fornecido diretamente dentro do modal aberto.
`typescript
export function formatSlackValidationErrorResponse(zodError: z.ZodError) {
const errorMap: Record<string, string> = {};
for (const issue of zodError.issues) {
const fieldName = issue.path[issue.path.length - 1];
if (fieldName === 'contactEmail') {
errorMap['email_block'] = issue.message;
} else if (fieldName === 'applicantName') {
errorMap['name_block'] = issue.message;
} else if (fieldName === 'description') {
errorMap['desc_block'] = issue.message;
}
}
return {
statusCode: 200,
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
response_action: 'errors',
errors: errorMap,
}),
};
}
`
Gerenciamos sessões com o Redis definindo um TTL de 15 minutos. Ao coletar logs de erro, percebemos que na maioria das vezes os problemas ocorrem por causa de e-mails ou limites de caracteres. A taxa de erros de entrada diminui se você ajustar as dicas (hints) do modal e adicionar feedback em tempo real.