OT Programmazione - rolling release

[XWolverineX]

Innanzitutto grazie per averlo guardato, spero ti abbia dato per lo meno dei nuovi input.

Visto il talk.
abbiamo N client con visioni abbastanza diverse del problema e che vogliono farsi poco i fatti dell'implementazione, per cui parte dei principi che citi emergono in maniera abbastanza naturale.

Interessante. Avresti mica voglia di espandere il discorso? Utilizzate qualche metodologia particolare per disaccoppiare i dettagli di implementazione dai client? Hypermedia, per esempio?

Un paio dei prodotti di cui parli mi sembrano interessanti e mi riprometto di darci un'occhiata; le specifiche-markdown magiche e il generatore di mock-server possono essere interessanti per roba a cui stiamo mettendo mano in questo momento.

Mi fa piacere. Possiamo anche continuare la cosa in privato se hai bisogno di aiuto o cose varie.

Solo un paio di considerazioni, la prima di carattere generale: onestamente, è un po' sempre la solita pappa del waterfall vs agile e compagnia, con implicito un po' del discorso del capire le esigenze dell'utente (personas, goals, ...) che si usa (o almeno, si dovrebbe usare) in progettazione GUI; tutto vero e tutto giusto, ma alla fine sono un po' sempre gli stessi concetti che girano da "The Pragmatic Programmer" in poi.

Concordo in pieno. Purtroppo la mia presentazione era totalmente differente. Quando poi mi sono reso conto (al primo giorno) del livello medio dello sviluppatore presente alla conferenza (tanti ragazzini alle prime esperienze che già possono permettersi di spendere 800 pound per una conferenza...), ho dovuto fare una forte virata e partire dai concetti base, scontati per persone con un pò più di esperienza. Posso andare oltre, te lo posso assicurare

Altra cosa: ok il design orientato al consumer della API e non costringere il client a sapere dettagli di implementazione assurdamente precisi (arrivare a leakare i nomi delle tabelle è inscusabile), ma come tutte le astrazioni, inevitabilmente c'è un leak dell'implementazione, se non altro a livello di performance. L'esempio che facevi dello sviluppatore lato client che vuole avere tutto in un'unica richiesta ovviamente regge finché i dati sono gestibili in un'unica richiesta - in altre parole, se ci si inizia a spingere un pelo più in là le API devono comunque tenere conto dei constraint tecnici. A quel punto credo che la soluzione giusta sia fare le API a due livelli, con il livello basso e complicato per quelli a cui servono API ad alte prestazioni e/o per casi d'uso complicati, e quella "facilona" per tutti gli altri (possibilmente una costruita sull'altra).

Chiaro, lo fanno tanti altri, React in primis (anche se non si tratta di WebApi). La domanda (tagliata in parte), era più che altro a una ripresa del concetto che avevo espresso prima: se nell'API che sto esponendo la mia entità di base è Coffee, mi aspetto di poter fare diverse operazioni su di esso con una singola chiamata, e non spezzettandole in 8 chiamate perchè nella mia base di dati l'entità è divisa in tale modo.

L'idea che ho cercato di trasmettere è che a mio parere, quando si espone un'API, si sta scrivendo software su un layer diverso da quello che fa girare generalmente il software di base.
Molto spesso invece i programmatori, quando ricevono la richiesta Ehi, ci serve una API, al 90% prendono quello che hanno nel backend, lo collegano in qualche modo e sparano cannonate di JSON, senza preoccuparsi dell'utilizzatore finale.

Dall'altro lato ci sono invece prodotti totalmente API based (ove il client stesso usa le API), che sarebbe l'approccio ideale. Vedi Parse, Stripe, alcune parti di Azure e così via.

Un saluto,
V.