Forem: James Konik

PDF Web Viewers Compared: Foxit, PDFTron, and PSPDFKit

James Konik — Wed, 27 Oct 2021 09:32:39 +0000

PDF is the goto format for high quality, printable documents and is growing in popularity. The files are used everywhere, but displaying them in the browser comes with challenges. The format is complex, and includes a broad selection of features to implement.

If you’re building software that requires PDF display, or more advanced interactions, then you need to make these features available to your users, and make them work well on multiple devices.

In this article, you’ll read about three choices for teams who want to present PDF documents on the web. You’ll learn about their features, their pricing, and their documentation. You’ll also see how they’re regarded by developers, and learn the best use cases for each of them. First though, let’s cover some basics.

What Is a PDF Viewer?

There are many viewers that can show PDFs, and many have their own SDKs, so developers can build them into their applications. Using them is as simple as adding a few lines of JavaScript to your site, and there is plenty of scope for customization.

Why Use a Third-party Viewer Over an Embedded iFrame?

You can embed PDF files directly into a page, but good luck getting results with that. Several issues might occur, such as conflicting scrollbars, misalignment and divergent cross-browser behavior. Direct embedding isn’t the best way to display PDFs in the browser.

To give your users the best experience, use a third-party viewer. These provide a better, more consistent experience. They also offer a wide range of features like signing, interaction, and collaboration.

Viewers are typically built around an SDK, enabling you to build them into your own systems and add features, as well as change the presentation to match the rest of your app.

How to Compare Viewers

Let's go through the viewers and see what they offer. I'll talk about their features, and see how easy they are to use. I'll also look at their documentation and pricing.

Foxit PDF Web Viewer

Foxit PDF Web Viewer is the web version of Foxit’s PDF viewer, which allows you to view documents consistently across different platforms, while enjoying the kind of advanced features you would expect in a desktop app.

Its demo shows off its detailed, feature-rich interface. It lets you select different areas to focus on and takes you through a brief mini-tutorial for each one, which gives you a quick overview of what it can do, and how you do it.

Foxit’s document manipulation features include highlighting, annotation, and strikeout. There are also security features like 256-bit encryption and user restrictions. It works with forms, can import and export data, and lets you sign documents.

It also has collaboration features, allowing users to work together on the same document.

It’s a pure JavaScript library, so it is easy to add to your applications. Its powerful SDK includes a viewer and interface—which can be deployed quickly—and it all runs on the frontend.

Deploying Foxit is straightforward. On the website is a 21-line JavaScript snippet for you to paste into your code and you only need to update the license to get up and running.

Foxit’s documentation includes a large selection of developer guides alongside a comprehensive API reference, containing details of its many modules and classes.

The developer guides walk you through many different tasks, with code samples and diagrams. They cover each major platform, including the web. The full API reference is also there if you want specific information quickly.

There are also articles, case studies and white papers to help you understand how to integrate its products into your business.

With its prices starting at $3000 per platform per year, the Foxit SDK is cheaper than PDFTron for single platform deployment, though you’ll need to discuss pricing with the viewer’s sales team for an accurate quote.

It offers a 30-day free trial, so you can test it out before making a decision.

Foxit has a vast selection of customers, including several major technology companies.

It has a reputation for good value, and has more features than the common Adobe reader. Its strong security is also a big asset.

Loomion used Foxit successfully to let customers view documents in meetings, and Omega chose it due to its superior interaction capabilities.

Developers also cited that Foxit received good feedback from customers and saves them time.

Foxit is strong on price and excels at presenting information to customers due to its customizability. It is also fast, with tests showing it outperforms another competitor 86% of the time.

Its developer guides can also help you get started with it quickly, useful if you’re using it via its free trial.
Its speed makes it ideal for resource-heavy environments, limited bandwidth scenarios, or if you’re deploying to older devices. Foxit’s feature set makes the viewer ideal if you need document signing, collaboration, or interaction.

PDFTron

PDFTron’s web viewer is another JavaScript driven offering, letting you work with PDFs on browsers and mobile devices.

Its interface is clear and intuitive, with buttons that convey their function well. The document in its demo certainly loads fast, but doesn’t render at fantastic quality.

The viewer includes annotation, encryption, watermarks, and signing. PDFTron also features ICC color management and color separation. It supports a wide range of document formats and also allows users to collaborate on files.

You can also copy the canvas directly to an image in a few lines of code, letting you convert PDFs to images easily.

In addition to JavaScript, PDFTron uses WebAssembly, PNaCI, and compiled C++ for extra performance.

Aside from the web viewer, the PDFTron SDK is considered stronger on mobile than its competitors, making it a good choice if you’re building a multi-platform application.

It reviews well, though memory management in Linux is a minor weakness.

Its API documentation is clear, and straightforward and has been highly praised by developers.

There is GitHub starter code for several frameworks, including React, Vue, and Angular. There are also several full app examples. It’s always good to see some working code when getting started with a new technology, so that will really help newcomers see how to use it.

PDFTron doesn’t provide clear pricing data. You need to contact its sales team to discuss your requirements and get a quote. Research suggests a baseline of $4000 per year. That’s more than Foxit, though it may vary depending on your use case.

Its ease of use can help you get quick results, with clients like Recover Health getting applications running in just 24 days.

PDFTron’s developers proactively react to issues and can help with any issues you have, too.

Its prebuilt samples are useful for those working with various frameworks, making the viewer ideal if you want to get an application out of the door fast. Its integrations also make it ideal for use with the platforms it supports.

PSPDFKit

PSPDFKit is another JavaScript library-based product, with a core viewer and several other components for different features. It can be deployed in standalone form via WebAssembly, or on a server using Docker, which allows you to pre-render documents for better performance.

Its demo cleverly uses a tutorial as the sample document, teaching you the basics of the interface and inviting you to try out its annotation tools.

With annotation, editing, redaction, and form filling, PSPDFKit covers many bases. It has a reader view to simplify document layouts for mobile devices. It also has digital and electronic signing. Document collaboration and commenting are available for team-based work.

The viewer’s document indexing makes it easy to search through multiple documents, which is useful for research based projects.

Its optical character recognition lets you convert inaccessible scanned or vector content into text you can work with directly.

You can generate PDFs from HTML, and design forms. It also has comparison features.

You can start using it with just ten lines of JavaScript, making it very quick to get going. Its website includes example projects using React, Node.js, webpack, and Ruby on Rails, and there are integrations for npm and Yarn.

Its well written API documentation contains technical data, as well as a few lines about what each element does, which developers will appreciate.

It claims to have simple and flexible pricing, though there are no figures provided on the site and, again, you’ll have to contact its sales department for a quote. Sales aren’t always quick to respond, with several developers complaining about its system on Twitter. One person described it, along with PSPDFKit, as a bit of a farce.

Be prepared to negotiate. On the plus side, there’s a 60-day free trial if you want to test it out while waiting for its sales team to get back to you.

It doesn’t seem as widely discussed as the other products here, with differing reviews ranging in opinion. The general consensus is that ease of use is a strength and custom functionality a weakness.

