Exploring Isograph

Published on: March 7, 2024

Join us as we welcome Robert Balicki, the creator of Isograph, to discuss how this innovative UI framework can transform your development projects. Robert shares key use cases, tips for leveraging Isograph, and a sneak peek at upcoming features.

Transcript

Edit transcript

Ryan Burgess
Music. Welcome to a brand new episode of the front end Happy Hour Podcast. I'm excited to be learning a little bit more about this topic. It's one I haven't leveraged yet, and I'm not sure others on the panel have so it will be a fun topic, but we are talking about isograph, and we have Robert joining us to share his thoughts and experience with it, which he is very close to the project. Robert, can you give an introduction of who you are, what you do, and what your favorite Happy Hour beverages? Absolutely, Robert Balicki I'm super excited to be here, and thank you all for having me. My name is Robert. I work on icegraph. I am employed by Pinterest. I help them adopt relay. Relay is a GraphQL framework for building react apps. Ice graph also a GraphQL framework for building react apps. So there's a bit of overlap here. My favorite Happy Hour beverage, certainly, gin and tonics. I'm a bit, a bit of a gin and tonic boy,

Ryan Burgess
nice. I mean, it's like, it's just a classic good drink, like it truly is. Robert Balicki I don't like sugar in my drinks, so it's the easy choice there. So yeah,

Ryan Burgess
I don't think I'm, yeah, I'd rather like more of a bitter taste than having a bunch of sugar in it. So that's good call. All right. Well, let's also give introductions of today's panelists. Stacey. You want to start it

Stacy London
off Sure. I'm Stacey London. I'm a principal front end engineer at Atlassian, Jem

Jem Young
Young, engineering manager at Netflix, and

Ryan Burgess
I'm the host. Ryan Burgess. Let's dive in. I got to start with like, I think, you know, Robert, you teed it up a little bit about what isograph is. But give us a brief overview. What is isograph. How does it work? Sure. Robert Balicki So isograph, like I said, is a framework for building react apps that are powered by GraphQL data. It has ambitions to be a framework for building apps that are powered by data, but for now, it's focused on GraphQL. So before we really dive into isograph? I think it's important to sort of set some context with respect to GraphQL. GraphQL is essentially a language for querying servers, but when used on the front end, the killer feature of GraphQL is that it lets you specify the data that a given component needs, and then sort of that is compiled into a single query for a given page. So you might have a user header component that selects the user's name, and maybe you also have some other user detail component that also selects the user's name, and in the query that's sent out for that given page, that name field is selected once. So that's really nice, because one, you get an efficient query. But two, it means that if you are looking, if you are modifying the user header component and you no longer use the name field, you can just go ahead and remove it from the fragment. That's that's the GraphQL term for the selection of data that you need. And if any other component happens be using that name field, it will continue to show up in the query, but if not, it will be removed. So that's great, because if many, many developers are working on a UI sort of independently, they don't need to coordinate anything, and you don't get this situation where the network response just sort of bloats over time. Because if you don't have this direct connection between when a component uses a field and when it shows up in the query. Developers maybe they should maybe stop using the field on a Friday, they look at the query, they're like, should I remove that field? Well, not without doing a bunch of extra research to determine if another component is using that field, and if that is used across multiple pages, that could be a lot of research. And so that's that's the thing that GraphQL gives you. It gives you what's called data masking, which is to say each component specifies the data it needs. It's the only one that sees that data, and that allows you to move independently and iterate quickly. So isograph, is something is a framework for building react apps that are powered by GraphQL data, where, essentially, instead of the unit of composition being fragments, which is to say, like, like I said, selections of data that are then coincidentally read out by a single component. ISO is built on the idea that only a single component or single function will read a given fragment, and therefore we associate those sort of at compile time. And for you as a developer, you start writing your query instead of selecting the Home Page Header fragment, which selects the user header fragment or whatever. Instead, you just select the Home page or the home page header, excuse me, and that home page header is essentially that fragment data passed to that homepage component, you do whatever you want to it, and you bundle it up and you send it back to the parent. So I guess one thing that I missed is that in other frameworks, such as relay, getting data masking is super important, but it involves a lot of boilerplate. And the most important thing about isograph. Is that it gets rid of that boilerplate. So you can conceive of your website as like a series of components, each of which may use some data, may use no data, whatever. But that's that doesn't matter to you. You just select the homepage header, and if it uses some field, it gets that field as a result of the fact that we know that one function is associated with one fragment. All of that boilerplate, such as passing the fragment reference down to the child, reading the fragment reference, choosing a bunch of globally unique names for fragments, and deciding on a prop name, all these decisions that you have to make which don't affect the output that the user sees, but are just opportunities to mess things up. Like you don't have to make those choices. So isograph is, I think, fundamentally, going to be an amazing framework, because it just cuts out so much boilerplate. That's sort of the initial introduction to isograph. I feel like I dove a little bit too much into the weeds here, and I'm happy to take a step back and clarify anything, but that's, that's sort of, I think, the initial selling point of isograph, but that that abstraction also unlocks a whole bunch of other stuff that I'm just super excited about.

