DEV Community: Brian Burton

Headless Ecommerce: Real World Test

Brian Burton — Tue, 12 Aug 2025 13:07:27 +0000

We recently completed a project that had complex requirements that wouldn't allow us to use any off-the-shelf hosted ecommerce platforms. We needed to be able to modify everything from the authentication system to simplifying the checkout process and nothing we found checked all of the boxes.

My responsibility was in choosing the OSS platform to build off of and so I dug in and built rough versions of the features we needed in three popular ecommerce platforms: Saleor, Sylius and Medusa JS.

Saleor (Python)

I've been a Python developer for about 15 years and this platform had the steepest learning curve by far. The documentation is sparse requiring the need to dive into the codebase to fully understand the Saleor way of doing things. It took over a week to get a semi-functional prototype almost working before we decided to abandon the platform due to its inflexibility.

Saleor's primary benefits are that it has a very active development schedule and out of the box it's designed to be scalable as it's essentially a monolithic GraphQL service with a job scheduler running beside it. Getting it running in a serverless environment was fairly straightforward, once you understand the architecture (which I gleaned from a Github issue and not the documentation) and all of the requirements.

That's about all of the pros. Saleor is moving away from its plugin architecture, where you could modify how the Core functions, in favor of a Shopify-style app architecture, where you create complete completely isolated apps that acts as intermediaries to provide the customizations you need. The App SDK is very limited, keeping you at an arm's length from its core functionality and preventing the level of customizability you'd expect from an open source project. Here are two examples of its inflexibility and complexity:

Imagine you want to create a simple custom mutatations. To do that you're required to run a completely separate Apollo server to provide Apollo Federation to combine the multiple services into a single GraphQL API. This would make perfect sense if this was a hosted product, but not for an open source self-hosted platform.
A more specific example of the absurdly high wall it's built around itself, it's currently (3.21.0) impossible to set a customer's password without the customer's intervention. You're required to force them through the "Forgot my Password" flow, but if you need to set or change a customer's password the only solution is to modify Core, which at that point you've essentially forked the project.

Opinionated frameworks and platforms are good, but this one feels almost like their roadmap is designed exclusively around their hosted product without consideration of their self-hosted userbase. One developer described it best: "Open sourced Shopify."

Sylius (PHP/Symfony)

In the PHP/Symfony world, Sylius appears to be the most mature "headless" ecommerce platform in that ecosystem. I put "headless" in quotes because it's often listed as a headless ecommerce platform in other lists, but in reality it comes with a fully functional storefront.

We didn't get very far with this one for two reasons:

Following the quickstart guide, they recommend using the Sylius-Standard project to create your development environment. That process is completely broken as it required several restarts to get the database image working only to discover the configured PHP version is incompatible and package.json is missing a library. We ended up building the dev environment from scratch wasting two whole days.
Once the dev environment was running, it ran like a dog on a box with 64GB of RAM. Every single Ctrl+S triggered a 20+ second rebuild by a separate Docker container that exists only to rebuild the assets. Page loads in the admin area took nearly 10 seconds to load. I have no idea why it ran so slowly and frankly I didn't want to lose the time to find out.

I love Symfony and the Sylius framework is written in an understandable and logical manner, but it is far too unpolished and difficult to develop on to consider for this project. This platform was abandoned pretty quickly.

Medusa JS (Typescript)

Compared to the others, it was a breath of fresh air. It's clean, simple modular architecture made adding custom features a breeze without spending days digging through documentation and Github issues.

You want to create a custom API route? Just drop it into the /api directory. Boom, done.

You want to change some core functionality? Create a module. Boom, done.

Want to distribute your module? Make it a plugin. Boom, done.

We created a fully functional prototype with all of the functionality we required in a day. It's lightweight, has a logical code structure and didn't appear to be limited by artificial walls. This is how you build an ecommerce framework.

Conclusion

I dislike publicly critizing open source projects as it's difficult to fully understand the choices behind their roadmaps and I don't want to discount the countless hours that have been invested to get the platforms to their current states. I truly appreciate the work they've put into creating these projects and hope that this is seen as honest feedback.

However coming from a developer/PM perspective where I was required to review and choose which project was the easiest to develop on, most extensible and most mature, the race wasn't even close. Medusa will most definitely be at the top of the list for the next headless ecommerce project.

