Frustrated by Magento? Then you’ll love
From time to time someone will ask me if I think Magento PWA Studio will ever be “a thing” — as in a thing that a Magento developer should be aware of and could benefit from.
My usual answer is “not like you want it to or think it will” — which is the sort of unsatisfactorily vague answer you give once your career is long enough.
Today I’m going to cover some Magento history to help put Magento’s PWA Stdio efforts in context. Then, in our next article, we’ll take a brief tour of the tooling to see is there’s any there there.
Magento’s Original Architecture
Magento 1 (as well as its forked successor project, OpenMage) uses a “Web MVC” (Model, View, Controller) architecture. This is a well established pattern for creating “full stack” applications. I first saw this architecture used in Java Struts and Web MVC was widely popularized by Ruby on Rails. Symfony and Laravel are two popular full stack PHP frameworks.
A full stack framework is designed to allow an individual development team to create and deploy a fully functional web application. The framework has code for handling incoming HTTP requests on a server, code for serving out responses to those requests, and code for composing together HTML/CSS/Javascript based interfaces. They’re designed to build web applications, but can also build web APIs that are consumed by other applications.
For comparison, React is a not a full stack framework. It’s a frontend framework for building UIs. React makes calls to web services, but can not create web services itself. Express is not a full stack framework. It’s a backend framework for creating web servers. You can use both React and Express together to do full stack work, but neither is a full stack framework in and of itself.
Let’s look at Magento 1’s MVC architecture broadly
When an HTTP request enters the system, it’s routed to a method in a class file. This class is called a controller, and this method is called an action method. Each action method maps to a single URL. I find it useful to think of these methods as main entry points.
An action method has two responsibilities.
First, it will interact with a data layer (this is the Model in MVC) to fetch and save data. If the user is requesting a web page that lists data, the action method will contain code to fetch that data. If the user has submitted a form or other request to save data, the action method will contain code to save that data.
Second, an action method prepares the view data and signals the rest of the system that it’s time to render the view layer. In Magento this means issuing layout handles, loading the layout system, and then rendering the layout. It also might mean preparing data for the layout, depending on which era of Magento 1 code you’re working with.
In Magento the view system is also called the layout system. Magento’s layout system renders a tree of PHP (phtml) template files. Each template is associated with a PHP class, and these PHP classes are called blocks. Magento works a little differently from other PHP MVC systems in that sometimes these blocks read data directly from the database rather than use data prepared by the controller action method. Because of this these blocks are sometimes called ViewModels.
The layout system renders HTML pages that are progressively enhanced with javascript. Magento 1 ships with the venerable Prototype.js framework. Many Magento extensions and themes pull in jQuery or another framework suitable for progressive enhancement.
You could write a book on Magento’s layout system — in fact, I’ve written two. If you want to learn more about this system No Frills Magento Layout is still available for both Magento 1 and Magento 2.
The MVC system isn’t Magento 1’s only system. There’s a module system that allows programmers to add code to the application in a shared way with a shared global configuration. There’s an event/observer system. There’s an active-record like Model system and Magento’s infamous EAV model system. There’s a system for adding Menus and Pages to the backend UI, as well a system for adding UI settable configuration values. There’s a rudimentary monkey-patching/dependency injection system. There’s a theme system.
It’s systems all the way down.
For an agency owner, or even an agency developer, this may seem over-engineered. But what some saw as over-engineered others saw as a stable software platform. Magento’s architecture allowed third party developers to do the exact same things that core developers were doing, and do so in a mostly stable way.
This over engineering contributed to a large part of Magento’s early success.
Enter Magento 2
When Magento 2 was first released, it came with a flurry of developer activity. Porting modules and themes over to the new system was a time intensive task. It would be natural to wonder what changed in Magento 2’s architecture to make this necessary.
Well, at the highest level — there were no architecture changes.
Magento 2 remains the same MVC based system that Magento always was. Its fundamental architecture patterns are the same. Requests still route to a controller, controllers can still do database things and tell the view to render, and views are still nested phtml template blocks that sometimes (more often in M2) talk to the database. The pages and applications are still a mix of HTML, CSS, and javascript.
What did change though is each layer of Magento’s systems was significantly refactored. This refactoring often came with new layers of abstraction and sub-systems.
For example: Controllers no longer contain multiple action methods — each individual controller has an execute method that maps to a single url.
Magento’s database accessing code is hidden behind a layer of Repository classes.
Magento module configurations were broken out into a hierarchy of individual XML files, and each of these files has its own set of classes for loading and merging.
The rudimentary dependency injection system turned into a full-on dependency injection system with injectable constructor arguments and a plugin system for wrapping any public method.
The XML files that power the layout system changed their semantics/structures and gained new abilities.
The UI itself used newer javascript libraries, and there’s a new system for embedding “javascript first” UI components. There’s an XML system for configuring these components, because of course there is.
Sometimes these changes were done to add new features. Sometimes they were done to make Magento 2’s new suites of unit, integration, and functional tests possible. Sometimes they were done because there was a team that needed something to do. Some people believe the changes were part of building a technological moat to offset the perceived risks of open source software.
What’s important to take away is that Magento 2 is the same sort of full stack system that Magento 1 was — just more complex.
What is Magento PWA?
History lesson done, this brings us to Magento’s PWA Studio. Progressive Web Apps (PWA) are a thing outside of Magento. It’s a movement in web and software development that leaves behind the hybrid web-page/web-application model that fueled the early growth of the web and proposes that web sites could a full on web application.
This isn’t a new concept — frameworks like Cappuccino existed long before the phrase Progressive Web Application came along. Heck, if you want to go way back to the mid-90s there were Java applets let us swing for the stars.
PWA may be a recycling of ideas, but it’s a recycling that comes at a time where technological trends have made full on software development in a web browser an everyday thing instead of an effort that requires a tech-first approach. Specifically — the move towards the web becoming a bunch of JSON services (often served by Node.js) that power native mobile applications and the emergence of “DOM-less” UI/UX oriented frameworks like React.
Magento’s PWA Architecture
The goal of Adobe’s PWA efforts (called PWA Studio) is to give their biggest customers a
- Modern development environment that
- Allows them to build React applications that
- Consume a data from Adobe provided services, with Magento Cloud and Magento Enterprise installations being the primary service.
This can come as a bit of a surprise to traditional Magento folks. Consider the architecture of a PWA Studio based solution.
An application built using Magneto PWA is a React application. It’s hosted on any old web server that can host static files.
This react application makes service (i.e. ajax) calls. However, it does not make service calls directly into Magento. Instead, it makes service calls into something Magento calls an “UPWARD” server. Practically speaking this UPWARD server is a Node.js based server. We say practically because there IS a PHP implementation of an UPWARD server — but this seems a concession to the traditional PHP oriented hosting ecosystem and not a place where the PWA Studio team’s heart resides.
When the UPWARD web server receives a request, it passes that request on to a traditionally-or-cloud-hosted Magento 2 system. UPWARD’s goal in life is to be a coordination layer for all of an application’s API calls. Consider this zoomed out best case architecture diagram.
In a version of PWA Studio’s future, a traditional Magento system is just one more service provider for an online retail experience.
The Future
I’ve talked with folks who’ve been building PWA solutions for Magento 2 systems and there’s a few things that have stood out.
- For a long time there wasn’t much there there to PWA Studio — people talk about having to build most of the components by scratch before they landed in Magento’s PWA’s Peregrine UI library.
-
There’s often a dark running joke that the team’s one or two sprints away from removing Magento as a backend service from their system entirely.
-
There’s also a lot of PWA work that side steps PWA Studio and UPWARD and leans on Magento’s new GraphQL endpoints and the traditional REST API.
If you were expecting Magento’s PWA solution to be something like Magento 1 — where any developer could pick it up and have themselves a running working store — all this probably seems bananas (or maybe just disappointing).
However, if you consider our theory on Magento PWA’s goal, this is all going to plan. Adobe has given teams a React based environment to build custom solutions on top of.
Even if developers turn up their nose at PWA Studio specifically, its existence changes the conversations Adobe’s largest customers will have their agencies. Progressive Web Applications are a thing people are asking for.
Wrap Up
That’s where we’ll leave it for today. Next time we’ll take a quick look on how to get started with Magento’s official PWA Studio tooling.