Stacy London
For those of us who are not using relay, let's say we're using the Apollo client and server graphs well together. Is there a comparison for those of us using the Apollo client, or is this more of a one to one with like, relay, yes, Robert Balicki so Apollo is actually getting a lot of the features of relay, especially recently. So data masking is coming to Apollo. And I think Data Masking is coming whole but like, granular, re rendering and stuff, stuff like it's coming to Apollo. So over time, it will be more similar to relay, and that's super exciting, because Apollo did an amazing job of getting people on GraphQL and helping them adopt best practices. Is just, is just kind of amazing. So I think the fundamental difference between how people use relay and how people use Apollo is in broad strokes as follows, Apollo encourages you to write one sort of mega query at the root and just pass it down. And as a result, your user header might receive the user object, which contains the name field that you actually selected, that you actually want, but it also contains the user's email, even if you didn't select it. Relay, on the other hand, strongly encourages you to have a specific fragment for the user header, and then really has an extra step at runtime of whenever this component renders, reading out just the fields that the user header selected, so just the name field and not the email field. And this has the advantage that there's no there's no accidental dependencies or sort of spooky action at a distance, where if you stop selecting the email and the user email link field, it stops being passed to the user header. Now, the user header probably shouldn't rely on the user email field, but it might, by accident, maybe something got typed as any for whatever reason. Or do you use on string to fire object dot keys or for whatever reason? You know there is just some dependency between these two components, so you can't be as certain that changes to one component won't break the rest of your app. And the data masking aspect of relay ensures that that is even sort of at runtime impossible. Does that answer your question?

Stacy London
Yeah, for sure. I think that I'm trying to like, draw the comparison for folks that are trying to, like, compare isograph to maybe what their setup is, and if they're using Apollo, like, how is isograph and Apollo compare? Robert Balicki Yeah, sure, with GraphQL and so with Relay and with Apollo, the unit of composition is fragments. So you might imagine that you have a homepage query with a user header fragment, or homepage, header fragment, whatever that then you pass that fragment to a given component. Or rather, you pass, you pass that some data to a given component, and relay that data is a fragment reference that you read out in that sub component. You know the difference between how that works in GraphQL, like I just described, and how it works in isograph is that you don't have to do any of that plumbing in isograph. So instead of having a user header fragment that you pass the user header component and then the user header component then reads that fragment and gets that data, you just get a user header component, and that component is just a regular React component that has run. It can use hooks. It has additional props, all this kind of stuff, but it has an additional prop of the data that it selected, and so you don't have to do any of the plumbing work to make sure that the data gets to there, and so on and so forth. And it also means that you can just use, I mean, these are called Client fields in isograph, the pairing of a fragment and a function that uses that fragment data. You can use client fields all the way down. So the homepage header, the homepage component might, you might select the homepage header. Component, which might select like an avatar, which might select a whatever, and all of these are fragments bundled with a function, and the parent just receives the result of that function, instead of having to do all of that, all of that plumbing, yourself. Now, not doing boilerplate, like not having boilerplate like that. Maybe it's compelling. Maybe it's not. If you're familiar with GraphQL, like, what I just said is, like, it's kind of second nature, you know, you don't really need to think about it too much and sort of make sense. But that put yourself in the shoes of somebody who's introducing GraphQL to a new code base and has to do that like, 200 times, or has to refactor a code base to make it more compatible with GraphQL, or is new to GraphQL, it's quite a bit more difficult. But even if the boilerplate isn't the best, I mean, even if that's not enough of a sufficient selling point like this also unlocks a lot of really awesome advantages. So consider an app like like Facebook, you go to the news feed. There's like 50 different types of news feed items that you might encounter, but 99% of the time it's just like a text based thing, maybe a poll here and there, maybe a video, whatever. You don't really have a lot of good options for keeping your app small. You can all. You can basically include all those different types, the JavaScript for all of these different the renderers for these different types of objects. And some of those renderers might be really big, like the video renderer might be, like pretty large, and maybe the user will never encounter a video that's not ideal. So in relay, there's what's called asylum. So data driven dependencies really has a mechanism for allowing you to download just the job, the JavaScript for the video player component, only if we encounter a video newsfeed item. Now, what is relay 3d it lets you download the JavaScript and the data for something in sort of as a unit. That's the same thing that ice craft gives you, except in icegraph, it's everywhere. So relay 3d entry points being able to defer a fragment. I'll get back to that one. A bunch of other concepts are sort of unified through this thing, through through this concept of a client feel. And so this unlocks a lot of really cool things, like you might think, pagination, that's kind of difficult, because you have to make another request for the same data. You have to update, sort of the limits of like where you're at all this kind of stuff as basically doable in user land, in isograph, whereas everywhere else, you have to have framework support for this. And because you have to have framework support, you sort of are limited in how exactly you want to how much control you can give to the user, so you might let them relay. Gives you support for loading a query imperatively, but it doesn't give you really good support for loading one of three queries along with some other data associated with each query. So this kind of functionality, because it's like, super accessible in user land, will mean that in icegraph, you're able to precisely model your domain, and if you precisely modeling your domain, you're able to do a lot of like, really cool stuff, like load the least amount of data and the least amount of JavaScript that you need for a given page, and Only load more if you actually need it, sorry. That was, that was kind of a word salad. I could unpack all of that as well. So asynchronous.