Saleor Core Hacking: Setting Up Your Development Environment

Brian Burton — Thu, 03 Apr 2025 08:29:55 +0000

Saleor is a headless e-commerce platform that's biggest deficit is its lack of documentation.

If you want to modify Saleor Core directly to create PRs, or in my case, modify its core functionality directly, setting up the development environment is not straightforward. I'm writing this out for both my future reference and to help anyone else in the same situation.

My environment is Windows, PyCharm and Docker Desktop.

Note that if you're only interested in Saleor App development, these instructions are not for you. This is only for anyone needing to change core functionality or to submit PRs.

Step 1: Clone the repository

git clone https://github.com/saleor/saleor.git

Step 2: Open the project in PyCharm and it should notify you of the presence of a devcontainer. Allow it to set up the devcontainer. If it doesn't prompt you, open the .devcontainer/devcontainer.json file and click on the small box to create it.

At this point the supporting containers will be running, but Core won't respond to any requests.

Step 3: Open the Services panel (Alt+8) and drill down to the saleor container.

Step 4: Click on the Terminal button on the right side of the Services panel.

Step 5: Run the following commands:

# Install any missing dependencies
$ poetry install

# Copy the environment variables file
$ cp .env.example .env

Edit the .env file add append these two lines:

ALLOWED_GRAPHQL_ORIGINS=*
ALLOWED_HOSTS=

Continue executing the following commands:

# Update the database structure
$ python manage.py migrate

# Create a super user
$ python manage.py createsuperuser
Email youremail@example.com
Password: 
Password (again): 
Superuser created successfully.

# Populate the DB with example data, if you need to
$ python manage.py populatedb

# Run the server
$ uvicorn saleor.asgi:application --reload

Then access your dashboard at http://localhost:9000 and you should be able to log in.

Cloud Build, Docker and Artifact Registry: CI/CD Pipelines with Private Packages

Brian Burton — Sat, 08 Jan 2022 17:01:13 +0000

If you use Artifact Registry to store private Java/Node/Python packages and Cloud Build to compile your code before deployment, you'll quickly discover that the Docker container it creates can't access the Artifact Registry by default.

This solution was discovered after a day of trial and error so I hope it saves you from the same forehead-to-desk frustration.

Step by Step

Deploy your private packages to the Artifact Registry.
Create a Service Account that only has access to read from the Artifact Registry. In my case I created artifact-registry-reader@<PROJECT>.iam.gserviceaccount.com and gave it access to the Artifact Registry repository as an "Artifact Registry Reader."
Edit the newly created artifact-registry-reader@<PROJECT>.iam.gserviceaccount.com Service Account and under permissions add your Cloud Builder Service Account (<PROJECT_ID>@cloudbuild.gserviceaccount.com) as a Principal and grant it the "Service Account Token Creator" role. [Note, this works even if you use Cloud Build in a separate project.]
Next, your cloudbuild.yaml file should look something like this:

steps:
  # Step 1: Generate an Access Token and save it
  #
  # Here we call `gcloud auth print-access-token` to impersonate the service account 
  # we created above and to output a short-lived access token to the default volume 
  # `/workspace/access_token`.  This is accessible in subsequent steps.
  #
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:slim'
    args:
      - '-c'
      - >
        gcloud auth print-access-token --impersonate-service-account
        artifact-registry-reader@<PROJECT>.iam.gserviceaccount.com >
        /workspace/access_token
    entrypoint: sh
  # Step 2: Build our Docker container
  #
  # We build the Docker container passing the access token we generated in Step 1 as 
  # the `--build-arg` `TOKEN`.  It's then accessible within the Dockerfile using
  # `ARG TOKEN`
  #
  - name: gcr.io/cloud-builders/docker
    args:
      - '-c'
      - >
        docker build -t us-docker.pkg.dev/<PROJECT>/services/frontend:latest
        --build-arg TOKEN=$(cat /workspace/access_token) -f
        ./docker/prod/Dockerfile . &&

        docker push us-docker.pkg.dev/<PROJECT>/services/frontend
    entrypoint: sh

FIVE. This next step is specific to private npm packages in the Artifact Registry, but my app has a partial .npmrc file with the following content:

