Yet, for Adobe Commerce developers, a clear gap existed.

There was no open-source MCP server tailored to the Adobe Commerce GraphQL APIs—no way to validate, autocomplete, or generate code in real time using AI based on the latest schema definitions.

That’s what motivated me to build the Adobe Commerce Dev MCP Server

What Is It?

It’s an open-source MCP Server built specifically for Adobe Commerce. It helps devs code faster and smarter by enabling AI-powered tools to understand the context of Adobe Commerce’s GraphQL schema.

It’s now publicly listed on:

• Cursor’s MCP Server Directory
• MCP.so

I’ve also published a quick YouTube demo showing how to set it up and use it.

Use Cases

Accelerate Adobe Commerce integrations

Code generation and autocompletion are aligned with the latest GraphQL APIs, directly inside AI-powered dev environments like Cursor.

Troubleshoot smarter

Identify deprecated fields or required inputs in mutations and queries, without digging through outdated docs.

Create a better coding experience

Modernize how we work with Adobe Commerce. Let’s bring some of that “good vibe” experience from other ecosystems into Magento/Adobe Commerce.

What’s New in the Latest Version?

• Hosted on Vercel for instant usage, no local setup required
• Video tutorial included for easy onboarding
• Now listed in major MCP directories for AI dev tools

Let’s Build Together

This project began as a personal proof of concept, but with over 150 downloads and growing interest, I’m excited to see where the community can take it. If you’re working with Adobe Commerce, I’d love your feedback, suggestions—or even better—your contributions.

Special thanks to contributors for the early feedback that helped shape this release.

Check it out on GitHub

The post Why I Built an Adobe Commerce Dev MCP Server (and How It Can Help You Code Faster) appeared first on Rafael Corrêa Gomes.

This article breaks down what this means for your roadmap, especially if you are running versions 2.4.4 through 2.4.6.

Adobe’s Strategic Guidance: Focus on the Future, Not Just the Patch

Adobe is signaling that significant investment in short-term upgrades may not be the best route, especially for merchants considering moving to Adobe Commerce as a Cloud Service within the next 12–16 months. Here’s how to interpret their guidance based on your current version:

1. If You’re on Version 2.4.7

You’re in a unique position. Adobe recommends not rushing to 2.4.8 if your plan is to migrate to ACaCS between Q2 2026 and Q2 2027. Instead, you should:

• Apply the latest security patch
• Avoid unnecessary upgrades
• Begin planning your move to Cloud Service

Your version (2.4.7) will be supported until April 2027, giving you flexibility to align technical efforts with business outcomes.

2. If You’re on Version 2.4.4, 2.4.5, or 2.4.6

You’ll need to move faster. These versions have shorter support windows:

• 2.4.4 support ends April 2026
• 2.4.5 and 2.4.6 support ends August 2026

If you’re not planning to move to ACaCS before Q3 2026, Adobe strongly recommends upgrading to version 2.4.8 to benefit from the latest enhancements and to extend your support window until April 2028.

3. Adobe Commerce 2.4.8: The Final Stop Before the Cloud

Version 2.4.8 is expected to be the last major step before a full cloud-native shift. It delivers platform stability and long-term support (April 2028), making it a safe investment for those who:

• Need more time to prepare for ACaCS
• Require longer-term support
• Are not ready for architectural changes in the next 12 months

Why This Matters for CTOs and Decision-Makers

Adobe’s roadmap is now directly impacting technical strategy. Instead of blindly following version-to-version upgrades, leaders are being asked to:

• Align platform decisions with business objectives
• Consider total cost of ownership (TCO) over time
• Start preparing teams and architectures for a SaaS future

This is a signal to reduce rework and focus on preparing for the changes.

Conclusion Adobe Commerce 2.4.8 isn’t just another upgrade, it’s a transition point. Whether you’re ready to adopt Adobe Commerce as a Cloud Service or need more time, Adobe’s recommendations allow you to choose a clear path.

CTOs should use this moment to assess cloud readiness and ensure their e-commerce infrastructure decisions align with Adobe’s and the industry’s future direction.

Related Links