Jem Young
Would you say this would be most useful for like, does this is it valuable any skill? Or is this more this is a large scale problem when you have multiple engineers working on an application, or this is something that you know, maybe a one or two person team would want to use. Robert Balicki I think the largest advantages will certainly accrue to big companies, where as communication coordination problems, where here GraphQL basically solves a communication issue, like GraphQL and sort of data masking, let let developers move independently and not communicate with each other, not coordinate and ship things without breaking things. So certainly, isograph probably will be most advantageous for large companies. However, the same thing could be said of Git, right? If you have too many developers, yeah, maybe you really should start using version control, but now that we're all familiar with Git, like, what's the smallest number of developers you want before you start using Git? It's one because you are multiple developers you today, or you working on one feature is sort of separate from you working on another feature. And because Git is so easy for us to use, the minimum number of developers you opt for use Git is one same thing as will be true of isograph. I think once we get all of the once we get the amazing developer experience that I want us to get to, and that's going to take time, but I think ultimately, like it seems like a big company thing, and that's where the most advantages will accrue, but I certainly think it's useful in one person projects you. If

Ryan Burgess
I have a GraphQL project, maybe it is just GraphQL, maybe it's using relay, maybe it's using Apollo, and I want to switch to isograph. Is it better to you know? Is that easy to do, or is it more like, Hey, I have a new project, and that's when I should introduce isograph. Robert Balicki I think it is a fairly straightforward proposition to convert from relay to isograph. I haven't done it, but conceptually it's there's a lot of similarities in that you define a fragment per function, and that's the important thing. I want to make some sort of automatic, automatic tooling to sort of enable that. I haven't prioritized that yet. I think it will always be fairly easy to convert from relay to isograph. And I think that ultimately, one of the things I want isograph to be is something that gives you the advantages of relay with out a lot of the requirements, and without relay has a somewhat deserved, maybe not so deserved anymore reputation for being difficult to adopt, and I want icecraft to be extremely easy to adopt. So one concrete example of of this is is defer. So if you add defer to a fragment, it instructs the server to potentially send it down as a separate payload, if the data in that if the fields in that deferred fragment are slow to calculate, for example, from a front end perspective, all you're really saying is that I want this data asynchronously. I want to suspend when I read this fragment initially, and eventually the data will be there. So whether the server sends the data down as an additional payload in response to the first network request, or whether you send a second network request immediately afterward for that deferred data. That's sort of an implementation detail, and both of those should be, you know, should be possible with the same defer interface, if that makes any sense. So in relay, relay is extremely focused, and God bless them, on providing the absolute best performance, and sort of, if you are not able to achieve that best performance, like you're sort of left high and dry. The philosophy that I want isograph to have is that if there is a second best alternative which is better than not having the feature, we want to give you that feature. So in particular, the plan for defer support in icegraph. And to be clear, icecraft does not yet support defer, but this is what I'm basically what I'm actively working on will be to make the make the initial request and then immediately send the follow up request for the deferred data. And that's really nice, because if your back end doesn't support defer, you still need that functionality a lot of the times it's like, it's really important as a value prop for using GraphQL, and you can do this in userland. You can just have a separate query that's loaded when a subcomponent renders in relay. But like, that's also not ideal, because that subquery might have fields in common with the parent query. So, like, the User name field might be selected in both queries, and you would really like to not to have that sub query not contain the not contain any duplicate fields. So having sort of framework support for this kind of stuff is really important. And that's one sort of very specific example where I think it's going to be advantageous to adopt isograph, if you are coming from relay, with respect to other frameworks, I think there's a bit of a bit of a bigger impedance mismatch. So I think that, like, Data Masking is really important, and you get data masking, but like, the improvement from going from no data masking to Data Masking is extremely large, and the improvement from going from relay to isograph little bit less large. Is is my how I think about

