6 ms·

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

by 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.
  - disantlor 4y ago
    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…)
    - interstice 4y ago
      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.
jebronie 4y ago
Commercetools sits nicely between way to complicated and too rigid to do anything useful.
- bfeynman 4y ago
  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.
  - jebronie 4y ago
    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).
swalsh 4y ago
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.
- ambicapter 4y ago
softfalcon 4y ago
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?
wintogreen74 4y ago
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.
subpixel 4y ago
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.
JLuterek 4y ago
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.

by cnj 4y ago

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

jebronie 4y ago

Commercetools sits nicely between way to complicated and too rigid to do anything useful.

bfeynman 4y ago
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.
- jebronie 4y ago
  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).

swalsh 4y ago

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.

ambicapter 4y ago

softfalcon 4y ago

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?

wintogreen74 4y ago

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.

subpixel 4y ago

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.

JLuterek 4y ago

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.