Technical requirements

The code for this chapter, as well as other chapters, can be found in this book’s GitHub repository: https://github.com/PacktPublishing/Mastering-Adobe-Commerce-Frontend

It is possible to run AC on a Raspberry Pi 4 device and, trust me, it can run smoothly as a platform, but it is not the best choice for the development itself.

While it is possible to run the platform on any computer, in my experience, the following setup is the best:

• A CPU with at least four cores, or at least eight threads.
• 16 GB of RAM (I recommend at least 32 GB of RAM as the virtual machines we will use to run AC will use a lot of memory.
• An SSD drive, though it will be even better if your PC/laptop has an NVMe drive. It just speeds things up when you work with the platform or do any development.
• A good internet connection – you’ll be downloading a lot of data once we start.

Choosing the best operating system

I only work on Linux and macOS since I find using UNIX-based operating systems for development is much, much faster, and, in my humble opinion, Linux and macOS simply have better applications to work with code.

What is your preferred operating system of choice? Is it Windows as it has most applications? Or maybe it’s macOS because of its unique and consistent ecosystem across multiple devices? How about Linux and one of its many, many distributions?

Well, I’m happy to tell you that it does not matter as we will cover all of these systems so that you can set up your local environment and work with AC.

Installing the required applications and services

We’ll start with a few words about the AC technology stack first before we start installing and configuring everything over the next 400 pages! If you don’t have access to AC, you can use the open source version, called Magento 2 Open Source; this is something you might have heard about before somewhere. I’ll explain more about the history behind Adobe and Magento in Chapter 2.

The platform is written in PHP and requires a bunch of services to run locally (or on a server), so let’s focus on the most important ones and explain what they are.

What is a service?

A service is a type of software (application) that runs continuously in the background on a computer or network and provides a specific functionality or set of functionalities to other applications. An email server is an example of a service; can you think of some other examples? I bet you can.

Next, I’ll explain what sort of services are required to run AC; I’ll try to illustrate this with a few comparisons to a restaurant (if you are completely new to frontend development, this might be handy). So, to run AC, you need the following:

• A web (HTTP) server: This is a piece of software that accepts HTTP(S) requests – that is, it is an application that your browser connects to and communicates with when rendering a web page.

  You can treat the HTTP/web server as a butler in a restaurant. They take your order (a request) and come back to you with your order (a response) based on what you (or your internet browser) asked for or picked up from the menu.

  For AC, it is recommended to go with Apache 2 or Nginx.

  The order (a request) is being sent to the kitchen to be processed and in our case, the kitchen is PHP.

• PHP and PHP-FPM: Regarding a simple technical definition of PHP, it is a scripting language that is used to create dynamic web pages. For us, it is the kitchen of our restaurant (along with PHP-FPM) that’s run on the local or remote server and is responsible for generating HTML content that our butler will send back to us (a response).

  The technical difference between PHP and PHP-PFM is very simple: you can treat PHP as the main chef of the restaurant and PHP-FPM as the manager who oversees if everything in the kitchen works as it should. If needed, they hire or fire extra staff to process multiple orders at the same time. In a real restaurant, it’s the chef who can fire or hire their subordinates, but I hope that this analogy is pretty clear.

• MySQL/MariaDB database: Now that our kitchen is ready to prepare meals for our customers, we need a place to store ingredients (data). In our case, this is a database. It’s like Excel, but you must use over 400 spreadsheet files with over 100 columns each, and the values of the rows and columns from one file need to match some columns and rows in other files. This is the heart of your entire data in the platform. Have I mentioned that a single piece of product information is stored in over seven database tables? I’m sure I have. Luckily for you, you don’t need to know much about the entire database structure.

  Think of MySQL as a giant fridge that contains all the required ingredients (data) to prepare a meal for our restaurant guests.

  Due to the large number of database tables, the process of merging data to be presented on the frontend can cause slow performance. As a solution, the Adobe team has incorporated an extra non-relational database known as Elasticsearch (ES).

Note

Elasticsearch has been replaced with OpenSearch by Adobe

• ES: This might be the first time you’ve seen this name or you might be new to it or haven’t worked with it before. Most developers don’t know how it works and that’s fine. Imagine ES as a black box in your project that you feed product data with. Or, if you’ve worked with REST API/GraphQL, ES is the API you connect to to feed and retrieve the data.

  In the end, thanks to ES, data is retrieved must faster, making your eCommerce store run swiftly. ES is a required part of the platform and is responsible for the following, among other things:

  • Product listing on category pages
  • Product listing on search result pages
  • Search suggestions

ES can be thought of as the restaurant’s menu or search system that allows customers to search for and find and retrieve already prepared dishes (datasets).

Important

At the time of authoring this book, the new version of Magento 2 will replace ES with OpenSearch.

• Varnish Cache: Varnish is primarily used as a wood finish or a protective coating, but that is not the way we use it in AC. In this instance, we’re talking about Varnish Cache, which, not diving into much detail, is an extra caching layer on top of AC that reduces the load on the database and the application itself by serving HTML-prepared content straight from RAM. This is called a full-page cache.

  It is hard to find a way to compare Varnish Cache to our restaurant business, but let’s give it a try! Imagine that you have a 3D instant copier for every completed dish you’ve prepared. Once a dish is ready to be served to the first customer, its exact copy is stored in your 3D copier’s memory. If the next customer orders the same dish/meal, the 3D copier prints the same dish in an instant and the waiter (the HTTP server) can bring it to the customer (browser).

I’m afraid that the preceding list is not complete, so to make sure nobody points out that something is missing, let’s add the remaining ones. Two more services can be used but are not required for frontend development:

• Redis Cache: Redis is just another database that allows you to store information based on the key-value system. It is very fast as the data is stored in memory. You can (and probably should do so on production instances) use Redis cache for the following things:
  • Session storage
  • Cache storage (I’ll explain the Magento caching system in more detail in Chapter 3)
• RabbitMQ: I’ll use a very huge oversimplification here, so let me apologize to all backend developers in advance: it is simply a messaging system to provide and allow asynchronous tasks to be run by Magento 2 code. Message queues, and why and when they should be used, are much more of a backend thing, but I’ll give you an example so that you know why they have been added to the framework in the first place.

  Imagine that a merchant has requested that their store communicate with their internal system via some sort of API. This communication needs to take place every time a customer places an order in their AC store.

  There are a lot of ways you could do this in AC:

  • Plugins
  • Preference
  • Observer

I don’t want to describe the differences between these approaches, but each of these places might encounter the same serious problem: “What happens if the merchant’s third-party API is not responding?”

If the customization, as stated earlier, was modified in one of the three ways described previously, the merchant’s API might stop responding, in which case we might be looking into serious checkout issues on our eCommerce platform. We don’t want that.

By utilizing a messaging system, we can push communication to a queue and process it asynchronously, ensuring a seamless and reliable experience for our merchants and their online customers.

As a frontend developer, you don’t need to know much about this, but you should be aware that a lot of AC-based eCommerce systems might have some customizations or additional queues configured, so make sure that you ask for the project’s documentation once you take on a project that is already live.

I hope that you’ve realized that the platform is not just a simple piece of software. It is a very advanced application that requires a lot of services to run. I believe that it does not matter if you are a frontend or a backend developer. When you start dipping your toes into AC waters you must know how those pieces of the puzzle fit together.

If I were to explain the step-by-step configuration for each of the listed services, I might as well write another book. Luckily for us, there are great open source tools available that do all the required configurations for us; I’ll explain them in the next chapter. For now, we just need to prepare our computer before we start using it.