The next step in ecommerce – replatform with APIs and micro front ends(stackoverflow.blog)
stackoverflow.blog
The next step in ecommerce – replatform with APIs and micro front ends
https://stackoverflow.blog/2022/12/12/the-next-step-in-ecommerce-replatform-with-apis-and-micro-frontends/
85 comments
I find myself regularly trying to talk my clients out of going headless on Shopify. The benefits are so hyped (and potentially real) but the cost/maintenance is significant.
I’ve come into working on multiple different headless sites developed by others who then walked away and left an entirely non-technical team to sort it out.
A well-built Shopify theme works great and plenty fast for even medium sized companies.
I’ve come into working on multiple different headless sites developed by others who then walked away and left an entirely non-technical team to sort it out.
A well-built Shopify theme works great and plenty fast for even medium sized companies.
We switched to building headless Shopify sites a while back due to constant requests from clients to do things that were not possible in Shopify alone, quite a long list but a lot of it boiled down to rich content or having more control over 'serverside' logic. Our approach is now at a point where I'm more confident in our GraphQL backed headless stores than any of our Shopify themes in terms of maintenance and ease of updating.
Since then Shopify has updated a bit (although not all that much, a lot of the issues remain) and we have had a wave of requests in the last year to build in Shopify - largely since none of the local marketing agencies want to touch headless.
It's been a bit disheartening really. I've been trying to get to the bottom of the marketing issues but I haven't been able to get clear answers on what they are.
Shopify also doesn't have amazing support for headless (double login on checkout is a big one), but with the rollout of their own Oxygen/Hydrogen platforms I've been waiting to see if they manage to solve these issues for their own solutions.
Since then Shopify has updated a bit (although not all that much, a lot of the issues remain) and we have had a wave of requests in the last year to build in Shopify - largely since none of the local marketing agencies want to touch headless.
It's been a bit disheartening really. I've been trying to get to the bottom of the marketing issues but I haven't been able to get clear answers on what they are.
Shopify also doesn't have amazing support for headless (double login on checkout is a big one), but with the rollout of their own Oxygen/Hydrogen platforms I've been waiting to see if they manage to solve these issues for their own solutions.
Yeah, I think if Oxygen/Hydrogen can smooth out some of those issues it would make more sense and be more self-documenting. The current state of hodge podging work arounds requires institutional knowledge to maintain.
I’ve found though that often when clients say they need something that only a headless solution can provide, they actually don’t truly need it. And once the actual requirements are focused, a well built Shopify theme is plenty sufficient.
Maybe we are working at a different scale of companies though.
The main advantage of headless to me is the ability to get the speed of the site way up. But the nature of e-commerce is to add tons of pixels and other junk so it can defeat the advantages (and much harder to talk them out of adding pixels sadly…)
I’ve found though that often when clients say they need something that only a headless solution can provide, they actually don’t truly need it. And once the actual requirements are focused, a well built Shopify theme is plenty sufficient.
Maybe we are working at a different scale of companies though.
The main advantage of headless to me is the ability to get the speed of the site way up. But the nature of e-commerce is to add tons of pixels and other junk so it can defeat the advantages (and much harder to talk them out of adding pixels sadly…)
I'd be interested in chatting about this further - I don't know many others operating in the same space, I can be contacted through the website in my profile (Director).
Our scale is a bit unusual, its more like high end small scale than large scale, think more like an architect designed house rather than a commercial building. As a result every site has some fairly unique features and Shopify often struggles with those. It's getting tricker to balance over time as the bar for a 'basic' store keeps being raised though.
Our scale is a bit unusual, its more like high end small scale than large scale, think more like an architect designed house rather than a commercial building. As a result every site has some fairly unique features and Shopify often struggles with those. It's getting tricker to balance over time as the bar for a 'basic' store keeps being raised though.
I tell this to every photographer, maker, and Mom and Pop shop wondering how to get into e-commerce. Thank you for validating my opinion.
It’s important to not just choose the correct tool for the job, but also be aware of the scale of tool you need.
There are hammers, and then there are pneumatic powered nail guns, which one do YOU need?
It’s important to not just choose the correct tool for the job, but also be aware of the scale of tool you need.
There are hammers, and then there are pneumatic powered nail guns, which one do YOU need?
I worked with a smaller but decent-sized player in this space and the API components (while difficult) are the easier piece of the puzzle. Micro-front-ends seem really cool but you don't have to dig very deep before your spidey sense starts to tingle. We built on top of CT and others, and the front-end composition was a nightmare, so if you think backend microservices are tough to get right you haven't seen anything yet. In our experience you typically jumped through a lot of hoops to build a custom UI in someone else's walled garden against APIs that had great promise but never got you as far as "API-first" should in terms of custom, sophisticated work flows.
Commercetools sits nicely between way to complicated and too rigid to do anything useful.
not that long ago there was a trending article on HN about how abstraction was expensive. It is exceedingly difficult to determine and offer the right interfaces for these that can have many different downstream implementations. Definitely not for the faint of heart, feels like a higher level of engineering than most people want/need.
Its just bad. The commercetools projects I have seen are all slow, broken clusterfucks. In one instance they apparently used the search api, that commercetools provides, and the requests take more than 3 seconds in some cases. Maybe they just implemented it badly, but I suspect its a mix of bad implementation and bad api. When I talked with the people that implemented that, about doing more complicated stuff than a run-of-the-mill facetted search, they could not offer a solution. Commercetools apparently uses elastic-search under the hood, but either its not possible to use that directly or not supposed to be used directly. @cnj please correct any misinformation, I confess I haven't spend any time researching this (I was turned off right away).
I'm going to have to disagree. While basic startups may be best served by shopify anything with complexity should consider an API-First platform. B2B2C, Multi, etc. all benefit from the flexibility it provides. What is important is finding a SaaS with a true multi-tenant infrastructure so they can price based on usage instead of having a large yearly minimum contract value.
Startups can have great success going API-First, but it's contingent on working with the right company.
Startups can have great success going API-First, but it's contingent on working with the right company.
Tools at the Shopify level solve customer problems for companies and then layer-on solutions to the merchants’ own problems (inventory, marketing, fulfillment etc)
Tools at the CommerceTools level address “large company” problems first and foremost, some of which are real and others imaginary, often to the detriment of the customer experience.
This isn’t a criticism of anyone’s technology but more of an observation of how things are very different when the customer is a billion dollar enterprise.
Tools at the CommerceTools level address “large company” problems first and foremost, some of which are real and others imaginary, often to the detriment of the customer experience.
This isn’t a criticism of anyone’s technology but more of an observation of how things are very different when the customer is a billion dollar enterprise.
When I worked in a LARGE eCommerce company maybe 6 years ago, everything was driven by CSV files dropped in an FTP folder. There were a few exceptions where companies had API's. Still even those were GET requests initiated by us, and we didn't want to overload them so it wasn't super up-to-date, but that was the norm. I tried to break out to do my own thing, and I realized those automated systems were only for the big guys.
If you were small, you don't even get the privlidge of an inventory file. Vendors don't have time to deal with small guys, and it can be super difficult to get started.
Playing with crypto, and NFT's, I realized this was what I wish was the norm. The indexers were close to real-time. The chain I was using (AVAX) had a finality of 4 seconds, and gas is cents.
What i'm going to describe isn't a solution to a problem the big guys have. They had enough sway with their vendors to get good systems. But for small guys like me, open access to automated systems would have been a god send. My dream system would be something like this:
Think of this happening in a subnet (an app specific blockchain that doesn't share space with other apps, so scale is not affected by other apps)
1. A Trusted supplier mints a NFT for each of their SKU's (yeah trust and crypto don't go together ideologically, that's a purity problem crypto needs to get over itself, sometimes trust is useful... if you try to build the whole thing trustless, it's not better than traditional systems).
2. These NFT's are listed in any NFT marketplace that cares to list them. (with subnet-to-subnet messaging, you don't need to duplicate the contracts... so shouldn't have major scale issue. This is a brand new feature, so i'm not super sure though.)
3. I as a small scale vendor list a sku on my normal site. I can take payment as normal, but then I can call the NFT's index to get real-time inventory (even though I have no preexisting relationship with the vendor)
4. I get an order, I buy the NFT off the marketplace, and burn the NFT. My customers details are provided in the NFT burn contract. An app specific precompile let's me transmit those details to the vendor without making it public on the block chain (with proof it received it correctly).
5. After the NFT is burned, an ERC20 token is dropped in my stores wallet. After I get enough of these, I can trade them in for a volme rebate. This let's the small vendors get access to effectively what is a volume discount.
I suppose this could be a SaSS app, but there's a bunch of side benefits to crypto, such as defi, tooling etc. But mainly vendors can customize their own terms if they own the full contract chain.
If you were small, you don't even get the privlidge of an inventory file. Vendors don't have time to deal with small guys, and it can be super difficult to get started.
Playing with crypto, and NFT's, I realized this was what I wish was the norm. The indexers were close to real-time. The chain I was using (AVAX) had a finality of 4 seconds, and gas is cents.
What i'm going to describe isn't a solution to a problem the big guys have. They had enough sway with their vendors to get good systems. But for small guys like me, open access to automated systems would have been a god send. My dream system would be something like this:
Think of this happening in a subnet (an app specific blockchain that doesn't share space with other apps, so scale is not affected by other apps)
1. A Trusted supplier mints a NFT for each of their SKU's (yeah trust and crypto don't go together ideologically, that's a purity problem crypto needs to get over itself, sometimes trust is useful... if you try to build the whole thing trustless, it's not better than traditional systems).
2. These NFT's are listed in any NFT marketplace that cares to list them. (with subnet-to-subnet messaging, you don't need to duplicate the contracts... so shouldn't have major scale issue. This is a brand new feature, so i'm not super sure though.)
3. I as a small scale vendor list a sku on my normal site. I can take payment as normal, but then I can call the NFT's index to get real-time inventory (even though I have no preexisting relationship with the vendor)
4. I get an order, I buy the NFT off the marketplace, and burn the NFT. My customers details are provided in the NFT burn contract. An app specific precompile let's me transmit those details to the vendor without making it public on the block chain (with proof it received it correctly).
5. After the NFT is burned, an ERC20 token is dropped in my stores wallet. After I get enough of these, I can trade them in for a volme rebate. This let's the small vendors get access to effectively what is a volume discount.
I suppose this could be a SaSS app, but there's a bunch of side benefits to crypto, such as defi, tooling etc. But mainly vendors can customize their own terms if they own the full contract chain.
> What i'm going to describe isn't a solution to a problem the big guys have. They had enough sway with their vendors to get good systems. But for small guys like me, open access to automated systems would have been a god send.
I guess what I don't understand about this is the incentive structure for the vendor.
If the TAM opened by providing small guys with inventory files is big enough, just put a CSV in an S3 bucket or provide an API that's "free until abusive". No need for middleware and you can probably pay for decades of bandwidth before the middleware's cut comes even close to break-even. I work with a few small vendors, and this is basically what they do. No NFTs, blockchain, or other nonsense needed. File hosting+CSV solved the problem over a decade ago.
This part also doesn't make any sense to me:
> After I get enough of these, I can trade them in for a volume rebate. This let's the small vendors get access to effectively what is a volume discount.
The real question is: how many of these vendors even want to work with the small guys?
In B2B, nontrivial volume discounts are justifiable due to a downstream entity's ability to guarantee demand to the upstream supplier. It's a cash-flow thing. If a downstream consumer can guarantee they will buy a certain amount of product, I can take that to the bank (sometimes literally) and invest in growing the business. The reduced volatility and guaranteed demand is worth a 20% discount because it allows me to invest in growth with reduced risk.
Small businesses with JIT inventory and bursty sales are literally the exact opposite of what a small manufacturer wants. As a manufacturer, why would I give a bulk discount to the least attractive type of consumer?! It'd be literally paying for the privilege of taking on someone else's risk... I can understand why my counterparty would love post-facto bulk rebates, but why the heck would I as a manufacturer give them the pleasure of screwing me!?
I guess what I don't understand about this is the incentive structure for the vendor.
If the TAM opened by providing small guys with inventory files is big enough, just put a CSV in an S3 bucket or provide an API that's "free until abusive". No need for middleware and you can probably pay for decades of bandwidth before the middleware's cut comes even close to break-even. I work with a few small vendors, and this is basically what they do. No NFTs, blockchain, or other nonsense needed. File hosting+CSV solved the problem over a decade ago.
This part also doesn't make any sense to me:
> After I get enough of these, I can trade them in for a volume rebate. This let's the small vendors get access to effectively what is a volume discount.
The real question is: how many of these vendors even want to work with the small guys?
In B2B, nontrivial volume discounts are justifiable due to a downstream entity's ability to guarantee demand to the upstream supplier. It's a cash-flow thing. If a downstream consumer can guarantee they will buy a certain amount of product, I can take that to the bank (sometimes literally) and invest in growing the business. The reduced volatility and guaranteed demand is worth a 20% discount because it allows me to invest in growth with reduced risk.
Small businesses with JIT inventory and bursty sales are literally the exact opposite of what a small manufacturer wants. As a manufacturer, why would I give a bulk discount to the least attractive type of consumer?! It'd be literally paying for the privilege of taking on someone else's risk... I can understand why my counterparty would love post-facto bulk rebates, but why the heck would I as a manufacturer give them the pleasure of screwing me!?
> just put a CSV in an S3 bucket or provide an API
It's more than JUST inventory. It's inventory, orders, and volume discounts. I don't deny that you could build a bunch of s3 buckets, and API's to solve these problems. Of course you can, we've been doing it for 2 decades. But it's not a great solution. I've worked with them, it sucks. As a retailer I need to automate each one independently. My web3 solution gives a single interface for multiple vendors for each function. I believe my solution is simpler. It may not sound simpler because the tech underneath is somewhat complicated. But from a user point of view (as a retailer, and as a vendor) it's WAY easier. I think it's also SIGNIFICANTLY less work for the vendor to implement.
> Small businesses with JIT inventory and bursty sales are literally the exact opposite of what a small manufacturer wants.
Does a vendor care if it's 1 large business or many small businesses in aggregate? It does if it has to deal with all the small guys. The main problem with dealing with many small vendors is the management of it all. This is my solution to making it trivial, so they can get the additional reach, without having to deal with a bunch of small entities.
My goal is to make it easier for small businesses to compete with big business (as in retailers). I think this technology can solve some of the problems that previously made it not worth the time for vendors.
It's more than JUST inventory. It's inventory, orders, and volume discounts. I don't deny that you could build a bunch of s3 buckets, and API's to solve these problems. Of course you can, we've been doing it for 2 decades. But it's not a great solution. I've worked with them, it sucks. As a retailer I need to automate each one independently. My web3 solution gives a single interface for multiple vendors for each function. I believe my solution is simpler. It may not sound simpler because the tech underneath is somewhat complicated. But from a user point of view (as a retailer, and as a vendor) it's WAY easier. I think it's also SIGNIFICANTLY less work for the vendor to implement.
> Small businesses with JIT inventory and bursty sales are literally the exact opposite of what a small manufacturer wants.
Does a vendor care if it's 1 large business or many small businesses in aggregate? It does if it has to deal with all the small guys. The main problem with dealing with many small vendors is the management of it all. This is my solution to making it trivial, so they can get the additional reach, without having to deal with a bunch of small entities.
My goal is to make it easier for small businesses to compete with big business (as in retailers). I think this technology can solve some of the problems that previously made it not worth the time for vendors.
> It's inventory, orders, and volume discounts.
I see. That makes more sense.
The web3 angle seems like a red herring.
> It may not sound simpler because the tech underneath is somewhat complicated. But from a user point of view (as a retailer, and as a vendor) it's WAY easier. I think it's also SIGNIFICANTLY less work for the vendor to implement.
Easier than bespoke, sure. But a web2 platform custom-built for this purpose would surely be easier than web3. Both to implement and to sell to vendors. No?
> Does a vendor care if it's 1 large business or many small businesses in aggregate?
Well, you definitely care about your counter-party's credit risk and the cost to you of assessing that risk!
Cost of assessment: having one large counter-party vs. a ton of smaller counter-parties is a substantive difference even if they're identical credit risks.
Actual risk: In practice a good number of those small counter-parties are small shops that might keep close to zero capital in their business. Particularly in the case of eg drop-shipping. A typical drop shipper is literally more risky than the end consumer! So counterparty's credit risk is wildly different. A bunch of worthless LLCs running on razor thin margins with very little cash in the bank vs. a large well-capitalized company with significant assets.
> My goal is to make it easier for small businesses to compete with big business (as in retailers). I think this technology can solve some of the problems that previously made it not worth the time for vendors.
Aggregating demand is a useful role for an intermediary, but the real product is financial services rather than information services. Playing the role of either auditor or guarantor for aggregated larger purchasing promises made by smaller entities would certainly be a real financial service for which you could charge a reasonable fee (ie take a cut of the discount). But still the vendor doesn't care. They just treat you as the large well-capitalized client. And your customers are the smaller consumers.
I see. That makes more sense.
The web3 angle seems like a red herring.
> It may not sound simpler because the tech underneath is somewhat complicated. But from a user point of view (as a retailer, and as a vendor) it's WAY easier. I think it's also SIGNIFICANTLY less work for the vendor to implement.
Easier than bespoke, sure. But a web2 platform custom-built for this purpose would surely be easier than web3. Both to implement and to sell to vendors. No?
> Does a vendor care if it's 1 large business or many small businesses in aggregate?
Well, you definitely care about your counter-party's credit risk and the cost to you of assessing that risk!
Cost of assessment: having one large counter-party vs. a ton of smaller counter-parties is a substantive difference even if they're identical credit risks.
Actual risk: In practice a good number of those small counter-parties are small shops that might keep close to zero capital in their business. Particularly in the case of eg drop-shipping. A typical drop shipper is literally more risky than the end consumer! So counterparty's credit risk is wildly different. A bunch of worthless LLCs running on razor thin margins with very little cash in the bank vs. a large well-capitalized company with significant assets.
> My goal is to make it easier for small businesses to compete with big business (as in retailers). I think this technology can solve some of the problems that previously made it not worth the time for vendors.
Aggregating demand is a useful role for an intermediary, but the real product is financial services rather than information services. Playing the role of either auditor or guarantor for aggregated larger purchasing promises made by smaller entities would certainly be a real financial service for which you could charge a reasonable fee (ie take a cut of the discount). But still the vendor doesn't care. They just treat you as the large well-capitalized client. And your customers are the smaller consumers.
> Easier than bespoke, sure. But a web2 platform custom-built for this purpose would surely be easier than web3. Both to implement and to sell to vendors. No?
Even better, if your goal is to promote competition rather than just make money: publish an open standard that can be implemented by anyone. Might not be much more than a specific set of columns that a CSV has to have to be considered an OpenVendorMagick(tm) inventory endpoint.
Even better, if your goal is to promote competition rather than just make money: publish an open standard that can be implemented by anyone. Might not be much more than a specific set of columns that a CSV has to have to be considered an OpenVendorMagick(tm) inventory endpoint.
In practice, web3 has proven to be more open and composable than web2. I guess in theory web2 could start coordinating with each other. But it just doesn't seem to happen often. On the other hand web3 companies have shown to be extremely interoperable. Whitnessing this was one of the first things that made me go "there's something here".
The financial services aspect is something I'm also aware of. That's in a way what I want referring to when I said it has defi benefits. It's another example where the big guys have an advantage, but I think crypto can even the playing field (my main concern there is I suspect it would be legally classified as a security)
> then I can call the NFT's index to get real-time inventory
Do you mean you're selling as an intermediary and aren't holding stock yourself? What sort of industries does that happen in? I'd have thought for most B2C sales you'd hold inventory yourself (that's always been one thing putting me off starting an online shop).
Do you mean you're selling as an intermediary and aren't holding stock yourself? What sort of industries does that happen in? I'd have thought for most B2C sales you'd hold inventory yourself (that's always been one thing putting me off starting an online shop).
> I'd have thought for most B2C sales you'd hold inventory yourself (that's always been one thing putting me off starting an online shop).
Not sure if this is what you're talking about, but drop shipping (you're a proxy store) and Print-On-Demand (you sell t-shirts but they're made and shipped to the customer by the order from a different company - again you're just a proxy) are very popular.
There's less margin but you remove all of the cost/risk of logistics and inventory
Not sure if this is what you're talking about, but drop shipping (you're a proxy store) and Print-On-Demand (you sell t-shirts but they're made and shipped to the customer by the order from a different company - again you're just a proxy) are very popular.
There's less margin but you remove all of the cost/risk of logistics and inventory
> There's less margin but you remove all of the cost/risk of logistics and inventory
Risk isn't removed, only externalized. In this case you externalize it to the manufacturer. They know this and are happy to take on the risk... for a price.
That's why the kind of post-facto bulk rebates pitched in GP make no sense.
The Big Big bulk discount the big guys get is the "real" price, and drop shippers get smaller/no discount because they have to pay at least part of the risk premium induced by the drop shipping business model.
Risk isn't removed, only externalized. In this case you externalize it to the manufacturer. They know this and are happy to take on the risk... for a price.
That's why the kind of post-facto bulk rebates pitched in GP make no sense.
The Big Big bulk discount the big guys get is the "real" price, and drop shippers get smaller/no discount because they have to pay at least part of the risk premium induced by the drop shipping business model.
[deleted]
Some people buy and hold inventory, but it's pretty common to do a process called "drop shipping" where you have a relationship with the manufacturer, and have them ship it to the customer. The benefit for them is YOU deal with the customers, and YOU do the marketing.
> yeah trust and crypto don't go together ideologically, that's a purity problem crypto needs to get over itself
The first white papers I read about crypto emphasized the "trustless" part of it. It's a selling point. They exchanged human trust for computational trust, only now people are realizing the limits of computer trust (namely, anything that isn't digital isn't covered).
What we're looking for now is a way to actually entangle digital assets with physical assets (hence the rise of NFTs, which purport to be a physical thing, or at least the closest thing to).
The first white papers I read about crypto emphasized the "trustless" part of it. It's a selling point. They exchanged human trust for computational trust, only now people are realizing the limits of computer trust (namely, anything that isn't digital isn't covered).
What we're looking for now is a way to actually entangle digital assets with physical assets (hence the rise of NFTs, which purport to be a physical thing, or at least the closest thing to).
You would always need a central authority to reconcile the state of the physical world with the digital ledger. At that point what is the blockchain for? Or, what does the network look like that "runs" the blockchain? Surely there isn't any mining or proof of work, because there's no internal token to produce this way; the value is all external.
And you cant trust random people to create the token or to reconcile (lie) about the physical/digital correspondence. Entangling digital with physical seems to devolve to just a database with a trusted authority administering it. I don't see any other way.
And you cant trust random people to create the token or to reconcile (lie) about the physical/digital correspondence. Entangling digital with physical seems to devolve to just a database with a trusted authority administering it. I don't see any other way.
My design philosophy is to use the blockchain for the parts where it's a good solution, and to not use it for the parts where it's not. For physical products that means adding some trust into the system. For pure digital systems, that means identity, money, or owned objects etc. can go on-chain. Things that are just transient data can go in a traditional database.
> (namely, anything that isn't digital isn't covered)
Yep! this was my realization when I first started thinking about the idea. You can't computationally trust the movement of physical stuff. Some amount of trust is going to slip in somewhere. It's better to insert the trustless transactions in the places where the relationship is purely digital. In my example above, you have a large vendor which you (as a retailer) trust has inventory to back up every NFT they minted, and you trust to ship relatively reliably. You can't avoid that trust (though you could build mechanisms to increase your trust like 3rd party audits or something). But the relationship with hundreds of small retailers could be built trustlessly. So it's more like strategic trust as opposed to pure trustlessness.
Yep! this was my realization when I first started thinking about the idea. You can't computationally trust the movement of physical stuff. Some amount of trust is going to slip in somewhere. It's better to insert the trustless transactions in the places where the relationship is purely digital. In my example above, you have a large vendor which you (as a retailer) trust has inventory to back up every NFT they minted, and you trust to ship relatively reliably. You can't avoid that trust (though you could build mechanisms to increase your trust like 3rd party audits or something). But the relationship with hundreds of small retailers could be built trustlessly. So it's more like strategic trust as opposed to pure trustlessness.
So, I happen to know this niche extremely well!
I'm one of the maintainers of MageOS (a fork of Magento) as well as a maintainer of Daffodil (a monolithic Angular PWA framework - not Microfrontends yet).
APIS are definitely the way to go but, while that's a great next step, what we're really facing is a standards issues.
Some have tried.
Schema.org as a standard is overly complex and each platform has their own API definition.
Microfrontends can be great as well, but ecommerce has a particularly special problem of requiring extremely performant SSR, so that's always a critical and complex piece to get correct.
However, this article is clearly an ad.
I'm one of the maintainers of MageOS (a fork of Magento) as well as a maintainer of Daffodil (a monolithic Angular PWA framework - not Microfrontends yet).
APIS are definitely the way to go but, while that's a great next step, what we're really facing is a standards issues.
Some have tried.
Schema.org as a standard is overly complex and each platform has their own API definition.
Microfrontends can be great as well, but ecommerce has a particularly special problem of requiring extremely performant SSR, so that's always a critical and complex piece to get correct.
However, this article is clearly an ad.
Former M1/M2 Dev here. The benefits of headless to me are that it's far easier to find javascript developers than to ruin someone with learning the Magento architecture.
I haven't seen Magento - under Ebay, under Adobe, under anyone address what I think is the biggest issue facing them - total cost of ownership in comparison to the competition.
Is mageOS mostly just a maintainence mode, keep this alive till everyone can switch off (like the M1 forks that exist) or do you actually envision trying to solve some of the challenges magento is facing as a community and platform?
I haven't seen Magento - under Ebay, under Adobe, under anyone address what I think is the biggest issue facing them - total cost of ownership in comparison to the competition.
Is mageOS mostly just a maintainence mode, keep this alive till everyone can switch off (like the M1 forks that exist) or do you actually envision trying to solve some of the challenges magento is facing as a community and platform?
MageOS is not a maintenance mode, unfortunately we don't do a good job expressing that.
The goal is to migrate management of the codebase out of Adobe's hands back into the community's. Community PRs, triage, etc.
We're currently working on getting the entire CI pipeline setup in Github Actions (if you're interested in contributing, we could really use friendly faces, it's quite an undertaking). Once we're past that, we have goals that are in progress:
DevX:
1. Correct the dep graph of MageOS to be a legitimate DAG and then use nx/bazel/make, etc to compute the build graph. 2. Create codespaces/gitpods/devcontainers for easier day 1 devs. 3. Rip GraphQl out into a separate package space. 4. Create smaller more use-case specific metapackages so that you're not forced into all of Magento or nothing. 5. Maintain backwards compatibility with existing Magento packages.
UX: 1. Significantly improve overall performance.
MerchX: 1. Improve Merch documentation and make Merch docs easier to consume.
Generally to your question, we're not interested in maintenance, we're interested in taking on the burden of being a better development effort alongside a better merchant experience.
That said, this is not a sales pitch. The problem is hard, but we'd like to prove that we're harder.
The goal is to migrate management of the codebase out of Adobe's hands back into the community's. Community PRs, triage, etc.
We're currently working on getting the entire CI pipeline setup in Github Actions (if you're interested in contributing, we could really use friendly faces, it's quite an undertaking). Once we're past that, we have goals that are in progress:
DevX:
1. Correct the dep graph of MageOS to be a legitimate DAG and then use nx/bazel/make, etc to compute the build graph. 2. Create codespaces/gitpods/devcontainers for easier day 1 devs. 3. Rip GraphQl out into a separate package space. 4. Create smaller more use-case specific metapackages so that you're not forced into all of Magento or nothing. 5. Maintain backwards compatibility with existing Magento packages.
UX: 1. Significantly improve overall performance.
MerchX: 1. Improve Merch documentation and make Merch docs easier to consume.
Generally to your question, we're not interested in maintenance, we're interested in taking on the burden of being a better development effort alongside a better merchant experience.
That said, this is not a sales pitch. The problem is hard, but we'd like to prove that we're harder.
The problem space is huge. It's akin to LibreOffice, we have this huge amount of code, written by enterprises in complex ways, and the end user doesn't care, they just want it to work.
The backwards compatibility is really a challenge, but I think more importantly dumping Knockout and Luma and all that insanity and going towards the Hyva route, or going more-headlessy with a good starter theme would encourage people enourmously.
Magento's frontend cluster-F is the reason we moved away from it. It was great to have such a good pricing engine, integrations pieces, currency support etc, but all of that skillset which is magento's core capability being a really well rounded online OMS is overshadowed by long and expensive turn arounds on frontend work.
The backwards compatibility is really a challenge, but I think more importantly dumping Knockout and Luma and all that insanity and going towards the Hyva route, or going more-headlessy with a good starter theme would encourage people enourmously.
Magento's frontend cluster-F is the reason we moved away from it. It was great to have such a good pricing engine, integrations pieces, currency support etc, but all of that skillset which is magento's core capability being a really well rounded online OMS is overshadowed by long and expensive turn arounds on frontend work.
Fully agree. The problems are hard, the interested talent is limited (who would want to work on line of business software when academia actively pushes people towards other things), and the problem space (all possible online business configurations) is immense.
Re:frontend, you're absolutely correct. Magento's frontend is a sad state. MageOS is actively looking for ways to move Luma/Blank into a separate installable package so that devs are not forced to see it at every turn.
In terms of Headless, there are a bunch of different heads at this point, but none have yet solved what I call the "upgrade-safe theme" problem.
I like what we've done with Daffodil since it doesn't impose any of those limitations that come with themes, while still handling a lot of the complexity that devs face when building ecommerce stores.
Re:frontend, you're absolutely correct. Magento's frontend is a sad state. MageOS is actively looking for ways to move Luma/Blank into a separate installable package so that devs are not forced to see it at every turn.
In terms of Headless, there are a bunch of different heads at this point, but none have yet solved what I call the "upgrade-safe theme" problem.
I like what we've done with Daffodil since it doesn't impose any of those limitations that come with themes, while still handling a lot of the complexity that devs face when building ecommerce stores.
Ignoring academia - what's the value for a business minded tech person to stay in the Magento world? I'm surely not the only M2 tech lead type who's jumped ship off to greener pastures.
Businesses will always have commerce problems, so you're pretty stable in terms of consistent income.
If you can make a name for yourself, you can do very well. Especially for Magento, I love the fact that I can make small change, deliver it as a composer package, and then (if the code is good enough) see the results on many brands within a few months.
It's hard to get that close-to-customer visibility anywhere else as most "cool" large scale FOSS projects are dev focused, which means your impact on the lay user is less obvious.
If you can make a name for yourself, you can do very well. Especially for Magento, I love the fact that I can make small change, deliver it as a composer package, and then (if the code is good enough) see the results on many brands within a few months.
It's hard to get that close-to-customer visibility anywhere else as most "cool" large scale FOSS projects are dev focused, which means your impact on the lay user is less obvious.
Thank you for calling them "JavaScript developers" instead of "front-end developers"; it's accurate.
[deleted]
As someone who works in the commerce space day-to-day, the trend is interesting and definitely something you will hear a lot of ecommerce managers and businesses discuss.
Aside from the frontend flexibility, one major advantage of building API-first in an ecommerce context is that it can allow different parts of the system to be developed and maintained independently. This can make it easier to update and extend individual components without affecting the overall system - which is often a headache with current systems such as Shopify, Magento etc.
IMO, One of the most interesting nuances in the space is the focus shift between OS and closed-source solutions in this space. The problem for larger companies (+$50M) is that they seek to build something their tech teams can take full ownership of and easily inject custom logic into. This is not as easy with proprietary solutions even if they are headless and API-first. Instead these businesses end up looking into either building something fully custom or seek out open source solutions like Medusa (JS/TS), Sylius (PHP) or Spree (Ruby) to use as a foundation to build a custom setup from.
In general though, the headless / API-first trend definitely seem to be something that a lot of companies are exploring at the moment.
Aside from the frontend flexibility, one major advantage of building API-first in an ecommerce context is that it can allow different parts of the system to be developed and maintained independently. This can make it easier to update and extend individual components without affecting the overall system - which is often a headache with current systems such as Shopify, Magento etc.
IMO, One of the most interesting nuances in the space is the focus shift between OS and closed-source solutions in this space. The problem for larger companies (+$50M) is that they seek to build something their tech teams can take full ownership of and easily inject custom logic into. This is not as easy with proprietary solutions even if they are headless and API-first. Instead these businesses end up looking into either building something fully custom or seek out open source solutions like Medusa (JS/TS), Sylius (PHP) or Spree (Ruby) to use as a foundation to build a custom setup from.
In general though, the headless / API-first trend definitely seem to be something that a lot of companies are exploring at the moment.
There's not a lot of ecom discussion on hackernews which is weird to me since that's the line of business I am in.
The trend I see continuing is the commidification and standardization of ecommerce platforms, with Shopify and BigCommerce continuing to chomp away at former giants like Magento (now Adobe Commerce). For most companies, the TCO of an ecommerce platform is an important driver in the decision making process. Companies often balk at the demands of shopify (around what you can and can't do) but then come to terms with it and select shopify as their platform.
For anyone with real budgets (like Nike.com) - totally custom, or building on a practically custom (Adobe) site, there may be moves towards the headless trends, but for the most part, the people (SMB) I deal with do not care about the technology, they just want a short time to launch and a low cost. So for me, I've seen a shift towards to low/no-code platforms and low cost. In the headless space I think fabric is particularly interesting, though I do think Adobe has a chance to do it correctly, but overall, I've sat in on several pitches for going headless and the total cost in just doesn't seem to be worth it.
The trend I see continuing is the commidification and standardization of ecommerce platforms, with Shopify and BigCommerce continuing to chomp away at former giants like Magento (now Adobe Commerce). For most companies, the TCO of an ecommerce platform is an important driver in the decision making process. Companies often balk at the demands of shopify (around what you can and can't do) but then come to terms with it and select shopify as their platform.
For anyone with real budgets (like Nike.com) - totally custom, or building on a practically custom (Adobe) site, there may be moves towards the headless trends, but for the most part, the people (SMB) I deal with do not care about the technology, they just want a short time to launch and a low cost. So for me, I've seen a shift towards to low/no-code platforms and low cost. In the headless space I think fabric is particularly interesting, though I do think Adobe has a chance to do it correctly, but overall, I've sat in on several pitches for going headless and the total cost in just doesn't seem to be worth it.
Shopify is excellent from a micro business point of view. Even coming from the perspective of a Python dev with limited FE experience, it’s so much easier for the client/business owner to administrate. I have a friend who was a Wordpress developer for 10+ years who couldn’t see from a client perspective that the technical limitations of shopify were irrelevant when compared with the hassle of Wordpress ( and it’s e-commerce plugins).
One of the interesting struggles I see in the space comes from companies that managed to grow on Shopify or BigCommerce, but then reach the limits of those platforms, and looking out into the enterprise space, they get hit with sticker shock, because there's a notable chasm between a Shopify Plus and something like Adobe Commerce or Salesforce Commerce Cloud. It's a little different when you're using those at an enterprise scale, where the cost and performance hits that come with 30+ Shopify Apps, or having to gaze into a crystal ball and give Adobe your best guess at how much infrastructure you'll need next quarter, but if you're a digitally native brand that's grown up on SaaS ecommerce, getting out of the kiddie pool usually means a big change in tech investment.
Of course, everyone in the space is scrambling to say they're headless, because commercetools has absolutely changed the conversation in the ecommerce space, but it's not some magic bullet. It's an architectural decision that should be informed by business needs, e.g. supporting multiple regions, multiple brands, or sharing one backend between your website, app, and in-store experiences. Handily, it does serve as a salve to front-end issues inherent to the all-in-one approach that was so dominant a decade ago. By decoupling the frontend from platforms like Shopify Plus or Salesforce, you get a taste of the speed and freedom that comes with a modern front-end, but also quickly run into no-go zones where even in 2022, there's no API access to important backend features - because there never will be, because that messes with the business model of these platforms.
On the bright side, even taking legacy monolithic platforms like that headless will make it easier to migrate to a more robust API-first backend solution when the time comes.
It certainly makes the most sense with the Nikes and the AT&Ts of the world. Substituting something like commercetools in for their in-house ecommerce systems offsets a huge amount of technical debt, and lets internal teams focus on being more effective at doing whatever makes Nike different from Puma. And while a digital transformation to a MACH approach sometimes has a higher up front cost, companies are clamoring to get away from the millions they spend in maintenance on versioned legacy stacks like Hybris and Salesforce.
Of course, everyone in the space is scrambling to say they're headless, because commercetools has absolutely changed the conversation in the ecommerce space, but it's not some magic bullet. It's an architectural decision that should be informed by business needs, e.g. supporting multiple regions, multiple brands, or sharing one backend between your website, app, and in-store experiences. Handily, it does serve as a salve to front-end issues inherent to the all-in-one approach that was so dominant a decade ago. By decoupling the frontend from platforms like Shopify Plus or Salesforce, you get a taste of the speed and freedom that comes with a modern front-end, but also quickly run into no-go zones where even in 2022, there's no API access to important backend features - because there never will be, because that messes with the business model of these platforms.
On the bright side, even taking legacy monolithic platforms like that headless will make it easier to migrate to a more robust API-first backend solution when the time comes.
It certainly makes the most sense with the Nikes and the AT&Ts of the world. Substituting something like commercetools in for their in-house ecommerce systems offsets a huge amount of technical debt, and lets internal teams focus on being more effective at doing whatever makes Nike different from Puma. And while a digital transformation to a MACH approach sometimes has a higher up front cost, companies are clamoring to get away from the millions they spend in maintenance on versioned legacy stacks like Hybris and Salesforce.
And i think that's where Magento should be succeeding. Frankly, Adobe Commerce minus all the AEM and other junk slapped on in the last year or two is just Magento 2 under the hood. It's flexible and extensible.
The benefit of moving to headless to me can be summed up like this: Frontend development strategies, platforms, and libraries are about as ephemeral as a fart. As online OMS systems get as complex as ERPs, it makes little sense to tie OMS capabilities to a specific frontend. That's how Magento 2's frontend got left behind 10 years. They picked something semi-popular and went all in on it (Knockout.JS) and merchants have been paying the price since (literally in terms of $).
Your OMS is going to trend closer to the ERP lifetime, but possible frontend platforms are changing at a rate that is getting shorter, so decoupling allows them to move mostly independently.
The benefit of moving to headless to me can be summed up like this: Frontend development strategies, platforms, and libraries are about as ephemeral as a fart. As online OMS systems get as complex as ERPs, it makes little sense to tie OMS capabilities to a specific frontend. That's how Magento 2's frontend got left behind 10 years. They picked something semi-popular and went all in on it (Knockout.JS) and merchants have been paying the price since (literally in terms of $).
Your OMS is going to trend closer to the ERP lifetime, but possible frontend platforms are changing at a rate that is getting shorter, so decoupling allows them to move mostly independently.
I deal with ecom a lot at work, in which we build out ecomm systems for large(er) companies.
Just about everything is going to AEM with elastic path/ some other ecomm apis and headless frontends (mostly React, namely NextJS, some unfortunately on Gatsby).
I'm not sure what is happening with all the old Magento platforms since Adobe took it over, but I don't think we do much work in Magento any more.
Just about everything is going to AEM with elastic path/ some other ecomm apis and headless frontends (mostly React, namely NextJS, some unfortunately on Gatsby).
I'm not sure what is happening with all the old Magento platforms since Adobe took it over, but I don't think we do much work in Magento any more.
I don't think Adobe knows either. Lots of people are still on Magento 2, and lots of big customers with a LOT of invested money into the platform, however the amount of people jumping into Magento is shrinking as the use case is getting attacked on both ends, on the cost for SMB and the benefits for large companies.
Having talked to adobe reps a bunch it's also they have no idea how things work and how all their tech fits together as Adobe continues to gobble up disparate technologies.
Having talked to adobe reps a bunch it's also they have no idea how things work and how all their tech fits together as Adobe continues to gobble up disparate technologies.
I worked at Magento when we were acquired by Adobe. No one at Adobe knows how all the tech fits together. The guy who championed the acquisition (Brad Rencher) left the company 6 months after that. Then w/ the acquisition of Marketo, it was the same thing all over again. My takeaway is that you coerce an organization to acquire a company you recommend so that you can gain some sort of social capital and then convert it into your next (higher level) gig
From your knowledge is it still worth trying to enter the Shopify App Store as a business pov or is too saturated?
Wondering where to focus
Wondering where to focus
I don't know. I am building custom integrations between eComm system and some niche ERPs - I haven't had a single person ask me about Magento, but many that asked me about shopify.
I’ve revisited that idea recently. with the emergence of AI, A lot of possibilities have opened up and it seems like a green field again.
This feels very much like a submarine ad for Commerce layer.
Not even a submarine ad when it literally says SPONSORED BY COMMERCE LAYER at the top!
To that point though - there's no transcript for the podcast. I try to at least describe some technical merit whenever I write a comment like this on HN, perhaps because I would hope that others would do the same if I were to arrange for sponsored content!
But I'm not going to sit through an hour of content and transcribe a quote vs. skimming a transcript to find something cool to highlight. And this isn't even getting into how the lack of a transcript signals how little the brand prioritizes accessibility!
Brands - there's no excuse not to have a machine-initiated human-edited transcript of any corporate podcast when things like OpenAI Whisper exist. Make sure the partners publishing your content are incentivized to do this as well.
To that point though - there's no transcript for the podcast. I try to at least describe some technical merit whenever I write a comment like this on HN, perhaps because I would hope that others would do the same if I were to arrange for sponsored content!
But I'm not going to sit through an hour of content and transcribe a quote vs. skimming a transcript to find something cool to highlight. And this isn't even getting into how the lack of a transcript signals how little the brand prioritizes accessibility!
Brands - there's no excuse not to have a machine-initiated human-edited transcript of any corporate podcast when things like OpenAI Whisper exist. Make sure the partners publishing your content are incentivized to do this as well.
> SPONSORED BY COMMERCE LAYER
We started building a marketplace startup earlier this year. Back then we were naive and weren't familiar with e-commerce stack (and headless commerce API), so we built everything in house (user management, inventory management, database schema, API, auctions etc.). We have a team of 7 covering across backend, web, iOS, and Android.
Are we making a big mistake re-inventing the wheel here? Would love to have some advice on this. When to build vs when to buy when it comes to e-commerce api
My biggest learning from time in the eCommerce world: trivial-sounding things are very, very difficult to get right, and the edge-cases in api-based solutions are entry-level features.
Take a single one of your items: inventory management. There's SOOO much going on here, people look and say "What's the big deal? decrement an integer!" How do you handle payment failures and dunning management? Subscriptions? Bundles? Incomplete carts? Buy online; pick-up in store? blended inventories? multiple locations? The list goes on and the number of interconnected components makes this really hard to solve.
You're building all this, a marketplace and front ends for web & mobile? With a team of 7? I had a team of 23 and struggled to stay on top of all the nuances in just subscriptions, so you're (a) missing important use-cases or (b) way more effective than my former team. Chances are it's somewhere in between.
Take a single one of your items: inventory management. There's SOOO much going on here, people look and say "What's the big deal? decrement an integer!" How do you handle payment failures and dunning management? Subscriptions? Bundles? Incomplete carts? Buy online; pick-up in store? blended inventories? multiple locations? The list goes on and the number of interconnected components makes this really hard to solve.
You're building all this, a marketplace and front ends for web & mobile? With a team of 7? I had a team of 23 and struggled to stay on top of all the nuances in just subscriptions, so you're (a) missing important use-cases or (b) way more effective than my former team. Chances are it's somewhere in between.
There's a real "it depends" flavor to any answer you'll get. If your feature set could be handled by off-the-shelf Magento with a couple of plugins, then, sure, you probably should have gone that way. But if you have unusual needs -- and Magento's rigidity means it's not hard to hit that wall -- then either you create massive technical debt kitbashing Magento or similar, or you go with one of the high-end headless systems, which are both expensive and still require you to build front- and backend solutions around them.
In turn, depending on your needs and the regulatory regimes you're working under, you may find that you could have saved time and money going with an industrial-grade solution that can seamlessly handle taxes, accounting and revenue recognition, multi-vendor logistics, credit/refunds, reverse logistics, etc. (there's a lot of etc.!), but that could be overkill for your requirements. I've seen SMBs with small digital teams build and run bespoke e-comm solutions handling all their needs (and more effectively than trying to fit a commercial square peg into a round hole), but the more complex and general their use cases, the more trouble they tend to have, especially when they get into multi-stakeholder retail scenarios (e.g., things like splitting a net-90 invoiced order between multiple future dates, vendors and warehouses, and logistics providers, while acting as a subledger that can handle revenue and income recognition properly).
In turn, depending on your needs and the regulatory regimes you're working under, you may find that you could have saved time and money going with an industrial-grade solution that can seamlessly handle taxes, accounting and revenue recognition, multi-vendor logistics, credit/refunds, reverse logistics, etc. (there's a lot of etc.!), but that could be overkill for your requirements. I've seen SMBs with small digital teams build and run bespoke e-comm solutions handling all their needs (and more effectively than trying to fit a commercial square peg into a round hole), but the more complex and general their use cases, the more trouble they tend to have, especially when they get into multi-stakeholder retail scenarios (e.g., things like splitting a net-90 invoiced order between multiple future dates, vendors and warehouses, and logistics providers, while acting as a subledger that can handle revenue and income recognition properly).
This seems like an old view of the current ecommerce landscape. Sure Magento is still an option, but as you pointed out it should only be considered for basic implementations where it can be used off-the-shelf with minimal customization.
Building a fully custom solution is the most expensive option today and really unnecessary. There is no reason to build your own product management system when so many flexible options exist. Just as I would never recommend building a server and push people towards containerization and the cloud, I recommend finding components that can be leveraged to streamline the custom build.
In terms of high-end headless systems, the market is large and growing. Some leading composable commerce SaaS offerings can offer free tiers and have pre-built front-ends and integrations.
Building a fully custom solution is the most expensive option today and really unnecessary. There is no reason to build your own product management system when so many flexible options exist. Just as I would never recommend building a server and push people towards containerization and the cloud, I recommend finding components that can be leveraged to streamline the custom build.
In terms of high-end headless systems, the market is large and growing. Some leading composable commerce SaaS offerings can offer free tiers and have pre-built front-ends and integrations.
It's worth considering a composable commerce SaaS. Many let you pick and choose the pieces you need, so you can fill out the remaining components and only replace what you built if their version brings significant value.
At this point, the answer is always buy and then build later if necessary. Just as we once questioned building a server vs using the cloud, using pre-built flexible components gets you to market faster.
Just be careful as the market right now has many monoliths and old systems claiming to be "headless" and "composable", but in reality Magento, Salesforce, Oracle, etc. are all expensive to work with and should only be considered for basic needs.
Looking at a marketplace you can consider marketplace specific vendors like mirakl and convictional, but being niche they can be very expensive. I would instead look at composable commerce solutions that are very flexible and can meet your marketplace needs.
At this point, the answer is always buy and then build later if necessary. Just as we once questioned building a server vs using the cloud, using pre-built flexible components gets you to market faster.
Just be careful as the market right now has many monoliths and old systems claiming to be "headless" and "composable", but in reality Magento, Salesforce, Oracle, etc. are all expensive to work with and should only be considered for basic needs.
Looking at a marketplace you can consider marketplace specific vendors like mirakl and convictional, but being niche they can be very expensive. I would instead look at composable commerce solutions that are very flexible and can meet your marketplace needs.
If you're building a marketplace, your SaaS offerings are more limited because the functionality diverges from B2C Retail... as you've probably (re)discovered, content moderation and approval for catalog information from your third-party sellers is crucial[0] and you'll need to solve interesting problems in promoting and suppressing search results when the business asks you to support paid partnerships with some third-party sellers as "official resellers" or sponsored listings.
Right now Mirakl is the big incumbent in marketplace APIs, but whether that's the right answer will depend on your company's scale, technical capabilities, and margins.
[0] I keep a folder of examples of unmoderated third-party seller content embarrassing large companies running marketplaces, this one is my go-to example: https://www.independent.co.uk/news/world/americas/ashli-babb...
Right now Mirakl is the big incumbent in marketplace APIs, but whether that's the right answer will depend on your company's scale, technical capabilities, and margins.
[0] I keep a folder of examples of unmoderated third-party seller content embarrassing large companies running marketplaces, this one is my go-to example: https://www.independent.co.uk/news/world/americas/ashli-babb...
I feel like this really is for like a small percentage of companies. If you're already significantly investing in developers to build out a customized front end and infrastructure dev ops, eventually you might move to invest in the back end as well.
I will likely always advocate for Shopify as long as they continue to strive to make commerce better for everyone.
As a developer, hosted Shopify is extremely powerful and enables the ability for merchants to create awesome personalized commerce experiences for their customers.
Shopify is great and if you want to start selling in minutes (literally) or do not have complex back-end requirements I highly recommend you use it. (In fact, I believe they have a sale on their plans as of the time of this comment in case you are interested in checking it out.)
As a developer, hosted Shopify is extremely powerful and enables the ability for merchants to create awesome personalized commerce experiences for their customers.
Shopify is great and if you want to start selling in minutes (literally) or do not have complex back-end requirements I highly recommend you use it. (In fact, I believe they have a sale on their plans as of the time of this comment in case you are interested in checking it out.)
Can anyone recommend a headless e-commerce platform?
I have only looked at saleor.io so far.
Shopify offers an official headless platform:
https://hydrogen.shopify.dev
https://hydrogen.shopify.dev
Headless e-commerce has been growing lately. See the MACH Alliance [1] to find out about closed-source platforms in this space. One thing to note is that we can see more and more specialization, new categories, such as headless loyalty/PIM/search etc., appeared on the market. Earlier this year, I wrote a short article [2] explaining what problems these APIs try to solve (sorry for the clickbait title).
[1] https://www.machalliance.com/members
[2] https://dev.to/voucherify/whats-mach-and-how-it-can-make-you...
[1] https://www.machalliance.com/members
[2] https://dev.to/voucherify/whats-mach-and-how-it-can-make-you...
Honest question: what is "headless" in this context? Aren't all web back-ends headless?
I think your criticism of the term is somewhat valid, in the end these are just back-ends with APIs :)
However, the point the platforms are trying to make is that their APIs have been written with the explicit purpose of building a frontend ontop of them later on.
A lot of the old-school platforms have some APIs as well, but they are meant to e.g. import products or export orders. They are not meant to implement a frontend on top of, because they have a frontend engine as part of their monolith, and many functions you need to write a proper frontend will not be available through their APIs.
So the term "headless" means "we have APIs, and they are designed for you to build a frontend on top of".
However, the point the platforms are trying to make is that their APIs have been written with the explicit purpose of building a frontend ontop of them later on.
A lot of the old-school platforms have some APIs as well, but they are meant to e.g. import products or export orders. They are not meant to implement a frontend on top of, because they have a frontend engine as part of their monolith, and many functions you need to write a proper frontend will not be available through their APIs.
So the term "headless" means "we have APIs, and they are designed for you to build a frontend on top of".
Thank you. The only usage of that term that I was familiar with was that given here:
https://www.howtogeek.com/660841/what-is-a-headless-server/
A “headless” computer system is just one without a local interface. There’s no monitor (“head”) plugged into it. There’s also no keyboard, mouse, touchscreen, or other local interface for controlling it.
https://www.howtogeek.com/660841/what-is-a-headless-server/
A “headless” computer system is just one without a local interface. There’s no monitor (“head”) plugged into it. There’s also no keyboard, mouse, touchscreen, or other local interface for controlling it.
Well said!
MVC frameworks like Django, Rails, etc, are not headless by default, as they take care of all frontend rendering.
Headless = frontend and backend are fully separated; the "promise" was to have the backend be used on multiple projects. You would have a headless backend, then a web frontend project, an iOS one, an Android one, etc without having to rewrite any backend code.
Headless = frontend and backend are fully separated; the "promise" was to have the backend be used on multiple projects. You would have a headless backend, then a web frontend project, an iOS one, an Android one, etc without having to rewrite any backend code.
So "headless" = " Web API"
I've been following https://www.shopware.com/en/ for a couple years. Awesome to see how they've grown in the space. Since it's written in PHP, I feel like it's a great replacement for Magento, especially as Adobe's catered more towards enterprise customers.
Nacelle is another. This is a very industry/salesy website, but they recommend a load of the most mature headless software platforms and integrators for stuff like ecomm and CMS:
https://machalliance.org/
https://machalliance.org/
Medusa (mentioned above) is one of the most notable in the OS space.
Of proprietary solutions Commercetools & Fabric are often mentioned among larger commerce businesses.
Of proprietary solutions Commercetools & Fabric are often mentioned among larger commerce businesses.
Saleor.io is a good start. Consider Medusa and Vendure if you want to stay open-source.
If you are interested in SaaS, look at Elastic Path.
I see a lot of people recommending the MACH Alliance. That is a marketing organization where members pay in to push their products. Nothing wrong with MACH technology, but worth understanding what it is before going down that road.
If you are interested in SaaS, look at Elastic Path.
I see a lot of people recommending the MACH Alliance. That is a marketing organization where members pay in to push their products. Nothing wrong with MACH technology, but worth understanding what it is before going down that road.
Snipcart may be of interest.
https://snipcart.com/
https://snipcart.com/
Does someone have a good introduction do micro-frontends? All I see is third-party widgets implemented using iframes or Web Components, and that is usually a nightmare for front-end performance.
Your understanding is one approach, but the composition can occur anywhere in the pipeline from SSR to client runtime composition, or in-between (example: at a CDN). eCommerce CAN be a good example, as things like the shopping cart, product catalog and recommendations split nicely on the front end without (typically) sharing backend or state. It helps to look at examples, some notable ones being the Spotify "adventure" and Dazn, as well as Ikea's overall philosophy & motivation for a variant on micro front ends (vertically segmented systems).
I’m a huge fan of headless but it’s still very much in its infancy.
The cost to implement and maintain a headless ecomm site is leagues away from a monolithic store.
Plugins that just worked with your Shopify store no longer work and require custom api dev/integration.
Want a new section built or a small thing changed? That’s going to require design and dev.
I’ve spoken to a few larger brands that have actually went back to their old monolithic store after spending hundreds of thousands switching.
The future is headless but not just yet.
The cost to implement and maintain a headless ecomm site is leagues away from a monolithic store.
Plugins that just worked with your Shopify store no longer work and require custom api dev/integration.
Want a new section built or a small thing changed? That’s going to require design and dev.
I’ve spoken to a few larger brands that have actually went back to their old monolithic store after spending hundreds of thousands switching.
The future is headless but not just yet.
[deleted]
So the people who build ecommerce websites discovered APIs? Why is this ad on the front page of HN?
Came here to say Magento is NOT now called "Adobe Commerce". Magento Commerce is now called Adobe Commerce. "Magento Community" is now called Magento. That's all. That's the comment.
Will React Server Components reverse that trend?
Amazon.com and other major online commerce players are also headless. Different, evolving front ends (think native or web views on iOS or Android, React, vanilla JS, angular, …) have a direct endpoint, which integrates with different services like product catalog, cart, checkout, recommendations).
headless is so 2010
good luck with your clunky javascript frontend
The movement towards "headless", API-first platforms has a lot of steam. So much so that older platforms (e.g. Salesforce) are jumping on the bandwagon to stay relevant in the market.
That said, I know there are a lot of startup-focussed readers on HN. This trend is for larger companies who want to really own their customer experience, including their own frontend. You'll have more flexibility, and using an API-first platform will be a lot less work than writing your own backend, but... it's still more work.
If you are small, you need a quick MVP etc. going with a Shopify or BigCommerce is the faster way to start selling. Once you've got a good stream of revenue and you're feeling these platforms are too rigid, looking for an API-first platform is a good idea!