PSPDFKit has some strong features for mobile users, such as pre-rendering from a server and simplified document layouts.

If your users need to work with scanned documents, it’s a great choice, too. It’s also ideal for those wanting to create PDFs from their image files, or create forms. Its strong indexing and conversion features make it a good choice for academics or anyone working with many documents, particularly if they need updating to make them more accessible.

Conclusion

There’s no shortage of choices when adding PDF support to your web applications. These three tools have many common features, and their individual strengths make them suitable for particular use cases.

They all have different features that you can implement easily and make available to your users. When deciding on one, you’ll want to check off your technical requirements and consider performance as well as ease of use.

Price is also a factor. Keeping costs down never hurt anyone. You should also think about support, particularly if your product is on the bleeding edge of technology and dependent on newer features.

Foxit has a broad feature set with straightforward pricing, and appears cheaper than its competitors. Its security features make it ideal if working with sensitive data or strict compliance requirements.

PDFTron is quick to get up and running and is strong on mobile, making it good for prototyping, or supporting multiple devices.

PSPDFKit is great if you want a fast, server-based approach. It also shines if you want its indexing features or optical character recognition.

Whichever you choose, it’s worth investigating everything the various viewers offer to make sure you’re getting the most value. Every feature you take advantage of brings your app one step closer to success.

Disclaimer: This article was commissioned and paid for by Foxit

Making E-Commerce More Accessible: 6 Tips for Developers

James Konik — Tue, 07 Sep 2021 13:26:29 +0000

Ignoring accessibility is a way to drive customers away from your e-commerce site. While it’s easy for developers to focus on new features and bug fixing, putting effort into inclusive, accessible sites will have huge benefits.

Accessibility impairment is more common than you might think. According to Shopify data, 2.3 percent of people live with a reading disorder, 8 percent of men have a form of color blindness, and 7 percent of people live with a severe dexterity disability.

In this article, I’ll highlight six areas where developers can make e-commerce sites more accessible.

Current Accessibility Standards

Accessibility standards exist to outline what to work toward clearly. The Web Content Accessibility Guidelines is a great resource for web content accessibility. It provides a single, shared global standard to meet the needs of individuals, organizations, and governments.

In some cases, accessibility standards are legally required. Applicable rules depend on your location, the products you sell, and the size of your business.

How to Implement Accessibility

If you’re just beginning to implement accessibility, a11y-101 is a great starting point. After implementation, ensure the product works well on screen readers and can be used via keyboard navigation. User testing, although pricier, is also an effective option.

Automatic audit tools, like the a11y command line tool, identify issues quickly and easily. The HTML_CodeSniffer is useful when testing for specific compliance guidelines.

See the result of using the a11y command-line tool on fabric’s site. Installing took thirty seconds, and running the tool is even quicker. Tools like this can significantly improve your accessibility without sacrificing time.

Let’s take a look at six specific tips for addressing problem areas to improve the accessibility of your e-commerce channels.

1. Improve Product Carousels

A carousel is a visually appealing way to show off products. This love, however, is not universal. They have several accessibility problems. First, their controls are unclear, particularly for the visually or cognitively impaired. Second, a screen reader may not associate controls with the required action. A control system that is obvious to a designer may not be intuitive to users.

Carousels that autoplay are an issue for those who use a keyboard to select screen elements. Users may not reach the control they want in time. Those who need more time to read are also frustrated when content changes automatically. Furthermore, the element chosen may also revert to the first available one when the carousel updates, making the whole site difficult to use.

If your client insists on using a carousel, you can still take steps to improve its accessibility. For example, see this sample code from the W3C Web Accessibility Initiative (WAI) under this license. It features readable text, optimizes for keyboard focus, and communicates changes to all users.

Although carousels are not ideal, you can still improve your site’s accessibility with them. In the below snippet, a live region is being created and then used later in the code. Doing so announces to users with visual impairments changes to the highlighted item.


    // In the init function, we add a live region to announce the slide number when using the previous/next buttons

function init(set) {

    //…… other code here

    var liveregion = document.createElement('div');
    liveregion.setAttribute('aria-live', 'polite');
    liveregion.setAttribute('aria-atomic', 'true');
    liveregion.setAttribute('class', 'liveregion visuallyhidden');
    carousel.appendChild(liveregion);

    //…… further code
}

// later in the setSlides function, we decide what happens when the slide is updated

function setSlides( args ) {

    //…… other code here

    if (announceItem) {
      carousel.querySelector('.liveregion').textContent = 'Item ' + (new_current + 1) + ' of ' + slides.length;
    }

    //…… further code

}

2. Make Visual Elements Accessible

Using only visual elements to present your product information excludes potential customers who cannot see them. Making information available to everyone is critical for accessibility. For images, that means including an alt tag, as seen in the following code:


<img src="coffee-maker.png" alt="blue coffee maker with glass mug and simple control panel" width="300" height="200" />

Video presents challenges to many users. But, with the right tweaks., you can make them available to everyone. Here are some changes to consider:

Captions: Captions make videos easier to follow, especially for the hard of hearing. Open captions are included in the actual video, while closed captions use a separate text file for screen readers and the visually impaired.
Transcripts: Providing a video’s full text as a separate transcript is an excellent way to increase accessibility. Transcripts also benefit those who prefer skimming through text, as opposed to a strictly visual format. Some media players, such as Able Player, automatically generate transcripts from closed captions.
Audio descriptions: Spoken audio describing a video helps visually impaired users understand what is happening. This can be presented as a separate, optional file or played alongside the video.
Accessible video players: If your frontend channels utilize a video player, make these more accessible too. Look to include supporting captions and audio descriptions, allow videos to be paused, have clear controls, and use high-contrast colors.

3. Replace or Improve Captchas

Captchas are designed to prevent bots and AI from accessing websites. However, AI is pretty good at them, scoring 98.4 percent on distorted text problems. In response, captchas are becoming harder, but this added complexity is causing difficulties for those with impairments.

Captchas are the biggest problem cited by screen reader users. Many visually impaired people cannot solve a visual captcha, leaving them unable to access the protected content. Although an audio captcha is a good alternative, they can also have accessibility problems. Furthermore, not all systems have audio available.

There are alternative ways to identify bots beyond captchas, so you can avoid using them altogether. One solution is to time how long a form on your e-commerce site takes to complete. Spambots can fill and submit forms instantly. By excluding any messages completed in under ten milliseconds, you can filter most of these bots out.

Another solution is to use server-side AI to analyze messages and filter IP addresses. For example, the honeypot involves hiding a form field so users cannot see it, but spambots still attempt to fill it in. It lets you identify spambots and filter out their responses accordingly.

See how to make a form field hidden:


<input name="name_bot_trap" type="hidden" value="">

Not all spambots will fall for this, however. Check out other techniques here and here.

Captchas don’t just stop bots; they prevent real people from using your site. Thus, replacing or improving captchas removes another barrier to user accessibility.

4. Use High-Contrast Themes

