I recently joined a team that was given a month to deliver several commerce applications. When I heard the technology was less 'tried and true' and more 'brand new,' I had two thoughts. First, that rhymes—put it in the article. Second, 'AHHH!' The latter was because I had no commerce experience, and my role as a front-end developer often requires me to anticipate technical challenges. This article is for a general audience, but centers on the front-end developer’s perspective.

Our big picture has three parts: the back-end (Adobe Commerce), an extensibility platform (Adobe Developer App Builder), and the front-end (Adobe Commerce Storefront). For context, here’s the high-level purpose of each.

• Adobe Commerce provides the core commerce infrastructure. Admins and developers can manage typical things like product catalogs, customer data, order processing, and payment integrations.
• Adobe Commerce Storefront is the customer-facing website, with which shoppers interact.
• Adobe Developer App Builder lets developers extend that core functionality with custom apps, integrations, and automations.

Here are my impressions from working on a new tech commerce project with a tight deadline.

Front-end developers can set up a basic storefront website in about 30 minutes using familiar tools like Node and NPM. My onboarding process was about a week of reading documentation, but as is typical with new technology, it could be hit, miss, or absent. At the time of writing, many of the out-of-the-box components were giving 404 errors. Fortunately, I found well-structured content in Adobe’s create your storefront documentation - the foundation for setting up a boilerplate project. The process of connecting a storefront website to a content source (Google Docs for us) had many accompanying visuals and provided high-level overviews before the deep dive.

After setup, the content within Google Docs is fed to the storefront by something called Adobe Edge Delivery Services. When a marketer finishes editing content, they can use a browser extension called Adobe Experience Manager Sidekick to preview and publish the page. A familiar and free content editing platform is one of the ways in which Adobe is aiming to reduce the cost of business ownership.

It’s time for content creation, often referred to as authoring. Text content like headings, paragraphs, and lists are straightforward. However, authoring blocks could get tricky for non-developers, its intended users.

A block is a component - a reusable, self-contained chunk with several things inside. Think of banners, product cards, or that thing no developer built by choice - popups. The tricky parts are when you need your block to pass data to the code; things like class names, attributes, or placeholders where the code will insert real data. Even though you can preview your changes, if that change isn’t visual, it will require opening the browser developer tools to confirm.

Here’s an example of my custom Store Locator block in Google Docs.

Here’s what it generates.

(Pictured above: the full featured open-source map Leaflet)

Behind the scenes, when Edge Delivery Services passes “Store Locator” to our codebase, it looks for a folder called store-locator and runs the files inside. They create the map, fetch store data (Google Sheets), add map markers, and store cards to the sidebar.

You’ve probably noticed that the section metadata matches the layout in each store card. This was one of the ways to pass data to the code. Within the store card, it lets authors choose which datum to display, and where to place it.

So far, I’ve only mentioned content blocks because that’s what I’ve worked with, but there are also commerce blocks which handle the complex aspects of the actual shopping flow.

Lastly, we have the storefront codebase. Front-end developers have seen frameworks and libraries appear at an impressive pace, so it’s nice that this codebase is mostly vanilla. Fortunately, it has “hot reloading” out of the box, and that allows developers to quickly log and learn about anything that’s unclear. I’ll probably write a separate technical article, but in summary, the simple structure, plethora of block examples, and quick local setup should allow new front-end commerce developers to breathe a little more easily. I’ve just begun my commerce journey, but I’m excited to see how this platform will unfold.

If you’re interested in learning more about Adobe Edge Delivery Services and how it can improve content authoring and site speed, contact Blue Acorn iCi.
—