Ryan Burgess
it. I think that makes a ton of sense. But I'd be curious, when you think of someone picking up GraphQL, maybe for the first time, like, I think you'd I hinted at that at the start. Is isograph, something that you would recommend, like, if you were doing GraphQL early on, or even just as someone who's been doing GraphQL for a while, would you say, like, isograph should be included because, you know, you don't need it, you don't need relay. But it's like, Should you in particular? Robert Balicki Yeah. So actually, one thing that's quite interesting I think about isograph is that you don't write GraphQL. GraphQL is an implementation details how your browser communicates with the back end, but you as a developer are writing basically an isograph query or an isograph literal. And that isn't exactly GraphQL. It looks like GraphQL in the sense that there are curly braces and you know that you have a name field on a user and stuff like that. So some superficial similarities, but you're not really writing GraphQL. And I think that is how it should be. I don't think people should be overly concerned with learning the ins and outs of GraphQL. You know, how do fragment spreads of an interface on a different interface type work in GraphQL? Like, that's kind of a complicated subject. It's quite deep. Like, it shouldn't be relevant to you as. A front end developer in particular, over the long term, like I want, in particular, be able to compile queries that aren't just written in GraphQL. So you might imagine, like writing the same isograph fragments, but then generating some sort of SQL statement that then gets, you know, executed on the server, and then, you know, whatever is transformed back into something that the front end understands. I don't think isograph will teach you GraphQL, and it shouldn't, because over time, the language will differ more and more from GraphQL. There's a there's a few things that I think are just not ideal about GraphQL, namely, the fact that fragments, fragment spreads, are sort of on the parent object, rather than being their own field. Like this is a bit of a problem, because it means that if you are, for example, spreading an interface on an interface, you don't have any way of knowing whether that child fragment was actually executed by the server, unless you do something special, like.dot.on interface, underscore, underscore, type name you need to know to do that. Nobody like basically you need to know to do that, and it's not reflected in the type system that like, if this type name field is present in the network response, you're allowed to do this, all this kind of stuff. GraphQL not an ideal language. It is a very good language for querying servers, but we are using it on the front end to provide data isolation to components. And there is a better language for providing data isolation to components. And it may go it may compile to GraphQL, make them out to SQL, make them out to whatever else, because, because

