Revolutionizing API Syntax and Schema Management with Jazz Framework - JSJ 663

that kind of became Jazz. That's like my mini origin story on that.

authoritypive state lifts in your database and the beckend interacts with that, and the front then kind of sense requests

to the back end. You move away from that to a new model where you try to keep as much state as possible or maybe even all state in the client and you just write youI around that as if you were building basically an old school offline app that just writes to memory too disc but then that state gets synced to other participants because of course you still want to interact with other users, maybe even have real

time multiplayer that sort of stuff. So you kind of the way I like to look at it is it is that we're so used to the traditional stack as like, obviously that's how you build web apps, but if you think about it, what the stacks do is they just facilitate sharing state between users, and the way they do

that traditionally is by having like centralized authoritative state. And with local first, you just turn that problem around and you like, what if everyone kept state locally and then how do we sink between participants?

which is what Jazz tools implements. For example, what local first is about is mostly solving the problem of well, if you write against the state as if it was local state, what should happen if multiple people added the same piece of content. Again, in the traditional stack model, this problem doesn't really exist because it just depends whoever's request comes first, and then there's one central state. In this case, you have distributed state, and how do you

solve for conflicts and distributed state? And what you get then is something that works very similarly to GIT. And again, different local first frameworks or services do different things, but what seems to be the most common is to rely on a technology called conflict free replicated data Types or CORDTS for short. That's the term that's starting to be thrown around more. That's an idea that JAZZ is based

on that many others are based on. And the way I like to illustrate that is that it's very much like GIT in that have your local state that you work with, and then you share your edits with other people and there's something akin to merging and contract resolution. The difference to get is that it's much more fine grained well, and get you kind of do pretty large commits right over, like maybe an hour's worth of time

or something for crdts. Imagine if you made these commits smaller and smaller until like every single keystroke and every single edit of an object property becomes a commit, and then that's what you think to Actually, objects no longer are like their current state, but they're just represented by the entire history of everything that ever happened to them. And again, I have to be careful here not to get too specific to how jazz works, how jazz interpret crdts,

but this is like a common story. And what Jazz does basically is you as the application developer. It gives you an API that makes these objects look like simple, mutable objects that you can write to and read from the hood. It converts these edits into changes in the history, and then kind of reconciles that history with everyone else who's interested in the same object based on their edits. Does that start to give you an idea?

see that with your Google Docs example. But my approach there is to be like, no, this is actually a better way to build any kind of app, and the real time multiplayer is kind of just the extreme case, and anything less interactive than that can still be solved with the same pattern. And one of the major other features that you get from local first is that it is offline first, because you can write against you state locally.

Even if you don't have a connection, your app keeps working, and you just think when you come back online, and you can kind of imagine the spectrum of like really intense, really interactive real time multiplayer on the one end, and like being completely offline on the other hand, and then in the middle you have something more like a traditional app where you have like some multi user collaborative app like a productivity app, or maybe a social network where

you have some frequency of interaction. And so far we needed very different ways of building apps and frameworks for each of these cases. But Cordts and the idea of local first is actually something that lets you solve all

of these cases with one abstraction. And what's nice there is that you don't have to choose what kind of app you're going to build because some parts of your app some features might be more real time, some features might be like less frequent updates, less collaborative, more personal, and so on. And that's kind of what really got me into the idea and where I'm like, oh, this can actually solve a lot of things.

the dom is so good good, I'm not. I'm not building things that are large enough or I don't even know things exist that are large enough that just JavaScript as it is isn't good enough these days?

at any time. You you could actually build us on top of jazz that you can implement authoritative state with a local first framework, but it's going to be more awkward than the traditional.

this point. Another thing is like if you need some of the more advanced bread and butter database features like in DCS over huge amounts of data, full text search, that's something that we haven't implemented as features yet, but they're not like impossible to do with local first. So this is an interesting example to kind of start giving you an idea of what kind of apps it's already really good for. Maybe where the boundary is like.

different storage implementations under the hood. It could communicate over web sockets, web party see in the future maybe something like quick and what that lets you do is like really quickly build apps on the abstraction level of like what do users do in my app and what kind of objects do they interact with? That's kind of all

