Nicolò Rebughini

If you've built a Shopify app with a Rails backend, you know the routine. You write a verbose GraphQL query string, fire it through the client, then start drilling into a nested hash response: `response["data"]["customer"]["defaultEmailAddress"]["emailAddress"]`. Repeat that across dozens of queries, each returning a slightly different shape, and your codebase turns into an archaeology dig site where nobody remembers which hash key lives where.

Shopify has been pushing hard toward GraphQL as the primary API surface, deprecating REST endpoints and funneling developers toward a more powerful but significantly more verbose interface. The problem is that Shopify's official Ruby tooling stops at giving you a client and an OpenStruct-style response. There's no domain modeling layer, no way to say "a Product always looks like this" across your entire codebase.

We built [ActiveShopifyGraphQL](https://github.com/nebulab/active_shopify_graphql) to fix that. 

## The Hidden Cost of Raw GraphQL Queries

The pain starts small. You write one query to fetch a product's title and price. Then another to fetch variants. Then someone needs metafields. Before long, you have query classes, query superclasses, helper methods for parsing responses, and OpenStruct wrappers that give you dot notation but still require you to know the exact shape of every response. 

Here's what a typical Shopify GraphQL interaction looks like in Ruby without any abstraction:

```ruby
query = <<~GRAPHQL
  query($id: ID!) {
    customer(id: $id) {
      id
      displayName
      defaultEmailAddress {
        emailAddress
      }
      orders(first: 10) {
        edges {
          node {
            id
            name
          }
        }
      }
    }
  }
GRAPHQL

response = client.query(query: query, variables: { id: "gid://shopify/Customer/123" })
customer = response.body["data"]["customer"]
email = customer["defaultEmailAddress"]["emailAddress"]
created_at = Time.parse(customer["createdAt"])
orders = customer["orders"]["edges"].map { |e| e["node"] }
```

This works, sure. But now multiply it by every entity in your app, and you start having problems:

- **Inconsistent object shapes.** Because GraphQL encourages fetching only what you need, the same conceptual entity (a product, a variant) ends up with different attributes in different parts of your codebase. In one place a variant has a SKU; in another, only a price. Your brain has to work overtime to track which version you're dealing with. 
- **Multiple API schemas for the same data.** If you're building a customer account portal, you might use Shopify's Customer Account API alongside the Admin API. Both can return a customer, but the email address lives at `defaultEmailAddress.emailAddress` in the Admin API and `emailAddress.emailAddress` in the Customer Account API. Same concept, different paths, different code. 
- **Maintenance burden at scale.** When Shopify updates their API version, you need to hunt down every query string scattered across your codebase, update field names, fix response parsing, and update all the tests. That time goes into maintaining plumbing instead of shipping features. 

At Nebulab, we deal with the GraphQL API every day, so we set out to solve the problem once and for all.

## What ActiveShopifyGraphQL Does

The gem lets you define Shopify entities as Ruby model classes with typed attributes, path mappings, and associations. It then auto-generates GraphQL fragments from those definitions, executes queries, and maps responses back to your model instances. No hand-written query strings for standard reads.

Here's the same customer interaction from above:

```ruby
class Customer < ActiveShopifyGraphQL::Model
  graphql_type "Customer"

  attribute :id, type: :string
  attribute :name, path: "displayName", type: :string
  attribute :email, path: "defaultEmailAddress.emailAddress", type: :string
  attribute :created_at, type: :datetime

  has_many_connected :orders, default_arguments: { first: 10 }
end

customer = Customer.includes(:orders).find(123456789)
customer.name       # => "John Doe"
customer.email      # => "john@example.com"
customer.created_at # => 2024-03-15 14:30:00 UTC
customer.orders     # Already loaded, no additional query
```

A few things are happening automatically here:

- The `path` option tells the gem where to find a value in the GraphQL response, so `defaultEmailAddress.emailAddress` gets mapped to a simple `email` attribute on your model.
- Type coercion handles the conversion (strings stay strings, `createdAt` becomes a Ruby `Time` object). 
- camelCase to snake_case conversion is automatic: you define `created_at`, and the gem knows to request `createdAt` from the API.

The `graphql_type` declaration is optional when your class name matches the Shopify type. A class called `Product` will automatically map to the `Product` GraphQL type, but you can override it when Shopify's naming diverges from yours, which happens more often than you'd expect!

### The Query API You Know and Love

If you've used ActiveRecord, the query interface will feel immediately familiar:

```ruby
# Find by GID or numeric ID
customer = Customer.find("gid://shopify/Customer/123456789")
customer = Customer.find(123456789)

# Filter with hash syntax
Customer.where(email: "john@example.com")

# Or Shopify's search query syntax for wildcards
Customer.where("email:*@example.com")

# Chain methods
Customer.where(email: "@example.com")
        .order(sort_key: "CREATED_AT", reverse: true)
        .limit(25)

# Select specific fields to reduce API cost
Customer.select(:id, :name).find(123)
```

The `where` method accepts either a hash (which gets auto-escaped and formatted into Shopify's search syntax) or a raw query string for more complex filtering. Error handling works too: if you query on an unsupported attribute, the gem surfaces Shopify's validation error rather than silently failing. 

Pagination is cursor-based under the hood, as Shopify's GraphQL API requires. The gem handles this transparently:

```ruby
# Automatic pagination up to a limit
ProductVariant.where("-sku:''").limit(100).to_a

# Batch processing with explicit page control
ProductVariant.where("sku:FRZ*").in_pages(of: 50) do |page|
  page.each { |variant| process(variant) }
end

# Lazy enumeration
Customer.where(email: "@example.com").each { |c| puts c.name }
```

### Using Connections and Eager Loading

GraphQL connections (the `edges { node { ... } }` pattern) are one of the most tedious parts of working with Shopify's API. ActiveShopifyGraphQL models them as associations:

```ruby
class Product < ActiveShopifyGraphQL::Model
  attribute :id, type: :string
  attribute :title, type: :string

  has_many_connected :variants,
    class_name: "ProductVariant",
    default_arguments: { first: 10 },
    inverse_of: :product
end

class ProductVariant < ActiveShopifyGraphQL::Model
  attribute :id, type: :string
  attribute :sku, type: :string
  attribute :price, type: :string

  has_one_connected :product, inverse_of: :variants
end
```

By default, connections are lazy loaded. Calling `product.variants` triggers a separate GraphQL query only when you actually access the variants. But when you know you'll need them, `includes` lets you eager load everything in a single query: 

```ruby
# One query fetches the product AND its variants
product = Product.includes(:variants).find(123)
product.variants.each { |v| puts v.sku }  # No additional queries
```

The `inverse_of` option enables bidirectional caching. When you eager load a product with its variants, each variant already knows its parent product without making another round trip: 

```ruby
product = Product.includes(:variants).find(123)
product.variants.first.product  # Returns cached parent, no query
```

This matters because Shopify's GraphQL API has rate limits measured in query cost points: every unnecessary round trip burns through your budget. Eager loading and inverse caching let you get more data in fewer, cheaper queries.

### Bridging the GraphQL API with Your ActiveRecord Models

Most Shopify apps store some data locally in a relational database while pulling other data from Shopify's API.

ActiveShopifyGraphQL includes a `GraphQLAssociations` module that bridges the two worlds:

```ruby
class Rating < ApplicationRecord
  include ActiveShopifyGraphQL::GraphQLAssociations

  belongs_to_graphql :product
  # Expects a `shopify_product_id` column in your ratings table
end

rating = Rating.find(1)
rating.product  # Loads Product from Shopify via GraphQL using shopify_product_id
```

The convention follows a `shopify_{association_name}_id` pattern for foreign keys, but you can override it with `foreign_key:`.

Oh, and going the other direction works too: a GraphQL model can declare `has_many :ratings` to query your local database for associated records.

### Switching Between Admin and Customer Account APIs

One of the trickiest aspects of Shopify development is dealing with the Admin API and Customer Account API simultaneously. They return the same conceptual entities but with different response structures. 

ActiveShopifyGraphQL handles this with the `for_loader` block: 

```ruby
class Customer < ActiveShopifyGraphQL::Model
  graphql_type "Customer"

  attribute :id, type: :string
  attribute :name, path: "displayName", type: :string

  # Admin API: email lives here
  for_loader ActiveShopifyGraphQL::Loaders::AdminApiLoader do
    attribute :email, path: "defaultEmailAddress.emailAddress", type: :string
  end

  # Customer Account API: email lives here instead
  for_loader ActiveShopifyGraphQL::Loaders::CustomerAccountApiLoader do
    attribute :email, path: "emailAddress.emailAddress", type: :string
  end
end

# Same model, different data sources
admin_customer = Customer.with_admin_api.find(123)
account_customer = Customer.with_customer_account_api(token).find(123)

admin_customer.email    # Works
account_customer.email  # Also works, different underlying path
```

Your application code doesn't need to care which API the data came from. A `Customer` is a `Customer`. The cognitive load drops significantly when your team can reason about stable domain objects instead of tracking API-specific response shapes. 

### Loading Metafields and Custom Data

Shopify merchants rely heavily on metafields for custom product data. The gem provides a dedicated `metafield_attribute` method that handles the query generation and response parsing:

```ruby
class Product < ActiveShopifyGraphQL::Model
  attribute :id, type: :string
  attribute :title, type: :string

  metafield_attribute :boxes_available,
    namespace: "custom",
    key: "available_boxes",
    type: :integer

  metafield_attribute :seo_description,
    namespace: "seo",
    key: "meta_description",
    type: :string

  metafield_attribute :product_data,
    namespace: "custom",
    key: "data",
    type: :json
end

product = Product.find(123)
product.boxes_available  # => 24
product.product_data     # => { "weight" => "2.5kg", "origin" => "Italy" }
```

For more complex scenarios like metaobjects (Shopify's custom data models), the gem also supports raw GraphQL injection with custom transforms. This is the escape hatch for when the standard attribute mapping can't express what you need. 

### Setting Up a Shared Base Class

ActiveShopifyGraphQL allows you to configure a base class that your models will inherit from.

At Nebulab, we use this to standardize ID handling across all our models. Shopify uses GIDs (Global IDs like `gid://shopify/Product/123`), but you often need the numeric part for database lookups or URL construction:

```ruby
class ApplicationShopifyRecord < ActiveShopifyGraphQL::Model
  attribute :id, transform: ->(gid) { gid.split("/").last }
  attribute :gid, path: "id"
end

class Product < ApplicationShopifyRecord
  attribute :title, type: :string
  attribute :vendor, type: :string
end

product = Product.find(123)
product.id   # => "123" (numeric part only)
product.gid  # => "gid://shopify/Product/123" (full GID)
```

This eliminates the constant GID-to-numeric-ID conversion that plagues Shopify codebases, especially when you need to compare IDs coming from Liquid themes (numeric) with IDs from GraphQL (GIDs). 

Of course, you can also use the shared base class for custom helpers and any other logic you don't want to duplicate.

## Where the Gem Is Headed

Right now, ActiveShopifyGraphQL is read-only. Mutation support is on the roadmap but presents some challenges due to how inconsistent Shopify mutations are.

The roadmap also includes metaobject modeling as first-class models, a caching layer, advanced error handling with retry mechanisms, and rate limit management.

We'll keep building these features as the need arises in our client projects, so stay tuned for updates!

## Ready to Put the Joy Back Into graphQL?

Raw GraphQL in a growing Shopify app creates a maintenance burden that compounds over time: inconsistent object shapes, duplicated query logic, manual type coercion, and the constant mental overhead of tracking which hash key lives where.

ActiveShopifyGraphQL replaces that with stable domain models, typed attributes, and an interface that Rails developers already know.

The library is production-tested, available as a [Ruby gem](https://badge.fury.io/rb/active_shopify_graphql), and ready to drop into your existing Shopify app. Give it a try, open an issue if something breaks, and let us know what you'd build on top of it!

And if you're building a Shopify app or custom storefront and drowning in GraphQL boilerplate, we've been there. [Let's talk!](https://nebulab.com)


ActiveShopifyGraphQL: The Library That Puts The Joy Back into Shopify's GraphQL API

Andrew Vathanakamsang

If you're running NetSuite as your ERP and Shopify as your storefront, you've probably encountered Celigo. Maybe you're new to the team and you've spotted "integrator.io" in the Shopify apps. You're wondering: how exactly does this sync orders, inventory, and customer data between our systems?

For some brands, Celigo is infrastructure that just works. For others, it's a annual expense that creates as many problems as it solves. The difference comes down to understanding what Celigo actually does, what it costs beyond the sticker price, and whether your operation genuinely needs it.

Here's how to make that call.

## What Celigo Actually Does

Celigo is an integration platform as a service (iPaaS) designed to move data between applications without writing custom code. Think of it as centralized plumbing for your tech stack—instead of building separate integrations between Shopify and NetSuite, Shopify and Klaviyo, NetSuite and your warehouse management system, you manage all those connections in one place.

The platform works through **flows**—automated processes that move data from a source endpoint to a destination endpoint. A flow might listen for new orders in Shopify via webhook, transform that data into the format NetSuite expects, and create a sales order record. Another flow might sync product data from NetSuite to Shopify every hour, ensuring your website inventory stays current.

Celigo provides several tools to build these flows:

- **Pre-built connectors** for popular applications (particularly strong for NetSuite + Shopify)
- **Visual mapping tools** to transform data from one schema to another
- **Filters and branching** to route data based on conditions
- **Lookup functions** to enrich data from additional sources
- **JavaScript hooks** for custom logic when visual tools aren't sufficient
- **Error handling and monitoring** with audit logs and alerting

The interface resembles Shopify Flow—visual, configuration-driven, accessible to non-developers. The difference is scale and sophistication. While Shopify Flow handles simple automation within the Shopify ecosystem, Celigo manages complex, bi-directional data flows across enterprise systems.

## The NetSuite Advantage

Celigo's strongest use case is NetSuite integration. The company has deep ties to NetSuite (their offices are reportedly close to each other), and their marketplace includes pre-built integration bundles for NetSuite + Shopify that handle common scenarios out of the box: order sync, inventory sync, customer sync, and fulfillment updates.

These pre-built integrations are both Celigo's biggest strength and a potential limitation.

On the strength side: they work well for standard use cases, getting you operational quickly without custom development. A typical flow might sync product data managed in NetSuite to your Shopify storefront, or push new Shopify orders into NetSuite for fulfillment. The integration handles the heavy lifting—API authentication, rate limiting, data transformation, error handling—without requiring deep technical expertise. And Celigo maintains these integrations as APIs change, which means you're not scrambling to fix broken integrations every time Shopify or NetSuite releases an update.

On the limitation side: these pre-built integrations are black boxes. You install an app, configure settings, and trust that the underlying logic works correctly. You don't have full transparency into how data flows or how edge cases are handled. When you need customization beyond what the pre-built integration supports—and most brands eventually do—you're layering custom code on top of an abstraction you don't fully control.

For brands running standard NetSuite + Shopify operations, this trade-off often makes sense. The pre-built integration handles 80% of requirements immediately, and you can customize the remaining 20% as needed. For brands with complex, highly customized workflows where the integration itself is a competitive advantage, the black box becomes a constraint.

## The Real Costs Beyond the Price Tag

Celigo's pricing is a function of the number of endpoints (applications you connect) and flows. Connect Shopify, NetSuite, Klaviyo, a CRM, and a marketplace, and you're looking at multiples of that base price.

Beyond licensing costs, there's operational overhead that doesn't appear on the invoice but directly impacts whether Celigo delivers value:

- **Ownership and expertise.** Despite marketing that positions Celigo as a no-code solution for business users, complex integrations still require technical expertise. You need someone who understands API rate limits, data transformation, error handling, and the quirks of each connected system. That person needs to read documentation, debug cryptic error messages, and make architectural decisions about data flow. The visual UI makes simple things easier, but it doesn't eliminate the need for technical competence. You're not avoiding development work—you're doing development work in a different interface.
- **Testing limitations.** Unlike custom code with unit tests and CI/CD pipelines, testing Celigo flows is primarily manual. You can use sandbox environments and clone flows for testing, but you're essentially testing in production. When you embed JavaScript hooks within flows—a common pattern as integrations grow more complex—that code typically isn't covered by automated tests. For teams accustomed to test-driven development and code review processes, this feels like a step backward. The ease of making changes in a visual interface means changes happen without the rigor you'd apply to custom code.
- **Change management and sprawl.** The ease of building flows is a double-edged sword. When anyone can create a new flow to solve a problem, flows multiply without oversight. Someone builds a new flow, the old flow gets turned off but never deleted, and six months later nobody remembers why either exists. Without discipline around documentation, review, and cleanup, Celigo becomes a sprawl of undocumented integrations that's harder to maintain than well-structured custom code. And because you're charged per connection, unused flows that remain active are literally costing you money for nothing.
- **Vendor lock-in.** The more flows you build in Celigo, the more committed you become to the platform. Migration costs grow with every integration. This isn't unique to Celigo—it's true of any iPaaS—but it's worth considering upfront. You're not just buying a tool; you're committing to an ecosystem. If Celigo's pricing changes, if the platform doesn't scale with your needs, or if you need capabilities Celigo can't provide, extracting yourself becomes expensive and time-consuming.

## When Celigo Is the Right Choice

Despite these considerations, Celigo is the right choice for many e-commerce brands. You'll know you're a good fit if:

- **You're using NetSuite.** If your ERP is NetSuite and you need to sync data with Shopify, Celigo's pre-built integrations are hard to beat. The alternative is building and maintaining custom NetSuite integrations, which is expensive and time-consuming. NetSuite's API is powerful but complex, and keeping integrations current as both platforms evolve requires ongoing development effort. Unless you have highly specialized requirements that the pre-built bundle can't accommodate, Celigo will get you operational faster and cheaper than custom development.
- **You have multiple integration points.** The value of a centralized integration platform grows with the number of connections. If you're syncing data between Shopify, NetSuite, Klaviyo, a CRM, multiple marketplaces, and a warehouse management system, consolidating those integrations in one place provides real operational value. Monitoring, error handling, and maintenance all happen in one interface instead of scattered across multiple systems. When an integration fails, you have one place to check. When you need to understand how data flows through your stack, you have one source of truth.
- **You have budget and dedicated ownership.** Celigo isn't a casual purchase, but for brands doing $50M+ in revenue where integration failures directly impact operations, the cost is justifiable. Equally important: you need someone to own the platform. This doesn't have to be a full-time role, but it needs to be someone's responsibility to maintain flows, review changes, monitor errors, optimize connections, and audit what's actually being used. Without ownership, Celigo becomes expensive shelfware that creates more problems than it solves.
- **Pre-built connectors exist for your stack.** Celigo's marketplace includes over 700 application connectors. If the vendors in your tech stack are well-represented—particularly if you're using popular e-commerce tools like Klaviyo, NetSuite, various marketplaces, and common CRMs—you benefit from pre-built integrations that Celigo maintains. If you're connecting to niche systems or building everything with universal HTTP connectors, you're doing custom development anyway. At that point, the value proposition diminishes significantly.

## When Custom Integration Makes More Sense

Conversely, Celigo is probably the wrong choice if your requirements, team structure, or workflows don't align with what the platform does best:

- **Your integration needs are simple.** If you're only syncing data between two or three systems with straightforward requirements, custom integrations or lighter-weight tools may be more cost-effective and easier to maintain. Paying for infrastructure you could build and maintain with a few hundred lines of code doesn't make economic sense.
- **You have strong in-house development capability.** Teams comfortable building and maintaining API integrations, implementing queue-based job systems, and writing comprehensive tests may find custom integrations more flexible and easier to reason about than visual flows with embedded JavaScript. If your engineering culture prioritizes code quality, test coverage, and version control, Celigo's visual interface and limited testing capabilities will feel like a constraint rather than an enabler.
- **Your workflows are highly customized.** Pre-built integrations work best for standard use cases. If your business processes are differentiated and complex—if the way you handle orders, inventory, or customer data is a competitive advantage—you'll end up customizing so heavily that you're essentially building custom integrations within Celigo's framework. At that point, the framework becomes overhead rather than value. You're paying for abstraction that gets in your way.
- **Testing and code quality are non-negotiable.** If your engineering culture requires comprehensive test coverage, code review, and version control for all business logic, Celigo's primarily manual testing approach and visual interface won't meet your standards. The JavaScript hooks you embed in flows aren't easily testable. Changes to flow configuration don't go through pull requests. You're trading control and rigor for convenience, and that trade-off may not be acceptable.

## Making Celigo Work For You

If you decide Celigo is right for your operation, success depends on treating it like critical infrastructure rather than a set-it-and-forget-it tool. Apply the same rigor you'd use for custom code:

- **Establish ownership.** Assign someone—whether an internal team member or an external partner—to own the platform. This person reviews all changes, maintains documentation, monitors errors, and ensures flows follow consistent patterns. Without ownership, Celigo becomes a free-for-all where flows proliferate without oversight.
- **Implement change management.** Don't let the visual interface create a culture where anyone can modify production flows without review. Require review before flows go live, maintain documentation for each integration, and create regular backups using Celigo's snapshot feature. Treat flow changes like code commits—document what changed, why it changed, and what the expected impact is.
- **Audit regularly.** Review active connections quarterly. Disable flows that aren't being used. Delete deprecated integrations. Connection count drives cost—keeping unused connections active is literally paying for infrastructure you don't need. We've worked with brands running 40+ active flows where only 12 were actually necessary. The rest were duplicates, abandoned experiments, or workarounds that outlived the problems they solved. Each represented both technical debt and unnecessary licensing costs. Regular audits prevent this waste.
- **Plan for testing.** Accept that testing will be more manual than with custom code. Use sandbox environments where possible, clone flows for testing changes, and maintain detailed runbooks for validating integrations after updates. When you embed JavaScript in flows, test that code in isolation before deploying it. Recognize that you're essentially testing in production, and plan your deployment process accordingly.
- **Monitor proactively.** Configure alerts for critical flows. Review error logs regularly. Integration failures are often silent—data stops syncing but no one notices until inventory is wrong or orders are missing. Proactive monitoring catches issues before they impact operations. Set up notifications for flow failures on mission-critical integrations like order sync or inventory updates.

## Making the Build-vs-Buy Decision

The build-versus-buy decision for integrations isn't primarily technical—it's strategic. Celigo works best when your competitive advantage lies elsewhere. If data synchronization is necessary infrastructure but not a differentiator, buying a platform lets you focus resources on what actually distinguishes your brand in the market.

But if your integration requirements are unique, if your workflows are a competitive advantage, or if you have the capability to build and maintain custom integrations efficiently, Celigo may add complexity without commensurate value.

The wrong answer is choosing based on what seems easiest in the moment or because NetSuite + Shopify brands just use Celigo. The right answer requires understanding your actual requirements, your team's capabilities, your budget constraints, and your long-term technical strategy.

Trying to decide whether Celigo's annual fixed cost and ongoing maintenance cost makes sense for your operation? Dealing with flow sprawl in an existing implementation? Or evaluating whether custom integration would serve you better? We help e-commerce brands make this evaluation based on their actual requirements, team capabilities, and strategic priorities. [Let's talk!](https://nebulab.com/contact-us)


Before You Buy: What Shopify Brands Need to Know About Celigo

Nick Belzer

In our work with e-commerce brands, we frequently encounter a common challenge: how do you build trust in systems that operate invisibly? While custom algorithms and automation solutions may be working flawlessly behind the scenes, both business teams and customer service representatives often struggle to confidently explain these processes to stakeholders and customers.

This scenario plays out repeatedly across e-commerce operations. While custom solutions deliver tremendous value, their invisible nature creates four critical challenges:

* Reduced trust in automated systems
* Limited opportunities for cross-team collaboration
* Increased support resolution times
* More difficult iterative improvements

The good news? We've developed several approaches to solve these visibility challenges, each suited to different business needs and constraints.

Let's explore each approach, starting with the quickest to implement and moving toward more comprehensive solutions. We'll share real implementation experiences and help you understand which solution might work best for your specific situation.

## 1. Tags

The simplest place to start is with Shopify's built-in tagging system. These lightweight markers can provide immediate visibility into system states and trigger automated processes. The beauty of tags lies in their simplicity – they're provided out of the box on Shopify and integrate seamlessly with existing workflows.

At Tannico, one of Italy's leading wine retailers, we use tags to control their product synchronization with their enterprise resource planning system. When products need to be synced, the operations team can simply add a specific tag, and our middleware picks up these tagged products for processing. This gives the team direct control over the sync process without needing to understand the underlying technical complexities.

## 2. Metafields

As your needs grow more sophisticated, metafields offer structured data storage capabilities that go beyond simple flags.

Again looking at our work with Tannico, we use metafields to store and control parameters for their third-party pricing engine. This allows the team to fine-tune pricing rules and see their effects directly within Shopify, making complex pricing management feel like a native part of their workflow.

While metafields require more planning and development effort than tags, they provide much richer data visibility without adding significant complexity to operations. They're particularly valuable when you need to store detailed configuration data or track complex states that can't be captured with simple tags.

## 3. Admin UI Extensions

When simple flags and data storage aren't enough, Admin UI Extensions offer a more sophisticated approach. These extensions allow you to create custom interfaces directly within the Shopify Admin, making complex operations more intuitive and accessible to your team.

[Our work with Cometeer](https://nebulab.com/case-studies/cometeer) serves as a perfect example of this approach. Their algorithm was making sophisticated decisions about which coffees to include in each box, considering factors like customer preferences, previous orders, and inventory availability. However, without visibility into this process, it was difficult for teams to understand and trust these selections.

![](https://cdn.sanity.io/images/kqgmf0g2/production/a6b7f0a08d0748f778e20893e2dbb0a5373d226f-1386x1050.png?fit=clip)

We transformed this "black box" system into a transparent one through a comprehensive Admin UI extension that visualizes the entire decision-making process. The results were remarkable: customer service representatives could now explain algorithm selection decisions, the time required for algorithm adjustments dropped as developers could now see exactly how their changes affected the selection process and, perhaps most importantly, non-technical team members began contributing valuable suggestions for improvements.

While this approach requires more initial investment in development time and resources than tags or metafields, it offers the most flexibility for complex interactions and rich data presentation.

## 4. Third-Party Platforms

As systems grow more complex, teams often need more sophisticated ways to interact with custom logic. While the previous solutions work well within Shopify's Admin interface, sometimes the best approach is to meet your teams where they already work by integrating with their daily platforms.

Many customer service and operations platforms like Zendesk and [Kustomer](https://developer.kustomer.com/kustomer-apps-platform/docs/widgets) provide robust API integration capabilities. This means you can surface key data from your custom Shopify solutions directly within these platforms and, more importantly, enable actions to be taken from there.

![](https://cdn.sanity.io/images/kqgmf0g2/production/15f920216eff929c332ecf67a9c340c42f28cd27-956x1168.png?fit=clip)

At [MeUndies](https://nebulab.com/case-studies/meundies), we integrated their custom subscription logic directly with their customer service platform. This meant that when handling customer inquiries, support teams could see relevant subscription data (like upcoming shipment dates and product preferences) and perform actions like skipping deliveries or updating preferences—all without leaving their familiar support interface. The integration eliminated constant switching between tools and made customer interactions more efficient.

The complexity of this approach varies based on the platform you're integrating with. Data exposure typically involves formatting and forwarding information through authenticated API requests. Enabling actions requires more setup as you'll need to create secure endpoints in your middleware to handle authenticated requests from the third-party platform. While this requires careful planning and ongoing maintenance, it can significantly streamline workflows for teams that spend most of their day in these platforms.

## 5. Custom Frontends

While the previous approaches cover most use cases we encounter, there are times when you need complete control over the user experience. In these situations, creating a custom frontend offers the ultimate in flexibility. Shopify provides robust support for embedding custom applications directly into the Admin Panel through their embedded app framework, with dedicated libraries for both Remix and Rails to handle the complexities of setup and authentication.

This approach gives you complete control over the user interface and functionality, allowing you to create exactly the experience your team needs. While we haven't found this level of customization necessary for most clients at Nebulab – the other solutions typically provide sufficient flexibility – it's worth considering for unique use cases that require specialized interfaces or workflows.

![](https://cdn.sanity.io/images/kqgmf0g2/production/53bfe0a056a980d2d3bc89539ca562d0f4993be7-2880x1620.png?fit=clip)

Development platforms like [Retool](https://retool.com), [Replit](https://replit.com) and [Gadget](https://nebulab.com/blog/building-shopify-apps-with-gadget) can significantly accelerate this process. Retool's drag-and-drop interface builder and pre-built components can reduce frontend development time by 50-70%, while Replit's collaborative development environment streamlines the iteration process. These platforms handle much of the foundational setup work, letting your team focus on building the unique features your business needs.

The trade-off here is still higher development effort and maintenance complexity compared to other solutions we've discussed, even with these acceleration tools. However, for organizations with highly specific needs or unique operational requirements, the investment can pay off through perfectly tailored workflows and improved team efficiency.

## Choosing Your Path

The best visibility solution for your organization depends on your specific needs and constraints. Here's a quick decision guide:

* **Tags**: Best for simple status tracking and quick wins with minimal investment
* **Metafields**: Ideal for structured data storage and analysis platform integration
* **Admin UI Extensions**: Perfect for complex interactions and rich visualizations
* **Third-Party Integration**: Choose when teams primarily work in other platforms
* **Custom Frontends**: Best for highly specialized needs requiring complete control

**Our experience has taught us that successful implementations start small and scale up based on actual usage patterns.** Begin by identifying which processes are currently invisible and causing pain points for your teams. Then start with simple solutions that address these immediate needs, gather feedback from users, and iterate based on real-world usage. Document everything thoroughly and train your teams effectively – visibility tools are only valuable if people know how to use them.

**You'll know your implementation is successful when you see**:

* Customer service resolution times decreasing
* Internal teams expressing greater confidence in automated systems
* Cross-team collaboration increasing
* System maintenance time and error rates improving

**These metrics consistently improve with better visibility into custom solutions.**

Ready to explore how these visibility solutions might work for your specific needs? [Contact our team](https://nebulab.com/contact-us) for a consultation. We'd love to help you bring your custom solutions into the light.

Into the Light: Bringing Visibility to Your Shopify Customizations

So, you’ve reached the hard conclusion that [you need to build some middleware](https://nebulab.com/blog/ecommerce-middleware) for your Shopify store—perhaps you need to integrate with an exotic third-party system that doesn't offer a native app, or you have a complex subscription flow that cannot be accommodated by an off-the-shelf solution.

But once you've mapped out all the business requirements, you're still left with a million decisions to make: where should you host your middleware? What's the best architecture, a monolith or microservices? Should your code run on a fixed cadence or respond to Shopify's webhooks?

In this article, we're publishing some broad technical considerations we've collected over the years while working on middleware implementations for our clients. We suggest treating these as general guidelines: your mileage may vary depending on your requirements, team composition, and growth stage.

Let's dive in!

## Reactive vs. Scheduled Middleware

The first crucial architectural decision you'll make is whether your middleware should be reactive or scheduled.

Reactive middleware responds immediately to events triggered by external actions, such as customer purchases or inventory updates. It's the preferred choice when dealing with time-sensitive business logic, such as sending email notifications or updating order information.

In reactive middleware, incorporating a queue mechanism is imperative to facilitate the asynchronous processing of incoming event payloads. By decoupling the reception of webhooks from the actual processing logic, queues create a buffer that allows your middleware to absorb workload spikes seamlessly. They also mitigate the risk of data loss during processing disruptions, ensuring that all incoming events are reliably processed.

Queues are de facto mandatory when building middleware for Shopify, as your store will deactivate your webhook subscription [in case of multiple failures/timeouts.](https://shopify.dev/docs/apps/webhooks/best-practices#respond-quickly)

Additionally, you should design reactive middleware to be idempotent and resilient against race conditions, e.g., when handling duplicate or out-of-order event notifications. This allows brands to mitigate the risk of data corruption.

Scheduled middleware, on the other hand, operates on a predefined cadence, executing tasks at regular intervals. It's the preferred choice when dealing with bulk data operations, such as subscription processing or (in some cases) integrations with third-party systems.

Because scheduled middleware might process a substantial amount of data during each execution, optimizing performance and resource utilization is essential. This can be achieved by grouping data into manageable chunks and processing it in batches, minimizing resource contention and maximizing throughput. When integrating with third-party systems, it's also essential to be mindful of rate limits, maximum payload sizes, and the opportunity to leverage batch APIs whenever available.

By understanding the distinct functionalities of reactive and scheduled middleware, businesses can leverage these tools strategically to orchestrate complex workflows and optimize their Shopify operations for efficiency and scalability.

## Monoliths vs. Service-Oriented Architectures

Especially in larger projects, it's tempting to implement your middleware logic as a constellation of microservices, making up what's typically called a Service-Oriented Architecture, or SOA for short. Technically, these services may run as traditional long-lived web applications, but we often see them deployed in serverless environments such as AWS Lambda or Cloudflare Workers.

The theory is that this design increases technical freedom and reduces maintenance overhead: for instance, the subscription processing engine may be implemented using a technology different from the WMS integration. Plus, if they're deployed as serverless functions, there's no need to worry about scaling the services to match transaction volume because the infrastructure provider will handle that responsibility for us.

In our experience, however, most SOA setups suffer from premature optimization. The additional freedom and scalability come at the expense of a more complicated development and infrastructure setup, with multiple codebases to maintain and constraints on the deployment process. Code reuse is also more complicated, and rather than going through the hassle of building and maintaining an internal SDK, engineering teams often end up duplicating the shared code. In other words, the additional effort and complexity often outweigh the gains.

Because of this, when faced with complex middleware architectures, we always consider whether there's a chance to simplify things by moving to a [Majestic Monolith](https://signalvnoise.com/svn3/the-majestic-monolith/) deployed as a traditional, long-lived Web application. While they're not as fancy as a serverless SOA, monoliths have several advantages:

* Engineers only need to work in one codebase to make orthogonal changes, which makes it easier to work atomically.
* Code sharing across API endpoints and scheduled jobs is trivial since everything's in the same application.
* We only need to write and maintain a single deployment pipeline, which makes deployments simpler and more robust.
* We eliminate the need to deal with network failures, data model inconsistencies, and data synchronization issues.
* It's still easier and cheaper to find and onboard new engineers on a monolith vs. a SOA.

This is not to say that microservices and serverless architectures are always bad. There are situations where they can help with scalability, e.g., for trivial middleware that only needs to respond to a specific webhook (in which case a serverless infrastructure is acceptable) or when a particular piece of business logic can be optimized by rewriting it in a more suitable technology. However, these pros always need to balance against the additional complexity introduced into the system.


## Keep Your Options Open

As we mentioned at the beginning of this article, your mileage may and will vary, especially as time passes and your middleware starts taking on more responsibilities. Our suggestion is to regularly re-evaluate your design and architectural choices to ensure that your current setup is still the ideal fit for your needs.

Furthermore, remember that the best middleware is no middleware. Whenever you see an opportunity to simplify your architecture by removing custom logic in favor of a third-party solution, you should seriously evaluate it. E-commerce brands are not tech startups, and every dollar you save in development costs is a dollar you'll be able to invest in other areas of the business.

If you are struggling with fine-tuning your custom integrations or business logic, [don’t hesitate to reach out](https://nebulab.com/contact-us): we can help you navigate and streamline the complexity, finding the ideal setup for your brand.

Designing and Scaling High-Throughput Shopify Middleware

On August 28, 2025, [Shopify will sunset the ability to customize your `checkout.liquid` template](https://shopify.dev/docs/themes/architecture/layouts/checkout-liquid).

Newly created stores on the Shopify platform will already notice that they cannot use this template to customize their payment steps, thank you, and order status pages. Shopify is reigning in control over these pages and forcing merchants to migrate to [Checkout Extensibility](https://www.shopify.com/plus/upgrading-to-checkout-extensibility?shpxid=169152ee-9333-4686-13FB-D40F49B3F520). [Recent articles](https://www.shopify.com/plus/customers/monos) published by Shopify promote Checkout Extensibility as the faster and more maintainable way to extend your store’s checkout experience.

Unfortunately, with limited control over the checkout, thank you, and order status pages, merchants have also lost the ability to place tracking pixels on these pages. To remedy this, Shopify has introduced [Web Pixels](https://shopify.dev/docs/apps/marketing/pixels). Web Pixels can be either standalone (Custom Pixels) or part of a Shopify App (App Pixels), and merchants can use them to track both predefined and custom analytics events.

In this article, we’ll examine the inner workings of App Pixel and Custom Pixels and discuss alternatives merchants can deploy when they need additional granularity in their data.


## App Pixels

App Pixels are part of Shopify Apps that you install: for example, the [TikTok app](https://apps.shopify.com/tiktok) provides an App Pixel out of the box–you just need to enable it from the Shopify Admin.

There are several benefits to using App Pixels over adding custom tracking code to your theme: the new structure simplifies the installation and removal of the pixel, allows you to comply with customer privacy regulations out of the box, and streamlines the integration of your tracking logic across different types of checkout (e.g., Shop Pay vs. one-page vs. three-page checkout).

While this new approach to tracking pixels is a significant step forward, not every platform has a Shopify App available; therefore, not every platform exposes an App Pixel. If your tracking platform does not have an App Pixel you can install, you might need to go with Custom Pixels.


## Custom Pixels

Custom Pixels can be used to integrate tracking platforms that do not expose an App Pixel or when you want to track a custom event or datapoint. Your pixel can subscribe to a [fixed set of events that Shopify publishes](https://shopify.dev/docs/api/web-pixels-api/standard-events) or to [custom events](https://shopify.dev/docs/api/web-pixels-api/emitting-data) published by your theme and send the information to an external service.

Similar to App Pixels, Custom Pixels can be enabled and disabled through the Shopify Admin, and they automatically conform to the customer’s privacy preferences, which makes them a powerful tracking solution fully integrated within Shopify.

With that said, Custom Pixels also have their limitations.

First of all, Custom Pixels [are sandboxed in iframes](https://shopify.dev/docs/apps/marketing/pixels#lax-sandbox-custom-web-pixel). Because of that, you might run into limitations with specific tracking scripts. We recommend working with your tracking platform to resolve these issues whenever possible.

Secondly, Custom Pixels only have access to a limited set of data. During a recent migration from custom checkout scripts to Web Pixels, we encountered a limitation on some Custom Pixels, specifically around conversion tracking. By default, Shopify publishes the `checkout_completed` event. As part of this event, Shopify [sends along limited order- and customer information](https://shopify.dev/docs/api/web-pixels-api/standard-events/checkout_completed). However, The tracking tags installed on our store used additional information, like the customer order count and type of purchase, that we originally included in the checkout script.

If you run into such limitations, there are a few alternatives you can try. That being said, each comes with trade-offs, and you should ensure the additional implementation and maintenance effort is worth it.


## Server-Side Tracking

Instead of relying only on Web Pixels, you can use server-side tracking to enrich (or replace) the data sent to your tracking platforms. Because this logic is not running in the browser, you can call the Admin API and access attributes that would otherwise not be available through the Storefront API.

This is a significant advantage, but it comes at a cost: you’ll have to manage custom code that runs on a separate server (or on a platform [such as Gadget](https://nebulab.com/blog/custom-shopify-automations)), and you will not be able to benefit from Shopify’s primitives for Web Pixels, putting the onus on you to deal with aspects such as privacy preference compliance.

An interesting middle ground is to use the [Shopify Flow](https://apps.shopify.com/flow) app. With the ability to [send HTTP requests](https://help.shopify.com/en/manual/shopify-flow/reference/actions/send-http-request) and the [new action to run custom JavaScript code](https://help.shopify.com/en/manual/shopify-flow/reference/actions/run-code), Flow gives you a robust set of tools to send information to an external API with attributes that your Web Pixels or frontend logic cannot easily access. You’ll still need to maintain the logic required for your solution, but Shopify will at least take care of hosting and executing it.


## Checkout Extensions

One of the benefits of the new Checkout Extensions system is that you can inject custom logic and UI into your checkout. Shopify allows extensions [to publish custom analytics events](https://shopify.dev/docs/api/checkout-ui-extensions/2024-01/apis/analytics) with any attributes you want. As Checkout Extensions have fewer restrictions than Custom Pixels, they can be used to pull extra information from the Storefront API and emit a custom analytics event. Your Custom Pixel can then send this event to any third-party tracking platform.

The implementation and maintenance cost here is relatively low: as long as your Checkout Extension adheres to the official APIs, this can be a reasonably robust solution. However, because Checkout Extensions can only access the Storefront API, you will have access to a more limited dataset than with server-side tracking.

You will also need to set up a custom Shopify app on your store and expose the extension to your theme. Luckily, Shopify makes this relatively easy by providing robust tooling and hosting the app directly, which means you don’t need external servers.


## Session Storage

Finally, another approach is to use the browser’s Session Storage to temporarily store attributes as the customer browses your store. You can then retrieve these attributes from your Custom Pixel at checkout. 

For example, you could use Session Storage to store a referrer URL here or the type of order the customer is completing (OTP vs. Subscription) _before_ checkout starts. Custom Pixels have access to Session Storage, which means they can read these attributes when the `checkout_completed` event is fired and forward them to your tracking platform.

Using Session Storage is the simplest way to add additional context to any analytics event: there is no need to set up a custom Shopify app, as all the logic can live in your theme and Custom Pixel. Additionally, in contrast to Checkout Extension, it not only allows you to include additional data that you read from Shopify’s API but also to collect behavioral data while the customer is browsing your store.


## Balancing Data Enrichment with Maintenance Effort

Web Pixels are a robust tracking solution fully integrated within Shopify’s ecosystem.

With more platforms getting on board, App Pixels are quickly becoming a straightforward and reliable solution for installing tracking pixels. In addition, Shopify enforces that the customer has opted into data collection before enabling these pixels, which is a step that is often overlooked when implementing tracking tags on a storefront.

Custom Pixels have some rough edges: their sandbox allows Shopify to enforce similar privacy constraints as for App Pixels but also creates situations where tracking tags don’t work, leaving merchants at the mercy of the tracking platform to build an App Pixel or to update their tracking script.

Finally, when neither App Pixels nor Custom Pixels provide the right data, you can consider alternatives such as Server-Side Tracking, Checkout Extensions, or Session Storage.

We work closely with business stakeholders to determine what events and data we need to track and how the data will be used. We then use that information to build a solution that will satisfy the brand’s needs while also minimizing the technical maintenance burden.

If you are migrating to Checkout Extensibility or need assistance with your existing tracking setup, [don’t hesitate to reach out!](https://nebulab.com/contact-us)

Web Pixels on Steroids: How To Enrich Your Shopify Analytics

Alberto Vena

In the complex world of e-commerce technology, Shopify stands out as a beacon for businesses eager to establish or expand their online presence. Its user-friendly interface, coupled with a vast ecosystem of apps and integrations, has made it the go-to platform for merchants. Still, the convenience offered in the off-the-shelf package is not enough for everyone.

While Shopify's app store provides many easy-to-install solutions that promise quick wins, the reality is that the more complex your business needs, the less likely you'll find an app that fits the requirements. And, as businesses grow and operations become more complex, the limitations of a simple Shopify build become more and more apparent until they bring businesses to a crossroads: either simplify operations to fit into Shopify’s boundaries, or heavily customize Shopify to play by their rules.

The former path might be acceptable and sometimes even advisable for smaller stores. Building complex Shopify customizations requires significant resources and can be a source of [technical debt](https://nebulab.com/blog/shopify-technical-debt); as such, these projects should always be justified by a clear and compelling ROI.

But for brands in the upper midmarket/enterprise segment, building more complex automations and customizations on top of Shopify often makes perfect sense: these companies have complex internal workflows, custom tooling, and nuanced policies, and their e-commerce platform must learn to adapt and play nice with the existing ecosystem.

Luckily, Shopify’s ecosystem comes with rich tooling designed to create custom apps and integrations. In this post, we'll delve into some of these tools. More specifically, we’ll cover Shopify Flow, Zapier, e-commerce iPaaS Solutions, Gadget, and Greenfield Apps, exploring their pros and cons, ideal use cases, and some examples of the customizations they enable.


## Shopify Flow

[Shopify Flow](https://help.shopify.com/manual/shopify-flow) is a tool built into Shopify that allows creating automations without leaving the platform. It's a basic yet powerful way to respond to events generated within your online store (e.g., a new order being placed) with a set of actions (e.g., sending an email to your staff).

**Pros:**

* **Seamless Integration:** It’s designed specifically for Shopify, ensuring a smooth integration with your store. It’s Included in Shopify for free; no need to pay for extra software.
* **User Friendliness:** Shopify Flow comes with a visual workflow builder that requires no coding, making it accessible to non-technical users.
* **Third-Party App Support:** Shopify apps can extend Shopify Flow by adding their own triggers and actions, which expand the possibilities of the tool. This functionality is only available to Shopify Plus merchants.

**Cons:**

* **Complexity Limitations:** While powerful, Shopify Flow does not always cater to highly intricate integration needs that require custom coding.
* **Partial Support for External API Calls:** You can create an action that performs an API request to an external service (if you’re on the Shopify, Advanced, or Plus plan), but you cannot use the data you receive in any way. Shopify has committed to solving this in 2024.
* **Partial Support for External Emails:** At the moment, it's not possible to send emails using Shopify Flow, except for emails to staff members or as part of email marketing automations. You cannot send transactional emails to your customers or anyone else.

**Ideal Use Case:** Shopify Flow is your go-to for automating operational tasks within Shopify's ecosystem, particularly if you're a Shopify Plus user and can use all of the functionality it offers. It's ideal for businesses looking to streamline processes like tagging high-value customers for exclusive offers or automating restock notifications.

**Example Customization:** Automating the tagging of VIP customers based on their spending history and automatically enrolling them in an exclusive loyalty program.

## Zapier

[Zapier](https://zapier.com/) can be a good alternative to Shopify Flow, if you find its limitations unbearable. Via the Zapier app for Shopify, you can connect Zapier to your Shopify store and pick from an extensive list of triggers and actions to build your automation.

**Pros:**

* **Wide Range of Integrations:** Zapier can connect Shopify with over 3,000 web services, facilitating many different kinds of automations.
* **No Coding Required:** Zapier’s interface is similar to Shopify Flow, but offers even more power by allowing you to build more complex, more robust automations.
* **Rapid Deployment:** You can quickly set up new integrations and automations without the time and cost associated with custom software development.

**Cons:**

* **Pricing:** Zapier’s costs can quickly escalate as you increase your usage of the platform and build more complex workflows.
* **Dependent on Third-Party Connectors:** Even though it boasts more integrations than Shopify Flow, Zapier still relies on the availability and limitations of third-party connectors.

**Ideal Use Case:** Zapier is best suited for businesses that find Shopify Flow too limiting, but still need to build automations or integrate Shopify with other platforms quickly and without custom development.

**Example Customization:** Automatically adding new Shopify orders to a Google Sheets spreadsheet for advanced reporting and analysis.


## E-Commerce iPaaS

Integration Platform as a Service (iPaaS) solutions connect your online store with a variety of other systems, such as ERP, POS, and warehouse management systems (WMS), facilitating the automation of business processes across platforms. There are plenty of iPaaS solutions that integrate with Shopify–our favorite are [Patchworks](https://www.wearepatchworks.com/), [VL OMNI](https://vlomni.com/), [High Cohesion](https://highcohesion.com/), and [Pipe17](https://pipe17.com/).

**Pros:**

* **Connector Ecosystem**: Unlike Zapier, which is a generic automation platform, e-commerce iPaaS platforms specialize in connecting e-commerce platforms like Shopify with CRM, ERP, POS, and WMS systems.
* **Data Integrity:** E-commerce iPaaS platforms were designed to ensure data consistency across platforms, reducing synchronization errors and improving operational efficiency.
* **Bespoke Support:** with most iPaaS platforms, you can typically engage their customer support or professional services team to build connectors that are not already available.

**Cons:**

* **Integration Complexity:** Setting up more sophisticated connectors and automations may require technical expertise to configure and manage.
* **Cost:** The investment required to use an iPaaS reflects its enterprise-level capabilities, making it more suitable for larger businesses with complex needs. Most platforms will charge you per connection or event (e.g., a new product being created).

**Ideal Use Case:** E-commerce iPaaS solutions are ideal for medium-to-large businesses that require robust, real-time integrations between Shopify and other enterprise systems.

**Example Customization:** Integrating Shopify with an ERP system to automate order management, inventory management, and financial reporting, streamlining operations and reducing manual errors.

## Gadget

[Gadget](https://gadget.dev/) is a powerful full-stack serverless platform that allows building and hosting custom Shopify Apps, skipping all the repetitive tasks and accelerating the development cycle of your custom app. Through Gadget, you can accomplish all the automations and integrations that are not possible with off-the-shelf apps and integrators.

**Pros:**

* **Rapid Development:** Gadget offers a rapid development environment for Shopify apps, reducing time to market and human error.
* **Scalability:** Gadget is built to handle high volumes of data and traffic, making it suitable for growing businesses.
* **Developer-Friendly:** Gadget provides advanced tools and resources tailored for developers who need to create sophisticated apps, like Shopify API version management and pre-built React frontends that are compatible with Shopify’s security policies.

**Cons:**

* **Learning Curve:** Developing with Gadget requires a significant amount of technical knowledge, making it hard to access for non-developers.
* **Cost:** Custom apps may involve higher initial development costs compared to simpler integration approaches.
* **Single Environment:** As of today, multi-environment applications (staging+production, for example) are not supported. However, Gadget claims the feature will be released soon.

**Ideal Use Case**: Gadget is a powerful choice for tech-savvy teams looking to build a private Shopify app for their brand as quickly as possible.

**Example Customization:** Creating a custom loyalty program that’s not supported by any off-the-shelf loyalty apps for Shopify.


## Greenfield Apps

When none of the tools above is capable of fulfilling our complex business requirements, we are left with one extra solution, probably the most flexible one: building a custom Shopify app completely from scratch. We call these “Greenfield Apps.”

Greenfield Apps can extend the functionality of your Shopify store in whatever way you want, as long as your desired workflow is supported by Shopify’s APIs.

**Pros:**

* **Malleability:** Greenfield apps can be designed to meet your exact business requirements, offering unparalleled flexibility.
* **Direct Integration:** You can use greenfield apps to interact with all of Shopify's APIs, enriching your online store with custom business logic, Storefront and Admin UI components, and complex automation and integration workflows.
* **Technical Scalability:** Greenfield apps can grow with your business, accommodating new features and processes as needed, without financial or technological lock-ins.

**Cons:**

* **Development Cost**: Custom development is typically more expensive and time-consuming than pre-existing solutions.
* **Maintenance Effort:** Greenfield apps require ongoing maintenance and updates to ensure compatibility with Shopify's evolving ecosystem. \

**Ideal Use Case:** When your business requires unique functionality that cannot be addressed with existing apps or tools, greenfield Shopify apps provide a solution tailored specifically to your needs.

**Example Customization:** A bespoke app that provides a UI for a marketplace’s vendors to update product prices and availability, and instantly propagates those updates across multiple warehouses within your Shopify storefront.

## Complexity Is Not Always a Bad Thing

While Shopify's app ecosystem offers a solid foundation for run-of-the-mill retailers, expanding beyond these boundaries unlocks new levels of operational efficiency, customization, and customer satisfaction.

When considering your options for customizing your e-commerce store, remember that the right choice depends on your needs, budget, and technical capabilities. Make sure that you’re factoring in all of these elements before committing to a specific solution.

Building custom features and integrations may seem daunting, and might require resources and expertise that you don’t have in-house. But at the end of the day, this growing complexity is often a testament to your brand’s growth and the need to evolve your customer experience.

If you need help launching a custom feature or integration for your Shopify store, [feel free to reach out!](https://nebulab.com/contact-us) Our engineering team would love to help you figure out the right solution.


Building Custom Shopify Automations, From Beginner to Pro

Marco Trincardi

There’s nothing more frustrating than trying to complete a puzzle, only to realize you’ve misplaced one of the pieces and there’s no way to finish the thing.

But what if you could _build_ that custom piece, designing it with all the right knobs and holes, allowing you to complete the puzzle? Imagine you could also paint it to perfectly complement the puzzle’s design. How amazing would that be?

Well, for real-world puzzles, you’re probably out of luck. But when it comes to computer systems, that’s pretty much what middleware does: just like your custom-built puzzle piece, middleware is custom software that streamlines the connection between different business applications, systems, or APIs, allowing them to communicate and collaborate effectively.

In e-commerce, middleware is usually found in enterprise applications, where companies often need to connect their proprietary systems to third-party vendors. However, middleware is not just for e-commerce giants: in specific scenarios, smaller brands can also use middleware to enhance the agility and robustness of their e-commerce setup.

In this article, we will explore the typical use cases for middleware software, the pros and cons of building your own, and how to do it correctly.


## When Does an E-Commerce Brand Need Middleware?

When you’re a large enterprise company, you typically have a dedicated IT department that handles system integration, and the responsibility for deciding when to buy or build middleware software lies with this department. In this case, you don’t need to worry about making such decisions.

But if you’re a smaller brand, you might be unsure when to think about middleware. Here are a couple of scenarios:


* You have found the perfect 3PL provider, but they don’t support your e-commerce platform out of the box.
* You want to use your existing ERP integration to generate invoices for your B2B e-commerce customers. However, the way your platform’s connector sends order data to the ERP is incorrect, and the resulting invoices are unusable.

In both cases, you could buy or build middleware software to integrate with the new system or adjust your existing integration. Just as a custom piece connects different sections of a puzzle, the middleware will bridge your different vendors together, ensuring they produce the desired results.

In general, whenever you want to insert yourself between different applications to streamline or adjust their data flow, middleware is the right solution.

With that said, adding middleware to your infrastructure is not free: let’s look at the complexity it can create and how to manage it.

## Middleware Seems Easy Until It Isn’t

Most of the time, your first middleware implementation is easy to build. You start from a well-identified business need, and the project goes almost flawlessly. Once online, you might find some edge cases that were not covered, but it’s usually pretty simple to address them. Everything’s under control, and everyone on your team is happy.

After a few weeks or months, you identify new business needs that are not satisfied by your existing system. Since the first iteration went well, you feel confident adding new functionality to the middleware–perhaps by integrating with a new external system.

As you work to reconcile the different data schemas, you feel like you’re getting pulled in too many directions: data management becomes more complicated, caching and scalability problems start popping up, and not even the people who built your middleware stack are quite sure of the data transfer flows anymore.

Back to the puzzle metaphor, the knobs and holes are the communication channels, while design and color are the data model that needs to be blended. You have already put many different knobs and colors in one giant puzzle piece, and every time you need to connect to a new part of the puzzle, you keep changing it, adding knobs and holes, and trying to blend the colors harmoniously.

What was simple and neat in the beginning has become increasingly complex over time.

It’s also interesting to note that the perception of middleware complexity does not increase linearly. Usually, it has a discontinuity point: everything seems smooth and easy, but once you reach the discontinuity, everything suddenly becomes complex and demanding. In technical literature, this condition is called _complexity creep_.

So, where does this complexity come from, and how can you manage it?

## Managing the Complexity of Middleware

Now that you understand the inevitable complexity of middleware, it’s time to look at a few ways to keep it under control. Drawing from years of experience, we've honed some practical strategies to manage and mitigate these challenges effectively.

Let's take a look!


### #1: First of All, Do You Really Need Middleware?

This might sound counterintuitive since this entire article is about middleware, but the best way to keep complexity under control is not to create it in the first place, and the most cost-effective middleware is the one that doesn’t exist.

This isn’t always possible, and middleware software is sometimes a necessary evil. However, we’ve often seen retailers reach for complex custom solutions when the stock functionality of their e-commerce platform or fulfillment provider would have worked just as well.

Before jumping into a middleware project, evaluate your vendors’ capabilities carefully–ideally, reach out to their support team and see if they can suggest any alternatives that will work out of the box.

Even when there are no alternatives, consider whether reframing your original request might lead to a much simpler solution: sometimes, the cost and effort involved in buying/building and maintaining your middleware doesn’t justify the return on that investment.

As a rule of thumb, if you can’t build a compelling business case around your middleware stack, and the only reason you’re building it is to make your life slightly easier, it’s probably better to hold off on the project until you can identify a pressing need.


### #2: Acquire a Bird’s-Eye View of Your Workflows

When you decide to build middleware, start the project by mapping the existing business processes. Don’t just focus on the process impacted by your middleware; instead, make sure to also cover upstream, downstream, and adjacent dependencies.

Sound too abstract? Let's make it more concrete with our ERP example:

1. First, describe what is happening in your internal and external software applications from when the order is made to when the invoice is sent.
2. Then, expand upstream, asking questions such as: “What are some of the promotions or discounts that could be applied to the order? How do we reflect that in the invoice?”
3. Finally, expand downstream, asking questions such as: “Does the invoice generation process only impact the ERP? How does it affect our CRM, supply chain or legacy systems?”

Back to the jigsaw puzzle metaphor, this process is like acquiring a view of the entire puzzle, and not just of the knobs and holes that surround our custom piece. Building this comprehensive understanding of your business workflows not only aids in your current middleware project but also helps you anticipate and manage future complexity.

The best part is that it doesn’t take ages to create this map: at Nebulab, we usually run a dedicated eight-hour workshop, remotely or in-person, to build the first version; we then spend a couple of hours now and then when we need to update it.

### #3: Adopt an Evolutionary Approach

Having a broad view of your business workflows doesn’t mean you have to build your entire middleware stack in one sitting. Quite the contrary!

The best approach is to build incrementally, one use case at a time, and get feedback from real-world usage. This feedback is essential to guide you in future development, refine your processes, and spark new ideas. It also makes it easier and more sustainable, reducing the chance that a middleware bug will severely impact your customer experience.

See it this way: The broader view tells you which direction to go, while the evolutionary approach tells you to put one foot before the other rather than making giant leaps. You have a complete vision of your puzzle, but you still build your custom piece one knob at a time.

## Your Middleware Is Critical Software

Once created, your middleware will become a central component of your brand’s tech stack: most likely, it handles your customer, order, or shipment data; it’s a critical piece of your customer experience, and it will negatively impact your operations in case of malfunction.

Because of this, middleware development should be considered mission-critical and treated accordingly: involve established vendors and highly skilled developers–ideally, someone with a track record of building high-traffic systems and who knows how to create resilient, high-quality software through best practices and automated testing.

In e-commerce, these competencies are rare. If you don’t have them in-house or in your partner network, [feel free to reach out!](https://nebulab.com/contact-us) We’ve supported tens of brands just like yours in designing, building, and maintaining their middleware solutions, and we know what it takes to make this journey as smooth as possible.
