> There are lighter weight options that do basic stuff like transaction management and binding result sets to object properties that are much less of a PITA than ORMs.
Query builders like these are my personal favorite from a productivity perspective! The point of a query builder is to dynamically build SQL statements that have many subtle variations (do we want to filter by EmailID or PhoneID here? What about a subquery? Did the caller want all results, or just results where $field=X?). They're basically one level above string templating for SQL generation, and often have niceties around ser/de and transaction management as you mentioned.
Because they are primarily about query generation, it feels _very_ natural to pop off the hood and write raw queries directly when necessary. You can usually use the transaction management and ser/de parts with raw queries, too.
> If the client wants to detect custom API gateways, it can say so plainly. It can send an explicit telemetry field with documentation. It can make the policy visible. It can put the behavior in release notes.
This seems like a very naive response. If clients send explicit telemetry fields to the gateway, a malicious gateway can trivially strip or modify the field to conform to what normal traffic looks like. The steganography cat-and-mouse game is valuable because it is much harder for a gateway to continuously reverse engineer all the fingerprinting mechanisms used. Sure, some malicious gateways will be able to stay on top of things, but not all - and not always.
Huge congrats to the folks behind this at Okta, A\, Microsoft, Figma, Linear, etc...
For the MCP nay-sayers - don't worry there's something here for you too :)
This is powered by a new token format called an ID-JAG - https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a... - and isn't MCP specific at all. ID-JAGs can be used for safe and secure data sharing anywhere where data is shared between applications that use the same SSO provider.
In regular OAuth, end users consent to share their data with applications individually. This makes sense for consumer usecases, where the end users own their data. But it doesn't make sense for many business usecases, where the business is the entity that should control data sharing and access, not the end user. As an employee at Acme, I shouldn't decide to link my Acme Google Drive data to Claude or ChatGPT, that should be the decision of my IT Department.
Enterprise-Managed OAuth, or Cross App Access (XAA), brings this IT-Admin centrally controlled sharing model into the OAuth framework so it works with the existing ecosystem.
There's also a great UX benefit from moving data sharing consent management from employees to IT Admins - it means that employees don't need to sit through a bunch of OAuth flows to link their accounts together. Their IT Admin has already set up all the sharing controls. Everything plugs in together and should Just Work from day one. Think joining a new company on the first day and your Slack is already linked to your Zoom, your Drive, your Calendar, etc...
Pre-GenAI I wrote a new interview question for a role on our team. As far as I know, the question was never made public. The interview required implementing a pretty basic CSS-in-JS utility in vanilla javascript. We instructed the candidate read the MDN documentation for the CSSStyleSheet interface, and then gave them a public API to implement. Passing implementations usually consisted of a ~10 line for loop, and was really just a test of whether a developer pick up and work with new libraries on the fly. Still, the interview probably had a 30% pass rate.
On a lark, I asked ChatGPT to complete the interview question in late 2022. I would have hired ChatGPT back then based on its first response! It was easily in the 90th percentile of responses I have seen.
Is your agent harness dropping the entire MCP server tool description output directly into the context window? Is your agent harness always addig MCP servers to the context even when they are not being used?
MCP is a wire format protocol between clients and servers. What ends up inside the context window is the agent builder's decision.
Mikey might have a profit incentive at play, but let's be abundantly clear - the drivers he is catching are frequently flagrantly breaking the law and endangering both themselves and the people around them. I have a very hard time feeling sympathy for those who are unable or unwilling to operate a car safely on public roads.
> The only issue it solves is if you want to bring your own tools to an existing chatbot.
That's a phenomenally important problem to solve for Anthropic, OpenAI, Google, and anyone else who wants to build generalized chatbots or assistants for mass consumer adoption. As well as any existing company or brand that owns data assets and wants to participate as an MCP Server. It's a chatbot app store standard. That's a huge market.
I've also had drivers do 50+ in residential areas, run red lights, play on their phones, cut off pedestrians in crosswalks, and once even park in a handicap spot at a gas station to buy cigs with me left in the back seat. If I was guaranteed a driver that could obey the traffic laws, I'd be happy to continue taking Ubers. That hasn't been the case.
The initial remote MCP specification was pretty painful, but the June spec and the upcoming November spec are much more workable - MCP auth is (mostly) just OAuth now. MCP Clients are OAuth clients and can be granted access tokens and managed just like any other 3rd party app integration.
I'd love to hear more about the specific issues you're running into with the new version of the spec. (disclaimer - I work at an auth company! email in bio if you wanna chat)
Ironic that DHH is politically active enough that it affects his day to day activities and public perception of his company - kind of the exact opposite of his own policy he expects his employees to abide by.
I’ve bought several of the WAOAW sleep masks as well. They’re great for the price point - I have a nasty habit of forgetting them in hotel beds though. I tend to go through one every few years or so. My wife enjoys hers as well.
Has anyone bought the third brand to round out the discussion?
I should caveat this by saying this is certainly not 9/9/6, yeesh. Weekdays are fuzzy but never 12 hour days. Do you count going to a meetup after hours as work? A dinner with a prospect? Early coffee with a coworker? Saturdays or Sundays are maybe two or three hours at the most.
Of course we are! This year has been the most exciting (and fun!) of my career in the Bay. There is so much to do and so much going on. Things that were impossible a year ago suddenly feel imminent. Nobody is forcing (or really even asking) me to work on the weekends but if I have an interesting idea bouncing around in my brain I'm not going to wait to Monday to play around with it.
Cloudflare is only the first to market with a solution. If this proposal catches on every WAF vendor under the sun will have it implemented before the next sales cycle. Enforcement of this standard will be commoditized down to nothing.
It cracks me up to no end how the dev tools are much better MCP clients than the web chatbots. Claude Code is so _so_ much better at MCP than Claude Web, which has issues with managing DCR client state, is comparatively terrible at surfacing debug information up, doesn't let regular users see under the hood at how tools are described or called, etc.
Using Claude Code or your IDE of choice to book a hotel is a fun unintended side effect of this.
Refresh tokens are only really required if a client is accessing an API on behalf of a user. The refresh token tracks the specific user grant, and there needs to be one refresh token per user of the client.
If a client is accessing an API on behalf of itself (which is a more natural fit for an API Key replacement) then we can use client_credentials with either client secret authentication or JWT bearer authentication instead.
Query builders like these are my personal favorite from a productivity perspective! The point of a query builder is to dynamically build SQL statements that have many subtle variations (do we want to filter by EmailID or PhoneID here? What about a subquery? Did the caller want all results, or just results where $field=X?). They're basically one level above string templating for SQL generation, and often have niceties around ser/de and transaction management as you mentioned.
Because they are primarily about query generation, it feels _very_ natural to pop off the hood and write raw queries directly when necessary. You can usually use the transaction management and ser/de parts with raw queries, too.
My personal favorite in this field is knex.js.