you have to think about and what you like. Because of the performance characteristics of local first, what you get away with very often if you have apps with like small teams where a couple people interact, you can literally keep all the data belonging to that team locally on each device. The only reason it's hard to scale, for example, productivity apps is because in a traditional model, the central database kind of needs to keep the data for every

single team, which might be millions of them. With local first, each of the team's devices just needs to keep the state for the whole team. And Linear is actually a good example of an app they build their whole own local first technology and infrastructure. They keep all of your team's issues locally on the clent, and that gives you

incredibly fast you X interaction on the client. We see with a lot of Jazz apps where people ask us like, look, I want to implement search in my app, so for that, I need an index, right and so far in every case you can literally just brute force your way over every single object in memory, and it's way faster than any like search feature against an API that that you've seen in any other app. That's that's kind of what it's already really good at. Obviously.

that don't fit on a single client's device anymore. And that's also where we start seeing differences between Jazz tools and some of the other local first solutions because they are very much what I would call like sink the world, like you actually have to keep the entire state and the client, whereas Jazz from the beginning was built to support granular sync, where what it does by default that it just thinks whatever objects you're trying to display right now,

and then over time you kind of accumulate everything that's important to that user, and you can like a big

things again if you don't need them anymore. But that means that you can now have like a local first experience for the data that you're actually interested in, but you can still work with potentially infinite data sets, and then you can build You can build indices against tens of millions of objects, for example on a server work and then the index itself again becomes a sinkable object, so the client can create the index locally, see which objects it might need to load, and all of that

is it's like not one extreme or the other. If you make local first granularly sinkable, you can actually create request and networking patterns under the hood that are very similar to traditional stacks with APIs. But again, you as a developer don't have to think about that. You just think about which objects do you want to have and kind of request them as needed, and it loads whatever you need.

put the object and some options into the function. I get the same result out every time. You know, it's very grug brain dev type stuff.

like from what I'm hearing, this is very opinionated. It's like you buy into this way of doing it and you're going to adopt it, which I think is great. It's probably not something that I personally latch onto. But I do really really believe that, you know, if you're gonna if you're gonna make something really great, yeah, integrate it and just tell people they have to buy in. But I'm I'm not sure if I'm representing that correctly. Is this like a very streamlined, top to bottom solution.

Or is this something where I can kind of take the approach of just plain objects and plain functions and build an application where I'm essentially replacing my res diish calls with jazz Ish calls.

defines how what I'm calling CO values work. Which these are your new primitives, and they are very much like they're supposed to be, just like collaborative Jason. You have objects, you have lists, and a bunch of other things for like text and rich text. But it's basically what if what if? Yeah, what if Jason was just collaborative? And that's your abstraction. It like, if you read it, it

looks just like Plaine Jason. If you write to it, you kind of have the choice between two different APIs, and that's where we get into the higher level opinionated thing. What Jazz implements is something very similar to and like react. People with no libraries like mobs, where like you know and React, even with like just used with use state, you get like the current readable version of the state and an update the function. And that's basically what using

Jazz is like currently. It even exposes a mutable API where you can literally just do like object dot property equals something and it will update it under the hood. But we'll probably move to something more. React is where it's like you get you subscribe to a collaborative value, you get a readable version of that every time something happens to it, and if you want to mutate it, use this update your function in which you can mutated. That's what replaces either your rest calls or what replaces

your local state updates. That all just becomes one. And the nice thing is you just subscribe to updates, whether they come from locally because you edited the object, or whether they come from other users who are like remotely changing that same object. And in new subscription you can update your UI. Obviously, again with something like React, that ties directly into the render loop like it just rerenders your component. But there's also Jazz Browser if you want

to use it and plain JavaScript. You just have a subscribe callback in there. You can do to the dorm whatever you want based on the newest version of that value. That's as simple as it is. What Jazz as a framework introduces to kind of structure your applications more almost in like a rail sense, is that it has this notion of schemas, which are similar to database schemas, where you say, like, look, these are the kinds of objects that I have in my app. They have these properties

with these types. Jazz has chosen to represent these schemas using classes because it's way easier in Typescript to have classes because you can refer to them as a type and as a value. So we can kind of use this schema information both at typing time so we can give you nice type inference for your apps objects, as well as at run time to do validation and stuff

like that. We've noticed that even just seeing the class syntex throws a lot of people off, So in the next version of the API will probably move to something that makes it look even more like the plane data that it is really but yeah, under the hood, it is really like collaborative Jason like objects that just have

