The last few months, we've been debating — as a community — what the Jamstack even is. In the way of a quick summary, we largely split into two groups:

1. The Pragmatists

   This group, pioneered by people like Hashicorp advocate Jeff Escalante, Forestry developer Franck Taillander, and Layer0 CTO Ishan Anand, is pushing to drop the name Jamstack because it's growing increasingly pointless as a descriptive term. They believe its trendiness has worn off and it's becoming restrictive and ultimately vexing as we fight about what's included in the definition.

2. The Resolutionists

   On the other side of the aisle, you've got the folks who want to fix the definition of the Jamstack to include new practices rather than ditch it altogether. In this camp, you've got industry leaders like Bud Parr of the New Dynamic, Brian Rinaldi from StepZen, CloudCannon CEO Mike Neumegen (who wrote an excellent article on this just a few days ago by the way), and the king of performance and accessibility Henri Helvetica.

So far, we've been trying to place a clear border through a fuzzy gradient. We've been asking: "where do we draw the line between Jamstack and the other?"

We're starting to see a consensus, though. Attitudes are cooling and people are starting to come together on a solution. Here's the gist of what they're agreeing on:

The Jamstack as a set of best practices.

It's not a dichotomy anymore. The question is no longer, "is this site Jamstack?" The question is now, "how many Jamstack techniques does this site incorporate?"

That undercuts the whole premise of the earlier debate. If the Jamstack is no longer a restrictive and exclusive category, then you don't have to drop the name entirely to start using some non-Jamstack techniques like dynamic rendering on a monolithic server. You also don't need to redefine the Jamstack to start doing bigger and better things, because you can use the Jamstack label to talk about some of your site without sounding like a purist. Now, we don't need to draw a clear border through a fuzzy gradient, trying to separate Jamstack from the other. We don't even have to place our site on that spectrum at all.

Here are some of those principles:

1. Jamstack sites don't rely on dynamic page-building code on the server.
2. As much content as possible is baked into the markup at build time.
3. Extra functionality is primarily added with third-party APIs.
4. Any necessary custom server-side code is organized in manageable, atomic, decoupled microservices.
5. Most of the necessary assets for the site to load are held close to the client in a CDN.

Perhaps you are prerendering most of your site, but the backend API you've created for yourself is based around a monolithic architecture because your particular use case requires it. That doesn't have to be controversial! You've just used some Jamstack techniques in combination with some more traditional techniques to create an application that works best for you. We can all agree that a hybrid approach like this will — in many but not all situations — work better than either extreme, right?

Consensus is good...right?

From one point of view, absolutely! People who were, at one point, not seeing eye to eye are now cooperating, and that sure is lovely to see.

On the other hand, one of our favorite business articles over here at TakeShape, a 2016 post on the blog "Conferences that Work" entitled "When consensus is dangerous", makes a great point:

"The value of consensus is in the process of seeking it — not a “yes, we have consensus!” outcome."

It's the old adage "it's the journey, not the destination" playing itself out over again. If we focus on the outcome of what the community largely feels the Jamstack is, we might be missing the underlying lesson. This whole ordeal just goes to prove that the people who are participating in this discussion are doing so because they have a passion for whatever they feel the name "Jamstack" represents. That's what's really binding this otherwise heterogenous and diverse community together!

So let's find something new to argue about.

At the Jamstack Philly: Summer of Jamstack event that we organized on July 1 and August 4, 2021, the closing keynote argued that we'll see the next few years of Jamstack development marked by four major trends:

1. We'll take Astro's motto to heart and start seriously shipping less JavaScript. That means going back to the simplicity and bare-bones, lightweight structure of the first Jamstack tools (like Jekyll) while retaining all the functionality of the big platforms that came later (like Next.JS).
2. We'll help non-developers to work with us on equal footing, finding ways to get them interacting with us in the same tools and codebases with clever and intuitive GUIs.
3. We'll see tools that we've come to love like Netlify or Vercel start to separate from the pack with platform-specific features in order to stay relevant.
4. We'll adopt new terminology for the newest techniques we're using (for example, DPR) that are far less specific — in other words, get rid of that spectrum entirely. Some are suggesting calling it just "modern" development.

Let's talk about those! Let's ask new questions to keep the process of consensus going:

1. How far can we push HTML and CSS (and WASM?) to replace the need for the slow and burdensome JavaScript?
2. What tools can we create to remove the encumbrances of our non-developer colleagues and help them work with us on the same plane?
3. If platforms have to innovate independently to stay in business, how can they maintain the cross-platform values that the Jamstack is based upon?
4. If the term Jamstack grows insufficient as we consider more and more practices "best" outside of that immediate category, what terminology will we use to describe what we're doing?