• Adobe Commerce 2.4.8 Release Notes
• Adobe Commerce as a Cloud Service Overview

The post Adobe Commerce 2.4.8 and Cloud Service Adoption: What CTOs Need to Know appeared first on Rafael Corrêa Gomes.

In today’s fast-paced business world, choosing the right e-commerce platform can make all the difference. For CTOs, the decision between Adobe Commerce as a cloud service and Shopify can be overwhelming. This blog post aims to provide an in-depth analysis of these two platforms, focusing on key considerations businesses must evaluate to make informed technical and business decisions.

Introduction

Hello everyone. Today, we’re diving into a critical comparison for CTOs: Shopify versus Adobe Commerce as a cloud service. We’ll explore essential factors related to business and technical choices necessary for selecting the right platform. With years of experience, I’ve identified four main pillars to consider, offering a clear view of each platform’s position in terms of business analysis.

Identifying the Four Main Pillars

Strict and Complex Requirements

The first pillar involves strict and complex requirements. When a platform needs to be tailored precisely to customer and business needs—such as integrating custom CRM, marketing tools, or ERP systems—strict requirements come into play. These cannot be easily altered, necessitating careful modeling and planning.

TCO and Flexibility

On the right side, we have the Total Cost of Ownership (TCO) and flexibility. TCO increases with customization, as the more flexible a platform is, the more it can be tailored, but at a higher cost. Understanding which components to build from scratch is crucial, as maintaining these custom elements will be your responsibility on either platform.

Faster ROI and Time to Market

On the left, we examine faster ROI and time to market. Moving in this direction allows for rapid platform launch, resulting in a quicker return on investment. Minimal initial investment makes this option appealing for many businesses.

Flexible Business Requirements

Lastly, considering flexible business requirements means adapting your business to the platform, rather than the other way around. By using market best practices and existing tools, businesses can streamline operations and processes, leading to faster time to market and ROI.

Platform Deep Dive

Shopify Basic to Advanced

Shopify’s basic and advanced options offer the fastest way to go live. With no contract required on Shopify Plus, you can create your own store independently, making this a flexible option. It’s ideal for businesses looking for quick ROI and time to market while being adaptable.

Shopify Plus

Shopify Plus maintains a favorable time to market while offering certain flexibilities. To achieve faster ROI, leveraging Shopify’s massive ecosystem of apps is necessary. Customization is possible, but it’s important to note that increased TCO might push you towards headless requirements.

Commerce Components and Adobe Commerce SaaS

Adobe Commerce SaaS and Shopify’s commerce components represent platforms where TCO is higher from the start due to headless architecture demands. Extensive coding and architecture planning are imperative. These platforms provide significant flexibility, but with a trade-off of increased TCO and time to market.

Specific Use Cases

For those needing custom customer experiences, such as scripts for VIP customer interfaces without affecting performance, server-side rendering is essential—highlighting the utility of commerce components or Adobe Commerce. Additionally, businesses needing an unaltered URL structure may find that headless platforms offer the necessary flexibility not available in Shopify Plus.

Conclusion

This high-level comparison provides valuable insights into how Shopify and Adobe Commerce SaaS stand relative to TCO, flexibility, ROI, and business requirements. For CTOs navigating this complex decision, understanding these elements will support better business and technical decision-making. Should you need further assistance, feel free to reach out. Until next time, best of luck with your e-commerce endeavors!

The post A Comprehensive Guide for CTOs: Adobe Commerce SaaS vs Shopify appeared first on Rafael Corrêa Gomes.

Adobe’s Strategic Positioning

One of the first aspects to note is Adobe’s strategic positioning. Unlike Shopify, which offers solutions ranging from small to medium and some advanced business needs, Adobe Commerce Cloud is focusing on enterprise-level businesses right from the start. With its core build being “headless by default,” Adobe provides a framework where the front-end presentation of a store is separate from the back-end operations, allowing for immense customization and integration flexibility.

Understanding the Headless Architecture

For those unfamiliar with headless e-commerce, it involves detaching the front-facing storefront from the back-end system. This separation means that the two communicate through digital connectors, similar to a universal translator, offering businesses the flexibility to tailor both ends independently. Shopify does provide headless solutions but generally as an advanced option requiring Shopify Plus. Adobe’s cloud service integrates this capability from the ground up, signaling its intent to serve businesses with complex, distributed retail environments needing customized solutions.

