Pattern: Backends For Fron­tends

On a desk­top app I might allow you to look at the items for sale, order online or reserve in store. On the mobile device though I might want to allow you scan bar codes to do price compa­ri­sons or give you context-based offers while in store. As we’ve built more and more mobile appli­ca­tions we’ve come to realise that people use them very diffe­rently and there­fore the func­tio­na­lity we need to expose will differ too.

So in prac­tice, our mobile devices will want to make different calls, fewer calls, and will want to display different (and proba­bly less) data than their desk­top coun­ter­parts. This means that we need to add addi­tio­nal func­tio­na­lity to our API backend to support our mobile inter­faces.

Another problem with the gene­ral-purpose API backend is that they are by defi­ni­tion provi­ding func­tio­na­lity to multiple, user-facing appli­ca­tions. This means that the single API backend can become a bottle­neck when rolling out new deli­very, as so many changes are trying to be made to the same deployable arti­fact.

— Sam Newman

Pas forcé­ment convaincu par tout, aucune recette miracle, mais inté­res­sant à lire pour amor­cer une réflexion. La couche d’API doit-elle être géné­rique ou spéci­fique à chaque appli­ca­tion ?