Here at TakeShape, we're putting our money where our mouth is and investing in the future tooling of the Jamstack. We're building out a concept called an API mesh: a tool to stitch together the inconsistent APIs and external services we use all the time in the Jamstack. That's one of the most common tasks we use serverless functions for, and it sure has never been a simple task. All those inconsistencies make merging the data from those disparate services quite a bear, but by offloading that difficulty to a third-party API mesh like TakeShape, you can get only the data you need from a single GraphQL endpoint. It's the key to modern Jamstack development and part of the answer to the four questions above.

We'd love to hear your thoughts on those four questions too! Make sure to tag us on Twitter at @TakeShapeIO and @jadenguitarman with your thoughts and check out our site at TakeShape.io to learn more about our plans.

TakeShape

TakeShape's API Mesh enables front-end developers to harness the power of the Jamstack by stitching together multiple external APIs with an intuitive internal CMS. I've actually been working on a series of livestreams about hydrating a product page with content from the TakeShape CMS and pricing data from Stripe, and while that might seem complex, TakeShape handles it smoothly. I just have to make one GraphQL request, and exactly the data I need arrives at the client, regardless of where that data originally came from. I wrote a summary article about those streams so you can see the process; you can check it out here.

I'm a little biased towards TakeShape, so I'll skip the ratings for this one, but I honestly love it; I'm including it in almost every project nowadays and think it's awesome.

Stripe

The whole point of ecommerce is to make money, so you need a tool to collect payment information and actually charge your customers. Stripe is the gold standard here. It's super simple to use, especially with the kits and libraries they provide, like Checkout and Elements. Their documentation is best-in-class, and their developer support team is the most helpful I've ever had to deal with.

Some more complicated setups can start getting difficult to manage, as Stripe locks you to using their system of products, subscriptions, prices, and customers, but that system is more than adequate for the vast majority of use cases. You do have to use something on the server-side for this, since Stripe requires that you keep one of your API keys secret for obvious reasons. On the Jamstack, that means running it on a host that supports serverless functions or funneling the requests to Stripe through an API Mesh like TakeShape.

All in all, I give Stripe a 9.5/10 based on its incredible developer experience.

Snipcart

Snipcart's tagline is Add a shopping cart to any website. It sure is bold, but they live up to that claim: devs from big names like Fiverr to small ecom sites are turning to Snipcart to make selling on the Internet easier. Using just HTML and JavaScript, you can inject a cart onto your site, define some attributes to describe whatever you're selling, and hook up your "Add To Cart" button. It's really that simple. DX is definitely important, but if the product manager still needs a little more convincing, you can tell them that it's portable (it's not stuck to any specific stack) and will speed up your development by working with your existing site. A lot of the tools in this market require you to build the site to work with the tool, but Snipcart has no such requirements.

Snipcart is flexible enough to handle almost any use case well, but there are some situations where you might be better off reaching for a more low-level tool. For example, I was looking into building a marketplace, and the guys from Snipcart told me that having money moving from a buyer to a seller would be difficult to implement without the money first going through a single account, which opens you up to higher transaction fees and getting taxed on those transactions differently depending on your jurisdiction.

Snipcart isn't the magic solution to every ecommerce need, but it absolutely nails its intended functionality, so I can confidently give this a 10/10.

Memberful

Ecommerce is more than just paying for a product online; one of the core concepts in ecom is the membership subscription. Memberful aims to simplify and abstract away the difficulty of this often tricky payment model, and man, does it succeed. Take a look at this guide for an example of its simplicity. It's definitely designed with non-developers in mind, so this will be a perfect fit for you if you're trying to paywall content on a larger site with dedicated content managers, if you're working on a site without a backend (like a Jamstack site), or with a Wordpress site (they've got an excellent and well-maintained plugin).

One thing I like about Memberful is that they're honest about their tool not being for everyone. In their own words, "we'd rather recommend a competitor that’s a better fit for your business than try to hard sell you on Memberful." They go on to list some situations where Memberful might be a little tougher to use and then they offer some better alternatives. For example, Memberful works best on digital content, so if you're selling physical products via an online experience (like Butcher Box or Dollar Shave Club), you might be better off with an all-in-one solution like Square.

It's less flexible than other solutions, but Memberful takes the master-of-one over the jack-of-all-trades approach, so they make up for it by perfecting their core feature set. They've definitely earned my approval: 9/10.

Auth0