Targeting Enterprise Needs

Adobe Commerce Cloud clearly targets larger enterprises — those looking to seamlessly integrate their online presence with mobile apps, in-store kiosks, and loyalty programs. It promises rapid provisioning, a notable improvement from traditional cloud setups, yet it does not promise the plug-and-play simplicity associated with Shopify. Instead, it’s about achieving a balance of speed and extensive customization options aimed at enterprise-level needs.

Financial Considerations

Adobe is also aiming to be more financially appealing, indicating lower Total Cost of Ownership (TCO) and licensing costs. This move could make Adobe a more attractive alternative for larger businesses concerned about the traditionally high costs associated with Adobe’s services. By becoming more price competitive with the likes of Shopify Plus, Adobe positions itself as a viable option for large-scale enterprises seeking a specialized approach.

The Ideal Adobe Commerce Cloud User

This service is not tailored for small to medium businesses or those just starting. Instead, it’s for large retailers seeking sophisticated, interconnected e-commerce solutions. Enterprises requiring a high degree of customization and a tailored headless architecture are the primary audience for Adobe’s new cloud service.

Conclusion: Assessing Your Needs

In essence, Adobe Commerce as a Cloud Service is carving a specific niche rather than competing head-on with Shopify. Its launch prompts an important decision for businesses: determining whether an integrated e-commerce platform or a flexible, headless solution aligns better with their current and future needs.

Final Thoughts

For businesses evaluating their options, understanding the intricacies of platforms like Adobe Commerce Cloud versus Shopify and others is crucial. Each business must consider its unique requirements to choose a platform that will grow with their evolving demands. We look forward to seeing how Adobe Commerce Cloud will influence the market and the new opportunities it will open for enterprise-level businesses.

Thank you for joining this deep dive into Adobe Commerce as a Cloud Service. Keep a lookout here for more insights as the June 2025 launch approaches.

The post Adobe Commerce as a Cloud Service is NOT like Shopify appeared first on Rafael Corrêa Gomes.

What’s Changing?

1. Adobe Commerce as a Cloud Service

• A fully SaaS-based eCommerce solution.
• Provisioning in minutes, reducing setup time significantly.
• Always up-to-date with Adobe handling updates and patches.
• Performance Boost: High-speed storefronts powered by Edge Delivery Services.
• AI-powered content creation with built-in A/B testing and intuitive editing tools.
• Scalability: Supports 250M SKUs and 30K unique prices per SKU.
• Seamless integration with Adobe Express and Firefly for content creation and merchandising.

2. Adobe Commerce Optimizer

• Works with any eCommerce system (not just Adobe Commerce).
• Enhances storefront experience, catalog, and merchandising.
• Lightning-fast performance with modern UI and AI-powered personalization.
• Pre-built connectors and APIs for easy integration.
• Advanced reporting for tracking improvements and fine-tuning strategies.

Adobe ensures continued support for existing on-premise and PaaS customers, meaning businesses can transition at their own pace. Companies can adopt Adobe Commerce as a Cloud Service all at once or take an incremental approach, starting with specific components like the storefront or catalog.

What This Means for eCommerce?

Adobe’s move towards a SaaS-first approach signals a significant shift in the industry. Companies looking for reduced Total Cost of Ownership (TCO), faster go-to-market strategies, and high-performing storefronts will find Adobe Commerce as a Cloud Service compelling. Meanwhile, Adobe Commerce Optimizer offers a way for businesses to modernize their commerce experience without major platform disruptions.

For those eager to learn more, Adobe Summit (March 18-20, 2025) will cover these innovations in detail.

Stay ahead in the eCommerce game, explore how these changes can drive your business forward!

The post Adobe Commerce’s Big Announcement: Cloud Evolution & Performance Optimization appeared first on Rafael Corrêa Gomes.

• Multiple teams
• Multiple languages
• Multiple currencies
• Multiple themes
• Multiple payment methods
• Multiple shipping methods
• Multiple domains