this editing and merging implemented. And my hope is with the protocol becoming open that not only might there be other frameworks on top of it that might different API designed choices but are still like wire compatable, but it can also be it would also be really easy to port it to other programming languages and environments, because one very interesting thing you can do is you cannot just

write client applications with Jazz. You can write server workers. Said, well, that's also just listen to these co values can do some external side effects to talk to third party APIs, or they could receive a web hook request and in response mutator co value which done some cliency. And right now you can kind of only write them a note Jazz because right now Jazz is only implemented in Typescript.

But if the protocol is open, there could then be like cojacent for Go or for Rust or for like whatever language you want, and you could write these complex systems that all use this really nice model of collaborative values and no one has to think about transport or persistems.

It's implemented and not Jazz. It's open source. It persists the history of the co values into esculate and the future. It will persist it directly onto the disk. But that's not really a format that you can interact with it like, it's just like primitive internal data basically. So that's one thing. And like Jazz tools, my company, Garden Computing, is running the sink and Storage Server as a service like as infrastructure that you can subscribe to, has a free tier

and so on. What's nice about that is if you use that, you can just start building an app and basically only write front end code and it sinks and persists. Do that and you have a whole functioning app with multiplayer and everything. But again you're not locked in. It's open source and so on.

jazz script for example. And what that lets you do is, like I said earlier, you can do server side things in reaction to CO values changing, or you can create co values in reaction to getting something like HGTP requests. And that's kind of one way in which you can

connect jazz date to the external world. One thing you might want to do in a server worker, for example, is to take jazz state and it's like high level structured form and replicate it the current state into like a traditional scale database, either because you want to connect it to an old part of your app that uses JAS and you want the jazz state to be integrated with that, or you might want to run some queries

that like that particular database is very good at. For example, one app someone is building with jazz right now, they use Jazz for like ninety nine percent of it, but then they want to do some really deep analytics on all the user interactions that ever happen, and that's just not something that Jazz is very good or fasted yet. So what they do is they have this like background process that sings jazz state in DUCTV, which is really

good at these kinds of curse. So that's stuff that you can do that that's kind of your adapter to the XCEL.

One of the things that I'm getting more into these days is running things over a web socket and so instead of having the worker kind of send these updates over ar rest API or whatever, also being able to you know, kind of stream them over the socket and get responses over the socket. And I'm assuming that that's either something you've got or something you're working on.

example is, Okay, you're pretty happy with your app. It works great, but you want to add something that's like really really real time where you're like, oh, do I need a web socket now, how does that integrate with Rails. What you could do is basically just build this feature with Jazz and that will work. Perfectly internally for that feature, but there might be some parts of the state that

the rest of your existing app is interested in. Right, So what you can do then is, since we don't have cojacent for rubiat, you could run a little note jazz server that subscribes to the Jazz state and at least puts like the current version of the state into your SKL database, where then rails can pick it up and render it and existing out and that that should work quite well.

local setup, then I essentially eliminate all of the network stuff. Right, So if if I'm on a slow network, or if my connection dies, or if even if I'm not on a slow network, and I just don't want to wait to get a response from the server and I don't need one per se, right because it's just sinking stuff back and forth, you know, it seems like it kind of gives me some resiliency and speed and performance.

is often even trickier than offline. But the main thing is that by not having to worry about requests or back end or like making sure the back end now supports an endpoint that gives you the data that you need to render this thing, you're just like in one context, you build your front then and the data model right next to each other, and you can iterate really really quickly, and you just think about what objects do they need to create or delete or I mean, if you're coming

from like a Ruby on rails background, that's actually what I started cutting my teeth. As a developer. You kind of have have that experience there, but on the back end and the back and also does the rendering, so local first lets you have that on the client, you meaningfully can create modified objects, and often what that looks like is like it looks almost illegal, like in a in a in a button on clickhandle, you create like a whole team and like documents and then whatever you

might have in your app. That's that's the developer experience it gives you. And it's hard to understate before you've tried to help yourself just how quickly that lets you build apps. However, one component that enables that really that we haven't really talked about yet, that I can go into more detail if you if you want this, it's

