remastering magento 2 frontend magento 2... · © 2017 magento, inc. mind the cache § with a...

© 2017 Magento, Inc.

Riccardo TempestaCTO & Magento Specialist | MageSpecialist


Remastering Magento 2 frontend

Why we may want to conceivea new Magento 2 frontend?

So to begin with…


A bit of history before going ahead...

§ Magento 1 page was returned as a single HTML document

§ Dynamic parts were composed server-side

§ Full Page Cache was not so easy to configure

§ UI reusability was: Blocks reusability

Magento 1 frontend:


Magento 1 | Old FPC approachTraditional FPC Varnish model Traditional FPC:

§ PHP is always involved

§ Cache invalidations issues

§ Not so effective

Varnish model:§ Hard to configure

§ Holepunching issues

§ Hard Varnish configuration

PHP

CLIENT

CACHE/FPC PHP

VARNISH

CACHE

CLIENT


Magento 2 | A new solution

§ Static contents are served as a HTML page

§ Dynamic parts are asynchronously updated

via REST API calls

§ Dynamic components are Knockout based

and reusable (e.g. [add to cart] button)

§ Just an example of UI component consuming

REST API webservices: minicart


Magento 2 – A new solution

§ Static parts are PHTML driven and managed server-side.

§ Dynamic parts (e.g. shopping cart) are updated client-side

via REST API calls

§ Introduction of KnockoutJS for reusable UI components.

§ Easy to use and expand REST API call set


Magento 2 – Advantages of the new solution

§ API REST command set covers all the main Magento 2 areas

§ High Full Page Cache performance

§ Average code complexity

§ High frontend code reusability

§ CPU/RAM overall offload

§ No Full Page Cache holepunching

§ Reactive frontend


Standard Magento 2 solution

Is great if§ You need a feature rich and short

time to market solution out of the box§ You are OK with standard Magento 2

customer experience

But you may still want a further improvement…

Best practices and common pitfalls

Going headless


What does headless mean?

§ Frontend becomes an application consuming Magento 2 webservices

§ High code reusability for different frontend engines

(e.g. Mobile applications)

FRONTEND MAGENTO

SERVER-SIDE MAGENTO

REST API calls


Something you should know: area

Magento 2 REST API area is “webapi_rest”Magento 2 frontend area is “frontend”

We are using REST API to providefrontend content, but:

Events, Plugins, Preferences and DI directivesdefined in “frontend” areawill not work in “webapi_rest” area

Keep it in mind when creating custom modules


Something you should know: imagesMagento2 “/rest/V1/products” will return images with their original size.We can create a new REST API call returning the image at desidered size,but “view.xml” file is for “frontend” area only.

This code will not work in REST-API area:“category_page_grid” type cannot be retrieved in “webapi_rest” area.

...$product = $this->productRepository->get($sku);$image = $this->imageHelper->init($product, 'category_page_grid');...


Something you should know: images§ 1st solution: Create a frontend controller returning the image at desired size§ 2nd solution: Workaround the problem expliciting “view.xml” information:

Magento is investigating on a dedicated and more efficient solution for image access on non-frontend areas

Just remember:Hardcoding is not always a good idea

...$product = $this->productRepository->get($sku);$image = $this->imageHelper->init($product, '', [

'type' => 'small_image','width' => 320,'height' => 240,

]);...


URL mapping

Since decoupled frontend is notaware of Magento URL table, wewill not be able to directly mapany URL to its resource type and ID.

We should instead retrieveresources by URL and not by IDALTERNATIVE: For small catalogs we could dump the whole sitemap to a JS file.

USER DECOUPLEDFRONTED

MAGENTOAPI

URL request

Client response

Ask resource by URL

Return resourcetype and ID

Ask resourceinformation by ID

Return resource


URL mapping: an exampleWe need a custom API returning resources information by URL

GET “/rest/V1/decoupled/resource/type/%2Fstrive-shoulder-pack.html”

GET “/rest/V1/decoupled/resource/type/%2about-us.html”

{"resource_type": "product","resource_id": "24-MB04"

}