For users with visual impairments, some visual elements don’t stand out, affecting the UI. One way to improve accessibility for color-blind users is to use contrasting colors. For instance, selecting colors on opposite sides of the color wheel contrasts nicely for everyone.

Some users also find excess brightness difficult to look at and prefer darker themes. Thus, some sites allow users to enable Dark Mode. You can offer this with CSS and JavaScript. Browser extensions, like Dark Reader, offer solutions. This extended tutorial explains writing a theme switcher in React.

There are several types of color blindness, and a color scheme that works for one user may not work for another. Thus, you can also conduct testing with color-blind users. Alternatively, you can take a screenshot of your site and test it in a color blindness simulator to see how your site looks and identify any issues to fix.

5. Provide Input Assistance

Form inputs need to be clear and understandable. They should alert users to any errors but also offer solutions. For example, making a field “required” is impairs accessibility. Using an asterisk to indicate a required field confuses screen reader users, who just read out “asterisk.” If you mark a field as required in HTML, screen readers will pick up on it but still read out the asterisk.

Adding the text “required” is a good compromise. You can use the <aria-hidden> tag to mask the asterisk. This displays the asterisk while making sure readers ignore it:


<label for="input_four">First Name <i aria-hidden="true">*</i><i class="visible-hidden">required</i></label>
<input id="input_four">

The visible-hidden is a CSS class to hide the “required” text from visual rendering. See a11y-101’s approach to hiding text:


.visible-hidden {
    clip: rect(1px, 1px, 1px, 1px);
    height: 1px;
    overflow: hidden;
    position: absolute;
    white-space: nowrap;
    width: 1px;
}

.visible-hidden:focus {
    clip: auto;
    height: auto;
    overflow: auto;
    position: absolute;
    width: auto;
}

Although that’s a good start, older readers may not support the <aria-hidden> tag.

Another aspect to consider is where to place an indication of “errors” on forms. Readers should be able to find it. For example, a small line of text at the top or bottom of your form can easily be cut off from the user’s screen. Providing text that explains how to fix specific errors automatically read by screen readers is ideal. Like carousels, you should aim to prevent screen updates resetting keyboard navigation.

By handling errors sensibly, you ensure users will continue to use your e-commerce site.

6. Keep Customers On-Site

Affiliate links can confuse users by taking them away from your site to a different one. For instance, driving users to a commercially driven, flashy site can be stressful.
To improve accessibility, ensure it’s clear where links lead.

Those using screen readers navigate using the tab key to move around the page. They must tab through affiliate links, making this process slow. Allowing users to skip links helps speed up the process.

fabric’s Experience Manager lets you build a headless CMS that keeps data and backend services separate from the presentation layer. This allows you to deliver a consistent, accessible experience across multiple channels, ensuring users don’t get confused as they move between channels.

Key Takeaways

In an increasingly diverse, complex e-commerce landscape, it’s more important than ever to consider the differing needs of your users. This is particularly true for the millions of users who have difficulties with site usability. Therefore, improving your site’s accessibility is essential.

fabric can help build an e-commerce site to meet user accessibility needs and deliver a great experience for everyone.

Scaling Multi-Channel E-Commerce with Microservices and a Headless CMS

James Konik — Fri, 30 Jul 2021 20:43:56 +0000

Having a multi-channel e-commerce solution helps you reach new customers by giving you distribution on a variety of channels. Brands and retailers can now sell through traditional catalogs and POS, online stores, third-party sellers, and even social media.

From a technical perspective, supporting a multi-channel e-commerce workflow isn’t easy. Doing it well demands you take the right technical approach and design an architecture that can handle rapid change without limiting your potential for growth.

Microservices, APIs, and a headless CMS can form the basis for solving this problem. In this guide, I’ll explain the benefits of using this kind of architecture, and I’ll share some examples of how such a system works in practice, with workflows and code samples.

What is Multi-Channel E-Commerce?

Multi-channel e-commerce is selling your products in more than one place online. We usually think of online stores when considering e-commerce, but there are plenty of other ways to reach customers.

Apps, social media, and marketplaces such as Amazon that allow third-party sellers are all good places to sell goods online. Tablets in physical locations, such as stores or trade events, are also popular.

Selling in multiple channels brings new challenges. Your backend infrastructure needs to support everything it’s connected to, and your developers need to be ready to handle the extra work of building and supporting these channels.

What is a Headless CMS?

A headless CMS is a content management system that keeps the backend independent from frontend delivery channels.

The backend makes its services available to these channels via APIs. These all use the same underlying data, so things like product or customer information can stay the same across all of them.

For example, if you have a product available on both Amazon and Google Shopping, your headless API can route its pricing data from a common source like a PIM, meaning the price, product descriptions, and images are identical on both channels.

What are Microservices?

Microservices are encapsulated services that each have their own interface. They can be updated and modified without affecting other services. If the interface stays consistent, internal changes shouldn’t affect other components.

For example, if you want to upgrade the security on your orders, that’s easier if your orders are handled by a set of microservices. If you were tied into a monolith, such as Oracle ATG, you’d have to upgrade the whole platform.

With microservices, each individual service can be deployed and scaled on its own container. With AWS, for example, you pay for what you use, and if one service is suddenly in demand, Amazon’s cloud can manage the upsurge without problems and without affecting the rest of your backend.

That’s useful if some part of your infrastructure sees a spike in traffic. Perhaps you have a holiday product that gets mentioned in an article. A lot of people will look at your catalog. A few days later (hopefully), a lot of them will come back and buy the product. Amazon can let you ride the wave of traffic to your catalog and then handle the increased demand on your ordering system.

Building vs. Buying

Once you understand the requirements of multi-channel e-commerce, it becomes clear that you need some sort of headless, API-driven solution, and microservices offer clear benefits when it comes to scaling and modifying features.

The hard question is whether you should build these services yourself or use a third-party solution.

Building multi-channel e-commerce microservices

Here’s an example of how data might flow through a microservices-based setup, with an API gateway receiving calls and a service mesh routing calls from your checkout service to the packing and accounts services.

To set up an architecture like this, you first need to decide what services you want it to provide and how they will connect. Once the essentials are in place, you can build from there. Let’s look at a couple of the key components you’ll need.

Order management system (OMS)

An order management system deals with taking orders and handling different payment methods, as well as updating inventory, invoicing, and passing information to your delivery and accounting teams.

When an order is placed, data flows from a frontend application to your backend infrastructure, which is responsible for distributing it among the other services that need it. Your product database will be updated, as will your accounts, and the warehouse will need to know what to deliver.

As orders involve the interaction of multiple services, they are a good test of your architecture, as well as being essential to get right.

Product information manager (PIM)

Storing product information is a key component of any e-commerce business with large and growing volumes of data to manage. The fields and relationships between them may evolve as new sales channels provide new ways to present them.

The PIM provides information on products to your customers and allows for manual updates by staff, as well as automatic updates via other services, such as inventory.

With a headless architecture, you can keep all this in one place so that updates will be reflected everywhere. You can add fields and redefine existing ones as required, and also expand your range of services to support new kinds of queries.

API gateway and service mesh

