Il trend emerso negli ultimi anni riguardo la strategia di realizzazione di progetti ecommerce è quello dell'

, nel quale la piattaforma non è più responsabile di fornire anche lo storefront, bensì quest'ultimo (che sia sito web, app mobile o qualunque altro punto di contatto con l'utente finale) può essere implementato con lo stack tecnologico si reputi più adatto, e andrà ad interagire con la piattaforma utilizzandone le API (generalmente REST e Graphql).

L'approccio headless è un abilitatore ed un acceleratore quando c'è la necessità di realizzare un'esperienza utente complessa e molto personalizzata, perché consente di avere "le mani libere" e scegliere gli strumenti più adatti per l'implementazione. E per lo stesso motivo, consente di raggiungere una migliore 

 perché slega lo sviluppo del frontend dallo stack tecnologico della piattaforma ecommerce, che potrebbe risultare troppo opinionato ed in alcuni casi potrebbe "invecchiare" troppo rapidamente.

, tenutosi a Giugno dello scorso anno, è stata condivisa un'anteprima di Hydrogen, il framework basato su React per la creazione di storefront custom basati su Shopify, che a novembre 

Hydrogen è basato su React 18, che al momento della pubblicazione di questo articolo è stato appena rilasciato in 

, ed è stato utilizzato perché metterà a disposizione la funzionalità dei 

 e la nuova architettura di server side rendering 

 dello sviluppatore Shopify Ilya Grigorik spiega bene come sono stati utilizzati per ottenere delle performance di altissimo livello:

C'è da dire che fino a qualche settimana fa Hydrogen utilizzava una versione custom dei React Server Components, ma è in lavorazione 

Al netto di questo, comunque, è possibile 

utilizzare con alcuni accorgimenti i componenti di Hydrogen

 anche in altri framework basati su React, per "iniettare" le funzionalità di ecommerce in applicazioni web pre-esistenti.

Un altro elemento fondamentale per ottenere le performance promesse sarà Oxygen, il worker runtime basato su V8 che sarà hostato dall'infrastruttura di Shopify, che sarà distribuito e con data store co-locato (simile a 

) e consentirà un accesso alle Storefront API di Shopify con velocità nell'ordine dei pochi millisecondi. Inoltre il runtime esporrà una versione delle standard Fetch API "arricchite" con smart cache defaults e strategie configurabili di caching per accelerare l'accesso ad API di terze parti:

import {useQuery} from '@shopify/hydrogen';

function MyServerComponent() {
  const {data} = useQuery(
    '3p-data',  // custom cache key

    // execute remote data fetch
    async () => await fetch('https://my.3p.com/data.json').then((res) => res.json()),
    {
      cache: {
        maxAge: 60,                      // freshness: cache this response for 60s
        staleWhileRevalicate: 60 * 10,   // revalidation: async refresh within 600s after 60s freshness expires
      },
    }
  );
}


Sarà comunque possibile ospitare uno storefront Hydrogen su qualunque altra piattaforma (ad esempio AWS, Heroku, Vercel, Netlify, Cloudflare o anche on premise) ma in quel caso si perderebbe l'enorme vantaggio di performance dato dalla "vicinanza fisica" delle API di Shopify con Oxygen.

Al momento il checkout di Shopify rimane fuori da questa rivoluzione. 

Non è prevista un'implementazione del checkout custom

 (quanto meno nelle prime versioni di Hydrogen), e l'approccio suggerito da Shopify rimane di utilizzare il redirect al checkout web.

Quindi? Via Liquid, da oggi solo Hydrogen?

Come si è visto, Hydrogen è ancora in una fase di pesante sviluppo e definizione, con alcuni grossi refactoring in corso. Ci possiamo aspettare di avere una versione stabile probabilmente entro la fine del 2022.

