In this Liquid Weekly Podcast episode, hosts Karl and Taylor are joined by Sam Isseyegh, co-founder of Discount Kit, a leading Shopify app. They explore Sam’s journey from gaming and web development to full-stack Shopify expertise. The team goes way back on Sam’s experience in web development experiences, all the way from playing Age of Empires to creating Geocities websites.
Sam shares his Shopify journey, from working on Pizza Hut’s ecommerce platform to app development, reflecting on the challenges of launching Stackable Discounts just before Black Friday. The conversation shifts to Shopify’s Checkout Extensions, emphasizing their significance, sandboxing benefits, and differences in running Shopify Functions compared to Scripts.
The power of Shopify Functions is explored further, with insights into enhancing customization and configuration using GraphQL schemas, input variables, and metafields. Sam shares tips on effectively utilizing metafields and passing settings between functions.
Explore the provided resources and links to dive deeper into the topics discussed in this episode. Don’t miss out on further Shopify insights—subscribe to the Liquid Weekly Podcast for your weekly dose of developer insights.
Timestamps
—
00:00 – Introductions
00:32 – Catching Up
07:08 – Sam’s Origin Story
15:19 – Checkout Extensions
23:21 – Differences between Checkout Extensions and Shopify Functions
26:05 – More Functionality with Functions
33:40 – Using Metafields to Pass Configurations
42:32 – Functions and Hosting
51:44 – Writing in Rust, Javascript, or Typescript
01:03:27 – In the Community
01:06:10 – Shopify Dev Changelog
01:08:54 – Picks of the Week
—
// Guest Information //
Follow Sam Online
– Twitter (X): https://twitter.com/SammyIsseyegh
– LinkedIn: https://www.linkedin.com/in/sammyisseyegh/
– Discount Kit: https://discountkit.app/
– Optizio: https://optiz.io/
// Resources //
Miro App: https://miro.com/apps/
Notion: https://www.notion.so/
Shopify Functions links:
– https://shopify.dev/docs/apps/functions
– https://shopify.dev/docs/api/functions
Checkout Extensions: https://shopify.dev/docs/api/checkout-extensions
Cart Transform API: https://shopify.dev/docs/api/functions/reference/cart-transform
Shopify Devs Shopify Functions Playlist – https://youtube.com/playlist?list=PLvQF73bM4-5W79CMjKV9GoDE58c9jS5TD&si=mQ99N-oUmMZiu7zb
// In the Community //
Collab Request default – John Speed Twitter Thread: https://x.com/John_Speed/status/1734287034133492087?s=20
DMCA Takedowns – Tobi Lutke Twitter Thread: https://x.com/tobi/status/1734345068868157547?s=46
Public Roadmap for Shopify Apps – Sam Twitter Thread: https://x.com/sammyisseyegh/status/1732095102367957490?s=46
// Changelog //
Customer Accounts Extensibility in Preview: https://shopify.dev/changelog/customer-accounts-extensibility-is-now-available-in-developer-preview
Webhook Topics for Discount Events: https://shopify.dev/changelog/introducing-webhook-topics-for-discount-events
Automatic discount functions for B2B: https://shopify.dev/changelog/automatic-discount-functions-now-apply-to-b2b-sessions
New Modal API latest version: https://shopify.dev/changelog/modal-api-added-to-the-latest-version-of-app-bridge
// Picks //
Karl – That Mitchell and Webb Look Sketch Comedy: https://www.youtube.com/watch?v=dOBhf8f7cXM
Sam – Gleam (Luey Pillford) – a new programming language that brings types to the Erlang ecosystem: https://gleam.run/
Taylor – Bicycle trainer: https://amzn.to/3vKgoNw
// Sign Up for Liquid Weekly //
Don’t miss out on more Shopify insights—subscribe to Liquid Weekly at https://liquidweekly.com/
– All right, everybody, welcome back to another edition of the Liquid Weekly Podcast. I’m your host, Karl Meisterheim, with my famous co-host, Taylor Page. Handsome as always, Taylor, good to see you. And today, we’re excited to be joined by Sam Isseyegh, who’s co-founder and app developer at Optizio.
And we’re gonna talk all things today. Check out extensions functions, it’s gonna be great. But before we get into that, Taylor, Sam, how are you? What’s going on in life? Tell us something happening. – Oh man, so well, at least for me, I’ll go ahead and start so that way,
You know, give Sam an opportunity to think about his week a little bit. But so this past couple of weeks here, you know, we’re getting ready for Christmas, right? By the time this comes out, it’ll be after kind of type thing. But we did the whole thing with the family.
We do the whole like go and get the Christmas tree thing. So growing up, we could never have real Christmas trees at home. For those of you that celebrate Christmas, you get the Christmas tree. My father was allergic to pine trees. And so we always got fake trees, kind of type thing.
And so I never got to experience the joy that is going out, picking it out and cutting it down. So I do that now with my kids, we make it a whole thing. And so that’s been a lot of fun being able to do that. It’s obviously a lot more expensive
Doing it that way as well. But you know, just try to justify it with making memories and whatnot. So from kind of work related type stuff, also was pretty excited. I got to start a kind of started this mastermind type thing. I don’t know if y’all have heard of the concept
Kind of type thing. I always sound like I feel really weird saying it like mastermind. I always think of the kids cartoon mega mind whenever I think of it. But so I’ve started this with a couple of other Shopify devs, just as a way to kind of like collaborate, work together,
Kind of help each other out, talking about the things that are and aren’t working and those sorts of things. So I’ve been really excited about that, just getting to learn from other people some more. And then, gosh, this past week, just had to put in a bunch of extra hours
To get a project over the line, got a bit on the burnt out. But I had a good long weekend to recharge, finally took advantage of, I don’t know if y’all doing this, working for yourself sometimes where you’re like, oh, it’s great ’cause I can choose what my schedule looks like,
You can choose who you work with. But then because of that, you feel this pressure to like work all the time and you don’t actually take the time off, like, oh, like I’m gonna stop at like two o’clock today and just play video games for a couple of hours
Or something in the middle of a workday, you feel kind of bad about that. But I talked to another person about that, they’re like, no, you should totally do that. Like, get over it, like, it’s fine. Like that’s one of the benefits of working for yourself.
So it was nice to take a little bit of time, recharge. So some things that have helped out with that that I’ve incorporated recently, like bullet journaling and using a project management system called Basecamp have been very helpful with just reorienting myself. And I find that whenever I’m getting overloaded,
It’s usually ’cause I’m not taking the time to set that stuff up. So, you know, back at it and doing all that fun stuff. So, you know. – I just think it’s ironic that you were talking about your love for cutting down trees and I’m wearing my reforestation T-shirt.
So I don’t know Taylor, how many trees are we cutting down here exactly? – Sorry, I was wondering how many trees do you get? Like it’s just the one. – As many as you want in theory. – I mean, you know, but they’re replanting the trees afterwards.
I like this idea though of some places where you actually just get the whole tree and then replant somewhere else. I think that’d be really cool, but I don’t know how that works. – I’m not a scientist. – We have the same plastic tree, you know,
For the last 20 years, more or less. – There you go. – My dad was careful with his money. So we still have the same tree. – That’s awesome. – At least it’s getting reused, you know? – Yeah, yeah, right. You’re not out there, you know, killing trees like me. So.
– No, no, no. – What’s going on with you, Sam? What’s new in your life? Other than putting up plastic trees. – Plastic trees. No, we, well this week we’ve had kind of a chilled week at work. So we, my colleague Dave, who’s my co-founder, we met up in London, had a big Christmas lunch, you know, beers and burgers, did some sort of project planning, wrote out the 2024 roadmap in,
And we use Miro and Notion to sort of plan out what’s coming next, really. So we had quite an easy week. I think things have died down a lot in the Shopify space. You know, this is the week before everyone goes away on holiday.
So yeah, pretty much just that on the work side. And then I’m heading off skiing to the Alps, the French Alps, first thing tomorrow morning. I’ve got a 5.30 a.m. train. And we’re taking the train for the first time actually. And I’m hoping it’s a little bit better for the environment
And it’s a little bit more comfortable than flying and driving. But yeah, so sort of getting all the bits and bobs for that ready. – How long a train ride is? Is it like, how long is that for you? – It’s not that bad. It’s, I think it’s roughly 10 hours total,
Including changing trains. We have to go from London to Paris, change train station and then onto the Alps from there on a French train. – Okay, that’s awesome. – Yeah, yeah, quite excited for that. – That’s so cool. – Yeah. – Awesome, well, welcome. – Top go skiing on the fricking Alps, Karl.
– Yeah. – My getting a Christmas tree sounds so lame now. – You can come with. – I know. – All right, I’ll be there. – I’ve got a lot of Eurocentric American things going on in my head right now, but that’s really cool. I’m glad you could do that.
I wish that we could actually go somewhere without driving our car. For me personally, life’s been good. I’ve been working on some checkout extension stuff. I didn’t get an excuse to kind of dive into that, which is nice ’cause my life has been a little code light recently
And I kind of miss problem solving, thinking through things. And the other big thing for me has just been the Liquid Weekly giveaway, the holiday giveaway. That idea came to me like a day before I wanted to start it. So I was scrambling to get everything pulled together
And I was so blessed to have so many people wanna be part of the sponsor. You know, Gadget and Anne and Trudy and Harshdeep and a bunch of other folks jumped in. And so I’m really excited for folks to take advantage of that and win some awesome prizes this season.
So see how that all sorts out halfway through. – Very cool, very cool. By the time this episode comes out, probably long over, but next time, pay attention and you can get a chance to do it. – Well, yeah, do multiple giveaways ’cause this one’s gonna go so good. – Yeah, that’s right.
– There’s a lot of really cool stuff in there for a lot of devs too. Just getting some one-on-one time with any of those people really would be huge. So very, very excited for those. – All right, well enough with the jibber jabber.
I know we’re all excited to really get to the beat of today’s talk ’cause we’ve got lots of questions on lots of interesting things to learn, I’m sure. So Sam, before we jump into the deep, deep stuff, just give us a quick 10,000 foot view of how you got into development
And specifically how you ended up niching down Shopify, the Optizio origin story, all that kind of stuff. We’d love to hear your context. – Yeah, of course, yeah. I’ve got quite a long story, sadly. So how did I get into development? I used to play a video game called Age of Empires that maybe you guys know. I don’t know. When we were growing up, that was the cool thing to do. And so I remember building websites for that.
That was sort of my first intro into web development. And when I say that, I say that with air quotes. That was sort of Geocities time, if you remember the drag and drop editors and that sort of thing. So it goes way back there. And then I actually studied geography at university.
So I don’t know, computer science wasn’t really a thing that you were pushed to do, at least in the school I was at. It was, I didn’t even know it existed, to be honest. I would have loved to have done it in hindsight, but I didn’t study computer science at university.
I studied geography and environmental economics. And actually straight out of university, I started a startup called Outingly, which attempted to sort of digitalize real life events. And that sort of went well and then very badly and sort of started software engineering roles over the next while. So I’ve worked at many very, very,
Very big enterprise companies doing mainly backend work, sometimes with really old systems, JD Edwards, if anyone, sort of green screen computing. Being lucky enough to toy with the Internet of Things projects, sort of like Amazon locker style things, Pebble Code, which doesn’t exist anymore, sadly, but that was a very cool company.
And then sort of have jumped between sort of front end, backend infrastructure sort of stuff. I met my co-founder, Dave, and our previous co-founder, also Dave, when we were working for Pizza Hut. So we helped to build their e-commerce platform that’s used all around the world.
And it sort of connects with many different point of sale systems. So yeah, I really did a bit of everything. So I think the term sort of full stack developer is, maybe not so cool anymore, but I did whatever people told me to do, basically.
And yeah, so eventually, so three and a half years ago now, we decided to start Optizio. That was sort of, we wanted to do innovative things. So we wanted to essentially be a consultancy to solve optimization problems. So where you talk about, you have a hundred million dollars
And you need to pick your fancy football team. You know, how do you pick the best options and sort of deal with those sorts of problems. And that landed us to, okay, how do we do the stuff that we wanna do? We need to make money to feed ourselves.
And we fell into the Shopify world that way and built our first app called Stackable Discounts. And about a year ago now, roughly a year ago, we built Discount Kit, our second app, which was built because of the environment change, the ecosystem changed. And we learned a lot over three years
And sometimes it’s better to start from the beginning than pivoting something. I don’t wanna say legacy ’cause it was still quite new, but yeah, sometimes it’s the better of two evils to just start again and start afresh. – Wow, that’s awesome. What a journey.
Wow, and I didn’t realize Pizza Hut was a thing in the UK. I was just showing my kids pictures of like the 1980s era Pizza Huts that I remember as a kid here in the US. – Yeah, it’s still quite popular here as a restaurant. I think people here don’t really know
That it does delivery. I think that was the whole thing they were advertising, like we deliver. – Yeah. That’s cool. – That’s awesome. Huge pivot from working for something like Pizza Hut to like now we’re working on, we’re building apps in Shopify and stuff like that.
How did y’all like, I guess, find Shopify? It sounds like you were kind of working on this enterprise level and then more so almost like scaled down to like a more of a direct to consumer kind of type model where you’re doing this kind of type thing. – Yeah, it’s a good question.
I think at Pizza Hut, it was e-commerce driven and there were some really cool things and processes that we had set up. So you have the website and the orders flow through to the kitchen and the point of sale. I think we had sort of a very SlackOps heavy ops environment
So every five minutes there was, this number of orders went through, here’s the experiments that were running at these percentages and this is the conversion rate and this is the average order value and this is the KPIs we care about. And so you were really like pushed to,
Hey, come up with your own experiment, push it live to 5% of people and see what the figures say. And so it was quite a good intro to e-commerce. It was fun, like that’s not legacy. I should say it’s sort of, they call it Pizza Hut digital ventures
So it’s like an internal startup type of thing, not the old sort of world. So we actually kind of thought, we built this tool called Dealbot. I say we, I mean, there’s a whole team behind that. That sort of tried to bundle up products for you.
So you put a pizza and a side and a drink into your car and it goes, hey, that’s a bundle, that’s 10% off. – Nice, it’s really handy. – Oh yeah, but I mean, when you shop, if you always get the best deal, you build this trust with the site, with the shop.
And so it did wonders for the conversion rate, that sort of thing. And so we were thinking, can we do something more generic for every store? We were kind of, we had kind of some bad experiences, some good experiences. And we were looking around the internet, we said, oh, Shopify does some things
In a completely different way. That’s super interesting. It has a big ecosystem. There’s such thing as a Shopify partner. Most other ecosystems didn’t have that. So yeah, it was our first attempt really. And then it just, it went really, really well. I think we launched just before Black Friday
Without realizing the drama that would ensue. And like, I think we launched a proof of concept, right? So it had very little functionality and pretty much every single shop that installed. And we were getting a lot of installs because stackable discounts back in the day, three years ago, back in the day.
– Yeah, that’s huge. – It was a high-stake reward. And so we got a load of installs and it pretty much didn’t work for every single shop. And so we were firefighting, how do we fix it for this specific theme and this specific merchant?
And we pulled all-nighters for like two weeks, I think, to just get, to survive without getting a one-star review. That was tough. That was a tough intro, but we learned a lot, obviously. – Right, baptism by fire, for sure. So in the Shopify space and app development,
In some sense, app development’s essentially been the same for a long time. There’s been a lot of changes, but it’s been relatively similar. But the paradigm shift seems to have come more recently with the introduction of checkout extensions, sensibility, and then also the introduction of functions.
So I’d love to chat with you a little bit more about that. Let’s kind of focus in first, maybe on checkout extensions. How do you approach that in terms of your work? Where do you guys see opportunities there? What are some of the cool technical things you’re learning as you push into that?
– Yeah, I think there’s a lot to go over on that just by itself, but I mean, it’s a big change from the old world where, as a plus store, you could edit your checkout.liquid. And these are currently plus-only features, really, the checkout extensions. So that is important to note.
This isn’t something new that every store gets just yet. But it is a very nice change from having to go in and look through sometimes quite massive checkout.liquid files where there’s– – Fight through someone else’s JavaScript that they hacked together on checkout. – No JavaScript with no processes or no tests, no structure.
It’s a bit like the Wild West, really. From a software engineering perspective, you have no idea who’s been there before and what happens when you touch this. And it’s the checkout. The checkout is the most important part of the funnel. If you screw up the checkout, you’ve lost, you’re throwing away money.
You’ve convinced someone to buy it by that point. So getting it right is important. So I think that’s, for me, the most important thing is the sandboxing. So these checkout extensions, they’re all sandboxed and they run in service workers or web workers, sorry. And you can’t mess things up as easily, I think.
It’s very locked down. So they provide certain JavaScript APIs to you, so like fetch and some storage APIs, but you don’t have access to the DOM. You can’t manipulate the DOM. You can’t do arbitrary things. And I know that’s upset certain people in the ecosystem and maybe rightly so,
Is a change in the way things are done. But I think overall, it is a good thing. Now you can run, you can just write a React component. And the UI components are built for you. You don’t have to be a fancy designer. You can just be a developer
And Shopify has built these incredible set of small Lego blocks for you to kind of add together and build your own experience. And then it integrates natively with the branding API. So it looks, you know, your, how do you say, sort of the roundness on your buttons and the color scheme, all just,
You get all of that out of the box and you go, that’s much better than writing arbitrary, random JavaScript, you know. – Yeah, the consistency there, or I think the biggest, one of the biggest selling points with checkout extensibility, you know, in addition to that consistency, right,
Was we also now have access for that to like, those customizations to reach like shop, like shop pay, which before like checkout.liquid, that was a big thing I found out when I was first working on Plus jobs. I’m like, okay, great. Like, let’s do this on checkout.liquid,
Shop pay rolls up and then I’m like, well, hey, like none of these, you know, customizations we’re doing are showing up here. And I was like, that’s not, it’s not accessible that way. And so now it is though. So that’s a huge, huge benefit.
I don’t know if you could speak maybe to that a little bit as far as the pros and cons of to checkout extensibility. You’d mentioned this too. There’s, I’ve seen a lot of like pushback also from other app devs in the space who are basically like,
You know, hey, like this really is a step back kind of type thing. And I think, you know, in some areas, yes, but is there anything that you’ve seen that’s really been a step backwards, you know, outside of some of these like little things as far as,
Oh, well, like now we can’t manipulate the DOM the way that we used to kind of type thing or whatever. Are there other like significant, I don’t know. Are there other significant changes with updating, migrating from checkout.liquid to checkout extensibility that you’ve noticed? – I don’t think I’ve personally,
Or like our team has personally run into any of those big blockers. I think we did consult from a very high level with someone who wanted like a map component in there. And I think they actually released that already. So I think, you know, the team’s pretty on the ball.
They have the foundation of remote UI, which was released. And it’s used by, you know, not only Shopify, it’s used by Stripe as well to do their injections of, you know, outside components. And I haven’t really, to be honest, a lot of it is just time.
I think you’re always gonna get, like you say, my specific scenario is not possible anymore. – Yeah, people that didn’t update, you know, to support checkout extensibility, you know, kind of type thing that are now mad about, they haven’t been on the ball with that or whatever.
– I haven’t run into that, so I’m not angry, you know, but if I had, I would probably have a different opinion, you know. – Now, have you had, and I don’t know, I’ll have to link this up in the GitHub repo, ’cause I’ve run into this where we, especially around Black Friday,
We were trying to run some automatic discounts, right? You know, kind of type thing or whatever, and running in discounts. Have you had that as a feature request where we could hide, like the current, like discount input at checkout? I don’t know if you’ve heard that from merchants,
Mainly because of like how it interacts with, hey, like our automatic discount, we just don’t want them to be able to add discounts at checkout kind of type thing, you know. So I don’t know if you, there’s an open GitHub issue on it for that to be added
To checkout extensibility as an option, but right now it’s not. And we used to be able to do that with checkout.liquid. So. – Yeah, so there are little things, yeah, like we said. I think it almost, and I can’t remember specifically on the discount field, but yes, the answer is many, many merchants
Have asked us that over the last three and a half years. – You’ve probably run into that a lot. – Oh yeah, because, well, especially with stackable because stackable allowed you to add a discount code and it would change the rules of how it was applied.
So, you know, there was a cart or cart slider input fields that we would add. And then you have this awkwardness where you had another one at checkout. And actually I believe plus stores used to be able to like toggle it off. And then I believe it also doesn’t show
If you don’t have any manual codes by default. So. – Correct, yeah. – I think there are some caveats around that. And yeah, that’s definitely come up many times in, yeah. But I feel like that’s not a new problem. That’s like a problem that’s been there for a while.
– Yeah, without some manipulation, you couldn’t. But now at the moment, checkout extensibility, there’s no way to touch it. ‘Cause like you said, like we can’t manipulate the DOM the way that we used to kind of take things. – Right, and I think that’s the kind of thing
That it would be nice, you know, for Shopify just to add an option, you know, and keep it as simple as that. It should just be a setting. And this is my personal opinion, right? You know, things like that should be settings, you know, natively. – Agreed. – And they shouldn’t be
DOM manipulations by random developers. Just my opinion, you know. – Yeah, yeah. – I think at that point, it’s as simple as, you know, allow people to toggle it off or not, you know. – Right, yep. Move away from that wild, wild west of checkout.liquid.
We just need, like this should just be a setting, you know. – Yeah, yeah. – 100%. – Yeah, there’s this difference between, you know, functions and checkout extensibility as well, because they’re two different things really. But– – Yeah, did you wanna go over maybe the high level, the differences as far as,
’cause I get that question a lot as far as, you know, when are we reaching for like an extension? What are functions, you know, ’cause we’re having to migrate, you know, stuff either way, like in any of these instances, right, where we were doing stuff in checkout.
So I don’t know if you can talk a little bit about that or maybe some things that y’all have found where this is actually better, we can get away with some things in extensions instead of checkout functions or whatever. – Right, yeah, I think there’s one example
That comes to mind, which is blocking checkout codes, discount codes at checkout. So with old scripts, I believe you could actually block a specific discount code from being added and also write a custom message, for example. I think that’s quite a desired feature. But then you look at, you know,
If functions are the replacement of scripts, but you can’t do that in functions, you know, where do you do that? And I think the answer is likely, can you do something like build your own discount input field that you have full control over to a degree, you know, it’s a React component,
And then can you hide the other discount entry field, which, you know, links the two problems together, obviously, you know, it’s a little bit. But, you know, it’s sort of like to get like functionality, you kind of need both. The functions don’t work full stop unless you’re on the new checkout regardless.
So you need to have upgraded, but you can use scripts, you know, in both worlds. So just to add more complexity, you know. – Yeah, yeah, yeah. And that’s what you’re, so you’re saying, you know, we’re safe to use, we can have upgraded checkout or be on checkout.liquid
And still use scripts, we’re safe there or whatever, but functions, you have to have migrated at that point. – That’s right, yeah, yeah, exactly. And yeah, I mean, functions is great because I like really functions looks like, or sorry, it is, you know, scripts v2, you know.
So there’s a lot of people saying, why are you taking scripts away? You know, scripts v2 is functions. So they’re not taking it away, they’re just changing. And if you look at the functionality, you can already see there’s way more functionality in functions than there is in scripts.
It’s just removed, you know, really loved features, I guess, which is unfortunate. – Well, can you give an example? What do you mean by like, there’s more, there’s more functionality with functions than what are things that we can do with functions that we couldn’t do with scripts before?
– Oh, that’s a good question. I’m probably gonna say something silly, but I think like, the, you know, the cart transform API is a great example. – I’m glad you’re bringing that up. ‘Cause I’ve seen people talk about it and I need to like read up on it.
And I’m like, I need somebody to explain to me what’s happening here. ‘Cause it seems there’s a lot of cool stuff in there. – I think I’m more excited for the future of cart transforms personally, you know, what they add to it eventually. So one example of a missing feature with the upgrade
Was the ability to change the price of a cart line to a specific price. So you could do that in scripts, line item scripts with, I think, I believe that was one of the functions available to you. You can’t do that necessarily in a function, a discount function specifically.
You could dynamically calculate the amount you wanna discount each line and do it that way. That would work. There are some other caveats there that I won’t go into right this second, but yeah, it’s the kind of thing where it used to be there and now it’s not.
And then they’ve just released a new cart transform called update, which is now in developer preview. So it’s not live in production yet, where you can update the cart line directly. And so instead of doing it with a discount function, which would have been most people’s first thought
Of where you would do that, or where you would have that functionality, it’s now a cart transform called update, and you can update a specific cart line and you can update the price and the title and the description. So yeah, there is definitely this world where functionality doesn’t feel
Like it’s in the same place, but it is there and it will eventually surpass those types. So like the expand and the merge functionality and the new bundles APIs, and they’ve even added storefront functionality there with the line items. Sorry, I forget how you say it, how they’ve called it in the API,
But you get sort of what’s in a line, what are the line parts, that’s the one. So you can build really nice user experiences with Liquid that directly link up with your function, which is something really cool, I think. So there’s definitely a bigger story there.
There’s also stuff like that I’ve seen order routing with that I don’t think existed before, which I think is a very specific plus focused functionality or feature for big stores. Like I think Unilever that might have many big stores around the world and they have different warehouses and things like that.
And so it improves their sort of experience. I think there’s the cart valid, sorry, I’m talking a lot guys. – No, no, no, you’re saying good stuff. So, you know. The cart validation stuff is also really good. And again, that sort of interacts really nicely with the UI in checkout, you know,
So you can put a message in it and it shows there. So I think there’s stuff that feels better integrated. It might be less functionality at the time being, but I think you’ll look back on it and it will be, oh, this is so much better, you know, one year down the line.
– Sam, I have two questions for you. One comment, first of all, my first comment is I really wish they’d made it possible to do this in Ruby, not just JavaScript. ‘Cause I was thinking like most of the lines– – I was waiting for you to start ragging on it being in JavaScript.
– No, no, I’m not ragging on it. I enjoyed it because there was really no other Ruby outlet in the theme sort of line space. Anyway, I have two questions for this. One is, one of the things that’s really bothered me sometimes about line item scripts is the properties
That are or are not available on the different objects that you can interact with like line items, variants, products, and things like that. Just certain fields, if you like, that would be obvious to have this in here, just aren’t in there. In functions, what have you found to be the case?
Do you have access to a lot more of the properties and data on line items and products and variants and things, or is there still some weird limitations of what you can find in there? – Oh, really good questions. I think I’ll answer the second one first.
So the way that it works in the functions world, and all of the functions are similar, not exactly the same, is you start with a GraphQL schema. Instead of just here’s some documentation about what you get and you have access to it directly, here’s this huge schema of information,
Which you can interact with as a GraphQL API. So you have the whole API available to you. And then what you do is you write a query on that schema, or against that schema, sorry. And you basically say what information you want. So I want the product ID,
But I also want the variant description or whatever it might be. And that allows you to keep the data that comes into your function really, really limited whilst giving you a lot of power. There are limitations in terms of, and this is, I think, classic Shopify
Where they’ve done quite a complicated rate limiting in the admin API with the leaky bucket algorithms and stuff. They’ve again got, you can create a GraphQL query worth this number of points, the down points. And each piece of data you ask for is worth a point or something like that.
And then some pieces of data are more expensive than others, sort of nested information. And that’s really great. And the second part to that is you have this great feature called input variables. So you don’t have to just statically write this input GraphQL query. You can pass it information, for example,
A list of collections that you wanna check if line items are a part of. So if you query a product, you have this cool GraphQL function you can have, it is in collection. You kind of have similar features, but you need to dynamically pass that list of collections.
So you have sort of a way to pass arguments to the GraphQL query to really narrow it down as well. So I think there’s a lot of, it’s different. It’s not the same, but you can get a lot of information. You also have access to metafields
On pretty much every resource, including the shop resource, which means technically you can put any data you want in there and access it, which is way more powerful than what you had before, which was car attributes, which was, then you’re getting into stringifying objects
And then, yeah, I don’t even wanna talk about that. – I’d be really interested to hear a little bit more too. And I think we had, this is a question with passing, you’re talking about like accessing data and stuff like that. But as far as like passing settings and configuration back and forth,
Using stuff like metaobjects or something like that, or metafields or whatever, I don’t know if you can talk about maybe benefits of that, as well to some degree, or maybe how y’all are leveraging that. ‘Cause there’s a real push right now, even on Shopify is in, right?
Where they want app devs to be using metaobjects, like essentially as their database, right? You know, like let that be like where you’re hosting all your data kind of type thing or whatever kind of type thing. So is that something y’all have explored or do you have any like input there
As far as maybe how folks could start looking at doing that within their own app? – Yeah, absolutely. I think so the main way to pass configuration to functions is through metafields actually. So generally a function, and this is not true for all functions yet,
But I believe they will all be like this. They all have an owner resource type. So, you know, if you run a discount function, there’s a discount node and that discount node is the owner of the function. I forget a payment customization and these types of things, what their owner is,
But there is always an owner and that owner can have a metafield associated with it. And so normally you would set up the configuration. So when you write a function, the way I’ve liked to describe it before is you can think of it like a class. I personally hate object-oriented programming,
But if you think of it like a class and you describe when you create a function, you describe, you know, the interface for it. You say what data can come in, what the output’s gonna be. And then when you actually go in and using discounts or payment customizations,
When you actually go and create one, you’re kind of creating an instance of that class, right? Of that function type, your new unique creation. And how do you pass, you know, the individual configuration to each of those instances? So if I create, you know, in discount kit, for example,
We have an order goal discount, which is a tiered discount based on the order subtotal. So it’s quite simple, but the configuration when you create one of those is, you know, tier one, you need to hit this amount of money and you get this percentage off.
So all of that data lives on the meta field of the discount node, so they can kind of live together. Now, it’s a really interesting point you make, because, you know, what we also want to do is show that data on the front end, on the storefront.
So we have a little message that says, “Hey, if you spend, you know, 20 bucks more, you get 10% off your basket.” And you want to gamify it and do that sort of thing. And that’s where it gets interesting, because if what you did instead, and this is not something we currently do,
We do it in a different way, but I’ll simplify. If you, instead of storing the configuration on the discount node, in this example, you store it on the shop resource, you now have access to that in Liquid. And so you can read the discount configuration
Or the payment customization or whatever it might be in Liquid directly, you know, at compile time of the theme, so like on the server, right? So it’s much nicer, a much nicer way to interact with data. So yes, and the way that you do the input variables
Actually is also in the function configuration, you specify the key in the namespace of a meta field that you’re going to pass that data into. So it is very based, meta fields are important, you know, that’s how it works actually. And yeah, I think it’s a great thing.
There are pain points around that as well, but like always, there are always pain points. – Right, right, right, right. So it feels like this world is fairly complex for folks that aren’t already familiar with it. And a lot of things that are being added and changed and getting into developer preview
And graduating everything, where is your sort of go-to source for the most up-to-date information about what’s actually available and documentation-wise? – Yeah, I mean, you guys have been around a while. I mean, the documentation for Shopify has just got so much better in the last three years,
Like you can’t even describe the difference. I think the documentation for functions especially is really, really good. So shopify.dev is my go-to. So if you go to the function APIs part of the dev site, you’ll kind of get all of the function types that exist. And then within that, you kind of have,
You have a GraphQL interface and then also an overview. The overview kind of describes what the limitations are, what it actually replaced. So normally those questions are actually answered. In line item scripts, I used to be able to split the lines of a specific line into two lines, for example,
And then discount only one of them. How do you do that now in functions? It kind of describes, oh, you would use a discount function. And if the discount amount is different on the two lines, Shopify will split them for you, for example. So that’s all kind of available in the overview docs.
And then the GraphQL references is obviously important for seeing what input you have. I think this is where having a typed language, or using TypeScript for functions or Rust for functions is really useful because actually, I mean, I do look at the documentation site, absolutely. But a lot of the time,
If you’re just kind of noodling around, if you just click dot and then you get what’s next and then you get the type of it, it’s a really good way to explore the documentation. So I’d say the type definitions that are available with, they have two actual sub packages.
So they have a function Rust. Okay, don’t quote me on the names. And the function JavaScript. And they’re both like helper packages, really. The Rust one, for example, comes with like a GraphQL client that looks at your schema and your query and auto generates the types for you,
Which is lovely ’cause now you have the full API typed in code. Again, there are negatives with that as well, but you get the same thing with TypeScript, out the box with the starter kit, you get an NPM or Yarn type gen command
That looks at your input query and it looks at the schema and it automatically creates the TypeScript types for you. And so, it’s kind of a chicken and an egg problem because to get the types, you need to touch the query. So you do need to look at the doc,
But I mean, sort of a week later or further down the line, you don’t really need to even go to the docs. You can kind of just click through and see what the types are. – Well, that’s what I was gonna ask you.
Yeah, so you’re talking about like how helpful the docs are, it sounds like, which I’m primarily a front end guy kind of type thing, but anytime I’m touching anything back end GraphQL related, that seems like most people’s recommendation is like just start poking around in the Explorer or whatever kind of type thing.
And that seems to be the best way to kind of surface what you’re needing. Do you think that’s pretty accurate? – Yeah, I think so. I think in this case, you do really need the docs to actually see the input. The input is small, right?
Relative, it’s nowhere near the size of like the admin API, which has thousands of resources. You have an input, which is generally the cart, the identity of someone, the localization. So what market are you in? You get access to all this information. You choose what you want.
Yeah, I think you need the documentation to come up with the query. And then from then on, you can kind of explore. But like if you use TypeScript, for example, they don’t just give you, oh, it might be there or it might not be there. They give you it like properly typed.
So they have a maybe type, for example. So you can actually like really understand what’s going on. So it’s really like the TypeScript definitions are really well typed, for example. – Nice, well, and I think this is kind of pertaining to both extensions and functions here. ‘Cause so, and I’m not sure how,
What Karl’s been digging into with checkout extensions, but most of the checkout extensions that I’ve been writing have been for folks I’m working with one-on-one that are plus brands. So with that, we have this option where we can do extensions only, checkout extensions, right? So it’s just hosted directly by Shopify.
And so we’re building some settings in at checkout or whatever, where they can add different things or whatever kind of type things. And so I’ve experimented a little bit with using metaobjects then for us to like, surface, you know, different little things that we need to do. But with functions, I mean,
Those aren’t hosted at all by Shopify. We don’t have that option, right? It’s not like we weren’t running, excuse me, like with Shopify scripts, you know, we’re just, we’re doing all of that within Shopify. But if we’re talking about functions, like we’re, you’re having to go hosting on your own completely, aren’t you?
– That’s a good question. I think there is an important, you know, distinction between the two worlds. Like, yeah, you’re completely right. I think the, I think they call it appless hosting of checkout extensions is really cool. And if I’m completely honest, I don’t know exactly what can be a headless extension
Or not. – Yeah, well, yeah, ’cause you’re building public apps. So it’s not like, you’re not having to dig into the minutiae there. But I don’t think there is, that’s what I’m saying is I don’t think there is a way to host functions directly from Shopify.
I think you have to go an app route. – Yeah, potentially a custom app. I don’t know the answer to that, honestly. So I won’t say the wrong thing. – Yeah, sure. – I think regardless, it probably will be coming anyway. So like we have done custom functions for people,
For plus stores, for different merchants. And the way we’ve tended to do that is either through one of our existing apps, so like Discount Kit or Stackable. And we just deploy a hidden discount function if it’s a discount function. But you could technically still do this.
So for example, you create a custom app. And I hope the answer isn’t like that you can do it. Then this sounds silly, but you could create like a custom app and you can create the functions programmatically with GraphQL. So you don’t really need to go through the whole
Building an app for there to be a page. So we have done discount functions that just have the configuration as code, for example. And so you can set up a GitHub action or something to continuously deploy that. And you’ve got your function, which is exactly how scripts work, right?
You have your code and you, okay, you have a nice GUI or editor to do it, but you could just write things locally in your development environment with all the tools that you like, and then push it up to GitHub. And then you have source control and auditability
And all of these other really lovely things that Git gives you. So yeah, again, it’s sort of, there are pros and cons and trade-offs, but you can technically do it without building a UI and without building an app. And we have done that for some people. I think there’s an interesting thing here,
Which is for checkout extensions, for example, specifically, you have the settings in the app.toml or the extension.toml, sorry. – Right. – And so you can kind of feed data in from that settings and you get the UI built for you, right? So you can say, I want a piece of text
And the merchant or a marketing member of their team might change that text over time and your React component can use that data straight away. So it is really powerful. With discount functions, as an example, just because that’s what we write every day at Discount Kit, it’s a little bit more complicated
Because if you want it to be written as code, you can write the configuration as code. There’s no problem with that. There’s nothing wrong inherently with that. But if you want, say, your marketing team to be able to go and change the tiers at a later date, then you do need a UI.
And so you need some sort of app bridge UI. My gut feeling is what will eventually happen if it’s not already being built by Shopify is they will have some sort of, you specify the settings in a toml file and they build out a UI for it
Because that’s what kind of makes sense. That’s what I would do in that situation. So if we’re thinking about it a year after they’ve started this thing, they’ve definitely thought of all this stuff. – Yeah, they’ve definitely. And that’s good. I learned something there, obviously, ’cause I’ve just been telling people,
Yeah, functions, we need to go, we need to get in there. Or we’re building something custom or whatever. So you’re saying basically there is a way to do it now, but in general, I mean, I’m still gonna like, leave that up to people that really know their ways around functions.
I’m not gonna touch that or whatever, but you’re saying basically it’s possible probably down the road, something else is gonna get built out similar to what we’re doing maybe with checkout extensions now for extensions only plus people. So that’s awesome. – Yeah, I think there’s also, that’s available to plus stores again.
So only plus stores can create custom apps that have functions. So that’s a specific limitation. Like you can’t have functions on a custom app for a non plus store. So it’s interesting, ’cause then you have the app side of things. So like DiscountKit, at DiscountKit, we just released the custom discount.
And the purpose of that is to make something that’s generic enough that, you don’t have to go and write your own function, but it’s not, I think there’s a balance because we tinkered with the idea of building our own script editor, because why not? It seems like a very obvious idea.
But in reality, most people what they do when they write a Shopify function is they go and copy and paste an example and then tweak a few things. That’s the reality of what people do. – Yeah, absolutely. – So it’s like people don’t actually wanna write the code
And maintain it and there’s a cost to that. So we’ve tried to replicate how we thought about writing discount scripts and build it into a UI. And then you have an app and there is a cost associated with that. And maybe it’s a little bit more expensive
Than some other apps, but you’d have to weigh up against, are we gonna pay a developer to look after this or are we gonna- – Well, I was supposed to say like, yeah, what you’re gonna end up paying a dev, and so that doesn’t make sense in a lot of use cases.
– Right. – Yeah, for sure. So yeah, we’ve tried to kind of go, okay, what do you do when you’re writing a discount function? Like the first thing you do is you try and look through the cart lines and go, which are the specific products I care about?
And so you have that sort of grouping of the cart lines part. So that’s sort of step one. And then what’s your algorithm that you wanna do? Is it a buy X, get Y, up to a certain limit or whatever that code you might write.
So can you build a little GUI to handle that logical bit? And we’ve got pretty far with it, not all the way, but yeah, it’s definitely possible. And yeah, if Shopify eventually releases some sort of way to create a form essentially from configuration,
Which they kind of already do, if you think about it with the app theme extensions and the checkout extensions. Yeah, it kind of feels like a no brainer and that will just happen eventually. And then your life will become easier, I suppose. – Yes.
– Sam, I don’t know if you can answer this question ’cause I don’t know your background, but are you a Rust developer at all? – Oh yeah, yes. I think I would consider myself a Rust developer now. I mean, we built our backend for stackable in Rust.
So three and a half years ago, but that was the introduction to it. But we’ve been running Rust in production for the last three and a half years. – Well, and so, but when writing functions for discount kit, we’re not using Rust, we’re using TypeScript.
– Well, that’s why I was about to ask him. I was just curious, since you were able to see both sides of it, when this first came out, it was Rust only. I think that was a big stumbling block for a lot of developers ’cause Rust is still
A little bit of a niche language for a lot of people. But now that you see both sides of it, do you see any reason to do the work, to get up to speed with Rust if you’re not already in that spot to do this work?
Or do you think they’re pretty much equivalent in terms of the benefits they bring to the extensions and functions? – That’s a really good question. You guys are coming out with the good questions today. I’ve spoken about this with Dave, my co-founder, so much, because there is a massive benefit
To writing everything in TypeScript or JavaScript, if that’s your flavor of choice. And the whole rest of your program is in that language. That’s brilliant because you can reuse code on the storefront, you can reuse code everywhere. So there’s a real benefit to it.
But like everything, there are trade-offs and pros and cons. And it’s really interesting ’cause Rust is a statically typed compiled language and JavaScript or TypeScript is dynamic and you need some sort of interpretation of that. – Right, so there are two different things and I’m not a compiler developer.
So please take what I’m saying as like very high level things, but in Rust, for example, you can have generics. And I believe they call this monomorphization. I probably said that really wrong, but it’s where you take like a generic function and you create many monomorphic instances of it.
So imagine you had a function that could take a string or a number instead of like what it would turn that into is like two functions, one that takes a string and one that takes a number. And so you get these massive, massive performance gains because it’s basically just a bunch of lookups
With like in comparison to like dynamically dispatching and however, all these other things work. And so there’s a trade-off. So you get way, way, way more performance, but you get a way bigger binary size. So, one isn’t better than the other. You might need to use Rust for the performance, right?
So JavaScript has an untyped or dynamically typed language, I should say. It’s really hard. It’s not that you can’t build compilers for dynamic languages. I believe there are examples of that being done. I’m not that aware of this stuff, but it’s much harder if you don’t have typing to build a native bundle,
A native binary that is really actually performant. And so when you think of writing something that needs to go into a fast performant WASM file, JavaScript is not the first language that comes to mind. And you can see that in the results when you test this stuff, if you generate something with WASM
And something with Rust and something in JavaScript. And I’ll talk specifically about discounts as an example, because we’ve done most of our testing there, where you normally care about the cart lines. So, how many cart lines are there? That’s sort of the bounds of your algorithm.
That’s the thing that’s gonna make a difference. So, if you have a hundred cart lines or 200 cart lines, from my testing, most of the most simple algorithms that you could possibly write, the TypeScript or JavaScript one is handling 20, 30 cart lines. The Rust one’s handling 100, 150, 200,
If you write performant code. And so it really depends. How likely is it that a lot of customers have really big cart lines, carts? I mean, if it’s B2B, it can be up to 500. Even the Rust functions probably would not be preferable there. So, yeah, I think you gotta be smart.
And I think there’s a difference here in the different function types that are available. So, I’m saying this from the discount function, whereby your algorithm, whether it’s a Biot-Sketch Y that you’re trying to create or whatever it is, you take the cart lines as input and you do something,
You probably have to iterate over them. So, that’s much more performance heavy than say a payment customization, which might just be a configuration, which doesn’t care about the number of cart lines in most cases. It might, but in most cases, as an example. So, in that case, you definitely should just use
Something like TypeScript if you don’t write Rust or you don’t understand Rust, there’s no need. If you want to write something that deals with large numbers of cart line items, you probably wanna use Rust, right? And the other point is that it doesn’t have to technically be Rust or JavaScript.
That’s just what Shopify supports out the box. You can write AssemblyScript if you wanted, you can write Haskell if you wanted, you can write a lot of other languages that do have compilers into Wasm. But again, they have these problems with the binary sizes tend to be really, really big.
And actually the JavaScript binary sizes are too big out of the box. And what Shopify have done is really clever. They’ve written this essentially compiler called Javi that pulls out the runtime, the JavaScript runtime, and it’s created like a Wasm runtime that imports the JavaScript things that you would normally use.
And so with Javi, you can write a TypeScript function that’s only a kilobyte or two kilobytes in comparison with a Rust one, which might be 200 kilobytes or 250 kilobytes. But then the performance, I mean, there’s the performance impact. So, yeah, I mean, there are geniuses working on this at Shopify.
If you look at the code they’ve released on Javi, for example, and they’ve also got one called Ruby, which is a Ruby to Wasm compiler. So they might do- – Oh, this is it. Girls, I’m bored now. – My personal opinion is that’s probably quite a long way away.
And it looks more like a proof of concept. But I mean, if they did it, if they could do it with JavaScript, they can probably do it with Ruby. – They can probably do it with Ruby. – You know, yeah. And then Taylor’s happy and Karl’s happy and everyone’s happy. – Everybody’s happy.
I don’t know if Taylor cares, but Karl’s happy at least. That’s what this podcast is all about. – Yeah, all my Ruby and Rails questions go to Karl. So, you know, as long as I’ve got JavaScript, then I can keep my questions to a minimum. – Oh, nice.
I mean, Ruby was the first programming language I learned ever. – Really? That’s awesome. – I used to love it. I used to really love it. I just never, we built our first startup in it and then I never used it after that really. – It’s one of many tools, I’ll say that.
It’s a good tool, but it’s not the only thing out there. – Of course, yeah. – Nothing about open-minded. Wow, that’s great, Sam. That was a real nice deep dive and I really appreciate the insight you provided there. Taylor, we’re getting to that part we probably need to transition,
But I also want to give you the benefit of, is there anything else you really need to dig into with him? – No, I mean, I think, I mean, we spent a little bit of time like touching on TypeScript. We didn’t get really dig it too much into TypeScript versus JavaScript.
And we did, sorry, Harshdeep. One listener submitted question that really does have to be asked because it does sound like you are a huge TypeScript fan and it gets a little spicy between folks sometimes. So that is our one question that we wanted to make sure we asked on here was,
When are you moving from TypeScript to the much superior language, JavaScript? That was our question and I asked it in the way that it was typed, so. – Yeah, nice. I mean, honestly, the truth is I don’t have anything spicy to say. The truth is I don’t really care. People have their preferences.
They do, people have their preferences and what you’ve programmed in for many years is gonna be your preference. I totally get and respect that. So no hard feelings. I would say, having things typed when you, so using functions as the example, right? So if you started with JavaScript from scratch,
You’d get the input variable into your function and then what you’re gonna guess, what’s available to you. And the truth is, is the answer is no, you won’t have to guess because you’re probably using VS Code and VS Code is running TypeScript under the hood and it’s giving you these squiggly lines
And these type completions. And so like most people are probably using TypeScript as a tool, it is a tool that is useful. So I mean, you can use it or not use it. It’s, personally, I feel a little bit naked when I write vanilla JavaScript now, it feels wrong. It feels dangerous. I mean, like there’s very few times- – I guess I’m still on the wild west side. I still stay pretty vanilla, but maybe it’s because I don’t know TypeScript well enough to see the benefit to start holding it in, but. – Yeah, I mean, like for me, I’ve written programming,
Sorry, I’ve written software in many different programming languages. So a lot of those are typed and what I tend to do is, I tend to, when I think of an idea or something, I tend to write out the types as a step one.
And then a step two is I sort of scaffold the functions. So I write the type signatures of all the functions that I’m gonna write before I’ve even started writing the code. So for me, doing the types upfront is a way of simplifying things and you describe your interface beforehand.
And I’ve got used to writing code that way for the last however many years. And so, but for me, it’s like, I would be doing that even if I was writing JavaScript, I would write an example object, step one, what is my input? Defining that, the documentation for maintainability,
For readability, for dealing with other developers, there are real benefits to it. It’s yeah, maybe it’s not everyone’s cup of tea, but. – Right, well, and so for you, it’s almost like describing a process of you’re almost building out the mental model beforehand. And then that helps you basically just be more efficient,
Not only when you’re building it out, but also later on down the road when it comes to maintenance, right? And really helpful when working with other devs too, which. – But you always do this in all walks of life, right? You never go into the detail as a step one.
You think like, what’s my high level strategy? How am I gonna get from A to B? I’m gonna take the train. Okay, how do I take the train? And then eventually you get to the low level stuff. So I think that’s the way I think about programming anyway,
Is like, once you get into the, oh, how do I write a for loop, right? And you’re describing the how, and it gets very, very difficult. So it’s much easier if you just take a step back really. That’s just my personal preference that everyone works,
Has a different brain and works in a different way. – Yeah, yeah, yeah, yeah. Well, speaking of different brains, Tyler, do you wanna go on to the next section here, which is what’s happening in Shopify space? Thank you, Tim. That was so awesome. – That was a super great transition, Karl. Well done.
– Nice. – Love it. – Nice. – And also, the narrative choice. So I’ll go ahead and I’ll share my screen. I’ll try to roll through these ’cause per usual, thankfully we’ve got lots of fun stuff that we were able to talk about today. Can you all see my screen okay?
– It’s getting late and Sam’s gotta go skiing in the Alps. – Yeah, he’s gotta go skiing. – Let’s not keep him longer than necessary. – So real big thing in the Shopify, in the community section. Karl, I miss your soundboard.
I admit, I made fun of you at first, but I miss it. – I’ll bring it back. – So the collab requests have now become the default. And so there is a little bit of an outcry in the app dev community. John Speed, who has always really great insights
On Shopify, had just posted a thread just talking about benefits, pros and cons, some feedback from other devs. Y’all can check it out. And basically just kind of responding to Glen Coats’ message, the kind of type thing. Before collab requests, unless the merchant goes in and turns it on, by default,
Literally anybody can pop open a store. They can check out the My Shopify from your partner account, you can request access. And so this was not helpful for some stores who might be bigger, who are getting slammed with a bunch of collab requests. And so this was done as a way
To prevent that from happening. Some folks aren’t happy about it. So pros and cons, everybody’s got some opinions on either side of the table, but a real interesting thread there. John’s always got some really good insights. And then Toby also released another follow-up. We’ve been talking about these DMCA takedown issues
And stuff for, I feel like a while now, mainly because it’s a big issue in the space. So Shopify has changed how they are responding to this with a whole bunch of updates and how that goes. So just even from the get-go in the admin.
So real helpful video, we’ll link that up as well there. So I did have a thing here too, ’cause Sam posted this poll. I wanna make sure it went in the community section too, about a public roadmap for Shopify apps. And so for people who are kind of interested in the feedback there,
I think there’s some good insights from other app devs too, in addition to Sam’s got some good takes on that too. So I would recommend folks checking that out if they are building in the space. And so, is that, y’all are moving forward?
– It’s good to see you kind of put him in a tough spot there. – Well, I think that was, it was like more so, that was the concern, right? Like the people in the poll were answering, yay, but all the other app devs are like, don’t do it.
So, I think there’s just some interesting stuff there. So I thought that that was pretty neat, but so yeah. And then I don’t know if we wanna go into the changelog. I know we’re getting a little bit long here. – Pick your favorite one. – Pick your favorite one. Just one.
Oh my gosh, this is hard. – That’s nice. Pick your favorite two. – Well, gosh, you’re gonna make me choose. Okay, so as far as some fun stuff, there’s some other stuff I’ll link up in the show notes and ’cause Sam actually was hoping we’d have time
To weigh in on some of these, some new webhook topics for discount events. I thought that that was interesting. That’s probably something that’s been on y’all’s radar. And then there was also a new modal API that was added to the latest version of AppBridge, where it’s, let’s see, it’s replacing,
It’s a replacement for the previous full screen API. So you’ve got basically a modal that you want to display as an overlay, prevents interaction with the rest of the app until it’s dismissed. That has just been recently released as well. So something that was interesting. We’ll make sure to include the other stuff
In the show notes as well for you folks here, just so you’re aware of the newest and greatest kind of things that are available. – Well, newest today. – Newest today. – It’s been a month now. – Well, you know, not everybody’s watching the change log,
You know, so we want to make sure people are using the new stuff. – The webhook for discounts is a massive one. It’s been missing for, yeah, forever. So it’s the one resource that never had that sort of webhook topic. So that’s a big deal.
– Yeah, which you’d think that would be huge. So it’s whenever a discount has been created, updated, deleted, or deleted. So that way can make sure to keep stuff in sync. – For functions, this is a big deal as well. If you create discount functions,
Because you have no idea if a discount’s been deleted or deactivated. So it’s not only, yeah, it’s the updating of them as well. And so, you know, what we’ve done and what I’m sure many other apps have done is build a synchronization system, which is always way more complicated than it should be.
– Wow, yeah. So this is gonna simplify things for you. – Oh yeah, it builds half of the infrastructure. So that’s good. – Nice. Just like a coding clutch. – Yeah, and the B2Bs for discounts is also a big one. I think there’s a lot of B2B DTC hybrid stores
That wanted discounting and more powerful discounting and they couldn’t use it before. So, you know, lots of happy merchants there as well. – Nice. – Yeah, that’ll be huge too. That was also in my changelog. Karl was making me cut it out, so I’m glad you snuck it in there.
Bam, ticked him off. – I’m sorry, people have other things to do. – Move on to the picks. – After breaks must be had. Yeah, pick of the week. All right, Taylor, you go first. Well, I’ll go first ’cause you just talked. – I’ve been talking a bunch, man. Yeah, you go. – Just sitting here waiting for my, here’s my moment.
All right, my pick of the week, and this is great ’cause Sam’s here and he’s in the UK, is there’s a sketch comedy group called That Mitchell and Webb Look. It was popular, is probably still popular in Great Britain. They came out around 2006.
I think you could correct me on all of this, Sam, ’cause you obviously are in that culture, but I think their sketches are, on the whole, rather hilarious, and there’s always some hits and misses, but if you like sketch comedy and enjoy some good British humor, check them out, they’re on YouTube.
Well, they’re probably a more official place, but you can find some clips on YouTube. – Yeah, this link video has over two million views. – I know, it’s pretty funny stuff. – That’s crazy. – Nice. – Yeah, I mean, it’s the first, these guys are the first people, you know,
If people come and move to the UK for university or whatever, I say, and they go, you know, like, how do you teach British humor? It’s like, these guys are right up there, you know. – That’s awesome. I need to watch this now. Need to understand my UK friends better. That’s fine.
How about you, Sam, what’s your pick? We’ll make Taylor go last. – Yeah, I’m last. So I didn’t read this, so I didn’t know I had to come up with something, but there is a cool project a friend of mine, Louis Pilford is working on, and it’s a new programming language called Gleam
That brings types to the Erlang ecosystem. So the Beam virtual machine, which is really, really cool. And so check Louis out and Gleam out. – Is it Elixir type? – It is, yes, sorry, you’re correct. – Okay, yeah. But some people still wanna use Erlang. I don’t know enough about this space.
I’m probably sounding stupid to people who do. – So Elixir is dynamically typed, I believe. I’m not sure. – Oh, is it? – Yeah. – I paid for a course on Elixir, and I’ve taken half of it, and it’s been four years. I still get reminder emails every Saturday.
Hey, you’re 10% with your course. Sorry. – Although you like Ruby, right? So it’s- – Well, that’s why I looked into it, ’cause a lot of, yeah, it’s like, you know, the elves in Middle Earth sail to the West. A lot of Ruby developers sail to Elixir.
So I was kind of looking into that. – Yeah, I think Louis was telling me the last time I spoke with him, there’s a PhD student that’s actually writing a Gleam to WebAssembly compiler. And so I was like, oh, you know, when that’s ready,
We’ll migrate all of our Shopify functions over to Gleam. And so that’ll work. – Nice. – Yeah. – Fancy- – So Taylor, since I didn’t give you a chance to, you can pick a change log for one of your picks of the week if you want, if you didn’t get them all.
– I can cut off, but I don’t wanna mix the massive sections too much. And Sam had my back. He snuck it in there. So it’s all right. – Thank you, Sam. – But so my pick of the week is gonna be, I got a bicycle trainer.
So for those of you that aren’t familiar with a bicycle trainer, it’s basically a way that you can ride your bike indoors kind of type thing. So it’s getting colder and I need a way to do that ’cause I don’t wanna be out running or biking
In my local area when it’s 10 degrees out. Yeah, it’s super nice out today. I’m pretty jazzed about that. – But in general. – But so I need to get another tire for it, but Thomas Kelly from Archetype Teams thankfully recommended like, ’cause I was telling him about this
And he was like, you need to get a bit different back tire, but it is so loud. I got this because it was specifically like a relatively quiet one. So I could ride it just in my office, you know, kind of type thing. But my office in my house is located
Underneath my daughter’s room. And I got this in the mail from Amazon. I was super excited and I hooked it all up and I started to pedal on it ’cause the kids had just gone to sleep. It was so loud. My daughter woke up and was like, “What was that sound?”
I was like, you know. And so I need to get a different tire for it so it’s a little bit quieter, but I’m excited to be able to be a little bit warm and not have to go somewhere to ride my bike. So bicycle trainer. – Amazing.
– Well, guys, this has been great. Sam, my bind. I was gonna take notes and at some point I just couldn’t keep up but I said, “You know what? “I’m just gonna have to listen to it again.” – Let’s record it. – Take notes afterwards. – Yeah, we’ll record it.
I did, didn’t I? Oh yeah, good. Now we recorded it. We really appreciate you taking the time out, especially right before your big holiday. And hope you don’t mind if we follow up with some more questions on Twitter or whatever, ’cause there’s so much there to explore and you have so much knowledge.
Thank you. – Oh yeah, absolutely. Any questions, shoot me over. And thanks for hosting and thanks for creating, you know, Liquid Weekly Podcast. ‘Cause, you know, we didn’t have these sort of resources really in the ecosystem. So it’s really, really fantastic to see all the other videos, you know,
All the big names in the ecosystem and then little old me. – Big names. Now that’s Sam saying we’ve got the big names. – Not the big names. – That’s right. – Not what I meant, I don’t know. – All right, well, thank you so much. Taylor and Drew, we’re weak to you and we’ll catch you guys on the next one. Until then, stay liquid. – Stay liquid. – We got a couple of stuff, we need a tagline. All right, see you guys. – I like stay liquid. [MUSIC PLAYING] you
1 Comment
Reject TypeScript, embrace ECMAScript 👨💻