Another key component to this architecture is your API gateway. It routes API calls to the correct services from the various frontend channels. You can change the routing, which allows you to easily switch between different services or versions of them.

For example, you could swap in a newer version of a service for testing or swap it out if you need to roll back to an earlier version. You can also route services from existing monoliths to newer microservices during a migration.

A service mesh acts as an intermediary between your services and controls the data flow between them. A service mesh can handle logging, load balancing, and encryption.

It can also enforce call limits on your services and provide a layer of security, letting you choose what data services are allowed to send to others. You may want to track which of your channels are calling particular services to help you identify issues or usage spikes.

Other services

Aside from the core services and gateway layers, there are many other supporting services that make up a headless, e-commerce microservice platform.

A personalization service can bring together the information you collect across all your channels and use it to customize the user experience on each one. A promotions and loyalty service can apply discounts to all your channels or specific ones. You could allow users to collect points or earn rewards from social media shares and then spend them on your web store, for example.

Example: Processing Orders from Multiple Channels

Let’s look at an example of how a microservice might deal with a call to its API. I’ll describe a workflow for processing orders using a prebuilt API, but if you build your own, it should be similar.

When the customer has selected their items and verified their order details, the order is sent via the checkout service as a post request to the checkout endpoint.

All channels can send the same request, regardless of their platform or UI. We can add or remove new channels without changing the backend, provided they send requests in the same format.

The post request is sent to:

POST /api-order/checkout

To send it in JQuery (assuming you have a web frontend), you can do something similar to this:


$.ajax({
    type: "POST",
    contentType: "application/json",
    url: "/api-order-checkout",
    data: JSON.stringify(data),
    dataType: 'json',
    success: function (data) { //using data formatted as in the section below
        //let the user know it has completed successfully
    },
    error: function (e) {
        //let the user know it has gone wrong
    }
});

The request is formatted like this:


{
    "cartId": "5f1b4158bb24210008b9a3f0",
    "customerEmail": "test@fabric.inc",
    "customerPhoneNumber": {
        "number": "07780811973",
        "kind": "Mobile"
    },
    "paymentDetails": [
        {
            "transactionDetails": {
                "paymentType": "CARD",
                "cardNumber": "4111111111111111",
                "expDate": "1122",
                "cvv": "999",
                "cardHolderFullName": "Joe Demo",
                "metadata": {}
            },
            "paymentIdentifier": {
                "cardIdentifier": "1111"
            },
            "paymentMethod": "Visa",
            "paymentKind": "Fabric User",
            "amount": "11.27",
            "currency": "USD",
            "conversion": 1,
            "billToAddress": {
                "name": {
                    "first": "Joe",
                    "last": "Demo"
                },
                "email": "demo@fabric.inc",
                "phone": {
                    "number": "07780811973",
                    "kind": "Mobile"
                },
                "street1": "600 CONGRESS AVE",
                "street2": "",
                "city": "AUSTIN",
                "state": "TX",
                "country": "US",
                "zipCode": "1003"
            }
        }
    ],
    "estimatedTax": {
        "itemsTaxes": [
            {
                "lineItemId": 1,
                "amount": 2
            },
            {
                "lineItemId": 2,
                "amount": 2
            }
        ],
        "shipToTaxes": [
            {
                "shipToId": "5f1b41892e8f1c0008fc20e8",
                "amount": 1.5
            }
        ]
    },
    "shipFrom": {
        "street1": "888 Broadway",
        "street2": "",
        "city": "New York",
        "state": "NY",
        "country": "USA",
        "zipCode": "46282"
    }
}

The API gateway will route this data to the relevant service. If the request is received and processed correctly, the backend will send a response formatted as follows:


{
"checkoutComplete": true,
"orderId": "4679-1016-66250"
}

So the frontend can present a confirmation message to the user, and of course, this will vary depending on the sales channel you’re using.

The backend can send further requests to other services, as determined by you and managed by your service mesh. As shown in the application diagram above, these could include calls to the shipping or promotions services, but the options are endless. To users, the interface is simple, while the backend implementation can be as complex as it needs to be.

Key Takeaways

Headless, microservices-based architectures have several advantages. Their modular nature makes them easy to change and gives you the flexibility to evolve your systems over time. They are also scalable, allowing you to allocate resources efficiently as you grow.

Building them yourself is time-consuming and expensive, so using a prebuilt solution can give you a headstart. These building blocks can get you up and running quickly and keep you ahead of the competition. With your architecture in place, you can add features and support new services, confident that your setup can handle their requirements.

Design Patterns for Modern Day Commerce Using Microservices

James Konik — Fri, 30 Jul 2021 20:07:33 +0000

E-commerce businesses are using microservices to build a set of reusable components for their stores. These services make it easier to deliver your content to multiple channels at scale by operating independently from the frontend.

In this post, I’ll talk about several design patterns you can implement and explain what they offer. I’ll also mention common use cases.

Understanding Software Design Patterns

Software design patterns are defined ways to solve common problems. They help developers understand how the components of a system relate to each other and interact. There’s no “perfect” design pattern—each has pros and cons and is helpful in specific situations.

Most developers spend years of practice getting these patterns right. However, by applying them properly, you can achieve results. There are five design patterns for modern e-commerce architectures:

The strangler pattern: A useful way to migrate from legacy software to a more modern approach.
The ambassador pattern: This gives you an encapsulated approach to handling network issues.
The sidecar pattern: This helps you add functionality without getting too tightly coupled to the rest of your software.
API interfaces: These help software services and components communicate.
Function chains: These help code to handle sequential tasks.

While implementation is the most difficult part, knowing the names and intentions of each pattern is an essential first step. At the end of this guide, you will have a starting point for deciding when each is right for your e-commerce platform.

The strangler pattern

Named after the strangler fig tree, the strangler pattern is moving from one platform to another gradually. You do this by replacing parts of your software one by one until eventually the old system is fully strangled. In practice, you can break it down into three steps:

Transformation: you create new versions of your services, replacing them one at a time
Co-existence: where you run the new services and older services together
Elimination: you replace everything you need and can retire the old system

Using the strangler pattern allows continuous delivery of new features and high code coverage. It also facilitates a modular, test-driven approach enabling you to isolate issues and ensure each service you deliver works well.

It’s a great way to shift to a new software setup, such as from a monolith to microservices. It lets you break the work down into manageable chunks, driving results quickly. Furthermore, you can distribute tasks to different teams to increase buy-in and accountability across your engineering organization.

On the other hand, it can take time. However, you can mitigate that by having teams work in parallel. Setting up your team right is as important as nailing the technical side of things.

The ambassador pattern

In the ambassador pattern, the ‘ambassador’ service is dedicated to communication. You create a proxy process or service that handles network requests for the rest of your application.

With an ambassador service in place, you can add features like monitoring, logging, and call rerouting. It’s useful to translate requests from one format to another—for example, multi-channel e-commerce, where you distribute products to many different frontend consumers.

If you’re using a mix of legacy and modern software, it can help bridge the gap, ensuring your network meets modern security and accountability standards. From an organizational viewpoint, it lets you assign a team to the proxy service itself, allowing you to divide responsibility.

