WEBVTT 1 00:00:00.001 --> 00:00:05.500 Okay, got 15 minutes to figure out if webhooks are dead yet. 2 00:00:07.300 --> 00:00:12.540 Yesterday, actually that was on Tuesday, Vanessa kicked off the keynote and kind of middle of the 3 00:00:12.540 --> 00:00:18.200 keynote, she mentions how like webhooks has been the problem for every Shopify developer. 4 00:00:18.410 --> 00:00:21.260 And it's the big thing that I've been kind of a recurring theme for the last decade. 5 00:00:21.550 --> 00:00:27.119 I want to quickly check whether or not that's correct. Can I get like a show and who struggled 6 00:00:27.120 --> 00:00:29.860 with Shopify Webhooks or Webhooks from any other. 7 00:00:32.119 --> 00:00:34.020 Okay, it looks like she was pretty close. 8 00:00:35.640 --> 00:00:37.600 And who wishes Webhooks were dead? 9 00:00:38.230 --> 00:00:39.280 Can I get a show in on that? 10 00:00:40.840 --> 00:00:42.460 I'm about to disappoint a couple of you. 11 00:00:45.019 --> 00:00:50.040 So quickly myself, I'm Alex Atixon for the French here. 12 00:00:50.700 --> 00:00:51.560 I'm actually French Canadian. 13 00:00:52.380 --> 00:00:54.540 I'm the CEO and also the co-founder of Hookdeck. 14 00:00:54.620 --> 00:00:56.040 There's a couple people here in the team. 15 00:00:56.160 --> 00:00:57.720 got Maria, Sussito, other folks. 16 00:00:58.540 --> 00:00:59.160 We've got a room. 17 00:00:59.500 --> 00:01:02.220 The stamp is in the room for everyone looking for it. 18 00:01:02.680 --> 00:01:04.180 Otherwise, I'm not going to get any of you in there, 19 00:01:04.280 --> 00:01:05.740 so I have to do something about it. 20 00:01:07.760 --> 00:01:10.100 For those that don't know us, we're 21 00:01:10.120 --> 00:01:13.040 trying to solve pretty much every problem around the sun 22 00:01:13.120 --> 00:01:13.960 when it comes to webhooks. 23 00:01:14.100 --> 00:01:15.800 But most specifically, and the reason 24 00:01:15.920 --> 00:01:18.100 I'm here is for your event gateway product. 25 00:01:18.780 --> 00:01:21.200 So the event gateway is a new cloud infrastructure 26 00:01:21.420 --> 00:01:23.900 permitive to receive events and webhooks 27 00:01:23.940 --> 00:01:24.660 into your infrastructure. 28 00:01:25.160 --> 00:01:29.000 So it's part of ability, queuing, event management, 29 00:01:29.240 --> 00:01:31.080 event routing, filtering, transformation, 30 00:01:31.500 --> 00:01:32.520 deduplication, and so on. 31 00:01:33.160 --> 00:01:36.300 And people often think we just received Shopify Webhooks. 32 00:01:36.640 --> 00:01:40.140 It's actually a small but meaningful amount. 33 00:01:40.260 --> 00:01:44.660 We get Webhooks from 7,000, 7,500 different 34 00:01:45.460 --> 00:01:47.640 Webhook providers now, and some of the usual suspects 35 00:01:47.700 --> 00:01:49.960 are gonna be Striped, Twilio, TikTok, WhatsApp, 36 00:01:50.240 --> 00:01:51.480 Clavio, whatever you name it. 37 00:01:53.760 --> 00:01:54.240 Some backstory. 38 00:01:56.130 --> 00:01:57.860 And part of the reason why this place matters to me 39 00:01:57.940 --> 00:01:59.620 is I come from the commerce ecosystem. 40 00:02:00.100 --> 00:02:01.540 I was working for a big merchant 41 00:02:01.700 --> 00:02:02.940 based in Montreal called Rachel. 42 00:02:03.620 --> 00:02:05.060 That's like a decade ago. 43 00:02:05.660 --> 00:02:08.860 Did the whole who commerce to Shopify migration. 44 00:02:10.020 --> 00:02:11.660 Definitely lost couple of air in the process. 45 00:02:13.060 --> 00:02:15.180 And then back then we also built a bunch of tech, 46 00:02:15.490 --> 00:02:16.960 custom tech, so we had our own 47 00:02:17.840 --> 00:02:19.940 homemade user account subscription management, 48 00:02:20.680 --> 00:02:23.240 edless storefront, fulfillment, warehousing. 49 00:02:23.880 --> 00:02:27.360 And as part of that, Webhook just became a total mess. 50 00:02:27.680 --> 00:02:33.440 So we had Webhooks from Shopify, Intercom, Stripes, 51 00:02:33.720 --> 00:02:36.100 ShipStation as part of making older services work. 52 00:02:36.260 --> 00:02:37.780 Thank you, Joda, for the mic check. 53 00:02:40.720 --> 00:02:45.080 And about that decade ago is where I discovered 54 00:02:45.240 --> 00:02:46.000 the Webhook iceberg. 55 00:02:47.060 --> 00:02:48.860 So back then I was mostly full stack developer, 56 00:02:49.040 --> 00:02:50.940 actually started as a product designer originally. 57 00:02:52.300 --> 00:02:56.240 And so I didn't know shit about dead alert cues 58 00:02:56.540 --> 00:02:59.760 and in the potency and all those nice stuff. 59 00:03:00.940 --> 00:03:02.380 So when you look at webhooks, you're like, oh great, 60 00:03:02.540 --> 00:03:04.380 it should be post request, what can be hard about that? 61 00:03:04.740 --> 00:03:07.560 And then you start getting more and more and more 62 00:03:07.780 --> 00:03:09.680 and shit break and it doesn't work. 63 00:03:09.880 --> 00:03:11.280 And then you wonder where the webhook went 64 00:03:11.500 --> 00:03:13.720 and then you discover the whole rest of the iceberg. 65 00:03:15.840 --> 00:03:19.720 So I'm here today because apparently 66 00:03:19.840 --> 00:03:20.940 webhooks are no longer cool. 67 00:03:21.440 --> 00:03:23.100 And now we're talking about next-gen events. 68 00:03:24.980 --> 00:03:26.160 And I'm kind of joking about it, 69 00:03:26.300 --> 00:03:28.980 but I think that's the best thing that Shopify could have done. 70 00:03:29.640 --> 00:03:33.420 It feels like we've been talking about this for such a long time 71 00:03:33.600 --> 00:03:35.980 with very minimal changes in the process. 72 00:03:36.700 --> 00:03:40.000 And now it's changing everything all at once. 73 00:03:40.400 --> 00:03:41.860 And so I think we have to think about it. 74 00:03:41.980 --> 00:03:43.520 And if something is going to kill webhooks, 75 00:03:44.160 --> 00:03:45.080 It's going to be next-gen events. 76 00:03:47.060 --> 00:03:48.460 So the first thing I want to highlight 77 00:03:48.860 --> 00:03:50.220 and why I think this topic matters 78 00:03:50.660 --> 00:03:52.780 is because a lot of you actually have stayed away 79 00:03:52.900 --> 00:03:53.480 from WebEx. 80 00:03:53.960 --> 00:03:56.000 You've looked at the iceberg and you're like, 81 00:03:56.660 --> 00:03:57.940 I don't want anything to do with this. 82 00:03:58.520 --> 00:04:02.020 I'm just going to run some cron jobs and pull the API instead. 83 00:04:03.100 --> 00:04:05.800 So I want to highlight this post on X 84 00:04:06.100 --> 00:04:08.920 that Pakkar from Foxell that you guys probably know. 85 00:04:10.840 --> 00:04:13.260 It was like a freaking Bible, so I 86 00:04:13.200 --> 00:04:14.380 can put the whole quote on there, 87 00:04:14.490 --> 00:04:15.380 but I think the part that matters 88 00:04:15.620 --> 00:04:17.100 is basically the disk changes everything. 89 00:04:17.500 --> 00:04:19.000 And the highlight there is that a lot of you 90 00:04:19.200 --> 00:04:21.400 are about to like deal with that iceberg. 91 00:04:21.959 --> 00:04:24.440 And so I wanna go through like some of the game changers, 92 00:04:24.520 --> 00:04:26.820 the things that like next-gen event is truly changing, 93 00:04:27.350 --> 00:04:29.640 but also some of the things that maybe are still going 94 00:04:29.740 --> 00:04:31.140 to be top of mind going forward. 95 00:04:33.580 --> 00:04:35.860 Number one, for those that went to the session 96 00:04:36.160 --> 00:04:37.300 about next-gen events from RG, 97 00:04:37.480 --> 00:04:39.120 probably know all of this, I'll try to go quickly, 98 00:04:39.360 --> 00:04:41.480 but for those of you that have been living under a rock, 99 00:04:41.680 --> 00:04:42.540 some of the key changes. 100 00:04:44.380 --> 00:04:45.500 First, GraphQL alignment. 101 00:04:45.860 --> 00:04:48.460 So the current webhook schemas are based on the old REST API 102 00:04:48.840 --> 00:04:50.780 and a lot of new fields have been adding to the API. 103 00:04:50.960 --> 00:04:53.340 They are not represented in the webhook schemas. 104 00:04:53.880 --> 00:04:55.680 And so with this new GraphQL API, 105 00:04:55.880 --> 00:04:59.720 now you get actually consensus between the webhook data 106 00:04:59.820 --> 00:05:01.620 that you get and the queries that you define 107 00:05:01.840 --> 00:05:03.420 for the GraphQL data that you wanna get 108 00:05:03.500 --> 00:05:04.500 in response to the webhooks, 109 00:05:04.860 --> 00:05:06.560 but also the original webhook data. 110 00:05:07.400 --> 00:05:09.040 Sorry, no longer the original webhook data 111 00:05:09.040 --> 00:05:10.039 with just like all the fields 112 00:05:10.040 --> 00:05:11.480 that you didn't necessarily care about 113 00:05:11.600 --> 00:05:13.180 or didn't align with the rest of the fields 114 00:05:13.300 --> 00:05:14.600 that you got from the GraphQL API. 115 00:05:15.720 --> 00:05:17.480 And then the second thing is that you actually get 116 00:05:17.600 --> 00:05:18.520 to know what changed. 117 00:05:18.820 --> 00:05:20.660 That's like a key thing people have been bringing over. 118 00:05:21.060 --> 00:05:24.100 Like is it in this example, the variant price that changed? 119 00:05:24.460 --> 00:05:26.320 And you can anchor your application 120 00:05:26.480 --> 00:05:28.100 to react to specific changes 121 00:05:28.260 --> 00:05:30.460 instead of trying to have to figure that out yourself. 122 00:05:32.320 --> 00:05:33.340 The next thing I wanna highlight, 123 00:05:34.240 --> 00:05:36.680 and this comes from the live stream that Taylor was on, 124 00:05:36.740 --> 00:05:38.480 but already forgot everything about it apparently. 125 00:05:40.180 --> 00:05:45.780 This quote from Sandish saying, "Aphrover AWS bill is consuming webhooks, queuing them 126 00:05:45.900 --> 00:05:48.560 and making sure we can manage them." 127 00:05:48.560 --> 00:05:49.480 This just blew my mind. 128 00:05:50.080 --> 00:05:54.600 That's insane that it's such a big part of the infrastructure and the infrastructure 129 00:05:54.780 --> 00:05:55.060 burden. 130 00:05:56.780 --> 00:06:02.200 And they surely listened because now with the new next-gen events, you have triggers and 131 00:06:02.240 --> 00:06:02.500 filters. 132 00:06:02.940 --> 00:06:06.120 Triggers and filters allow you to be much more specific about the data that you want 133 00:06:06.120 --> 00:06:06.400 to get. 134 00:06:07.160 --> 00:06:12.460 with some configuration complexity, but at the end of the day it gives you so much more 135 00:06:12.540 --> 00:06:17.700 granularity around what specifically you want to receive, and in many cases you can receive 136 00:06:17.800 --> 00:06:23.200 up to 90, 95% less webhooks, and that's mainly driven by the product updated webhooks and 137 00:06:23.200 --> 00:06:25.260 the inventory changes that have been extremely noisy. 138 00:06:25.940 --> 00:06:30.080 Now obviously that can be a silver bullet, especially in the case thinking about you, 139 00:06:30.580 --> 00:06:32.720 where you do actually want to get all the data, right? 140 00:06:32.880 --> 00:06:35.320 So that only works to the extent where you don't want the data. 141 00:06:36.380 --> 00:06:38.060 But ultimately, now the choice is yours, 142 00:06:38.280 --> 00:06:40.360 and it's your control of what you actually want to get. 143 00:06:40.480 --> 00:06:41.840 And that makes a very meaningful change. 144 00:06:43.480 --> 00:06:45.280 That being said, we can't ignore the rest of the iceberg. 145 00:06:45.840 --> 00:06:48.540 Because what we talked about mainly touches on the actual H&B 146 00:06:48.700 --> 00:06:51.520 post request, which request that you get, what data contains. 147 00:06:52.040 --> 00:06:54.320 But a lot of the challenges around managing those events, 148 00:06:54.460 --> 00:06:56.480 like coming to your infrastructure, are still true today. 149 00:06:57.760 --> 00:07:00.519 15 minutes is not enough to start breaking down 150 00:07:00.520 --> 00:07:04.260 what the dependency is and how to implement solutions to it 151 00:07:04.260 --> 00:07:04.780 and all that. 152 00:07:04.860 --> 00:07:06.880 But I want to focus on key three things. 153 00:07:07.200 --> 00:07:08.760 That when I'm having a conversation with some of our 154 00:07:08.800 --> 00:07:11.440 customers and users in this room, but also some of you that 155 00:07:11.440 --> 00:07:14.100 are just depending on webhooks, the things that keep coming 156 00:07:14.580 --> 00:07:15.320 over and over again. 157 00:07:17.040 --> 00:07:18.440 One is our visibility. 158 00:07:19.460 --> 00:07:22.160 Right now, it's still very difficult to know what actually 159 00:07:22.360 --> 00:07:23.720 the webhooks are that have been sent to you. 160 00:07:24.140 --> 00:07:26.780 In the dev dashboard, you do get a list, but it's basically 161 00:07:26.860 --> 00:07:28.960 just like a static list with filters on status. 162 00:07:29.120 --> 00:07:32.680 So you can't find specific product ideas for specific stores 163 00:07:34.020 --> 00:07:36.260 and knowing the statistics around which topic 164 00:07:36.360 --> 00:07:38.740 or during volume, which store that might not even 165 00:07:38.920 --> 00:07:41.000 be a paid customer for you or sending a lot of web 166 00:07:41.140 --> 00:07:43.620 book to your server, that sort of stuff. 167 00:07:44.260 --> 00:07:47.020 Second, you can't actually find specific issues. 168 00:07:47.180 --> 00:07:48.660 So if customer support comes through 169 00:07:48.740 --> 00:07:50.020 and it's like, where the hell is this order 170 00:07:50.080 --> 00:07:51.100 in the fulfillment system? 171 00:07:51.500 --> 00:07:52.820 And you want to trace what actually 172 00:07:52.940 --> 00:07:54.360 happened with the processing that webhook. 173 00:07:54.440 --> 00:07:56.060 Right now, there's really no solution to this. 174 00:07:56.620 --> 00:07:58.120 And then second is replayability. 175 00:07:58.480 --> 00:08:03.720 Inevitably, U or Codex or Claude is gonna, 176 00:08:04.320 --> 00:08:05.420 sorry, fuck things up, 177 00:08:06.500 --> 00:08:08.240 and you might do a bad deploy, 178 00:08:08.720 --> 00:08:10.120 don't process the events the right way, 179 00:08:10.220 --> 00:08:11.880 need to go back in history, replay it. 180 00:08:12.000 --> 00:08:14.320 You might have server outage, database connection issues, 181 00:08:14.500 --> 00:08:16.920 all that sort of stuff that all ultimately result 182 00:08:17.180 --> 00:08:20.260 in you having ways of being able to keep the web of payloads 183 00:08:20.300 --> 00:08:21.520 and be able to reprocess them. 184 00:08:23.440 --> 00:08:26.099 Second is this noisy shock problem 185 00:08:26.100 --> 00:08:28.580 or for the distributed system nerds, 186 00:08:28.640 --> 00:08:29.900 the noisy neighbor problem. 187 00:08:31.200 --> 00:08:32.900 So when you have specific stores, 188 00:08:32.940 --> 00:08:35.479 you don't actually control what they do with their stores 189 00:08:35.640 --> 00:08:37.740 and the events and webhooks that it generates. 190 00:08:37.900 --> 00:08:39.300 So routinely we see, for instance, 191 00:08:40.200 --> 00:08:41.400 merchants that will use the ERP 192 00:08:41.400 --> 00:08:43.860 and will do like full catalog sync every single morning 193 00:08:44.060 --> 00:08:46.180 and will generate a million events all at once. 194 00:08:46.640 --> 00:08:47.800 And that tends to be disruption 195 00:08:48.220 --> 00:08:49.920 for all the other stores that you process. 196 00:08:51.579 --> 00:08:53.100 Solutions to this are pretty complex 197 00:08:53.120 --> 00:08:54.920 and I'm gonna talk a bit more about that later. 198 00:08:55.700 --> 00:08:58.540 But ultimately, you have this trade-off of how far do you go 199 00:08:58.540 --> 00:09:00.440 in the technical and architectural complexity 200 00:09:00.540 --> 00:09:02.580 to solve this problem versus how much do you accept 201 00:09:02.760 --> 00:09:05.160 that if one big merchant does a bulk update of all their 202 00:09:05.220 --> 00:09:06.680 customers or all their prices, 203 00:09:07.240 --> 00:09:09.640 that it jams up your capacity to process events 204 00:09:09.720 --> 00:09:10.440 from other shops. 205 00:09:12.420 --> 00:09:15.300 Last but not least, we're not just talking 206 00:09:15.360 --> 00:09:16.160 about Shopify Webhooks. 207 00:09:16.260 --> 00:09:18.260 We're never just talking about Shopify Webhooks. 208 00:09:19.280 --> 00:09:21.760 Everyone gets Webhooks from all over the place. 209 00:09:22.180 --> 00:09:24.160 There is thousands of vendors. 210 00:09:25.420 --> 00:09:26.800 And especially in the Shopify community, 211 00:09:26.970 --> 00:09:28.860 we see people integrating with other e-commerce store, 212 00:09:29.000 --> 00:09:31.640 customer support system, inventory fulfillment, 213 00:09:31.940 --> 00:09:35.100 also shipping providers like UPS and all that sort of stuff. 214 00:09:35.420 --> 00:09:37.720 And so usually when you're thinking about those problems, 215 00:09:38.140 --> 00:09:40.040 Shopify is maybe the biggest event source, 216 00:09:40.200 --> 00:09:42.120 but it's really the only event source. 217 00:09:42.230 --> 00:09:43.880 And so solutions tend to be, 218 00:09:44.860 --> 00:09:46.120 you tend to be looking for solutions 219 00:09:46.260 --> 00:09:47.540 that are agnostic across vendors. 220 00:09:50.040 --> 00:09:51.140 Time to answer the big question. 221 00:09:52.580 --> 00:09:53.680 Our webhooks is dead. 222 00:09:55.540 --> 00:09:56.920 And obviously this is controversial. 223 00:09:57.180 --> 00:09:58.700 Some people might not like this. 224 00:09:58.820 --> 00:09:59.680 Some people might like this. 225 00:09:59.880 --> 00:10:02.920 I think in the past we've seen that Shopify is pretty good, 226 00:10:03.000 --> 00:10:04.880 maybe too good at deprecating stuff. 227 00:10:05.380 --> 00:10:09.280 And so if I had to make a bet on the future of WebEx 228 00:10:09.620 --> 00:10:12.740 as a primitive in the Shopify ecosystem, 229 00:10:13.500 --> 00:10:14.660 I think the writing is on the wall. 230 00:10:14.940 --> 00:10:15.640 That's my personal bet. 231 00:10:15.780 --> 00:10:17.080 I have no insider information on that. 232 00:10:17.580 --> 00:10:20.640 But it doesn't mean that the iceberg is going anywhere 233 00:10:21.160 --> 00:10:22.259 and there's still gonna be WebEx 234 00:10:22.260 --> 00:10:23.700 and the other vendors and all that sort of stuff. 235 00:10:24.600 --> 00:10:25.980 So are our webhooks dead yet? 236 00:10:26.040 --> 00:10:28.080 They're definitely getting a rebrand, that's for sure. 237 00:10:28.540 --> 00:10:30.240 And I think when it comes to the primitive 238 00:10:30.420 --> 00:10:34.200 in Shopify itself, it's very clear that you should be 239 00:10:34.240 --> 00:10:36.020 applying to move to Word next-gen events. 240 00:10:36.220 --> 00:10:38.260 There's gonna be huge benefits from doing that. 241 00:10:39.439 --> 00:10:43.480 And I personally feel that it's something that should be 242 00:10:43.840 --> 00:10:46.220 fairly high on the list of people that do rely heavily 243 00:10:46.260 --> 00:10:47.600 on those webhooks and events right now. 244 00:10:48.639 --> 00:10:51.019 And I think in the short term, there's a lot of benefit 245 00:10:51.020 --> 00:10:54.020 gain, I think in the long term, you'll probably have to. 246 00:10:55.700 --> 00:10:56.960 So what do we do? 247 00:10:57.680 --> 00:10:58.360 We start testing. 248 00:10:59.440 --> 00:11:03.620 It was in the workshop during.dev. 249 00:11:04.120 --> 00:11:07.520 It was said that the expected release is for 2026.10, 250 00:11:08.070 --> 00:11:10.020 the version API, so that we're looking at October. 251 00:11:10.530 --> 00:11:11.800 Now we'll see which one of you guys 252 00:11:11.800 --> 00:11:13.740 are comfortable going live with this before Black Friday. 253 00:11:14.120 --> 00:11:18.260 But if you start testing now, you might actually. 254 00:11:18.700 --> 00:11:20.940 And if anything, it might save your butt when you get there. 255 00:11:21.060 --> 00:11:23.500 So part two is give feedback. 256 00:11:23.920 --> 00:11:26.040 ArchDEEP, the PM, there has been very good 257 00:11:26.120 --> 00:11:26.860 at listening to people. 258 00:11:27.000 --> 00:11:29.000 A lot of folks here I know have been giving them feedback 259 00:11:29.220 --> 00:11:30.120 and has definitely been listening, 260 00:11:30.280 --> 00:11:32.060 has been quoting some of you the same way I am. 261 00:11:33.700 --> 00:11:37.840 And then lastly, and that's the part where I sell my wares 262 00:11:37.980 --> 00:11:41.100 a little bit, implement resilient observable infrastructure 263 00:11:41.880 --> 00:11:44.380 that might involve us, that might involve other tooling 264 00:11:44.560 --> 00:11:46.719 and whatever your cloud provider offers 265 00:11:46.720 --> 00:11:48.240 and what you're currently building on. 266 00:11:49.500 --> 00:11:50.140 But on that note, 267 00:11:51.080 --> 00:11:51.440 (singing) 268 00:11:51.920 --> 00:11:52.520 grant announcement, 269 00:11:54.520 --> 00:11:56.900 I wanna announce something we've been mailing for last year. 270 00:11:58.740 --> 00:12:00.620 So we've been talking to a lot of you 271 00:12:01.040 --> 00:12:03.740 and that noisy shop problem is the one of the thing 272 00:12:03.800 --> 00:12:05.600 that's been coming up over and over again. 273 00:12:06.660 --> 00:12:08.040 And we've rebuilt our infrastructure 274 00:12:08.640 --> 00:12:10.920 to be able to offer a solution to this 275 00:12:11.200 --> 00:12:11.960 called Deliver Groups. 276 00:12:12.700 --> 00:12:15.599 The idea of Deliver Groups is that you can configure 277 00:12:15.600 --> 00:12:18.600 specific throttling rate on a per store basis. 278 00:12:18.930 --> 00:12:22.420 And so what we do is from whatever the xshopify shop 279 00:12:22.520 --> 00:12:25.160 domain value is, we can dynamically 280 00:12:25.320 --> 00:12:28.980 create thousands of Qs and respect specific delivery 281 00:12:29.100 --> 00:12:30.180 rate for specific tenants. 282 00:12:30.650 --> 00:12:33.000 And so if one tenant generates-- sorry, 283 00:12:33.240 --> 00:12:36.520 using tenant, one shop generates a lot of volume, 284 00:12:37.020 --> 00:12:39.220 the delay is going to be strictly limited 285 00:12:39.640 --> 00:12:40.920 to that specific store. 286 00:12:41.540 --> 00:12:43.940 And we do that while still respecting your server capacity. 287 00:12:44.320 --> 00:12:46.660 and UGDAC is responsible for fair delivery 288 00:12:46.880 --> 00:12:48.520 across all the stores that have back pressure. 289 00:12:48.980 --> 00:12:50.700 We also tie that in with issue notification 290 00:12:51.000 --> 00:12:53.220 and Slack or incident IO or pager duty 291 00:12:53.300 --> 00:12:55.100 or whatever you use to alert you 292 00:12:55.140 --> 00:12:57.120 whenever there's stores causing this. 293 00:12:57.400 --> 00:12:59.360 And we give you all the metrics around which store, 294 00:12:59.520 --> 00:13:01.580 what the delay is, how many events is there, 295 00:13:01.780 --> 00:13:03.360 how long is it gonna take for it to empty 296 00:13:03.820 --> 00:13:05.500 and give you controls to change the throughput, 297 00:13:05.740 --> 00:13:07.520 cancel those events, re-queue them later, 298 00:13:07.840 --> 00:13:08.420 that sort of stuff. 299 00:13:09.340 --> 00:13:11.580 We do have a little demo, nothing like Tube Big, 300 00:13:11.680 --> 00:13:15.440 but if you want to play around with it in our glass box, 301 00:13:17.000 --> 00:13:19.120 and to give everyone another incentive, 302 00:13:19.400 --> 00:13:21.500 I remind you there's the stamp in there. 303 00:13:21.680 --> 00:13:23.780 So someone's going to be manning the box 304 00:13:24.480 --> 00:13:25.700 to stamp your sheets. 305 00:13:29.700 --> 00:13:30.720 So I guess that's it. 306 00:13:31.220 --> 00:13:31.680 Thank you. 307 00:13:32.740 --> 00:13:33.180 [APPLAUSE] 308 00:13:40.280 --> 00:13:43.700 15 minutes to short for Q&A, but you know where to find me. 309 00:13:43.800 --> 00:13:46.600 So if you want to talk about it, I'll be around 310 00:13:46.980 --> 00:13:48.480 and probably at some point in the glass blocks too. 311 00:13:48.640 --> 00:13:49.600 So cheers guys. 312 00:14:10.080 --> 00:14:12.480 Okay, apparently I did a good enough job 313 00:14:12.490 --> 00:14:13.780 and now I'm getting Q and A, so. 314 00:14:15.240 --> 00:14:17.500 Does anyone have any questions for me? 315 00:14:22.500 --> 00:14:23.720 Hi, thank you so much. 316 00:14:23.840 --> 00:14:25.160 That was amazing, amazing talk. 317 00:14:25.340 --> 00:14:26.580 Thank you for sponsoring the event. 318 00:14:26.860 --> 00:14:27.520 Appreciate it, thank you. 319 00:14:29.220 --> 00:14:32.560 You mentioned that Shopify tends to deprecate stuff, 320 00:14:34.240 --> 00:14:35.640 which, okay, sounds good. 321 00:14:36.160 --> 00:14:39.720 And so in terms of webhooks specifically, 322 00:14:40.020 --> 00:14:42.380 so we have a lot of webhooks that are running in production. 323 00:14:43.520 --> 00:14:44.960 And that's been the case for years now, 324 00:14:45.500 --> 00:14:46.500 across our services. 325 00:14:48.420 --> 00:14:52.020 And so the events API seems very interesting, it's cool, 326 00:14:52.140 --> 00:14:54.360 it's the way forward, you're not getting inundated 327 00:14:54.400 --> 00:14:55.680 with information you don't need, 328 00:14:55.840 --> 00:14:57.560 you're getting your exact payload and so on. 329 00:14:59.360 --> 00:15:02.140 And so from a realistic capacity perspective, 330 00:15:04.160 --> 00:15:05.740 'Cause there's such a core primitive, 331 00:15:05.980 --> 00:15:08.740 like webhooks I don't think are gonna be going away 332 00:15:09.360 --> 00:15:09.740 realistically. 333 00:15:11.480 --> 00:15:14.760 So would you say like generally it would be wise 334 00:15:15.080 --> 00:15:18.840 to slot in a webhooks to events, API migration, 335 00:15:19.140 --> 00:15:23.040 say this year or maybe first half of next year, 336 00:15:23.740 --> 00:15:26.000 what sort of timeline you think would be optimal 337 00:15:26.500 --> 00:15:28.780 in terms of like not just moving, 338 00:15:29.140 --> 00:15:31.560 but it's probably here to stay. 339 00:15:31.740 --> 00:15:33.700 So, webhooks are probably here to stay, no? 340 00:15:35.440 --> 00:15:35.960 We'll see. 341 00:15:38.060 --> 00:15:39.660 I'll touch on the last thing quickly. 342 00:15:40.140 --> 00:15:43.120 They're, and they've been public about this. 343 00:15:44.140 --> 00:15:46.140 They're billing this as a separate system. 344 00:15:46.630 --> 00:15:49.980 They got brand new systems starting pretty much from scratch. 345 00:15:51.320 --> 00:15:53.580 Ask yourself, all along would you maintain 346 00:15:54.100 --> 00:15:57.200 two separate systems sending billions of events a day? 347 00:15:57.940 --> 00:15:58.120 All right? 348 00:15:59.080 --> 00:16:00.600 All things a lot of incentive to do that. 349 00:16:00.900 --> 00:16:04.060 So that's just me projecting, speculating. 350 00:16:04.380 --> 00:16:06.320 Hopefully nobody in the room's mad at me for that. 351 00:16:09.260 --> 00:16:12.240 And then the other part of it is that the amount of attention 352 00:16:12.440 --> 00:16:14.560 and craft that's been going into next-gen events 353 00:16:15.140 --> 00:16:17.680 gives me confidence that this is going to extend 354 00:16:17.830 --> 00:16:20.040 to the quality of the actual operational service. 355 00:16:20.540 --> 00:16:21.780 And I know they've been concerned 356 00:16:21.920 --> 00:16:23.920 about webhook latency issues. 357 00:16:24.140 --> 00:16:26.380 Like we have a service called IGDEC Radar 358 00:16:26.460 --> 00:16:27.800 that monitors their real-time latency, 359 00:16:28.140 --> 00:16:29.380 Shopify webhooks and send alerts. 360 00:16:29.740 --> 00:16:31.460 And now I know that their engineering teams 361 00:16:31.620 --> 00:16:33.460 is looking at it and a little bit bothered by it too, 362 00:16:33.620 --> 00:16:37.500 but the point is, I know they're aware of this, 363 00:16:37.640 --> 00:16:39.640 they're working on this, they're keeping attention to this, 364 00:16:39.760 --> 00:16:43.360 and they've shown the attention to detail and care 365 00:16:43.940 --> 00:16:47.120 that in my opinion, if you are heavily relying on it, 366 00:16:47.920 --> 00:16:49.800 there's very little reasons to wait 367 00:16:50.260 --> 00:16:52.920 until the point where they say it's generally available. 368 00:16:53.920 --> 00:16:55.880 That's my take, maybe I'm taking the word for it 369 00:16:55.920 --> 00:16:57.420 a little too much, some would say. 370 00:16:58.880 --> 00:17:01.080 But from what I've seen, like Sandesh, for instance, 371 00:17:01.320 --> 00:17:04.540 like reducing AWS infrastructure costs by 50%, 372 00:17:04.760 --> 00:17:06.860 are you really just gonna sit on that for a year? 373 00:17:07.260 --> 00:17:07.699 You know what I mean? 374 00:17:08.959 --> 00:17:10.620 And so that's my personal opinion, 375 00:17:10.740 --> 00:17:12.860 but everyone makes their own trade-off and calculus 376 00:17:13.040 --> 00:17:14.800 on risk tolerance and so on. 377 00:17:15.890 --> 00:17:16.100 Thank you. 378 00:17:20.160 --> 00:17:22.280 Hi, I have a question on the new feature. 379 00:17:22.920 --> 00:17:26.300 You were saying that you can rate limit specific shops, 380 00:17:26.620 --> 00:17:29.600 tenants to make sure the infrastructure doesn't buckle 381 00:17:29.900 --> 00:17:30.880 and the other ones are not delayed. 382 00:17:31.520 --> 00:17:33.960 How do you make sure that a store that every day 383 00:17:34.180 --> 00:17:37.060 sinks their whole inventory still gets all of the updates 384 00:17:37.240 --> 00:17:37.820 to you, right? 385 00:17:37.820 --> 00:17:39.380 If I set the rate limit too low, I 386 00:17:39.480 --> 00:17:41.300 might not get all of the events that they 387 00:17:41.330 --> 00:17:43.920 did in the morning until the next 24 hour cycle. 388 00:17:44.360 --> 00:17:48.440 Do you have any indicator on that on how low I should not 389 00:17:48.580 --> 00:17:50.320 set it so I get still everything? 390 00:17:51.080 --> 00:17:51.940 Yeah, that's interesting. 391 00:17:51.950 --> 00:17:54.360 Like being smart around the delivery rate and so on. 392 00:17:54.440 --> 00:17:57.400 just to clarify, those rates are for the data 393 00:17:57.480 --> 00:17:58.620 that we send to your server. 394 00:17:58.880 --> 00:18:01.720 So a deck will accept whatever Shopify sends. 395 00:18:02.260 --> 00:18:03.340 We're never gonna send Shopify, 396 00:18:03.700 --> 00:18:05.720 like, oh, this was too much for this shop, right? 397 00:18:06.500 --> 00:18:08.980 And so you get to set your limit. 398 00:18:09.320 --> 00:18:11.020 Now we don't have anything smart in the sense, 399 00:18:11.100 --> 00:18:13.920 like, oh, for this specific shop, you send it to this, 400 00:18:14.180 --> 00:18:15.400 but we do send the alerts when you're 401 00:18:15.560 --> 00:18:16.640