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.
> 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!
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".
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 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.
Yes. We migrated from Rackspace to GCP. When I joined the company, it was clear Rackspace was loosing the cloud race, but back in 2012/2013 it was a strong contender.
Sometimes one adopts a technology too early...
We had a longer selection process between AWS, GCP and Azure. AWS was difficult because some of our customers see Amazon as a competitor. However today we also offer the option to run on AWS. GCP won over Azure.
For my team, I'm looking for a Principal Engineer Incident Response!
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.
As the Principal Engineer Incident Response, you’ll work on challenging technical problems of an ambitious product. Depending on the time of the day, we process more than $1 mio revenue per hour. Every minute of downtime is costly for our customers, and our best features are useless if our services are not up. You’ll help new and existing product teams to detect incidents before our customers do, respond to them effectively, and most importantly learn and improve from every incident.
commercetools | Remote (EU and US) or in an office (Germany: Berlin, Munich. US: Durham) | Scala Software Engineers, Site Reliability Engineers | https://commercetools.com
commercetools | Remote (EU and US) or in an office (Germany: Berlin, Munich. US: Durham) | Scala Software Engineers, Site Reliability Engineers | https://commercetools.com