Authentication is really hard to get right, and no matter how many times I try to roll it myself, I always fail. But then I heard about Auth0, and I believe I physically sighed in relief. They just give you a login system with best practices built right in, something I was really bad at building previously. Their security experts have already worked out solutions to fraud and other problems that modern ecommerce platforms are bound to face at some point or another.

That said, Auth0 can be difficult to get started with. It takes a bit of knowledge about those best practices to use Auth0's platform correctly without introducing more bugs and vulnerabilities. Thankfully, they've taken care of this by creating an excellent store of educational content on this topic to make integrating with them far easier. If you're interested in learning about how to work with Auth0, the best place to start is their blog.

With that said, it's the most powerful solution to one of the most common problems on the Internet: authentication. Auth0 earns a 8/10 from me.

Foxy.io (FoxyCart)

If Snipcart is the easy-to-use, build-into-your-existing-website shopping cart solution, Foxy.io is the super-powerful, only-for-devs, uber-customizable shopping cart solution. It's not better, just different from Snipcart, and so we use it in different scenarios. Perhaps when our small-town Mama's Pizza wants to start selling their pizzas online, Snipcart would be best, but Foxy.io might be the powerhouse needed to turn the gears behind BestBuy's website (large, but still with a single seller). Foxy.io doesn't manage inventory, while Snipcart does. Large sites like BestBuy likely are already handling that with a custom inventory solution, while something small like Mama's Pizza might make use of the inventory features of Snipcart to store their limited slate of pizza options. Foxy.io also can handle more payment gateways, which is unnecessary for smaller sites but could be critical for something as large as BestBuy.

I really like how they put it on this page: "FoxyCart is not a turnkey solution. This generally makes FoxyCart perfect for some and just plain wrong for others." I couldn't have said it better; Foxy.io (what they call it now) does the cart and checkout really well, but if that's not the largest part and central focus of your website, then you might be better off with a simple solution like Snipcart.

It's perfect for a small set of ecommerce sites, but go with Snipcart for everything else. I give it a solid 6/10 though.

SendGrid

Ah, SendGrid. Where were you all my life? Emailing is super difficult. The World Wide Web has evolved for the last 25 years, but the whole emailing system is stuck in 1996. SendGrid is kind of like a translator between that nonsense we had to deal with ages ago and the modern way we work with APIs. With customer outreach, support, and marketing being such a big part of the ecommerce world, tools that can make emailing easy like SendGrid have become absolutely indispensable. There's not that much to say about SendGrid other than the fact that they're trusted with handling crucial parts of the architecture of big websites like eBay, Nextdoor, Uber, AirBNB, and Yelp.

It does lean more towards being developer-friendly over content-creator-friendly, so you might find the interface a bit clunky if you're using SendGrid for blast emailing at a bigger company with dedicated marketers. It also looks like they funnel a lot of resources into development, which leaves customer support to focus on the biggest customers, so some smaller users have reported long stretches of time going by before hearing back from them.

Overall, I love SendGrid, and despite its minor flaws, it's always worked well for me. I give this one a 9.5/10.

Shopify

You were expecting this one, weren't you? I'll admit, I used to rail against Shopify, and I still have my qualms, but I've come to see just how powerful it can be. It's probably the least technical tool on this list, so that immediately opens up all sorts of possibilities to non-developers. That's quite important to a lot of web development agencies as their developers then don't have to be bogged down with minor updates and can focus on future development, depending on how much you've customized the templates they give you. There's a massive community (as one would expect the largest ecommerce solution to garner), and they've created all sorts of plugins and templates to make the developer's job even easier.