Shopify Multi-store Architecture

The first concept to understand is the hierarchy between a Shopify Store and a Shopify Market. Below is a diagram illustrating this hierarchy.

Shopify Markets are groupings of geographic regions that merchants can define within the Markets admin to customize the storefront experience for different groups.

When to Consider Shopify Markets?

Use Shopify Markets if you have international traffic or a multi-language website, common in Canada. Evaluate whether to use Markets or Markets Pro. The Pro version includes additional features like regional payments and taxes. Using Shopify Payments can be advantageous. Shopify Markets is available in all plans.

When to Consider Shopify Multi-store?

Consider a multi-store setup if you have multiple teams, such as when managing two brands, each with its own visual identity and team, or if you operate one site per country. Using a multi-store setup when not needed can complicate management. However, if you have a complex system with independent teams, it helps maintain their autonomy. Note that stock synchronization, theme changes, and app setups are done manually for each store. Multi-store setups are available only for Shopify Plus, which includes 9 expansion stores by default.

Advantages and Recommendations

I recommend using Shopify Markets as soon as you identify international traffic or multi-language needs. This feature enhances UX and SEO throughout your store. Prioritize using Shopify Payments and apps like Shopify Translate and Adapt, and Shopify Geolocation to help with theme customizations.

A common mistake is not leveraging the full potential of Shopify Markets or Multi-stores. To maximize benefits, ensure you have a business or technical strategist on your team or partner with experts.

I lead a team of experts and can help you on this journey. Let me know how we can assist you!

The post Shopify Multi-store Architecture: Simplifying Cross-Border Selling appeared first on Rafael Corrêa Gomes.

Defer: Delayed but Organized Execution

The defer attribute offers an effective way to enhance page loading speed by optimizing the sequence in which JavaScript files are loaded and executed. Here’s how it works:

1. Background Loading: When you use the defer attribute, the associated JavaScript file is loaded asynchronously in the background while the browser parses the HTML and constructs the DOM.
2. DOM-Friendly: One of the primary advantages of defer is that it doesn’t block the DOM construction. The script is executed only after the entire DOM has been built, which ensures a smooth user experience.
3. Execution Timing: Although defer scripts load asynchronously, they maintain their original order of execution as listed in the HTML document. These scripts are executed in the order they appear in the DOM.
4. DOM Load: The DOM load event waits until all deferred scripts are downloaded and executed, ensuring that the webpage is fully functional before scripts are run.
5. External Scripts: The defer attribute is typically applied to external scripts and helps improve the performance of pages containing large or complex scripts.

Async: Independent and Immediate Execution

The async attribute introduces a different loading strategy that offers unique benefits for specific scenarios:

1. Independence: Unlike defer, async loads scripts in parallel with other page elements, but it does not wait for other scripts or the DOM to be fully loaded before executing. This makes it particularly useful for third-party scripts not tightly coupled to your site’s functionality.
2. Immediate Execution: Scripts marked with async are executed immediately after downloading, even if the DOM is not yet ready. This can lead to potential issues if the script relies on DOM elements that haven’t been constructed yet.
3. Third-Party Integration: async is an excellent choice for integrating third-party components such as ads, analytics, and counters. These elements often operate independently from the rest of your page’s functionality.

Choosing the Right Approach

While both defer and async offer benefits. It’s crucial to select the appropriate strategy based on your website’s requirements:

• Use Defer: To ensure that your JavaScript doesn’t interfere with the DOM construction and needs to be executed in a specific order. This is particularly useful for scripts that modify or interact with the DOM.
• Use Async: Integrating self-contained third-party scripts that do not require a fully loaded DOM. This is great for scenarios where scripts don’t need to wait for one another or for the DOM to be ready.

Conclusion

Optimizing the performance of your website involves making informed decisions about how you include and execute JavaScript. The choice between async and defer depends on the nature of your scripts and your specific performance goals. By understanding the differences and considering the benefits and downsides of each approach, you can ensure that your website loads efficiently and delivers a seamless user experience.

Check out my other posts for interesting architecture articles. Images from the page speed checklist website.

