[{"data":1,"prerenderedAt":441},["ShallowReactive",2],{"footer-primary":3,"footer-secondary":93,"footer-description":119,"enter-the-workshop-setting-up-ab-testing-posthog":121,"enter-the-workshop-setting-up-ab-testing-posthog-next":174,"sales-reps":189},{"items":4},[5,29,49,69],{"id":6,"title":7,"url":8,"page":8,"children":9},"522e608a-77b0-4333-820d-d4f44be2ade1","Solutions",null,[10,15,20,25],{"id":11,"title":12,"url":8,"page":13},"fcafe85a-a798-4710-9e7a-776fe413aae5","Headless CMS",{"permalink":14},"/solutions/headless-cms",{"id":16,"title":17,"url":8,"page":18},"79972923-93cf-4777-9e32-5c9b0315fc10","Backend-as-a-Service",{"permalink":19},"/solutions/backend-as-a-service",{"id":21,"title":22,"url":8,"page":23},"0fa8d0c1-7b64-4f6f-939d-d7fdb99fc407","Product Information",{"permalink":24},"/solutions/product-information-management",{"id":26,"title":27,"url":28,"page":8},"63946d54-6052-4780-8ff4-91f5a9931dcc","100+ Things to Build","https://directus.io/blog/100-tools-apps-and-platforms-you-can-build-with-directus",{"id":30,"title":31,"url":8,"page":8,"children":32},"8ab4f9b1-f3e2-44d6-919b-011d91fe072f","Resources",[33,37,41,45],{"id":34,"title":35,"url":36,"page":8},"f951fb84-8777-4b84-9e91-996fe9d25483","Documentation","https://docs.directus.io",{"id":38,"title":39,"url":40,"page":8},"366febc7-a538-4c08-a326-e6204957f1e3","Guides","https://docs.directus.io/guides/",{"id":42,"title":43,"url":44,"page":8},"aeb9128e-1c5f-417f-863c-2449416433cd","Community","https://directus.chat",{"id":46,"title":47,"url":48,"page":8},"da1c2ed8-0a77-49b0-a903-49c56cb07de5","Release Notes","https://github.com/directus/directus/releases",{"id":50,"title":51,"url":8,"page":8,"children":52},"d61fae8c-7502-494a-822f-19ecff3d0256","Support",[53,57,61,65],{"id":54,"title":55,"url":56,"page":8},"8c43c781-7ebd-475f-a931-747e293c0a88","Issue Tracker","https://github.com/directus/directus/issues",{"id":58,"title":59,"url":60,"page":8},"d77bb78e-cf7b-4e01-932a-514414ba49d3","Feature Requests","https://github.com/directus/directus/discussions?discussions_q=is:open+sort:top",{"id":62,"title":63,"url":64,"page":8},"4346be2b-2c53-476e-b53b-becacec626a6","Community Chat","https://discord.com/channels/725371605378924594/741317677397704757",{"id":66,"title":67,"url":68,"page":8},"26c115d2-49f7-4edc-935e-d37d427fb89d","Cloud Dashboard","https://directus.cloud",{"id":70,"title":71,"url":8,"page":8,"children":72},"49141403-4f20-44ac-8453-25ace1265812","Organization",[73,78,84,88],{"id":74,"title":75,"url":76,"page":77},"1f36ea92-8a5e-47c8-914c-9822a8b9538a","About","/about",{"permalink":76},{"id":79,"title":80,"url":81,"page":82},"b84bf525-5471-4b14-a93c-225f6c386005","Careers","#",{"permalink":83},"/careers",{"id":85,"title":86,"url":87,"page":8},"86aabc3a-433d-434b-9efa-ad1d34be0a34","Brand Assets","https://drive.google.com/drive/folders/1lBOTba4RaA5ikqOn8Ewo4RYzD0XcymG9?usp=sharing",{"id":89,"title":90,"url":8,"page":91},"8d2fa1e3-198e-4405-81e1-2ceb858bc237","Contact",{"permalink":92},"/contact",{"items":94},[95,101,107,113],{"id":96,"title":97,"url":8,"page":98,"children":100},"8a1b7bfa-429d-4ffc-a650-2a5fdcf356da","Cloud Policies",{"permalink":99},"/cloud-policies",[],{"id":102,"title":103,"url":81,"page":104,"children":106},"bea848ef-828f-4306-8017-6b00ec5d4a0c","License",{"permalink":105},"/bsl",[],{"id":108,"title":109,"url":81,"page":110,"children":112},"4e914f47-4bee-42b7-b445-3119ee4196ef","Terms",{"permalink":111},"/terms",[],{"id":114,"title":115,"url":81,"page":116,"children":118},"ea69eda6-d317-4981-8421-fcabb1826bfd","Privacy",{"permalink":117},"/privacy",[],{"description":120},"\u003Cp>A composable backend to build your Headless CMS, BaaS, and more. \u003C/p>",{"id":122,"slug":123,"vimeo_id":124,"description":125,"tile":126,"length":127,"resources":8,"people":8,"episode_number":128,"published":129,"title":130,"video_transcript_html":131,"video_transcript_text":132,"content":8,"status":133,"episode_people":134,"recommendations":161,"season":162,"seo":173},"65956c5e-17ae-467d-8ae8-c2dd8cfcc2ab","setting-up-ab-testing-posthog","1060881589","Join us and our friends at PostHog to learn all about building A/B testing infrastructure in your CMS with their killer A/B testing functionality.","68305008-77bb-46a0-9ce0-4e94b8667fea",65,3,"2025-02-27","Building A/B Testing in Your CMS: A Deep Dive with Directus & PostHog","\u003Cp>Speaker 0: And we are live. Alright. Welcome. Welcome. Welcome.\u003C/p>\u003Cp>Super excited to kick off this webinar. It's been a long time in the making for me. I have been knee deep in AB testing over the last couple weeks, so super excited. We are going to be covering how to build AB testing inside your CMS with Posthog and Directus. As everybody trickles in, if you are in the chat, let us know where you are from.\u003C/p>\u003Cp>Hop in the chat. Let us know. Awesome. I am Brian Gillespie from Directus. I see a few of you in the chat already know me.\u003C/p>\u003Cp>We also have Yurai from Posthog. Yurai, nice to have you.\u003C/p>\u003Cp>Speaker 1: Hey, everybody. Nice to meet you. I'm Yorai. I live in Amsterdam, Netherlands, and I've been at Posthog for about a year and a half. And for the last year or so, I've been, working hard, on our AB testing tool, which I'm hoping to, demo you a bit today.\u003C/p>\u003Cp>Speaker 0: Yes. I could I I'm excited because I'm gonna learn a bit on this one as well. Obviously, I've done a lot of the technical implementation for not just our own use case at Directus, but, for this amazing bonus that we got for everyone at the conclusion of this. But, I, you know, I I haven't messed around with all of the the the, like, the metrics and, like, the testing and it just like, all of the config inside post hoc is is tremendously powerful. So I looking to, I guess, forward to seeing what, you know, how that is cooked up on your end.\u003C/p>\u003Cp>Alright. Let's, let's cover the agenda, and then we'll kinda give a brief overview of, both direct us and post hoc just because I I saw some questions in the sign up of the people that weren't familiar with either one. So this is obviously the awkward introduction phase. Hi. Okay.\u003C/p>\u003Cp>I see everybody. Canada, Tampa, Florida, Texas. Amazing. Nashville. Next, we're going to kick it over to Yurai where they'll cover he'll cover, basically, a demo of post hoc and how you set up experiments, how you run AB testing, what's a feature flag, what's not, what you should be thinking about as you're testing.\u003C/p>\u003Cp>And then we're going to, basically do a live jam sesh of how to connect Directus and Posthog using this, the starter kit that we've created. And we'll open this up for q and a at the end of this. And I'll show you guys how to get this amazing bonus with, the working source code, fingers crossed. Right? So you don't have to invest the time and headache that I have invested over the last couple weeks.\u003C/p>\u003Cp>But with that, Yirai, maybe you want to talk a little bit about post hoc for those who are unfamiliar with the tool.\u003C/p>\u003Cp>Speaker 1: Sure. I guess it'll be easier if I share my screen right away. Yeah. Go for it. Let me do that.\u003C/p>\u003Cp>Alright. Well, so post hoc, started as, as a product analytics platform, but we've really evolved into kind of, like, an all in one solution which allows you to build great products. So, besides product analytics, we have today more tools such as session replay, feature flags, surveys, you know, data warehouse, and, of course, experiments, which we'll talk about today. So experiments, basically allow you to, test, like, variations on your website, test different changes, and see if those changes lead to some kind of improvements in the behavior of your users, which is then, of course, visible in the metrics that you are tracking. So the way it works is that you you use post hoc's product or feature called feature flags.\u003C/p>\u003Cp>And feature flags basically assign different variations of your website to your users. And usually, by default, you will be testing two variations, on your website. The variations will be normally called control and test. And let's say user a will get the variation control, user b gets the variation test. They will both see something different on your website, and then, you know, PulseHawk will track the behavior of your users on the website by capturing events.\u003C/p>\u003Cp>And then we aggregate those events on our site, and we basically calculate results for you, which tell you whether a particular variation is better than some other variation. So like I said, every experiment is is backed by a feature flag, but, actually, you don't really need to know, much about feature flags at all. The feature flag will be created for you when you set up an experiment. So, like, all you have to do is basically create the experiment, and I believe Brian will later show you how to do that via direct us.\u003C/p>\u003Cp>Speaker 0: We will. And,\u003C/p>\u003Cp>Speaker 1: basically, it all kind of, like, happens under under the hood. And, basically, all you need to then do to analyze your experiment is to just let it go to your experiments that impose HOG, and you will be able to analyze your results there. So I'm going to open an example experiment to show you what a results analysis might look like. So over here, I have a running experiment open. You can see that it was started, like, two months ago, which will be, like, a pretty long running experiment, but that's just because, like, it's it's some test data.\u003C/p>\u003Cp>But, basically, the the core of each experiment is the metrics that you are tracking. Right? It's it's these metrics that tell you, like, what what exact changes in behavior your your changes in in your content or in your experience are producing. And in this particular experiment, I'm tracking, six different metrics, three primary and three secondary. And the difference between the primary and secondary is just that it's just like the way of of organizing your metrics.\u003C/p>\u003Cp>So the primary metrics are something which actually inform whether your experiment is successful or not. And secondary metrics are kind of like guardrails. So it's it's something that you don't really want to regress. It's it's maybe not like a like a metric directly tied to your experiment, but it could be anything from, let's say, like, a session length or or any kind of, like, in interaction maybe indirectly linked to your experiment, but you still may want to track that to make sure that, that you don't get some some other part of your of your product kind of, like, regressed.\u003C/p>\u003Cp>Speaker 0: Cool. That's a I I like that for sure. Hey. That's that's one of the confusing things for me. It was, like, what goes in primary, what goes in secondary?\u003C/p>\u003Cp>Just, so it sounds more of, like, secondary would be like, hey. This is a great guard against unwanted side effects. Like, hey. Exactly. Increased conversion, but, you know, like, the time on the page or or, like, session time or, bounce rate or something rose versus, the actual event that we wanted.\u003C/p>\u003Cp>Speaker 1: That's exactly right. Yeah. So it's just like a way of organizing things. And but other than that, there is really, like, no difference under the hood between, like, a primary metric or a secondary metric. Basically, always, like, at a at a very low level, what we do at Boss Hog is capturing events, and, a metric is like a way of counting those events in a in a certain way.\u003C/p>\u003Cp>So let's have a look at at one of these metrics. So let's let's take a look at the first one. I'm going to click at this on this edit button, and here is my metric definition. So this is a funnel metric which measures, the conversion rate between two events. So the first conversion so so the first event here is called sign up started.\u003C/p>\u003Cp>The second event is sign up completed. And what this funnel metric measures is the conversion between these two events. So you can see that I have 3,000 persons who did the first event, but only 815 persons who, triggered the second event. And so the the difference between these two events is basically your conversion rate, which in this case is twenty seven percent. And what you actually see here so this is like the the metric definition form.\u003C/p>\u003Cp>This is not your experiment result. This is just kinda like a preview, which shows you well, is the data actually there, right, in the in the system? Like, are actually people sending these events? And that kind of tells you that, okay. Like, this is, like, a valid metric to experiment on.\u003C/p>\u003Cp>Like, our instrumentation is set up properly so we can actually go ahead and and save that metric. So once I save the metric and, well, once the experiment is running, I will start seeing my results once sort of, like, a minimum criteria are met, which is that, you know, you need to have some sort some number of events that have been ingested. You need to have events for both control and test variants. And once all of these are met, you will start seeing results. And the way we present results is kind of like an industry standard way to present results of, you know, AB experiments, which is that we show you this chart, which is called a delta chart.\u003C/p>\u003Cp>And what you see here is that for each variant, you will see this bar. And this bar is basically a credible interval. What it shows you is the the actual or let me actually start start start, like this. So so each each bar shows you, the actual difference between that given variant and the control variant. Right?\u003C/p>\u003Cp>The the black bar in the middle is the delta between the variant and and the and the control variant. So you can see that in case of the test one variant, we actually have a regression here. So the control is at 0%, and the test one variant is kind of like minus 13%. So that's bad. Right?\u003C/p>\u003Cp>Like, that's a that's a regression. We have worse conversion rate for the test one variant compared to the control variant. Now for the test two variant, we actually see an improvement. So the delta here is plus 6.92 compared to control, and that's why this bar is in is in green because it's actually gonna be improvement. So that's what the the the black vertical bar tells you.\u003C/p>\u003Cp>And now now onto the edges onto the edges of the actual bar. So this is like a credible interval. So what this bar tells you is actually the uncertainty that you have because, in any kind of statistical testing, there is some sort of uncertainty. And this like, the the the outer boundaries of these, credible intervals tells you, what kind of range in the actual results you may expect. And this basically tells you that, this credible interval, goes from minus 3% to plus 70%.\u003C/p>\u003Cp>And that means that in ninety five percent of the cases, because this is a so called 95% credible interval, you can expect the true value to lie between, like, this range. So there is still some sort of small probability that there will be a regression, for the test two variant even though, it's kind of like there's a high probability that it will be, some some sort of improvement. The narrower a credible interval is, the higher certainty you have. Right? Because, it's kind of like a tighter range of values where the actual value may lie.\u003C/p>\u003Cp>The wider it is, then it's kind of like more more uncertainty. And oftentimes, as you as you collect more data and you, like, keep refreshing results, you can you can kind of, like, observe the variance getting narrower and narrower every day as you kind of gather more data and get gather more more certainty. So that's what these credible intervals bars tell you. It's calculated separately for each of the metrics. And, at post hoc, we use a so called Bayesian statistical methodology, and the two main outputs of the methodology is the credible interval itself, which tells you the the uncertainty of the result.\u003C/p>\u003Cp>And kind of like the main output is is what we call win probability. So in this case, for this variant, there is an almost 83% probability that this test two variant is actually better than control. And then we show you, kind of like the the significance banner over here. And at post hoc, the the criterion that we use to tell you whether you should roll out a variant or shouldn't roll out a variant is that the win probability needs to be higher than 90% for the best variant. And in this case, you can see that it's actually less than 90%.\u003C/p>\u003Cp>And that's why for this particular metric, we declare it as not significant because it's less than 90%, which is what this tool tip also tells you.\u003C/p>\u003Cp>Speaker 0: Okay. So now you've just answered, like, my own specific like, this is the biggest question I've had on, like, the experiments that we've ran of, like, what's how do you measure the significance? You know? Because we we've ran several tests, and, I'll get into, like, the specific results here in just a bit of one of our tests. But, like, some of the tests have been like, we saw, like, a it what looked like a positive improvement, but it was marked not significant.\u003C/p>\u003Cp>So it's like, like, it you know, can we be confident in that result or not?\u003C/p>\u003Cp>Speaker 1: Right. Yeah. Yeah. That's a good point. And, we actually keep, improving this UI, and we want to actually, like, make it clearer as to, like, what all of these numbers mean and when you can expect significant.\u003C/p>\u003Cp>And it's like why something is significant, why something isn't significant. Just, like, make make all of this kind of decision making clear. So that's that's definitely a a valid point.\u003C/p>\u003Cp>Speaker 0: I I I'll just stick you in the UI explaining it, man. Take it like you flawlessly. You did I was\u003C/p>\u003Cp>Speaker 1: gonna ask that again. I I didn't hear that. I I\u003C/p>\u003Cp>Speaker 0: was gonna say, just stick a video of you inside the UI because you, you you did flawlessly.\u003C/p>\u003Cp>Speaker 1: Oh, nice. Yeah. We might actually do that. That's a that's a great Yeah. Cool.\u003C/p>\u003Cp>Am I still sharing? Because I think the, Oh, we lost the screen share. Yeah. Oh, okay. I'll reshare.\u003C/p>\u003Cp>Okay. And then, so just like continuing to the second metric, it's it's exactly the same principle. So each metric is is evaluated in exactly the same way. I mean, the the like, on our back end, there are some differences as to how, different metric types are evaluated. So for example, the second metrics the second metric is a different metric type.\u003C/p>\u003Cp>Right? So, like, in in the first case, we had a we were measuring funnel conversion. In the second metric, we are actually just measuring the role click count. And, of course, there are some statistical differences as to how this should be evaluated, like, on the back end. And we make sure that, like, we do this properly.\u003C/p>\u003Cp>But for you as a user, there's really no difference. You basically just look at, the movement of these bars relative to the control variant, and you look at the the win probability. And then the banner will will tell you whether a particular metric is significant or not. You can also dive deeper into any particular metrics. So if you click on details, you will see the actual counts for, for each variant.\u003C/p>\u003Cp>You can see that the test variant is strongest. Right? So it makes sense that it has the highest count over here. And this is like a cumulative chart, so the the the counts actually stay the same after we we stopped collecting the data for this experiment. Nice.\u003C/p>\u003Cp>Yeah. You can also see things like exposures for each variant, their means, the delta, things like that. There's also like a like a small cool feature, which is that you can actually view recordings for any particular variant. So the the the power of the POSIX platform is really that we offer multiple products, and they are kind of, like, interlinked. So you can can actually, like, click on on this particular variant and see the recordings, like, of those persons that that that actually, like, sold that variant.\u003C/p>\u003Cp>And I don't see any recordings here because I'm on my local instance and just, like, using all the data so you can know from actual users. But in Yeah. On actual dashboard, you would actually see recordings, of users where you could actually see how they how they interact with your with your website.\u003C/p>\u003Cp>Speaker 0: Yeah. And and, like, having that all in one has been, like, a significant help for us at Directus. You know, I would it's not like for us, it's it's not stack overflow. It's it's like stack overload. Like, I, you know, I the thought of adding, like, six more tools to your tech stack for your website, is just like a a mess.\u003C/p>\u003Cp>It's it's like a pain for us. I I don't wanna do it. So and, like, when we integrated post hoc, like, the the analytics for us was, like, one of the one of the first things that we got a lot of value out of, and then we we started diving into the AB testing. You know, as we we kinda shift gears, like, do you have any best practices, your eye on, like like, what to test? You know, obviously, like, you've built this thing.\u003C/p>\u003Cp>You probably worked closely with with some clients at Posthog. Like, what are people testing? Do you have any best practices to share?\u003C/p>\u003Cp>Speaker 1: Sure. So I would say if you if you are just starting out with experiments, start with something very small. So things like, you know, small changes to your landing page. That will really allow you to, just, like, kind of, like, get, like, how how the whole things works. And, maybe also kind of, like, circumvent some of the gotchas, like, like, why why while you are still starting out.\u003C/p>\u003Cp>Like, there are, like, several things that you should be aware of if you are implementing AB testing. I'm not sure if if, like I would say, like, maybe there can, like, be on the scope of this of this webinar, but we have, like, section with some troubleshooting and FAQs and, some best practices, when when implementing experiments. To summarize very quickly, I would say the like, one important thing is to make sure that your tracking is set up correctly. So, like, in your code, whenever a user performs a given action, you do actually capture that action so that Pulsar receives that event because, obviously, if we don't receive the correct events, we cannot, provide correct analysis. Now in terms of some in terms of, like, some likely more actionable AB testing advice, I would say start with small changes.\u003C/p>\u003Cp>Also make sure that, you are testing perhaps only, like, one or two changes at once. Because if you change, like, too many things, let's say, on your on your on your landing page, and then the test is showing, you know, significant outcome, like, you don't really know which which one of those a changes that you've made is actually leading to the improvement. Whereas, if you just like there's, like, small incremental changes, then you would be able to to tell that, kind of, like, more reliably. Another kind of, like, important technical detail is that you should probably use a reverse proxy on your post hoc setup to make sure that the, like, ad blockers are not, like, blocking capturing of the events, which is, like, a common issue, that can be really easily, circumvented with this. We also have, like, proper documentation, on this.\u003C/p>\u003Cp>Like, in general, if if you have, basically, for for any questions, you can use our search functionality in our documentation, for example, for the reverse proxy. That will explain to you exactly what you you should do to to set up also correctly to to be able to circumvent, ad blockers. Another useful tip is to learn how to actually estimate, your sample size properly. So one thing I I haven't explained yet is that we have this data collection section over here. And what this allows you to do is to is to answer the question how long you should run your experiment for.\u003C/p>\u003Cp>And, so I'm actually going to show you how this works. So if I click on edit over here, I have this slider which says minimum detectable effect. And this basically says, well, what kind of change in my metric am I trying to measure? And there's, like, a trade off to be made here because, if you are the the way the way sample sizes and experimentation work is that the larger the change you are trying to measure, the smaller the sample size you need. It may sound kind of counterintuitive.\u003C/p>\u003Cp>Speaker 0: It it definitely. Definitely. Because I've seen this, and I'm like, like, hey. Why why do we need less people for this?\u003C/p>\u003Cp>Speaker 1: Yeah. And, actually, right now, we are actually completely rebuilding this component to to do, like, a better job, explaining all this. But, basically, what this means is that if there is a huge change in your metric, you don't really need, like, a sensitive test for it. Right? You you don't need, like, a, like, a huge sample size because, if there is, like, a huge effect, that effect will already be apparent in, like, a relatively small sample size.\u003C/p>\u003Cp>But if you are trying to measure something much smaller, like, let's say, I'm I'm just going to move this slider from 10% to 2%, I need, like, a much more sensitive test, which means, like, a much higher sample size. Right? So, like, I I basically need, much bigger sample size to be able to reliably say, this 2% change is not just due some sort of chance. It's actually due to the actual change in the in the underlying behavior. But I definitely need, like, a larger sample size for this.\u003C/p>\u003Cp>So Right. The consideration some some some key considerations here is that are that, first of all, what is the sample size you can actually get? Right? If you if you are a startup and you're just, like, getting your first users, it might be actually difficult to get a sample size of 10,000 persons. So in that case, you are basically restricted to much smaller sample sizes.\u003C/p>\u003Cp>And\u003C/p>\u003Cp>Speaker 0: Right.\u003C/p>\u003Cp>Speaker 1: That actually means that your tests would actually would probably have to target, you know, just like large changes.\u003C/p>\u003Cp>Speaker 0: You wanna go big or go home at that point.\u003C/p>\u003Cp>Speaker 1: Exactly. Yeah. But as soon as you have some larger user base, you can start going after, you know, incremental small changes, that perhaps produce, smaller effects on your metrics. But you can you can run, like, many of such experiments and, you know, even incremental changes or or of one or 2% over time. They they really add up to a lot.\u003C/p>\u003Cp>So, yeah, there's, like, a trade off to be made here, when it comes to this, so it's it's it's good to be aware of that.\u003C/p>\u003Cp>Speaker 0: Yeah. Well, awesome. Yeah. Thanks for the best practices, man. Thank you.\u003C/p>\u003Cp>Like, yeah, I'm I'm learning just as much on this as as the audience, so I appreciate that. We'll jump into, you know, kind of, like, our own experience a little bit, and then I'll, kinda run through the steps of of integrating post hoc and direct us and and, again, show you guys the the source code. We'll we'll dive into it. We won't write code. That didn't work out well for me the last time I, I did one of these live sessions.\u003C/p>\u003Cp>But, as far as our own, like, experience with posthog, you know, recently, we rolled out a brand new version of our home page. And I'm gonna can we see this? Oh, yeah. There we go. So this was a big change for us.\u003C/p>\u003Cp>And, you know, this one, if I shrink it down, it's probably a little better. But this was a this new homepage was a big shift for us. And one of the things that we wanted to do was we wanted to test first to make sure that, number one, the messaging was wasn't causing a a decrease in conversions. Number two, you know, we wanted to make sure that that this was performing better than our our old home page. You know, we've got this interactive carousel component that basically links into, what we call our directus pizza demo, which is just a a live working instance of directus.\u003C/p>\u003Cp>So folks can hop in and and poke around inside one of the templates. Before we we shifted all that traffic, right, we wanted to make sure that this was actually worthwhile. So our own results that we saw got a fancy slide up here somewhere. Boom. Yeah.\u003C/p>\u003Cp>So, the conversions were were relatively the same. And, again, that goes back to kinda your eyes point about, like, what metrics are, you know, how do we measure significant change? But some of the big results that we saw was, like, a 30% decrease in bounce rate on the site, which is huge. And, obviously, that correlates with a, like, a larger session time, most likely because people are getting in the demo of Directus, at least that's our hypothesis, and and actually poking around, which is which is what we want. And and I know you guys at Posthog, you're I, you guys are are kind of following that same methodology of, like, you know, let's let's skip all of the, fluffy marketing stuff and actually get you into the product, so we can actually dive in and and learn.\u003C/p>\u003Cp>Alright. So let's actually dive into a this integration. And I put together just, like, this a really nice visual for how we've been doing AB testing with post hoc at Directus. And that is kind of the the concept behind behind this setup. We've done tests at at two levels, and I call it the block level, which is basically testing within the same page, which is, you know, hey.\u003C/p>\u003Cp>We wanna test a different headline on the homepage, or we wanna test, a different pricing component or a a different pricing tier. So that would be like a block level test. And then, I I was calling this a page level test, which is basically testing between different pages. You could call it a split test. You guys are calling it redirect testing inside the documentation dry.\u003C/p>\u003Cp>But it basically like, we we take a URL. We want to redirect some percentage of the traffic. You know, usually, if it's just two variants you're testing, you you probably split fifty fifty. But but that's the way that we've been doing testing at Directus. And now I'm going to show you how this all comes together.\u003C/p>\u003Cp>So, this is post hoc, and we laid a special theme, special post hoc theme on top of a direct us instance just for this webinar. But this is our CMS starter template with a little bit of magic sprinkled into it. So, if we take a look at what I call the checklist where did that guy go? Supposed to have a production person here, Matt. Not calling you out, but I'm calling you out.\u003C/p>\u003Cp>The post hoc checklist, can we see that live? Do I have to stop screen sharing to see that? Yeah. There we go. Alright.\u003C/p>\u003Cp>So this is the AB testing checklist, as far as integrating with posthog. I'm gonna show you how to create a a project in posthog. We're going to dive into, like, creating a personal API key to power this little automation that we've got. We're gonna walk through the directest data model. We'll adjust some permissions.\u003C/p>\u003Cp>I'll show you the flow that's involved, and we'll talk through, like, this Next. Js front end, and how that is integrated. Alright. So let's get back to the screen share, and we'll do this together. What I'm going to do, and this is a little crazy to do.\u003C/p>\u003Cp>We are, like, maxed out as far as projects. So I'm gonna delete this test project. This is, sketchy on a demo on a webinar, but, that's what we're gonna do. Alright. So I'm in post all the first thing we've gotta do.\u003C/p>\u003Cp>Right? We're we're gonna create a project. Just go through this. This is gonna be the AB testing webinar project. Great.\u003C/p>\u003Cp>Alright. So we've got our project. I'm gonna need two things. I need the project ID. So I can find that up here in the URL, or, let me get my fancy mouse pointer going here.\u003C/p>\u003Cp>I can find that from these settings as well. So I'm gonna grab the project ID, and, yes, we will send the recording of this. I promise. Alright. So now in the Directus instance, which you are going to get total unrestricted access to you at the end of this, we've got some global set up.\u003C/p>\u003Cp>So global's inside Directus, are basically, just a what we call a singleton collection. So globals are are typically things like, social links or favicons, logos, stuff that you're gonna use across your entire site. So we're gonna add our project ID. And then the other thing that I'm gonna add, I I don't necessarily need this project API key for the directive side of things. You'll need this on the Next.\u003C/p>\u003Cp>Js integration. You'll wanna copy it to your clipboard, stick it into your text editor, so that you've got that. But what we're gonna do, we need to go into our personal settings. And the reason why is inside this Directus instance, there's an a nice little automation that will show. Alright.\u003C/p>\u003Cp>So I'm gonna log in, reauthenticate for security, and we're gonna look for a personal API key. So I'm just gonna create a new key. This is our a b testing webinar key. We want a specific project that's gonna be our AB testing webinar. Whenever you create keys, whether that's in post hoc or GitHub, please be very specific.\u003C/p>\u003Cp>So we're gonna do right access on experiments and feature flags, and I think this should be all we need. Am I am I correct in that assumption, your eye?\u003C/p>\u003Cp>Speaker 1: Looking good to me. Yeah.\u003C/p>\u003Cp>Speaker 0: Okay. Perfect. Alright. So I'm gonna grab this key. I'm gonna go in, and I'm gonna post that inside this direct us instance.\u003C/p>\u003Cp>Amazing. Magic. Right? So let's let's talk through the changes inside this Directus instance. Again, this is our simple CMS template.\u003C/p>\u003Cp>Like, if you go to Directus.io, you go to get started for free, you create a cloud account, You get logged in. You can get the starting point for this, just by clicking CMS, or you can also get it through our template CLI tool. We'll button up all these resources. But this already has what we call the many to any relationship. It's basically a dynamic page builder that is set up inside your CMS.\u003C/p>\u003Cp>So if I open up my live preview pane, we can see that this page is made up of blocks. Right? And this paradigm lends itself to that block test that I was talking about. So that is kind of the setup here. The, extra collections that we've added to this direct to census, which are very minimal, are are just two pieces.\u003C/p>\u003Cp>Right? We have added experiments and experiment variants. And the reason why we add those inside direct us, we need to be able to link the content inside the CMS to the post hoc experiment. And this is it gets back into the why we created this. So we want to empower our marketing team, our content editors, to run tests, right, without code, without bothering the developer, without it being blocked by the developer.\u003C/p>\u003Cp>Right? We want marketers or well, this is my personal mission. I want developers and marketers to get along well. And if you are waiting, on information from marketing to set up the actual code for an AB test, not great. Likewise, if they have to bug you every time they want to test a new variant, that's gonna frustrate you as well.\u003C/p>\u003Cp>So, what we do, we've created a a experiments collection. And inside that, pretty simple. We've got a name for the experiment. We've got a feature flag key that you'll see we actually need, inside post hub. We've got a a short description.\u003C/p>\u003Cp>We've added a type of test. You know, is it a block or is it a page level test? And then we have our variants. So the variants are a relationship to that experiment variants, and this is pretty simple as well. We've got a key for the variant.\u003C/p>\u003Cp>Each experiment has to have a control variant as your eye talked about. And if you're doing a page level experiment or a redirect test, you need to have a URL. So on the front end, running a test is as simple as this. Right? With those pieces put together, and I'm sure Matt is crossing his fingers behind the scenes right now.\u003C/p>\u003Cp>Let's do a block level test. Right? So I'm inside Directus. I want to test a new headline. New headline.\u003C/p>\u003Cp>Home page. There he is. I see I see him in the chat. New headline for homepage. Alright.\u003C/p>\u003Cp>I stole this placeholder copy directly from you guys, Uriah. We want to let's see if this new headline improves conversion. So, hey, this doesn't totally replace post hoc. This is just a a slick integration to work together with the two. So we're gonna pick the test type.\u003C/p>\u003Cp>This is gonna be our block level test. We wanna test within the same page. And we'll add the control, and we'll add, just like this new headline variant. Great. Okay.\u003C/p>\u003Cp>Now with that out of the way, we save. What happens behind the scenes? There is an automation. I love automation. Direct as flows is a great way to build these automations.\u003C/p>\u003Cp>This is what this automation looks like, and I'll walk you through it really quickly. So whenever I go to create an item inside experiments, we've run this series of operations. We grab our global settings, so that API key, that project ID, and then we format a payload for post hoc. We create a new experiment inside post hoc using their API. Did we lose audio?\u003C/p>\u003Cp>Can you hear me okay, Yuri?\u003C/p>\u003Cp>Speaker 1: I can hear you, Brian. Yes.\u003C/p>\u003Cp>Speaker 0: Okay. Okay. Alright. I just wanted to make sure. Hopefully, it'll all be in the recording as well.\u003C/p>\u003Cp>But, then we've got a another it just it little piece of JavaScript here that formats a feature flag payload, and that's helpful for our redirect test that we're doing. And then basically, we stuff all that into post dog. And at the end of this, we return a payload that gets saved inside Directus. So the effect that we've get is a experiment that gets created inside Posthog. We've got a experiment here inside Directus now that we can actually link to, a piece of content.\u003C/p>\u003Cp>So if I go into post dog, we go to experiments. Check installation, skip installation. Skip or no? Skip. I did not remember that part of the creating a project.\u003C/p>\u003Cp>Alright. So we could see this experiment here inside post hoc. Let's see. There it is. This is all set up.\u003C/p>\u003Cp>But now let's go and link this to a piece of content. Right. So we're gonna go back to our home page, and we've got our hero block. So this is the control block. I'm just gonna go down to the bottom.\u003C/p>\u003Cp>And, basically, we've got a a relationship from this block to our experiment, and then we're gonna pick the variant that it belongs to. Except something wasn't quite right. It wouldn't be a demo that I was doing if everything worked smoothly. Why isn't my variant showing up? Clear filters.\u003C/p>\u003Cp>Experiment. There is the alright. You got me. Let's clean this up just a bit. I've got tried to get fancy, and I've got, I don't know what level of fancy I got here.\u003C/p>\u003Cp>But, okay. We'll try this again. Now I'm gonna link this to our new homepage headline experiment. We're going to add this to our control, and now we're gonna add another headline. This is the new headline.\u003C/p>\u003Cp>Amazing. It's gonna look beautiful. We're gonna link it to that same experiment, except now I'm gonna link this to our new headline variant. So all I'm doing behind the scenes here, nothing fancy. I'm just linking this piece of content to the posthog experiment.\u003C/p>\u003Cp>On the Next. Js front end, we're making a call. We get this content, And, because we've got posthog integrated, we get something like this. If I hit refresh, right, I don't see two hero images or two hero blocks here. I just see one.\u003C/p>\u003Cp>Right? And that is because of the post hoc SDK that's set up that is handling all the magic, and you could probably understand why I don't want to do all that magic myself. Now let's see if I can actually trigger you're gonna have to show me, like, a a trick to, like, force some type of, visitor into a variant sometime, your eye.\u003C/p>\u003Cp>Speaker 1: Sure. We can do that.\u003C/p>\u003Cp>Speaker 0: Let's see. This should be put in. Yeah. It's it doesn't seem like I can actually trigger the not triggering the variant here for some reason, through this. But, this is how this is actually integrated.\u003C/p>\u003Cp>This is like a a block level test. Now, you know, if I swap\u003C/p>\u003Cp>Speaker 1: Can you, can you open your web tools? Maybe we can try to override a flag, for this particular page. Yeah. I I Oh, we don't have to do that. That was up to you.\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah. Okay. So there we go. So if you know, now you could see if I swap the control Right?\u003C/p>\u003Cp>If I make the headline the control, we could see the difference here. And, basically, the post hoc integration is is pulling that all together. So that is, like, the setup inside Directus. Like, if I wanted to run a page, a a reader direct level test, let's say I wanted to have a a new pricing page. Right?\u003C/p>\u003Cp>If I go to pricing, we've got pricing to fit every budget here. Maybe I wanna change this. We have new pricing. So we'll just create a new page. Pricing to fit no one's budget, and we'll just raise the prices by quite a bit here.\u003C/p>\u003Cp>Amazing. Alright. So now I'm gonna hit save as copy in this template, and now I've got I've got two new pages or or, well, one new page, but that's our page. I'm gonna go in. And now if I wanna do a redirect level test, I have new pricing page.\u003C/p>\u003Cp>Pricing page. We'll do a redirect. So the control, here, we're gonna add this URL. So that'll just be slash pricing. And when you set up the control experiment or the control variant, again, that is the URL that you're testing.\u003C/p>\u003Cp>It's an important distinction to make. Next, we will add the new pricing page. Great. That's gonna be new pricing. And, again, our direct us flow automation, like, will will bring this home for us and basically create this experiment inside post dog.\u003C/p>\u003Cp>So we'll just hit refresh. We've got our new pricing experiment, and I can click in and and see the the variance here. And as Yurai showed, there's just a feature flag that backs these. Now what we're doing on the page level tests is we're using the post hog feature flag payloads, to avoid making a extra call to direct us for this information. So if we I think I can get a better view if I click edit here, maybe shrink this back a bit.\u003C/p>\u003Cp>You can kinda see what's going on here. We've got an experiment type. It's a page level test. We've got a control path, so that's our pricing. And then we have a path that we're going to redirect to.\u003C/p>\u003Cp>And what happens on the front end if we go to local host 3,000. Now if I try to navigate to pricing, I'm either going to get the control did I I guess we may have to dive into the actual tools here. We'll we'll work that out in a moment. Love giving these demos on the fly. Alright.\u003C/p>\u003Cp>What is next on the agenda? We'll just look at that really quickly. Alright. Our feature flag test. Alright.\u003C/p>\u003Cp>So we've got the director side of things. We've nailed that piece. And then let's take a look at, like, the Next. Js side. Right?\u003C/p>\u003Cp>We want to, like, walk through how this is actually set up and integrated. So a a couple important pieces that you need as far as, like, setting this up within Next. Js. Let's pull this up. Alright.\u003C/p>\u003Cp>Can everybody see this? Okay. Let me try to close close the terminal a bit here. I I can shrink the the size of the make make the font just a little bit bigger. Alright.\u003C/p>\u003Cp>So, again, once you download this repo, you know, feel free to to browse through it on GitHub. We'll, again, we'll we'll send you all of this. But let's let's start on the direct side of things. Inside this Next. Js application, there are our fetchers.\u003C/p>\u003Cp>So we're just using these two. Close. Shrink that. Okay. There we go.\u003C/p>\u003Cp>Alright. So these fetchers are are basically just communicating using the Directus SDK. What we've got here and the only change that we've made from our standard Next. Js template is just making sure we grab the experiment data and the experiment variant that we've linked to a page block. So this all comes together on our, like, our page builder setup that we've got.\u003C/p>\u003Cp>And one of the other things that you'll have to do inside Directus, you can fetch that data, but you need to be able to add the data to your permissions. So you've got to make sure that your experiment variance and your experiments are enabled underneath your permissions to make this work inside Directus. That is just as far as getting into best practices, that's one of my Directus best practices. At 99% of my errors are because I didn't set permissions. Right?\u003C/p>\u003Cp>But we have to add that experiment variant there. And then inside what we call the page builder, there's a a bit of logic here that basically, filters out the blocks. So, this template is set up to run Next. Js server components, so we don't get this flash of content, whenever we enroll someone into a variant. But, basically, we're just checking to see, is this block attached to a variant in an experiment?\u003C/p>\u003Cp>If it is, we get the feature flag from the post halt client, which we'll look at in a moment. And should we add this block? So if the feature flag is found and the block is the control variant, we'll add that control variant. If the feature flag is found and it's not the control variant, we'll make sure we add that to the, to that block. So, not a huge shift in in the logic as far as working with Directus, just simply matching those up.\u003C/p>\u003Cp>On the post hoc side of it, and this is all we it's just standard boilerplate from the post hoc documentation. You need to have a post hoc provider. So we just set this up using use client here because this provider is going to go into a shared, like, a layout inside this Next. Js application. One of the important bits, especially for, like, server side rendering is the bootstrapping.\u003C/p>\u003Cp>So, basically, we're getting all the feature flags on the server side from post hoc and making sure we pass that when we initialize the the post hoc JS client on the the client side. And, Yurai, do you have anything to to kinda add on that bootstrapping side? You know? I I know this was, like, one point that was, a a little bit of where I ran into some issues when I was implementing this.\u003C/p>\u003Cp>Speaker 1: No. Not really. I would just say that this this is really the preferred way how to how to get a feature flex to your client, for a couple of reasons. Because the the other alternative is to actually fetch the feature flags directly from the client, but there is always some delay there. So, you know, you you you may get some usage events being sent without correct future flag information if you do it that way.\u003C/p>\u003Cp>Right? But if you if you bootstrap your flags, that means you always evaluate the flags on the server, which is actually faster because, the POSOC library actually evaluates, the flags there without having to actually go to the POSOC server. So it's actually faster. And once the the web content is served, you already get the feature flags kind of, like, basically already bootstrapped to it. So, this is is actually what what we always recommend, for our users to do.\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah. Makes sense. Now how you do the bootstrapping, it depends on your specific application. The way that we chose to do it in this specific one.\u003C/p>\u003Cp>So we've got this post hoc provider. There's a there's a shared layout that I'll I'll show you. This is just how we we use this provider. So inside our root layout component, and this is using the the Next. Js app router setup, we are actually, like, sending this bootstrap data in a header from a Next JS middleware.\u003C/p>\u003Cp>So we get that here. We pass it to our provider, that sends it down through the client. But the middleware is an important piece. Now you you could do this via a, like, a server component and, like, if you're not doing the redirect testing, I found that that worked pretty well. But, as far as, like, the redirects, you probably wanna do this in the Next.\u003C/p>\u003Cp>Js middleware. Just this is the best way that I've found to do it. So what we've done inside the middleware, if we get to the actual function here. Right? We get the path name that you're sending, you know, what we're navigating to, and then we're basically getting a distinct ID.\u003C/p>\u003Cp>So this is just a helper that is somewhere, maybe in a where is that guy? Distinct ID. Yep. So a post log gives stores a cookie. We will try to get the distinct ID for that visitor, that user via that cookie.\u003C/p>\u003Cp>If we can't find it, we're just gonna create one. Right? And then we will look for some cache data inside the cookie. So we've got, like, a a bootstrap cookie, where we're we're caching this data. But, basically, what we're doing to enhance performance and and make sure that you're not, like, delaying rendering every single time, we've got a flag route set up on the API side, which is somewhere.\u003C/p>\u003Cp>Posthog flags. So, basically, there's a Node. Js posthog client. We pass that distinct ID to it. We go get all the flags and the payloads, and then we're caching that for sixty seconds.\u003C/p>\u003Cp>So as the user navigates, this middleware gets triggered, and, you know, we're we bootstrap that data. And then we also use this to handle our redirect, at the page level. So we've got a check for redirect function, which basically looks at that flag data that we have here. So once we fetch all of those flags from post hoc, we're iterating through those and saying, okay. Are any of these redirects that we've set up matching this experiment?\u003C/p>\u003Cp>If so, then we we send them through. You know, there's a a little bit more fancy stuff behind the scenes, but I I know we're coming up on time with this. Is there I I'm trying to think if there's any other, like, important pieces that I wanted to cover before we turn everybody just totally loose on this thing. I don't think so. Let's see.\u003C/p>\u003Cp>Where's my checklist? Redirect. We've configured the provider. And I saw where is was it Jobchum? Yes.\u003C/p>\u003Cp>So the that was a good spot. I figured out why this is not working. Thanks to JobChomp. It the public post hoc API key is from my previous project. So that's where I told everybody to take this down, make sure you copy it, but I forgot to stick it into my EMV.\u003C/p>\u003Cp>And, yeah, that's why we were having issues. Always love it on the demos. That's that's always fun. Alright. That's it.\u003C/p>\u003Cp>Let's, we'll open it up for q and a. You're I, you know, while we're waiting on questions to come up, I just wanted to say thank you for for jumping on with us and, you know, at least teaching me how to get get more use out of out of the post hoc side of things.\u003C/p>\u003Cp>Speaker 1: Of course. Yeah. It's a it's a it's a pleasure. It's it's a very nice integration that you that you build there. And, we actually have our own kind of, like, no code experimentation tool.\u003C/p>\u003Cp>It's still very, like, very much in beta. But, we'll I'd love to get access\u003C/p>\u003Cp>Speaker 0: to that.\u003C/p>\u003Cp>Speaker 1: Yeah. Whoever whoever uses, like, just Bosak can actually, like, already try it out. It's it's, like, not nearly as powerful as as as, like, what direct Directus allows right now as in kind of, like, rearranging blocks and, like like, doing all that. It's basically just for, like, simple simple style changes. But, yeah, perhaps there is also something for us to to learn here.\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah. You know, I like, hopefully, like, coming out of this, we'll have, like, a, like, a how to dev blog post to to put this together. But, you know, one of the things that I I just I struggle to find any, like, linking to CMS examples. So, now that we've got one, this is how an integration could work.\u003C/p>\u003Cp>Let's let's take some questions here from Steven. Do you have a guide on what kind of traffic numbers you need to do effective testing?\u003C/p>\u003Cp>Speaker 1: Yeah. So maybe I can answer that. So like I said, we we have this sample size calculator, which basically tells you exactly that. Now, that calculation is always tied to a particular metric. Right?\u003C/p>\u003Cp>So if you are tracking five metrics, but each of those metrics has kind of, like, different, like, usage numbers, as in, like, different number of persons that actually generate that metric. To be to be really statistically rigorous, you actually have to take the metric with, kinda like the smallest traffic and make sure that you actually get enough traffic for that metric. Right? Other than that, it's it's it's already like what I mentioned. The the the larger the change you are targeting, the smaller the sample size.\u003C/p>\u003Cp>But the smaller the change you are targeting means that, you kind of, like you need to have, like, a more sensitive test, and you need a you need a large larger sample size.\u003C/p>\u003Cp>Speaker 0: That makes sense. Alright. One other question I see from Stefan. How would you set up an AB test for global components across multiple pages like a header? Will it be, like, a new type of test that needs to be set up first?\u003C/p>\u003Cp>It it depends. Like, any good development oriented question, the answer is it depends. But, you know, if you've got the let me just pull up direct us real quick, and then we'll I'll give the bonus link in just a moment. Where's this at? Alright.\u003C/p>\u003Cp>So, you know, a basically, inside the direct us instance that that we've shown here, on the page block level, we we just added a relationship to the variance. And, you know, we've got the corresponding logic inside the Next. Js application that basically just says, hey. Post all, give me the variance and then assigns one of those. But you could add the same relationship to other pieces of the website if you wanted to, whether that was, you know, your navigation, like, your navigation items, within the setup.\u003C/p>\u003Cp>So this, this CMS setup has navigation already built into it. You know, you could potentially link it there. You know, you could do, like, a a hybrid approach inside the code where you, you know, you hard code some of these tests, which are, like, a lot of the examples in post hoc just for simplicity's sake are are there. In our own experience, it's like I I tryna I kind of, like, look at it through the lens of, like, hey. Is this something we're we're gonna do often?\u003C/p>\u003Cp>Like, do I wanna test header elements often? If so, you know, it might make sense to enable your content editors to be able to do that. If it's, you know, like, a one and done test, you might just, add it to the code and and move on. So, hopefully, that's helpful. Let me throw up the well, I'll just post it here in the chat, if I can.\u003C/p>\u003Cp>What's going on? The screen share is stuck. Why is this not working? Something's going on. Okay.\u003C/p>\u003Cp>I can't post the link here in the chat. Matt, if you're around, post this link in the chat for me. My screen is fouling up as it often does on these demos. We'll we'll definitely send this out in a newsletter after the webinar as well, but, there's a repo where you can get all the source code. If you have any questions, feel free to follow-up with us.\u003C/p>\u003Cp>On the Directus side of things, we are also offering a special little promo. And I can't get this to yeah. Hey. The screen share thing is just spinning for me. So that's where we're at with it.\u003C/p>\u003Cp>Uriah, thanks for joining, man. I really enjoyed this. You know, this has been a fun project, and I I appreciate your support and your help along the way.\u003C/p>\u003Cp>Speaker 1: Likewise.\u003C/p>\u003Cp>Speaker 0: Excellent. We'll have a recording out for everyone. And with that, thank you, and good night.\u003C/p>\u003Cp>Speaker 1: Thank you, everybody. Good luck. Bye bye.\u003C/p>","And we are live. Alright. Welcome. Welcome. Welcome. Super excited to kick off this webinar. It's been a long time in the making for me. I have been knee deep in AB testing over the last couple weeks, so super excited. We are going to be covering how to build AB testing inside your CMS with Posthog and Directus. As everybody trickles in, if you are in the chat, let us know where you are from. Hop in the chat. Let us know. Awesome. I am Brian Gillespie from Directus. I see a few of you in the chat already know me. We also have Yurai from Posthog. Yurai, nice to have you. Hey, everybody. Nice to meet you. I'm Yorai. I live in Amsterdam, Netherlands, and I've been at Posthog for about a year and a half. And for the last year or so, I've been, working hard, on our AB testing tool, which I'm hoping to, demo you a bit today. Yes. I could I I'm excited because I'm gonna learn a bit on this one as well. Obviously, I've done a lot of the technical implementation for not just our own use case at Directus, but, for this amazing bonus that we got for everyone at the conclusion of this. But, I, you know, I I haven't messed around with all of the the the, like, the metrics and, like, the testing and it just like, all of the config inside post hoc is is tremendously powerful. So I looking to, I guess, forward to seeing what, you know, how that is cooked up on your end. Alright. Let's, let's cover the agenda, and then we'll kinda give a brief overview of, both direct us and post hoc just because I I saw some questions in the sign up of the people that weren't familiar with either one. So this is obviously the awkward introduction phase. Hi. Okay. I see everybody. Canada, Tampa, Florida, Texas. Amazing. Nashville. Next, we're going to kick it over to Yurai where they'll cover he'll cover, basically, a demo of post hoc and how you set up experiments, how you run AB testing, what's a feature flag, what's not, what you should be thinking about as you're testing. And then we're going to, basically do a live jam sesh of how to connect Directus and Posthog using this, the starter kit that we've created. And we'll open this up for q and a at the end of this. And I'll show you guys how to get this amazing bonus with, the working source code, fingers crossed. Right? So you don't have to invest the time and headache that I have invested over the last couple weeks. But with that, Yirai, maybe you want to talk a little bit about post hoc for those who are unfamiliar with the tool. Sure. I guess it'll be easier if I share my screen right away. Yeah. Go for it. Let me do that. Alright. Well, so post hoc, started as, as a product analytics platform, but we've really evolved into kind of, like, an all in one solution which allows you to build great products. So, besides product analytics, we have today more tools such as session replay, feature flags, surveys, you know, data warehouse, and, of course, experiments, which we'll talk about today. So experiments, basically allow you to, test, like, variations on your website, test different changes, and see if those changes lead to some kind of improvements in the behavior of your users, which is then, of course, visible in the metrics that you are tracking. So the way it works is that you you use post hoc's product or feature called feature flags. And feature flags basically assign different variations of your website to your users. And usually, by default, you will be testing two variations, on your website. The variations will be normally called control and test. And let's say user a will get the variation control, user b gets the variation test. They will both see something different on your website, and then, you know, PulseHawk will track the behavior of your users on the website by capturing events. And then we aggregate those events on our site, and we basically calculate results for you, which tell you whether a particular variation is better than some other variation. So like I said, every experiment is is backed by a feature flag, but, actually, you don't really need to know, much about feature flags at all. The feature flag will be created for you when you set up an experiment. So, like, all you have to do is basically create the experiment, and I believe Brian will later show you how to do that via direct us. We will. And, basically, it all kind of, like, happens under under the hood. And, basically, all you need to then do to analyze your experiment is to just let it go to your experiments that impose HOG, and you will be able to analyze your results there. So I'm going to open an example experiment to show you what a results analysis might look like. So over here, I have a running experiment open. You can see that it was started, like, two months ago, which will be, like, a pretty long running experiment, but that's just because, like, it's it's some test data. But, basically, the the core of each experiment is the metrics that you are tracking. Right? It's it's these metrics that tell you, like, what what exact changes in behavior your your changes in in your content or in your experience are producing. And in this particular experiment, I'm tracking, six different metrics, three primary and three secondary. And the difference between the primary and secondary is just that it's just like the way of of organizing your metrics. So the primary metrics are something which actually inform whether your experiment is successful or not. And secondary metrics are kind of like guardrails. So it's it's something that you don't really want to regress. It's it's maybe not like a like a metric directly tied to your experiment, but it could be anything from, let's say, like, a session length or or any kind of, like, in interaction maybe indirectly linked to your experiment, but you still may want to track that to make sure that, that you don't get some some other part of your of your product kind of, like, regressed. Cool. That's a I I like that for sure. Hey. That's that's one of the confusing things for me. It was, like, what goes in primary, what goes in secondary? Just, so it sounds more of, like, secondary would be like, hey. This is a great guard against unwanted side effects. Like, hey. Exactly. Increased conversion, but, you know, like, the time on the page or or, like, session time or, bounce rate or something rose versus, the actual event that we wanted. That's exactly right. Yeah. So it's just like a way of organizing things. And but other than that, there is really, like, no difference under the hood between, like, a primary metric or a secondary metric. Basically, always, like, at a at a very low level, what we do at Boss Hog is capturing events, and, a metric is like a way of counting those events in a in a certain way. So let's have a look at at one of these metrics. So let's let's take a look at the first one. I'm going to click at this on this edit button, and here is my metric definition. So this is a funnel metric which measures, the conversion rate between two events. So the first conversion so so the first event here is called sign up started. The second event is sign up completed. And what this funnel metric measures is the conversion between these two events. So you can see that I have 3,000 persons who did the first event, but only 815 persons who, triggered the second event. And so the the difference between these two events is basically your conversion rate, which in this case is twenty seven percent. And what you actually see here so this is like the the metric definition form. This is not your experiment result. This is just kinda like a preview, which shows you well, is the data actually there, right, in the in the system? Like, are actually people sending these events? And that kind of tells you that, okay. Like, this is, like, a valid metric to experiment on. Like, our instrumentation is set up properly so we can actually go ahead and and save that metric. So once I save the metric and, well, once the experiment is running, I will start seeing my results once sort of, like, a minimum criteria are met, which is that, you know, you need to have some sort some number of events that have been ingested. You need to have events for both control and test variants. And once all of these are met, you will start seeing results. And the way we present results is kind of like an industry standard way to present results of, you know, AB experiments, which is that we show you this chart, which is called a delta chart. And what you see here is that for each variant, you will see this bar. And this bar is basically a credible interval. What it shows you is the the actual or let me actually start start start, like this. So so each each bar shows you, the actual difference between that given variant and the control variant. Right? The the black bar in the middle is the delta between the variant and and the and the control variant. So you can see that in case of the test one variant, we actually have a regression here. So the control is at 0%, and the test one variant is kind of like minus 13%. So that's bad. Right? Like, that's a that's a regression. We have worse conversion rate for the test one variant compared to the control variant. Now for the test two variant, we actually see an improvement. So the delta here is plus 6.92 compared to control, and that's why this bar is in is in green because it's actually gonna be improvement. So that's what the the the black vertical bar tells you. And now now onto the edges onto the edges of the actual bar. So this is like a credible interval. So what this bar tells you is actually the uncertainty that you have because, in any kind of statistical testing, there is some sort of uncertainty. And this like, the the the outer boundaries of these, credible intervals tells you, what kind of range in the actual results you may expect. And this basically tells you that, this credible interval, goes from minus 3% to plus 70%. And that means that in ninety five percent of the cases, because this is a so called 95% credible interval, you can expect the true value to lie between, like, this range. So there is still some sort of small probability that there will be a regression, for the test two variant even though, it's kind of like there's a high probability that it will be, some some sort of improvement. The narrower a credible interval is, the higher certainty you have. Right? Because, it's kind of like a tighter range of values where the actual value may lie. The wider it is, then it's kind of like more more uncertainty. And oftentimes, as you as you collect more data and you, like, keep refreshing results, you can you can kind of, like, observe the variance getting narrower and narrower every day as you kind of gather more data and get gather more more certainty. So that's what these credible intervals bars tell you. It's calculated separately for each of the metrics. And, at post hoc, we use a so called Bayesian statistical methodology, and the two main outputs of the methodology is the credible interval itself, which tells you the the uncertainty of the result. And kind of like the main output is is what we call win probability. So in this case, for this variant, there is an almost 83% probability that this test two variant is actually better than control. And then we show you, kind of like the the significance banner over here. And at post hoc, the the criterion that we use to tell you whether you should roll out a variant or shouldn't roll out a variant is that the win probability needs to be higher than 90% for the best variant. And in this case, you can see that it's actually less than 90%. And that's why for this particular metric, we declare it as not significant because it's less than 90%, which is what this tool tip also tells you. Okay. So now you've just answered, like, my own specific like, this is the biggest question I've had on, like, the experiments that we've ran of, like, what's how do you measure the significance? You know? Because we we've ran several tests, and, I'll get into, like, the specific results here in just a bit of one of our tests. But, like, some of the tests have been like, we saw, like, a it what looked like a positive improvement, but it was marked not significant. So it's like, like, it you know, can we be confident in that result or not? Right. Yeah. Yeah. That's a good point. And, we actually keep, improving this UI, and we want to actually, like, make it clearer as to, like, what all of these numbers mean and when you can expect significant. And it's like why something is significant, why something isn't significant. Just, like, make make all of this kind of decision making clear. So that's that's definitely a a valid point. I I I'll just stick you in the UI explaining it, man. Take it like you flawlessly. You did I was gonna ask that again. I I didn't hear that. I I was gonna say, just stick a video of you inside the UI because you, you you did flawlessly. Oh, nice. Yeah. We might actually do that. That's a that's a great Yeah. Cool. Am I still sharing? Because I think the, Oh, we lost the screen share. Yeah. Oh, okay. I'll reshare. Okay. And then, so just like continuing to the second metric, it's it's exactly the same principle. So each metric is is evaluated in exactly the same way. I mean, the the like, on our back end, there are some differences as to how, different metric types are evaluated. So for example, the second metrics the second metric is a different metric type. Right? So, like, in in the first case, we had a we were measuring funnel conversion. In the second metric, we are actually just measuring the role click count. And, of course, there are some statistical differences as to how this should be evaluated, like, on the back end. And we make sure that, like, we do this properly. But for you as a user, there's really no difference. You basically just look at, the movement of these bars relative to the control variant, and you look at the the win probability. And then the banner will will tell you whether a particular metric is significant or not. You can also dive deeper into any particular metrics. So if you click on details, you will see the actual counts for, for each variant. You can see that the test variant is strongest. Right? So it makes sense that it has the highest count over here. And this is like a cumulative chart, so the the the counts actually stay the same after we we stopped collecting the data for this experiment. Nice. Yeah. You can also see things like exposures for each variant, their means, the delta, things like that. There's also like a like a small cool feature, which is that you can actually view recordings for any particular variant. So the the the power of the POSIX platform is really that we offer multiple products, and they are kind of, like, interlinked. So you can can actually, like, click on on this particular variant and see the recordings, like, of those persons that that that actually, like, sold that variant. And I don't see any recordings here because I'm on my local instance and just, like, using all the data so you can know from actual users. But in Yeah. On actual dashboard, you would actually see recordings, of users where you could actually see how they how they interact with your with your website. Yeah. And and, like, having that all in one has been, like, a significant help for us at Directus. You know, I would it's not like for us, it's it's not stack overflow. It's it's like stack overload. Like, I, you know, I the thought of adding, like, six more tools to your tech stack for your website, is just like a a mess. It's it's like a pain for us. I I don't wanna do it. So and, like, when we integrated post hoc, like, the the analytics for us was, like, one of the one of the first things that we got a lot of value out of, and then we we started diving into the AB testing. You know, as we we kinda shift gears, like, do you have any best practices, your eye on, like like, what to test? You know, obviously, like, you've built this thing. You probably worked closely with with some clients at Posthog. Like, what are people testing? Do you have any best practices to share? Sure. So I would say if you if you are just starting out with experiments, start with something very small. So things like, you know, small changes to your landing page. That will really allow you to, just, like, kind of, like, get, like, how how the whole things works. And, maybe also kind of, like, circumvent some of the gotchas, like, like, why why while you are still starting out. Like, there are, like, several things that you should be aware of if you are implementing AB testing. I'm not sure if if, like I would say, like, maybe there can, like, be on the scope of this of this webinar, but we have, like, section with some troubleshooting and FAQs and, some best practices, when when implementing experiments. To summarize very quickly, I would say the like, one important thing is to make sure that your tracking is set up correctly. So, like, in your code, whenever a user performs a given action, you do actually capture that action so that Pulsar receives that event because, obviously, if we don't receive the correct events, we cannot, provide correct analysis. Now in terms of some in terms of, like, some likely more actionable AB testing advice, I would say start with small changes. Also make sure that, you are testing perhaps only, like, one or two changes at once. Because if you change, like, too many things, let's say, on your on your on your landing page, and then the test is showing, you know, significant outcome, like, you don't really know which which one of those a changes that you've made is actually leading to the improvement. Whereas, if you just like there's, like, small incremental changes, then you would be able to to tell that, kind of, like, more reliably. Another kind of, like, important technical detail is that you should probably use a reverse proxy on your post hoc setup to make sure that the, like, ad blockers are not, like, blocking capturing of the events, which is, like, a common issue, that can be really easily, circumvented with this. We also have, like, proper documentation, on this. Like, in general, if if you have, basically, for for any questions, you can use our search functionality in our documentation, for example, for the reverse proxy. That will explain to you exactly what you you should do to to set up also correctly to to be able to circumvent, ad blockers. Another useful tip is to learn how to actually estimate, your sample size properly. So one thing I I haven't explained yet is that we have this data collection section over here. And what this allows you to do is to is to answer the question how long you should run your experiment for. And, so I'm actually going to show you how this works. So if I click on edit over here, I have this slider which says minimum detectable effect. And this basically says, well, what kind of change in my metric am I trying to measure? And there's, like, a trade off to be made here because, if you are the the way the way sample sizes and experimentation work is that the larger the change you are trying to measure, the smaller the sample size you need. It may sound kind of counterintuitive. It it definitely. Definitely. Because I've seen this, and I'm like, like, hey. Why why do we need less people for this? Yeah. And, actually, right now, we are actually completely rebuilding this component to to do, like, a better job, explaining all this. But, basically, what this means is that if there is a huge change in your metric, you don't really need, like, a sensitive test for it. Right? You you don't need, like, a, like, a huge sample size because, if there is, like, a huge effect, that effect will already be apparent in, like, a relatively small sample size. But if you are trying to measure something much smaller, like, let's say, I'm I'm just going to move this slider from 10% to 2%, I need, like, a much more sensitive test, which means, like, a much higher sample size. Right? So, like, I I basically need, much bigger sample size to be able to reliably say, this 2% change is not just due some sort of chance. It's actually due to the actual change in the in the underlying behavior. But I definitely need, like, a larger sample size for this. So Right. The consideration some some some key considerations here is that are that, first of all, what is the sample size you can actually get? Right? If you if you are a startup and you're just, like, getting your first users, it might be actually difficult to get a sample size of 10,000 persons. So in that case, you are basically restricted to much smaller sample sizes. And Right. That actually means that your tests would actually would probably have to target, you know, just like large changes. You wanna go big or go home at that point. Exactly. Yeah. But as soon as you have some larger user base, you can start going after, you know, incremental small changes, that perhaps produce, smaller effects on your metrics. But you can you can run, like, many of such experiments and, you know, even incremental changes or or of one or 2% over time. They they really add up to a lot. So, yeah, there's, like, a trade off to be made here, when it comes to this, so it's it's it's good to be aware of that. Yeah. Well, awesome. Yeah. Thanks for the best practices, man. Thank you. Like, yeah, I'm I'm learning just as much on this as as the audience, so I appreciate that. We'll jump into, you know, kind of, like, our own experience a little bit, and then I'll, kinda run through the steps of of integrating post hoc and direct us and and, again, show you guys the the source code. We'll we'll dive into it. We won't write code. That didn't work out well for me the last time I, I did one of these live sessions. But, as far as our own, like, experience with posthog, you know, recently, we rolled out a brand new version of our home page. And I'm gonna can we see this? Oh, yeah. There we go. So this was a big change for us. And, you know, this one, if I shrink it down, it's probably a little better. But this was a this new homepage was a big shift for us. And one of the things that we wanted to do was we wanted to test first to make sure that, number one, the messaging was wasn't causing a a decrease in conversions. Number two, you know, we wanted to make sure that that this was performing better than our our old home page. You know, we've got this interactive carousel component that basically links into, what we call our directus pizza demo, which is just a a live working instance of directus. So folks can hop in and and poke around inside one of the templates. Before we we shifted all that traffic, right, we wanted to make sure that this was actually worthwhile. So our own results that we saw got a fancy slide up here somewhere. Boom. Yeah. So, the conversions were were relatively the same. And, again, that goes back to kinda your eyes point about, like, what metrics are, you know, how do we measure significant change? But some of the big results that we saw was, like, a 30% decrease in bounce rate on the site, which is huge. And, obviously, that correlates with a, like, a larger session time, most likely because people are getting in the demo of Directus, at least that's our hypothesis, and and actually poking around, which is which is what we want. And and I know you guys at Posthog, you're I, you guys are are kind of following that same methodology of, like, you know, let's let's skip all of the, fluffy marketing stuff and actually get you into the product, so we can actually dive in and and learn. Alright. So let's actually dive into a this integration. And I put together just, like, this a really nice visual for how we've been doing AB testing with post hoc at Directus. And that is kind of the the concept behind behind this setup. We've done tests at at two levels, and I call it the block level, which is basically testing within the same page, which is, you know, hey. We wanna test a different headline on the homepage, or we wanna test, a different pricing component or a a different pricing tier. So that would be like a block level test. And then, I I was calling this a page level test, which is basically testing between different pages. You could call it a split test. You guys are calling it redirect testing inside the documentation dry. But it basically like, we we take a URL. We want to redirect some percentage of the traffic. You know, usually, if it's just two variants you're testing, you you probably split fifty fifty. But but that's the way that we've been doing testing at Directus. And now I'm going to show you how this all comes together. So, this is post hoc, and we laid a special theme, special post hoc theme on top of a direct us instance just for this webinar. But this is our CMS starter template with a little bit of magic sprinkled into it. So, if we take a look at what I call the checklist where did that guy go? Supposed to have a production person here, Matt. Not calling you out, but I'm calling you out. The post hoc checklist, can we see that live? Do I have to stop screen sharing to see that? Yeah. There we go. Alright. So this is the AB testing checklist, as far as integrating with posthog. I'm gonna show you how to create a a project in posthog. We're going to dive into, like, creating a personal API key to power this little automation that we've got. We're gonna walk through the directest data model. We'll adjust some permissions. I'll show you the flow that's involved, and we'll talk through, like, this Next. Js front end, and how that is integrated. Alright. So let's get back to the screen share, and we'll do this together. What I'm going to do, and this is a little crazy to do. We are, like, maxed out as far as projects. So I'm gonna delete this test project. This is, sketchy on a demo on a webinar, but, that's what we're gonna do. Alright. So I'm in post all the first thing we've gotta do. Right? We're we're gonna create a project. Just go through this. This is gonna be the AB testing webinar project. Great. Alright. So we've got our project. I'm gonna need two things. I need the project ID. So I can find that up here in the URL, or, let me get my fancy mouse pointer going here. I can find that from these settings as well. So I'm gonna grab the project ID, and, yes, we will send the recording of this. I promise. Alright. So now in the Directus instance, which you are going to get total unrestricted access to you at the end of this, we've got some global set up. So global's inside Directus, are basically, just a what we call a singleton collection. So globals are are typically things like, social links or favicons, logos, stuff that you're gonna use across your entire site. So we're gonna add our project ID. And then the other thing that I'm gonna add, I I don't necessarily need this project API key for the directive side of things. You'll need this on the Next. Js integration. You'll wanna copy it to your clipboard, stick it into your text editor, so that you've got that. But what we're gonna do, we need to go into our personal settings. And the reason why is inside this Directus instance, there's an a nice little automation that will show. Alright. So I'm gonna log in, reauthenticate for security, and we're gonna look for a personal API key. So I'm just gonna create a new key. This is our a b testing webinar key. We want a specific project that's gonna be our AB testing webinar. Whenever you create keys, whether that's in post hoc or GitHub, please be very specific. So we're gonna do right access on experiments and feature flags, and I think this should be all we need. Am I am I correct in that assumption, your eye? Looking good to me. Yeah. Okay. Perfect. Alright. So I'm gonna grab this key. I'm gonna go in, and I'm gonna post that inside this direct us instance. Amazing. Magic. Right? So let's let's talk through the changes inside this Directus instance. Again, this is our simple CMS template. Like, if you go to Directus.io, you go to get started for free, you create a cloud account, You get logged in. You can get the starting point for this, just by clicking CMS, or you can also get it through our template CLI tool. We'll button up all these resources. But this already has what we call the many to any relationship. It's basically a dynamic page builder that is set up inside your CMS. So if I open up my live preview pane, we can see that this page is made up of blocks. Right? And this paradigm lends itself to that block test that I was talking about. So that is kind of the setup here. The, extra collections that we've added to this direct to census, which are very minimal, are are just two pieces. Right? We have added experiments and experiment variants. And the reason why we add those inside direct us, we need to be able to link the content inside the CMS to the post hoc experiment. And this is it gets back into the why we created this. So we want to empower our marketing team, our content editors, to run tests, right, without code, without bothering the developer, without it being blocked by the developer. Right? We want marketers or well, this is my personal mission. I want developers and marketers to get along well. And if you are waiting, on information from marketing to set up the actual code for an AB test, not great. Likewise, if they have to bug you every time they want to test a new variant, that's gonna frustrate you as well. So, what we do, we've created a a experiments collection. And inside that, pretty simple. We've got a name for the experiment. We've got a feature flag key that you'll see we actually need, inside post hub. We've got a a short description. We've added a type of test. You know, is it a block or is it a page level test? And then we have our variants. So the variants are a relationship to that experiment variants, and this is pretty simple as well. We've got a key for the variant. Each experiment has to have a control variant as your eye talked about. And if you're doing a page level experiment or a redirect test, you need to have a URL. So on the front end, running a test is as simple as this. Right? With those pieces put together, and I'm sure Matt is crossing his fingers behind the scenes right now. Let's do a block level test. Right? So I'm inside Directus. I want to test a new headline. New headline. Home page. There he is. I see I see him in the chat. New headline for homepage. Alright. I stole this placeholder copy directly from you guys, Uriah. We want to let's see if this new headline improves conversion. So, hey, this doesn't totally replace post hoc. This is just a a slick integration to work together with the two. So we're gonna pick the test type. This is gonna be our block level test. We wanna test within the same page. And we'll add the control, and we'll add, just like this new headline variant. Great. Okay. Now with that out of the way, we save. What happens behind the scenes? There is an automation. I love automation. Direct as flows is a great way to build these automations. This is what this automation looks like, and I'll walk you through it really quickly. So whenever I go to create an item inside experiments, we've run this series of operations. We grab our global settings, so that API key, that project ID, and then we format a payload for post hoc. We create a new experiment inside post hoc using their API. Did we lose audio? Can you hear me okay, Yuri? I can hear you, Brian. Yes. Okay. Okay. Alright. I just wanted to make sure. Hopefully, it'll all be in the recording as well. But, then we've got a another it just it little piece of JavaScript here that formats a feature flag payload, and that's helpful for our redirect test that we're doing. And then basically, we stuff all that into post dog. And at the end of this, we return a payload that gets saved inside Directus. So the effect that we've get is a experiment that gets created inside Posthog. We've got a experiment here inside Directus now that we can actually link to, a piece of content. So if I go into post dog, we go to experiments. Check installation, skip installation. Skip or no? Skip. I did not remember that part of the creating a project. Alright. So we could see this experiment here inside post hoc. Let's see. There it is. This is all set up. But now let's go and link this to a piece of content. Right. So we're gonna go back to our home page, and we've got our hero block. So this is the control block. I'm just gonna go down to the bottom. And, basically, we've got a a relationship from this block to our experiment, and then we're gonna pick the variant that it belongs to. Except something wasn't quite right. It wouldn't be a demo that I was doing if everything worked smoothly. Why isn't my variant showing up? Clear filters. Experiment. There is the alright. You got me. Let's clean this up just a bit. I've got tried to get fancy, and I've got, I don't know what level of fancy I got here. But, okay. We'll try this again. Now I'm gonna link this to our new homepage headline experiment. We're going to add this to our control, and now we're gonna add another headline. This is the new headline. Amazing. It's gonna look beautiful. We're gonna link it to that same experiment, except now I'm gonna link this to our new headline variant. So all I'm doing behind the scenes here, nothing fancy. I'm just linking this piece of content to the posthog experiment. On the Next. Js front end, we're making a call. We get this content, And, because we've got posthog integrated, we get something like this. If I hit refresh, right, I don't see two hero images or two hero blocks here. I just see one. Right? And that is because of the post hoc SDK that's set up that is handling all the magic, and you could probably understand why I don't want to do all that magic myself. Now let's see if I can actually trigger you're gonna have to show me, like, a a trick to, like, force some type of, visitor into a variant sometime, your eye. Sure. We can do that. Let's see. This should be put in. Yeah. It's it doesn't seem like I can actually trigger the not triggering the variant here for some reason, through this. But, this is how this is actually integrated. This is like a a block level test. Now, you know, if I swap Can you, can you open your web tools? Maybe we can try to override a flag, for this particular page. Yeah. I I Oh, we don't have to do that. That was up to you. Yeah. Yeah. Okay. So there we go. So if you know, now you could see if I swap the control Right? If I make the headline the control, we could see the difference here. And, basically, the post hoc integration is is pulling that all together. So that is, like, the setup inside Directus. Like, if I wanted to run a page, a a reader direct level test, let's say I wanted to have a a new pricing page. Right? If I go to pricing, we've got pricing to fit every budget here. Maybe I wanna change this. We have new pricing. So we'll just create a new page. Pricing to fit no one's budget, and we'll just raise the prices by quite a bit here. Amazing. Alright. So now I'm gonna hit save as copy in this template, and now I've got I've got two new pages or or, well, one new page, but that's our page. I'm gonna go in. And now if I wanna do a redirect level test, I have new pricing page. Pricing page. We'll do a redirect. So the control, here, we're gonna add this URL. So that'll just be slash pricing. And when you set up the control experiment or the control variant, again, that is the URL that you're testing. It's an important distinction to make. Next, we will add the new pricing page. Great. That's gonna be new pricing. And, again, our direct us flow automation, like, will will bring this home for us and basically create this experiment inside post dog. So we'll just hit refresh. We've got our new pricing experiment, and I can click in and and see the the variance here. And as Yurai showed, there's just a feature flag that backs these. Now what we're doing on the page level tests is we're using the post hog feature flag payloads, to avoid making a extra call to direct us for this information. So if we I think I can get a better view if I click edit here, maybe shrink this back a bit. You can kinda see what's going on here. We've got an experiment type. It's a page level test. We've got a control path, so that's our pricing. And then we have a path that we're going to redirect to. And what happens on the front end if we go to local host 3,000. Now if I try to navigate to pricing, I'm either going to get the control did I I guess we may have to dive into the actual tools here. We'll we'll work that out in a moment. Love giving these demos on the fly. Alright. What is next on the agenda? We'll just look at that really quickly. Alright. Our feature flag test. Alright. So we've got the director side of things. We've nailed that piece. And then let's take a look at, like, the Next. Js side. Right? We want to, like, walk through how this is actually set up and integrated. So a a couple important pieces that you need as far as, like, setting this up within Next. Js. Let's pull this up. Alright. Can everybody see this? Okay. Let me try to close close the terminal a bit here. I I can shrink the the size of the make make the font just a little bit bigger. Alright. So, again, once you download this repo, you know, feel free to to browse through it on GitHub. We'll, again, we'll we'll send you all of this. But let's let's start on the direct side of things. Inside this Next. Js application, there are our fetchers. So we're just using these two. Close. Shrink that. Okay. There we go. Alright. So these fetchers are are basically just communicating using the Directus SDK. What we've got here and the only change that we've made from our standard Next. Js template is just making sure we grab the experiment data and the experiment variant that we've linked to a page block. So this all comes together on our, like, our page builder setup that we've got. And one of the other things that you'll have to do inside Directus, you can fetch that data, but you need to be able to add the data to your permissions. So you've got to make sure that your experiment variance and your experiments are enabled underneath your permissions to make this work inside Directus. That is just as far as getting into best practices, that's one of my Directus best practices. At 99% of my errors are because I didn't set permissions. Right? But we have to add that experiment variant there. And then inside what we call the page builder, there's a a bit of logic here that basically, filters out the blocks. So, this template is set up to run Next. Js server components, so we don't get this flash of content, whenever we enroll someone into a variant. But, basically, we're just checking to see, is this block attached to a variant in an experiment? If it is, we get the feature flag from the post halt client, which we'll look at in a moment. And should we add this block? So if the feature flag is found and the block is the control variant, we'll add that control variant. If the feature flag is found and it's not the control variant, we'll make sure we add that to the, to that block. So, not a huge shift in in the logic as far as working with Directus, just simply matching those up. On the post hoc side of it, and this is all we it's just standard boilerplate from the post hoc documentation. You need to have a post hoc provider. So we just set this up using use client here because this provider is going to go into a shared, like, a layout inside this Next. Js application. One of the important bits, especially for, like, server side rendering is the bootstrapping. So, basically, we're getting all the feature flags on the server side from post hoc and making sure we pass that when we initialize the the post hoc JS client on the the client side. And, Yurai, do you have anything to to kinda add on that bootstrapping side? You know? I I know this was, like, one point that was, a a little bit of where I ran into some issues when I was implementing this. No. Not really. I would just say that this this is really the preferred way how to how to get a feature flex to your client, for a couple of reasons. Because the the other alternative is to actually fetch the feature flags directly from the client, but there is always some delay there. So, you know, you you you may get some usage events being sent without correct future flag information if you do it that way. Right? But if you if you bootstrap your flags, that means you always evaluate the flags on the server, which is actually faster because, the POSOC library actually evaluates, the flags there without having to actually go to the POSOC server. So it's actually faster. And once the the web content is served, you already get the feature flags kind of, like, basically already bootstrapped to it. So, this is is actually what what we always recommend, for our users to do. Yeah. Yeah. Makes sense. Now how you do the bootstrapping, it depends on your specific application. The way that we chose to do it in this specific one. So we've got this post hoc provider. There's a there's a shared layout that I'll I'll show you. This is just how we we use this provider. So inside our root layout component, and this is using the the Next. Js app router setup, we are actually, like, sending this bootstrap data in a header from a Next JS middleware. So we get that here. We pass it to our provider, that sends it down through the client. But the middleware is an important piece. Now you you could do this via a, like, a server component and, like, if you're not doing the redirect testing, I found that that worked pretty well. But, as far as, like, the redirects, you probably wanna do this in the Next. Js middleware. Just this is the best way that I've found to do it. So what we've done inside the middleware, if we get to the actual function here. Right? We get the path name that you're sending, you know, what we're navigating to, and then we're basically getting a distinct ID. So this is just a helper that is somewhere, maybe in a where is that guy? Distinct ID. Yep. So a post log gives stores a cookie. We will try to get the distinct ID for that visitor, that user via that cookie. If we can't find it, we're just gonna create one. Right? And then we will look for some cache data inside the cookie. So we've got, like, a a bootstrap cookie, where we're we're caching this data. But, basically, what we're doing to enhance performance and and make sure that you're not, like, delaying rendering every single time, we've got a flag route set up on the API side, which is somewhere. Posthog flags. So, basically, there's a Node. Js posthog client. We pass that distinct ID to it. We go get all the flags and the payloads, and then we're caching that for sixty seconds. So as the user navigates, this middleware gets triggered, and, you know, we're we bootstrap that data. And then we also use this to handle our redirect, at the page level. So we've got a check for redirect function, which basically looks at that flag data that we have here. So once we fetch all of those flags from post hoc, we're iterating through those and saying, okay. Are any of these redirects that we've set up matching this experiment? If so, then we we send them through. You know, there's a a little bit more fancy stuff behind the scenes, but I I know we're coming up on time with this. Is there I I'm trying to think if there's any other, like, important pieces that I wanted to cover before we turn everybody just totally loose on this thing. I don't think so. Let's see. Where's my checklist? Redirect. We've configured the provider. And I saw where is was it Jobchum? Yes. So the that was a good spot. I figured out why this is not working. Thanks to JobChomp. It the public post hoc API key is from my previous project. So that's where I told everybody to take this down, make sure you copy it, but I forgot to stick it into my EMV. And, yeah, that's why we were having issues. Always love it on the demos. That's that's always fun. Alright. That's it. Let's, we'll open it up for q and a. You're I, you know, while we're waiting on questions to come up, I just wanted to say thank you for for jumping on with us and, you know, at least teaching me how to get get more use out of out of the post hoc side of things. Of course. Yeah. It's a it's a it's a pleasure. It's it's a very nice integration that you that you build there. And, we actually have our own kind of, like, no code experimentation tool. It's still very, like, very much in beta. But, we'll I'd love to get access to that. Yeah. Whoever whoever uses, like, just Bosak can actually, like, already try it out. It's it's, like, not nearly as powerful as as as, like, what direct Directus allows right now as in kind of, like, rearranging blocks and, like like, doing all that. It's basically just for, like, simple simple style changes. But, yeah, perhaps there is also something for us to to learn here. Yeah. Yeah. You know, I like, hopefully, like, coming out of this, we'll have, like, a, like, a how to dev blog post to to put this together. But, you know, one of the things that I I just I struggle to find any, like, linking to CMS examples. So, now that we've got one, this is how an integration could work. Let's let's take some questions here from Steven. Do you have a guide on what kind of traffic numbers you need to do effective testing? Yeah. So maybe I can answer that. So like I said, we we have this sample size calculator, which basically tells you exactly that. Now, that calculation is always tied to a particular metric. Right? So if you are tracking five metrics, but each of those metrics has kind of, like, different, like, usage numbers, as in, like, different number of persons that actually generate that metric. To be to be really statistically rigorous, you actually have to take the metric with, kinda like the smallest traffic and make sure that you actually get enough traffic for that metric. Right? Other than that, it's it's it's already like what I mentioned. The the the larger the change you are targeting, the smaller the sample size. But the smaller the change you are targeting means that, you kind of, like you need to have, like, a more sensitive test, and you need a you need a large larger sample size. That makes sense. Alright. One other question I see from Stefan. How would you set up an AB test for global components across multiple pages like a header? Will it be, like, a new type of test that needs to be set up first? It it depends. Like, any good development oriented question, the answer is it depends. But, you know, if you've got the let me just pull up direct us real quick, and then we'll I'll give the bonus link in just a moment. Where's this at? Alright. So, you know, a basically, inside the direct us instance that that we've shown here, on the page block level, we we just added a relationship to the variance. And, you know, we've got the corresponding logic inside the Next. Js application that basically just says, hey. Post all, give me the variance and then assigns one of those. But you could add the same relationship to other pieces of the website if you wanted to, whether that was, you know, your navigation, like, your navigation items, within the setup. So this, this CMS setup has navigation already built into it. You know, you could potentially link it there. You know, you could do, like, a a hybrid approach inside the code where you, you know, you hard code some of these tests, which are, like, a lot of the examples in post hoc just for simplicity's sake are are there. In our own experience, it's like I I tryna I kind of, like, look at it through the lens of, like, hey. Is this something we're we're gonna do often? Like, do I wanna test header elements often? If so, you know, it might make sense to enable your content editors to be able to do that. If it's, you know, like, a one and done test, you might just, add it to the code and and move on. So, hopefully, that's helpful. Let me throw up the well, I'll just post it here in the chat, if I can. What's going on? The screen share is stuck. Why is this not working? Something's going on. Okay. I can't post the link here in the chat. Matt, if you're around, post this link in the chat for me. My screen is fouling up as it often does on these demos. We'll we'll definitely send this out in a newsletter after the webinar as well, but, there's a repo where you can get all the source code. If you have any questions, feel free to follow-up with us. On the Directus side of things, we are also offering a special little promo. And I can't get this to yeah. Hey. The screen share thing is just spinning for me. So that's where we're at with it. Uriah, thanks for joining, man. I really enjoyed this. You know, this has been a fun project, and I I appreciate your support and your help along the way. Likewise. Excellent. We'll have a recording out for everyone. And with that, thank you, and good night. Thank you, everybody. Good luck. Bye bye.","published",[135,149],{"people_id":136},{"id":137,"first_name":138,"last_name":139,"avatar":140,"bio":141,"links":142},"791e1503-1d88-463d-9347-0b9192933576","Bryant","Gillespie","9013afc8-e8d7-4182-9b18-44db08117bb9","Developer Advocate at Directus",[143,146],{"url":144,"service":145},"https://directus.io/team/bryant-gillespie","website",{"service":147,"url":148},"github","https://github.com/bryantgillespie",{"people_id":150},{"id":151,"first_name":152,"last_name":153,"avatar":154,"bio":8,"links":155},"190b7533-6d11-46e4-bc7c-71579efb3fe7","Juraj","Majerik","e01c8e0f-527a-4368-86f8-38f267f67ac1",[156,158],{"service":145,"url":157},"https://posthog.com",{"service":159,"url":160},"linkedin","https://www.linkedin.com/in/jurajmajerik/",[],{"id":163,"number":164,"year":165,"episodes":166,"show":170},"181a77a7-65c5-46b3-9e4f-474acc00436a",1,"2024",[167,168,122,169],"bb508a73-7947-4be9-8493-a226861cfe7c","b0159a9d-73b5-432e-b2a4-b3f606f8ba96","45133ec4-b8c7-4989-83a3-b0b46c20835c",{"title":171,"tile":172},"Enter the Workshop","e9e9a7a1-29f9-4bab-b486-d75e385a9d13",{"title":8,"meta_description":8},{"id":169,"slug":175,"season":163,"vimeo_id":176,"description":177,"tile":178,"length":8,"resources":8,"people":8,"episode_number":179,"published":180,"title":181,"video_transcript_html":182,"video_transcript_text":183,"content":8,"seo":184,"status":133,"episode_people":185,"recommendations":188},"advanced-content-workflows-inngest","1067367779","Join us and our friends at Inngest to learn all about building advanced content workflows and orchestrating automated localization for content in different languages. ","f0228f3a-bc39-4151-b6fd-55594af0f637",4,"2025-03-20","Build Advanced Content Workflows: A Deep Dive with Directus + Inngest","\u003Cp>Speaker 0: With Directus and Inngest. I'm your host on the Directus side, Bryant Gillespie, developer advocate, growth engineer, professional hack and slash developer over here at Directus. Super excited for today. Got a special guest that I'll introduce in just a moment. We should have a good time.\u003C/p>\n\u003Cp>We kinda reworked the slide deck a bit last minute, as I tend to do. But before we dive into introductions, let's just take a look at what's on the agenda. Alright. So we'll go through some super awkward introductions in just a moment. We'll deep dive into what is ingest, what powers ingest behind the scenes, why you would wanna use ingest, then we'll get into why Directus and ingest are a great pair together.\u003C/p>\n\u003Cp>And then we're gonna run through this advanced content workflow after we've, walked through this integration of invincible automatic localization, for your content, which is always a beast. So with that, I want to kick over to mister Dan. Dan, how are you, sir?\u003C/p>\n\u003Cp>Speaker 1: Great. Great, Brian. Thanks for thanks for having me. Stoked about stoked about doing this. Thanks everyone for joining as well.\u003C/p>\n\u003Cp>My name is Dan, and I'm the CTO and cofounder at a company called Jest. And we'll, we'll get into a little bit more about what that is and, what we're doing today and, why you've joined. But, yeah, just thanks for joining, and I'm stoked about the stuff that Brian, Brian kicked off today.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Yeah. And, Abel, like, for for some context and backstory, like, I first found ingest, we were working on a project we were calling Event OS. And, Direct has made it a breeze to set this up, get some APIs to work with inside a Nuxt application, but it's not dissimilar from the platform you use to register for this event. One of the the main challenges was, like, how do we send notifications and, like, how do we set up reminders an hour before an event and still have that be robust, like, cancellable in case we move the event, you know, and all sorts of things that we're gonna cover today.\u003C/p>\n\u003Cp>So that was my introduction to ingest, and frankly, I was kinda blown away. I I don't think if Matt is here in the chat, I was like, man, we gotta get these guys on a partner webinar, and voila, here we are. So with that, we'll just drag the little slide deck over. And what's up next is what is ingest? So I'll kick it over to you, Dan, and, you know, let you dive into ingest a little bit deeper for those who are unfamiliar.\u003C/p>\n\u003Cp>Speaker 1: Great. Thanks, Brian. Appreciate it. So I'm gonna give you a little high level overview today, and we're a technical audience, so have a little bit more of a a technical variant on slides today. So, if anyone needs things a little bit bigger, tell me to bump it up in the chat.\u003C/p>\n\u003Cp>I'll try to respond if there's anything. So yeah. So, basically, what is Ingest? Okay. What you can basically think about it as the at the high level is that Ingest is a workflow orchestration platform that enables you to run reliable asynchronous jobs anywhere.\u003C/p>\n\u003Cp>We're gonna get come back to that in just a just a minute or two. So why would you use ingest for this this task, this need? What ingest allows you to do is to define these step functions. So you're creating workflows directly in your existing code base, use our SDKs, and any logic that you're used to. There's no DAGs or really obscure complex DSLs to learn to build these, powerful functions using regular code.\u003C/p>\n\u003Cp>So they're also reliable by default. So everything that you run with ingest automatically is retries. I think we've probably a lot of people here have built systems where, things go wrong. An API goes down for a few minutes, there's a blip, there's a networking thing, there's a race condition that happens in your database, and all simple retry a few seconds later would solve your problem. So ingest does that by default, and it also includes, something that is called durable execution.\u003C/p>\n\u003Cp>You may have heard this term, and if you haven't, you can think of this as your code is designed to be fault tolerant and survive catastrophic failovers, basically. So I won't get too deep into that topic today, but there's plenty of resources that we can send you after if you are curious. The last thing is that we've built in queuing and flow control right into ingest so that you can go to production confidently. What that means is that there are concurrency management built into the system that you don't need to have run a a worker or a queue or anything like that. You just define it in your code very simply.\u003C/p>\n\u003Cp>You also have controls for multi tenant support, which is another advanced topic we won't get into yet today. But you can just kind of anything that you might have built into some sort of, asynchronous system that you might need is there at your fingertips with easy configuration like throttling, rate limiting, delaying the start of jobs, debouncing, batch processing, dynamically prioritize prioritizing certain jobs, as well as running work in parallel or fanning out to multiple jobs. So that's at the high level, but realistically, okay, what can I build with ingest? So let's just you know, at the highest level in general thing is ingest is a general purpose tool, and you can run any background task. Something simple, just one function, one operation to something that is that is very complex and has to orchestrate between different process.\u003C/p>\n\u003Cp>So you also have the control in your hands. You can control the flow of the logic with if statements, not DAGs, and you can kinda build whatever you want. So I'll give you a little taste of, you know, with this audience, which is technical, and I'm sure a lot of y'all are interested or already users of Directus. You know, what might work in or make sense in your in your situation or what you might be building? So one of the first things that's very hot, sure a lot of you are dabbling or building already, pushing these things to production is AI workflows.\u003C/p>\n\u003Cp>So you can handle the complexity of things like flaky LOM API calls that might fail, things like chaining, building agent loops, calling tools if you're getting that advanced, or do things like human in the loop flows. You know, you're you're proving the work that that, LLM did for you. So this might be a research AI workflow. Go out and get all this data and pull it back and store it somewhere, or you might be creating content. That kinda leads me into content processing, which is where you might be pre or post processing some content.\u003C/p>\n\u003Cp>It might be a blog post or could be static assets that are in your system like images or videos. You might be doing things like translating, resizing, transcribing more to those assets. You might need to kind of create a complex pipeline. So one example here is that you you might be taking data, from your, your Directus system and you might be piping that into maybe a React SVG library and generating visual assets on the fly for your content and then uploading it to where you're storing, your assets. You know, another thing there, like, kind of beyond content is is user journey automation.\u003C/p>\n\u003Cp>Brian said at the top something about scheduling emails with events and and and and that and and whatnot. Within just, sorry, Brian.\u003C/p>\n\u003Cp>Speaker 0: No. No. That was a huge one for me, man. That was, that was, like, my introduction to it, and I think that was, like, one of the one of the first case studies or something I ran across in the docs of, like, hey. Just something as simple as let me sign a user up and then wait a day and send them something Yeah.\u003C/p>\n\u003Cp>Incredibly convoluted in other systems.\u003C/p>\n\u003Cp>Speaker 1: Yeah. And and you know what? You might have this thing where you could some systems might allow you to schedule an email in the future, or you might have a cron based system. But what if you could just, you know, prepare something, do some operation maybe like you're sending somebody you know, you're sending someone an invite, and then that invite email goes out. And then twenty four hours before the event, you might wanna schedule and say, let's render this email.\u003C/p>\n\u003Cp>Might be using, say, React email, which is awesome, and, pulling in data from different sources and sending that person a personalized email twenty four hours ahead. Or you might wanna customize, hey. This user is in this time stamp. So you might wanna, like, have more control sorry, time, time stamp, time zone. So you might wanna have, like, a time aware thing.\u003C/p>\n\u003Cp>So you could use something like another complex tool or, whatever is within an event platform that you're doing or something like Intercom or HubSpot, but that can be either not very controllable. You can't bring in custom logic and code. It's very static. They're crazy expensive, for those purposes. So you kinda do whatever you want here.\u003C/p>\n\u003Cp>Build flows that are scheduling delays, Slack notification, even like things like provisioning resources or provisioning access. So, that's a fun kinda use case. You can kinda build anything triggered with these vents. I'll go through a couple of these other ones because these are kinda secondary. But, you know, if you're integrating your system with a third party webhook, maybe something like integrating Stripe payments somehow into in into your system, or maybe you're using a system like Mux, and you're uploading your video assets to Mux, but you need to do something in your Directus CMS after those videos are uploaded, you can use a webhook.\u003C/p>\n\u003Cp>And you can those events can go to ingest and trigger your functions to run your Directus instance. So you can kind of build more advanced integrations with more control that you might need. And the last thing that happens in a lot of systems is there's always data from one source to another to another place. So you might have just data import jobs. Kind of think about it like you're building ETL jobs or just pipelines or synchronization, but you don't, you know, you you don't need anything like a complex data science tool or, something that a data engineer might use like an airflow or something like that.\u003C/p>\n\u003Cp>So you can build kind of anything in this, but I hope these are kind of ideas that might work with, what you're already doing with Directus. So I'll go from there, and I'll, I'll get to that question in a little bit. We have some time at the end as well. And, I'll go and just show, like, a little bit of functions. You this again is a technical audience, so let's just show some code about how you build an Ingest function and how it works.\u003C/p>\n\u003Cp>So I'll run through this. Basically, what you're doing here is you're creating the Ingest function. It's pretty simple. You define it in your existing code base along with your directus functions, your directus logic and whatnot, your whole system. You can do things like define queuing or flow control right at the top of the function very easily.\u003C/p>\n\u003Cp>So if, for example, you just wanted to run this job, at most 30 times in sixty seconds and you wanted to max out at three retries or 15 retries, you can control these things very easily and the ingest system will just do it automatically for you. You don't need to battle queues and infrastructure for that. You also declaratively define the event that will trigger your function. So in this case, when a blog post is drafted, run this code. And then bay very simply, you define a function right here, which is a handler that has all your code.\u003C/p>\n\u003Cp>If you're thinking about what I talked about before which is workflows, steps, and whatnot, when you're defining ingest functions, all you need to do is learn a couple building blocks which are steps. The main one is step dot run. Basically, you can encapsulate some sort of business logic, some sort of side effect, and you can perform an operation in there. Each time you run code within one of these, it's automatically retried if it fails as per your retry policy. And if this does succeed, if there's any failures later in the function, it won't be retried.\u003C/p>\n\u003Cp>We cache those results and save them. So it makes your function a little durable if you're familiar with that term or fault tolerant, you know, that's the the a la the, durable execution side of things. So, basically what you're doing is you're defining steps and multiple steps to build out your workflow. You can use normal if logic. You can dynamically define steps on the fly.\u003C/p>\n\u003Cp>You do not need to predefine them, which is really great. And that's the building blocks. But what's interesting is that there's more power to these these these basic primitives of steps that you have. So here's one example that might tie back to what we were just talking about, which are that you can pause workflows and wait for approval. So you can or wait for other data to happen, other events.\u003C/p>\n\u003Cp>So you could build things that run, process some, you know, some data, and then wait for maybe an approval or maybe something else in your system to be updated, like a draft or publish status or something, and you can resume your function. So ingest your code will not be running. Ingest basically holds on to the state of your function. And then when it gets that event, it resumes and restarts your function from where it stopped, doing some different kind of magic and whatnot. So then again, you can use that approval to dynamically, you know, traverse and and run different steps.\u003C/p>\n\u003Cp>You can also do things that are a little bit, you know, kind of outside of this this this thing that are that are kind of extending the power, which are making reliable calls to LLMs by offloading those AI calls to ingest servers. You can also do things like what Brian talked about, which are basically use other types of steps like sleeps or delays. So you can delay to an exact time and then resume the code then, or you can delay to an arbitrary number of days or hours or weeks, and then your code resumes. So these are kinda just the the basic building blocks. There's a couple more that I didn't get into.\u003C/p>\n\u003Cp>But if you can learn these couple primitives, you can build a lot of complex logic that also is very reliable outside of box. So, you know, going from here, I'll just take a step back and look at the architecture. And, Brian, how are we doing on time right now?\u003C/p>\n\u003Cp>Speaker 0: We are we're no. We're golden.\u003C/p>\n\u003Cp>Speaker 1: Can you see? Okay.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Yeah. No. I just yeah. No.\u003C/p>\n\u003Cp>We're beautiful. No worries. I I I did just wanna say, like, the hey, like, the the background jobs and and, like, some of the the queuing stuff was what got me in the door. But, like, the the durable execution piece, especially when you're working with, like, the LLM stuff, after you've you've used, like, one of these big models where you could just literally watch credits evaporate when a function fails is, has been a, like, a nice piece for my workflow. So, kudos there.\u003C/p>\n\u003Cp>Speaker 1: Yeah. Thank you. Thank you. Appreciate that. And, yes, to the to the, to the audience, yes.\u003C/p>\n\u003Cp>Using, step dot a I dot infer, if you're running in serverless because with something like Vercel, it can offload it to our servers. So your function stops running. It's not consuming any any compute and it offloads. So that was an easy one to jump in there. Thanks for that question.\u003C/p>\n\u003Cp>Yeah. I'll jump into the architecture because I wanna show you how it works with Directus and how the system is. So basically, at at the high level, this is a little, you know, you don't need to know, like, know everything in detail. I'll try to zoom and see if I can pinch in a little bit. There we go.\u003C/p>\n\u003Cp>So the ingest system comprises a bunch of things that you might typically build or need to to execute this and do this yourself. So and there's much more beyond that. But the fundamental thing is there's an event API that receives data from anywhere, could be from your direct assistance or the webhook, And there's, something that consumes those events and basically, creates new jobs and enqueues them. It stores the state of those jobs. It stores the history of those jobs in case there's a problem or anything or you wanna observe that later, which we'll get to, then it executes those jobs.\u003C/p>\n\u003Cp>And what happens is the ingest knows, okay, I'm running this function and it toasted on your direct instance. Your code is sitting in your direct instance, and it invokes it via HTTP. So it securely just calls it when it needs to, invokes the minimum number of work, and then returns to ingest. And then if it needs to resume or continue, it will make other calls as necessary. So if you sleep, it goes back to ingest, then it calls your server again later.\u003C/p>\n\u003Cp>So this is the basic kind of principle of how all the systems work together and how there's a queue built into the system that is basically pushing work to your system. And that's why it's really key to have the flow controls. You know, you don't want to you wanna set something like throttling because you don't wanna overwhelm and knock down your system or your database in case you're processing, say, a huge backlog of 10,000 or 10,000,000, jobs or tasks that you need to do. So this is really key and also just shows that the code that you write is hosted on your, your machine. It's where you have it.\u003C/p>\n\u003Cp>You keep it along with your existing, direct as code base, which is really great. So I'll, I'll show you a little bit about, like, why do we have a database, what is this dashboard UI. So when you're running these long jobs that are happening behind the scenes, they're often hard to observe. I'm sure that some of you have worked in systems where you're parsing just logs on CloudWatch or something like that. You're trying to figure out what's the status of this job.\u003C/p>\n\u003Cp>Okay. Now we need to chuck it into a database so we can observe this. And you're trying to piece together what happened and where things failed. So we get to that one question in one second. So what we have is we have a dashboard that gives you visibility into the system.\u003C/p>\n\u003Cp>So this is the ingest dashboard and ingest cloud where you can see the the output or status of all the different workflows and functions that you've run-in your system, and then you can expand these to see all the different steps and what might have failed, what have might retried, the outputs of those steps, some metadata that you might pull through like, say, tokens in the model that you might have used to make an AI call or the time stamp when something started or ended. You also can look at inputs, say, okay. What piece of content triggered this? You can debug what actually happened and understand, did this work? You can easily cancel and retry these things or retry them in bulk.\u003C/p>\n\u003Cp>There's a lot of operations you could do, but this is the core of, like, this observability that you have into the system. So in also at the, like, the highest level, you can see broad system level metrics, like what functions have failed. Is my import data pipeline failing at a high rate? What what's happening? I need to look into this.\u003C/p>\n\u003Cp>So it gives you this kind of overall picture of how the system is go is going where it's it might be doing things always in the background. It's it aren't always automatically visible. And you can run many functions and have all different types of, functions and workflows like generating video transcripts or creating chat completions or daily digest. You you just get the single pane of glass of, like, understanding what's running in my system. And so the point of concurrent runs that, was asked in the, in the, in the chat, what happens is basically, like, ingest, can can execute multiple things at a given time.\u003C/p>\n\u003Cp>Depending on your plan and your configuration, you can limit how much concurrency you want. So you can control I only wanna execute 1,000 things at a time, or you might have multiple servers that you've horizontally scaled to handle more load. You can control individually what that is. You can also with the multi tenant controls can can control how many concurrent jobs a given user gets. So you can limit it like that in case you're building that type of system.\u003C/p>\n\u003Cp>But, ingest handles that because it it it does the it actually processes the the work off the queue internally. It can you basically declaratively say, this is the concurrent number of like, amount of work that I wanna run. So that's a that's a great question though. So, you know, basically, to summarize, like, this part, there's why are we here? We're talking about in ingest and direct us.\u003C/p>\n\u003Cp>Right? So tie back a couple things that I that I went over. It's the same code base that you're already running. It's the same server. You get to take right.\u003C/p>\n\u003Cp>Use the ingest SDK to define the functions right in the same code base with everything else that you're using with Directus, and there's no additional compute necessary. And, and, Brian, you got some? No.\u003C/p>\n\u003Cp>Speaker 0: No. I was just jumping back in as we transition.\u003C/p>\n\u003Cp>Speaker 1: Yeah. I'll, I'll I'll, Brian's gonna go in a lot deeper about this, which I'm which I'm stoked for all y'all to see because he's built some really cool things. And and some of the things again, this is fault tolerance, the async workflows, you know, so you get the confidence, automatic retries, and control over these processes. And remember that steps encapsulate these retryable logic. You can bring existing logic, import new libraries, whatever the heck you want, write any workflow.\u003C/p>\n\u003Cp>And one thing that Brian will go deep on this, I think, is super cool about how it works together is Directus, hooks are super cool because it kinda provides this nice link between the direct to system and ingest functions, but I won't spoil anything there. I'll, I'll pass over to Brian to kinda take it from here. But, and then we can go to if there's any other questions, we'd probably go to the the QA afterwards so we can get through some of these things.\u003C/p>\n\u003Cp>Speaker 0: Some of\u003C/p>\n\u003Cp>Speaker 1: the questions might be answered.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Definitely. So I pop the questions into the chat. We'll get to them if we can. I'll take the screen back, and we'll briefly cover what is Directus.\u003C/p>\n\u003Cp>For those, who are joining, who are not familiar, Directus is I I like to call it LEGO for developers where, like, everything that you need to build a digital experience, whether it's an app, a website, automatic content translation, which we're gonna do today, it it's all there for you. And you're just stacking these bricks together a lot like, what Dan was mentioning with ingest of, you know, these primitives that you have, and you could use them to build really powerful stuff. So Directus will give you intuitive UI, which we'll look at in a moment, a nice, like, admin CMS layer. You get instant rest and GraphQL APIs on top of any SQL database, and this is all self hostable. You can also run-in our cloud as well.\u003C/p>\n\u003Cp>And just a little tiny, fine print there of any, should be like most SQL databases. Right? Alright. So why Directus? Why ingest?\u003C/p>\n\u003Cp>Why together? A couple things. Like, Dan already mentioned, you know, the hooks that we have in Directus make this super easy to communicate with ingest. But more than that, ingest gives you that durable execution. To say being able to build these powerful workflows in code is tremendous.\u003C/p>\n\u003Cp>So the first question that, I was asked when I was putting this webinar together, and and this is from our team was, hey. Why why ingest when we already have automations inside Directus? So if you're still learning Directus, we have an automations module called Directus flows, and it is allows you to define a low code, no code automations. You know, when something happens, do this. These flows are great for short lived automations.\u003C/p>\n\u003Cp>Some of the things that that Dan showed in the previous slide where we have the syntax of, like, the step function, Directus doesn't have the ability inside a flow to wait for thirty days and send an email or to, wait for another event inside of a flow, without some complicated logic tying it all together. So flows are great for short lived automations or automations that that don't have super complex logic, and ingest is a great complement to flows. And, you know, in the future, I could even see us having an extension to trigger ingest, functions inside a flow. But, as we get into flows versus hooks versus extensions, as as Dan mentioned, Directus flows underneath the hood once you pull off the the mask here, the the Scooby Doo, I kinda mean, is just using Directus hooks. So, Directus hooks, if we pull up my browser, which is always dangerous since I'm using Arc, Directus hooks are just code that fires whenever certain events occur, and you've got a lot of different hooks at your disposal.\u003C/p>\n\u003Cp>This is using custom extensions, and we'll kinda cover that in just a minute. But at the core, hooks are allowing you to say, hey. When this event happens at Directus, do this. And, we'll we're leveraging these hooks extensively in this integration. So there's filter hooks, which happen before the event is emitted.\u003C/p>\n\u003Cp>So if I wanna run some code to either modify the payload before an item gets created or potentially stop that from occurring, I could do that via a filter hook. And then the ones that we're leveraging today in this workflow are gonna be our action hooks. So when after an item gets created, we wanna do something. In this case, it's going to be sending those events to ingest. Alright.\u003C/p>\n\u003Cp>Any questions on hooks before we kinda dive into this? We've also got, like, an endpoint that we're gonna use, and I I just wanna take a moment to touch on one of the most important pieces of Directus is this extensibility. So if you go into our documentation, which is a a great starting point after this webinar, take a look at the extensions overview. You could customize every piece of Directus. So you could customize the interfaces, like how the data is displayed inside the studio.\u003C/p>\n\u003Cp>But the parts that we're leveraging today are API extensions. The hooks, endpoints, operations are within flows, and, of course, bundles are how we put all these together and distribute them. Alright. So how do we make Directus and Ingest play nice? And this was the part that, I did the heavy lifting on with some help from Dan and his team.\u003C/p>\n\u003Cp>You're still blown away by how easy it is to write ingest functions. It really just kinda gets out of the way. And and once you guys go through this process and set this up and and don't worry. Wait. There's more type of moment here.\u003C/p>\n\u003Cp>We're we're gonna give you the whole code base as the bonus after this, so don't worry about taking notes or screenshots or anything like that. But, once you've got this set up, then you can build really incredible stuff, with the incredible pace, I would say. Alright, so I'm going to open up my code editor here and we're gonna take a look at the first piece of the puzzle which is our environment setup. And for Directus projects this almost always starts with a Docker composed file. So this is the pretty standard boilerplate Docker composed from, our documentation.\u003C/p>\n\u003Cp>I've I've done just a little bit of cleanup here and extracted some of these things out to environment variables versus, just inlining them. And a couple things that I want to note, when you spin up Directus, especially, like, using our standard Docker Compose, which we're using Postgres for the database, Directus will create this, this folder structure for you with the database, the extensions. This template is is just for applying the schema that we've got for this example, but, it will create all of that for you. And for a cleaner DX, I've basically just extracted this custom Directus extension out to the root in a queue folder. So this entire code base, I've I've gone through the trouble of trying to make comments, to to add a little bit of what I was thinking as we went through here.\u003C/p>\n\u003Cp>But all the the rest of this is pretty standard with the exception of a different port. I'm sure Dan can relate to this as you're developing. You've got, like, 35 instances of your product running on your local machine at one given time, so you gotta switch these ports over. The only addition here is the ingest dev server. So the ingest dev server, they've got a a docker image that you could pull.\u003C/p>\n\u003Cp>You can also run this via NPM too. Right? Dan, a node?\u003C/p>\n\u003Cp>Speaker 1: Yeah. Yeah. You can. You can install the binary via MPX or NPM.\u003C/p>\n\u003Cp>Speaker 0: Perfect. Perfect. Yeah. So, you know, we highly recommend Docker if you're working with Directus, but, you know, you could run this, ingest dev server using NPM if you prefer. But I just wanted to point this out like we've got it pointing to our direct assistance, and this is running on port eight two eight eight.\u003C/p>\n\u003Cp>The dev server is amazing for running locally. It's almost, identical to the ingest cloud dashboard, with a few exceptions. And, you know, one thing I do wanna call out, and I think Dan already iterated on it, is your ingest functions, unless you're doing, like, the the LLM infer that that Dan mentioned, these are all running on your same Directus instance whether you're using the dev server or ingest cloud. So I just wanted to call that piece out. Now for the environment that we've got set up here, you could see when you go to production and just has event signing keys or event keys and signing keys so you could keep, things very secure.\u003C/p>\n\u003Cp>For purposes here, we're just running, on the dev mode, keep it lightweight, make it easy to iterate. One thing to note, when we get into the translation workflow, we are using DeepL, so I've just got that environment variable. So when we are configuring a Directus extension, Directus has a extensions SDK that makes this process super easy. I just bang in this command into my terminal, n p x create direct us extension. Make sure you use the at latest tag to to pull that.\u003C/p>\n\u003Cp>And what you're going to initialize, I'll just show you kinda what this looks like, is a bundle extension. MPX Directus create extension at latest. This will ask you to install, and then we will go through and choose a bundle. And this is where my Internet just totally craps the bed apparently. Too many connections at once.\u003C/p>\n\u003Cp>Okay. Yep. So we scroll down, we hit a bundle, and a bundle is just a collection of these extensions. Now once you initialize that, it will look something like this. Where are we?\u003C/p>\n\u003Cp>So I've I've got this in our queue set up. You could see here we've got our Directus extension. It is a type of bundle, and then to add extensions to that bundle you run npm add or npm run add or p npm add, whichever package manager that you're using. So as far as the ingest setup here, let's dive into what that actually looks like. And, again, we're gonna give you access to all of this code.\u003C/p>\n\u003Cp>So at the high level here, we've got a function folder that stores all of our functions. We've got some hooks that we'll take a look at, and then we have this ingest client. So how do we set this up? How do we make sure it connects securely and plays nice with Directus? We are pulling in from the ingest package, and we're gonna skip this little middleware piece, but this create ingest client basically just returning a new ingest client that we can use to invoke these functions.\u003C/p>\n\u003Cp>Now the middleware piece here is rather important. Basically, all we're doing here is some dependency injection to use direct to services, like creating an item, updating an item, sending a notification to our user. So that's an important piece of the puzzle. There's a a couple things like a helper function in here to set the directest context so we can leverage that. And then we're just basically using a singleton pattern for this ingest client so that, you know, we're we're using the same client over and over.\u003C/p>\n\u003Cp>Setting this up and, you know, ingest needs to be able to serve those functions. So, in that we've got a endpoint that we define. So this is a custom direct us endpoint. You know, you can see some some standard, imports here. This is where we're actually going to import those functions.\u003C/p>\n\u003Cp>We'll show that in in just a few, but we're basically defining an endpoint. The ID here is gonna be the route that this gets served on. So, I'm using ingest. If I go to local host eight zero eight eight slash ingest, that's where my functions will be served from. And you can see here when we're defining an endpoint, we get the express router instance, and then we get the direct us context.\u003C/p>\n\u003Cp>And that is what we are calling here or or what we're passing when we set the directest context so that ingest has access to those directest services. Very important piece. If you're setting this up on your own, don't, don't forget that part of it. Last but not least, we'll basically just serve the ingest client here. You can see the syntax we're passing in the client that we've set up, and then we're giving it the functions to serve.\u003C/p>\n\u003Cp>Now the last piece of making these actually talk to each other is the direct us hooks. Right? So, we've got our hooks set up. The famous handler. I see.\u003C/p>\n\u003Cp>Not sure what you mean by that, Bazar, but, I we can unpack that in the q and a for sure. Alright. So hooks. Right? Again, we're just defining these actions that we want to run whenever a certain event occurs.\u003C/p>\n\u003Cp>And I was I was using I I won't say I was using this wrong, but Dan definitely gave me a level up, while we were prepping for this webinar. So, breaking these down. Right? We're using the action hooks inside Directus. So I only want to invoke a ingest function after a certain thing occurs, not not necessarily before.\u003C/p>\n\u003Cp>So if we break this down, whenever a post so we'll get into our data model in a moment, but whenever our post gets updated, we are going to send, ingest an event that our posts were updated and we're gonna pass the the event from Directus and this accountability object from our context, which is basically this is the user permissions and, like, the user ID and things like that. Is this user going to have access to actually update that post, after we do the translations that we take a look at. So\u003C/p>\n\u003Cp>Speaker 1: one\u003C/p>\n\u003Cp>Speaker 0: of the things that I I do wanna recommend as you go through this, mirror the event names inside your ingest functions from your direct us, events. So you could see this syntax here. Basically, I've just added direct us in case we've got some other service that we want to send events to ingest from. But here, I've just mirrored the syntax and the reason why, and Dan schooled me on this, is it makes it easier to debug and trace these things through your application, especially if you want to trigger multiple ingest functions on a post update or when a post gets created. Alright.\u003C/p>\n\u003Cp>So the last piece of our puzzle. Right? We've added hooks. We will create our ingest functions, and we'll take a look at that. We'll share this amazing slide deck at the end of this as well.\u003C/p>\n\u003Cp>But we've got a full guide if you've already got a direct us project and you just wanna walk through integrating this. We've got a full guide that we've written on our documentation for you to check out as well. Alright. So, Dan, I'm gonna bring you back. This was your diagram.\u003C/p>\n\u003Cp>You know, maybe maybe kinda touch on how this works a bit.\u003C/p>\n\u003Cp>Speaker 1: Yeah. Yeah. So I think, Brent really laid it out really well here in that. He just showed where with the extension and direct us hooks, that's where we're we're hooking to these actions and just broadcasting basically events over to ingest. So So those events, are basically declaring what happened within the direct to simple, system.\u003C/p>\n\u003Cp>And then our ingest functions, will declare when they run. Right? We we saw that before when I walked through some code. You declare when something happens, this is when I wanna run. So instead of directly invoking jobs, this allows you to decouple and also build things independently and do things like fan out, as Brian alluded to.\u003C/p>\n\u003Cp>So the ingest system basically understands what your function, your workflows, want to do when, and it basically routes them through back to to, to your server. So at the highest level, that's how we're stitching together the hooks with events ingest and then back to the back to the system to to call your code.\u003C/p>\n\u003Cp>Speaker 0: Beautiful. Beautiful. I I love the love the diagram, and it like, this was a a big reason why we shifted to this format to make it feel a little more interactive, a little more fun. So all that said. Right?\u003C/p>\n\u003Cp>Now to the main event of, like, hey. We we've got this set up. These two are talking together. How are we going to build this advanced workflow? What are we gonna build?\u003C/p>\n\u003Cp>So we're gonna show you guys content translations that are automatic and, of course, durable, and I will say totally unbreakable because I know I've written a lot of the code, but but very, very durable, and, like, an incredible workflow for, anybody on your content team that needs to handle translations. So if you've worked with content translations and other systems, this GIF probably holds true. It is so much fun, probably involving, like, a lot of spreadsheets, a lot of working back and forth with either different contractors or different team members. Directus makes that whole process a lot easier. We've got a beautiful interface for it, and, I think Matt on our team is gonna kill me for saying beautiful intuitive interface.\u003C/p>\n\u003Cp>But let's dive into why this why this sucks. Right? We're gonna do this manually as kind of the first step that usually involves those spreadsheets, then we can graduate to APIs. The one we're using today is DeepL, but, you know, Chat GPT and some of the other LLMs have gotten incredibly good at translations. Kind of a toss-up there between speed, DeepL, I've found is is really quick, and, it seems to be highly accurate.\u003C/p>\n\u003Cp>But as you get into that, especially when you're translating a lot of content, you run into, hey. This is gonna take a while. And as Dan alluded to, I've already ran into this, like, 35 times through the, building of this thing is, oops, we hit the rate limit of the APIs or one of those API calls fails. What happens? Right?\u003C/p>\n\u003Cp>Then we lose not only our data, so, you know, we just hope and pray that there's some logs that we can go back and get some of that data, from their side or, you know, just evaporates. So, this is what we seek to fix inside this workflow. And before I show you Directus and Ingest, I want to take a look at our our data model at a high level. Now, this is a simplified example, and I guarantee you when you go to production, you've got a lot of content that you're gonna translate that it probably has a more complex structure than this. But, I do wanna give you this, like, again, we're gonna give you the whole code base.\u003C/p>\n\u003Cp>You could take this and run with it, and so this starting point will make it easy for you to adapt to those, those more complex models. At the high level, we've got a post. The post has a title, a slug, and some content. Now, there's also a languages collection inside the Directus instance. Whenever you use our translations interface, we will create that for you if you don't have it already.\u003C/p>\n\u003Cp>The format is pretty standard. We have a code like in US, the name English direction, and then one of the additions I've added here is just a DeepL translation code because their API, doesn't necessarily follow the standard ISO codes. And then for each, post that we're gonna translate we have a relationship to a collection or a SQL table called post translations. So within that we have a pointer back to our language and then we have our title, slug, and content. So at a high level that's the data model we're working with.\u003C/p>\n\u003Cp>Let's kind of pull this up and and see what this actually looks like. Alright. Dan's gonna laugh at me here. I'm sure to mess up Arc here. Still haven't mastered the side by side in Arc.\u003C/p>\n\u003Cp>So over here on the left, I've got our, ingest dev server up and running. If I go in here, you could see I I don't have any runs yet, But over here on the right is our special themed version of Directus just for the ingest webinar. I really dig the the black and green vibes that you guys have on the website, Dan, by the way.\u003C/p>\n\u003Cp>Speaker 1: Same. Okay.\u003C/p>\n\u003Cp>Speaker 0: Nice. Alright. So, if we take a look at this, right, this is a beautiful gosh. I gotta stop saying beautiful, Matt. Intuitive interface for all of our content editors.\u003C/p>\n\u003Cp>We could see the default language up here at the top. So we're writing this in English. We're gonna pass that to the DeepL API. When we send this translation over, you know, I could set this and and write in whatever default language that I want, and we'll handle the translations. Directus gives you this beautiful side by side view for your translations, and we can see that all of these different languages in our system are fully translated.\u003C/p>\n\u003Cp>So, the flow that we're gonna set up, and I'll I'll walk through this in a minute, is we're gonna take any post anytime a a change happens or we create a new post, we're gonna fetch all the languages that we have that we wanna translate content for, and we're gonna go and actually translate that. Beautiful. Alright. So let's take a look at this invincible translation workflow. And usually I do this kinda in code, at the top of my document.\u003C/p>\n\u003Cp>I break this down. Since we did this format, I wanted to make it a little more visual, and I'll still walk you through the actual code for this. So at the start of this, what will happen and what I left off of this diagram is the user event. Right? User creates a new post, and then that kicks off the process here.\u003C/p>\n\u003Cp>So we're gonna send the post ID, we call it a key, to this workflow. And the first step is gonna be normalizing these event keys because the Directus, event emitter, like if we do post dot update we get an array of keys versus like post dot create we just get a string for the key. So we're gonna normalize those keys. We'll check and see if relevant fields have changed. So if nothing has changed on an update, doesn't make any sense to actually build these translations again.\u003C/p>\n\u003Cp>If something has changed, we're going to retrieve all the translations for that existing post, and that's an important piece. Again, you know, we don't wanna translate content if we don't have to, if it hasn't changed. This is gonna be using, Directus item service, so we'll dive into the code in just a moment. We have, we'll get all of our available languages via the direct Us item service again. We'll use both of those to build a list of translation items.\u003C/p>\n\u003Cp>So what do we actually need to translate? We'll fire those off using, the ingest step functions to the DeepL API and we're gonna do that in parallel and we'll also loop over those so we get that nice tracking and observability. We'll log any errors and then when we get that back we're going to upsert into the database and potentially notify the user. So that's the flow at a high level. Let's take a look at the actual code.\u003C/p>\n\u003Cp>And, Dan, if I gloss over something or I miss something on the ingest side, definitely call me out for it.\u003C/p>\n\u003Cp>Speaker 1: Will do.\u003C/p>\n\u003Cp>Speaker 0: Perfect. Alright. So, again, you can see here, this is, these are the two hooks that we're using to actually manage this workflow. So whenever an item gets updated, we send ingest, hey. We updated this, or we say, hey.\u003C/p>\n\u003Cp>We created this. And then our function looks like this. And, this is not the shortest function I've ever written, but definitely not the longest. I'll say that. So, again, an outline of the translate workflow, what I found is super helpful for me is just to quickly outline the logic at the top of each one of these.\u003C/p>\n\u003Cp>And if we go through, we could see that we're importing that ingest client. We've got the DeepL API, just their node client that we're gonna use, and we've got some types that we're pulling in to, make the TypeScript compiler TypeScript gods happy. So, we've got some translatable fields here. Again, it just defining some constants. These are the only fields that we wanna translate.\u003C/p>\n\u003Cp>You could easily set this up to be dynamic, and just defining some of the the DeepL params that we're gonna use in our API call. So when we get into the meat of the ingest function here, you can see we've got an ID. We've got our name just describing what this is. And then, you can trigger an ingest function, on any number of events. So the standard syntax here is an object with an event property, but if you want to have multiple triggers for this function, you could just pass an array of objects.\u003C/p>\n\u003Cp>Great. So onto our handler function, we're getting the event and the step, which is standard syntax and Jest is giving us that. And then we're also pulling out this direct us context that we added through that middleware. So through that, we're gonna get our services, we're gonna get our schema, our EMV variables, which is gonna give us the DeepL API key. So the first step in this function is normalizing those keys.\u003C/p>\n\u003Cp>You could see all of that code here. What's notably missing is the step functions that we saw earlier. And originally, I had these wrapped, but, a a nice little tip that Dan gave me is if this, the code that you're running doesn't actually mutate external state or depend on external state, you don't necessarily have to wrap it in a in one of the ingest step functions. Next up, we'll get our payload from the event. We'll check that to see if we have any translatable content included.\u003C/p>\n\u003Cp>And if we don't have any translated translatable content, then we can just return early. Right? Next, we'll get our translator. So this is the DeepL client. We'll get our schema from Directus, and we're gonna init these item services.\u003C/p>\n\u003Cp>So this is how we talk to the database, on the Directus side of it. There's just a little helper function down at the bottom of this file that that makes that a little less verbose, and then we run into our first step function. So here, we're going to get the current post, and this is just a, a service call by the post service. So we're gonna read by the query. We're gonna look for the post with the ID that we were passed in the event and return not just the root level fields, but also the translations that are attached to that post.\u003C/p>\n\u003Cp>So if we look at that in, like, the Directus UI to give you an example, we're not only gonna fetch this information, we're gonna fetch all the individual translations. And that is one of my favorite features of Directus is, being able to fetch the data that I need in a single API call. So I could go deeper into this if I wanted to, you know, three, four, five different levels. Eventually, you'll reach a max where you you don't wanna go, but, depending on the data that you've got, using these asterisks as a wildcard is incredibly helpful for local development. Now, going further, again, we're just going to have a step function that, will cancel this whole thing.\u003C/p>\n\u003Cp>If we can't get the languages from Directus, we don't know what to translate. And this was a a last minute addition. And, Dan, could you talk about, like, the retry logic just a little bit?\u003C/p>\n\u003Cp>Speaker 1: Yeah. As Ingest handles, errors automatically and does retries, some errors you might anticipate and say, this is a non retryable setup. So if I'm missing the API key, might as well not retry it because it's just not gonna work. So in that sense, you, ingest allows, includes a custom function, basically, which allows ingest to say, you know what? Let's stop here and not retry anything else.\u003C/p>\n\u003Cp>So that's what Brian is using here where this is a nonrecoverable error kinda situation. So but, typically, you can throw errors to customers and whatnot, and, those will all be retried automatically. You can even catch them and handle them however you want as well.\u003C/p>\n\u003Cp>Speaker 0: Beautiful. Beautiful. Thank you, Diane. Alright. Let me try to find where we were at.\u003C/p>\n\u003Cp>Okay. So we've got our languages, then we move on to the next step, which is actually building our translation list. Excuse me, guys. Dealing with six not six kids, but sick kids here at the house. Always a struggle.\u003C/p>\n\u003Cp>So here in this step function, we're basically just building up a list of the translations that we want. Right? So we're looping through all of those, posts that we've got, making sure, you know, we've got the fields that we wanna translate, and then we're basically building an array for those things that we'll we'll pass to the next step as we scroll down, which will be actually translating all these items in parallel. So, here, we're using promise dot all to fire these all at once. And, again, I think hey.\u003C/p>\n\u003Cp>Dan, you mentioned this, like, it like, defining a unique ID for these was not not strictly necessary, but, maybe talk about that for a minute if you don't mind.\u003C/p>\n\u003Cp>Speaker 1: Yeah. Yeah. When you're executing in a loop, it's or in something like here where you're paralyzing with promise dot all. You don't need to. Ingest basically takes this and under like, understands, like, internally.\u003C/p>\n\u003Cp>You could check out though the SDK as well if you're curious about how it works. Basically, it takes the step ID and and and appends some sort of, iterator and creates a hash. So, automatically, it, make sure that if two steps have the same ID, it is it will, like, not they won't overwrite each other conflict. But for the sake of debugging, which I think is a great idea of what Brian's done here is you can dynamically set these keys, in your in your loop, which makes it easier for what Brian will show in just a minute, in the UI. Yeah.\u003C/p>\n\u003Cp>Great.\u003C/p>\n\u003Cp>Speaker 0: Alright. So we go through we send all these to DeepL. We get all of those things back, and then, the final two steps here, we're basically, again, using promises to do all of these upserts. So, when you're using these services in, like, inside the actual directest, like, API endpoints or hooks, there is this upsert, which, if anybody on the Directus team is listening, would love to have the upsert on the SDK. Just put in a nod for that one.\u003C/p>\n\u003Cp>But, this makes it super easy to, upstart content. Super simple. Like, hey. If this ID doesn't exist, we're gonna create the translation here. And then last but not least, we're we want to notify the user, hey.\u003C/p>\n\u003Cp>Your translations are done. So you can go check them out, because this is running in the background. Awesome. So that's the flow. Let's take a look at the UI.\u003C/p>\n\u003Cp>How does this work? Let's, what do we what are we gonna translate? Dan, do you have any thoughts?\u003C/p>\n\u003Cp>Speaker 1: I don't know. You hit someone good yesterday. It was just, like, hello from\u003C/p>\n\u003Cp>Speaker 0: Hello from Dan and Bryant. Alright. So we're going to throw this in. What do we have? This is an amazing webinar.\u003C/p>\n\u003Cp>This is not me. This is somebody in the chat. We're not saying we're amazing. But alright. Here we go.\u003C/p>\n\u003Cp>So now what will happen as soon as I save this, over on the left, we should see the event being fired to ingest, unless I have done something totally wrong. And and just to prove that I'm not pulling any switcheroo on you guys, we don't see any translations there. So immediately after I've created that new post, now we could see, the ingest dev server and I get all this observability, all these steps that ran within the actual flow. So we get all of those steps broken down and you can see here we've got the individual steps within that loop that we use those specific IDs for. And as I go through here, you could see the output for each one of these.\u003C/p>\n\u003Cp>So, I don't speak Russian. Not sure if you do, Dan, or not. No. So there we go. So we could see here's the actual content that's that's getting translated.\u003C/p>\n\u003Cp>There's the slug. There's the title, etcetera, in all the different languages that we have set up. And this it's like seeing this together was, like, when it really hooked for me of, like, okay. Great. All this is running in the background.\u003C/p>\n\u003Cp>I get all the observability. So, like, when something inevitably screws up, which for me is often, if you catch any of the hundred apps hundred hours episodes. But and, like, having all this at your fingertips is incredibly powerful as a developer. And being a a developer that has all this and is able to build a flow like this that will do all the translations for your team automatically, turns you into a hero, %. So that is the flow.\u003C/p>\n\u003Cp>Dan, any anything to add before we kinda jump into queue?\u003C/p>\n\u003Cp>Speaker 1: Yeah. And what's really nice is I think just, you set it up earlier with Docker Compose, but with everything running on your your machine, you can work and iterate quickly on this flow and not have to worry about, like, conflicting with, you know, bumping into shared resources. Like, if you're using something like SQS or something like that on Amazon, you need to provision those things. It becomes a little bit of a nightmare. And what also is nice here is, like, you know, Brian's code works perfectly as we see.\u003C/p>\n\u003Cp>It's all green. But if there was an error, you'll be able to see that span go red. And what's nice about the dev server flow is that it saves the input of your function. So if Brian were to go back to his code base, fix that bug, save it, the dev server would basically you know, the his direct to server would would refresh, reload, and you could click rerun in this dev server, and it would just rerun the function again. So if he, you know, if you hit rerun live, it should just it should just work.\u003C/p>\n\u003Cp>And so this gives you, like, this fast feedback loop. So you're, like, in this kind of hot reload situation where I'm working on my I'm tweaking I'm tweaking. So instead of you having to, like, go to the right, manually click a bunch of buttons in the in the Directus UI, you can have a fast feedback loop. So, like, do it once in there, keep going, you know, tweak the output, look at things, tweak maybe prompts or different things that you might be using, to to create this. So at least, like, this allows you to kind of, hopefully move a lot faster when you're building these these things that can be complex.\u003C/p>\n\u003Cp>Speaker 0: But, yeah, I can't stress that enough. Like, the the speed at which you could iterate with the dev server and, direct us being able to, you know, go in and quickly model a feature and idea, and then also being able to, like, prepare that for scale using Ingest is, again, a great pair. Just, works really well together. Alright, guys. So if we move to our amazing slide deck, it is now time for Q and AO.\u003C/p>\n\u003Cp>If you guys have any questions in the chat that we wanna take a look at, Dan, do you spot any that we need to\u003C/p>\n\u003Cp>Speaker 1: I did see a couple questions I could talk to. The first thing I could do was a couple questions on self hosting for Jess side because we we know we can, self host direct us. Right? And I'm sure a lot of people do that as well.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Self hosting is incredibly popular for Directus.\u003C/p>\n\u003Cp>Speaker 1: So I'm sure I'm sure there's a lot of people in the audience that are very curious about self hosting ingest as well. And you can self host ingest. The code that, Brian showed that runs in the DevServer, that binary is the exact same binary that you could self host. You can also you can run it in a very lightweight version or you can offload. Ingest has queuing and state history involved like that it that is backed by.\u003C/p>\n\u003Cp>So when it's running locally, it just runs in memory because it's low volume and it's very simple. But when you self host it and you deploy it into your own cloud or wherever you want, you can hook it up to an existing, instance of Postgres or you can also, plug it out and and connect it to a dedicated Redis, maybe running in another container or something like that. It can handle a little bit more scale and handle, like, you know, restarts of your ingest system. So, you know, you can self host. There are certain things that aren't in self host yet, like, some observable observability and metrics.\u003C/p>\n\u003Cp>A lot of those systems were built in ingest cloud. We're gonna be, you know, kind of bringing some of those things down to, to open source as well. But now, you know, all the key features, all the throttling, flow control, defining functions, are all are all there. So you can run that wherever you want and and and self host.\u003C/p>\n\u003Cp>Speaker 0: Amazing. Got it. So I on the directed side of it, of course, like, you could self host, we've got a BSL license, which basically, a free to run for anybody under under $5,000,000 in total finances or revenue. So So if you have questions on the license, definitely reach out to our team about that. You can do that through the website.\u003C/p>\n\u003Cp>What other questions do we have? I think there was one that I saw that, was super helpful. I like, comparing I like, when I first came into Ingest, I'd heard of Temporal, worked with it a bit. I can't find this one in the chat now, but, like, how do you guys stack up against temporal, Dan?\u003C/p>\n\u003Cp>Speaker 1: Yeah. Yeah. We that's a I think it's a great question. You know, especially with the term durable execution, temporal's, you know, in its essence, describes itself as a durable execution engine. So it is dead focused on a, what we believe is just like the durable execution of the function.\u003C/p>\n\u003Cp>Actually, the logic. Right? Is when something fails, it does checkpoints and it and it retries. So in that sense, there there is similarities. Right?\u003C/p>\n\u003Cp>But we consider that durable execution is just like a means to an end. Right? It is it is a feature. It is not the whole platform. So what ingest really, layers on is a couple things.\u003C/p>\n\u003Cp>We have an event based approach as Brian showed with the hooks, so you can fan out and you can replay and do more things, have a little bit more flexibility with events. And if you're someone who likes events, like, I'm sure that that resonates. And if you haven't, give it a try. And all the flow control and advanced queuing is one of the things that is unique to ingest and, is is in this self self hosted open source version as well is all this reliable flow control. So when people are building these systems, often you don't just wanna execute a job and run it to completion.\u003C/p>\n\u003Cp>You need to manage how fast it's processing, this job, you know, how many times per minute you might run something. Maybe I wanna delay, I wanna debounce something, I wanna rate limit this job, run things in batch processing. Maybe just dynamically say, when there's 20 posts that have been published, let's execute this batch instead of saying, you know, let's just push these 20 items in one big blob. So there's a a a lot of differences in that sense of, like, what we've built around. And I think one of the things that also is true with the ingest SDK is it doesn't mess with the runtime.\u003C/p>\n\u003Cp>If you have used temporal, you in the TypeScript or JavaScript, you know, SDK, temporal does something where they kind of, like, wrap your logic and certain things like random doesn't work. So there's some gotchas that's like, I don't know what's going on with this runtime or it's going to wrap some of your things and you might not it might just not be native code, but we've fundamentally chosen to build ingest, say, anything that you're using works. It's very easy to look in the source and see where things are running. It's very it aims to be a very thin layer, so there's no weird kind of, like, gotchas and things that I need to know. And, generally, like, you know, ingest is very dynamic and defining steps and everything is very fluid.\u003C/p>\n\u003Cp>So there aren't, there's a lot of friction to, like, the rigidity that you might find with other solutions. So I those are just a few things. There's many more, that you could check out, like, on our site and whatnot, but or ping me afterwards if you if you if you're curious.\u003C/p>\n\u003Cp>Speaker 0: Yeah. And I'm not sure that you could say this, but, like, the the syntax that that I found, like, writing the same sort of thing in in jest is dramatically, easier, and it just jives with the way that my brain works versus, like, some of the verbosity and, like, just how temporal structures things. So, do we have any other questions? I I guess that's gonna sting a bit if we have temporal onto one of the partner webinars as well. But\u003C/p>\n\u003Cp>Speaker 1: I, what is called? I'll mention one someone asked a question about, retries. What happens when something hits hits max retries? The function will be declared as failed. And what, ingest also allows you to do is basically say, you know, if there's a complete outage, say, DeepL's down for twenty four hours or or an hour, all your functions are failing and all the retries are exhausted, you can use ingest to say, select, you know, between these two time stamps, anything that failed, replay them so you can do bulk retrace, retries, we call replays of, of those functions.\u003C/p>\n\u003Cp>So you can recover from systems because we persist all the inputs, you know, if that's helpful.\u003C/p>\n\u003Cp>Speaker 0: Definitely. And then, I think probably the last question before we wrap up is, can you run webhooks in the ingest server, the dev server?\u003C/p>\n\u003Cp>Speaker 1: You, you can. You'll have to configure your webhooks in in in in I guess it depends on, like, how you're how you're running things. So, Ingest Cloud, it has webhooks and and transforms. And locally, you just need to write a little logic to just, like, wrap that transform to simulate what, what is happening. We'll be bringing in in the future a synchronization, some thing with Cloud to make that a little bit more easy and bring them into the DevServer.\u003C/p>\n\u003Cp>But fundamentally, the webhooks are just the same API endpoint that ingest dot send is using, that Brian showed in the in those, in those direct hooks. So it's just sending JSON payloads, and that's what, what webhooks primarily are. So, it's, it's pretty easy to to utilize it and build around. There's also a few different docs on our website about that if you're curious about webhooks.\u003C/p>\n\u003Cp>Speaker 0: Yeah. Awesome. I don't I don't see any other questions from the team. We're a little bit over, Dan, but I I I man, I appreciate you coming on. Like, before we kinda get into the awkward outro, I do want to just reiterate, like, for anybody still here, if you've registered for this, we'll hit you with an email with all the links to the repo, this amazing slide deck that we put together.\u003C/p>\n\u003Cp>So don't worry about that. That'll be coming in the next, couple hours, so just be patient. But wrapping this thing up, we we hope this was helpful for you guys. Please send us your feedback. We really enjoy doing these webinars, showcasing other tools and, things that that help you build faster.\u003C/p>\n\u003Cp>And, Dan, thank you for joining. Really appreciate the, you know, the collaborative effort on this thing. Learned a ton about it. And, for everybody else who like, next steps for you guys, what what does that look like? You know, you wanna sign off a little bit?\u003C/p>\n\u003Cp>Speaker 1: Yeah. Yeah. Thanks for thanks for having me, and, thanks for doing all the leg work. You wrote all the code. You built all of it.\u003C/p>\n\u003Cp>So it's, it was pretty awesome to see this, and I think it's a great example. I think if you really wanna figure it out and you want some more, there'll be the follow-up email. Brian also has a really great tutorial that he put together, which has a lot of detail. It's pretty incredible, but definitely check that out. I'm sure that'll be in the follow-up email.\u003C/p>\n\u003Cp>And, then also, I'd say, like, if you just wanna tinker a little bit, go with ingest, go check out, one of the quick starts on our docs and just go tinker a little bit with the dev server, build some different things with some dummy code, and then kind of, that's easy way to just kinda get started, and then you can kind of dive in for the in-depth stuff with Directus using, using Brian's tutorial that he wrote. So thanks for everybody joining. And if you ever have any questions, we, we do have a Discord community. You can find the link on our site, or you can always reach out to us, contact us anytime with ingest dot com. That's 2, by the way.\u003C/p>\n\u003Cp>Just always remember that one.\u003C/p>\n\u003Cp>Speaker 0: Two n's. Yeah. Perfect. Alright, Dan. Thank you.\u003C/p>\n\u003Cp>Thanks for the audience. That's a wrap. We'll see you all.\u003C/p>\n\u003Cp>Speaker 1: Thank you.\u003C/p>","With Directus and Inngest. I'm your host on the Directus side, Brian Gillespie, developer advocate, growth engineer, professional hack and slash developer over here at Directus. Super excited for today. Got a special guest that I'll introduce in just a moment. We should have a good time. We kinda reworked the slide deck a bit last minute, as I tend to do. But before we dive into introductions, let's just take a look at what's on the agenda. Alright. So we'll go through some super awkward introductions in just a moment. We'll deep dive into what is ingest, what powers ingest behind the scenes, why you would wanna use ingest, then we'll get into why Directus and ingest are a great pair together. And then we're gonna run through this advanced content workflow after we've, walked through this integration of invincible automatic localization, for your content, which is always a beast. So with that, I want to kick over to mister Dan. Dan, how are you, sir? Great. Great, Brian. Thanks for thanks for having me. Stoked about stoked about doing this. Thanks everyone for joining as well. My name is Dan, and I'm the CTO and cofounder at a company called Jest. And we'll, we'll get into a little bit more about what that is and, what we're doing today and, why you've joined. But, yeah, just thanks for joining, and I'm stoked about the stuff that Brian, Brian kicked off today. Yeah. Yeah. And, Abel, like, for for some context and backstory, like, I first found ingest, we were working on a project we were calling Event OS. And, Direct has made it a breeze to set this up, get some APIs to work with inside a Nuxt application, but it's not dissimilar from the platform you use to register for this event. One of the the main challenges was, like, how do we send notifications and, like, how do we set up reminders an hour before an event and still have that be robust, like, cancellable in case we move the event, you know, and all sorts of things that we're gonna cover today. So that was my introduction to ingest, and frankly, I was kinda blown away. I I don't think if Matt is here in the chat, I was like, man, we gotta get these guys on a partner webinar, and voila, here we are. So with that, we'll just drag the little slide deck over. And what's up next is what is ingest? So I'll kick it over to you, Dan, and, you know, let you dive into ingest a little bit deeper for those who are unfamiliar. Great. Thanks, Brian. Appreciate it. So I'm gonna give you a little high level overview today, and we're a technical audience, so have a little bit more of a a technical variant on slides today. So, if anyone needs things a little bit bigger, tell me to bump it up in the chat. I'll try to respond if there's anything. So yeah. So, basically, what is Ingest? Okay. What you can basically think about it as the at the high level is that Ingest is a workflow orchestration platform that enables you to run reliable asynchronous jobs anywhere. We're gonna get come back to that in just a just a minute or two. So why would you use ingest for this this task, this need? What ingest allows you to do is to define these step functions. So you're creating workflows directly in your existing code base, use our SDKs, and any logic that you're used to. There's no DAGs or really obscure complex DSLs to learn to build these, powerful functions using regular code. So they're also reliable by default. So everything that you run with ingest automatically is retries. I think we've probably a lot of people here have built systems where, things go wrong. An API goes down for a few minutes, there's a blip, there's a networking thing, there's a race condition that happens in your database, and all simple retry a few seconds later would solve your problem. So ingest does that by default, and it also includes, something that is called durable execution. You may have heard this term, and if you haven't, you can think of this as your code is designed to be fault tolerant and survive catastrophic failovers, basically. So I won't get too deep into that topic today, but there's plenty of resources that we can send you after if you are curious. The last thing is that we've built in queuing and flow control right into ingest so that you can go to production confidently. What that means is that there are concurrency management built into the system that you don't need to have run a a worker or a queue or anything like that. You just define it in your code very simply. You also have controls for multi tenant support, which is another advanced topic we won't get into yet today. But you can just kind of anything that you might have built into some sort of, asynchronous system that you might need is there at your fingertips with easy configuration like throttling, rate limiting, delaying the start of jobs, debouncing, batch processing, dynamically prioritize prioritizing certain jobs, as well as running work in parallel or fanning out to multiple jobs. So that's at the high level, but realistically, okay, what can I build with ingest? So let's just you know, at the highest level in general thing is ingest is a general purpose tool, and you can run any background task. Something simple, just one function, one operation to something that is that is very complex and has to orchestrate between different process. So you also have the control in your hands. You can control the flow of the logic with if statements, not DAGs, and you can kinda build whatever you want. So I'll give you a little taste of, you know, with this audience, which is technical, and I'm sure a lot of y'all are interested or already users of Directus. You know, what might work in or make sense in your in your situation or what you might be building? So one of the first things that's very hot, sure a lot of you are dabbling or building already, pushing these things to production is AI workflows. So you can handle the complexity of things like flaky LOM API calls that might fail, things like chaining, building agent loops, calling tools if you're getting that advanced, or do things like human in the loop flows. You know, you're you're proving the work that that, LLM did for you. So this might be a research AI workflow. Go out and get all this data and pull it back and store it somewhere, or you might be creating content. That kinda leads me into content processing, which is where you might be pre or post processing some content. It might be a blog post or could be static assets that are in your system like images or videos. You might be doing things like translating, resizing, transcribing more to those assets. You might need to kind of create a complex pipeline. So one example here is that you you might be taking data, from your, your Directus system and you might be piping that into maybe a React SVG library and generating visual assets on the fly for your content and then uploading it to where you're storing, your assets. You know, another thing there, like, kind of beyond content is is user journey automation. Brian said at the top something about scheduling emails with events and and and and that and and whatnot. Within just, sorry, Brian. No. No. That was a huge one for me, man. That was, that was, like, my introduction to it, and I think that was, like, one of the one of the first case studies or something I ran across in the docs of, like, hey. Just something as simple as let me sign a user up and then wait a day and send them something Yeah. Incredibly convoluted in other systems. Yeah. And and you know what? You might have this thing where you could some systems might allow you to schedule an email in the future, or you might have a cron based system. But what if you could just, you know, prepare something, do some operation maybe like you're sending somebody you know, you're sending someone an invite, and then that invite email goes out. And then twenty four hours before the event, you might wanna schedule and say, let's render this email. Might be using, say, React email, which is awesome, and, pulling in data from different sources and sending that person a personalized email twenty four hours ahead. Or you might wanna customize, hey. This user is in this time stamp. So you might wanna, like, have more control sorry, time, time stamp, time zone. So you might wanna have, like, a time aware thing. So you could use something like another complex tool or, whatever is within an event platform that you're doing or something like Intercom or HubSpot, but that can be either not very controllable. You can't bring in custom logic and code. It's very static. They're crazy expensive, for those purposes. So you kinda do whatever you want here. Build flows that are scheduling delays, Slack notification, even like things like provisioning resources or provisioning access. So, that's a fun kinda use case. You can kinda build anything triggered with these vents. I'll go through a couple of these other ones because these are kinda secondary. But, you know, if you're integrating your system with a third party webhook, maybe something like integrating Stripe payments somehow into in into your system, or maybe you're using a system like Mux, and you're uploading your video assets to Mux, but you need to do something in your Directus CMS after those videos are uploaded, you can use a webhook. And you can those events can go to ingest and trigger your functions to run your Directus instance. So you can kind of build more advanced integrations with more control that you might need. And the last thing that happens in a lot of systems is there's always data from one source to another to another place. So you might have just data import jobs. Kind of think about it like you're building ETL jobs or just pipelines or synchronization, but you don't, you know, you you don't need anything like a complex data science tool or, something that a data engineer might use like an airflow or something like that. So you can build kind of anything in this, but I hope these are kind of ideas that might work with, what you're already doing with Directus. So I'll go from there, and I'll, I'll get to that question in a little bit. We have some time at the end as well. And, I'll go and just show, like, a little bit of functions. You this again is a technical audience, so let's just show some code about how you build an Ingest function and how it works. So I'll run through this. Basically, what you're doing here is you're creating the Ingest function. It's pretty simple. You define it in your existing code base along with your directus functions, your directus logic and whatnot, your whole system. You can do things like define queuing or flow control right at the top of the function very easily. So if, for example, you just wanted to run this job, at most 30 times in sixty seconds and you wanted to max out at three retries or 15 retries, you can control these things very easily and the ingest system will just do it automatically for you. You don't need to battle queues and infrastructure for that. You also declaratively define the event that will trigger your function. So in this case, when a blog post is drafted, run this code. And then bay very simply, you define a function right here, which is a handler that has all your code. If you're thinking about what I talked about before which is workflows, steps, and whatnot, when you're defining ingest functions, all you need to do is learn a couple building blocks which are steps. The main one is step dot run. Basically, you can encapsulate some sort of business logic, some sort of side effect, and you can perform an operation in there. Each time you run code within one of these, it's automatically retried if it fails as per your retry policy. And if this does succeed, if there's any failures later in the function, it won't be retried. We cache those results and save them. So it makes your function a little durable if you're familiar with that term or fault tolerant, you know, that's the the a la the, durable execution side of things. So, basically what you're doing is you're defining steps and multiple steps to build out your workflow. You can use normal if logic. You can dynamically define steps on the fly. You do not need to predefine them, which is really great. And that's the building blocks. But what's interesting is that there's more power to these these these basic primitives of steps that you have. So here's one example that might tie back to what we were just talking about, which are that you can pause workflows and wait for approval. So you can or wait for other data to happen, other events. So you could build things that run, process some, you know, some data, and then wait for maybe an approval or maybe something else in your system to be updated, like a draft or publish status or something, and you can resume your function. So ingest your code will not be running. Ingest basically holds on to the state of your function. And then when it gets that event, it resumes and restarts your function from where it stopped, doing some different kind of magic and whatnot. So then again, you can use that approval to dynamically, you know, traverse and and run different steps. You can also do things that are a little bit, you know, kind of outside of this this this thing that are that are kind of extending the power, which are making reliable calls to LLMs by offloading those AI calls to ingest servers. You can also do things like what Brian talked about, which are basically use other types of steps like sleeps or delays. So you can delay to an exact time and then resume the code then, or you can delay to an arbitrary number of days or hours or weeks, and then your code resumes. So these are kinda just the the basic building blocks. There's a couple more that I didn't get into. But if you can learn these couple primitives, you can build a lot of complex logic that also is very reliable outside of box. So, you know, going from here, I'll just take a step back and look at the architecture. And, Brian, how are we doing on time right now? We are we're no. We're golden. Can you see? Okay. Yeah. Yeah. No. I just yeah. No. We're beautiful. No worries. I I I did just wanna say, like, the hey, like, the the background jobs and and, like, some of the the queuing stuff was what got me in the door. But, like, the the durable execution piece, especially when you're working with, like, the LLM stuff, after you've you've used, like, one of these big models where you could just literally watch credits evaporate when a function fails is, has been a, like, a nice piece for my workflow. So, kudos there. Yeah. Thank you. Thank you. Appreciate that. And, yes, to the to the, to the audience, yes. Using, step dot a I dot infer, if you're running in serverless because with something like Vercel, it can offload it to our servers. So your function stops running. It's not consuming any any compute and it offloads. So that was an easy one to jump in there. Thanks for that question. Yeah. I'll jump into the architecture because I wanna show you how it works with Directus and how the system is. So basically, at at the high level, this is a little, you know, you don't need to know, like, know everything in detail. I'll try to zoom and see if I can pinch in a little bit. There we go. So the ingest system comprises a bunch of things that you might typically build or need to to execute this and do this yourself. So and there's much more beyond that. But the fundamental thing is there's an event API that receives data from anywhere, could be from your direct assistance or the webhook, And there's, something that consumes those events and basically, creates new jobs and enqueues them. It stores the state of those jobs. It stores the history of those jobs in case there's a problem or anything or you wanna observe that later, which we'll get to, then it executes those jobs. And what happens is the ingest knows, okay, I'm running this function and it toasted on your direct instance. Your code is sitting in your direct instance, and it invokes it via HTTP. So it securely just calls it when it needs to, invokes the minimum number of work, and then returns to ingest. And then if it needs to resume or continue, it will make other calls as necessary. So if you sleep, it goes back to ingest, then it calls your server again later. So this is the basic kind of principle of how all the systems work together and how there's a queue built into the system that is basically pushing work to your system. And that's why it's really key to have the flow controls. You know, you don't want to you wanna set something like throttling because you don't wanna overwhelm and knock down your system or your database in case you're processing, say, a huge backlog of 10,000 or 10,000,000, jobs or tasks that you need to do. So this is really key and also just shows that the code that you write is hosted on your, your machine. It's where you have it. You keep it along with your existing, direct as code base, which is really great. So I'll, I'll show you a little bit about, like, why do we have a database, what is this dashboard UI. So when you're running these long jobs that are happening behind the scenes, they're often hard to observe. I'm sure that some of you have worked in systems where you're parsing just logs on CloudWatch or something like that. You're trying to figure out what's the status of this job. Okay. Now we need to chuck it into a database so we can observe this. And you're trying to piece together what happened and where things failed. So we get to that one question in one second. So what we have is we have a dashboard that gives you visibility into the system. So this is the ingest dashboard and ingest cloud where you can see the the output or status of all the different workflows and functions that you've run-in your system, and then you can expand these to see all the different steps and what might have failed, what have might retried, the outputs of those steps, some metadata that you might pull through like, say, tokens in the model that you might have used to make an AI call or the time stamp when something started or ended. You also can look at inputs, say, okay. What piece of content triggered this? You can debug what actually happened and understand, did this work? You can easily cancel and retry these things or retry them in bulk. There's a lot of operations you could do, but this is the core of, like, this observability that you have into the system. So in also at the, like, the highest level, you can see broad system level metrics, like what functions have failed. Is my import data pipeline failing at a high rate? What what's happening? I need to look into this. So it gives you this kind of overall picture of how the system is go is going where it's it might be doing things always in the background. It's it aren't always automatically visible. And you can run many functions and have all different types of, functions and workflows like generating video transcripts or creating chat completions or daily digest. You you just get the single pane of glass of, like, understanding what's running in my system. And so the point of concurrent runs that, was asked in the, in the, in the chat, what happens is basically, like, ingest, can can execute multiple things at a given time. Depending on your plan and your configuration, you can limit how much concurrency you want. So you can control I only wanna execute 1,000 things at a time, or you might have multiple servers that you've horizontally scaled to handle more load. You can control individually what that is. You can also with the multi tenant controls can can control how many concurrent jobs a given user gets. So you can limit it like that in case you're building that type of system. But, ingest handles that because it it it does the it actually processes the the work off the queue internally. It can you basically declaratively say, this is the concurrent number of like, amount of work that I wanna run. So that's a that's a great question though. So, you know, basically, to summarize, like, this part, there's why are we here? We're talking about in ingest and direct us. Right? So tie back a couple things that I that I went over. It's the same code base that you're already running. It's the same server. You get to take right. Use the ingest SDK to define the functions right in the same code base with everything else that you're using with Directus, and there's no additional compute necessary. And, and, Brian, you got some? No. No. I was just jumping back in as we transition. Yeah. I'll, I'll I'll, Brian's gonna go in a lot deeper about this, which I'm which I'm stoked for all y'all to see because he's built some really cool things. And and some of the things again, this is fault tolerance, the async workflows, you know, so you get the confidence, automatic retries, and control over these processes. And remember that steps encapsulate these retryable logic. You can bring existing logic, import new libraries, whatever the heck you want, write any workflow. And one thing that Brian will go deep on this, I think, is super cool about how it works together is Directus, hooks are super cool because it kinda provides this nice link between the direct to system and ingest functions, but I won't spoil anything there. I'll, I'll pass over to Brian to kinda take it from here. But, and then we can go to if there's any other questions, we'd probably go to the the QA afterwards so we can get through some of these things. Some of the questions might be answered. Yeah. Definitely. So I pop the questions into the chat. We'll get to them if we can. I'll take the screen back, and we'll briefly cover what is Directus. For those, who are joining, who are not familiar, Directus is I I like to call it LEGO for developers where, like, everything that you need to build a digital experience, whether it's an app, a website, automatic content translation, which we're gonna do today, it it's all there for you. And you're just stacking these bricks together a lot like, what Dan was mentioning with ingest of, you know, these primitives that you have, and you could use them to build really powerful stuff. So Directus will give you intuitive UI, which we'll look at in a moment, a nice, like, admin CMS layer. You get instant rest and GraphQL APIs on top of any SQL database, and this is all self hostable. You can also run-in our cloud as well. And just a little tiny, fine print there of any, should be like most SQL databases. Right? Alright. So why Directus? Why ingest? Why together? A couple things. Like, Dan already mentioned, you know, the hooks that we have in Directus make this super easy to communicate with ingest. But more than that, ingest gives you that durable execution. To say being able to build these powerful workflows in code is tremendous. So the first question that, I was asked when I was putting this webinar together, and and this is from our team was, hey. Why why ingest when we already have automations inside Directus? So if you're still learning Directus, we have an automations module called Directus flows, and it is allows you to define a low code, no code automations. You know, when something happens, do this. These flows are great for short lived automations. Some of the things that that Dan showed in the previous slide where we have the syntax of, like, the step function, Directus doesn't have the ability inside a flow to wait for thirty days and send an email or to, wait for another event inside of a flow, without some complicated logic tying it all together. So flows are great for short lived automations or automations that that don't have super complex logic, and ingest is a great complement to flows. And, you know, in the future, I could even see us having an extension to trigger ingest, functions inside a flow. But, as we get into flows versus hooks versus extensions, as as Dan mentioned, Directus flows underneath the hood once you pull off the the mask here, the the Scooby Doo, I kinda mean, is just using Directus hooks. So, Directus hooks, if we pull up my browser, which is always dangerous since I'm using Arc, Directus hooks are just code that fires whenever certain events occur, and you've got a lot of different hooks at your disposal. This is using custom extensions, and we'll kinda cover that in just a minute. But at the core, hooks are allowing you to say, hey. When this event happens at Directus, do this. And, we'll we're leveraging these hooks extensively in this integration. So there's filter hooks, which happen before the event is emitted. So if I wanna run some code to either modify the payload before an item gets created or potentially stop that from occurring, I could do that via a filter hook. And then the ones that we're leveraging today in this workflow are gonna be our action hooks. So when after an item gets created, we wanna do something. In this case, it's going to be sending those events to ingest. Alright. Any questions on hooks before we kinda dive into this? We've also got, like, an endpoint that we're gonna use, and I I just wanna take a moment to touch on one of the most important pieces of Directus is this extensibility. So if you go into our documentation, which is a a great starting point after this webinar, take a look at the extensions overview. You could customize every piece of Directus. So you could customize the interfaces, like how the data is displayed inside the studio. But the parts that we're leveraging today are API extensions. The hooks, endpoints, operations are within flows, and, of course, bundles are how we put all these together and distribute them. Alright. So how do we make Directus and Ingest play nice? And this was the part that, I did the heavy lifting on with some help from Dan and his team. You're still blown away by how easy it is to write ingest functions. It really just kinda gets out of the way. And and once you guys go through this process and set this up and and don't worry. Wait. There's more type of moment here. We're we're gonna give you the whole code base as the bonus after this, so don't worry about taking notes or screenshots or anything like that. But, once you've got this set up, then you can build really incredible stuff, with the incredible pace, I would say. Alright, so I'm going to open up my code editor here and we're gonna take a look at the first piece of the puzzle which is our environment setup. And for Directus projects this almost always starts with a Docker composed file. So this is the pretty standard boilerplate Docker composed from, our documentation. I've I've done just a little bit of cleanup here and extracted some of these things out to environment variables versus, just inlining them. And a couple things that I want to note, when you spin up Directus, especially, like, using our standard Docker Compose, which we're using Postgres for the database, Directus will create this, this folder structure for you with the database, the extensions. This template is is just for applying the schema that we've got for this example, but, it will create all of that for you. And for a cleaner DX, I've basically just extracted this custom Directus extension out to the root in a queue folder. So this entire code base, I've I've gone through the trouble of trying to make comments, to to add a little bit of what I was thinking as we went through here. But all the the rest of this is pretty standard with the exception of a different port. I'm sure Dan can relate to this as you're developing. You've got, like, 35 instances of your product running on your local machine at one given time, so you gotta switch these ports over. The only addition here is the ingest dev server. So the ingest dev server, they've got a a docker image that you could pull. You can also run this via NPM too. Right? Dan, a node? Yeah. Yeah. You can. You can install the binary via MPX or NPM. Perfect. Perfect. Yeah. So, you know, we highly recommend Docker if you're working with Directus, but, you know, you could run this, ingest dev server using NPM if you prefer. But I just wanted to point this out like we've got it pointing to our direct assistance, and this is running on port eight two eight eight. The dev server is amazing for running locally. It's almost, identical to the ingest cloud dashboard, with a few exceptions. And, you know, one thing I do wanna call out, and I think Dan already iterated on it, is your ingest functions, unless you're doing, like, the the LLM infer that that Dan mentioned, these are all running on your same Directus instance whether you're using the dev server or ingest cloud. So I just wanted to call that piece out. Now for the environment that we've got set up here, you could see when you go to production and just has event signing keys or event keys and signing keys so you could keep, things very secure. For purposes here, we're just running, on the dev mode, keep it lightweight, make it easy to iterate. One thing to note, when we get into the translation workflow, we are using DeepL, so I've just got that environment variable. So when we are configuring a Directus extension, Directus has a extensions SDK that makes this process super easy. I just bang in this command into my terminal, n p x create direct us extension. Make sure you use the at latest tag to to pull that. And what you're going to initialize, I'll just show you kinda what this looks like, is a bundle extension. MPX Directus create extension at latest. This will ask you to install, and then we will go through and choose a bundle. And this is where my Internet just totally craps the bed apparently. Too many connections at once. Okay. Yep. So we scroll down, we hit a bundle, and a bundle is just a collection of these extensions. Now once you initialize that, it will look something like this. Where are we? So I've I've got this in our queue set up. You could see here we've got our Directus extension. It is a type of bundle, and then to add extensions to that bundle you run npm add or npm run add or p npm add, whichever package manager that you're using. So as far as the ingest setup here, let's dive into what that actually looks like. And, again, we're gonna give you access to all of this code. So at the high level here, we've got a function folder that stores all of our functions. We've got some hooks that we'll take a look at, and then we have this ingest client. So how do we set this up? How do we make sure it connects securely and plays nice with Directus? We are pulling in from the ingest package, and we're gonna skip this little middleware piece, but this create ingest client basically just returning a new ingest client that we can use to invoke these functions. Now the middleware piece here is rather important. Basically, all we're doing here is some dependency injection to use direct to services, like creating an item, updating an item, sending a notification to our user. So that's an important piece of the puzzle. There's a a couple things like a helper function in here to set the directest context so we can leverage that. And then we're just basically using a singleton pattern for this ingest client so that, you know, we're we're using the same client over and over. Setting this up and, you know, ingest needs to be able to serve those functions. So, in that we've got a endpoint that we define. So this is a custom direct us endpoint. You know, you can see some some standard, imports here. This is where we're actually going to import those functions. We'll show that in in just a few, but we're basically defining an endpoint. The ID here is gonna be the route that this gets served on. So, I'm using ingest. If I go to local host eight zero eight eight slash ingest, that's where my functions will be served from. And you can see here when we're defining an endpoint, we get the express router instance, and then we get the direct us context. And that is what we are calling here or or what we're passing when we set the directest context so that ingest has access to those directest services. Very important piece. If you're setting this up on your own, don't, don't forget that part of it. Last but not least, we'll basically just serve the ingest client here. You can see the syntax we're passing in the client that we've set up, and then we're giving it the functions to serve. Now the last piece of making these actually talk to each other is the direct us hooks. Right? So, we've got our hooks set up. The famous handler. I see. Not sure what you mean by that, Bazar, but, I we can unpack that in the q and a for sure. Alright. So hooks. Right? Again, we're just defining these actions that we want to run whenever a certain event occurs. And I was I was using I I won't say I was using this wrong, but Dan definitely gave me a level up, while we were prepping for this webinar. So, breaking these down. Right? We're using the action hooks inside Directus. So I only want to invoke a ingest function after a certain thing occurs, not not necessarily before. So if we break this down, whenever a post so we'll get into our data model in a moment, but whenever our post gets updated, we are going to send, ingest an event that our posts were updated and we're gonna pass the the event from Directus and this accountability object from our context, which is basically this is the user permissions and, like, the user ID and things like that. Is this user going to have access to actually update that post, after we do the translations that we take a look at. So one of the things that I I do wanna recommend as you go through this, mirror the event names inside your ingest functions from your direct us, events. So you could see this syntax here. Basically, I've just added direct us in case we've got some other service that we want to send events to ingest from. But here, I've just mirrored the syntax and the reason why, and Dan schooled me on this, is it makes it easier to debug and trace these things through your application, especially if you want to trigger multiple ingest functions on a post update or when a post gets created. Alright. So the last piece of our puzzle. Right? We've added hooks. We will create our ingest functions, and we'll take a look at that. We'll share this amazing slide deck at the end of this as well. But we've got a full guide if you've already got a direct us project and you just wanna walk through integrating this. We've got a full guide that we've written on our documentation for you to check out as well. Alright. So, Dan, I'm gonna bring you back. This was your diagram. You know, maybe maybe kinda touch on how this works a bit. Yeah. Yeah. So I think, Brent really laid it out really well here in that. He just showed where with the extension and direct us hooks, that's where we're we're hooking to these actions and just broadcasting basically events over to ingest. So So those events, are basically declaring what happened within the direct to simple, system. And then our ingest functions, will declare when they run. Right? We we saw that before when I walked through some code. You declare when something happens, this is when I wanna run. So instead of directly invoking jobs, this allows you to decouple and also build things independently and do things like fan out, as Brian alluded to. So the ingest system basically understands what your function, your workflows, want to do when, and it basically routes them through back to to, to your server. So at the highest level, that's how we're stitching together the hooks with events ingest and then back to the back to the system to to call your code. Beautiful. Beautiful. I I love the love the diagram, and it like, this was a a big reason why we shifted to this format to make it feel a little more interactive, a little more fun. So all that said. Right? Now to the main event of, like, hey. We we've got this set up. These two are talking together. How are we going to build this advanced workflow? What are we gonna build? So we're gonna show you guys content translations that are automatic and, of course, durable, and I will say totally unbreakable because I know I've written a lot of the code, but but very, very durable, and, like, an incredible workflow for, anybody on your content team that needs to handle translations. So if you've worked with content translations and other systems, this GIF probably holds true. It is so much fun, probably involving, like, a lot of spreadsheets, a lot of working back and forth with either different contractors or different team members. Directus makes that whole process a lot easier. We've got a beautiful interface for it, and, I think Matt on our team is gonna kill me for saying beautiful intuitive interface. But let's dive into why this why this sucks. Right? We're gonna do this manually as kind of the first step that usually involves those spreadsheets, then we can graduate to APIs. The one we're using today is DeepL, but, you know, Chat GPT and some of the other LLMs have gotten incredibly good at translations. Kind of a toss-up there between speed, DeepL, I've found is is really quick, and, it seems to be highly accurate. But as you get into that, especially when you're translating a lot of content, you run into, hey. This is gonna take a while. And as Dan alluded to, I've already ran into this, like, 35 times through the, building of this thing is, oops, we hit the rate limit of the APIs or one of those API calls fails. What happens? Right? Then we lose not only our data, so, you know, we just hope and pray that there's some logs that we can go back and get some of that data, from their side or, you know, just evaporates. So, this is what we seek to fix inside this workflow. And before I show you Directus and Ingest, I want to take a look at our our data model at a high level. Now, this is a simplified example, and I guarantee you when you go to production, you've got a lot of content that you're gonna translate that it probably has a more complex structure than this. But, I do wanna give you this, like, again, we're gonna give you the whole code base. You could take this and run with it, and so this starting point will make it easy for you to adapt to those, those more complex models. At the high level, we've got a post. The post has a title, a slug, and some content. Now, there's also a languages collection inside the Directus instance. Whenever you use our translations interface, we will create that for you if you don't have it already. The format is pretty standard. We have a code like in US, the name English direction, and then one of the additions I've added here is just a DeepL translation code because their API, doesn't necessarily follow the standard ISO codes. And then for each, post that we're gonna translate we have a relationship to a collection or a SQL table called post translations. So within that we have a pointer back to our language and then we have our title, slug, and content. So at a high level that's the data model we're working with. Let's kind of pull this up and and see what this actually looks like. Alright. Dan's gonna laugh at me here. I'm sure to mess up Arc here. Still haven't mastered the side by side in Arc. So over here on the left, I've got our, ingest dev server up and running. If I go in here, you could see I I don't have any runs yet, But over here on the right is our special themed version of Directus just for the ingest webinar. I really dig the the black and green vibes that you guys have on the website, Dan, by the way. Same. Okay. Nice. Alright. So, if we take a look at this, right, this is a beautiful gosh. I gotta stop saying beautiful, Matt. Intuitive interface for all of our content editors. We could see the default language up here at the top. So we're writing this in English. We're gonna pass that to the DeepL API. When we send this translation over, you know, I could set this and and write in whatever default language that I want, and we'll handle the translations. Directus gives you this beautiful side by side view for your translations, and we can see that all of these different languages in our system are fully translated. So, the flow that we're gonna set up, and I'll I'll walk through this in a minute, is we're gonna take any post anytime a a change happens or we create a new post, we're gonna fetch all the languages that we have that we wanna translate content for, and we're gonna go and actually translate that. Beautiful. Alright. So let's take a look at this invincible translation workflow. And usually I do this kinda in code, at the top of my document. I break this down. Since we did this format, I wanted to make it a little more visual, and I'll still walk you through the actual code for this. So at the start of this, what will happen and what I left off of this diagram is the user event. Right? User creates a new post, and then that kicks off the process here. So we're gonna send the post ID, we call it a key, to this workflow. And the first step is gonna be normalizing these event keys because the Directus, event emitter, like if we do post dot update we get an array of keys versus like post dot create we just get a string for the key. So we're gonna normalize those keys. We'll check and see if relevant fields have changed. So if nothing has changed on an update, doesn't make any sense to actually build these translations again. If something has changed, we're going to retrieve all the translations for that existing post, and that's an important piece. Again, you know, we don't wanna translate content if we don't have to, if it hasn't changed. This is gonna be using, Directus item service, so we'll dive into the code in just a moment. We have, we'll get all of our available languages via the direct Us item service again. We'll use both of those to build a list of translation items. So what do we actually need to translate? We'll fire those off using, the ingest step functions to the DeepL API and we're gonna do that in parallel and we'll also loop over those so we get that nice tracking and observability. We'll log any errors and then when we get that back we're going to upsert into the database and potentially notify the user. So that's the flow at a high level. Let's take a look at the actual code. And, Dan, if I gloss over something or I miss something on the ingest side, definitely call me out for it. Will do. Perfect. Alright. So, again, you can see here, this is, these are the two hooks that we're using to actually manage this workflow. So whenever an item gets updated, we send ingest, hey. We updated this, or we say, hey. We created this. And then our function looks like this. And, this is not the shortest function I've ever written, but definitely not the longest. I'll say that. So, again, an outline of the translate workflow, what I found is super helpful for me is just to quickly outline the logic at the top of each one of these. And if we go through, we could see that we're importing that ingest client. We've got the DeepL API, just their node client that we're gonna use, and we've got some types that we're pulling in to, make the TypeScript compiler TypeScript gods happy. So, we've got some translatable fields here. Again, it just defining some constants. These are the only fields that we wanna translate. You could easily set this up to be dynamic, and just defining some of the the DeepL params that we're gonna use in our API call. So when we get into the meat of the ingest function here, you can see we've got an ID. We've got our name just describing what this is. And then, you can trigger an ingest function, on any number of events. So the standard syntax here is an object with an event property, but if you want to have multiple triggers for this function, you could just pass an array of objects. Great. So onto our handler function, we're getting the event and the step, which is standard syntax and Jest is giving us that. And then we're also pulling out this direct us context that we added through that middleware. So through that, we're gonna get our services, we're gonna get our schema, our EMV variables, which is gonna give us the DeepL API key. So the first step in this function is normalizing those keys. You could see all of that code here. What's notably missing is the step functions that we saw earlier. And originally, I had these wrapped, but, a a nice little tip that Dan gave me is if this, the code that you're running doesn't actually mutate external state or depend on external state, you don't necessarily have to wrap it in a in one of the ingest step functions. Next up, we'll get our payload from the event. We'll check that to see if we have any translatable content included. And if we don't have any translated translatable content, then we can just return early. Right? Next, we'll get our translator. So this is the DeepL client. We'll get our schema from Directus, and we're gonna init these item services. So this is how we talk to the database, on the Directus side of it. There's just a little helper function down at the bottom of this file that that makes that a little less verbose, and then we run into our first step function. So here, we're going to get the current post, and this is just a, a service call by the post service. So we're gonna read by the query. We're gonna look for the post with the ID that we were passed in the event and return not just the root level fields, but also the translations that are attached to that post. So if we look at that in, like, the Directus UI to give you an example, we're not only gonna fetch this information, we're gonna fetch all the individual translations. And that is one of my favorite features of Directus is, being able to fetch the data that I need in a single API call. So I could go deeper into this if I wanted to, you know, three, four, five different levels. Eventually, you'll reach a max where you you don't wanna go, but, depending on the data that you've got, using these asterisks as a wildcard is incredibly helpful for local development. Now, going further, again, we're just going to have a step function that, will cancel this whole thing. If we can't get the languages from Directus, we don't know what to translate. And this was a a last minute addition. And, Dan, could you talk about, like, the retry logic just a little bit? Yeah. As Ingest handles, errors automatically and does retries, some errors you might anticipate and say, this is a non retryable setup. So if I'm missing the API key, might as well not retry it because it's just not gonna work. So in that sense, you, ingest allows, includes a custom function, basically, which allows ingest to say, you know what? Let's stop here and not retry anything else. So that's what Brian is using here where this is a nonrecoverable error kinda situation. So but, typically, you can throw errors to customers and whatnot, and, those will all be retried automatically. You can even catch them and handle them however you want as well. Beautiful. Beautiful. Thank you, Diane. Alright. Let me try to find where we were at. Okay. So we've got our languages, then we move on to the next step, which is actually building our translation list. Excuse me, guys. Dealing with six not six kids, but sick kids here at the house. Always a struggle. So here in this step function, we're basically just building up a list of the translations that we want. Right? So we're looping through all of those, posts that we've got, making sure, you know, we've got the fields that we wanna translate, and then we're basically building an array for those things that we'll we'll pass to the next step as we scroll down, which will be actually translating all these items in parallel. So, here, we're using promise dot all to fire these all at once. And, again, I think hey. Dan, you mentioned this, like, it like, defining a unique ID for these was not not strictly necessary, but, maybe talk about that for a minute if you don't mind. Yeah. Yeah. When you're executing in a loop, it's or in something like here where you're paralyzing with promise dot all. You don't need to. Ingest basically takes this and under like, understands, like, internally. You could check out though the SDK as well if you're curious about how it works. Basically, it takes the step ID and and and appends some sort of, iterator and creates a hash. So, automatically, it, make sure that if two steps have the same ID, it is it will, like, not they won't overwrite each other conflict. But for the sake of debugging, which I think is a great idea of what Brian's done here is you can dynamically set these keys, in your in your loop, which makes it easier for what Brian will show in just a minute, in the UI. Yeah. Great. Alright. So we go through we send all these to DeepL. We get all of those things back, and then, the final two steps here, we're basically, again, using promises to do all of these upserts. So, when you're using these services in, like, inside the actual directest, like, API endpoints or hooks, there is this upsert, which, if anybody on the Directus team is listening, would love to have the upsert on the SDK. Just put in a nod for that one. But, this makes it super easy to, upstart content. Super simple. Like, hey. If this ID doesn't exist, we're gonna create the translation here. And then last but not least, we're we want to notify the user, hey. Your translations are done. So you can go check them out, because this is running in the background. Awesome. So that's the flow. Let's take a look at the UI. How does this work? Let's, what do we what are we gonna translate? Dan, do you have any thoughts? I don't know. You hit someone good yesterday. It was just, like, hello from Hello from Dan and Bryant. Alright. So we're going to throw this in. What do we have? This is an amazing webinar. This is not me. This is somebody in the chat. We're not saying we're amazing. But alright. Here we go. So now what will happen as soon as I save this, over on the left, we should see the event being fired to ingest, unless I have done something totally wrong. And and just to prove that I'm not pulling any switcheroo on you guys, we don't see any translations there. So immediately after I've created that new post, now we could see, the ingest dev server and I get all this observability, all these steps that ran within the actual flow. So we get all of those steps broken down and you can see here we've got the individual steps within that loop that we use those specific IDs for. And as I go through here, you could see the output for each one of these. So, I don't speak Russian. Not sure if you do, Dan, or not. No. So there we go. So we could see here's the actual content that's that's getting translated. There's the slug. There's the title, etcetera, in all the different languages that we have set up. And this it's like seeing this together was, like, when it really hooked for me of, like, okay. Great. All this is running in the background. I get all the observability. So, like, when something inevitably screws up, which for me is often, if you catch any of the hundred apps hundred hours episodes. But and, like, having all this at your fingertips is incredibly powerful as a developer. And being a a developer that has all this and is able to build a flow like this that will do all the translations for your team automatically, turns you into a hero, %. So that is the flow. Dan, any anything to add before we kinda jump into queue? Yeah. And what's really nice is I think just, you set it up earlier with Docker Compose, but with everything running on your your machine, you can work and iterate quickly on this flow and not have to worry about, like, conflicting with, you know, bumping into shared resources. Like, if you're using something like SQS or something like that on Amazon, you need to provision those things. It becomes a little bit of a nightmare. And what also is nice here is, like, you know, Brian's code works perfectly as we see. It's all green. But if there was an error, you'll be able to see that span go red. And what's nice about the dev server flow is that it saves the input of your function. So if Brian were to go back to his code base, fix that bug, save it, the dev server would basically you know, the his direct to server would would refresh, reload, and you could click rerun in this dev server, and it would just rerun the function again. So if he, you know, if you hit rerun live, it should just it should just work. And so this gives you, like, this fast feedback loop. So you're, like, in this kind of hot reload situation where I'm working on my I'm tweaking I'm tweaking. So instead of you having to, like, go to the right, manually click a bunch of buttons in the in the Directus UI, you can have a fast feedback loop. So, like, do it once in there, keep going, you know, tweak the output, look at things, tweak maybe prompts or different things that you might be using, to to create this. So at least, like, this allows you to kind of, hopefully move a lot faster when you're building these these things that can be complex. But, yeah, I can't stress that enough. Like, the the speed at which you could iterate with the dev server and, direct us being able to, you know, go in and quickly model a feature and idea, and then also being able to, like, prepare that for scale using Ingest is, again, a great pair. Just, works really well together. Alright, guys. So if we move to our amazing slide deck, it is now time for Q and AO. If you guys have any questions in the chat that we wanna take a look at, Dan, do you spot any that we need to I did see a couple questions I could talk to. The first thing I could do was a couple questions on self hosting for Jess side because we we know we can, self host direct us. Right? And I'm sure a lot of people do that as well. Yeah. Self hosting is incredibly popular for Directus. So I'm sure I'm sure there's a lot of people in the audience that are very curious about self hosting ingest as well. And you can self host ingest. The code that, Brian showed that runs in the DevServer, that binary is the exact same binary that you could self host. You can also you can run it in a very lightweight version or you can offload. Ingest has queuing and state history involved like that it that is backed by. So when it's running locally, it just runs in memory because it's low volume and it's very simple. But when you self host it and you deploy it into your own cloud or wherever you want, you can hook it up to an existing, instance of Postgres or you can also, plug it out and and connect it to a dedicated Redis, maybe running in another container or something like that. It can handle a little bit more scale and handle, like, you know, restarts of your ingest system. So, you know, you can self host. There are certain things that aren't in self host yet, like, some observable observability and metrics. A lot of those systems were built in ingest cloud. We're gonna be, you know, kind of bringing some of those things down to, to open source as well. But now, you know, all the key features, all the throttling, flow control, defining functions, are all are all there. So you can run that wherever you want and and and self host. Amazing. Got it. So I on the directed side of it, of course, like, you could self host, we've got a BSL license, which basically, a free to run for anybody under under $5,000,000 in total finances or revenue. So So if you have questions on the license, definitely reach out to our team about that. You can do that through the website. What other questions do we have? I think there was one that I saw that, was super helpful. I like, comparing I like, when I first came into Ingest, I'd heard of Temporal, worked with it a bit. I can't find this one in the chat now, but, like, how do you guys stack up against temporal, Dan? Yeah. Yeah. We that's a I think it's a great question. You know, especially with the term durable execution, temporal's, you know, in its essence, describes itself as a durable execution engine. So it is dead focused on a, what we believe is just like the durable execution of the function. Actually, the logic. Right? Is when something fails, it does checkpoints and it and it retries. So in that sense, there there is similarities. Right? But we consider that durable execution is just like a means to an end. Right? It is it is a feature. It is not the whole platform. So what ingest really, layers on is a couple things. We have an event based approach as Brian showed with the hooks, so you can fan out and you can replay and do more things, have a little bit more flexibility with events. And if you're someone who likes events, like, I'm sure that that resonates. And if you haven't, give it a try. And all the flow control and advanced queuing is one of the things that is unique to ingest and, is is in this self self hosted open source version as well is all this reliable flow control. So when people are building these systems, often you don't just wanna execute a job and run it to completion. You need to manage how fast it's processing, this job, you know, how many times per minute you might run something. Maybe I wanna delay, I wanna debounce something, I wanna rate limit this job, run things in batch processing. Maybe just dynamically say, when there's 20 posts that have been published, let's execute this batch instead of saying, you know, let's just push these 20 items in one big blob. So there's a a a lot of differences in that sense of, like, what we've built around. And I think one of the things that also is true with the ingest SDK is it doesn't mess with the runtime. If you have used temporal, you in the TypeScript or JavaScript, you know, SDK, temporal does something where they kind of, like, wrap your logic and certain things like random doesn't work. So there's some gotchas that's like, I don't know what's going on with this runtime or it's going to wrap some of your things and you might not it might just not be native code, but we've fundamentally chosen to build ingest, say, anything that you're using works. It's very easy to look in the source and see where things are running. It's very it aims to be a very thin layer, so there's no weird kind of, like, gotchas and things that I need to know. And, generally, like, you know, ingest is very dynamic and defining steps and everything is very fluid. So there aren't, there's a lot of friction to, like, the rigidity that you might find with other solutions. So I those are just a few things. There's many more, that you could check out, like, on our site and whatnot, but or ping me afterwards if you if you if you're curious. Yeah. And I'm not sure that you could say this, but, like, the the syntax that that I found, like, writing the same sort of thing in in jest is dramatically, easier, and it just jives with the way that my brain works versus, like, some of the verbosity and, like, just how temporal structures things. So, do we have any other questions? I I guess that's gonna sting a bit if we have temporal onto one of the partner webinars as well. But I, what is called? I'll mention one someone asked a question about, retries. What happens when something hits hits max retries? The function will be declared as failed. And what, ingest also allows you to do is basically say, you know, if there's a complete outage, say, DeepL's down for twenty four hours or or an hour, all your functions are failing and all the retries are exhausted, you can use ingest to say, select, you know, between these two time stamps, anything that failed, replay them so you can do bulk retrace, retries, we call replays of, of those functions. So you can recover from systems because we persist all the inputs, you know, if that's helpful. Definitely. And then, I think probably the last question before we wrap up is, can you run webhooks in the ingest server, the dev server? You, you can. You'll have to configure your webhooks in in in in I guess it depends on, like, how you're how you're running things. So, Ingest Cloud, it has webhooks and and transforms. And locally, you just need to write a little logic to just, like, wrap that transform to simulate what, what is happening. We'll be bringing in in the future a synchronization, some thing with Cloud to make that a little bit more easy and bring them into the DevServer. But fundamentally, the webhooks are just the same API endpoint that ingest dot send is using, that Brian showed in the in those, in those direct hooks. So it's just sending JSON payloads, and that's what, what webhooks primarily are. So, it's, it's pretty easy to to utilize it and build around. There's also a few different docs on our website about that if you're curious about webhooks. Yeah. Awesome. I don't I don't see any other questions from the team. We're a little bit over, Dan, but I I I man, I appreciate you coming on. Like, before we kinda get into the awkward outro, I do want to just reiterate, like, for anybody still here, if you've registered for this, we'll hit you with an email with all the links to the repo, this amazing slide deck that we put together. So don't worry about that. That'll be coming in the next, couple hours, so just be patient. But wrapping this thing up, we we hope this was helpful for you guys. Please send us your feedback. We really enjoy doing these webinars, showcasing other tools and, things that that help you build faster. And, Dan, thank you for joining. Really appreciate the, you know, the collaborative effort on this thing. Learned a ton about it. And, for everybody else who like, next steps for you guys, what what does that look like? You know, you wanna sign off a little bit? Yeah. Yeah. Thanks for thanks for having me, and, thanks for doing all the leg work. You wrote all the code. You built all of it. So it's, it was pretty awesome to see this, and I think it's a great example. I think if you really wanna figure it out and you want some more, there'll be the follow-up email. Brian also has a really great tutorial that he put together, which has a lot of detail. It's pretty incredible, but definitely check that out. I'm sure that'll be in the follow-up email. And, then also, I'd say, like, if you just wanna tinker a little bit, go with ingest, go check out, one of the quick starts on our docs and just go tinker a little bit with the dev server, build some different things with some dummy code, and then kind of, that's easy way to just kinda get started, and then you can kind of dive in for the in-depth stuff with Directus using, using Brian's tutorial that he wrote. So thanks for everybody joining. And if you ever have any questions, we, we do have a Discord community. You can find the link on our site, or you can always reach out to us, contact us anytime with ingest dot com. That's 2, by the way. Just always remember that one. Two n's. Yeah. Perfect. Alright, Dan. Thank you. Thanks for the audience. That's a wrap. We'll see you all. Thank you.","019ddedf-e66c-4156-89ff-380d9f7e15a4",[186,187],"42e32b28-830e-4966-b849-176902ae12f7","c812e8dd-f9fe-4ee6-bef4-19be62f3427d",[],{"reps":190},[191,247],{"name":192,"sdr":8,"link":193,"countries":194,"states":196},"John Daniels","https://meet.directus.io/meetings/john2144/john-contact-form-meeting",[195],"United States",[197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246],"Michigan","Indiana","Ohio","West Virginia","Kentucky","Virginia","Tennessee","North Carolina","South Carolina","Georgia","Florida","Alabama","Mississippi","New York","MI","IN","OH","WV","KY","VA","TN","NC","SC","GA","FL","AL","MS","NY","Connecticut","CT","Delaware","DE","Maine","ME","Maryland","MD","Massachusetts","MA","New Hampshire","NH","New Jersey","NJ","Pennsylvania","PA","Rhode Island","RI","Vermont","VT","Washington DC","DC",{"name":248,"link":249,"countries":250},"Michelle Riber","https://meetings.hubspot.com/mriber",[251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,228,439,440],"Albania","ALB","Algeria","DZA","Andorra","AND","Angola","AGO","Austria","AUT","Belgium","BEL","Benin","BEN","Bosnia and Herzegovina","BIH","Botswana","BWA","Bulgaria","BGR","Burkina Faso","BFA","Burundi","BDI","Cameroon","CMR","Cape Verde","CPV","Central African Republic","CAF","Chad","TCD","Comoros","COM","Côte d'Ivoire","CIV","Croatia","HRV","Czech Republic","CZE","Democratic Republic of Congo","COD","Denmark","DNK","Djibouti","DJI","Egypt","EGY","Equatorial Guinea","GNQ","Eritrea","ERI","Estonia","EST","Eswatini","SWZ","Ethiopia","ETH","Finland","FIN","France","FRA","Gabon","GAB","Gambia","GMB","Ghana","GHA","Greece","GRC","Guinea","GIN","Guinea-Bissau","GNB","Hungary","HUN","Iceland","ISL","Ireland","IRL","Italy","ITA","Kenya","KEN","Latvia","LVA","Lesotho","LSO","Liberia","LBR","Libya","LBY","Liechtenstein","LIE","Lithuania","LTU","Luxembourg","LUX","Madagascar","MDG","Malawi","MWI","Mali","MLI","Malta","MLT","Mauritania","MRT","Mauritius","MUS","Moldova","MDA","Monaco","MCO","Montenegro","MNE","Morocco","MAR","Mozambique","MOZ","Namibia","NAM","Niger","NER","Nigeria","NGA","North Macedonia","MKD","Norway","NOR","Poland","POL","Portugal","PRT","Republic of Congo","COG","Romania","ROU","Rwanda","RWA","San Marino","SMR","São Tomé and Príncipe","STP","Senegal","SEN","Serbia","SRB","Seychelles","SYC","Sierra Leone","SLE","Slovakia","SVK","Slovenia","SVN","Somalia","SOM","South Africa","ZAF","South Sudan","SSD","Spain","ESP","Sudan","SDN","Sweden","SWE","Tanzania","TZA","Togo","TGO","Tunisia","TUN","Uganda","UGA","United Kingdom","GBR","Vatican City","VAT","Zambia","ZMB","Zimbabwe","ZWE","UK","Germany","Netherlands","Switzerland","CH","NL",1773850435858]