There is a caveat in that last pro, though. The plugin system can put the stability of your website in the hands of others, and we've seen that go well — and occasionally very, very badly — for Wordpress. Using plugins like this can open you up to vulnerabilities exposed by the plugin authors (who can be sometimes slow to fix them), so make sure to only use plugins created by companies you trust. Shopify also tends to be more of a platform than an add-on tool, so while you get the convenience of using prebuilt templates, it's much harder to customize and add non-ecommerce content. Many ecommerce companies run blogs or other informational pages, which aren't so easy to implement (it's definitely possible though!). Lastly, there's the fees. On top of the fee to use Shopify (which can be anywhere from $9 - $2000 depending on your needs), you'll likely be paying a fee on every transaction (plus your payment processor's fee).

I've grown to enjoy Shopify recently, but for many it's an acquired taste. Given just how powerful it can be, I'll give it a 7/10.

There you have it! That's my favorite 8 tools for turning a profit from your Jamstack site. It might've been historically difficult to combine ecommerce and the simplicity of the Jamstack, but thanks to tools like these 8, I'm hopeful that we'll be seeing more amazing ecommerce Jamstack experiences on the web in the future.

If you've got any questions about TakeShape or about the list in general, feel free to contact us on Twitter (@TakeShapeIO, @jadenguitarman) or at takeshape.io.

However, in the age of the Jamstack, there is a new way for front-end developers to solve this challenge. It's called an API Mesh.

Term definition: an API Mesh is kind of like a switchboard for APIs. You can set it up so that all the data and functionality you'd normally ping an API for (for example, from a CMS, or from Stripe, or from another other REST or GraphQL API) and pipe it into TakeShape (the original API Mesh). Then with one GraphQL request to TakeShape, you can access whatever data or functionality you ask it for, regardless of its original source.

The Plan

In a recent two-part stream over on my Twitch, I demonstrated the process of collecting data from multiple sources and using it to fill out a product page right on the client-side with TakeShape's API Mesh. The first part of the stream was mostly about planning, so here's what I came up with:

I decided that the majority of the data about the product itself should be stored in TakeShape's CMS (it's helpfully bundled in the same suite of tools as the API Mesh and a static site generator), while any data about pricing should be stored in Stripe. That last part might seem a bit strange to anyone who's used to working with traditional databases like MySQL: you'd think it would be better to have all the information about the product available from a single source, right?

Actually, it turns out that keeping all that product data in one place isn't necessary. Stripe makes for a good example here, since your pricing data is going to have to be stored there anyways if you're going to charge people using Stripe. If you have the price stored in your database (or CMS) along with all the other product data, then there will be some period of time — like when you're changing how much something costs — when it doesn't match exactly with the price you've got in Stripe. Then suddenly you've found yourself in a situation where you're advertising one price but charging the customer another.

To avoid scary situations like this, we need to keep Stripe as the single source of truth for any piece of data it reasonably should control. All of our prices and money-related data ought to be kept there and only there, while any other product attributes (like title, description, image, etc) could stay in the CMS.

The Steps

1. Fill our data sources with data.

   This was actually the easy part, since I just borrowed one of TakeShape's awesome starter kits on Github (I used this one). It came with everything I needed to get started, so I didn't have to do much setup. I actually ended up deleting 6 of the 9 products that came with the starter project, just for simplicity. After creating a new Stripe account, I created a product and a price in Stripe for each of the remaining sellable items, and called it done.

