Alex: Okay, got 15 minutes to figure out if webhooks are dead yet.
Alex: Yesterday, actually that was on Tuesday, Vanessa kicked off the keynote and kind of middle of the
Alex: keynote, she mentions how like webhooks has been the problem for every Shopify developer.
Alex: And it's the big thing that I've been kind of a recurring theme for the last decade.
Alex: I want to quickly check whether or not that's correct. Can I get like a show and who struggled
Alex: with Shopify Webhooks or Webhooks from any other.
Alex: Okay, it looks like she was pretty close.
Alex: And who wishes Webhooks were dead?
Alex: Can I get a show in on that?
Alex: I'm about to disappoint a couple of you.
Alex: So quickly myself, I'm Alex Atixon for the French here.
Alex: I'm actually French Canadian.
Alex: I'm the CEO and also the co-founder of Hookdeck.
Alex: There's a couple people here in the team.
Alex: got Maria, Sussito, other folks.
Alex: We've got a room.
Alex: The stamp is in the room for everyone looking for it.
Alex: Otherwise, I'm not going to get any of you in there,
Alex: so I have to do something about it.
Alex: For those that don't know us, we're
Alex: trying to solve pretty much every problem around the sun
Alex: when it comes to webhooks.
Alex: But most specifically, and the reason
Alex: I'm here is for your event gateway product.
Alex: So the event gateway is a new cloud infrastructure
Alex: permitive to receive events and webhooks
Alex: into your infrastructure.
Alex: So it's part of ability, queuing, event management,
Alex: event routing, filtering, transformation,
Alex: deduplication, and so on.
Alex: And people often think we just received Shopify Webhooks.
Alex: It's actually a small but meaningful amount.
Alex: We get Webhooks from 7,000, 7,500 different
Alex: Webhook providers now, and some of the usual suspects
Alex: are gonna be Striped, Twilio, TikTok, WhatsApp,
Alex: Clavio, whatever you name it.
Alex: Some backstory.
Alex: And part of the reason why this place matters to me
Alex: is I come from the commerce ecosystem.
Alex: I was working for a big merchant
Alex: based in Montreal called Rachel.
Alex: That's like a decade ago.
Alex: Did the whole who commerce to Shopify migration.
Alex: Definitely lost couple of air in the process.
Alex: And then back then we also built a bunch of tech,
Alex: custom tech, so we had our own
Alex: homemade user account subscription management,
Alex: edless storefront, fulfillment, warehousing.
Alex: And as part of that, Webhook just became a total mess.
Alex: So we had Webhooks from Shopify, Intercom, Stripes,
Alex: ShipStation as part of making older services work.
Alex: Thank you, Joda, for the mic check.
Alex: And about that decade ago is where I discovered
Alex: the Webhook iceberg.
Alex: So back then I was mostly full stack developer,
Alex: actually started as a product designer originally.
Alex: And so I didn't know shit about dead alert cues
Alex: and in the potency and all those nice stuff.
Alex: So when you look at webhooks, you're like, oh great,
Alex: it should be post request, what can be hard about that?
Alex: And then you start getting more and more and more
Alex: and shit break and it doesn't work.
Alex: And then you wonder where the webhook went
Alex: and then you discover the whole rest of the iceberg.
Alex: So I'm here today because apparently
Alex: webhooks are no longer cool.
Alex: And now we're talking about next-gen events.
Alex: And I'm kind of joking about it,
Alex: but I think that's the best thing that Shopify could have done.
Alex: It feels like we've been talking about this for such a long time
Alex: with very minimal changes in the process.
Alex: And now it's changing everything all at once.
Alex: And so I think we have to think about it.
Alex: And if something is going to kill webhooks,
Alex: It's going to be next-gen events.
Alex: So the first thing I want to highlight
Alex: and why I think this topic matters
Alex: is because a lot of you actually have stayed away
Alex: from WebEx.
Alex: You've looked at the iceberg and you're like,
Alex: I don't want anything to do with this.
Alex: I'm just going to run some cron jobs and pull the API instead.
Alex: So I want to highlight this post on X
Alex: that Pakkar from Foxell that you guys probably know.
Alex: It was like a freaking Bible, so I
Alex: can put the whole quote on there,
Alex: but I think the part that matters
Alex: is basically the disk changes everything.
Alex: And the highlight there is that a lot of you
Alex: are about to like deal with that iceberg.
Alex: And so I wanna go through like some of the game changers,
Alex: the things that like next-gen event is truly changing,
Alex: but also some of the things that maybe are still going
Alex: to be top of mind going forward.
Alex: Number one, for those that went to the session
Alex: about next-gen events from RG,
Alex: probably know all of this, I'll try to go quickly,
Alex: but for those of you that have been living under a rock,
Alex: some of the key changes.
Alex: First, GraphQL alignment.
Alex: So the current webhook schemas are based on the old REST API
Alex: and a lot of new fields have been adding to the API.
Alex: They are not represented in the webhook schemas.
Alex: And so with this new GraphQL API,
Alex: now you get actually consensus between the webhook data
Alex: that you get and the queries that you define
Alex: for the GraphQL data that you wanna get
Alex: in response to the webhooks,
Alex: but also the original webhook data.
Alex: Sorry, no longer the original webhook data
Alex: with just like all the fields
Alex: that you didn't necessarily care about
Alex: or didn't align with the rest of the fields
Alex: that you got from the GraphQL API.
Alex: And then the second thing is that you actually get
Alex: to know what changed.
Alex: That's like a key thing people have been bringing over.
Alex: Like is it in this example, the variant price that changed?
Alex: And you can anchor your application
Alex: to react to specific changes
Alex: instead of trying to have to figure that out yourself.
Alex: The next thing I wanna highlight,
Alex: and this comes from the live stream that Taylor was on,
Alex: but already forgot everything about it apparently.
Alex: This quote from Sandish saying, "Aphrover AWS bill is consuming webhooks, queuing them
Alex: and making sure we can manage them."
Alex: This just blew my mind.
Alex: That's insane that it's such a big part of the infrastructure and the infrastructure
Alex: burden.
Alex: And they surely listened because now with the new next-gen events, you have triggers and
Alex: filters.
Alex: Triggers and filters allow you to be much more specific about the data that you want
Alex: to get.
Alex: with some configuration complexity, but at the end of the day it gives you so much more
Alex: granularity around what specifically you want to receive, and in many cases you can receive
Alex: up to 90, 95% less webhooks, and that's mainly driven by the product updated webhooks and
Alex: the inventory changes that have been extremely noisy.
Alex: Now obviously that can be a silver bullet, especially in the case thinking about you,
Alex: where you do actually want to get all the data, right?
Alex: So that only works to the extent where you don't want the data.
Alex: But ultimately, now the choice is yours,
Alex: and it's your control of what you actually want to get.
Alex: And that makes a very meaningful change.
Alex: That being said, we can't ignore the rest of the iceberg.
Alex: Because what we talked about mainly touches on the actual H&B
Alex: post request, which request that you get, what data contains.
Alex: But a lot of the challenges around managing those events,
Alex: like coming to your infrastructure, are still true today.
Alex: 15 minutes is not enough to start breaking down
Alex: what the dependency is and how to implement solutions to it
Alex: and all that.
Alex: But I want to focus on key three things.
Alex: That when I'm having a conversation with some of our
Alex: customers and users in this room, but also some of you that
Alex: are just depending on webhooks, the things that keep coming
Alex: over and over again.
Alex: One is our visibility.
Alex: Right now, it's still very difficult to know what actually
Alex: the webhooks are that have been sent to you.
Alex: In the dev dashboard, you do get a list, but it's basically
Alex: just like a static list with filters on status.
Alex: So you can't find specific product ideas for specific stores
Alex: and knowing the statistics around which topic
Alex: or during volume, which store that might not even
Alex: be a paid customer for you or sending a lot of web
Alex: book to your server, that sort of stuff.
Alex: Second, you can't actually find specific issues.
Alex: So if customer support comes through
Alex: and it's like, where the hell is this order
Alex: in the fulfillment system?
Alex: And you want to trace what actually
Alex: happened with the processing that webhook.
Alex: Right now, there's really no solution to this.
Alex: And then second is replayability.
Alex: Inevitably, U or Codex or Claude is gonna,
Alex: sorry, fuck things up,
Alex: and you might do a bad deploy,
Alex: don't process the events the right way,
Alex: need to go back in history, replay it.
Alex: You might have server outage, database connection issues,
Alex: all that sort of stuff that all ultimately result
Alex: in you having ways of being able to keep the web of payloads
Alex: and be able to reprocess them.
Alex: Second is this noisy shock problem
Alex: or for the distributed system nerds,
Alex: the noisy neighbor problem.
Alex: So when you have specific stores,
Alex: you don't actually control what they do with their stores
Alex: and the events and webhooks that it generates.
Alex: So routinely we see, for instance,
Alex: merchants that will use the ERP
Alex: and will do like full catalog sync every single morning
Alex: and will generate a million events all at once.
Alex: And that tends to be disruption
Alex: for all the other stores that you process.
Alex: Solutions to this are pretty complex
Alex: and I'm gonna talk a bit more about that later.
Alex: But ultimately, you have this trade-off of how far do you go
Alex: in the technical and architectural complexity
Alex: to solve this problem versus how much do you accept
Alex: that if one big merchant does a bulk update of all their
Alex: customers or all their prices,
Alex: that it jams up your capacity to process events
Alex: from other shops.
Alex: Last but not least, we're not just talking
Alex: about Shopify Webhooks.
Alex: We're never just talking about Shopify Webhooks.
Alex: Everyone gets Webhooks from all over the place.
Alex: There is thousands of vendors.
Alex: And especially in the Shopify community,
Alex: we see people integrating with other e-commerce store,
Alex: customer support system, inventory fulfillment,
Alex: also shipping providers like UPS and all that sort of stuff.
Alex: And so usually when you're thinking about those problems,
Alex: Shopify is maybe the biggest event source,
Alex: but it's really the only event source.
Alex: And so solutions tend to be,
Alex: you tend to be looking for solutions
Alex: that are agnostic across vendors.
Alex: Time to answer the big question.
Alex: Our webhooks is dead.
Alex: And obviously this is controversial.
Alex: Some people might not like this.
Alex: Some people might like this.
Alex: I think in the past we've seen that Shopify is pretty good,
Alex: maybe too good at deprecating stuff.
Alex: And so if I had to make a bet on the future of WebEx
Alex: as a primitive in the Shopify ecosystem,
Alex: I think the writing is on the wall.
Alex: That's my personal bet.
Alex: I have no insider information on that.
Alex: But it doesn't mean that the iceberg is going anywhere
Alex: and there's still gonna be WebEx
Alex: and the other vendors and all that sort of stuff.
Alex: So are our webhooks dead yet?
Alex: They're definitely getting a rebrand, that's for sure.
Alex: And I think when it comes to the primitive
Alex: in Shopify itself, it's very clear that you should be
Alex: applying to move to Word next-gen events.
Alex: There's gonna be huge benefits from doing that.
Alex: And I personally feel that it's something that should be
Alex: fairly high on the list of people that do rely heavily
Alex: on those webhooks and events right now.
Alex: And I think in the short term, there's a lot of benefit
Alex: gain, I think in the long term, you'll probably have to.
Alex: So what do we do?
Alex: We start testing.
Alex: It was in the workshop during.dev.
Alex: It was said that the expected release is for 2026.10,
Alex: the version API, so that we're looking at October.
Alex: Now we'll see which one of you guys
Alex: are comfortable going live with this before Black Friday.
Alex: But if you start testing now, you might actually.
Alex: And if anything, it might save your butt when you get there.
Alex: So part two is give feedback.
Alex: ArchDEEP, the PM, there has been very good
Alex: at listening to people.
Alex: A lot of folks here I know have been giving them feedback
Alex: and has definitely been listening,
Alex: has been quoting some of you the same way I am.
Alex: And then lastly, and that's the part where I sell my wares
Alex: a little bit, implement resilient observable infrastructure
Alex: that might involve us, that might involve other tooling
Alex: and whatever your cloud provider offers
Alex: and what you're currently building on.
Alex: But on that note,
Alex: (singing)
Alex: grant announcement,
Alex: I wanna announce something we've been mailing for last year.
Alex: So we've been talking to a lot of you
Alex: and that noisy shop problem is the one of the thing
Alex: that's been coming up over and over again.
Alex: And we've rebuilt our infrastructure
Alex: to be able to offer a solution to this
Alex: called Deliver Groups.
Alex: The idea of Deliver Groups is that you can configure
Alex: specific throttling rate on a per store basis.
Alex: And so what we do is from whatever the xshopify shop
Alex: domain value is, we can dynamically
Alex: create thousands of Qs and respect specific delivery
Alex: rate for specific tenants.
Alex: And so if one tenant generates-- sorry,
Alex: using tenant, one shop generates a lot of volume,
Alex: the delay is going to be strictly limited
Alex: to that specific store.
Alex: And we do that while still respecting your server capacity.
Alex: and UGDAC is responsible for fair delivery
Alex: across all the stores that have back pressure.
Alex: We also tie that in with issue notification
Alex: and Slack or incident IO or pager duty
Alex: or whatever you use to alert you
Alex: whenever there's stores causing this.
Alex: And we give you all the metrics around which store,
Alex: what the delay is, how many events is there,
Alex: how long is it gonna take for it to empty
Alex: and give you controls to change the throughput,
Alex: cancel those events, re-queue them later,
Alex: that sort of stuff.
Alex: We do have a little demo, nothing like Tube Big,
Alex: but if you want to play around with it in our glass box,
Alex: and to give everyone another incentive,
Alex: I remind you there's the stamp in there.
Alex: So someone's going to be manning the box
Alex: to stamp your sheets.
Alex: So I guess that's it.
Alex: Thank you.
Alex: [APPLAUSE]
Alex: 15 minutes to short for Q&A, but you know where to find me.
Alex: So if you want to talk about it, I'll be around
Alex: and probably at some point in the glass blocks too.
Alex: So cheers guys.
Alex: Okay, apparently I did a good enough job
Alex: and now I'm getting Q and A, so.
Alex: Does anyone have any questions for me?
Audience: Hi, thank you so much.
Audience: That was amazing, amazing talk.
Audience: Thank you for sponsoring the event.
Audience: Appreciate it, thank you.
Audience: You mentioned that Shopify tends to deprecate stuff,
Audience: which, okay, sounds good.
Audience: And so in terms of webhooks specifically,
Audience: so we have a lot of webhooks that are running in production.
Audience: And that's been the case for years now,
Audience: across our services.
Audience: And so the events API seems very interesting, it's cool,
Audience: it's the way forward, you're not getting inundated
Audience: with information you don't need,
Audience: you're getting your exact payload and so on.
Audience: And so from a realistic capacity perspective,
Audience: 'Cause there's such a core primitive,
Audience: like webhooks I don't think are gonna be going away
Audience: realistically.
Audience: So would you say like generally it would be wise
Audience: to slot in a webhooks to events, API migration,
Audience: say this year or maybe first half of next year,
Audience: what sort of timeline you think would be optimal
Audience: in terms of like not just moving,
Audience: but it's probably here to stay.
Audience: So, webhooks are probably here to stay, no?
Alex: We'll see.
Alex: I'll touch on the last thing quickly.
Alex: They're, and they've been public about this.
Alex: They're billing this as a separate system.
Alex: They got brand new systems starting pretty much from scratch.
Alex: Ask yourself, all along would you maintain
Alex: two separate systems sending billions of events a day?
Alex: All right?
Alex: All things a lot of incentive to do that.
Alex: So that's just me projecting, speculating.
Alex: Hopefully nobody in the room's mad at me for that.
Alex: And then the other part of it is that the amount of attention
Alex: and craft that's been going into next-gen events
Alex: gives me confidence that this is going to extend
Alex: to the quality of the actual operational service.
Alex: And I know they've been concerned
Alex: about webhook latency issues.
Alex: Like we have a service called IGDEC Radar
Alex: that monitors their real-time latency,
Alex: Shopify webhooks and send alerts.
Alex: And now I know that their engineering teams
Alex: is looking at it and a little bit bothered by it too,
Alex: but the point is, I know they're aware of this,
Alex: they're working on this, they're keeping attention to this,
Alex: and they've shown the attention to detail and care
Alex: that in my opinion, if you are heavily relying on it,
Alex: there's very little reasons to wait
Alex: until the point where they say it's generally available.
Alex: That's my take, maybe I'm taking the word for it
Alex: a little too much, some would say.
Alex: But from what I've seen, like Sandesh, for instance,
Alex: like reducing AWS infrastructure costs by 50%,
Alex: are you really just gonna sit on that for a year?
Alex: You know what I mean?
Alex: And so that's my personal opinion,
Alex: but everyone makes their own trade-off and calculus
Alex: on risk tolerance and so on.
Alex: Thank you.
Speaker 3: Hi, I have a question on the new feature.
Speaker 3: You were saying that you can rate limit specific shops,
Speaker 3: tenants to make sure the infrastructure doesn't buckle
Speaker 3: and the other ones are not delayed.
Speaker 3: How do you make sure that a store that every day
Speaker 3: sinks their whole inventory still gets all of the updates
Speaker 3: to you, right?
Speaker 3: If I set the rate limit too low, I
Speaker 3: might not get all of the events that they
Speaker 3: did in the morning until the next 24 hour cycle.
Speaker 3: Do you have any indicator on that on how low I should not
Speaker 3: set it so I get still everything?
Alex: Yeah, that's interesting.
Alex: Like being smart around the delivery rate and so on.
Alex: just to clarify, those rates are for the data
Alex: that we send to your server.
Alex: So a deck will accept whatever Shopify sends.
Alex: We're never gonna send Shopify,
Alex: like, oh, this was too much for this shop, right?
Alex: And so you get to set your limit.
Alex: Now we don't have anything smart in the sense,
Alex: like, oh, for this specific shop, you send it to this,
Alex: but we do send the alerts when you're
Alex: queuing to back pressure and so on,
Alex: and then you can make a judgment call on it.
Alex: I do think being smart about it, at some point,
Alex: might be good.
Alex: The problem I think with a lot of systems like this
Alex: when they try to be too smart,
Alex: they don't really do what you want
Alex: and then it takes you by surprise
Alex: and then I don't wanna take you by surprise at three in 3 a.m.
Alex: 'cause like our system thought it'd be good
Alex: if like the rate limit was higher or something like that.
Alex: So I think it's a tricky line to walk,
Alex: but I do think there's probably ways
Alex: that we can help with this, yeah.
Alex: One more?
Alex: All right, Tim.
Alex: Tim, you're a lucky guy, you get the last one.
Speaker 4: So with the current webhook system, especially with stuff like products being super noisy,
Speaker 4: if you're piping that through Hookdeck, does Hookdeck have any type of filtering?
Speaker 4: So you can do filtering there on what gets sent to your store, and also do you have any
Speaker 4: kind of data transformation ability?
Alex: You're asking me about webhooks?
Alex: Dude, they're dead.
Alex: Why are we talking about this?
Alex: No, no, yes, we do.
Alex: So we support filtering, deduplication.
Alex: Deduplication is basically the equivalent of triggers
Alex: in the sense that you can subscribe to only specific changes
Alex: in payload, and we're taking the job of figuring that out
Alex: for you, basically.
Alex: We do support full-blown JavaScript
Alex: transformation that wrote in as posposing function
Alex: on every single event that you get.
Alex: You can do content type transformation,
Alex: all sorts of different changes to the payload,
Alex: like trim them down, and all that sort of stuff.
Alex: And the other thing is everything we do is not specifically
Alex: for Shopify.
Alex: What we do works with every single event
Alex: that you get from any single vendor.
Alex: And that's why it's called delivery groups
Alex: and not shop throughput management or something.
Alex: It's trying to be agnostic.
Alex: But yes, we do.
Audience: Awesome.
Audience: Thank you.
Audience: Yep.
Audience: [APPLAUSE]