Ryan Burgess
Michael, so, yeah, there's that flexibility. And I know you mentioned developer productivity, it sounds like that's like a clear goal for you too in this project is like, how do I make it easier for developers on the other end of it. And so I'm curious to know, like, what are things that you think about our priorities for you as you're developing? Isograph for for the developer, for the developer productivity? Robert Balicki Yeah, I'll divide that into two buckets. One is sort of the query language itself, and then second one is tooling. But let's start with tooling. It's going to be really important to have a good VS code extension, and to have stuff like go to definition and stuff like that. But even more, if fragments were sort of a first class well, if really a client fields, fragments associated with functions were a first class entity in GraphQL, a lot of tooling would be a lot better. So you imagine a client field, such as the user header component, which is on the user object in GraphQL, it is a new field that is on user. You can kind of think of it that way. And so you can imagine a world in which, in graphical when you looked at the user, you didn't just see the name, email id and so on server fields. You also saw stuff like, there's an avatar and, I mean, think back to code bases you've worked on. In particular avatar component, it's super redundant. There's like, four or five in every in every code base. And if you're tooling, whenever you selected a user auto completed or suggested, you know, hey, there is an avatar component. It's likely that there would be fewer and, you know, it's kind of nice. So you can imagine a world in graphic in which, when you open graphical, in addition to saying username, email id, you also saw user component, or user detail component, user avatar, and so on and so forth. So I think that there's just, like, there's just a lot of work on the the sort of the fiasco extension and sort of tooling side. And the second way I think about this, in terms of making this easy for users, is I want the there to be as little impedance mismatch like I want an isograph component to sort of match your mental model. And I hope I have the same mental model as you do, but like, if I look at a a page, I divide it into little boxes, and those boxes are components, and that that's great, that like, works out pretty well. But then you start thinking about like, well, what if the data is missing? What about loading states? Like, that's where all the complexity comes in. So I think that bundling components with the data they need is going to make it a lot easier to just think about, to break down a given web page into discrete parts and go on from there. And in particular, I think associating a component with the data with that it uses is really nice in terms of stuff like loading. You might imagine loading a like the footer, delaying loading of the footer because it's off screen during initial paint, right? I mean, your the designer might not really know all the details, and so you guys might like, agree to just like, defer the data, but like, really a best practice for that would be to asynchronously load the JavaScript for the footer and load the data at the same time in because there's a static connection between the function and the data that it uses in isograph Like that's really logical to do, and that's really obvious, and in every other framework, these are two separate things. So while it probably is a best practice to defer the. I'll asynchronously load the JavaScript for the footer and defer the data. It's two separate steps. So what I'm saying here is that the impedance mismatch is gone because these are both loaded as a unit, and you might want to load the footer sort of immediately, or maybe like when it's 600 pixels from being on screen or whatever, whenever you choose to load it. Loading both of those at the same time is really important. I think that's the the two buckets of of developer experience that I that I think about. I like

Ryan Burgess
that one. I can think of many use cases too, where, like, you're right, like, we love our components, like, we like to break it up into smaller pieces. You can, you know, defer loading. But also, I was thinking about it too. Is something that, you know, a lot of companies do when it's something at Netflix, we've done a ton of, is AB testing, and I'm pretty sure Pinterest does quite a bit too. And so I love even just like, the smaller components and having everything together, because you can mix and match a lot easier, but then you can also not send down a whole payload of things. For someone who's in experience a, and, you know, getting code from experience B, it's like, there's many ways to do that, but I see this as being beneficial for that to make it even easier. So I love that aspect of it, too. And 100% Robert Balicki I think that's something that's really difficult to do, and it's sad, because you want to tell a designer that, like, yeah, we'll try the 51st 51st variation of something. But like, if every single time we add a variation, it adds it to the parent bundle, like, that's a problem. And so 100% something that isograph is going to have, sort of out of the box is, you know, the ability to load JavaScript only if you encounter an object of that given type. So sort of a user land version of relay, where you're only going to load the video component if you encounter a video object, and 100% like all like, the fact that AB tests are super hard to do in a lot of situations is kind of is very unfortunate, because we should be getting to the point where a lot of this stuff is just like, sort of not automated, but is you get a lot of support for this. So with isograph, I mean, ice graph is the only framework where, like, a component is associated with its data. So you have a lot of things that components give you. Components have a physical location on a screen. So with isograph, one thing that I want to be able to provide, eventually, very low on the priority list right now, is some sort of ability to get feedback, to get analytics saying, hey, the footer is never on screen during initial paint, that you can already get in, you know, in whatever with whatever solution. But because the footer is associated with the footer data, because they also get the suggestion that, like, hey, because this is off screen during initial pay, you might want to defer the data for the footer and and the footer and so all this stuff, I feel like I have this vision in my head where you build a website, and sort of as you scroll down, or as you change pages, like all the stuff that's needed, but nothing more is loaded, and as you navigate away, like there's some sort of garbage collection work you know that, like, gets rid of, like, the data that you're no longer Showing on screen and so on and so forth and so over time, like the App State, the apps memory footprint stays small. The bundle size stays small, no matter where you where you start. And I think that's like, sort of intimately related to basically the same thing that's going to make AB testing really easy is exactly this thing, which is you should be able to get the absolute minimum amount of JavaScript and data for a given data page or route, plus state of your app and so on and so forth. Yeah, that's, that's sort of long term. That's the long term direction I want to take icecraft, which is that it should be a bundler. And the more knowledge that a bundler has about the state of your app, the more optimist, the more accurate it can be. With something like Facebook, it's a very large app, and so you can kind of bundle split by route, but like every single route, there's routes are like, not even that good of an abstraction, because you can have, like, a bit of, a bit of, like, one kind of component in another page, and so on and so forth. And these routes will be very, very large, but the more, the better way to think about this is like, given the state of your app, so you might be on a given page with a given tab open, given all of that state, what do we need? What JavaScript do we need? And the more that the router can know, sorry, more that the bundler can know about, what about the state of your app and what you need to show to the user, the more it can prune the bundle so it might only give you the JavaScript for tab one, but not for tab two and tab three, and when you open tab two, or you hover over the button to open tab two only, then Do we, like, actually make the network request to get the JavaScript for tab two and the data for tab two,