really it's a really tricky question. How do you do user identity and permissions in a local first way, because that's not really answered by like just the simple way of light it out so far. Let me know if you want to go into that or if you have some other.

is out of scope. We just give you the shared state, you figure it out yourself, or in many of the other cases where they also have folset services, they kind of they do the local first state. But then identity and auth is still traditional in a centralized way, which works okay for a lot of things, but it kind of makes you trade off some of the local first properties you could otherwise have, and it's tricky to do, like, well,

how do you do offline them? Because then you're not really authenticated against the back end that at least checks the permissions and so on. So that's tricky. So for that reason, what I decided to do when I build Jazz is like I saw the crdts that give you the shared sit I was like, damn, this is amazing. I want to build everything like that, but it feels like only part of the puzzle. You also need to

solve user identity and permissions in a similar way. So what I've done there is to couple cred keys with basically good old public key cryptography, where a user in Jazz is just the cryptographic keyper and we'll talk in

a second about where that comes from. And when you make changes to an object, you actually sign those changes with your public key, which means that everyone else who gets your changes, no matter how they got hold of them, whether it was to a centralized infrastructure or peer to pe or whatever, they see the signature and they know, okay, this was definitely Charles who made that at it. That's

kind of the right access part. And for the read access, what you do is you encrypt your changes and then you only give the key to people who you want to see that object. Right. That means that you can now actually in a local first way, so on the client synchronously when you create objects and when you write to them by signing and encrypting them, you know for sure that the permissions have been set up correctly and you don't need to trust the sinking back end to

do that for you. That just needs to exchange the edits, or you might send them peer to peer, and all the edits that you receive you can verify who did them. It gets a bit more complicated then, because you might want to have complex permission structures, like teams of certain people with different roles. So what Jazz implements there is something called groups, which is basically a scope for permissions where you can say, like, look, this person with this

key pair is the admin. They added someone who is a writer and someone who is a reader, and Jazz under the hood make sure that when you receive edits, for example, not only is it check that they have a valid signature, but that they have a valid signature by someone who has the correct role in that team.

The teams themselves are also like CRDT CO values, so they get sing together with everything else, and you can even nest groups so like they can inherit from each other, and with that abstraction you can build basically arbitrarily complex setups like in no For example, you might have a team and you want everyone on the team to be able to read and addit every page by default, but then you might want to add hoc invite someone just to that page to also write it who's not otherwise

in your team. And by using that structure of inheriting groups, you can build all of that in a completely local first way without having to trust any back end, and you can even verify every single edit yourself locally. That's very unique, and like one of the hardest parts of that was to make that fast enough to be able to compete with a traditional trusted back end.

one uses crypto wallets for that reason. So Jazz kind of lets you have pluggable what it calls off providers, where it has a couple of native ones that are really nice. My favorite one is passkey off, where we're using the past key feature to actually store the key pair. So the user experience to the user is like it just prompts you for like touch ID or face ID, but then actually stores the key on your device and only you have that. But it still gets If you're

using Apple devices, it gets sync between them. If you're using Chrome and Endry, it gets SYNCD between them. So you actually have like an end to end encrypted app at that point. But you can also do something more traditional, where like if you want to use something like Clerk or Zero, we have an adapter for that where the key pair gets stored and the user's private metadata, so after they look in Clerk, for example, gives that to the front and the front can then give that to

Jazz as the key pair. That means that basically Clerk and any admins you might have in Clerk are trusted with the keypairs for all the users. But that's kind of the case for any traditional web app already anyway, So you kind of you have the choice, like how deep you want to go there. The nice thing is that even in this setup, neither the app developer nor the users have to trust me running the sink and

storage infrastructure. Like I still never see your data and plain text, I don't have your keys, but I can still do the sinking for you.

to be there. Tomorrow. But that's that's something that's a little bit yeah, but I think I think, I mean, obviously, if you're trusting clerk for your users, you're already trusting clerk for your users, So I wouldn't I wouldn't lay anything additional there, but I would I would seriously warn anyone from trusting past keys as a primary source, because

I've done quite a bit of experimentation with it. As I imagine you're well aware of the the drawbacks of it and the way that browsers implement it differently, the differences between the iCloud ID versus the browser ID. And you could very very easily overwrite your private key, for example, for iCloud and not not knowingly, and and perhaps you're taking I know that there's certain measures that you can take that will prevent the private key from being overwritten