The post JS defer vs async appeared first on Rafael Corrêa Gomes.

Since the last release v13.2.0, you can start to use DevContainer online or locally. Here I’ll describe how to start using it.

Github Codespaces

The easiest way to start is by using Github Codespaces. You can initialize your environment by accessing PWA Studio on Github and clicking on Create codespace on develop from there.

All the required initial steps have been executed automatically, installing the NPM packages, running the build, and initializing the watch command through port 10000.

Running PWA Studio locally

After cloning the PWA Studio locally from Github, open in on Visual Studio Code, and you will see this message to open in on DevContainer. Before clicking on it, confirm you have Docker running.

If you missed the button above, you can click on the bottom left side of the screen and Reopen in Container.

Locally might take more time than Github Codespace. In the end, you will have it running, as you can see in the image below.

Now you have an environment ready to test and contribute! Certainly, the best part is that we have it running in development mode. Any change you make to the files will be instantaneously reflected on your local Venia demo store.

For more articles, check out my blog section.

The post PWA Studio setup in minutes appeared first on Rafael Corrêa Gomes.

In web/config/session.php

return [
    'secure' => true,
    'same_site' => 'none'
];

Add a route in your routes/web.php file to generate a CSRF token:

web/routes/web.php

Route::get('/api/csrf-token', fn () => ['csrf_token' => csrf_token()]);

Create a hook for fetching the CSRF token:

web/frontend/hooks/useCsrf.js

import { useAuthenticatedFetch } from './useAuthenticatedFetch'

/**
 * A hook for fetching a CSRF token from the server.
 *
 * The CSRF token MUST be included in every POST, PUT, PATCH, or DELETE
 * request sent to the server as a property called "_token" in the JSON body
 * or by header as X-CSRF-TOKEN.
 *
 * @returns {Function}
 */
export const useCsrf = () => {
  const fetch = useAuthenticatedFetch()

  return async () => {
    const response = await fetch('/api/csrf-token')
    const { csrf_token } = await response.json()

    return csrf_token
  }
}

Then, when submitting a non-GET request, fetch it before submitting the form, for example:

import { Form } from '@shopify/polaris'
import { useAuthenticatedFetch } from '../../hooks/useAuthenticatedFetch'
import { useCsrf } from '../../hooks/useCsrf'

export default function MyComponent() {
  const fetch = useAuthenticatedFetch()
  const csrf = useCsrf()

  const handleSubmit = async formValues => {
    const csrfToken = await csrf()

    const response = await fetch('/api/somewhere', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'X-CSRF-TOKEN': csrfToken  // Include as header
      },
      body: JSON.stringify({
        _token: csrfToken    // OR include as "_token" property on the body, either works
        ...formValues
      })
    })
  }

  return (
    <Form onSubmit={handleSubmit}>
      {/* form contents */}
    </Form>
  )
}

With the hook, you can now easily include CSRF protection on all forms in your React frontend.

Because the React frontend and Laravel backend have different origins, the default ‘same_site’ => ‘lax’ in config/session.php prevents cookies from being correctly in the browser. Setting this to ‘none’ allows the cookies to be set. Settings ‘secure’ to true also ensures the cookies are only set over HTTPS. Once you’ve changed those values, you should be able to see your session cookie stored in the browser. Without the session cookie, the Laravel backend will regenerate a CSRF token on every request, and you will always end up getting a CSRF token mismatch error.

TIP: Always include the 'Content-Type': 'application/json' header when making a POST request, or your Laravel’s request body will be empty.

The post How to set up CSRF protection on Shopify Apps? appeared first on Rafael Corrêa Gomes.

Stores on the Shopify Advanced and Plus plans will continue to have access to the Carrier Service API. Stores on the Shopify plan can continue to request access by contacting Shopify support. Stores on the Shopify Starter or Basic plans that were previously granted access are not impacted by this change and will keep their access to the Carrier Service API.

Next steps

• Update your Shopify App Store listing and any other external communications to reflect this change by January 1, 2023.
• Inform your support staff about the changing access requirements and timelines.

If you need any professional guidance, please let me know!

The post No more Carrier Service API appeared first on Rafael Corrêa Gomes.