9 ms·

The next step in ecommerce – replatform with APIs and micro front ends

96 points by djha-skin 4y ago

hn_throwaway_99 4y ago
This feels very much like a submarine ad for Commerce layer.
- JLCarveth 4y ago
  > SPONSORED BY COMMERCE LAYER
- btown 4y ago
  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.
calvinmorrison 4y ago
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.
- fein 4y ago
  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.
  - calvinmorrison 4y ago
    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.
    - sarora27 4y ago
      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
- moneywoes 4y ago
  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
  - calvinmorrison 4y ago
    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.
damienwebdev 4y ago
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.
- calvinmorrison 4y ago
  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?
  - neon_electro 4y ago
    Thank you for calling them "JavaScript developers" instead of "front-end developers"; it's accurate.
  - damienwebdev 4y ago
    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.
lagrange77 4y ago
Can anyone recommend a headless e-commerce platform? I have only looked at saleor.io so far.
- ssharp 4y ago
  Shopify offers an official headless platform: https://hydrogen.shopify.dev https://hydrogen.shopify.dev
- sebrindom 4y ago
  https://github.com/medusajs/medusa https://github.com/medusajs/medusa
- amoopa 4y ago
  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.
- intrasight 4y ago
  Honest question: what is "headless" in this context? Aren't all web back-ends headless?
  - FanaHOVA 4y ago
    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.
    - intrasight 4y ago
      So "headless" = " Web API"
  - cnj 4y ago
    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".
deleted 4y ago
[deleted]
tbassetto 4y ago
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.
- buttersbrian 4y ago
  https://micro-frontends.org/ https://micro-frontends.org/
- wintogreen74 4y ago
  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).
amoopa 4y ago
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.
cnj 4y ago
Full disclosure: I work at commercetools, another player in the space. 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!
- disantlor 4y ago
  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.
  - interstice 4y ago
    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.
jebronie 4y ago
headless is so 2010 good luck with your clunky javascript frontend
birdhouse 4y ago
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).
ushakov 4y ago
Will React Server Components reverse that trend?
angryasian 4y ago
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.
ta3411 4y ago
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
- eastbayjake 4y ago
  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-babbitt-tshirt-kmart-sears-b1880070.html https://www.independent.co.uk/news/world/americas/ashli-babb...
- HillRat 4y ago
  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).
s1k3s 4y ago
So the people who build ecommerce websites discovered APIs? Why is this ad on the front page of HN?
subtledigital 4y ago
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.
peterjaap 4y ago
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.
RobDukarski 4y ago
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.)

96 points by djha-skin 4y ago

hn_throwaway_99 4y ago

This feels very much like a submarine ad for Commerce layer.

JLCarveth 4y ago
> SPONSORED BY COMMERCE LAYER
btown 4y ago
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.

calvinmorrison 4y ago

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.

fein 4y ago
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.
- calvinmorrison 4y ago
  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.
  - sarora27 4y ago
    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
moneywoes 4y ago
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
- calvinmorrison 4y ago
  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.

damienwebdev 4y ago

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.

calvinmorrison 4y ago
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?
- neon_electro 4y ago
  Thank you for calling them "JavaScript developers" instead of "front-end developers"; it's accurate.
- damienwebdev 4y ago
  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.

lagrange77 4y ago

Can anyone recommend a headless e-commerce platform? I have only looked at saleor.io so far.

ssharp 4y ago
Shopify offers an official headless platform: https://hydrogen.shopify.dev https://hydrogen.shopify.dev
sebrindom 4y ago
https://github.com/medusajs/medusa https://github.com/medusajs/medusa
amoopa 4y ago
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.
intrasight 4y ago
Honest question: what is "headless" in this context? Aren't all web back-ends headless?
- FanaHOVA 4y ago
  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.
  - intrasight 4y ago
    So "headless" = " Web API"
- cnj 4y ago
  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".

deleted 4y ago

[deleted]

tbassetto 4y ago

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.

buttersbrian 4y ago
https://micro-frontends.org/ https://micro-frontends.org/
wintogreen74 4y ago
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).

amoopa 4y ago

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.

cnj 4y ago

Full disclosure: I work at commercetools, another player in the space. 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!

disantlor 4y ago
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.
- interstice 4y ago
  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.

jebronie 4y ago

headless is so 2010 good luck with your clunky javascript frontend

birdhouse 4y ago

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).

ushakov 4y ago

Will React Server Components reverse that trend?

angryasian 4y ago

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.

ta3411 4y ago

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

eastbayjake 4y ago
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-babbitt-tshirt-kmart-sears-b1880070.html https://www.independent.co.uk/news/world/americas/ashli-babb...
HillRat 4y ago
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).

s1k3s 4y ago

So the people who build ecommerce websites discovered APIs? Why is this ad on the front page of HN?

subtledigital 4y ago

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.

peterjaap 4y ago

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.

RobDukarski 4y ago

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.)