Suite de l'histoire sur hellolawyer — un jobboard juridique. Dans ce post, je vais raconter quelles étaient les solutions techniques (mauvaises)

La première idée était de créer un bot Telegram qui publierait des offres d'emploi personnalisées en fonction des intérêts et filtres choisis : localisation, poste, format, domaines du droit.

Il a été décidé de faire deux dépôts : un pour le bot, un autre pour la logique backend.

Boy oh boy, it was a mistake.


1. Déploiement problématique — il fallait mettre en œuvre le déploiement pour deux dépôts.
2. Appels réseau et contrats — il fallait configurer la connectivité réseau des deux conteneurs. Oui, juste docker network, mais il fallait le faire.
3. Modèles de données redondants.

Je souligne séparément la tentative d'utiliser un nouvel outil sympa pour travailler avec la base de données — edgedb (maintenant c'est www.geldata.com sous l'acquisition de vercel) — à l'époque, il était encore en bêta. Finalement, on a réécrit en asyncpg 😎

4. Refactorisations. Comme j'étais mécontent du code que j'avais écrit. Mais il fonctionnait et remplissait son rôle : des utilisateurs apparaissaient. Mais l'ingénieur ne mourait pas et voulait tout réécrire. En trois ans d'existence, même une v2 de l'API est apparue 😰

Ensuite, nous avons décidé de faire un client web...

Encore une fois, après avoir regardé des vidéos hype sur YouTube, j'ai pris nextjs. Et bien sûr, toutes ces requêtes devaient être à nouveau proxyfiées vers le backend. Heureusement, à ce moment-là, je connaissais openapi alias swagger. Au moins, les requêtes vers ce backend pouvaient être écrites moins souvent.

Ensuite, une autre ère a commencé. L'ère du travail sur l'interface utilisateur, plus précisément sur les fiches de poste. Comme nous voulions y mettre tout et qu'elles brillent et soient belles. Et bien sûr, il y a encore eu des tentatives de refactoriser les vues et les composants 💪

À suivre ☕️

L'image a été gentiment générée par chatgpt