Vivim en una era d’excés digital on s’ensenya als desenvolupadors a creure que l’objectiu d’una API és servir dades. Aquest és un error fonamental que ha costat milers de milions en infraestructura i seguretat arreu del món. Hem passat anys debatent REST contra GraphQL o gRPC contra WebSockets i ens hem oblidat de mirar la solució més elegant i rendible que existeix. Parlo del concepte de No com a Servei o NaaS (https://github.com/hotheadhacker/no-as-a-service).
Per aquells que es van saltar les classes de l’Acadèmia de la Flota Estel·lar, el Kobayashi Maru és un exercici d’entrenament dissenyat com un “escenari sense victòria”. L’objectiu no és guanyar, sinó veure com gestiones un fracàs inevitable. En el món de l’Enginyeria de Backend, el nostre escenari sense victòria és la Excepció No Controlada.
Passes setmanes arquitecturant un servei bonic i net. Utilitzes Records, optimitzes les teves consultes SQL, apliques principis SOLID. I després, el dia de posar-lo en producció, un usuari envia un JSON mal format, i la teva API vomita un Stack Trace de 50 línies directament a la seva consola del navegador. És lleig, és poc professional i exposa la teva lògica interna al món.
Si ets un desenvolupador que ha gestionat processament de nòmines o conciliació bancària/financera en una empresa que utilitza Spring, segurament has treballat amb Spring Batch. Confesso que no en sóc un gran fan; té aquella verbositat i sobrecàrrega característica de l’ecosistema Java, fent que fins i tot la feina més simple sembli que requereix molt més estructura de la necessària. Però de què serveix queixar-se? La tecnologia que utilitza la teva empresa és el que assegura la teva supervivència (habitatge, menjar, roba). Així que, queixar-se no és el tema d’avui.