Stacy London
like today, you can kind of do these things. You have, like, let's say, like, intersection observer or, you know, something comes into screen, then fire, and you can, like, Lazy Load components. So you're kind of effectively doing that idea of just getting that JavaScript. You need at the time that you need it, and that component might control its own data fetching so, you know, it will fetch that data at that moment. So you can kind of do that today, but it's like a lot of sort of manual orchestration that you're doing as an engineer. And I think what you're saying is the dream kind of for isograph is like, it would do all of that kind of for you, and the engineer doesn't have to, like, manually wire all that up. Is that kind of what you're going for precisely? Robert Balicki That's exactly right. It's not just sort of, like bundling in terms of, like, lazily loading stuff. You can think of it as like, if I have a parent component and I select, like, let's say I have a user detail component and I select the user header component inside of that user detail component, well the field that what I get for the user header like, let me change the example. If I'm if I'm doing a user profile component and I select the avatar component, then what I actually get for the avatar like my parent, the parent component shouldn't really care what it actually gets. Concretely, it should only care that the user avatar or the avatar component, like as you have the same type that I would expect, like on type level, it should match. And so in practice, that could mean that you, if you're bundling for mobile, the user avatar you get is like a 16 by 16 pixel picture. And if you're bundling for desktop, it's like a 200 by 200 pixel. And that's like, if you have a hard require of the child component in the parent, rather than having this sort of indirection, where isograph gives you the child component for you, then it's really difficult, because you've hard required one specific component. And now you have to, like, you have to do a lot of work to get what to do actually optimize for what you need. Now you could, sort of like, mock require calls and stuff like that, but, you know, it's not easy. And more to the point, like, nobody really does it because it's difficult. And as you know, like, if you're thinking about like a unit test, right? You're unit testing the user profile component, then what avatar Do you want? Like, it should just be a div with a Test ID, right? Or, I mean, maybe, and that's the kind of thing that like, because there's this, because isograph is doing all of the plumbing for you. It's able to say, like, hey, actually, in this, in this, given this context, context being like, you know, we're building for mobile, we actually will give you a different component than you would get on, you know, in some other situation, all of these things are just like, you can do them right now, and they're done on all, like, the best websites where performance really matters, and you have teams that are dedicated to performance, but as an engineer who's focused on product, I don't want to think about I don't want to, like, put in extra effort, and so all of these things have to be super easy. And that's sort of the goal of ice graphs to make, like, make your apps as performant as possible, as easily as possible. For all the product developers, love

Ryan Burgess
that thinking. I'm curious too. It's like the project size, like, how long have you been working on this? How many people are working on it? Robert Balicki You have so I started working on it sort of in earnest last April, and I've been trying to devote as much free time as possible to it. There are now three of us working on it, yeah. And we have one person using ice graph too, so that's kind of cool. I haven't actually talked to them, so I don't know whether they'd be comfortable being named, but like, there's a user, and that's cool. But yeah, there's the three of us and and, yeah, and it's been basically in the works for a year, but idea wise, like, I worked on the relay team before working on ice craft, and a lot of these, like, a lot of these ideas were cooking in my head beforehand. Like, a lot of like, I wish relay would adopt these, a lot of these features, and it's very understandable why they don't, which is that relay is supporting Facebook. So making breaking changes to relay is really, really difficult. And so in my opinion, it's just like I had an opportunity to rebuild it from the ground up, making all of the changes that I wish were possible to make in relay, and just make them all at once. And so far, I mean, like the vision for icergraph now is a little bit different than it was a year ago, but roughly the core thing of client fields like that that I think is held up so that this makes me happy, makes me optimistic about the rest of the vision, that it's