While the ambassador pattern can quickly tie disparate systems together, it isn’t ideal if network latency is a concern. It can increase inter-service communication and higher memory and CPU usage.

If you have issues moving away from your monolith or legacy software you’re stuck maintaining, the ambassador can be a great way to circumvent those weaknesses. It allows you to add features to old software without having to rewrite everything.

The sidecar pattern

In the sidecar pattern, you move a specified set of functionality into a separate component. This component exists alongside the primary application, generally sharing the same lifecycle.

The sidecar is hosted together with its parent and can even run in the same process. That means there is little to no latency when the sidecar communicates with the parent, and it has access to the same resources.

It can, however, use a different programming language or framework than the primary service, and multiple sidecars can use different languages. That means you can use the right tool for the job when adding extra functionality or cater to the strengths and preferences of various team members.

Often the sidecar process can handle peripheral functions such as logging or network connectivity, while the main application handles core functions. Thus, if you need to move or reconfigure the application, teams can focus on the sidecar without having to change the main application.

It’s a simple pattern with many potential applications. For example, in an e-commerce setting, you could use it to log financial transactions. As detailed records are vital in e-commerce, you can have an independent one to add to and build on over time.

You can also use the sidecar pattern for handling network operations like adding modern encryption to a legacy service. This can let you partially modernize old e-commerce systems without resorting to a complete rewrite.

API interfaces

An application programming interface, or API, is a way for software components to communicate with each other using a defined set of calls. Web services or microservices commonly use APIs.

In addition to their use over networked communication, you can also use them for communication between microservices on the same host. There are several patterns commonly seen in API interfaces.

REST is the most recognizable. It’s a staple of computer science courses and standard for a vast number of websites and services. It includes a set of verbs, which implement the CRUD pattern. RESTful services are stateless and cacheable, making them ideal for the web.

In headless commerce, APIs allow multiple frontend applications to communicate with your backend services. Websites, apps, and software deployed on any other platform can send API requests to the same location. This lets you work on each component separately, making improvements and additions without worrying about the effect on the whole ecosystem.

Function Chain

You can build serverless functions on the cloud that are self-contained and stateless and can execute on demand. Services like Amazon Web Services, Microsoft Azure, and Google Cloud let you create these, so you don’t have to worry about hardware issues.

You can organize serverless functions into a function chain. In this pattern, each function invokes the next when it completes. This pattern is ideal if a user action kicks off a series of tasks that are slow to process. The first function can respond to the user, so they aren’t left waiting.

There are a few issues to consider when applying this pattern. Ideally, functions are independent and replaceable, but here the functions are dependent on each other. This breaks object-oriented design principles, but it’s necessary for certain applications. You can use a queuing system to call the functions in sequence, making them more independently operable and scalable.

Function chains are useful to implement sequential tasks that are well defined. For example, you may want to call a function chain after a user places an order to process data through different microservices and push it into each subsequent data store.

These tasks can each happen independently and in the background. This way, your e-commerce store’s UI stays snappy while the backend functions might take minutes to complete.

Key Takeaway

The more you know about software patterns and how to apply them to e-commerce microservices, the better you can leverage this existing knowledge to solve problems.

Using the Strangler Pattern to Break Down Your E-Commerce Monolith

James Konik — Wed, 30 Jun 2021 19:24:10 +0000

Monolithic platforms like Shopify, Oracle ATG, and BigCommerce are easy to get up and running. However, they lock you into various platform-specific limitations. As a result, you're subject to each platform’s constraints and may feel stuck using one-size-fits-all software.

You face similar challenges if you’ve built your own e-commerce monolith. When more components of the application are intertwined, it is harder to modify features, scale components, or divide the work. After years of using one of these systems, technical debt builds up and changes are hard to implement.

Microservices solve such problems. You can modularize your e-commerce business. Adapting quickly to the wealth of new opportunities to engage with your customers is a competitive advantage. That's why modern tech companies like Netflix, Amazon, and Etsy have all switched to microservices.

Migrating from monolith to microservices provides many technical and business challenges. One approach that helps to replace your monolith is the strangler pattern. It does so one service at a time.

In this post, you’ll learn how to use the strangler pattern to break down each piece of your e-commerce monolith until you’ve replaced it with discrete, scalable microservices.

Why Microservices?

Microservices have several advantages over a monolithic approach:

Technical flexibility

One-size-fits-all platforms are fast and convenient when you get started, but as your business develops, issues start to arise.
With microservices, you are free to implement the programming languages and third-party services that are best for each piece of your application. Because they’re scalable and modular, your decisions don’t tie you down.

Flexibility

Microservices are independent and decoupled from your frontend. That means you can easily build new ways to reach your customers and wire them up to your services without having to reinvent the wheel each time.
With your own services, you can ensure each service matches your needs, defining the data format, and functionality. You can also control how user access is structured. Flexibility also prevents bottlenecks as your teams are not dependent on each other.

Security

Attackers that gain access to your monolithic platform often gain access to everything - customer, product, and order data. Microservices can create silos between services, keeping them more secure.

Performance

Scalability and the ability to focus resources on your more heavily trafficked services dynamically mean you can improve performance. For example, Best Buy improved its catalog API sync time from 24 hours to under 15 minutes.

What is the Strangler Pattern?

The strangler pattern takes its name from the strangler fig tree. Like the tree, you use your existing application as a base. Then, you build a new service that replaces one specific element of it. When it’s done you retire the old part of the application.

You continue this service by service until the new microservices replace your entire monolith. You ‘strangled’ the old code and thus can abandon it completely.

There are three phases in the strangler lifecycle:

Transform the application by creating new versions of existing services.
Co-exist with the old application running alongside an ever-increasing number of microservices.
Eliminate the old when the new services completely replace the old system.

Strangler vs. waterfall approach

Besides the strangler pattern there is also the waterfall replacement pattern, the more common approach to migrating microservices. The waterfall pattern requires you to commit to a long development and deployment cycle, which increases the risk of bugs and lowers your velocity.

The waterfall method can take well over a year to deliver results, but you can make progress in bursts of six months or less by using the more agile strangler method. It naturally divides work into attainable targets, which means developers are motivated to complete tasks that deliver visible results.

With the strangler pattern, you can use each new microservice as soon as it is ready. There’s no need to build a completely new system. Some recommend rolling out changes monthly. For one, you can enjoy the advantages quickly. Secondly, it also lets your developers move on to the next project. If issues occur, they can roll pieces of the system back more easily than the whole thing.

The strangler pattern is often the better option. It allows you to migrate each piece of your infrastructure step-by-step in a manageable, low-risk way and deliver business value faster.

The downside to the strangler pattern

There are some caveats. Migrating a complete application one step takes a while. Analyzing successful projects using the strangler pattern suggests to remaining consistent and ensuring your management team commits to the long-term project.

Microservices benefit from robust development practices (like continuous integration and deployment) and having engineers that are familiar with them. Finding the right team is just as important as picking the right languages and frameworks. It’s important to make sure your developers are on board with the new processe. If they understand the advantages of the changes, buy-in will be higher.

