NEAR Developer Tooling Community, 23 Apr 2022

Previous Meeting

⏯

youtube image

►

From YouTube: Developer Tooling Community Meeting (April '22)

Description

In our first Developer Tooling Community Meeting, we discussed near-sdk-rs 4.0 release, workspaces-rs, and upcoming tooling projects & features! Then we opened up to any questions you all had. 😀

Join our next meeting!
👉 http://near.ai/tooling-meetings 👈

`workspaces-rs` discussion thread:
https://github.com/near/workspaces-rs/discussions/125

`near-sdk-rs` discussion thread:
https://github.com/near/near-sdk-rs/discussions/797

Follow the latest from NEAR Protocol on:
Website: https://near.org/
Discord: https://near.chat/
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
#Blockchain #FutureIsNEAR #NEAR #nearprotocol

A

Hey everyone welcome uh to the first developer tool community update. This is another weekly series that we're going to be doing uh pretty much every week if you haven't, if you've been registering for all of these we're having a different topic, so the third thursday of each month we're going to go over developer tooling, what's coming up, what's new and get your feedback live from it uh and also we'll post this up to youtube.

A

If you haven't seen, we've been uploading these to youtube about a day, or so afterwards, um so yeah feel free to watch these and um yeah register for the other webinars as they come out this week. We're gonna be talking about workspaces, um we're talking about russ, sdk, the new update uh and then yeah a little bit of a road map update and then q a we'll open it up at the end. So at the at the bottom of the screen, you should see a q, a question.

A

If you could ask your questions, there um go ahead and post them. If you want to come up on stage and ask a question: live uh ping me in chat or just post a message in chat that you'd like to do that and we'll bring you up at the end of the presentation, um so yeah without further ado, do an introduction, um austin b. Do you want to go ahead and introduce yourself.

B

Yeah, of course, uh thanks for thanks for having us and great to see everybody, I'm austin baggio and I'm uh the product manager for the dev tools, team, uh yeah and- and I'm just gonna reiterate what josh said today. We're really excited to just share a little bit of a deeper dive into the sdk 4.0 uh workspaces, rs, and then we'll talk about what we're going to focus on uh for this quarter and share a bit of our roadmap.

B

So um I'm also I'm joined with by austin and fong um I'll I'll pass over to you austin. If you want to introduce yourself yeah.

C

Sure uh I'm austin the uh awesome a I guess, uh austin able. um So I'm I'm the team lead of the court of the developer tools team. So I'm basically focusing on like the rust tooling, so uh we should center around the rust, sdk and stuff like that um and with me I work with you know: font danielle, miraculous and and fong is uh I'll. Let fong introduce himself.

D

All right for sure, I'm fong, I'm a developer on the developer tools, team and I'm mainly focused on rust, tooling. I mean rust, testing and tooling, but uh mainly on workspaces and a bunch of some other stuff too, but yeah mainly workspaces for now.

B

Cool sweet: um let's, let's jump in, let's start talking about the sdk uh austin, I think you want to share the discussion.

C

Yeah yeah so we'll share my screen.

C

You can see my screen there, no right yeah sweet, so hopefully, hopefully, this strong font is big enough. If it isn't someone bark at me, hopefully uh that that should be. That should be big enough to kind of read everything um so yeah just give kind of a high level overview of um what we'll be talking about today. So this is a lot of changes that have happened over a long period of time, uh but since this is the first time we are doing a community meeting, there is somewhat of a lot to cover.

C

So what I've tried to do is try to like consent to condense it down into the things that are gonna change for, like when you're actually building a contract like what will functionally change for you, and I won't go too in depth with like actually the lower level optimizations or anything like that. um So the the first main initiative that has that has been going on with the update to the 4.0 sdk is the uh collections update.

C

So if you're not familiar with collections, these are basically just like data structures, but their the state of it is actually like sharded and persisted onto you, know the near blockchain and then- and this just allows it to be more scalable. um But what we're changing is that we're moving these collections and like basically iterating on them to create like a version two of these which are going to live under uh the near sdk store module.

C

um The reason we're kind of putting in a separate space is because we want it to be an easy transition from the from the old collections, but also we want to make it clear that these are actually like storing data on the blockchain and not just in memory data structures.

C

um So how you can access these new data structures right now is, if you're using any of the 4.0 pre-releases you just have to enable the unstable feature flag. um This is just going to be unstable because there might be some like format changes until until this is actually released, um but anyone can actually play around and use these.

C

Most of them should stay stable, but this is just kind of so that we don't have like uh some bear breaking changes, um so the plan for the migration is just that these will be stabilized soon and then the existing ones that exist under near sdk collections will be uh moved under a legacy feature flag, but they will always be available so that if people want to continue using um the existing collections, they have that's that's totally fine, um so kind of the reasons or the motivations for for creating these.

C

Like version two of all these collections, um the first one would be having a caching layer so that um there there isn't any redundant reads or writes right now, if you're modifying a certain key value pair or any sort of like element in these data structures, everything will be written as many times as you actually call out into it.

C

um So this basically removes all that redundancy so that all all loads from storage are like kept in this caching layer and like lazily loaded and then any changes you make are persisted at the end, rather than every time you do a specific operation.

C

um So this will kind of like optimize uh gas usage for or certain contracts, um not all, of course, but uh the next point of of like why we're doing these changes is that um it's it's a lot less error. So these apis are gonna much more closely match the rust standard collections apis. um So it's gonna be much more like idiomatic rust and be able to like hook into a lot of the like powerful rust.

C

You know, compiler features to be able to make sure there's, there's no like data inconsistencies or, like you know, data races or any sort of, or any sort of like bugs like that, um and then also it allows us to do a lot of uh added additional apis that didn't previously exist. So things like the entry api.

C

If you're familiar with like the rust hash map entry api, it's like a very convenient way to be able to um get an entry and like insert if, if there isn't actually a value or modify, if, if there already is so, it just creates these like additional patterns that that weren't, possibly for and then also allowed to like immutably iterate over a data structure. Rather than having to do everything manually yourself. So to give an idea of like what a pattern.

C

That's kind of like a a little bit of a foot gun that that is exists with the current collections is when you're actually trying to modify value. Actually, you have to like load it into memory. You have to modify it and then you have to insert it back and that's kind of like a disruptive pattern for developers, because it's much more error prone because you actually have to like make sure that you're manually, inserting it back and doing so in the correct way.

C

um So, like here's kind of an example of what you would have had to do before, which is you know, loading the value into memory modifying it and then inserting it back where, with these new data, with these new collections, you're able to like actually modify the values in place and it'll, do everything else. You know for you so that you can. You know just write the code, you need and not have to worry about. You know making sure all the logic connects all correctly, um and this has been kind of a pain point.

C

There's been, you know, bugs opened with this being misused currently, so this will kind of eliminate so many different bugs that make it so much easier for people to just do what they want and have a drop in replacement for uh the rust standard elections. um This obviously there's no free lunch like there will be downsides to this, and- and one of those is just that there is a little bit of overhead with this caching layer.

C

um So there might be, like a you know, a slight coat size increase for people that are using this stuff. uh Another thing to keep in mind is that the the near contract standards are still going to be using the old collections. For now there is a plan to migrate this over in the future, uh but for now that is the case um and then also using this more idiomatic rest api is, is gonna, be very familiar for people that are used to writing roughs.

C

But if you're not used to writing rust, this might actually be a little bit of a hurdle to get over at first just get used to how how this pattern works and get used to this new api, um but hopefully we'll be able to. You know, provide any documentation on how to like switch switch over between the two or you know, help anyone on this on this transition over um and then also another.

C

Another key point to mention is that some of these collections aren't actually backwards compatible on a storage level, because some were kind of modified in such a way that you can't just like drop and replace the old collection with the new one, because there was a lot of like optimizations uh from the you know, reading and writing to storage uh that it made sense for these not to be backwards, compatible um yeah. So so the next point, the next kind of initiative that we're kind of focusing on is, is better air handling.

C

So within the sdk there's a lot of patterns around you know unwrapping or panicking with with air values, and this is kind of it's a little bit unintuitive for people that you know come from writing other types of rust programs where you're used to having like result, handling and like not have to unwrap, or do all this extra code for for certain operations.

C

um So the first, the first support that we're adding with this is, you know, being able to return results at the you know at the function level.

C

So um now, when you, whenever you right now, we're going to have this like temporary annotation called handle result, um and this is going to allow you to like put a result as a return and basically what this is gonna like is it's gonna, create the glue code so that if this does return an error, it's basically gonna panic with that error, um and if and if it is okay with whatever value is in the okay type, it's basically gonna serialize that and return it as the result as it normally would be before, um and this doesn't come at any like any cost like this is basically um going to be optimized away by the compiler, the this level of complexity, um because you can do anything that implements as ref string um and basically just print out that error or like panic with that error.

C

uh So it doesn't have like this overhead of having to use formatting machinery, but if you did want a more complex type that did use formatting machinery, you can do that. So this in this, uh in this discussion, post that you'll have a link to um you, can see like there's a more complicated example where you know you have an actual structured error. Type which has you know, is going through formatting machinery, and you can still use that.

C

So it's like very extensible, but also at the same time uh it can be just as efficient as doing uh operations as you would before um so yeah. I kind of mentioned that uh yeah it just just to be clear like this is just like a temporary annotation in the future. We will remove this.

C

um The reason we're keeping this for now is just because um we want to make sure we're not silently breaking contracts that are returning a serialized result, which is kind of a different thing, where it's basically uh saying that this contract succeeded, but we're gonna, uh you know serialize, whatever the result type is which is kind of a different pattern, um but then, obviously, in the in the next release, like the 5.0 release, this this annotation will be removed, and you can just do error handling how you normally would um and the second parts of their handling that we're kind of improving is the callback handling.

C

So callbacks are common. If you haven't worked built a you know a rust contract before and haven't used callbacks, um they are somewhat um important for doing asynchronous calls and like getting back a return result and completing with it.

C

um But currently the the pattern was that whenever you're using this callback uh annotation it's going to unwrap if there is any error and basically panic immediately and that's not always like a great pattern for developers, because sometimes you actually want to like gracefully handle that error and do some logic specifically if it did fail- um and this basically allows you to like have result- types that you don't have to.

C

You know manually check if certain promises fail, they're succeeded, uh which will make just your code a lot more easily easily written like read and then also just allow you to do certain patterns that you weren't able to do before um some other small stuff. So if you try to migrate from version three to version four, you might see that, like the the one change that might be, the most breaking is just that uh account. Id is now validated by default.

C

um So before account id was an alias to a string, and then there was this another other type called valid account id, which would do all the validation for you and whenever you're, using this type in a contract, you kind of have to think which type is which- and you know, either unwrapped from a valid account id to an account id to be able to interact with things, and it was kind of a very confusing pattern.

C

um So, for now everything within the internal sdk apis are now going to be like just one type, the account id and it's going to be validated by default. But if you want to skip this validation and just have the contract just as optimized as it was before, uh you can use this, like account id new, unchecked method. um There's a lot of documentation on like what the differences are uh between the two or like how you migrate between them and hopefully, all the examples within the sdk and otherwise are gonna, make the transition simple.

C

But that's basically a tldr of that change. um There's also no need to use the the setup alec, which was a thing that was a previous artifact of version, three, which um basically set up the custom allocator to be more optimized for for a wasm smart contract. um This is now just like enabled by default, and if you did want to opt out of it, you can just like disable that feature.

C

um And one other thing: this is probably something that most people don't interact with, but if you're interacting with contracts on a very low level, um there was kind of this weird pattern where you would have to go through this blockchain interface to be able to perform these low level operations and interact with the syscalls directly um you wouldn't necessarily have to, but this was kind of the the uh the pattern given in examples and was followed by a few contracts that were writing low low-level contracts.

C

um But now, if you ever did want to like transition from this, it's as simple as just uh calling the methods directly from uh near sdk, uh the sys module um so yeah the code will be a lot simpler if you're trying to write low level contracts um and yeah, that's that's. This obviously isn't pattern that most people are gonna use. So I won't go too much in detail about that. um The next point, which is kind of an initiative- that's that's more current, like this- is something that's happening.

C

Right now um is there's a nep 264 protocol change, uh which is going to affect the sdk apis with regards to cross contract calls.

C

So there's a bunch of links in here like if you follow them, you can see all the information about like what, at a low level, the the actual protocol change will look like, um but essentially it's just adding another host function that allows utilizing the unspent gas from the current transaction, and this might seem like a very simple thing, but this actually allows a lot of a lot of patterns and allows us to simplify our apis for calling cross-contract calls, because the current pattern is right now is you have to like specify a very a static and specific amount of gas for each asynchronous call you make, um and this basically allows you to like split the amount of unused gas dynamically which will make contracts uh across contract, calls uh much less like uh much less error prone and just like much more ergonomic and code, much more readable.

C

So um that's kind of the the initiative there um there's links to like the prs and the discussion and everything if you want to dig deep into like what this actually looks like um and like what the changes would be like from the current cross contract api to the new one, um there'll be more documentation once this fully finalizes.

C

There is a pr with the implementation and all of the details as it is right now, but that isn't you know completely final, so I won't go too in depth with like uh what this will look like.

A

uh Before we move on, let's just um take a quick pause just to kind of cover the um we have a few questions from somebody yeah.

C

Yeah earlier, let's do that before.

A

We dive in dive into more stuff.

B

No, it's all good, but yeah.

A

Absolutely absolutely um yeah um till asks is: are there uh the state breaking updates? um Are the state breaking updates state breaking from v3 collections, or does this affect the 4.0.0 pre-seven collections.

C

Yeah, so so, if you're, if you're upgrading from version three to version four there's, no there's no breaking changes that you have to worry about.

C

As far as like the collections, the only difference is, if you're, switching from the the collections under near sdk collections, the ones under your sdk store because they're like completely different structures, and it has to be very intentional for you to switch, which is kind of intention, which is you know intentional by default, so that, if you are doing this, you have to like think about the breaking changes and most of the time it's dropping and replace.

C

But um if you're just upgrading from version three to version four, you don't have to worry about anything being uh breaking like you can just upgrade your contract and uh nothing should be. Nothing should be state breaking. If there is anything, that's state breaking then open up an issue like that's definitely not intended awesome that answers that question.

A

Thanks um next question is: how will the new caching feature affect gas fees for performance.

C

Yeah, so so there is a slight overhead. um It really depends on the usage.

C

um That's why it's hard for me to give like exact numbers, because it really depends on how you're, using these collections, to be able to give an estimate about what that overhead looks like um it will save gas if there is a lot of overlap on the on basically the values that you're indexing like say, if you're practicing a key a couple times: uh you're gonna save gas, but if you access all unique values, um there will be a slight overhead, but that overhead grows.

C

If there's a ton of values, you you you access, so there's a lot of complicated like different cases that you could consider um if you have, if you're curious about maybe like a specific one like a specific use case or like you have some code, I'm like I'm happy to just like look it over and give a suggestion on like what the differences will be, um but yeah it's really hard to give like exact.

C

Like you know, figures of like oh there's, you know five percent overhead or or you know it's it'll decrease gas cost by this percentage because it really depends on the usage. um Got it sorry for not being able to give like a very specific answer to that. But hopefully that's helpful cool.

A

No no worries, awesome and then yeah. Just a couple. Shout outs uh uh june's excited about the that they can use the proper account id rather than a string using in vm context.

A

um Super excited about that and then also yeah, a few plus ones for the better and error handling and callbacks I'll also add a plus one to that. I'm really excited. There's gonna be better handling um there as well um cool yeah and again keep keep throwing the questions in the q a button at the bottom, um we'll we'll keep answering them as they come uh as as far as the gas or the protocol, the the nap264.

A

There was one question on that um and it said so. The gas on the new cross contract call will now be automatically allocated uh as in no more static setting of the gas amount.

C

Oh yeah, so let me let me get more in detail with that, because I I really should have covered. That is um there's no. You know flexibility loss like you can still specify a static amount of gas um and you can configure the amount of like basically the amount of the weight of how much unused gas you're going to be allocating to each contract, um but by default. Essentially, each like the api right now that was proposed is essentially going to attach a weight of one to all of the all.

C

The different function calls um with zero static gas, um so it'll just split everything evenly by default um and then, if you do want to configure and like add a static amount to each or just even remove the weight, so you say you don't want to include extra gas on the specific operations. um There's. No flexibility. Loss like this is purely just like a a value. Add like you, don't have to hook into this pattern like you can avoid it.

C

If you want it'll, just be a simpler api and then you'll have this ability to just like not have to think about gas. If you have a very simple use case or if you, if you want to utilize gas more efficiently, hopefully that answers that question.

A

Yeah awesome. Thank you.

C

um So yeah just to kind of tie things in um the 4.0 stable release plan. I know this is like. Obviously a very you know, delayed thing: it's something that I've wanted to get the stable out earlier, but we, the the idea, was to have this improved cross-contract api um in with this stable release.

C

So that's kind of we have to wait for the critical change to come through uh so that the the that implementation within your core has been released, and it has been deployed to test that, um but we won't be able to stabilize the sdk until uh it gets released on mainnet, which is in a month. So um in that month the escape will release, but people can play around with these apis before and like use it on testnet, but because it doesn't work on mainnet, we can't necessarily release it or else people's you know.

C

Contracts will just won't work on maintenance, um so yeah. If people are, if you want to start playing with this on testnet, um that's totally that's totally a possibility. um So yeah, that's the plan and then there's a tracking issue for the 4.0 release. If anyone's curious, when that's gonna happen, like you just follow that issue um and it'll be updated once once that happens,.

A

One follow-up question about the cash cashing: uh it says you mentioned the cashing save gas. If a key is get multiple times is this detected during compile time? Example? Cleverly don't cache if it knows it needs it only once and then cache it. Otherwise, during compile time, as things that are repeated will be known.

C

Yeah, that's not the case, because the thing is you actually need that cash to get the the same api like, for example, when you're doing a get you're gonna be um you're gonna, be getting a reference to the value um and to be able to get a reference to that value. You actually need that the the value to be put in the cache and then you're you're out you're getting a reference to it.

C

This might be getting too technical, but, like um you act, but basically the the short answer is like we can't just like cache um only if it's being ad access more than once, um and not only if it's being accessed once because the api is fundamentally different. If, if that's the case um so yeah, it's just an initiative to to make sure that you know there's no, it's way less error-prone um cool awesome. Thank you. I think that answers our question. Yeah.

A

Yeah feel free again uh feel free anybody to follow up with more questions, keep dropping them in and we'll keep answering as we go, uh but yeah.

C

Yeah, if it doesn't answer, I'm happy to follow up with that and give more detail um so yeah. If there's no other, you know questions right now or for now I'll. Just keep moving on to the to the next kind of.

A

C

Section, but this is more uh stuff that we're focusing on right now or something more for the future and early on is um what we're calling er. This is. This name is very much open to be changing in the future, but is what we're calling right now, an aci which is like our take on on on an avi, which is basically like an application contract interface, and what it's intended to be is uh like a human readable schema.

C

So when someone writes a contract, you can actually have this schema to be able to see how to interface with it, and this kind of provides a lot of flexibility, because not only does it allow people to easily see how to interact with contracts, but you can also generate clients based on this and be able to at compile time connect any sort of front-end script, or even another contract through cross-contract calls at compile time, which is kind of like very powerful to be able to like eliminate a bunch of like redundant duplicate code of having to like define the interface on the front end and on the like.

C

You know on the contract and on the front end and make sure they're you know connected correctly, that's especially difficult when you're doing it in different languages, um so this is kind of the initiative that we're working on right now, um it's you know going to be very it's going to be similar in ways to the solidity avi if you're familiar for coming from the ethereum space, um and but it's obviously going to have its differences, because you know near has differences in its protocol and stuff like that.

C

um There is kind of like an example of what this somewhat will look like, but obviously not final, uh just to give an idea of like what the format will look like, because it's going to have some data about which methods are exposed. What the details about those methods are um and any details around like the serialization format of any parameters or results so yeah.

C

I won't go too much in detail about this because uh around the specific format, because um that is like subject to change like it is something we're iterating on and making sure we're doing it correctly. So um if you do have any opinions about what this you know, what should be included in the schema or um anything that you think is off like please feel free to like either share in this discussion, or there will be one made specifically for the aci in the future um and we'd love your input.

C

It's basically what I'm trying to say here. um So so, basically, the part parts, the three kind of components of like this initiative is one deciding on a schema format that is kind of accessible for everyone, and you know intuitive for people to use, um and then the first part of that is like we want to be able to generate the schema from the sdks that people don't have to like manually, define us or anything. It's basically, you write your contract and then you'll be able to emit this schema.

C

You know file, or you know, idl or whatever it is uh in json format and then uh the third part is just like being able to generate a client from this so being able to like generate the glue code to be able to like interact with this through a client library or through rpc, or you know, through a cross-contract call. um So that's kind of the initiative, like obviously I'm not going too much in detail with this, because it's very early stages.

C

um But if you do want to follow like the kind of proof of concept, um you can see the work that daniel has been doing on his branch. It's all linked in the in the discussion here um but yeah. Once it's more like you know, fully connected and usable, we will kind of share that with the community and hopefully get as much input as possible um and yeah. That's that's pretty much all I wanted to cover.

C

I don't know if there's any like final questions, I might kind of scan through this before I pass it off to fong um yeah.

A

Just one question about uh with the aci asking about: if there will be some sort of implementation of this and explorer uh might be a little yeah soon to um have an answer on that. But but yeah yeah.

C

So likely it's it's maybe possible, um it's it's not exactly so, so the difference is why it probably won't be on the explorer is because um this schema won't actually exist on chain. This is a purely off-chain like tooling thing to be able to interact with um you are like. Maybe there is some way like we can allow to be able to like upload schemas or something like that to the explorers.

C

So people can see like what the contract interface looks like um definitely possible and will give you a lot better diagnostics um and there's so much flexibility with what you can do in front ends to be able to like see which, what contract or how to interact with the contracts and be able to like easily you know, call out into them and perform transactions on them. um So explorer is definitely possible, but more so with with other tooling such as just like any sort of front end.

C

Maybe even the wallet like if you're trying to like interact with certain contracts, I'm not really sure I mean there's tons of tons of different options, but um yeah hope. Hopefully, hopefully that gives somewhat of an answer to that question.

A

C

A

Yeah well without further.

C

A

Yeah, I was going to say yeah uh pass over to fong unless uh there's anything else, you'd like to cover.

C

No, that's! That's! That's pretty much! uh How that will what I want to cover uh cool.

A

Awesome yeah and keep dropping those questions um after fong. Does his presentation uh we'll open it up for kind of an ama on anything, um so keep dropping questions in the q a section at the bottom of your screen.

D

All right sweet, so thanks austin for that update. um Let's continue on to workspaces, see, let me share this desktop. Okay. Can anyone see the discussion notes here? Yep sweets, so um I'll be discussing workspaces today?

D

If uh you don't know what that is uh going forward, workspaces will be um replacing sim uh sdk tests and uh those will be deprecated and workspaces will be the the one go-to stop for that now, since uh it has a lot of nice niceties and improvements over them like uh being able to benchmark and get accurate uh gas usage from uh calling into contracts themselves, while testing um but yeah so like today, I'm just going to be discussing what's changed in workspaces 0.2, so we've added a couple new features like time travel, so you can advance to a future state in the your local testing environment.

D

So this will be if your contract relies on anything time, sensitive or anything related to like block heights or epoch heights. um You can basically just advance into the future and be able to test that really easily that's without like having to wait for the actual blocks to be produced themselves, which is pretty nice. In my opinion, um traveling. It's awesome and uh I'll show this a little bit more and later on in a live demo of uh of testing this with a crown cat, a scheduling contract.

D

Some other noteworthy features is uh compiling your projects on the fly. While testing you can specify a path to your contracts uh project, basically so like. If it's uh you have a cargo.tomo and uh you define like your smart contract in a specific folder. You use uh target there and it'll compile it for you give you back the walls and you can deploy it right then, and there on in the test itself.

D

um Some other uh changes that happened were some breaking api changes such as needing weights before uh spinning up a sandbox, but most of them are pretty much convenience changes. So um if you want to see what that is like, please take a look at the changelog in workspaces. Rs workspaces is really new, so a lot of feedback is uh definitely needed and appreciated.

D

If, uh if you guys can go, take a look at that uh see where we can improve, uh there's, definitely a good amount of cruft that uh I haven't seen that that still needs to be spotted for sure, but yeah. It's uh definitely new and uh it's whatever you guys want to see out of it. uh I just know: there's some features that are really nice to have, but maybe I don't know all of them. So please leave any feedback and without further ado let me go to the demo itself.

D

um Okay, can I see it in my code? Editor yeah yeah. We can see it sweet, so this is uh let me before I go explain what the code does. Let me run it um just so you guys can see the output, and this is the uh the cronkite example itself.

D

You guys will be able to see this on the repo if you want to follow more in-depth. I I've left a couple comments. uh This should be in later this week, but yeah as that's running. Let's uh let me explain what what's happening in here so uh first off, let's just uh first off get some of the concrat contracts inside uh the concat repo. You can find that over here.

D

If you follow this example and that contract will be the manager to schedule your task and run specific uh yeah, basically around specific tasks in the future or any. In a specific time, um but yeah, so this is what it would normally look like for this specific example. We start with uh spinning up a sandbox and with this uh worker that we grab from the sandbox uh being spun up, we can use it to deploy contracts and then uh call into them.

D

So there's a specific counter contract, I'm going to be deploying as well, which is just to increment decrements by one it's um you can find out on the near near examples website and that's like the most basic contract you can get with just like incremented decrementing.

D

um I'm also going to be deploying the manager contract itself, which will be scheduling all the tasks later on. um Then afterwards, we're gonna be creating or we're gonna, be scheduling the task itself.

D

Every hour with this specific call right here- and this is just cronkite specific notation for um for cron syntax, and that would be just for every hour, so yeah and then we'll have to just an agent to be able to run that specific task, then we'll actually like try to actually run it. So uh this is just a lot of boilerplate from like crown cat itself just trying to register the the agent and stuff you can just uh look through chromecast documentation.

D

If you want to learn more about that, but this is the juicy bit where I wanted it, where I wanted to really show so after an agent has been registered to execute the task, we're going to fast forward about an hour into the future or 4 500 blocks, and this will allow us to test whether this task has been scheduled and has been executed or not.

D

So then we'll we'll try to execute the task, given the conditions on the contract that an hour has passed and we can actually like see if the task has been ran or not. And after all that it's said and done, we should be able to see that the task has been ran and we get like rewards for executing that task from our agent and uh yeah and we should see like the amount profited after executing the task itself, and it should be done by now.

D

Let's see my outputs yeah, so yeah, the the agent profited like this amount of yakuto near from executing that specific task we scheduled and all this is using time travel and we don't have so like before. You would actually have to wait an hour to execute this whole entire test, but now we're fast forwarding you only probably wait like a minute or so and yeah yeah. Let me know if, um if you guys have any questions on any of this.

D

But otherwise I can just pass it on to uh austin baggio with the road map.

A

Cool yeah. No, um I don't see any questions yet but yeah. If anybody has any, please drop them in um if you could basically oh yeah, um I was actually just about to ask that someone just posted this question about workspaces js having a similar interface. Maybe we could talk a little bit about the differences between workspaces, rs versus workspaces, js.

D

Sure yeah, um let's see so workspaces js, is basically the js counterpart to the rs version.

D

Its api slightly differs a little bit because it's been out of date for a bit, um but it's being uh picked up now and uh uh you should see like a release in the next month or two with like uh newer api changes and like catching up to what rs has with time traveling um but yeah, mostly js. The js side of things is for front end. If you want to use it for any kind of front end, you want to test on the rs.

D

One is mainly for if you want to want to have like a rust contract and test everything end to end on rust and have those guarantees all be there, but uh for the most part the feature set should be roughly the same uh between the two. It's just that each one will have their own set of conveniences like with different convenience functions and whatnot, but um they're very similar, um like that yeah just testing it out and like like uh the expect. The behavior under the hood is all very similar.

D

It's just spinning up a sandbox node, where you can interact through it via a worker and uh be able to call into contracts, deploy them like usual, but yeah. That's pretty much just what they're.

A

Like between the two, so it's almost like a one-to-one like this is just different languages, but you'd prefer. You would suggest individuals use workspaces js when they're trying to um test like near api js functionality with their contracts versus.

B

A

Rs is not really for that. It's more like digging deeper into rough smart contracts. Is that correct? Yes, so there are things that rust cannot do or rust can do that, js can't and vice versa.

A

Maybe it might actually be a good idea for us to kind of like not during this call, but um as we have this tools list and our documentation kind of go over, maybe like a check mark box of like this is the the features like they they both can do this, but js is is more for this, and and rs is more more helpful for that, but is.

D

There anything like.

A

On the top of mind that you could.

D

Yeah no yeah, specifically just that, like I mean like just rust, yeah rust for the rest, workspaces for rust contracts and uh likewise for javascript, gotcha, typescript.

C

Yeah, I think I think it's important to also keep in mind that they're very interchangeable, like you, can test a job. You know assembly, script or javascript contract with the rest workspaces, and you could do vice versa. If you wanted, I mean some people might want to write a ros contract and test it in javascript, because their front end might be you know in a javascript front end. So it's really just whatever people's preference is.

A

But once compiled to wasm it like it doesn't really matter what you're using it's just testing the wasm file. At that point, right.

C

Yeah there's no connection between between the, um like, whatever sdk you use and whatever workspaces. It's just.

D

That's right, I gotcha. uh Oh one, slight remark: uh it might be a little bit different for the javascript sdk, that's coming, but those will be highlighted when it comes out. Yeah, cool.

A

Cool cool, so they're just pretty much almost similar tools, but um just depending on what language you're more comfortable working with right, cool awesome. um Someone asked also: does this mean that jest simulator, sandbox and local testing are going to be deprecated, um as you uh indicated, this actually works with sandbox. So that's kind of like the playground um that you're- or I guess, maybe I'll. Let you answer this question as well, so.

D

um My local tests do you mean like the unit tests in in the sdk itself, because those will still be there in some form but not but like. If you use like a net simulator in sdk, that will be deprecated.

A

Yeah, this is all for, like simulation like any you're trying to simulate activity on the blockchain. That's what these testing frameworks are for.

D

Yeah so yeah it will be completely replacing that and well it's not really simulating anymore. So it's more like it's almost an accurate representation of what would happen on the blockchain itself. Just it's. It's literally just a a node on the blockchain, but disconnected from the rest of the network.

A

Cool awesome: that's a good good way.

B

A

B

Just getting super specific on that like sandbox, obviously it's designed to simulate um like a real environment. That's that's why we have it and that's why it's going to be a much better uh tool to use in the future um and just being like really clear with with sim tests like yes, it will be deprecated we'll be providing migration like playbooks, um like really good documentation, really good examples um and and of course, we'd love feedback for anyone that is planning on going through the I'll. Just call like the sim tesla workspaces, migration.

B

um We would love feedback so that we can make sure that, uh like you have everything you need all the tools to to do. That.

A

Yeah exactly and the deveral team is going to be working on deprecating uh some tests from the examples that we currently have and then showing how to use these new frameworks on there as well, so um yeah. Definitely and again, please leave us feedback. Any questions issues, comments, concerns, but yeah. You definitely are going to love it more than simulation simulation tests, because I know a lot of developers have had some issues running those um but yeah uh just tests will still be.

A

You can still run those with your contracts and um yeah same like local tests in in your rust. uh Smart contracts will still be there but yeah. This is more like you and then using sandbox, so sandbox not going anywhere we're actually using it. It's just a framework built on top of it. um Someone asked: can we estimate gas consumption? Workspaces rs? I believe that is a feature here. That's kind of one of the one of the awesome things that we have is like a gas profile. Oh maybe we can elaborate on that.

A

I would say a yes. We can estimate gas consumption but b. I remember there was some sort of tool that we were working on, which is like a profiler and actually was telling you how much gas you're using to like spin up the vm and and do all these like kind of breaking it down. Is that in workspaces, or is that going to be in workspaces.

D

um That part, I'm not so sure of but like if you want to estimate gas itself like you, can do it per transaction um like right in workspaces like whenever you create a transaction and submit it to the network. uh You'll get back your gas, your gas burned for it, and you should be able to accumulate all that yourself and see how much gas is being consumed for your whole, entire automation, script or testing workflow.

C

Awesome the breakdown was something within near core. um It was something that was considered being exposed to network spaces, but that's that's not like immediately available, but it possibly could be something in the future.

A

Cool cool and then, as far as like estimating cross-contract call gas, is that something that workspaces will be able to do so I'll know in my cross-contract for my promised chain I can know exactly how much gas each cross contract calls using.

D

Yes, like um like at the top level you'll get the aggregate aggregate of all the cross-contract calls, but uh for each of the receipts or each of the cross-contract calls you should be able to get the gas burnt as well for each of them.

A

Beautiful yeah. No, that's super! That's super awesome, cool. um Okay, a couple more questions: will there be an npm rust package to be able to pull this in as a version control dependency.

D

uh That is not in the plans right now, but could be. uh Please amend a ticket and I'll take a look at that awesome.

A

Cool cool for workspaces, js is the environment setup um new for every test, or only once I have six tests that take about five minutes.

D

um So it depends on what kind of functions in the javascript side you're using.

D

So there is an optimization feature where you can call fork which copies the state of the sandbox and spins up a new one while not having to reunite initialize anything and that's like the fastest way to go about it. But if you're purely just calling into let's say a net every single time, then it will spin up a sandbox every single time and have to reinitialize everything.

A

Cool, let me know yeah go ahead, go ahead! Oh.

C

Sorry, I was just I was just gonna yeah. I don't know if you were completely done with that question, but I was just gonna jump back to the previous one. I think I think, when they're referring to uh being able to pull this in as a virgin control dependency, I think they were talking about workspaces, maybe not sandbox, um in which case there yeah there is, for there is like yeah it is deployed. It is on crates, I o, so you can pull workspaces itself.

C

I don't know, maybe I'm just understanding the question that they asked and maybe we can get a clarification but yeah both these are able to be pulled in through through through whatever build system. You know npm and crazy. Yeah.

D

If it's purely sandbox, then yeah there's npm uh package for it already, if you're trying to use the rust workspaces in npm that'd be a little bit different but yeah. If you, if that's the case, please submit the issue and I'll have to take a look at it.

A

um Cool uh yeah, please, please uh ask any more questions: cool cool cool. um Where can I watch this video again on our youtube, so youtube forward slash near protocol? It will be uploaded tomorrow or by tomorrow. um Yes, you can watch this video again on youtube. Thanks for asking that question um june asks what does it mean by agent profited in the output at the end of your test,.

D

All right, so um it's a little bit yeah. So there's agent is like a thing inside cronkite itself, an agent um executes the task that gets scheduled on the concrete contract and agents. Don't really work for free, so once an agent executes a task it, um it gets a reward. So therefore, like the profit is basically the reward they get from executing the task itself.

D

A

Any sense yeah yeah yeah awesome, um not at all related, but since someone mentioned node npm, are you guys using dev futures or considering moving to deno.

D

I do not know because I I don't work on the javascript side of things that that would be best um left for bo or sir he. But you can uh ask that in an issue on the workspaces js for repo.

A

Yeah absolutely yeah yeah any yeah any of these um yeah again. The discussions that were shared earlier by both austin and fong will be on the individual repos you go to github discussions and then inside there we're having a live conversation about um these future features releases.

A

uh Any kind of feedback that you want to give us would be awesome and then yeah next month on this tooling um uh webinar, we will hopefully have some of the javascript guys on board talk about new api js workspaces js, I don't know, maybe get an update on the javascript sdk, which I'm really excited about as well, so um yeah feel free to come back next month in the tooling tooling meeting and ask some more of those questions. Hopefully we'll have those individuals on the panel um cool yeah.

A

I think I can pass this off now. It's uh to austin b.

B

Yeah, that's a that's a perfect segue in in a month we're hoping to be able to talk about the javascript uh sdk. um Can you guys see that slide there? um I'm I'm just gonna!

B

Go uh I'm just gonna go over at a high level like like austin fong, just talked in amazing detail about some of the stuff, that's really top of mind for us, so this is gonna be a little bit repetitive, but I just wanted to drill a little bit deeper into what we're gonna focus on over the next quarter and share the road map. So um the first one is make near the most successful blockchain for web 2 developers, um javascript sdk, javascript workspaces.

B

This is obviously going to be huge and will help us onboard a ton of uh new developers. Second, we've got streamline and improved developer experience for creating full stack, apps I'll, dig into that a little bit more and then another one is just like from like a like pagoda perspective. We just want to get better at making product decisions. A lot of it is about getting feedback from the community, um and we just want to do that better.

B

So um doing a little bit of a deeper dive into each of these um making near the most successful blockchain for web 2 developers, javascript sdk workspaces, uh workspaces js, um where you're like we're actively working on it.

B

Both here are on it right now um we're hoping to to have that launch this quarter um and and just unlocking an entire new set of developers that are more comfortable in javascript uh writing contracts so um and and just hand in hand with that comes with not just releasing uh the uh releasing the the repos or or updating the repos. It's just.

B

It's like updating, readme, documentation, examples, creating tutorials and all that so expect that to come and keep us honest for for how we can make it as easy as possible for everyone to get started, um streamlined and improved developer experience for creating full stack.

B

Apps um austin already talked about the aci api, slash metadata, slash whatever we eventually call it, um we'll we'll settle on a name um uh yeah and in fong, obviously just talked about pushing workspaces as our primary uh uh our primary testing framework, which comes with with decorating sim tests and making sure that that's a really easy process.

B

um Another another item that we will we'll likely talk about in the future is just getting feedback on project initialization. So our goal for this quarter is to create a spec around how we should think about project initialization in the future. We're not going to promise that we're going to have that done in the next couple of months, but um we obviously need community feedback in that area.

B

We know that there's some some pain around like project initialization like creating your app um uh like the cli and things like that, so um a focus for us um and then the one that I I didn't mention there was was m1 support. um We we just want to have that one support um should be able to install a simply script or um test with the sandbox using an m1 device, so uh we'll be working on that um yeah and then and then. Finally, the like making better product decisions.

B

Getting feedback like one of the things we want to do is more sessions like this. We're gonna, hopefully run three over the next quarter um and uh we're gonna improve our project management, tooling, which hopefully just increases transparency and just gives us a feedback tool uh for uh our feedback mechanism to to get feedback from the community back to the development team um and then the final one is just like.

B

We just want to make sure that we're evaluating all of the other ecosystems, so we're going to give like our team some some time to explore other ecosystems, other solutions that are adjacent to the products we're working on. If you have any suggestions or have any ideas, um uh please just reach out or uh add to the discussion for for stuff, you'd love to see uh cs building, um and then that's that's a segue into the roadmap.

B

um The reason why I'm sharing this is just to reiterate our focus, but also to say what's not on here. um What did you like in the community expect to see on this roadmap from the dev tools team? So um I'm not going to go into d. We've already talked about all these so um but yeah rust, sdk. Getting that launched, uh javascript sdk and workspace there javascript, sdk and workspaces js.

B

So I should say js on sdk, um delivering uh delivering an aci uh working on project, initialization, tooling, and then eventually mobile client, libraries, which uh we'll probably talk about in the future, but the the one plug here is: let us know what we're missing. Let us know what you need, let us know what's broken, um let us know what you expect um and- and we can obviously adjust this. So I think with that. It's it's questions.

B

If there's any other questions, um I've got links to the github discussion here and obviously you can find us on discord and join office hours, but I'm just going to pause. Is there anything else from the community.

A

um Yeah matthias asked um you said something about other ecosystems and curious. What you meant about that by that.

B

Yeah yeah so like one like from like a developer tools, perspective, um obviously we're trying to build everything that we think we need to build to make near like the most easy to use blockchain and to grow. um We're we're hyper aware that there's other layer ones that exist that have solved problems um and and have really elegant solutions.

B

So we just want to be able to give space for our team to investigate what those are um uh and again like this is I'm gonna turn this around to and ask um if there's an amazing tool from another ecosystem that you've used share it with us? Let us know, let us know how like what what we've built so far is has maybe not met met expectations. um Does that answer that question.

A

I think it does um they. They haven't responded. Yes, yes, it does they they. They said yes, cool, um awesome, awesome! You know yeah thanks for the update yeah uh again, please continue to ask questions. uh We got about five more minutes left uh cool, some more coming in what about near cli rs. Is that actively deployed and thinking about how four point x would affect that um so yeah? Do we have any updates on near cli, rs.

C

Yeah, so the cli and the russ sdk versions are not uh are not tied together in any way like you can use any cli version with any uh any sdk version um it is being developed. um It isn't like. Obviously the priorities right now are like these things that we mentioned right now, um but is it is a plan to have like the the rest of the the rest right?

C

The rest cli be kind of have like first class support um and be brought up to feature parody with the you know, the you know traditional javascript uh cli. um I don't know if anyone else wants to add any details, I'm not sure what uh um one of their details, whoever asked them curious about. But um yes, there is a plan to kind of uh push that along and make it actually like. It is usable right now.

C

I I personally like to use it myself, but uh as far as like I I don't know if it has complete feature parody, um but hopefully with the with the next call. There will be people that you know work on work on that and be able to give more detail.

D

Yeah, I can give a little bit more detail too, um so there so mostly it's like still mostly being developed on, uh like as it hasn't actually been, like prioritized as much just as what else has said, but uh yeah like it will have like a lot more features uh in the future, with like extension systems and like being able to uh add more stuff to it than just your normal, near cli, js version of it um like, similarly to some of the other cli tools you might as have seen like just being able to.

D

Let's say I don't know npm, add something and you'll be able to do it like npm, a different sub command or something like that, but yeah most most of this is still being in develop stage. So not much progress has been made on that either.

A

Cool um someone's asking about documentation for near apijs are more hands-on. Examples. um Yeah, like I was saying before nobody on this call is currently working on near apijs. The wallet team uses it heavily and there's some individuals that are going to be contributing to um yeah updating that library. Specifically, it is a very highly used library and it hasn't been getting the much as much attention as we would like. um Yeah definitely been hearing that from the community definitely going to be working on that in this next quarter.

A

They're already, I believe, working on shipping new features in code around that but yeah. I would love to have them a part of next month's conversation about where we're at with that library, because yeah super important and uh really want to uh put a lot of love into engineer, api, js or or nash, as we internally uh refer to it. So yeah thanks for thanks for that question and then yeah. I used to ask about examples. Another person said something about uh these tools are nice. Are you also considering updating examples and documentation?

A

Yeah, that's on the devral team, my team. We are going to be we're actively hiring individuals and we're building up the team right now. Right now, we've been uh primarily focusing on developer support in the channels plug for our office hours, which we have twice daily. If you go to near.org forward slash office dash hours, you can see when we have those in our in discord. So yeah.

A

If you have any questions or concerns jump into one of those sessions with us live and- and we can- you know you can share your screen- can walk you through code stuff, like that. But yeah examples are on the roadmap that we're. Currently, I just kicked off a conversation with the education team and they're, going to be partnering with us to help create a good um set of canonical examples for um yeah for everyone, because yeah right now we have the same examples.

A

We were just kind of patching them and making sure that they all work and not failing so you can see one of our new dev raw members dennis has been doing a lot of testing um in the individual, repos, making sure they're not failing and staying up to date with all the new versions that are being released. But as far as more examples, we definitely have that as high priority, and you can see more to come uh soon, so stay tuned and uh yeah. I love love the feedback, keep it coming. Yeah.

C

One other thing about that is that the examples within the repos themselves are kept up to date with the code. So if you are curious and want some examples of um all the latest stuff you can, you can look inside either the sdk and the workspaces repos.

A

Awesome thanks for thanks for flagging that um cool um what is going to happen with mpx create near app um anybody. Anybody have uh uh comments on that yeah I'll I'll.

B

Take it for now um uh like honest answer, we don't know yet um so like when we work on like the project. Initialization um like problem like near create app, is going to be a part of that, um whether it's deprecated, whether it's just updated, is still very tbd.

B

um Just to be completely honest, um so I will we will share more as we figure it out and it's not just gonna magically go away one day, um we'll obviously have the community involved in in that decision, making kind of an unsatisfying non-answer, but it's the honest truth and we'll figure it out.

A

Totally totally um cool. Well, thank you. So much yeah, I said: hey near seal irs is blowing near cl out of the water just saying uh yeah, no there's got a lot of really cool features in there. I'm really stoked uh to see kind of yeah like we built near cli a couple years ago and having that time and space to kind of think about uh how would we want to do it if we started all the way over from scratch, but yeah? Thank you so much for everyone for joining I'll.

A

Look out for this video to be uploaded either later today or tomorrow, and yeah see you next month. If you, if you want to be a part of any of these other um webinars, we have one each week every same time. Every thursday um check it out come in come into office. Hours hang out with us talk with us and uh yeah get in those github discussions. Give us some feedback. We'd love to have you help us shape our future of our products and tools. So awesome thanks. Everyone have a great rest.

B

A