Ryan Burgess
also taking, like, lessons learned from writing relay and going, Yeah, I wish we had this. And you're, you're so bang on. It's like, you're not gonna break relay or just risk that too. Like, if you're Facebook, you're like, we depend on this, and it's going to, it's fine if we want these things, but it's like, how do you prioritize investing in those so I like your approach is like, Okay, well, I can go write something different. I guess. Is the goal to start getting companies using it like, you know, being at Pinterest, do you think there's value in the company adopting something like isograph? Yes, Robert Balicki yes. 100% the goal is to get people using isograph that is, that is would make me super happy. I have not tried to get Pinterest to adopt isograph yet. I think within the next six months it will be a very good it'll be a good time to adopt isograph In the meantime. Like, there's some, you know, there's some major missing features that I'm working on, but like, maybe at about six. Months, maybe about a year, like it's going to be a great, a great framework to adopt, and I certainly will be pushing internally to use it, maybe on some sort of, some sort of not user facing screen at first, and then more and more. However we're adopting relay, that's a pretty big investment. I think, like we have gotten, we're getting 95% of the benefit, which is to say we get a lot of boilerplate, but we do get data masking, and that's like the crucial feature. Like, if isograph ever gives up on data masking, like something has gone horribly wrong, because data masking is like the key thing that allows companies to allows developers to move independently and maintain velocity at scale. Like, that's really important for a big company, but yeah, so 100% the goal is for folks to adopt icegraph. Also, right now, there's a lot of work remaining to be done. And I think if you're interested in working on a project that has a rust compiler and a TypeScript sort of runtime, then this is a great project to participate in, like, I'm happy to provide whatever support you need, or whatever freedom you need to feel comfortable working on it. And in particular, I think, like, isograph is a great project to get started with because, or get in on now is because the roadmap. A lot of the roadmap is, there is this feature in relay, and we need to re implement it. So, like, the roadmap is very well defined, but there is still sort of groundbreaking, foundational work that remains to be done. So you can have a lot of impact, but you also have, like, a very clear direction in in which to go.

Ryan Burgess
I love the call for like, help on on the project too, because it's like, open source is a lot of work, so it's really cool. I think it'd be a fun project for people to join. I'm also curious, maybe before we dive into pix is, I would love to know, even if people are wanting to get started leveraging isograph Today, like what, how do they do that? What are things that they could start trying out? Yeah, absolutely. Robert Balicki So if you go to icegraph dot Dev, there is a quick start guide, and that gets you going with the if I recall correctly, it's with the Star Wars API. There's sort of a public GraphQL Star Wars API that everyone uses for demos. I think that's the one that's used. I haven't looked at in a while. That's how you should get started. And the other way is to basically what you need is to download a schema and then start developing against that. And that's sort of the only requirement. The Quick Start should get you most of the way there. And then there's other documentation for some of the more complicated features, which we didn't talk about, like, you know, mutations and stuff like that.

Ryan Burgess
Awesome. Well, in each episode of the front end Happy Hour podcast, we like to share pics of fun things that we found interesting. Want to share with all of you. Stacy, I'm going to lean on you for the to kick us off. Sure.

Stacy London
All right, got two music picks. The first one is paralyzed by glaring. These two picks. I've never heard of these bands before. They got suggested to me in some interesting Spotify algorithms. But yeah, paralyzed by glaring. Kind of synth driven, dark wave, cold, wavy, dreamscape vibe to it. The second song is, get careful darker by our missing and also kind of in that same dark wave synth pop genre. They're good songs to listen to while you walk and contemplate things.

Ryan Burgess
I like that. So it's not, is it? Is it coding music too? Or is it just like, gotta be that chill vibe?

Stacy London
It depends. There's some there's vocals, they're very subtle. So if vocals bother you while you're coding, then probably not. But you could do it. You could listen to it while you code.

Ryan Burgess
Too. Fair enough. Jem. What do you have for us?