@<NAMESPACE>:registry=https://us-npm.pkg.dev/<PROJECT>/npm/
//us-npm.pkg.dev/<PROJECT>/npm/:username=oauth2accesstoken
//us-npm.pkg.dev/<PROJECT>/npm/:email=artifact-registry-reader@<PROJECT>.iam.gserviceaccount.com
//us-npm.pkg.dev/<PROJECT>/npm/:always-auth=true

[Note: All that's missing is the :_authToken line]

SIX. Finally my Dockerfile uses the minted token to update my .npmrc file, giving it access to pull private npm packages from the Artifact Registry.

ARG NODE_IMAGE=node:17.2-alpine

FROM ${NODE_IMAGE} as base

ENV APP_PORT=8080

ENV WORKDIR=/usr/src/app
ENV NODE_ENV=production

FROM base AS builder

# Create our WORKDIR
RUN mkdir -p ${WORKDIR}

# Set the current working directory
WORKDIR ${WORKDIR}

# Copy the files we need
COPY --chown=node:node package.json ./
COPY --chown=node:node ts*.json ./
COPY --chown=node:node .npmrc ./
COPY --chown=node:node src ./src

#######################
# MAGIC HAPPENS HERE
# Append our access token to the .npmrc file and the container will now be 
# authorized to download packages from the Artifact Registry
# 
# IMPORTANT! Declare the TOKEN build arg so that it's accessible
#######################

ARG TOKEN
RUN echo "//us-npm.pkg.dev/<PROJECT>/npm/:_authToken=\"$TOKEN\"" >> .npmrc

RUN npm install

RUN npm run build

EXPOSE ${APP_PORT}/tcp

CMD ["cd", "${WORKDIR}"]
ENTRYPOINT ["npm", "run", "start"]

This is NPM specific but you can transfer these concepts to any other GCP resource to give your Docker build containers secure access with short-lived tokens to any resource in your project(s).

Fully Isolating Data in a Multi-Tenant SaaS on Google Cloud using a Token Vending Machine

Brian Burton — Fri, 26 Nov 2021 09:22:45 +0000

If you're building a multi-tenant SaaS, securely isolating customer data not only from other customers but from your own developers is a conversation that you'll have sooner or later. At a former startup, our customers' data was highly confidential and we went to extreme efforts to protect it both from inadvertent exposure caused by software bugs and internal access by employees unless absolutely necessary.

We strived for a hybrid pool/silo architecture, my favorite security strategy to achieve this is one that AWS promotes known as the Token Vending Machine that leverages IAM to isolate customer data.

Essentially an authorized user (1) makes an API request through the API Gateway (2), which calls a custom authorizer to validate the credentials and generate a dynamic IAM policy (3). The dynamic IAM policy is passed to the handler function (4) that locks all further processes into a specific set of resources (5). The elegance of this solution is that it removes the burden of handling tenant security from the developers' hands and moves it down to the platform level. The threat of inadvertently exposing tenant data even at the hands of a malicious developer is almost completely mitigated.

The Problem

Google Cloud doesn't offer the same functionality out of the box:

Endpoints and API Gateway don't support custom authorizers.
Dynamically generated IAM policies aren't supported.

The proposed solutions you'll find on StackOverflow, Reddit and even GCP's own whitepapers all basically say the same thing: "Tenant security should be handled at the app level."

Yuck!

But after days of trial and error, I found a solution that gave us the highly secure tenant isolation we needed on Google Cloud!

The Solution

Similarly as before, the user in Tenant A (1) makes an authorized request to list the users in their tenant (2). The API Gateway passes that to the UsersEndpoint service (3) that has no inherit permission to access any database, so it passes the user's auth token to the TokenVendingMachine (4). The TokenVendingMachine validates the token and based on the custom claims retrieves the tenant's Service Account key file from our secure bucket (5) and returns it to the UsersEndpoint service. Finally we can call our database using the key file (6) and return the results to the user.

Step 1: Onboarding

When a new tenant is created, a tenant-specific Service Account is asynchronously created and the JSON key file is stored in a highly-secured bucket containing tenant key files.

Step 2: Authentication

We use the Identity Platform with multi-tenancy enabled to authenticate users. When a user logs in they exchange their initial token with a custom token containing custom claims such as the user's tenant and role, and that custom token is sent with every subsequent request.

Those custom claims look something like this:

{
  tn: 'tn-xyz987', // Tenant ID
  rl: 'editor', // Role
  rg: 1, // Region
  ...
}

The claims identify the user's tenant, their role and the region that their data resides in.

Step 3: API Requests

When a user's authenticated request hits the API Gateway, it's sent to a Cloud Run service that runs our API. The database and storage buckets are abstracted behind like-named services and require a valid JSON key file in order to access any resource.

So if a user requests a list of users within their tenant, the API's code can be as simple as this pseudocode:

app.run('/users', (res: Request, res: Response) => {
  // Create a new instance of our TokenVendingMachine class
  const tvm = new TokenVendingMachine();

  // Request the key file using the user's auth token
  tvm.get(req.headers.authorization)
    .then(async (key: Credentials) => {
      // The tenant's database name has been embedded in the key
      const db = new Database(key);

      const rows = await db.query("SELECT ...");

      res.json(rows);
    })
    .catch((e: any) => res.status(403));
});

Main Takeaway: The developers can write code as if this is a single-tenant environment!

I know what you're going to say...

Why not issue short lived service account credentials?
Latency. Retrieving an existing key file from a GCS bucket is extremely fast compared to requesting new credentials on each request. Sure you could cache those short-lived credentials, but it creates a new set of problems of storing those securely if your goal is total isolation.

Why not use the Secrets Manager to store the key files?
In a word, cost. At $0.03 per 10,000 operations the costs will add up fast for an API.

Isn't a storage bucket full of key files dangerous?
Not if properly secured. The TokenVendingMachine service has read only access to all objects in that bucket and another service that generates the key file during the onboarding process has write access. There's also have a backend service that regularly cycles the keys so that they don't live on in perpetuity.

Conclusion

What's important is that by separating tenant security from the app level, we achieve reliable, secure storage and access of our customers' data while removing the responsibility of tenant security from our developers' hands.

Cross-Domain Firebase Authentication: A Simple Approach

Brian Burton — Mon, 15 Feb 2021 08:24:26 +0000

If you're reading this you've probably just discovered that Firebase Auth only authenticates for a single domain, yet you need to share that authentication across domains and subdomains and not sure where to start.

I was in the same boat and discovered one developer's approach that helped to point me in the right direction. Here is a simpler approach that's just as secure but with less plumbing and allows the user to authenticate through any of your subdomains.

How Does it Work?

I. Initial Authentication

First the user authenticates using Firebase Auth to obtain an ID Token on the client side on any subdomain. For this example the user authenticates through app1.domain.com.
The user then sends that ID Token via POST to the Cloud Functions endpoint /auth/login on the same subdomain, app1.domain.com.
The Firebase Hosted website rewrites /auth to the AuthFunction Cloud Function.
AuthFunction takes the ID token, verifies it using verifyIdToken() and then calls createSessionCookie() and assigns that value to the __session cookie with the domain .domain.com giving it access to all of the subdomains of the requesting domain. The cookie should have httpOnly=true, secure=true and sameSite=strict set.

Note: __session is the only cookie name that Firebase Hosting allows you to use. Any other cookies get stripped. Source

II. Cross-Domain Authentication

Assume the user is now authenticated on app1.domain.com but we need the user to be authenticated on app2.domain.com. First the user checks if it's authenticated with Firebase Auth client side, then it makes a GET request to https://app2.domain.com/auth/status.
The Firebase Hosted website rewrites /auth to the communal AuthFunction Cloud Function.
The /auth/status endpoint checks for the existence of the __session cookie, then validates the session cookie value with verifySessionCookie(). If valid it calls createCustomToken(<uid>) and returns the custom token to the client. If not it returns a 401 error and clears the __session cookie.
If a 200 status code is returned, the client takes the custom token and calls Firebase's signInWithCustomToken() passing the custom token. Now the user is authenticated on app2.domain.com.
If a 401 status code is returned, the client logs out through Firebase Auth and is sent to the login page.

Destroying a Session

Finally when a user logs out, the /auth/logout endpoint should be called to perform two actions:

Clear the __session coookie.
Optionally call revokeRefreshTokens(<uid>) to revoke all tokens for that user across all devices. Otherwise if you want to revoke authentication on a single device you'll need to monitor for the presence of the __session cookie and if it vanishes the user should be logged out using Firebase Auth. The latter requires that the cookie's httpOnly property is set to false.

To be continued with code examples.