Valtech Accelerators
If we had to build everything from scratch for each project, there's no way we would land the kinds of clients we do. We would blow through budgets before delivering a viable product and no one would be happy. To fix this issue, we've had an internal accelerator for monolith Adobe Commerce (Magento) for years. This includes common features, improvements and fixes assembled into modules we can install on projects. Sometimes when a project team develops a cool feature that would be interesting for other projects, we'll refactor the implementation into a reusable module and add it to the accelerator. Since joining the R&D team I've been the main developer that takes care of this development, adding many modules (especially GraphQL support) to our accelerator. I also take care of the maintenance. When the core platform updates I take care of making sure our modules are compatible and releasing any fixes.
We developed a similar practice for PWA Studio, Adobe's first run a headless commerce. The first issue I needed to tackle for PWA Studio was the developer experience. They provide a mechanism to modify core code during build time, but it's fairly clunky, has some big limitations, and out of the box it's all done in one file. I built out a way to separate this functionality into a better, file based structure while still supporting everything that PWA Studio offers out of the box. I also added even more support so we can modify GraphQL queries easily instead of needing to own the whole query. With this new framework I built out numerous modules to add features and functionality that we can use across all projects. On top of that, the extensibility framework I designed supports modifying our module code so projects can easily customize our packages as needed.
Part of the extensibility I added was adding execution order declaration and blocking mechanisms so projects and modules can handle cross-module dependencies when playing around in the same source file. I also made an ESLint validation rule to ensure all of our packages were making this declaration properly. This rule was added to our PWA Studio coding standards package that I developed so teams can be up and running easily and ensure they're following the correct standards.
Though not exclusive to the accelerator, in 2022 I had the amazing opportunity to work in the Adobe team developing PWA Studio at the time and contribute to the core platform. Amongst other things, I built out a mechanism to inject key data into the initial response from the backend so that initial render can happen a lot quicker, drastically reducing CLS (Cumulative Layout Shift) penalties. With that and other changes I now have the "title" of top contributor to the platform on github
Documentation is also a big part of my job. Not only are all of the new tools I've built well documented with usage examples, I've created guides in our Confluence space for other useful PWA Studio information, such as the request flow. I've also created and administered our PWA 101 and 102 bootcamps, where we onboard new developers into what PWA Studio is and how to develop in the ecosystem. I'm the go-to for PWA Studio related questions and support.
EDS is Adobe's newest offering for headless commerce and it's undoubtedly their future. Although a bit.... interesting with its use of document based content management (yes, document as in Word document) the performance is insane. With no server side rendering we're getting scores of 100 in core web vitals for full-fledge commerce sites. This is unheard of on any other platform. As a reference, some of the better performing monolith platforms get around 20-30, with PWA Studio around 40 in my experience. I've been leading the way in Valtech's two first projects on this new platform with great success on both. I've ensured that the learnings between the two projects are shared properly and also taking that knowledge back to the practice level to apply to our new boilerplate and turn into documentation for any new teams moving to this platform.
It's not only fast on performance but also fast to develop. We were able to go from kickoff to launch in around 3-4 months with a beautiful product by the end of it. And that's with the typical bumps in the road from integrating systems. As we try to sign more clients to the platform, I've helped on many "Proof of Concepts" where we take our boilerplate and in a few days have a mostly-styled version of their current site but running on EDS.
Using one of the "drop-ins" now used in EDS, in a few weeks I refactored a large client's monolith catalog page that was taking 6+ seconds to load and devastating their performance scores, bring it down to around 1.5s.
Part of this shift is also using Adobe I/O. I've used it when setting up their API mesh and I'm looking forward to using it more for future ERP integrations.
As a true developer, if there's a monotonous task that I'm really not into and I can automate or make it easier with a tool, I'm jumping on that. Here are a couple of examples from recent that come to mind.
PCI DSS v4 is required soon so I had to do an analysis of what teams will need to do to be up-to-date. The biggest change for us was basically just more documentation. We need to document the reasoning behind any of the domains in our Content-Security-Policy (CSP) allowlist. A brief explanation for anyone not technical, this is a key bit of information (header) sent from the backend that tells the browser what it can or cannot load on the page. Crucially, it's a way of limiting code from only trusted sources from running. This header is a long list of directives (eg image, script, or iframe) and the domains that are allowed for that type. The excel template I made for documenting all of this had the directives as columns, and the domains were the rows (since a domain can be allowed for multiple types). If there's a match, the cell is green, otherwise it's empty. Going from that long string to the excel sheet would be mind numbing, and a huge amount of time across all the different projects.
Enter the tool. I created a CLI tool where you pass in the full header value and it will output a CSV for the template. Great!
The next step was documenting the "why" for each domain. When doing this process for our accelerator, I found the most crucial bit of information was "what code is adding this domain?". Now, to go through each one of the domains, then search through the code and find where it's used (there could be multiple), and add it to the sheet sounded awful. Not to mention extremely time consuming with my PHPStorm that is slow as hell.
Enter the tool. I added a new command to the CLI tool which accepts the header value and the project path and will output a CSV of the associated modules that include it. Sick!
It works... now time to make it pretty. Especially in my case, I was running this thing a lot and I kept having to re-copy the header value which was a pain. I wanted to make it configurable. So I started adding support for creating a "site" and saving the CSP header value for that site. I also made the project path configurable, and added support for project type, supporting both monolith and PWA Studio. For quick analysis, I also added an option to format the output as a nice looking table in the terminal since looking up values in the CSV form was not going to happen and importing the CSV into excel was a couple extra steps. And of course while I was added it I refactored the whole thing to be in Typescript so it was (maybe?) more maintainable.
Not long after the CSP parser, I was working on updating our EDS boilerplate to the latest version Adobe has. It's an extremely active project and they're making sweeping changes, so it's quite volatile at the moment making updates difficult. The code was one thing, overall going smoothly. The update came with quite a few new features. They added support for cart, checkout, and customer account, all of which we were previously handling with PWA Studio. Most of these new featured required entirely new pages or modifications to existing ones. Since it's all document based this is as easy as just creating a new document in Sharepoint with the right name. However for the content, Adobe currently doesn't provide access to their boilerplate's Sharepoint which means the best source I have access to is a Markdown version of their page. There's no real process available to go from Markdown to a Word document which means I would need to recreate each of the block manually in the new pages. Sounds like a monotonous task to me!
Enter the tool. I made a new CLI tool to convert their markdown into a temporary Word document that automatically opens and deletes itself, allowing you to easily copy the content off to your Sharepoint doc. I also added a command to similarly treat EDS's JSON into excel sheets so I could copy over any new configurations or translations.
Did these tools save me time? Absolutely not. Obviously there's always a balance. In my current role, I'm establishing processes that many other developers are going to use, so the benefits are multiplied.