# Back-End

# Introduzione

In questo capitolo, vado ad elencare tutte quelle mie competenze che riguardano la persistenza dei dati e la loro erogazione, quando tramite RESTful API, vengono richiesti dal Front End.

# Laravel

Il framework PHP che impiego per il back-end è Laravel. Lo caratterizza l'eleganza della sintassi ed è il compagno ideale di Vue.js.

Lo utilizzo unicamente come API Responder, delegando tutto quello che è l'aspetto grafico a Vue.js. Il compito di Laravel è di occuparsi di operazioni CRUD col DataBase, inviare e-mails, gestire API di terze parti (es. pagamenti),...

Sulla stessa linea di pensiero, gli autori del framework, che nelle ultime versioni, hanno deciso di relegare l'aspetto grafico in un package opzionale.

# Test Driven Development

Per i miei progetti, perlomeno quelli più importanti, adotto un approcio al codice Test Driven. Tradotto in pratica, significa prima scrivere il codice per riprodurre il test di una richiesta del cliente, e passo dopo passo, scrivere il codice della richiesta vero e proprio. Questo guidare per mano lo sviluppo, implica un controllo molto capillare del software e riduce drasticamente la possibilità di errori imprevisti, magari anche non strettamente connessi alla feature implementata. Per contro, necessita di più tempo: tempo totale = tempo richiesta + tempo test richiesta. Un altro enorme vantaggio, è la possibilità di refactoring o upgrade: i tests evidenzierebbero immediatamente eventuali errori.

E' inevitabile per progetti grandi: pollini.com ne è sprovvisto, il codice, scritto in Laravel 5.1 (ha terminato il rilascio delle patch di sicurezza il 9/06/2018) non è aggiornabile senza i tests (gli errori verrebbero riportati al call-center dai clienti che non riuscirebbero a fare gli acquisti 😱) e per un e-commerce costituisce un evidente grosso problema.

# Modularità e Domain Driven Development

Il mio target sono i grandi progetti: inevitabile quindi la necessità di trovare una metodologia che riesca a scomporre un grande problema difficilmente risolvibile, in molti piccoli problemi facilmente risolvibili. Questa metodologia si chiama modularità e si oppone allo sviluppo monolitico di un'applicazione. Tecnicamente si chiamano packages e fungono da "Lego": un po' come NPM nel front end, Composer è il cemento per tenere insieme tutti i mattoncini.

I vantaggi sono enormi: pensate alla differenza fra cercare un libro in un enorme scatolone pieno di altri libri, o trovarlo in un'apposita biblioteca, ordinato per nome/autore/versione.

Inoltre, agevola enormemente il re-impiego di codice: ad esempio, un package generico di categorie e prodotti, potrà essere riutilizzato in svaritati e-Commerce, ognuno dei quali aggiungerà eventuali differenze al package di base. Eventuali aggiunte o correzioni, richierebbero inoltre il lancio di un singolo comando sui servers che pubblicano progetti interessati dal cambiamento.

# DataBase

Ogni mio lavoro, relativamente alla modellazione dei dati, parte da una progettazione grafica del DataBase (perlopiù MySQL), a cui segue successivamente la codifica delle migrations, per poter avere un versioning del DataBase (limitatamente al package cui si riferiscono).