One way to mitigate the risks of migrating to microservices is to use an established e-commerce platform like fabric. We've built fabric on microservices and can work with your team to ensure a smooth migration.

Example: Using the Strangler Pattern in E-Commerce

Let’s look at how to implement the strangler pattern. I use the monolith provided billing service feature and move it to a new microservice. Then, I'll show you how to migrate important data and features without breaking your existing application.

Step 1: Decide where to start the migration

The service you choose to start with depends on your need and the platform you’re using. There are two common approaches.

Critical features that you need to upgrade: If it's impossible to update your legacy codebase or you’re facing performance issues that cost you customers (like a slow checkout experience), starting here might be best. Ensure everything is watertight before deploying. It takes more time but has more impact.
Pick something less critical, to test the process: It's a great idea if your developers are implementing microservices for the first time as it’s less risky. However, it will drive less value for the business.

Let’s look at moving an e-commerce billing address service from a monolithic platform like Oracle ATG to a microservice hosted on AWS. Billing services that are slow or prone to errors might be preventing you from collecting revenue from customers. Thus, they’re often mission-critical in online stores.

I’ll only include a couple of attributes, but you can replicate this general pattern with whatever data you need.

Step 2: Build a middle layer

An API gateway can manage service calls and filter them to either your existing monolith or new services. AWS includes a guide on how to do it. A service mesh is also useful for load balancing and routing to manage data flow between your services.

With the middle layer in place, you can switch between your new and old services seamlessly. You could also theoretically A/B test the old and new path or roll back if something goes wrong during the migration.

Step 3: Build a new service and migrate data

Next, replace the old billing portion of your application with a new microservice. Here’s some code based on this example from Amazon’s AWS documentation that uses EC2 and Docker to deploy a billing microservice.

This task definition creates a new Docker container running on AWS to replace an Oracle ATG billing address service.


{
    "containerDefinitions": [
        {
            "name": "[billing-address-service]",
            "image": "[account-id].dkr.ecr.[region].amazonaws.com/[service-name]:[tag]",
            "memoryReservation": "256",
            "cpu": "256",
            "essential": true,
            "portMappings": [
                {
                    "hostPort": "0",
                    "containerPort": "3000",
                    "protocol": "tcp"
                }
            ]
        }
    ],
    "volumes": [],
    "networkMode": "bridge",
    "placementConstraints": [],
    "family": "[billing-address-service]"
}

You’ll need to transfer data from your existing monolith’s database to your new microservice’s backend database in most cases.

For example, the Oracle ATG billing address service described above uses profile data. You can copy this from your Oracle application’s backend to AWS, as demonstrated below.

This sample code uses Amazon SQS to queue up a series of data transfer jobs. This is critical if you have lots of data to move. Because the process may take a long time, you don’t want a single failed transfer to break the whole process.


const { SQSClient, SendMessageCommand } = require("@aws-sdk/client-sqs");

const REGION = "us-west-1"; //replace with your region

const params = {

DelaySeconds: 12,
  MessageAttributes: { // add other fields if you need them, remove what you don’t.
    profileId: {
      DataType: "Number",
      StringValue: "543",
    },
    address: {
      DataType: "String",
      StringValue: "29 Acacia Road, Springfield",
    },
  },
  MessageBody:
    "Clothing Store Product Data.",

  QueueUrl: "SQS_QUEUE_URL", // your queue URL

}

const sqs = new SQSClient({ region: REGION});

const run = async () => {
  try {
    const data = await sqs.send(new SendMessageCommand(params));
    console.log("Success, product sent. MessageID:", data.MessageId);
  } catch (err) {
    console.log("Error", err);
  }
};
run();

Once you’ve queued up each row, you need a service to receive and process the data. It will add each row to your new database and delete messages from the queue as they are successfully processed.

import  { SQSClient } from "@aws-sdk/client-sqs";

const REGION = "us-west-1"; //replace with your region

const sqsClient = new SQSClient({ region: REGION });
export  { sqsClient };

import {
  ReceiveMessageCommand,
  DeleteMessageCommand,
} from  "@aws-sdk/client-sqs";
import { sqsClient } from  "./libs/sqsClient.js";

// Set the parameters
const queueURL = "SQS_QUEUE_URL"; //Your queue URL

const params = {
  AttributeNames: ["SentTimestamp"],
  MaxNumberOfMessages: 10,
  MessageAttributeNames: ["All"],
  QueueUrl: queueURL,
  VisibilityTimeout: 20,
  WaitTimeSeconds: 0,
};

const run = async () => {
  try {
    const data = await sqsClient.send(new ReceiveMessageCommand(params));
    if (data.Messages) {
      var deleteParams = {
        QueueUrl: queueURL,
        ReceiptHandle: data.Messages[0].ReceiptHandle,
      };
      try {
        // TODO: Save your data here
        database.save(data);
        // Then delete the queued message
        const data = await sqsClient.send(new DeleteMessageCommand(deleteParams));
        console.log("Message deleted", data);
      } catch (err) {
        console.log("Error", err);
      }
    } else {
      console.log("No messages to delete");
    }
    return data; // For unit tests.
  } catch (err) {
    console.log("Receive Error", err);
  }
};
run();

Once your data is transferred into the new microservice, and you’ve verified it is correct, you can begin testing the new service. If everything works correctly, you can retire part of your monolith and repeat the process with each part of your application.

Obviously, this migration process varies widely depending on the monolithic e-commerce platform you’re using. Still, hopefully, this gives you a sense of how you can apply the strangler pattern in your application.

Conclusion

The strangler pattern can help move away from your legacy software platform in a structured, low-risk way. It helps make meaningful improvements quickly without breaking your existing e-commerce store.

You can thus roll out new features and turn your platform into scalable, robust services that form the core of your e-commerce business. The decoupled nature of microservices lets you use them across multiple channels.

If you’d like to avoid doing a complete migration yourself, fabric can help. With industry-leading expertise in e-commerce microservices, they can help you migrate to their suite of e-commerce microservices using a secure, scalable method like the strangler pattern.

Moving from BigCommerce to Microservices-Based E-Commerce

James Konik — Fri, 25 Jun 2021 01:53:34 +0000

BigCommerce includes many features and services, but if you want to take every opportunity to engage with your customers, you need a solution of which you’re in complete control.

There’s no better way to do that than replacing it with microservices. After all, this is the approach Amazon took to scale and become so successful. You can move one step at a time, adding reusable core components that act as a foundation for multiple frontend sales channels.

In this post, we’ll discuss replacing BigCommerce with a microservices-based alternative, looking at the reasons for making the change. Then we'll discuss the specifics, along with a few examples of what to do code-wise.

Note: We've written before about migrating away from classic e-commerce monoliths like Salesforce Demandware. As you'll see, many of the same concepts and migration practices apply to modern monoliths like Shopify Plus.

Why Microservices?

Microservices have several advantages over a pre-built, one-size-fits-all solution.

Security