2. Tell the API Mesh about all of our sources.

   The API Mesh needs to know where to collect data from if it's going to deliver it to us in one neat little packet, so we've got to give it our Stripe credentials and instructions on how to use their API. Now this might sound a bit complex, but it's really not; I went through this process live on the stream, and even with my impulsive rambling, it barely took 10 minutes.

   All we really have to do is define these data sources as services in TakeShape. They're listed under the Schema tab. Just click the "Connect Service" button to add a new one.

   

   To add a new service, click the Schema tab, and then the Connect Service button.

   It'll walk you through a simple form just asking for the name of the service, the root endpoint (that's [api.stripe.com](http://api.stripe.com) in my case), and your auth details. Make sure to read the docs of the API you're using (here in my case) and the little note on the TakeShape form to make sure you're putting the right credentials in the right fields. In my initial stream, I made a tiny mistake here and used the wrong auth type. It wasn't a big deal; I just had to spend 5 minutes correcting it in the second stream.

3. Tell the API Mesh to stitch data from those sources into one request.

   For this, we're going to jump into a little bit of JSON. Click the Export button on the Schema page to download the JSON that represents your entire project.

   

   Click the Export button on the Schema page to download JSON that represents your entire project.

   The JSON it downloads might seem a bit unwieldy, but luckily most of it isn't relevant at the moment, so I use my code editor to fold a lot of it up so I can focus on what's important right now:

   

   My folded-up, simple view of the JSON schema that represents my whole project

   See the Stripe service we added earlier? The TakeShape GUI just edited this JSON file for us. For the queries, shapes, and forms, we're going to do essentially the same thing, except we're just going to edit the JSON file ourselves.

   The first step for me was to go into the Product form and remove any property that mentions price data, since we're going to keep that in Stripe. If you're following along, make sure to check the order list too. Do the same thing in the Product shape, making sure to check the required list as well (that was another thing I briefly forgot about in the livestream, which I had to spend a minute or two correcting).

   Next, we've got to add a property to the Product shape called productId, which would look something like this:

    "productId": {
        "type": "string",
        "title": "Product ID",
        "minLength": 1
    }
   

   That goes in the properties array under the Product shape.

   The whole point of using this API Mesh in the first place was to help us developers stitch together all the tools our coworkers are using, so we've got to give whoever is in charge of maintaining the product entries the ability to enter the Stripe product ID into the CMS. TakeShape's CMS just displays forms to the user, which they can fill out to edit the product (or whatever other thing they're editing). So earlier, when we removed the price data from the Product form, we were removing the ability for our coworkers to add the price directly into TakeShape's CMS. Now that we want to let them add the Stripe product ID, we're going to add a new property to the Product form:

    "productId": {
        "widget": "singleLineText"
    }
   

   Now here comes the toughest part, though it's still fairly straightforward. We want TakeShape to automatically pull in price data from Stripe whenever we ask it about a product. In other words, we're asking TakeShape to resolve the product to its appropriate price data from Stripe. In line with that, let's give TakeShape a resolver so it knows what data to give us.

   Go back to that Product shape and add this property:

    "priceData": {
        "type": "object",
        "properties": {
            "inCents": {
                "type": "number"
            }
        },
        "title": "Price Data",
        "@resolver": {
            "name": "rest:get",
            "service": "stripe",
            "options": {
                 "fieldName": "priceData",
                "path": "v1/prices"
            },
            "argsMapping": {
                "searchParams.product": [
                    [
                        "jsonPath",
                        {
                            "path": "$.source.productId"
                        }
                    ]
                ]
            },
            "resultsMapping": {
                "inCents": [
                    [
                        "jsonPath",
                        {
                            "path": "steps[0].data[0].unit_amount"
                        }
                    ]
                ]
            }
        }
    }
   

   Here's a little breakdown for the curious:

   1. First, we define that this is going to be an object, and that it'll have one property of its own called inCents, which will be a number.
   2. Then, we tell it to get information from a GET request to the stripe service we defined earlier, at the /v1/prices endpoint.
   3. Then, the API mesh is instructed to send the productID of this particular product into Stripe as a search parameter.

   4. Lastly, we're asking that the unit_amount buried in Stripe's response be piped into that inCents property we defined earlier, so that our end result ends up nice and tidy.

      We're done with this file, so just reimport that JSON file back into TakeShape and let the API Mesh do its thing.

4. Fill our product page with data from the API Mesh.

   If we're going to hydrate our product page on the client, then we need to first request the data from our API Mesh. The GraphQL query we're sending to TakeShape would look something like this:

    const query = `{
        getProductList {
            items {
                description
                    image {
                        sourceUrl
                    }
                    name
                    priceData {
                        inCents
                    }
                    category {
                        searchSummary
                    }
                    soldOut
                }
            }
        }`;
   

   Here's the function I wrote to actually send that request:

    const getMeMyData = async index => {
        let req = await fetch(
            `https://api.takeshape.io/project/${TS_PRODUCT_ID}/v3/graphql`, 
            {
                method: 'POST',
                headers: {
                    'Content-Type': 'application/json',
                    'Authorization': `Bearer ${TS_API_KEY}`
                },
                body: JSON.stringify({ query })
            }
        );
   
        let result = await req.json();
        return result.data.getProductList.items[index];
    };
   

   And then here's the function that uses that data to hydrate my HTML:

    const hydrateMePage = async productIndex => {
        const product_data = await getMeMyData(productIndex);
   
        document.getElementById("product-title").innerText = product_data.name;
        document.getElementById("product-description").innerText = product_data.description;
   
        let productImage = document.getElementById("product-image");
        productImage.src = product_data.image.sourceUrl;
        productImage.alt = product_data.name;
   
        document.querySelector(".product-price > span").innerText = "$" + (product_data.priceData.inCents / 100).toFixed(2);
        document.getElementById("product-category").innerText = product_data.category.searchSummary;
        if (product_data.soldOut) document.querySelector("main.container").classList.add("sold-out");
    };
   

   Those two small functions set us up to fill out our whole page with data from multiple sources without practically any technical debt. Just run a hydrateMePage(0) and it'll fill the page with data like magic; except that it's not magic, it's an API Mesh stitching together our CMS and Stripe data so we don't have to do the legwork of stitching it ourselves.

The Results

And with those four steps, we've suddenly created an entire data pipeline for our ecommerce website. To create a search results page, or a homepage, or anything else, we don't even have to replicate all the steps; depending on whether you need to add more sources or not, you'd just start from step 2 or 4.

If you're interested in seeing more builds like this, I stream over on my Twitch every Monday afternoon. We also talk with leaders in the web development community about their experiences with interactive interviews there on Thursday afternoons. Make sure to follow @takeshapeio and @jadenguitarman on Twitter to get the latest updates.