and produce an error instead. But that's one I'm not I'm not yet comfortable with that. I don't feel like that one's sure for that use, cause I think it's excellent as it's a built in password manager. Pass keys as a password manager built in. I'm one hundred percent on board. It's mature, it's good it's ready, use it go. But as something for storing, you know, you've got what sixty four bytes of arbitrary data you can store, and yeah, it's easy to overwrite that.

to and encrypted app, probably they could. That's the kind of app where the users would know how to use passkeys. But right now, yeah, that's that's just something that we offer. Most people want like a more traditional method.

industry right now. It's very seamless. I mean typically the way that it's happening is you just do your normal sign in and then it pops up and says, you know, use Windows Hello, or use face ID and so a lot of people are using passkeys without even knowing that they're using passkeys because they've already been seeing it on their phone, they've already been seen it on the Windows computer, and then it just pops up in their browser like, oh, okay, it's the same thing I've been doing for the last

five years on my phone.

them and change absolutely nothing inside your app. You can also offer your app to like enterprises with weird custom as his own needs or whatever, and nothing about your app's logic around how accounts work, how teams and permissions work has to change, which is something really nice because usually this is a huge topic and your like permission model in your back end is very tightly coupled to kind of the off provider that you choose to use.

their account. But if they do that, and you might even hardcode into your app that that happens by default. A typical pattern in apps that want the more traditional permission model is that they just create an admin account that admins have, that the server worker has, and every user automatically invites that to all of their groups and then you get like this access pattern that's very similar where you can just see all your users data. But we yeah, so that's kind of the mechanics of it.

What we're working on right now is kind of make that a more full fledged browser. For example, if you use jazz cloud as a service and you create an app in there, and people start creating objects on their clients that like if they opt in, or if you enable the default opt in, you can very nicely browse that as if you were looking at like a database you high basically.

But I mean, don't don't most people that build apps don't they want you know, like even Slack right in Discord, like they get to see all the messages, you know, Like with Discord, all the messages are visible by the Discord admins. They get to train AI on them that you know, and say, like with Slack, anybody on the Slack team can look at any of the messages. Anybody who is an admin of your Slack group can look at all the messages. And that's I mean, that's generally

considered a feature, not a bug. Although i personally like what you're saying, I personally am on board with, yeah, encrypt my data, but you know, like, is this what you think the market wants?

And in this case, even like you would be like sure like Slack, if Slack to or decided to use Jazz for whatever reason, you'd be like, sure, Jazz, Slack admins can see all the data in my team. But like Garden Computing, who's running the Jazz service count that's already an improvement, right, and it still gives you, as the app developer, all the freedoms and flexibility that you

had before. Interestingly, if you care about analytics type data, you get much more high fidelity analytics out of Jazz by default, because everything, every object has the full history, so without instrumenting your app in anyway or registering any

custom events. Just in the in the dashboard is the way we'll expose it to is you can see like, oh, these five users from like these cities are working together on this object right now, or like this has been really hot over the last week, and these teams are collaborating like that in a like way that that schema aware of what the objects in your app are, and you get that for free just by like writing to the objects basically, So in that sense, it's almost gives

you more data that you can exploit as an app developer. It's again just that the trust relationship is now explicit.

bit awkward. And migrations is maybe the most awkward thing because you're now basically confronted with distributed migrations like different clients might update you up at different times but still interact with each other at the same time. It's a tricky problem. In what we've found so far is the best thing to do is to just change your mindset a little bit where you can't treat migrations anymore as does like stop the world, will change everything to this

new thing and then continue the database. You have to treat it more as like protocol evolution, where you can only ever add new fields basically, and if you've built graph ql APIs that should be familiar to you. If you've done anything with proto buffs, that's kind of best practices there where in these cases you also expect clients with the old schemer interacting with you, So if you follow that same model, you'll be fine. And because it.

things permanently, and you are able to do that. You basically you mark the object as deleted, and every client and the sinking back will actually delete it.

answered that question too. What I mean is, like all of us that are developing web apps, we all come into this case where we change some property that's you know, I think one of the one of the probably more common ones is if you change anything that's in a cookie because cookies last forever, right, or you change you change some object that can exist out in the wild that's maybe not part of the scheme, as just an ad hoc object, and then you get this problem where

