I predict that Anthropic will clamp down on the heavy agentic use of Claude Pro, the cost gap between Claude Code and this approach is HUGE...
Anyway, I'm doing the same - one extra tip is to use the "project" feature of Claude Desktop to give your coding assistant some context - use it similar to .cursorrules.
Why would they? There's already rate limits in place. If you use it too much, you have to stop for a while. Whether you're doing text extraction from large documents, having it write your memoir, or using a diy Claude Code, what's the difference?
There's also some fundamental limitations to the Desktop MCP experience that are probably never getting fixed; Claude Code can spin off subagents and play around with the context, I assume that Claude Desktop's form factor is basically going to stay the way it is until the end of time lol.
> The data exposure was discovered following an internal investigation conducted voluntarily by Kaiser Permanente. The company discovered that online trackers used on its websites and mobile applications were transmitting certain types of personal data when users interacted with its services.
I have respect for the individuals that started this investigation, and the ones that made sure this is publicly disclosed. This could have easily been swept under the carpet.
Actually, that they uncovered this on their own and publicly disclosed it sounds like they have an above-average privacy culture in place.
I know the odds that the person(s) who kicked off this investigation are reading this comment are very low, but if so: Kudos, well done!
To you and me, that's a lot of money, for Google's size that's really not a lot of money. The fact that it just became profitable certainly helps the beancounters decide to keep it around though.
Being in Silicon Valley has warped my sense of money so much.
When I read $300m, what I read is "when you factor in office costs & health care as well as salary/stock grants, an average FAANG software engineer must be ~$1m. That's only 300 employees!"
It's a crazy way to think. Suddenly all prices that end with `m` and not `b` seem pointless.
Google includes the income from paid Gmail accounts in their cloud revenue. From all accounts, that is all of the profit and in fact it generates more profit that offsets the cloud losses.
Answering your technical question: Some companies let you deploy their "building blocks" onto multiple clouds (you typically choose the exact region/availability zone), and then also allow you to build proper multi-cloud deployments. There is usually no switch to flip, but these deployments (if properly setup) should tolerate if one region/cloud goes down.
For higher level services, I can't think of an example. For the examples above, you're still thinking at VM level, whereas you typically don't do that if you purchase a higher level service.
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".
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.
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!
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.
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.
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'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.
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.
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.
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.
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.
> 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!?
> 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 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.
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).
> 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
> 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.
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).
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.
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.
I am the Director of Tech Leadership at commercetools and I am looking for Principal Engineers interested in contributing to the fast growth of our leading customizable API first (GraphQL & REST), Cloud-native (AWS & GCP), Headless Commerce SaaS processing more than $1mio revenue per hour depending on the time of the day.
If you're a trusted leader who is passionate about modern technologies, naturally curious, alway eager to share your knowledge and thriving in an international scale-up learning environment, then we'd love to build the future of multi-channel eCommerce with you!
Some of our global benefits include:
- Work Anywhere: Up to 60 days/year from a country different from your base country
- Open Learning & Development Budget
- ct Academy: Regular internal training sessions
- Flexibility: Morning person or night owl? We believe in outcome and motivated employees
- Mindset & Growth: A diverse, creative workspace with an international culture & learning environment
In my experience, a week-long rotation is much more grueling than a daily rotation. Having to stay home for a single evening/night has much less impact for me than having to do it for a whole week.
Additionally, the impact on personal live of being Oncall on the weekend is bigger. At commercetools, we recognize this by paying more for an Oncall day on the weekend (200 EUR on Fri/Sat/Sun) vs. a day during the week (150 EUR).
commercetools | Remote | Full-Time | Frontend / Javascript / NodeJS, Scala, Python, Site Reliability Engineers (SRE), Engineering Managers, Principal Engineers
Check all the open roles: https://commercetools.com/careers/jobs
For my team, I'm looking for a Principal Engineer Service Quality and a Principal Engineer Performance!
We recently crossed the threshold of 100 engineers, and are setting up a tech leadership track to enable us to grow further. By being one of the first Principal Engineers, you’ll shape the role itself and the tech leadership culture together with the Director of Tech Leadership, who you’ll report to.
Anyway, I'm doing the same - one extra tip is to use the "project" feature of Claude Desktop to give your coding assistant some context - use it similar to .cursorrules.