Al suo rilascio 1.0 Hydrogen non sarà nemmeno l'unica opzione disponibile per realizzare storefront custom per Shopify. Restando nell'ecosistema React c'è ad esempio 

 (che pure integrerà le features di React 18 dalla prossima release), mentre spostandosi nell'ecosistema Vue c'è 

Con Hydrogen, Shopify vuole fornire la sua soluzione ufficiale per la realizzazione di storefront headless. Attenzione: questo non significa che secondo Shopify una volta che Hydrogen sarà diventato 

 tutti i progetti ecommerce dovranno essere headless, bensì vuole mettere a disposizione una strada alternativa che permetta di superare i limiti dell'approccio di sviluppo basato su Liquid, limiti con i quali ci si scontra quando si affronta una tipologia di progetti più complessi.

Per una grossa fetta dei merchant che oggi utilizzano Shopify, Hydrogen (e l'approccio headless in generale) non sarà la soluzione migliore. Adottare uno storefront custom richiede di tenere in considerazione molti fattori, alcuni dei quali sono:

Questi fattori vanno enormemente ad aumentare il costo di realizzazione e mantenimento di un tipico progetto di medie/piccole dimensioni basato su Shopify.

Ben diverso è il discorso per progetti più complessi, che hanno necessità di personalizzazione spinta dell'esperienza utente o di una forte integrazione tra diversi sistemi eterogenei sul frontend, pensiamo ad un cms headless come Storyblok o un motore di ricerca come Algolia, ma anche sistemi di single sign-on, personalizzazione dei contenuti e chi più ne ha, più ne metta.

Questa classe di progetti, che sempre più spesso stanno adottando Shopify (ed in particolare Shopify Plus) possono ottenere davvero il massimo dalla piattaforma utilizzando un approccio headless.

Il trend emerso negli ultimi anni riguardo la strategia di realizzazione di progetti ecommerce è quello dell'headless, nel quale la piattaforma non è più responsabile di fornire anche lo storefront, bensì quest'ultimo (che sia sito web, app mobile o qualunque altro punto di contatto con l'utente finale) può essere implementato con lo stack tecnologico si reputi più adatto, e andrà ad interagire con la piattaforma utilizzandone le API (generalmente REST e Graphql).

Headless Shopify - Un'introduzione ad Hydrogen

In Bitbull siamo alla ricerca di due Frontend Developer da inserire nei team che si occupano di progettare e far evolvere 

 di medie e grandi dimensioni per brand di respiro internazionale.

Le persone che stiamo cercando hanno almeno 

 nello sviluppo frontend di progetti di applicazioni e siti web.

Costituisce titolo preferenziale aver lavorato almeno un anno con una delle seguenti tecnologie:

È inoltre apprezzata la familiarità con:

, pertanto la sede di lavoro è ininfluente.

Cerchiamo persone che abbiano sempre voglia di 

. Dal canto nostro siamo sempre alla ricerca della soluzione migliore e facciamo 

, ma anche che siano pronte a mettere in discussione le proprie convinzioni :)

Oltre alla RAL, che sarà commisurata al livello di esperienza, offriamo un 

 (per partecipare ad eventi, corsi, workshop, acquistare libri ecc).

Per dubbi o domande e per candidarsi scrivere a job@bitbull.it

Siamo alla ricerca di due frontend developer

In Bitbull siamo alla ricerca di due Backend Developer da inserire nei team che si occupano di progettare e far evolvere 

 di medie e grandi dimensioni e di sviluppare le 

 nello sviluppo di progetti in PHP, costituisce titolo preferenziale aver lavorato almeno un anno con una delle seguenti tecnologie:

È inoltre apprezzata la dimestichezza con:

, che sarà commisurata al livello di esperienza, offriamo un 

Siamo alla ricerca di due backend developer

In Bitbull siamo alla ricerca di un DevOps da inserire nel team che si occupa di progettare ed evolvere le nostre infrastrutture su 

 di medie e grandi dimensioni, e che si integra con il team di sviluppo per supportarlo sugli aspetti di 

La persona che stiamo cercando ha almeno 

 in questo tipo di attività, ed ha i seguenti requisiti:

Cerchiamo una persona che abbia sempre voglia di 

Siamo alla ricerca di un DevOps

This post was initially published as a guest post on the 

On Friday, February 1th took place the first Vue Storefront Hackathon outside Poland: 

 are proud to have hosted the fifth edition in Milan (Italy).

We are so happy of the success of this event: 

 on the Slack channel working together on fixing bugs and implementing new features, with a total of 

 during the day! And the best part is that many of them was made by newcomers in the Vue Storefront development! This thanks to the included training session held by VS founder and core developer 

 at the beginning of the day (you can find the basic training in 

And beyond the code contributed during the day, there have been even some interesting design sessions that lay the groundwork for some important features that will be implemented in the next versions, like the 

The event shown again how much vibrant and friendly is the Vue Storefront community!

The pace new hackathons are announced is high! Don't miss the very next ones:

It’s now a global event! If You like to organize an official Vue Storefront Hackathon please drop a line to contributors@vuestorefront.io. You will receive all the marketing stuff, the training and Core Developers attending Your event!

This event was a great opportunity for us at Bitbull to give back our support to this truly awesome community! We strongly believe that the key for the success of a project is a true open governance and collaboration, and Vue Storefront is a great example of such approach! So, thank you to Divante, Snow.Dog, DeveloDesign and 

Summary of Vue Storefront Hackathon #5

We couldn't wait to announce the first Vue Storefront Hackathon in Italy, after the big success of the other 

 are proud to host the event on Friday February 1st at Eataly Smeraldo convention center in Milan + remotely!

Vue Storefront is a production ready, standalone Progressive Web Application storefront for ecommerce that works with any back-end (eg. Magento, Prestashop or Shopify).

If you're new to VueStorefront, don't worry, you can join the training session for developers. And all is absolutely for free!
Don't miss this unique opportunity to get experience under the core team guidance and 

 to find out more. The next milestone - version 1.7 - is waited for mid January and will focus on performance. Stay updated on 

10:00–10:30 — Welcome and kick off

14:00–17:30 — More intense coding

17:30–18:00 — Recap and YouTube livestream

The core front-end team will be available for questions on the 

5th Vuestorefront Hackaton

Da un punto di vista squisitamente tecnico, 

 un protocollo per la comunicazione sicura attraverso una rete di computer. Si tratta in effetti di una comunicazione tramite HTTP all’interno di una connessione criptata TLS o SSL (quest’ultimo considerato vulnerabile e ormai in dismissione).

Dal punto di vista dell’utente, HTTPS è la soluzione che consente di garantire l’integrità e la riservatezza dei dati scambiati tra i computer e i siti.

La cifratura della comunicazione avviene per mezzo di un certificato che il server invia al client, e che quest’ultimo esamina per determinare che effettivamente il server sia chi sostiene di essere.

: è il tipo di certificato più semplice, e vedremo più avanti che è possibile ottenerne gratuitamente. Da un punto di vista crittografico è assolutamente equivalente agli altri due, la differenza consiste nel fatto che un certificato DV non contiene alcuna informazione relativa al soggetto proprietario del sito web, ma solo il nome (o i nomi, nel caso di un certificato 

 – Subject Alternative Names), il cosiddetto Common Name (CN).

: un certificato OV consente al client di ottenere una serie di informazioni aggiuntive riguardo il soggetto proprietario del sito web, in particolare il paese, lo stato/provincia, la città e il nome della società. Per poter rilasciare un certificato OV, l’Autorità di Certificazione (la cosiddetta 

) deve effettuare, oltre alla verifica di proprietà del dominio da parte del richiedente, anche il controllo sull’effettiva esistenza dell’entità legale di quest’ultimo.

: si tratta del certificato contenente il maggior numero di informazioni, ed è anche il più costoso e complesso da ottenere. La CA deve effettuare una serie di controlli approfonditi sul richiedente, e i criteri per il rilascio dei certificati EV sono definiti dalle 

, attualmente (al 1 gennaio 2017) alla versione 1.4.2. Le linee guida sono prodotte dal CA/Browser Forum, un’organizzazione di cui fanno parte le maggiori CA e le aziende che sviluppano i browser, come pure rappresentanti delle professioni legali e di revisione. Anche noto come “Green Bar certificate” dal momento che i browser hanno adottato la convenzione di mostrare il nome dell’entità associata al certificato accanto alla barra dell’indirizzo con un carattere verde.

Circa due anni fa i vendor dei principali browser 

 che dovrebbe portare gradualmente i miliardi di siti che popolano la rete ad adottare HTTPS su tutte le pagine, a partire da quelle che contengono elementi che consentono all’utente di inserire i propri dati (ad esempio form di autenticazione e di pagamento con carta di credito).

Nelle scorse settimane questo percorso ha visto un primo traguardo importante, con il rilascio delle ultime versioni di 

 che hanno iniziato a segnalare come non sicure le pagine contenenti form che non sono sotto HTTPS.

 di considerare le pagine protette da HTTPS in modo privilegiato.

Sembra quindi evidente che per non rischiare di trovarsi penalizzati (dai motori di ricerca ma soprattutto dai propri utenti), questo è il momento giusto per dotare il proprio sito di un certificato https.

Il primo interrogativo che dobbiamo porci è quale tipo di certificato ci occorre.

Esiste un dibattito riguardo all’effettivo valore aggiunto dei più costosi certificati OV ed EV rispetto ai più semplici DV. 

 di usabilità condotti negli scorsi anni evidenziano come utenti che non hanno una specifica formazione riguardo i temi di sicurezza della navigazione non notano l’indicatore di convalida accanto alla barra dell’indirizzo, vanificando di fatto il vantaggio in termini di trust nei confronti degli utenti.

Vero è che tali studi erano basati su test con gli utenti condotti utilizzando IE7, ai tempi il browser più diffuso, e da allora le UI dei browser si sono (per fortuna!) largamente evolute.

Se si opta comunque per ottenere un certificato EV, è possibile acquistarlo da una delle tante CA presenti sul mercato, come 

 (per citare le più note). E’ consigliabile tenere pronta tutta la documentazione disponibile riguardo la propria organizzazione (es. certificato di attribuzione partita IVA, iscrizione alla Camera di Commercio, visura camerale ecc). E, ovviamente, la carta di credito 🙂

Se invece ci si rende conto che un certificato DV è sufficiente per le esigenze di protezione del traffico verso il proprio sito, allora – come anticipato in apertura – ci sono alcune soluzioni oramai alla portata di tutti per ottenere un certificato SSL assolutamente valido e riconosciuto dalla stragrande maggioranza dei browser.

 è una CA che fornisce certificati TLS Domain Validated gratuiti e che mette a disposizione un meccanismo completamente automatizzato per il rilascio e il rinnovo. Il progetto è gestito da un’organizzazione no-profit, l’

 tra le quali Mozilla, Google e Facebook, ed è inoltre un progetto della Linux Foundation. L’obiettivo dichiarato del progetto è di fornire certificati gratuiti e nella maniere più user friendly possibile per far diffondere l’uso di HTTPS e contribuire così a creare un Web più sicuro e maggiormente rispettoso della privacy.

Il rilascio e il rinnovo di un certificato avvengono attraverso l’utilizzo del 

Inoltre Let’s Encrypt è stato integrato su numerose piattaforme di gestione hosting come Plesk, cPanel e WordPress.com, rendendo la richiesta e l’installazione di un certificato alla portata di chiunque.

I certificati rilasciati da Let’s Encrypt hanno una durata molto breve (3 mesi) ma la possibilità di automatizzare completamente il processo di rinnovo rende questa limitazione assolutamente superabile.

I certificati sono di tipo SAN (Subject Alternative Names), quindi consentono di associare più nomi di dominio ad un singolo certificato (esempio classico: 

). Non è supportato al momento il wildcard (

) utilizzate AWS, ed in particolare il servizio 

 allora avete la possibilità di utilizzare il servizio 

 per richiedere fino a 20 certificati gratuiti di tipo DV rilasciati da 

Al momento in cui scrivo non è possibile agganciare un certificato ottenuto tramite ACM direttamente ad un’istanza EC2, ma solo ad un ELB. E’ possibile farlo direttamente dalla configurazione dell’ELB oppure tramite Elastic Beanstalk.

Anche i certificati rilasciati da ACM sono di tipo SAN, in più supportano il wildcard (

). La durata dei certificati è di un anno.

Sembra che non ci siano più scuse, è il momento di passare in massa ad HTTPS. Gli utenti iniziano oramai ad aspettarselo e i browser non faranno altro che alimentare questa aspettativa.

Per quanto riguarda un sito che inizia oggi la sua attività, è sicuramente da considerare l’ipotesi di partire dal giorno zero completamente sotto HTTPS. Mentre per siti già attivi ed indicizzati occorre prestare un po’ di attenzione in caso di passaggio per quanto riguarda l’aspetto SEO, facendo in modo che le url già indicizzate in HTTP vengano correttamente redirezionate in HTTPS.

HTTPS, HTTPS everywhere…

, la ricerca nativa di Magento non brilla per efficienza e per attinenza dei risultati, motivo per cui nel corso del tempo si sono affacciate sul mercato soluzioni di varia natura per sopperire a questa mancanza.

Uno dei recenti ingressi in questo panorama è 

, startup italiana ma con base negli States (anche se il team è distribuito in giro per il mondo, un motivo in più 

 :D). Tooso è un motore di ricerca verticale per l’ecommerce, che propone un approccio alternativo alla ricerca nel catalogo: applicando 

il motore di ricerca “impara” dall’attività degli utenti

 cercando di restituire risultati via via più attinenti, con l’obiettivo dichiarato di 

rendere inutili gli strumenti di raffinamento dei risultati di ricerca

 (filtri, ordinamenti, paginazione ecc ecc).

Inoltre, mette a disposizione nativamente le funzionalità di typo correction e autosuggest.

Il modello di pricing è freemium: fino a 200.000 query l’anno è gratuito, dopodiché costa 0,01$ a query. Il che lo rende molto appetibile per ecommerce di piccole dimensioni, che praticamente a costo zero possono ritrovarsi la ricerca sul proprio sito notevolmente migliorata, ma che al contempo possono contribuire ad accelerare l’”apprendimento” del motore di ricerca. Una classica dinamica win-win quindi.

Da pochi giorni è stato rilasciato su Magento Connect il modulo di integrazione per Magento sviluppato da Bitbull:

https://www.magentocommerce.com/magento-connect/tooso-search-integration.html

Al momento Tooso è in fase di beta privata, per diventare early adopter è necessario contattare lo staff all’indirizzo 

. Una volta ottenuta una API key, è sufficiente inserirla nella pagina di configurazione sotto System -> Configuration -> Tooso Search Engine, dopodiché è possibile attivare il modulo impostando a 

Una volta attivato, il modulo sostituisce in modo trasparente la ricerca nativa di Magento, per cui qualunque ricerca effettuata tramite la search bar da quel momento in poi mostrerà i risultati restituiti da Tooso, compreso il suggest sul campo di ricerca.

Tooso è un prodotto ancora molto giovane ma sicuramente promettente, e il modello di pricing lo rende più accessibile di altre soluzioni più affermate, per cui potrebbe valere la pena provarlo. Se vi dovesse capitare di farlo, fateci sapere la vostra esperienza!

Rilasciato il modulo Magento per l’integrazione con Tooso Search

La decisione di Google di <a href="https://chrome.googleblog.com/2016/08/flash-and-chrome.html" target="_blank">non supportare più ufficialmente Flash in Chrome</a> a partire dalla versione 55, che verrà rilasciata a Dicembre, rappresenta un classico esempio di teoria del caos. Come infatti 

“il batter d’ali di una farfalla in Brasile può provocare un tornado in Texas”

, così la decisione di rimuovere Flash – una tecnologia ormai considerata unanimemente obsoleta – andrà a creare qualche fastidio ai merchant che utilizzano il browser di Google per gestire il proprio catalogo Magento 1, nella fattispecie per caricare le immagini dei propri prodotti. Questo perché a suo tempo Magento decise di adottare una soluzione basata su Flash per implementare l’uploader che tutti conosciamo:

Dobbiamo ricordare che le prime versioni di Magento risalgono al 2009, in quel periodo i browser erano lontani dal trovare uniformità negli standard per quanto riguarda qualsivoglia tipo di API e Flash era l’unico strumento in grado di garantire compatibilità cross-browser.

Oggi le cose sono cambiate, le <a href="https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications" target="_blank">File API</a> e XMLHttpRequest sono utilizzabili in modo uniforme su tutte le versioni recenti dei browser più diffusi, tant’è che anche Magento 2 ha utilizzato sin da subito un uploader Flash-free.

Per cui non c’è da disperarsi, la soluzione a questo problema è abbastanza semplice e consiste nell’installare il seguente modulo:

<a href="https://github.com/openstream/No-Flash-Image-Uploader" target="_blank">https://github.com/openstream/No-Flash-Image-Uploader</a>

Si tratta di un modulo che sostituisce in modo trasparente l’uploader nativo, sia per la galleria di immagini in scheda prodotto sia nel file manager del cms, che una volta installato non richiede alcuna configurazione.

E’ poco invasivo, in quanto usa una sola rewrite (per la classe 

), per cui il rischio incompatibilità con altri moduli di terze parti è ridotto al minimo.

Seppure non sia aggiornato da un po’, è testato e funzionante sulle ultime versioni di Magento 1. Noi abbiamo avuto modo di verificarlo direttamente sulle versioni Community 1.9.1.0 e 1.9.2.4 ed Enterprise 1.14.1.0.

Installarlo è molto semplice, se si utilizza Composer (e si dovrebbe, 

 anche su Magento 1), è sufficiente aggiungere questa dipendenza nel proprio composer.json:

<pre class="brush: jscript; title: ; notranslate" title="">"require": {
...
"openstream/dull-uploader": "v1.1.2"
...
}
</pre>

Se già si utilizza il repository <a href="https://packages.firegento.com" target="_blank">packages.firegento.com</a> non è necessario altro, alternativamente si può aggiungere il suo repo direttamente:

<pre class="brush: jscript; title: ; notranslate" title="">"repositories": {
...
{
"type": "vcs",
"url": "https://github.com/openstream/No-Flash-Image-Uploader"
}
...
}
</pre>

Se invece non si utilizza Composer, è possibile semplicemente <a href="https://github.com/openstream/No-Flash-Image-Uploader/archive/v1.1.2.zip" target="_blank">scaricare lo zip</a>, estrarlo e copiare le cartelle 

Questa è una soluzione semplice ed efficace che abbiamo individuato per un problema noioso che si presenterà da qui a qualche mese (se, come me, utilizzate <a href="https://www.chromium.org/getting-involved/dev-channel" target="_blank">il Dev channel di Chrome</a>, Flash è già stato rimosso).

Vale anche la pena ricordare che sostituire l’uploader in Flash ha anche il vantaggio di rimuovere i problemi che solitamente si presentano con l’upload delle immagini quando il sito è protetto da autenticazione http basic (una delle cause tipiche del messaggio “Upload HTTP Error”).

Se conoscete altre soluzioni al problema sentitevi liberi di segnalarle nei commenti.

Bitbull

Gennaro Vietri

Articoli scritti da Gennaro Vietri