this user calls in and they can't log in, or at least they don't have the experience of logging. Maybe the authentication process succeeds, but their app is just like

stuck in this error state. And then the only way to solve it is that you have to clear out the cab because there's some little property where it's triggering an education your app where it's like if this, then do that, and so it passes the first check, and then it's you know, if that, then do this, and then it fails and it's in this limbo state that you didn't expect because some user that logged in three months ago that still has some local object in local

storage related to how the off object used to look like or how their profile object used to look like. It's the new version of the application code, and it can't like it can't regulate itself, right, like you know what I'm talking about.

database or whatever. It is the reality of the situation is most people are not that mindful, and everyone makes mistakes, and so when when like one fails safe to have that, Like I just working with a buddy on a project, I said, okay, if you get a four to oh one, clear out all the data and log the user out. If you get a five hundred, clear out all the data and log the user out. Because we're trying to build this in a way that we actually don't have errors.

But if we do encounter an error, we just want to say, okay, wipe out all of the local state so that we don't end up in a loop where the person's trying to log in but because they had a you know, that's the kind of thing I'm saying is providing a fail safe to say, hey, if the version has triggered from three to twenty seven, that's more than three version changes, So just wipe out all the local state.

you can literally do whatever in a migration. You can mutate the objects any way you want, and it's up

to you to follow these best principles. But that also means that if you botch something or there's some weird unexpected edge case that you didn't think about, you can after the fact just be like, look, if the state that we're getting at the beginning of the migration doesn't look like any of these standard steps that we take in the happy path, just you know, just throw it away, like whatever, that's something that you can do in a jazz migration.

or some of the other GDPR or whatever. Right this this is the kind of personally identifiable information that I've got to be like extra and especially careful with, and so having it on a local storage, you know, maybe maybe that you know, for whatever reason, I have to have in some kind of controlled back end, and so I'm just gonna have to, you know, do end runs to the server for that kind of a thing. Everything else I can run local first, right, And so yeah, I'm thinking in that.

migration that does soft deletes, right. And what's nice about that, by the way, is that if if you mess up the patch migration as well, which trust me I've done many times, and you can unsoft deleted and you can look at the whole history of botch patch migrations that happen to it and find something useful somewhere in there, because that's what you do with the traditional database, right,

You try your best to write reasonable migrations. If they utterly fail, you roll back or you write more migrations against it, and you do the same on a local level. But yeah, I mean so far, I'm always honest, and I'm like, look, this is the trickiest part. This is the scariest part. So far, everyone who has built apps which jazz has been able to write these migrations correctly,

even though we provide no guardrails. Yet. We're kind of in a stage where we're like, we give you all the tools and we wait for, like, what are the best practices around how to do migrations, and then introduce guardrails on a framework level. But so far it hasn't been an issue, despite these people changing their apps around quite a lot as they iterate on them.

like this is almost not local first at all. I can maybe very quickly mention some examples, but what it's best for right now is if you really care about a good offline first experience, if you want to build any kind of app that has collaboration, particularly if it's real time, but also if it's not real time, just like team abstractions, permissions, that sort of stuff way easier to express. Yeah, I think these are the ones where people get the most value out of jazz right now.

And again, like what is jazz not good at? Honestly, the biggest thing right now is just like we're early documentation is lacking horribly. We're working on it. We're trying to patch that up by just providing good discord support basically, So that's the biggest thing. Like, if you really need it, you'll probably want to use it despite it having bad documentation for everything else, you probably only want to use it for an experiment to get familiar with it. That's

kind of the main bottleneck right now. So in terms of the adopt is just to paint a picture. One of our earliest ones. They're building like an app for freelancers to collect invoices out of your cloud Flare, your

AWS to then submit to tax authorities. But what they a is that actually locks into your AWS and your cloud Flare with you use the name of passwords, so you kind of you need to be able to trust that app as much as you would trust the password manager, and for them, obviously the whole permission and encryption thing was a godsend because they got all of that for free, and they wanted to just make it a single player

experience in the beginning, just for individual freelancers. But because they build it with Jazz, they got like org features where you can invite someone from your team to also submit invoices by just adding a button basically, so this was like a very obvious fit. Maybe the most unobvious fit was a guy who's building a kind of social network with his team. It's called learn Anything, like a learn minus anything that xyz I think is the domain.