Jem Young
I've got two picks. The first one is a blog post by Jeff Wofford. It's called How to boss without being bossy, and it just, it's a pretty, pretty lightweight read, but he just goes through different ways of asking, how to ask people to do things, and he knows different scales on clarity versus harshness versus, you know, how is this perceived by the other person? And it's really fascinating, because I never thought about how I ask people to do things, but I do, and it's good to have it laid out in like, a really clear pattern. It's like, oh, okay, this may be more appropriate for this situation. So it's a great read for leaders or parents or pretty much anybody who has to ask other people to do things. My second pick is this game I've been planning. As some of you know, I love playing video games, pretty wide variety, and I tend to bounce from RPGs to real time strategies to racing games. I'm currently in my racing game face, and I've been playing this game called Dakar desert rally. Pretty fun. I don't know if you all know about the desert rally, and it spans a few countries, but it's pretty much people on dirt bikes and like, these crazy four by fours, and they're just tearing through the desert and there's no roads or anything, they're just, like, going through you have to navigate via map and GPS. It's like, on my bucket list of things to do. But I'm not a millionaire, so I can't afford it, but the game is a ton of fun. You can see how different vehicles handle and just tear across the desert, and the physics are really solid. So super fun. Yeah, super fun. Very

Ryan Burgess
cool. Awesome. Robert, what kind of pics do you have to share? All right, Robert Balicki I will share something about myself. Is that I like darkness when I sleep, and given that we're in New York, there's always a bit of light coming in from the outside. So what I wear every night to bed is this, I mean, for those on the video call, you'll see it's a giant eye mask that, like, goes right over my head and it looks like I'm robbing a bank every night when I go to bed. And this is, this is just like, absolutely transformed my ability to sleep. That is one thing that I That's my pick, called knighthood. It's also a nice, punny name as well. N, i, t, e, H, O, O, D, I swear I

Ryan Burgess
love it. And it looks like it, straight up, looks like a hood too. Is uncomfortable. Robert Balicki Oh yeah. I mean, there's pressure on your eyes and your face, but like I, I don't find that a problem. Pretty simple. It looks like it goes underneath it, like stops at my nose. So I fold it up above my nose. So Okay,

Ryan Burgess
that's fair. I was picturing it Stacy, that it would go like, whole full face. And I was like, Yeah, that would maybe bother me. But yeah, if you're only covering, kind of just your eyes and stopping that that point, that makes a ton of sense. Very cool. Yeah, I just have one pick. It's actually a new camera that I purchased, so not a cheap pic, that's for sure. But I migrated from a Canon DSLR to a Canon mirrorless camera. I don't know why it took me so long. I am thoroughly enjoying it. The like video on it is just amazing autofocus, like everything is just working so nicely, and it's so much lighter of a camera too. So I'm really enjoying that I got the Canon r5 so I think I've been shooting with it for a few weeks now. And yeah, I'd highly recommend it if you're in photography. If you haven't made the move to mirror list, try it out. It is, is pretty awesome. I don't know why it took me this long. It just Yeah, kept pushing it off. So that's my pick. And Robert, thank you so much for joining us. It was really great to do, like, a deep dive on isograph, and really understand, you know, the goals of the project, how you came to it, you know. And even just coming from heavily on the relay side of things, I really found that interesting. So thank you for all the knowledge you've shared with us and our listeners. Where can people get in touch with you? Robert Balicki Yeah, so the my Twitter is statistics, fdW, that is probably the best place to reach me, but also everything you need is on isograph, dot dev as well, including links to the GitHub and other ways to reach me. So those are the best ways. Thank you so much for having me like this is such a fun time, and I of course, love sharing about icecraft. So thank you for taking the time to listen.

Ryan Burgess
Well, thanks for joining. And yes, I am sure our listeners will enjoy it as well. For all you listeners, you can find front end Happy Hour on YouTube, Twitter, at front end, HH, frontend, Happy hour.com, really whatever you like to listen to podcasts on, leave us a review. Let us know how we're doing. Reviews definitely Help others discover the podcast. And also it kind of helps us know what we need to adjust or change. Any last words, Robert Balicki wait a year like isograph is going to be everywhere. It's the, absolutely the best way to build web apps and eventually build mobile and there's no reason that we can't target Kotlin and iOS and so on. So like, eventually, I think this is gonna be the best way to build apps asynchronous. Mark my words. You will be right on

Ryan Burgess
point. You heard it here first, and yes, get on board. You.