---
title: "Command Line Magic with Arke!"
description: "Join us for an in-depth technical demonstration of Beacon! Arke’s internal developer tool built to streamline composable workflows."
date: "2025-07-31T04:15:53.000Z"
url: "https://timbenniks.dev/videos/live-contentstack/004-m_xqi2xwwmy"
youtube_url: "https://www.youtube.com/watch?v=m_xQI2xWWmY"
playlist: "live-contentstack"
duration: "1:09:48"
image: "https://img.youtube.com/vi/m_xQI2xWWmY/maxresdefault.jpg"
tags: ["composable-architecture", "cms", "cloud-infra", "frontend", "developer-experience"]
---

# Command Line Magic with Arke!

Join us for an in-depth technical demonstration of Beacon! Arke’s internal developer tool built to streamline composable workflows.

Watch on YouTube: https://www.youtube.com/watch?v=m_xQI2xWWmY

## Transcript

[Music] [Music] Hello everyone. That said started soon and then it started really soon. Um low. Do you not have a camera? Oh, there you are. Yeah. Yeah. All right. Just a little slow on the uptake. It's all good. Um welcome everyone. We are live with the folks from ARC and we have a whole delegation of awesome people here that we will soon go over who does what and what is this all about. Um welcome. Um low why don't you kick all that off? Yeah. So welcome everybody to the stream pulse for developers. Today we have an awesome stream. We're going to be talking about command line magic. Um and I want to welcome the art crew. So we have Patrick who is the CTO. Um we also have Chris who is the lead engineer and we have Rodrigo who is the head of Arc Brazil. So you folks want to introduce yourselves. Why don't we start with Patrick? Well hi, thank you for the introduction. Uh really excited to be here. It was great meeting with you guys at content con. Um I think you already said it. My role at ARC is CTO. I oversee our development team, BA, QA. Maybe Rodrigo, you go next. Cool. Yeah. Um, Rodrigo Pepl is my name. I've worked with ARC since 2023 and always with the mission to build this team in Brazil. uh AR has a big commitment working uh in the same time zone, very similar culture and it's a pleasure to be here with you today. You have such a good background by the way. I know. Tell me this is real. The real one is better. Oh, there we go. Nice. Sorry to interrupt. Chris, it's you. Excellent. So yes, my name is Chris Nielsen. I am a technical lead here at Arc Systems. I've been with ARC for about 10 years. I've been doing development work for closer to 20 years. Uh in that time, I've been all up and down the development stack from backend to front end, mobile development, database administration, cloud uh stuff in general. I I'd say over my career, I've largely focused on CMS systems. started with a a homegrown CMS and then burgened up into Sitecore for a while and now branching out into headless CMSs. Uh most definitely focusing on content stack uh for for a while now. Over the past five or six years, I've been leading up the front-end development team here at ARC. Uh and and by that I mean we do a lot of React, a lot of Nex.js and occasional Node on the back end, that sort of technology stack. So that's consider yourself a fool's back now or do we still not know what that actually means? that that has been a very loaded term I have like when when I started we didn't make such distinctions at least in the company I started with we didn't have front end and back end we just had devs and you were expected to do everything um now we have this distinction between backend and front end and I don't know it it I kind of twig out when people call themselves a front-end developer because the ones that I've met I don't know it's it's a lot to ask of somebody it's It it's it's a common label to find but not a common person to find if that makes sense. Yeah. I just found out recently that I am considered a middle stack engineer because I work in the back in in the back of the front because I do I've mainly done CMS configuration and integration tools. Chris underells himself just a little bit. He has been instrumental I would say in the last five to six years in our pivot. We started out as a net development shop right so that's been our story for a long time but um Chris really kickstarted our front-end development team and and that team is huge now. It's it's grown and overtaken the size of our net team. Oh wow. That's awesome. Awesome. And so when a team like that grows, you apparently need a bunch of CLI tools. Yes. So I kind of forcibly made a bridge here to see what we talk about. Nailed it. I see what you did. CLI have been in our history, right, for a long time. And so who wants to take a stab at ex actually say explaining what a C cli is? Well, I'll I'll be happy to to talk about that a little bit. I I know that um CLI tools in general play a fairly major role I would say especially in the in the technology stack that I tend to work in the most. Um a lot of it gets done in um well you know I'm on a Windows laptop right now but I spend 90% 95% of my development time in a Linux system uh sshed in and it's just like that's how my development flow works. I'm in the CLI constantly. uh it is a bit of a shift. You know, I I have spent a lot of time in other development stacks and using more guey tools is is the norm in other environments, but uh if you're doing a lot of React, a lot of uh Next.js development, you're using the CLI. Like, you know, if you're starting up Storybook, that's a CLI command. If you're starting up your Nex.js system, that's a CLI command. If you're working with uh CI/CD and you're building out pipelines, chances are you've got some CLI commands in there somewhere. um actions only cover so much. So that's uh an important part of the flow and it really just means being comfortable with the terminal, being comfortable with what commands are out there. Um once you get used to it, it's it makes a lot of things a lot easier. it becomes uh definitely definitely a productivity bonus to be able to stream multiple commands together, have them execute and have a lot more flexibility than you would otherwise have. It helps. Oh, sorry, going low. I was just going to say it's an efficiency thing, too. Like once you become like a super user or very comfortable in the terminal, it's much faster to use the CLI sometime for some things, right? And I always say like so I'm primarily self-taught developer but I took a few classes right and the one that I have used throughout my career has been I took a Unix class and it was just about getting comfortable in the terminal moving around CLIs and writing scripts and it's the one thing that like I go back to that education every time. Absolutely. It really is. And I I remember that that point in my development career when I started transitioning into the terminal and it was it's a night and day difference in terms of how quickly I I can execute commands and how quickly I can, you know, just string something together and have a script run something through. Uh it's it's a pretty massive productivity boost once you get used to it. And so maybe before diving in what you guys actually built, it might be interesting to talk a little bit about how at Arc at your agency um you actually use these CLI tools for your governance and things like that. Um I see Rodrigo's camera is on loading spinner. So maybe Patrick you want to take that one one more time on that question. Tim, I'm sorry. Yeah. So um can you talk a little bit about how in your agency on the process side of things on the governance side how you use these CLI tools and um how that makes you you know um more successful faster? Well I think um one way that we use this tool that we've developed is to um put schemas from site uh from content stack into source control. Right? So now the code and the content types from uh content stack that are dependent upon each other, they interact with each other, they're now all under source control. And the value of this is when we go through a pull request and we do a code review, right? You have those two things side by side. And that's important. That means that there's less chance of some sort of u mistake or coordination problem between multiple developers because at the end of the day you've got probably a team of devs. They're all working from the same codebase and those content types interact with different parts of the code and so we need to be in sync on that and and this tool allows us to do that. And so did you feel like building this tool because that's kind of how it used to work? Because you can also in content stack for example make a branch for let's say you make a new feature you make a branch and that's where your changes are and then use whatever automations content stack has when you merge. I'm not saying you have to but you can. And so where did it come from that you decided you know let's build this thing rather than let's use that thing. I think it I think it came from uh prior experience with other CMS's. I know Rodrigo could speak to this. Rodrigo's got a lot of experience uh from you know TDS, Sitecore, Unicorn. Rodrigo, do you want to talk about that just a little bit? Sure. Yeah, we kind of take that for granted. U in those platforms that you are developing not just the code but you are serializing schema and content types so that you can distribute them as part of the the the whole code itself. You can version that. You can um visualize history of the of that and which makes much easier to just spin up uh a new instance and having your code running without relying on any manual operations. Not to mention that you can as part of command line you can implement your scripts and automate your stuff. Um it's also very important for the CI/CD integrations where you can just promote the things naturally as part of um just your code uh comes with the type with itself and sometimes even some minimal content to make your code happen. So in other platforms like site support that you mentioned you you take that for granted and the command line interface is for most developers the most natural way to interact uh back in the days not to speak as an old guy it was the only one CLI was was computers right so for us most of us it's natural um and I think that's why we take for granted again yeah yeah it's very interesting to see when you move from a more monolithic system that you kind of manage on prem yourself. So you have your pipelines and all the things you can do towards something that's in the cloud like a SAS suddenly the the whole vibe switches but you can still use CLI right but in your mind it might have switched so much it's like oh now services and um you know management APIs all do it that way but there's also a reason why we at content have built a CLI but slightly different features than yours so that's why this works so well I think you want to say yeah I think philosophically you know as developers ers were very used to having source control be the source of truth that's drilled into us from very very early on. So that this kind of workflow scratches that itch. I also think um this is kind of a minor observation but probably worth knowing. When you make a branch in content stack you are basically doubling whatever content type count you have. And that may or may not be important for you, but it's something to be aware of. Y branch, right, you're making a copy of those content types and so you're increasing your content type count and that that could be a consideration. Yeah. and at scale sometime like we've seen that that's why this is such an interesting conversation because we have customers that do this at scale without a CLI tool but all with scripts that would then essentially just make a new branch look at the delta of the difference of the content and then apply it with the API and sometimes because they have 500 sites in one organization and then one branch creation sometimes takes five minutes sometimes it takes 30 and they might do 200 at the same time. Mhm. And so in different setups you can be pragmatic in different areas and it works fine and otherwise it's harder again. And so um sometimes doing it through a CLI in a slightly different you know management style that might work much better and that's why I love how open all this stuff is right your CLI just uses our management API in the way you want and just run and it kind of just works unless like of course when you start hammering APIs it will just say at one point no and then you deal with it. Yeah. Yeah. And you know, back to the poll request code review cycle, uh, being able to have someone, your lead dev or another dev who's, uh, knowledgeable review your content model changes can provoke a thoughtful discussion. Yeah, agreed. Um, do we I think we just lost Chris. Looks like we did. We did. Yeah, maybe some sort of an internet thing. However, I we do want to go to actually talk about what this CLI tool is that you built if around it. It's time now. We're 15 minutes in. Yeah. Yeah. Because I want to see it in action. So, we did I think we have Chris back now. I think he's back. There he is. Right on time. Welcome back. We want to see Sorry, technical issues on my end apparently. We just wanted some drama on the stream, you know, a little bit of song just to keep us all engaged. Yes, no doubt. No doubt. I think this is the moment you share your screen because you had a few slides you wanted to go over, right? Yes, I did. Yes. And and apologies. I my audio cut out. I've missed like most of what you guys were talking about for the last little bit. So, sorry if I'm going to cover something that you all just talked about, but yes, I do have uh some things to share. Let me go ahead and uh I have a short presentation. Um, and it just kind of talks about Beacon, what Beacon is, why it exists, that sort of thing. Awesome. All right. So, I I think I'm sharing again now. Yeah. So, you're good to go. Beautiful. Okay. So, uh, what is Beacon exactly? Right. So, as we were talking about, Beacon is a command line tool, uh, that we use to work with content types and entries inside of content stack. And so really we built beacon because we had a desire to keep our data schema under source control to be able to deploy that schema as part of a CI/CD pipeline. Right? So this is a command line tool uh and its purpose and and reason for existing is that it can serialize and deserialize stack content. Right? So anything including content types, global fields, entries, assets, taxonomies, anything related to that. Uh okay. So it's not just content types, it's actually also the content itself. Yes, it it can absolutely serialize uh the entries as well, right? And and deserialize them successfully. So, um, we'll talk about that as part of a workflow a little bit later because I think it enables some very interesting, um, options in terms of how you want to work and how you want to manage your your content, right? But primarily, um, what we wanted to support here is a developer experience of being able to manipulate and test schema changes as part of working through a component. Right? So ideally the ways that we would prefer a developer to be able to work with this is a developer should be able to work with both the schema and the component together as as one unit of work and then submit both of those for code review as part of one PR as part of a package. Uh and then you know you go through the code review process. People leave comments on it. People have a way to look at the schema changes before they get applied to your environments. uh and then when it's done it's integrated into your CI/CD tool chain and then it gets pushed up into a higher environment um schema and code together. So, and so before you go to the next, do does it have like certain features for let's say a field was removed or changed? Of course, if there's content on that field already that exists in the database, will you then just lose that or like how does it work? Is there some sort of management there? I know this is a painful question, but no, it's not painful at all. uh in uh in fact that's are the current guidance on that is that as part of doing a code review the people looking at the code are supposed to look at the schema changes and say hey you're removing a field here let's take a look at that what are the consequences of removing this field right because it's the same problem that you face if you remove the field through the content stack UI if the field has data and you remove it it's gone um exactly and actually it's not gone But you it's dangling. Let's call it like that. Yes. Yes. The data is there but there's nothing. Yeah. Do is there a deprecation process in this CLI tool? Not as part of the CLI tool. No. But we do like we use this tool on client projects and we do have deprecation procedures in place. Right. So the way we handle that is just through a development workflow. We say hey we're going to make a a substantial change. we're going to remove a field uh we will mark that field as deprecated in our code and then uh beacon because it has the ability to um I think this is also possible in the content stack UI you have a very extensive search interface but I will tell you the way I've been doing it beacon has the ability to serialize entries from a stack all entries and so if I want to deprecate something and I want to remove a field the process that I've been following is I will point Beacon at the production stack, pull down all the content, all of the entries, let me see what is out there, what has been published um and and where is it and then I can do open up VS Code and do a full text search over that entire serialization and I will find everywhere that UID has been used and I will know this field is being used on these specific entries and I can say to the developer, hey, this field is still in use. we can't delete it yet. Um, so that's that's part of the workflow, right? Like when I'm saying let's do a code review and and note, hey, we're we are going to remove a field, we don't want to do that unless we are sure that it's not going to cause us any problems, right? That's how I check. It's really interesting that you're combining now much more that content and code is kind of the same package and I have it's been a while that I saw that folks are doing that. It actually makes a ton of sense, right? Oh, I I certainly think content comes with a feature normally, right? Yes. I mean, from from my perspective, the way that we are writing our components, uh we are relying extensively on code generation uh either using the REST API, we will generate uh TypeScript types that model the output of the REST API or we will use GraphQL Go codegen. We have a project using the graphql endpoint. Sure. Either way, we are generating types based on the schema that exists inside of content stack. Uh and those types inform the code. So when we are writing code, when we are writing components, uh we want to make sure that our code gen is in place. And if our code gen is in place, then we cannot write code that does not compile against our schema because types will stop us, right? it will throw a compile error if we this doesn't exist. Stop it, please. Yeah, exactly. And so what's actually interesting to bring up here is that for example, the content stack CLI has has this stuff too. There's like a TSG gen plugin. We have all that stuff and the more the marrier. So now developers get to choose to either use beacon or ours and it kind of just use what you like and that's a very important part of having a partnership like this where there might be a bit of overlap but that's actually totally cool because you might have done it slightly differently than us. Indeed. Indeed. Um yeah actually that's a very interesting point. Uh, beacon in general does not do codegen and it makes no assumptions about how you were going to generate types or if you were going to generate types. Uh, I I'm certainly aware of the TSG. Uh, we actually have um something called CSG that also generates types based on the rest API. Uh, I think they both do a pretty decent job. Uh, when we are using the GraphQL endpoints, we use an off-the-shelf tool called GraphQL code. Yeah, I use that too. That's great also. Yeah. Yep. And introspection thing. Yes, exactly. It does introspection and it works wonderfully. Uh but because those options are so varied, I kind of look at that as a separate problem like codegen based on your types. That's not Beacon's domain, but it's definitely designed to work under the assumption that you're going to have something along those lines. And nothing says like for the future potentially because you were like talking about hey this UID is already used and things like that like the content stack CLI recently got a lot of like audit tools for like when you're importing again it kind of looks if like hey is there circular dependencies and bunches of things like that and so in the future you might actually want to tap into that and then these two actually extend each other like there's so much that can be done here it's super interesting. Oh, absolutely. In fact, there's some interesting things to talk about there as well. I know that circular dependencies or circular references are an interesting problem inside of content stack. Uh I I'll give you some insight here. The beacon under the hood is using the content stack management API to import and export content types. And of course, content types and and global fields are allowed to reference each other. And there's issues with trying to import a uh content type before it the content types that it references have been imported. It's it's going to give you problems. Beacon has ways to deal with that. Uh and and it handles the circular uh references. It's able to deal with that sort of situation. Uh and it will give you warning messages. Um actually it's able to handle circular references perfectly well. uh if you were trying to work with for instance entries and an entry references something and the thing that it references has been deleted it's able to handle that as well but it will give you this kind of feedback like hey I'm going to serialize all this content but you're referencing something that has been deleted so when you try to des serialize in other words when you try to push it back up it's you're going to have an it it's not going to be one to one right like it'll do a best effort but if the data is not there when it serializes it won't be there when it des serializes either that's you know that's it it'll tell you these things and and give you some feedback but uh that's only so much you can do. Yeah, exactly. Yeah, our tool does similar stuff and we know this pain and this is part of the game of being developer like data is just this is the game. So sorry to keep asking you questions maybe go to the next slide and at one point you're just going to show it. Yeah, I'm just excited. That's how that goes. Yep. Let's see. All right. So, we have we have this idea that and and this comes from working in in prior CMS environments that a development team will have um multiple stacks working together, right? So, this kind of workflow sort of implies that you'll have at least one stack for your higher environment, meaning QA, UAT, product or whatever. And then each developer will have a dedicated develop development stack for them if they are doing content modeling. Um, and so Beacon gives you a way for every developer to keep their own personal stack uh under control, right? Like they're able to make changes to their content types without needing to worry, hey, am I going to break something? am I going to clobber some other, you know, co-workers to work when they're working in the same area? Uh, they don't have those concerns anymore. And so that's enabling a a different kind of workflow for them. And then also, of course, I talked about this a little bit earlier, we have this uh CI/CD integration. So Beacon is really designed to work in this uh sort of workflow as well, right? So once you have serialized your content types into source control those go through your code review process beacon is intended to be part of your CI/CD integration as a command line tool it's very easy to integrate that into whatever pipeline system you have um and once a unit of work has been completed uh as part of your CI/CD deacons used to push those changes into your higher environments right so in your CI/CD you'll will be feeding it the management token associated with your higher environment stack. Tell Beacon to push your content up and then in this way your schema this serialized source control becomes the single point of truth for what your project's schema is supposed to be. So always in sync. So this is going to be some kind of when you make a new feature it becomes a branch and then you want to merge the branch and then this is kind of part of also the checking everything works but then also after it's merged it does a bunch of stuff. That's right. Right. So the the general flow there is once your PR merges in, you'll have some sort of action that takes place when something hits the develop branch or QA or main or whatever you want. Um, however your setup is configured and then beacon will will apply those at that time. Oh, that's awesome. Very cool. Yeah. I have a question. So, have you yet encountered or used um Beacon on like a multi-tenency architecture or multi-brand situation and like if so, how did you approach that? I have I have not encountered um that yet. Sorry. That's okay. I'm just because I was looking at the diagram and listening to you and it seems like you could use this but it would be maybe you would have to do some slightly different architecturing of this but it seems like it would be possible. No, when you you say branch do you mean content stack branch? No, I mean multibrand like so let's say you have instead of multi-developer stacks you have stacks from different brands but they are sharing uh some component code but also sharing the schemas right. Yeah. Yep. Yeah. We see quite often that that one brand could have 200 subbrands that all have a crap ton of pages with and then they all want to slightly change their own thing but the base is the same and then you have to somehow manage that. We we have done a project for a client where they wanted something like 50 call it project sites within a single stack and that team did use beacon for that. So I don't think it's quite maybe what you're describing low, but it's in the it's in the neighborhood. Yeah. It's always fun when you throw scale at something to see how it works. Yes. And then the reason I asked about branch there, I misheard brand for branch. I don't know Chris if you wanted to just talk about beacon's ability related to to content stack branches. Sir, yes. Beacon is branchaware in the sense that you can configure it to target a specific branch and it will do so. Uh beyond that though branches are uh in content stack however you want to configure that uh beacon makes no particular assumptions about it. Uh other than you you have a configuration option you can tell it you know focus on this branch or that branch and it will only apply changes or or pull changes from that branch. By far the safest bet. Yeah. So yeah, I can continue. Um, y another use case here is backup and recovery. So that we uh are using this on a couple of clients as well, right? So as I mentioned, Beacon is fully capable of serializing a stack's contents, meaning the entries and assets as well. And it lets you handle the idea of managing your own full stack backups. Right? So beacon operates in um a relatively incremental mode. It does need to index everything when it's first running, but once that index is run, it only pulls down entries that it believes have changed since the last uh pull. Right? So this gives you a way to take all of the entries, all of the assets, all the content types, everything, put it into your file system, and then from there you can easily imagine workflows that let you do things like compares with the previous archive or, you know, let's back these up somewhere or perform audits on them, whatever you want to do with them after that. They're in your file system. They're files. um not only are they files but they are in YAML format uh which is specifically chosen because it it enables an easier human readability right so if you are a developer looking at this um it's not minimized in any way it's you know here's YAML you can open it up you can look at it you can read it um that sort of thing so that helps with the process and then if you want to archive that you can it's uh relatively easy so and could you grab an archive from last year and push it to a to a stack and it just works. Yes, certainly. And what happens if you already have new content there? Wipes it out. Oh, okay. Yeah. Yeah. As long as you know, right? Yeah. No, no, it does exactly what it says. It if you're restoring an archive, it's going to restore that archive if you have there. Uh, actually, I should clarify. There is a little bit of nuance. uh they are beacon by default unless you tell it to it will not delete your entries. There is it will warn you uh about that. it will say hey I'm I was I would have deleted this but I didn't because you didn't pass the right flag but there is a command line flag that that says go ahead and delete entries I want what's in file system to be what's in the stack and in that case in that mode of operation it will wipe out whatever's in so is there like does it is it doing some kind of like diff process where it looks at what was here before is it like time or date based will it let you know like no uh That's a fascinating question, right? Because I uh spent a fair amount of time experimenting with that. No, it is not time and date based. It intelligent. It will pull down uh the entry and then it is relatively intelligent about well I I think it's intelligent. I I wrote my logic for it. Says the person who wrote it was an unbiased opinion here, right? Obviously, but no, it it will look at the the contents of what uh is in content stack and it understands that there are certain fields in content stack that might change but do not represent a substantial change from an archive position. Right? So among those are when was this entry last published or um you know who was who who was the last person to update this entry. It understands the difference between built-in system fields inside of content stag and uh fields that have been added because they are part of a content type. So it's it knows to to look and compare fields in that way. It's got some additional logic when it's doing comparisons about how whites space is handled. Um how uh missing fields compare to a field that is present but has an empty string value like does that really count as a diff. Um it it's got some some nuance as far as that goes, but no, it's it's not just looking at the modified date and time. It's it's got some some uh some deeper logic than that. Cool. That's really awesome. When I look at this, you essentially well, it's probably not very much the same, but it looks very much like Unicorn. So, I'm going to throw to Rodrigo because these like if you use sideore or content stack, they're really quite different pieces of software. They do they have the same goal, but they get there differently, which is, you know, everybody has their own awesomeness there. How does it feel using this with content like does it feel like sitecore related development like what what is the vibe here for you is I come from that same background that's why I'm asking right I think it feels at the beginning when you don't have it it feels that you're missing something because now you have to create your types your metadata has to be exported manually and you have to mail that or throw to someone themes. So it feels like you are missing something and indeed I think the reason we built this is because it feels like a big gap and interesting to know you're one of the first to actually mention that as a gap but that's because you come from that background of course because we take yes that's our way we do traditionally and you tend you tend to think comparably to that but I think we we giving we're bringing lot of information here in this call to to tell everyone that is indeed advantages of having that more uh a single source of truth and etc. and also helps you as a developer to think about the artifacts not just the code but the artifacts as a whole the serialization included that composes your your building the the feature you're building right um absolutely you're not abusing this you're not using u u unicorn tds or our tool uh to do anything like touching content that belongs to the content editor You're not supposed to do that. Uh it's not taken as a good practice, let's say, because you can screw up things very easily. Yeah. And I've been speaking to Chris future features we'll be bringing is the ability to localizely u serializing un serialized the serialized data in a certain part of the content only. certain schemas only instead of uh like today we're u re refreshing everything and um getting of course the analysis of deleting that if you force uh but those are the way I think that compares to the the way we do things in inside core but at the same time I I understand why you didn't feel that gap uh because you grow of doing things in a certain way that you don't so you don't feel yeah it's very like you mentioned the word artifact I haven't used that since I used sitecore last because there's somehow something that you can hold in your hand just like how you host Sidecore and that you have the pipelines and you can code it yourself but in the end when we look at it from a distance it's all kind of so similar but it's fun I have not heard the word artifact in a long while and you that that's not a judgment. It means nothing. But it's just kind of fun how different crews that use different tooling have different words for this kind of stuff. That is that is interesting, Tim. I I think um you know maybe bouncing back even to the the earlier multi-tenant question if you are putting more and more of the overall solution which includes things beyond just code into source control then it makes it easier to to start to think about how you can apply that same solution or a solution in a in a similar vein to more than one target environment which could be exactly going down that multi-tenant path. Right. So I think there's a lot of room with a tool like this to to apply it to more complicated use case scenarios. I would say the more you mature as a brand or an agency with more complex setups, this is going to help you a lot more. Like this is not used for beginners, but the moment you go slightly deeper, this actually accelerates you, which is very exciting. Definitely. Okay, we only have like 20 minutes and I want to see the actual tool and in action. Chris, let's go, man. Yeah, absolutely. So, I I do have um a little bit to show here, right? So, we are using this tool on again a number of projects. um can't necessarily share a client project but we are using it to build the art.com redesign website and I can show you a little bit about how this is uh organized we have a react nexs site and so that's part of it and then here under uh CS is where we are keeping our schema right so we have content types global fields taxonomies and in this case I also have assets and entries you can uh for this project, I'm not committing those to source control. They're not part of what we want to push, right? So for higher environments, when I do a commit, I'm only committing my schema. I'm not committing my assets or entries, even though I do have them in my stack. So uh it can show you a little bit about what these files actually look like. You know, we have a variety of pages here. They have uh again, once you are looking at these, this is in YAML. This is I'm sure you're familiar with some of these field names. This is sure largely unchanged from what the management API is going to produce if you ask it to export um a content type. There's going to be a couple of um nuances there, but by and large this is what you get. You can see I've also got taxonomies in here and and that's uh that's what's in the file system right now. I can show you Uh, that's also what is in my content stack. I'll swap over to that and show you how this correlates. You can see I've got all these content types here in my content types content stack stack. Here we go. And so you can see the the correlation between Yeah. the components, right? So let's look and see what does this look like. If I'm a developer and I want to, for instance, let's make a change to one of these components. Let's go into my um features grid. Take a look at it. And we've got a grid. We've got some stuff here. I want to add let's add a a CDA, right? Call to action for this one. So, I've added a new property to my features grid. And so, let's save that. Close that. And by the way, while I'm looking at this, you'll see I've got my name next to my stack, right? So, this is my personal stack. This is my private development stack. We have stacks for everybody on the team. We have a primary stack. This is what you were just showing on your slide. Showing. Yeah. Yeah. That's right. Yep. So, we have one stack that treats our higher environments. That's this arc.com. And then we have a stack for every developer who's currently working on the project. Right. So, I can save this. I don't have to worry about am I going to mess up somebody? Is it going to be a problem? It's not. It's not. It's just my my personal state. Right. So now I've made a change to a field. I can drop back in here and I can do yarn beep and pull. And so it's going to connect to my stack and it's going to pull down all of those changes. Right. So first thing it does start looking at it indexing everything. What's in there? This looks so fancy. Dude, I know. Right. I'm the progress. I've got a little graph here. Um, so many things. This is fantastic. Yeah. So, I actually have some other changes. You caught me in the middle of doing some other other development work, but I just changed my flexible hero. If I look in source control, uh, well, it says it was created. I think that was actually a brand new component. So, let's try I bet my CTA is in here. There it is. Oh, yeah. Yeah. There's my CTA, but let's let's try one with an actual change now that I've synced up. So, okay, wonderful featured icon cards is in here. Let's add a CTA here as well. All of our things are going to have CTAs with this CTA icon so we know what it is, right? Save that. Now, let's run it again. Come back to my terminal. Chris, just want to show this interview one more time. The output. Oh, totally. [Music] Right. So, you can see it picked it up. Hey, you changed your featured icon cards. And then if I come into here, sure enough, there's my new field that's been added. So, what I would do at this point is, you know, I want to go and edit my components. I want to make whatever changes are necessary to make this that thing come up. And then I want to submit that out to a PR, have somebody look at it and uh and work with it at that point. Right. So, so did you just how does it work with your TypeScript? Did that now also update or do you have to do that separately? I do that separately on this project. Uh we do have GraphQL uh on this one. So I do have a a script for that. Well, in that case you just have to do Yeah, like a codegen gen. Yeah, it's a coach in but that's that's outside of Beacon, right? So again, yes, one of one of the things Beacon tries not to make assumptions about how you were doing that or if you were doing that, right? So there's a lot of ways to do it. Exactly. And like we've we've noticed there's a few things like for example when you turn on your visual builder stuff in content stack there's some additional properties that you're going to need on the fields and you want them in TypeScript but when you don't turn those on you don't want them in TypeScript or at least have the question mark thing and so there's it is a little changeable so I understand that you don't want to assume too much here. Yes, indeed. That's that's certainly true. But yeah, I mean we do have codegen working u yeah it's it's separate from beacon but beacon is designed with that in mind. It's it's designed under the assumption. Right. So go ahead. One thing I noticed when you were making the changes previously um it looked like it was checking for RTE plugins. Um yes. So can you talk a little bit about that? like how you're handling that and what happens when there's like extra things on the RTI or like custom fields. Great. A wonderful question. So yeah, one of the things that we have come across is that when you are in content stack and you have installed from the uh from the marketplace a a plugin that affects either content stack as a whole or uh provides plugins for the JSON RDE. If you try to serialize those things, if you're using the management API to to pull down an entry that contains plug-in specific data, that plugin is uh what you get out of the management API. It it it will serialize it, but it is associated with a a UID that is assigned to the instance of the plugin on the stack on which it is installed. Right? So every time if if it's not a problem to pull it down, but then if you turn around and you say, "Okay, now I I've serialized this. I want to push it up to a different stack." Now you've got a problem because that UID is specific to the combination of a specific stack and a specific plugin. Once that UID is generated, uh, if you just try to naively push it up, you're going to have problems because even if the other stack, if your target stack has the same plugin installed, it will have a different UID. So, you've got to do something got to to map that, right? So, so Beacon handles that. Uh, there's a configuration option in Beacon where you can tell it, I've got these plugins installed on my stack and they have these UIPs. And if you look in the documentation, it it shows you exactly how to derive these values, how to find them, and and how to configure to handle this sort of situation. The way Beacon handles that is that when you're serializing, when you're pulling down stuff from your stack and you notice and and Beacon notices that it's got a a plugin in place and it's going to run into this problem, it will at that point map the UID to whatever value you have configured in your configuration. So instead of serializing the stack specific UID, it will serialize a stable value that then during the des serialization process, it's able to use the same configuration and say, "Oh, I see you have the uh whatever it is, Alolia." Well, Alolia doesn't have them. Anyway, we do, but it's that might not be the right example. You thinking this binder, I think, does this binder? Binder is the one that we originally ran into this on, but we solved it generically, right? So, um, you'll it'll say, "Oh, you've got binder content on the target stack. Binder has a different UID. I'm going to map that at that point." And so, it's able that's that's what you're seeing when you see the uh what JSON plugins are installed, what other plugins are installed. We'll echo that back to you as as part do you effectively use an management API to install a plugin? Is that what you do in the end? No. No. Uh actually uh interesting question. We we made some attempts in that direction but I thought it was overreaching for what Beacon was trying to do. Yeah. So that sort of thing I understand that it it might be an interesting prospect to do that because then you don't have to do all the jumping through a hoop backwards because of this UID thing, right? And it's interesting on on one of our projects uh we were attempting to control the plug-in state of the stack also in source control. And it turns out it it's definitely possible to do that but I think it's overkill. I think that installing plugins is is something that is out of scope for what Beacon is going to do. So what Beacon does in that situation is is if you try to for instance uh you have serialized content in your file system that referenced a plugin uh originally and if you try to push that out to a stack that doesn't have a plugin, Beacon will tell it will say, "Hey, I can't do this because target stack is missing the plugin. You've got to go install." Okay. Yeah, that's what I was gonna ask. Yeah. Yeah. Yeah. So, so Beacon will tell you will warn you about that, but it won't try to install the plugin itself. You've got to still do that. Um, one quick one. Um, at content, I think it's it's been a while, but we now have varants for entries as well that you could use for personalization or other things, whatever. A variant. Do you have some sort of feature that deals with those as well? So there's nothing specifically that deals with variance in in that sense. Uh we haven't the the clients on which I've used this project have not used the variant feature yet. So I don't have a specific use case at this time, but it's definitely something that I want to be able to support and I want to you're going to have fun with that because we store the deltas of the changes base variant and then the subvariant and then the different language. You're going to have some fun, but you might just want to look at the code of our CLI and just use it. It's fine. Absolutely. or combine or whatever because that's like all those kind of new things are coming out of course and as partners we should be able to kind of talk together and just figure out that we don't do you know extra work here but there's a bunch of stuff like that I have another one that's probably pretty hard let's say I have a JSON rich text field that's configured in a very complicated way I even have my own plugins in it and what comes out is JSON of course and in your front end you might want to parse that JSON with either your own package for our package and make it into HTML. How do you store that stuff in your YAML files as the JSON just JSON but that's stringifies basically. Oh. Oh, I see what you're asking. No, if you look at the JSON that gets output in that uh very interestingly that JSON will include UIDs for practically every node along the Yes, it does. It does. and and there's no way, at least there's no way that I know of, maybe you know something different, but there's no way that I know of that you are deserializing. In other words, you're pushing that up into another stack. You can't really control those UIDs. So, they show up as diffs. So, remember earlier I was talking about there's there's some nuance in terms of how Beacon compares two entries and whether or not it decides something is different. It understands those UIDs are something that it shouldn't be looking at when it's comparing two entries. uh but the content otherwise the content of the JSON like it um when it's when it's looking at an entry uh the way that process works is it will have the schema as the content type defines it and it will have the entry and it will go field by field both so it understands this field oh this is a JSON RTE field I have special processing so it will understand hey these these UID values they they aren't relevant for yeah just I just don't care I grabbed the JSON and it's what it is yeah it it is what it is. Um and in general we we solve those sorts of things. My usual philosophy for that is to take an extremely light touch in terms of uh what what is there's there's an axiom here is that you want to be uh very accepting uh very very tolerant in terms of what you will accept but very strict in terms of what you output and so I try to follow that in terms of beacon as well. Oh yeah, that makes sense. You're a bit like a browser where a website you built 30 years ago kind of still works. So you have to be very liberal of what you accept and then very strict of how you render. And so that's exactly Yeah. Because the first thing that came to mind is when a rich text editor, the JSON one, you can do a reference to another thing and then render that in the rich text editor. Yep. But if you ignore the UIDs, you're not going to know. And so when that thing doesn't exist, you make a link that doesn't exist anymore when you upload. So there's going to be a lot of fun with that stuff. But keep in mind, it's not ignoring the UIDs. Uh it's it's it's ignoring them only for the purposes of dipping. And references inside of JSON RTE are handled exactly the same as they are for reference fields. In other words, when you're referencing something, uh, Beacon understands the JSON RTE JSON structure and it understands how to crawl down through all of the nodes and locate something that is a reference. Uh, and when it finds a reference, the way that is handled because again, as you pointed out, the UIDs are not something that you can really control with content management API. So, it's got to map that to something that it can control. So if you look at what is serialized for a JSON RTE value, if it's got a reference or indeed if there is a reference field anywhere in the entry, uh what gets serialized is not the UID uh by beacon, but rather a a string in a particular format that says, you know, it starts with dollar sign beacon or whatever and then a slash and then it has a the the title field for whatever is being referenced, right? So it's got a way to map that back, right? because um and again I realize after uh there there are some edge cases here that Beacon understands and will warn you about but by and large for the most part content stack successfully enforces a constraint that that title fields must be unique within the context of their respective content type. So um again we found some exceptions to that rule but u generally speaking beacon makes the assumption that it's okay to rely on that uniqueness quality and therefore the title field can be used uh to to map those references around. So that's that's how it's handled internally. All right. So time is flying. I have yes two questions of which one is fun and the other one is more serious. Which one do you want first? Bring it on. Let's keep this. Let's start serious. We'll start serious. So, let's say somebody watches this stream is like, okay, I'm going to use this now on as another agency or somebody who works with like 20 other customers and they find something that like, hey, why didn't you have this or hey, this is broken. What do you guys kind of expect in terms of how that works? Do you want people to, you know, make a PR? Do you treat this like a product and therefore people complain and then until you have enough complainers you make a new release? Do you release every day? Like what what is your process here? Yeah. No, wonderful question. Beacon is open source. Uh if if you go to the GitHub, it is an open source project. I expect to run that like an open source project. In other words, uh submit an issue request in GitHub, submit a PR. I'm happy for PRs if you want to fork it, if you want to do your own thing. That's what open source needs. Um, so so give me some some issues and uh we you know I I I will I I would love to say that I will commit all of my time to working exclusively on Beacon, but but we go. Well, I it's it it will be worked into a a a support process like we we are committed to making sure that Beacon is is out there and is usable and it's workable. Um as far as that goes, but but yes, you give us give us some issues. Give us some PRs. Go ahead and fork it. Let's let's see what happens. Let's work together. That's great. We we talked about this internally some, right? Um, and we just decided as a company, you know, this, we don't want to deal with making a product and all of the hassle that comes with it. We can tell you all the hassle that comes with that, by the way. I know. And at the same time, you know, we we think there's value for for this. We we we want to encourage the development community around content stack. We think content stack's a great product. So, you know, why not? Let's let's open it up. And I think uh other hopefully other people get value from Beacon. And if Beacon as a tool becomes better because people are contributing back to it, well, that's good for art, too. Yes. Good for everyone. And so, how much pipe coding did you use to build this, Chris? Zero. That's I knew that answer. No, no. I I take that back. I have generated test cases using uh co-pilot agent. So you make your forage go up. That's it. Right. I'm just kidding. Well, not not just for the coverage uh tracking, but you know, if you if you want Look, guys, I have some opinions about code. I know. I can tell. No, I I mean I It's great at generating test cases and if you're very specific with it uh it it can take a lot of grunt work out. I will tell you um if you look in this project right now we have we have tried to describe co-pilot instructions including look at beacon right so it's in here I will say I've tried to use this I don't think I would trust exactly what uh an agent is outputting yet and I don't know if that's because like you know beacon is a relatively new tool I don't know if it you know doesn't fully understand only have to make server for a beacon and then tell it exactly what it can do in terms of toolings and resources, right? Yes. I think I think really the answer there um if I can speculate is you want your agent to be working with an MCP server making the changes in your stack and then use Beacon to pull those down. Oh, that's if I ask right now, the the agent will absolutely go into my CS schema directory and it will start editing these YAML files, which is fine. Like I in theory, that should be okay. And I've done this before, but the output is, you know, it's it's not really you still needed a dev oversight. You need somebody who understands what's a hallucination, what's not if you're going to do that. Exactly. Because sometimes the outcome is not at all what you intended. Like I've tried it before and if you don't understand sometimes basic function structure or anything, you can just get some real garbage and you might not know it if you don't understand like you don't have a foundational knowledge. You're just vibe coding. Yeah, exactly. I was doing it this morning and I clicked undo five times in a row because it was like what the heck like what is this? Yeah. So there you go. There's something that's a real taste thing too about content modeling, right? And I I think there's probably room uh for building out some something in source control that that helps to I think give a little bit of inference or extra context rather for for that agent to try to assist with modeling. But I don't know. Modeling is hard, man. I've not seen it. There's kind of an art to that. I There really is because there's always trade-offs, right? And knowing which trade-off to pick, it's I think it's hard to tell an AI what's enough context so it can make the right selection. Sometimes they can do okay though. Yeah. I think I've noticed the more structured stuff you're going to do like content modeling, the less successful it is and the more fingerpainty it becomes like code. It actually gets a little better. Mhm. Like we're now trying to figure out, for example, at content stack, you probably know we have a JS SDK for delivery and a TS1. And so we would love for folks to use the TS1 a little bit more because it's just more secure, it's more stable, it helps. The DX is a lot nicer, but we cannot just say drop this, go there because you're going to lose three weeks of work and your stakeholders are like, hey, put no changes happened on the website, but you coded for three weeks. That's not going to fly. And so we're now figuring out how can we use AI for people to just paste in their old query with the JSDK and it gives you a TSSDK one. You just swap it out and run. And turns out AI is a lot better at that than content modeling, right? You can just paste a whole bunch of your code and it just rewrites the whole the same code, but then with the TSSDK with the slightly different query stuff you have to do. Yeah. And it just works. Yeah. I think when you're doing content modeling, a a big part of knowing what's the right answer is understanding really well how your content author is going to interact with the authoring experience. Like that that is who you're designing your cont. Yes. And so if you don't have that context and I don't think AI really does unless you're somehow feeding it to it, that's that's the problem. And yeah, I think this these are the golden words that Lo and I were are always looking for. Yes, you worked as a like content stack is a team by, right? Your content editors just as much use it as the developers. Oh, yeah. At at Arc, if if I can just toot our horn just a little bit. Yes, go for it. This is Yes, please do. We we absolutely design for two audiences, mind, right? There there is the end user who's consuming content from from the digital screen, website, mobile, whatever, but there's also the authors themselves. And if they're not happy with the product, if they're not engaged and able to use it and and get their job done and do it quickly, they're not going to be happy with the solution. And that's a that's a real problem. And we see a lot of uh we see a lot of clients who migrate away from CMS's for that reason. So we want them to be happy and successful. Absolutely. And I think like people a lot of times es and also AI gets it's very hard for it to navigate something that straddles a line, right? That straddles a line between computer and human and content modeling is in both of those spaces at the same time. And really to get the most efficient content models, it needs to be crossunctional. Right? So many times you see sometimes developers create content models, create schemas having never talked to the people who are actually going to create content with them, right? So it's not efficient to it's efficient to your APIs, right, as a developer, but not efficient to the content teams. And then that causes you have to go back and reiterate on the model that's not feature-based. It's literally because you didn't have the information prior to so their workflow wasn't in it and now you have to go and try to backtrack and put that workflow in the model. Yeah. Yeah. No, you're you're so right about that low. I think uh you know developers always are thinking about reuse and maybe sometimes they try to apply that methodology to a content model and you end up having to author something in five different places and the author is like what am I doing? So our our BAS are very much in tune with that and I I think our BAS and our our content modelers, they they have a real good partnership to make sure that we're delivering something that the authors will like. Awesome. Wow, we are five minutes over. That went fast. That's a good sign, right? It really did. This was awesome. Um, thank you all so much to ARC and I would be remissed if I didn't mention that ARC is Content Stacks partner of the year. Congratulations on that. We're so happy to be partners with y'all and thank you so much for being here and showing us Beacon. Um, we posted the links in the chat. If you want to contribute to Beacon or just try it out, please do. Also, please join the ContentStack Discord community. You can go to community.contentstack.com. contentstack.com and join our Discord. You can ask questions in there. You can hang out with us. We're all in there. Um yeah. And what else do we have? What else are our requisite marketing things we need to do? No, we did it. We're good. We did it. Um for me mainly is like I'm excited to to try more of Beacon. Yes, this is going to be super fun. And maybe not everybody knows, but I am like I'm doing developer experience, but I'm also being somehow put into the position of being the product manager of our CLI and SDK because that fits so well. And so I kind of know a little bit about what's happening with CLI and I'll make sure not that there's not too much overlap that if there's overlap that we work together than rather than build something that's very similar because that that's just a waste of effort. I love that. And we're really working hard at the moment to making our CLI much more pluggable to actually have modules you can plug in and making make your own package on npm and just push it into the CLI and it kind of just works. And that also means you can put it on the marketplace. And so there's a big thing coming where something like beacon can be a very nice addition to if to if people already know our CLI, you can just plug it in and run. And of course, this there's there's some time here to make sure that that all fits in nicely. And also, if you did want to separate the products out, that's also possible. So, we're just very excited to see how nicely this how smooth this is, Chris. Like, congrats. Like, it's really, really good. It's fantastic. I'm definitely going to put that on my personal side because I want my data models, actually. Okay. And so let's end on a fun question real quickly before we go. How did the name beacon come about? Why did you decide to name the CLI tool the Beacon? Oh, fascinating. Well, I don't go ahead. I I have an answer. I don't know if it's a fun answer. we theme for some of our products that we've created and some of these products are internal to ARC but not all around our sort of developer kit if you will that's applied to stack and so it has an outdoor wavefinding kind of hiking theme to it so uh for instance our solution that we apply to every content stack project is called base camp and we were originally going to call beacon compass but I think there was already a compass name taken. Yes. Okay. We got to, you know, like what what else can we do? So, we just a brainstorming session and we landed on beacon. There we go. Awesome. Well, I really like it. I think maybe it was unintentional, but you calling it Beacon and that's really a lot of the behavior that it does is super awesome. Totally. Yeah, exactly. Yeah. I wanted to say a quick hi to Angie who came in at the right the mo the last moment. Yeah. Hi Angie. Thanks everyone. And um let's do a lot of cool stuff together as partners. Yes. Thanks for having us. This was a great fun session. I I really appreciate the opportunity to talk. Awesome. Cheers. Cheers everyone. Thank you for