It's like a mix between Reddit and quorra, kind of like a learning social network where you can be like, oh, I want to learn how to play the guitar or I want to learn rust, and it will have like a community curated list of like tutorials, polls, videos, and so on. So that's still like very much like a social network part and they decided to base their entire

app as Jazz. That's the only database. So in their case, Jazz actually serves these initially static pages of content, and they already get like millions of visitors per week because they've got good SEO, so it's really stressing Jazz in a way that's not local firsts at all. It just

takes a traditional back end database role. But then as a user, like probably in the beginning, you're just passive, but then you're like, oh, I want to start learning this and then track your progress as you read different articles. You can take your own notes in there, and then it magically transforms into this local first experience where you start having your own personal data that's local and really

fast to interact with. But because they build it with Jazz, they didn't have to glue together different systems that are good at either of these. They could just use Jazz to represent all the data they have, whether it's like this global data across US or individual user data. Okay, these are kind of the two best examples I can think of. If people are really interested, you can check out some of my other podcasts where I list a

couple more. But for the sake of time, I think that that gives us a good contrast.

stuff like that, and then if you have any questions, hop on the discord, because right now we're in a face, like I said, where we just we sit down together with people trying things with jazz, answer their questions or even help them build their apps because we learn a lot from that and it is kind of it works,

and it works right away. The nice thing is it is quite a little set up if you decide to use jazz Cloud, because you just start a front end project essentially, and then for whenever you get stuck or you have questions how to best build something, just just coming ask us on the discord.

other stuff? Right, So let's say in an existing React app or view app and go, Okay, these components are going to use Jazz, these components are going to use my existing back end, and some of these components are going to do both, and maybe I have that server process running on the side.

Easiest case is probably if the Jazz state and you' listing state is completely separate and you kind of only need to make it up just for the user identity, so you're existing all works with Jazz. It gets more tricky when it does need to put stuff into existing databases, which is possible, but again no documentation for it. We

would need to help you with it. So to be honest, like right now, the people getting the most value out of Jazz are green field apps, but it is possible to build more complex stuff, and over time we'll have more patterns and examples of that for you to do that without any of our.

this might be really nice. I don't have to figure out how to you know, web socket the thing through action cable on my rails back end, right, I can just you know, I can just put Jazz in on that piece, right, and it just kind of exists outside of the you know, the rest of the app, because the rest of the app, when I search, I don't need it to search the chat log. I just needed to search, you know, the other learning resources that I'm providing people.

But but yeah, so we're gonna we're gonna maybe watch part two together. I'm I'm thinking she might get the two film collection for me for for Christmas. So I'm I'm waiting to find out that before we do. But yeah, so all the dudes out there that uh, you know, you thought, yeah, I would never be able to get my wife to watch us with me. My wife is

one of those wives. Okay, she wants me to watch Pride and Prejudice with her, and she I played Portal and she couldn't bother to watch that, and Star Wars is right out, so I was super super surprised, but she enthusiastic loved dude. So I will I will pick Dune and maybe I'll throw up a link here to the two discs set. And so last week we I think it was last week that we talked a bit about Blue Sky. I was able to get it installed and running. I left an issue open, so anybody who

wants to know, yeah, I I did. Uh yeah, I figured that out. They they used Docker, but the use of docer just makes it more complicated and more difficult to install because you can just create you know, you could just get cloned the repo and then node install and then set up your reverse proxy with Caddy. And so I just gave those instructions along with some additional detail for some optional stuff. So when you see the instructions that you know you don't have to do all

of the things. It's just there's a couple of steps. It's like you set up the environment variables. That's like one half of the instructions is you know, copy and paste this big, huge, long list of environment variables. And then you know, optionally set up caddy for SSL if you're not already using something else to reverse proxy for you, and then you need to have a it's a well known file you need to have reverse proxy to in particular, apart from the slash x RPC or whatever it is.

I didn't My experience with it was kind of man because it's like, this is literally a Twitter clone. And of course, of course my first ten seconds of blue Sky were the same as anybody's first ten seconds of Twitter. I immediately was followed by bots with you know, pictures of women from the chin down claiming to want to be my friend. So I I just I don't know,

