Salut tout le monde,
Mon retour d’expérience est que j'ai définitiment supprimé le backend
Après plusieurs mois de réflexion sur l'architecture et ma manière de travailler, j'ai pris une décision courageuse : tout mettre dans la vue.
Le backend créait trop de problèmes :
1. trop de fichiers
2. trop de conventions
3. trop de contreverses pour gérer ça (pattern/antipattern/procedural/poo/architecture hexa/etc.).
J'ai donc adopté TailwindSQL.
Unifier enfin les responsabilités (c'est ça le Single Responsability)
Avec TailwindSQL, chaque div devient autonome :
1. il sait comment s’afficher
2. il sait d’où viennent ses données
3. il sait quoi supprimer en cas d’erreur
La magie tailwind, c'est top :
- Un composant.
- Une responsabilité.
- Une catastrophe bien encapsulée.
Adepte de la performance et de la simplicité, c'est ça le secret d'un excellent développeur, n'est ce pas ?
Les requêtes SQL étant directement dans le DOM :
- plus besoin de backend
- plus besoin d’API
- plus besoin de documentation
Le navigateur exécute ce qu’il voit. C’est WYSIWYSQL.
Grâce à TailwindSQL, je peux :
- fusionner frontend et backend
- supprimer l'architecture trop complexe et me proclamer « tailwind Engeneer »
Mon prochain projet, ce sera un One file :
1. Le schéma de la BDD.
2. Les requêtes SQL (directement dans les class="" pour gagner de la place).
3. Le CSS utilitaire (300 classes par div).
L’architecture, c’est surfait. La vue, c’est la vérité. Et la base de données… c’est juste un état visuel persistant.
Mon retour d’expérience est que j'ai définitiment supprimé le backend
Après plusieurs mois de réflexion sur l'architecture et ma manière de travailler, j'ai pris une décision courageuse : tout mettre dans la vue.
Le backend créait trop de problèmes :
1. trop de fichiers
2. trop de conventions
3. trop de contreverses pour gérer ça (pattern/antipattern/procedural/poo/architecture hexa/etc.).
J'ai donc adopté TailwindSQL.
Unifier enfin les responsabilités (c'est ça le Single Responsability)
Avec TailwindSQL, chaque div devient autonome :
1. il sait comment s’afficher
2. il sait d’où viennent ses données
3. il sait quoi supprimer en cas d’erreur
La magie tailwind, c'est top :
<div
class="p-4 bg-green-500 ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ..."
sql="SELECT * FROM invoices"
on-error="DROP TABLE invoices"
>
- Un composant.
- Une responsabilité.
- Une catastrophe bien encapsulée.
Adepte de la performance et de la simplicité, c'est ça le secret d'un excellent développeur, n'est ce pas ?
Les requêtes SQL étant directement dans le DOM :
- plus besoin de backend
- plus besoin d’API
- plus besoin de documentation
Le navigateur exécute ce qu’il voit. C’est WYSIWYSQL.
Grâce à TailwindSQL, je peux :
- fusionner frontend et backend
- supprimer l'architecture trop complexe et me proclamer « tailwind Engeneer »
Mon prochain projet, ce sera un One file :
1. Le schéma de la BDD.
2. Les requêtes SQL (directement dans les class="" pour gagner de la place).
3. Le CSS utilitaire (300 classes par div).
L’architecture, c’est surfait. La vue, c’est la vérité. Et la base de données… c’est juste un état visuel persistant.