Microservices are modular and interchangeable by design. That means your developers can work on them without affecting other parts of your system. It also means you can quickly make and test changes and slot in older or alternate versions of your code.
Being able to respond fast and hone in on potential problem areas are key advantages of microservices. By contrast, a large platform may take time to fix holes, and the process of upgrading might be out of your control.

Flexibility

BigCommerce offers you several templates and has plenty of features, but you are also at the mercy of any changes it makes.
With your own microservices, you can update them when you like. You can choose the fields and data format to work with and decide how your services connect and share information.
You can make every decision related to your business yourself. That may seem daunting, but specialists can help, even if you’re using your own solution.

Costs

While BigCommerce is extendable, many of the upgrades aren’t cheap. Even one can significantly add to your costs, and the more you have, the bigger the hit.
Estimates suggest ongoing costs for microservices can drop by up to 90%, and that’s before you factor in the productivity gains for your developers.

Replacing BigCommerce

BigCommerce’s headless architecture is ideal when shifting to microservices as you can pick and choose what you replace relatively quickly. Furthermore, by taking a modular approach and focusing on one service at a time, you can gradually transition.

Moving one service at a time makes it easy to identify any issues and roll back any mistakes. If you have trouble with any of your new services, just swap the old one back in, then test and improve the new one until it does what you expect.

Step 1: Decide where to start with the migration

There isn’t a fixed approach to migrating from one platform to another, and you might take several valid routes. Let’s look at some of BigCommerce’s services and decide what to implement using microservices.

Product information management (PIM)

Product Information Management is one of the most important tasks in e-commerce, and being able to update and access this data is crucial. BigCommerce has several apps available to help with it.

With microservices, though, you can customize everything from storing the data you need in the format of your choice to making it available to every channel you use. So you aren’t limited to finding the closest fit from a range of options.

fabric’s PIM system gives you a ready-made solution, allowing you to make changes using an intuitive UI and supporting features like multiple product hierarchies, auditing, and one-click migration.

Order management system (OMS)

Your order management system needs to handle payments, store the user’s order, and make sure it gets dealt with. In addition, logistical issues, like stock management, need it to run flawlessly.

BigCommerce has its own OMS with a defined workflow and several extensions available in its marketplace.

Your own OMS will be a crucial component of your business. It will take time to build and to get everything right. But a customized system built to your specifications can make the rest of your business run smoothly and efficiently.

fabric has its own OMS, and using this as a starting point for your system can save you a lot of time and ensure you nail the basics.

Other supporting services

PIM and OMS are essential to nearly all e-commerce businesses. The other services you pick will depend on which of BigCommerce’s capabilities you currently use and want to improve or replace.

BigCommerce offers many features out of the box. You might want to replicate its customer review system or perhaps control user access for your staff.

If you want to take things slowly, starting with a small, non-essential service can be a great way to get going.

Step 2: Build a middle layer

As you switch from BigCommerce to your new microservices, you need to make sure the system sends requests to the right place. You can do this with an API Gateway. Setting one up lets you choose which services deal with requests, so you can pick and choose what your new services handle.

Swap out legacy services

Once the middle layer is in place, you can retire old services and add your new ones. You can also swap things back and forth between new and existing services for testing or even filter requests so that some are dealt with by BigCommerce, and some go to your new setup.

Step 3: Migrate data from BigCommerce to microservices

When switching over, you’ll need to get your data out of BigCommerce and into your new backend database. It’s easy to export data from BigCommerce: you can generate a CSV file that contains everything, or you can pick and choose the fields to export.

As well as getting the fields out, you need to decide on your new data structure. Will you use identical field names for the fields you want, or will you change them? You may want to allow for additional fields too.

If you want to extract data from BigCommerce dynamically, you can do that via its APIs. The latest version of its REST API is three, faster and more efficient, though it doesn’t yet include everything in the older version two.

There’s also a GraphQL API, though this is still in early access and feature-incomplete. Being able to build your own full-featured API in any language is one advantage of microservices.

Let’s look at the data format for shopping cart items:

Field Name	Data Type
id	string
customerId	integer
email	string
currency	object
isTaxIncluded	boolean
baseAmount	number
discountAmount	number
cartAmount	number
coupons	array[object]
discounts	array[object]
lineItems	object
createdTime	string
updatedTime	string
locale	string

Here’s the JavaScript for adding this code to a message queue, adapted from the AWS documentation. You can also find code there to receive the data, which doesn’t need much adaptation.

I’ve picked out a few attributes from the list above. You can add more, using the same format, or remove any you don’t want.


// Imports for AWS
const { SQSClient, SendMessageCommand } = require("@aws-sdk/client-sqs");

// Set this to your region
const REGION = "us-east-1"; 

// The parameters, swap in what you need, and out what you don’t
const params = {
  DelaySeconds: 10,
  MessageAttributes: {
    id: {
      DataType: "String",
      StringValue: "475",
    },
    customerId: {
      DataType: "String",
      StringValue: "562567",
    },
    baseAmount: {
      DataType: "Number",
      StringValue: "79.99",
    },
discountAmount: {
      DataType: "Number",
      StringValue: "59.99",
    },
  },
  MessageBody:
    "Shopping cart information.",
  QueueUrl: "SQS_QUEUE_URL", // Your queue URL, e.g. 'https://sqs.REGION.amazonaws.com/ACCOUNT-ID/QUEUE-NAME'
};

const sqs = new SQSClient({ region: REGION });

const run = async () => {
  try {
    const data = await sqs.send(new SendMessageCommand(params));
    console.log("Success, message sent. MessageID:", data.MessageId);
  } catch (err) {
    console.log("Error", err);
  }
};
run();

Step 4: Test and repeat

As you replace each service, you should test thoroughly, making sure everything works correctly. That makes it easier to fix issues, as you can be reasonably sure that they relate to your recent changes.

Once everything is working, move onto the next service and repeat the process. This iterative, step-by-step approach lets you stay focused and get the right balance between working on new services and putting them through their paces in the real world.

Conclusion

Developing a new system yourself allows you to tune everything to your liking. It also lets your developers build the system the way they want and learn how it works as they put it together.

Taking advantage of existing solutions like BigCommerce also has benefits. It’s cheaper, quicker and many have tested the solution.

fabric specializes in microservices, and its solutions can help you make the switch easily. Its products are API-driven, allowing you to extend fabric core features easily and grow your services as your business expands.

Moving from Shopify Plus to Microservices-Based Commerce

James Konik — Thu, 13 May 2021 22:01:27 +0000

If you’re selling products online, there’s a good chance you’re using a one-size-fits-all platform. These platforms offer many advantages but they also have limitations. If you want to move beyond these limitations, microservices can help.

Shopify Plus is a one-size-fits-all platform that allows you to use headless systems while retaining most of its features. So if you already have a Shopify Plus setup, you can keep the frontend and migrate the backend to a microservices-based alternative for more flexibility.

In this post, we'll explain why businesses are moving away from monolithic e-commerce platforms like Shopify Plus and how they are doing it from a high level.

Why Microservices?