I guess joined it if you want to. I've kind of I don't see the allure of it because it's it's literally just a clone of Twitter with I mean, you can you can run a local server and you can set up your data server and that's cool. And you can set it up so that your data server is your domain name. So for example, if you're beyond code boot camp dot com, then your handle can literally be at beyond code boot camp dot com. Mine is

not I didn't. I played around with a little bit, but I just I was a little I just wasn't that. I wasn't that into it because it's it's just it's literally Twitter with the logo changed and maybe a few features less, and you know, you got the local data stor as a feature more. But I mean, I guess cool, good,

you know, go good them. But yeah, if you want to, if you want to install it, there's an issue up that's called it's called something like how to win stall with Node no Docker and it's very very simple, So if you want to do it, I'd recommend it. If you're going to join blue Sky, I think that you have a moral obligation to run a personal data server, because otherwise what are you joining it for. You're like throwing out the baby and keeping the bathwater.

caved with social networks. Yeah, you have your personal.

to join? Rather than what technology are you going to use? And so that's where I don't unless they have a unique value proposition where it's like I can do this here that I can't do there, I have a hard time believing that it's going to really bloom, especially because they're investor backed and investors don't care about personal data servers, that stuff's going to go.

of can't fully believe in it. But yeah, I'm routing on that basis, and so far, the indication seems to be that the people behind it are deeply aware of this conflict and are thinking about it in good ways. But I don't trust the fact that the introducing the monetization part so slowly.

Mostly I went over there because there were people that had left Twitter that I wanted to interact with, and so, you know, as far as that goes, you know, maybe maybe Blue Sky just doesn't get traction and they come back, or maybe they don't or I don't know, but for now, that's where some of the folks I want to be around are and so I'm there, and there are a whole bunch of people on x Twitter that I want to be around, and so I'm there too, And.

Like I've picked some games on here that have a board game geek weight of like four four and a half, and it's like, look, this game's going to take you five hours and you're gonna get way into all of the ins and outs of how it's played.

what they are. But anyway, so they all kind of some of them playing together, right, So it's like if you have other cards that are of this same kind, then you get mine cards or diamonds which are the points or you know whatever, or coins, and you can you can spend the coins to do other things, like you can buy essentially moving your their technology tracks. You can move your marker up the technology track, or you can.

are two cards above it. Otherwise you just go to the one that is above it, and then you you know, you just chain all the way up to the surface, and so you do what each card says, right, And then there's some other complications, like you can have a cave in and so if there's a cave in instead of getting that reward you clear the cave in, right, But.

We're going to run for three months. We're gonna have calls, at least a couple of calls every week and just kind of walk you through anything that you're running into, answer questions, things like that, just so that you can build AI features into your applications. And that's everything from help bots and stuff like that all the way up through just sort of the I've got this text field and I click a button and it writes a summary

for my podcast episode kind of thing. I mean, I'm looking to build something for the top end dev system that I just barely converted over to a SAS where people can come in and instead of having to know which form to go edit the podcast, whatever whatever field in, they can essentially tell the bot, hey move the episode with ONSELM from Monday the eighth or ninth, or whenever this is going to come out to.

you generate three more? So I can pick one and it'll be smart enough to do that. So that's kind of the thing we're looking for. The system that we've been using to have the show notes written doesn't always get it right, and so it'll pick up on exactly the wrong thing and write a summary that we talked about Lord of the Rings instead of JavaScript. That happened once because Dan told a story about how The Lord of the Rings got translated into Hebrew, and so it said, hey,

they talked about literature. And it was like, well, technically, but anyway, So that's the kind of thing. So I'll be teaching you how to do all that kind of stuff and how to choose the right llms to do that, and how to connect to those services. I'm hoping to

have examples in JavaScript and Ruby. If you're doing some other language, you know, we'll give you enough tools to where you can figure out how to talk to the APIs and get authenticated and all that stuff, but you'll have to use whatever libraries in whatever language you're doing. So if that's Go or Alixer or something. I'm just trying to think what other picks I have. I could pick one that would piss everybody off, but I think I'll save that for next week. And yeah, I guess,

I guess I'll just wrap it up there. I have redone the top end Dev's website. I'm currently working through some issues, but if you point out an issue that I'm not aware of yet, I am totally willing to give you a discount or a free month to the JavaScript Geniuses group or something like that.