원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Introducir las entradas de formularios que llegan a los bots de mensajería interna en una base de datos es más tedioso de lo que parece. Esto se debe a que las estructuras de carga útil (payload) de Slack y Discord son completamente diferentes. Pasar tiempo cada vez consultando la documentación del SDK para integrar APIs hace que uno se cuestione su vida como desarrollador de backend.
Slack envía datos como un objeto anidado en tres niveles al enviar un modal. Discord envía los valores en formato de matriz de componentes. A esto se le suma la presión de tener que responder en un plazo de 3 segundos tras recibir el webhook.
Combinamos el patrón adaptador y Zod para crear una capa de normalización de dominio.
`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'],
},
});
}
}
`
Si separas los adaptadores, no necesitarás modificar la lógica de negocio aunque se agregue un nuevo servicio de mensajería. Esto reduce el esfuerzo de mantenimiento.
Las funciones serverless de Vercel generan una instancia por cada solicitud. Si te conectas directamente a Postgres de forma tradicional, superarás el límite de max connections y se producirán errores.
El uso del conector sin servidor (serverless pooler) de Neon permite reducir drásticamente la latencia de conexión y procesar solicitudes concurrentes. Debes evitar los guardados duplicados utilizando una clave de idempotencia (idempotency key).
`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();
}
}
`
Es más seguro responder rápidamente con un código 200 al webhook y procesar la inserción real de forma asíncrona. Esta es la única manera de evitar el tiempo de espera (timeout) de 3 segundos.
Los usuarios se frustran si cierras el modal y devuelves un error solo porque introdujeron un dato incorrecto. Debes proporcionar retroalimentación (feedback) directamente dentro del modal abierto.
`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,
}),
};
}
`
Gestionamos las sesiones con Redis y establecemos un TTL de 15 minutos. Al recopilar los registros de errores, podemos ver que la mayoría de los casos ocurren debido a restricciones en el correo electrónico o en el límite de caracteres. Si modificas las pistas (hints) del modal y añades retroalimentación en tiempo real, la tasa de errores de entrada disminuirá.