Running Vue Storefront in production (PWA Magento webshop)

Editor's Notes

• #2: Today i’m going to tell you about the journey that we had with Meubelplaats, from the start. My name is Tjitse, i’m a backend developer at Vendic I’m my daily job i’m responsible for building integrations with Magento 2, but also making sure that our webshops are running smoothly
• #7: We don't want to over complicate things in production, and add an extra layer of complexity with docker.
• #8: That's why we are using Elastic and Redis directly without docker in between. We're used to working with both technologies in Magento 2 What we will have to do is: Install elasticsearch and run it on port 9200 Install redis and run it direclty on a port. Redis sockets didn’t work great with Kue in my experience.
• #9: Desired architecture: We will start with Magento 2, the data is then loaded into elastic via the mage2vuestorefront datapump Elastic is used as storage, this is one of the reasons that VueStorefront is so fast. The catalog data is loaded into the system memory. The VueStorefront API gets all the catalog data from Elastic. Things like carts, orders, user registrations, stock data and images are not in elastic but are fetched directly from Magento 2 by using the REST API. I’m not entirely sure if there is already full GraphQL support, you can ask the core team this. The VueStorefront frontend is ran in cluster mode. In our case we have four different Nodes. This greatly improves the stability of our application. If one node crashes the others will take over.
• #10: We use Haproxy for our more complicated Magento2 setup, so it did make sens to use this for VueStorefront The same can be acomplished with Nginx, it’s just a matter of taste
• #11: We have four types of request: An image request that starts with /img, it will be passed to the VueStorefront API which then will fetch the image from Magento 2 An API request that stratrs with /api. It will be handled by the VueStorefront API running on port 8080 A request for Magento 2. In our case we are running Magento 2 on checkout.meubelplaats.nl. But I think you can easily run this on the same domain, but it would complicate the routing. A request for a static file in the Magento 2 route. For example robots.txt or sitemap.xml, maybe product feeds. A request for the VueStorefront frontend application running on port 3000. A big thanks to our server provider Magehost for helping out with the configuration and suggesting Haproxy.
• #12: Since this is officially a MUG, i’ll skip the Magento 2 setup. Just setup a basic Magento 2.2 or 2.3 instance and create a new API user.
• #13: The first thing we need to do when setting up the VueStorefront API is cloing the API repo ofcourse. The default configuration is stored in config/default.json. We can copy this to local.json and customize it as we see fit. The local.json stores all the settings. The connection to Magento 2 Custom VSF module that you have installed Multistore config
• #14: The VueStorefront frontend setup is faily easy. Hopefully Filip has already explained this in the morning.
• #15: We now want to import our catalog data into Elastic, this data will be used by the VueStorefront API. We can shoose from two different projects. One is the ‘old’ Mage2VueStorefront project, which is integrated into the VueStorefront API via NPM. Or we can use a Magento 2 extension that adds extra indexers to the project.
• #16: Choose which one you like. We were already in the final stages of the project when the VueStorefront indexer was first launched. So we are using the Mage2VueStorefront module, which has worked reliable so far.
• #17: You can import the data into Elastic by using one of the scripts that are included in the repository, or you can write your own script. Check the example script i’ve included.
• #19: So how do we run NodeJS applications, and how do we keep them running? For Magento 2 developers that are used to working in a PHP env. this might be new. When you develop locally you just run yarn dev, what do we use in a production env?
• #20: We use PM2 for this PM2 has tons of cool features, which I won’t talk about today One of the cool features is that you can add a ecosystem JS/JSON/YAML file to your project, which will add your deployment settings In our example we are running the VueStorefront frontend in cluster mode, with 4 instances. This means we have four different frontend applications We can always add more nodes if we want to increase capacity This greatly increases the performance and reliability of your applications, depending on the number of CPUs available. Under the hood, this uses the Node.js cluster module such that the scaled application’s child processes can automatically share server ports.
• #21: PM2 status will give us an overview of the deployed apps It will give use basic stats per app, like mode status number of restarts uptime CPU usage memory usage
• #24: This is one of the coolest things about headless development. Every frontend developer can connect to the same API VueStorefront This means a lightweight, disposable development enviroment. So no syncing of databases between staging and live No extra programs needed like mysql, elasticsearch, redis, varnish, php. Just NodeJS and Yarn. And no configuration issues The development environments are identical on every machine. This eliminates a lot of work and future problems.
• #25: As most Magento 2 developer know, a lot can go wrong with configurations Most of the time an issue is just a yes/no toggle somewhere in the configuration “Ah it was just that flat catalog was turned on in production and not on my local machine” VueStorefront packs 100’s of settings, most of which are identical on every environment
• #26: As most Magento 2 developer know, a lot can go wrong with configurations Most of the time an issue is just a yes/no toggle somewhere in the configuration “Ah it was just that flat catalog was turned on in production and not on my local machine” VueStorefront packs 100’s of settings, most of which are identical on every environment
• #27: Behind the scenes a popular library Node Config is used
• #28: Node config uses a default.json, which is overrided by a local.json
• #30: With the custom-enviroments-variables.json we can override certain environment specific parts of the local.json Examples are: IP address Port The settings are only overwritten if the environment variables are set
• #31: An example on how we start staging In the previous slide we’ve made the server host with the environment variable PROD_SERVER If we now set PROD_SERVER to localhost in a bash script And then run yarn dev on your local machine The server host is changed to localhost.
• #32: So, if a team member want’s to change a configuration file. For example ‘synchonize carts’ to true. We can do this via a normal PR and every team member uses the same config. We also include all the files needed for development into version control This means every developer working on the frontend/api/mage2vs can start developing on their local machine and doesn’t have to worry about settings. The process is also repeatable, wich is great for CI
• #33: This was a somewhat difficult topic. I saw a lot of questions about this in the VS slack
• #34: In the beginning we just cloned the Vue Storefront repo Added our theme in the theme folder And adjusted the local.json This caused a lot of problems in the team, because we were working with three developers and multiple remote servers, all having their own local.json copy
• #35: Our current setup works much better. We have a repo all the VueStorefront commits, with the official VueStorefront repo as an upstream branch Our own theme repository is add as a git submodule If you don’t like git submodules, that’s no problem You can also just develop under the /themes folder It was also easier to test things with Travis
• #36: In the future it would be best to have the VS core as an NPM module And also the theme as a seperate NPM package This would be comparable with a modern Magento 2 composer setup.
• #37: This allows us to have unified environments with a shared local.json. We start the application with a small shell script, containing only the settings that are changed for that specific environment. For example see the staging script that we use: For staging we use another VS API endpoint, which we can specify in the shell script
• #38: Now to the theme development.
• #39: This is comparable with Magento 2. When you start building a new theme, you must have some kind of base theme With VS it is also possible to develop your theme from scratch We thought it was the best to started with an emtpy base theme, and code everything ourselves After a few days of working on the new theme we quickly changed to using the default VueStorefront theme as a basis It saved us a lot of work.
• #41: When we started out in with the Meubelplaats project, in the end of 2018, there we’re only two base themes available. The default VueStorefront theme, and I think it was a blue B2B theme. That i’ve not seen since then since In 2019 there are more and more new themes released, some are available on Github for free. For example the Vuetique theme
• #43: At the time there weren’t plans to integrate Dutch payment service providers with VueStorefront . Our client wanted to integrate with Sisow, and Filip had already presentated the original external checkout module. So we decided to use his external checkout plugin, and contribute to it
• #44: Our setup is composed of three modules: The VSF external checkout module, is a VueStorefront module that redirects to Magento 2 on checkout A Magento 2 module that receives the cart token and user token from VueStorefront (via a simple GET request), restores the cart and redirects to the M2 checkout. A Magento 2 module that runs in, what I call, checkout only mode. Any other frontend page will redirect to the VueStorefront homepage
• #45: The solid lines represent the path of the user The dottet line represent data send between Magento 2 and VueStorefront
• #46: VueStorefront uses a different URL structure. In our case it was: url/pagetype/sku|id/name+id We could have written some kind of scraper, but II had just had two great workshops on Magento 2 integration testing during MageTestFest in Florance, so I thought it would be more fun to practice TDD on a Magento 2 module and release it on Github.