{"resource_type": "cms_page","resource_id": "about-us"

}


Mind the cache§ With a standard Magento 2 you can rely on embedded FPC or Varnish§ Magento 2 REST API are not intended to be cached and you may experience

performance issues.Solutions

https://github.com/sandermangel/headless-middleware

§ Designed for Magento 2 headless

§ Standalone software, is not a Magento 2 plugin

§ Embedded caching system

https://github.com/magespecialist/m2-MSP_APIEnhancer

§ Magento 2 module§ Supports Varnish, cache

invalidation and tagging§ Extensible via di.xml

Magento is investigatingits own new

dedicated solution

Choosing the right framework

How to do that?


Three possible candidates for this revolution


1-way binding (FLUX model)

§ A new way of thinking your application§ Application works like a deterministic network (or pure network)§ Very stable§ High performance

Action Dispatcher Store View

Action


Standard 2-way binding

Almost the same approach of KnockoutJS as used in current Magento2 templates

Model

View

Continuous updatechange detection engine

NOTE: You can use 1-way binding as wellwith AngularJS and VueJS.


Standard 2-way binding (MVVM)

An AngularJS2 2-way binding example

§ Easy to use§ Model modifies View / View modifies Model§ Beware of frontend performance!


The three solutions compared

§ A Facebook solution§ Rendering only library§ 1-way binding§ Requires external libraries§ High stability§ Wide community§ High performance§ Easily embeddable

§ A Google solution§ Full MVW framework§ 1-way/2-way binding§ RxJS embedded§ Very stable§ Growing community§ High modularity§ Full frontend replacement

§ Full MVVM framework§ 1-way/2-way binding§ Easy to learn§ Short time-to-market§ Growing community§ Component based§ High modularity§ Easily embeddable

There is no better framework, it really depends on your project

Advantages of the headless solution

Should you go headless?


Should you go headless?

The answer is yes if:§ You want to avoid performance bottlenecks due to high

traffic impact

§ You want to deliver a custom-tailored user experience§ You want to go omnichannel and offer a seamless UX

across different devices

§ You want high resilience when upgrading to major releases


An idea for tomorrow: PWA

What does PWA mean:§ Responsive

§ Good user experience even in low connectivity condition:§ Contents are updated via service workers

§ Only server-side dependent operations should require connectivity

§ App-like appeal for mobile

§ Indexed by search engines

§ Static cached contents available off-line


Going Mobile!

You can reuse your Angular or React code.Your mobile application is just another Magento 2 REST-API consumer.

Case Studies


§ www.mondoconv.it§ Magento 2 EE§ Published Jan 15th, 2017§ Mondo Convenienza S.p.A.§ 1.6 bn € multichannel yearly revenue§ 30+ showrooms

Customer requirements

§ Custom checkout workflow

§ Rapidly changing specifications

§ Sales persons mobile application

Solution

§ Full ReactJS checkout

§ Custom checkout REST-API

§ Angular 2 / Ionic 2 PWA application for

sales persons


§ www.wineowine.it§ Magento 2 CE§ Still WIP§ Wineowine srl§ Online wine store

Customer requirements

§ Reactive frontend

§ Custom design

§ High performance

Solution

§ Fully decoupled ReactJS frontend

§ Custom REST-API implementation

§ API caching based on

MageSpecialist APIEnhancer

Conclusions


Two approaches compared: Development

Standard Magento 2

Project complexity

Dev

elop

men

t cos

t

Here you start saving time and money

Headless Magento 2


Two approaches compared: Infrastructure

Standard Magento 2

Site performance

Infr

astr

uctu

reco

st

Headless Magento 2

You’re saving moneyright from the beginning


The Community

Thanks to Magento 2 wide API support,the Community is already working on headless solutions

Any suggestion about Magento 2 API improvementand core inclusion is always welcome!


Final Conclusions

Better customer experience = more conversions

Better performance = more traffic

Less costs = more margin


THANK YOU

Github:MageSpecialist

Twitter:@RicTempesta

remastering magento 2 frontend magento 2... · © 2017 magento, inc. mind the cache § with a...

Documents