Shopify is a fantastic system in many ways, but if you use it exclusively you have to accept its limitations. Moving all or part of your system away from it can avoid these problems. Let’s look at some of the areas microservices can improve.

Security

Shopify has been in the news regarding data theft before. Managing your services means you’re free to address those concerns and implement additional security.
Its fraud protections aren’t as comprehensive as some services, so moving to a different payment system that matches your requirements can give you and your customers peace of mind.
Working with APIs means you can control the data flow in and out of your backend. It also means you can develop it incrementally while building on what you already have. That means you don’t have to reinvent the wheel when you want to offer something new on the frontend.

Technical Limitations

One issue with Shopify Plus is its lack of multi-store architecture, though this feature has been promised in the future and some plugins may help with it. If you can’t wait, you can build a backend that can handle data across all your outlets.
Shopify Plus's SEO approach is good but hard to modify. Using a custom frontend can allow you to change the URL structure, the robots.txt file, and give you better control over your subdomains.
It’s a similar situation with Shopify’s checkout. It’s hard to customize, leaving you with a fixed approach. What’s there isn’t bad; it’s just that you can’t deviate from it significantly or add specific features easily.
Shopify Plus can also slow down as you add features; its plugins don’t have to be certified. Handling services independently means you can ensure they continue to perform at the level you require.

Flexibility

Shopify allows you to get up and running quickly, but you’re tied into the way it does things. With microservices, you can take a modular approach, get the essentials in place, and add whatever you need on top.
Shopify apps aren’t always geared to work well internationally and can cost a lot if you have multiple local versions of your store. Data for multiple stores is also tricky to combine.
Shopify payments can have restrictions for products, as well as countries and currencies. You need a local business and bank account in each territory you have a store. That makes changing and expanding difficult.
With microservices, you can add an API query doing whatever it is you need—you aren’t limited to what Shopify offers. If you need to support a new feature, you can do that.

Replacing Shopify Plus

You can take advantage of the modularity of microservices to move from Shopify bit by bit. Identify what you can benefit most from replacing and build it. If you do that repeatedly, you can move away from Shopify step by step, improving your service with minimal disruption.

Step 1: Decide Where to Start the Migration

Let’s look at some of Shopify Plus’s services and decide what to implement using microservices.

Product Information Management (PIM)

Your Shopify installation will include lots of product-specific data. Moving this to a separate backend, with an API letting you retrieve, modify, and create new products, is a great place to start.

Decoupling this data from Shopify means you can use it on any of the new channels you create. It gives you complete control over what’s shared, and the formatting and structure can be defined however you like.

Fabric has a prebuilt PIM system that will help you make the transition quickly and easily and offers you plenty of flexibility. As well as helping you get set up, Fabric can also help with data migration.

Order Management System (OMS)

Your order management system includes your user’s shopping cart as well as payments. You have to smoothly pass the data on to your payment handler and delivery setup while allowing users to track and potentially cancel the whole process. There’s a lot involved, and everything needs to run like clockwork.

Taking control of this area means you can evolve it over time and perfect everything, adding features for the various frontend services you want to use while ensuring the core functionality is rock-solid.

Fabric can help with this, too. Its OMS promises a friction-free experience that can drive customer satisfaction and make life easier for everyone involved in your order and delivery chain.

Other Supporting Services

Shopify Plus offers a whole suite of features and services. Some of these will matter to you more than others—priorities differ from business to business. When picking a feature to include, you should consider what you’d like to make available to channels other than Shopify and which areas have the most scope for improvement.

These might include store management, customer personalization, or analytics. Take a look at the features Fabric offers to see what it can do for you in those areas.

Step 2: Build a Middle Layer

To integrate your new services with your Shopify installation, you can set up an API gateway. That will let you reroute requests to your new backend.

You could also adopt a service mesh model, which handles communication between your application components and lets you manage data flow between your existing application and external microservices.

With a new layer in place, you can look at replacing services one by one, thoroughly testing at each stage, and ensuring the new process is fully integrated before moving on to the next.

Step 3: Migrate Data from Shopify Plus to Microservices

To move data from your old system, you can export it to a CSV file, then use JavaScript to shift it across to your new microservice. You can do this as you go, create a service, copy your data into it, and then adjust your API gateway to handle future requests from Shopify.

Exporting Data from Shopify Plus

Shopify Plus has a simple export system, letting you easily create a CSV file. Its documentation explains how to do this for a product, customer, and order data, among other things. You can find an example file here.

Shopify product data includes the following fields:

Required	Required but can be blank	Optional
Handle	Body	SEO Title
Title	Vendor	SEO Description
Published	Type	Google shopping metafields
Status	Tags	Cost per item
	Image Src
	Image Position
	Image Alt Text
	Gift Card

There are more fields for products that have additional options and variants. Consult the documentation for details.

Your new system won’t have to use the same fields, so you can pick and choose which are relevant to you and which, if any, are required in your system. That kind of flexibility is one of the advantages of working with microservices. You can have a compact, faster system or one that contains whatever extra information you need.

Importing Data into Microservices

You can use JavaScript to transfer your data into your new system. Here’s an example showing how to import data using the latest version of Amazon SQS. You can find more details in Amazon’s documentation.


const { SQSClient, SendMessageCommand } = require("@aws-sdk/client-sqs");

const REGION = "us-east-1"; //or whatever your region is

const params = {

DelaySeconds: 10,
  MessageAttributes: {
    Title: {
    DataType: "String",
    StringValue: "Sneakers",
    },
    Vendor: {
    DataType: "String",
    StringValue: "Comfy Sneakers Inc",
    },
    InventoryQty: {
    DataType: "Number",
    StringValue: "146",
    },
    Value: {
    DataType: "Number",
    StringValue: "79.99",
    },
  },
  MessageBody:
    "Product Data.",

  QueueUrl: "SQS_QUEUE_URL", //replace this with your queue URL

}

const sqs = new SQSClient({ region: REGION});

const run = async () => {
  try {
    const data = await sqs.send(new SendMessageCommand(params));
    console.log("Success, product sent. MessageID:", data.MessageId);
  } catch (err) {
    console.log("Error", err);
  }
};
run();

Step 4: Test and Repeat

As you expand your microservices and move functionality away from Shopify, it’s essential to test thoroughly. This should be done at every stage. You need to have a rigorous testing system to ensure everything is still working smoothly, including the area being moved and everything else.

Advantages of the Iterative Approach

Taking a section by section approach means you can focus on a particular service and know where to look should any problems arise. That makes issues easier to fix and the overall adjustment smoother.

In addition to finding errors, it’s helpful to have metrics that measure the speed of transactions. If you can connect these to sales and customer retention, all the better.

Conclusion

Shopify Plus is an excellent platform with much to like about it, but the world is moving away from one-size-fits-all software toward more flexible, customized solutions.

Building services yourself is very achievable, but there is plenty of support available so you don’t have to go it alone entirely. An existing solution can save you time and money, and, as these services mature, the argument for that route gets stronger.

Consider taking advantage of prebuilt or customized microservices with Fabric to quickly build a system that offers adaptability for new challenges and opportunities based on solid, reusable foundations.