원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Insérer dans une base de données les soumissions de formulaires reçues par un bot de messagerie d'entreprise est plus fastidieux qu'il n'y paraît. En effet, les structures de charges utiles (payloads) de Slack et de Discord sont totalement différentes. Lorsque l'on passe son temps à éplucher la documentation des SDK pour intégrer les API, on finit par ressentir un certain découragement en tant que développeur backend.
Slack transmet les données sous forme d'objets imbriqués sur trois niveaux lors de la soumission d'une modale. Discord envoie les valeurs sous la forme d'un tableau de composants. À cela s'ajoute la pression de devoir répondre en moins de 3 secondes après la réception du webhook.
Nous combinons le pattern Adaptateur et Zod pour créer une couche de normalisation du domaine.
SlackPayloadAdapter et DiscordPayloadAdapter.`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'],
},
});
}
}
`
En séparant les adaptateurs, il n'est plus nécessaire de modifier la logique métier même si une nouvelle messagerie est ajoutée. La charge de maintenance s'en trouve réduite.
Les fonctions Serverless de Vercel créent une nouvelle instance à chaque requête. Si l'on se connecte directement à Postgres de manière traditionnelle, on dépasse la limite des connexions maximales (max connections) et des erreurs surviennent.
L'utilisation du chargeur de connexions sans serveur de Neon permet de réduire considérablement la latence de connexion et de gérer les requêtes simultanées. Il est indispensable d'empêcher les doubles enregistrements à l'aide d'une clé d'idempotence.
`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();
}
}
`
Il est plus sûr de renvoyer rapidement une réponse 200 pour le webhook et de traiter le stockage réel de manière asynchrone. C'est le seul moyen d'éviter le délai d'attente (timeout) de 3 secondes.
Fermer la modale et renvoyer une erreur en cas de mauvaise saisie finit par lasser l'utilisateur. Il est préférable de fournir un retour visuel directement à l'intérieur de la modale ouverte.
`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,
}),
};
}
`
Gérer les sessions avec Redis en leur appliquant un TTL de 15 minutes permet d'observer, lors de la collecte des journaux d'erreurs, que les blocages proviennent majoritairement des e-mails ou des limites de caractères. Ajuster les indices textuels des modales et y ajouter un retour en temps réel permet de réduire le taux d'erreurs de saisie.