Previously one wrote about NEAR API JS with Rails 7. After first written, one made several edits to the article here and there to the point it's not smooth anymore. Reason is, it fails. Yeah...
Let's talk a bit about its failure and what we did instead.
(This includes some terminology that may be difficult to understand. Overall, one include a final section containing some terms, non-exhaustively, for explanation).
View Functions are functions that read some data from the contract. These methods are free: you don't have to pay gas fee when calling them. The NEAR API Ruby Gem contains just the function for this. As view functions can be called by anyone, even one whom don't have a wallet (hence no private keys required), it's safe to call it from the server-side. The built-in function makes it easier to call it from the server side and send (POST) the information back to the end user to view the information.
In contrast, if we did this with Javascript, there are some difficulty trying to get things displayed in front; unlike a pure frontend approach, Rails generate the page from the server before sending the content to the user for viewing. Javascript is on the client-side, hence if we need to read data, it requires to first send back to server, processed, and send it back to client-side for rendering, which is just redundant.
Unfortunately, the NEAR API Ruby Gem aren't capable of doing change functions yet, as far as one is concerned. Hence, the easiest is NOT to write your own stuff, but just re-use near-api-js. It's also not easy to re-write what's already written in near-api-js to backend though. There are a few concerns to consider:
If we store the function keys on the server side; In case of a breach, funds might be stolen. Even though function keys have restrictions on how much funds to withdraw from users, it's still funds stolen. It makes better sense to store it on the client-side.
Javascript don't communicate well with Embedded Ruby (ERb): information sending to ERb requires Ajax, and that's just difficult for Rails student like me. Hence, the max one could do after executing a function is to have a pop-up saying it's successful. Professionals could do more than that, though.
This is the worse thing one ever made. Because one haven't learnt until how to cache on the browser (it's in Chapter 9 of Michael Harts Ruby on Rails Tutorial Book, but one barely finishes Chapter 7), one send wallet information back to server, currently including the function keys (which really don't need to, as it's not needed by the view functions, but one is too lazy to remove it for now).
To initiate a request back to server, we need to click a button to send the request. This button is different from the Login button. This means we can't do everything in one click, but requires login first, then send some information back to server in a second click. One have no good idea of solving this, though.
Even if we can cache, we also need to send some information back to a database. With Rails, the easiest way to create dynamic pages is with a database entry. One entry, one page. Therefore, sending at least the wallet address back to the server, just like signing up, is required, to create a dedicated page.
The equal program in React (originally) is NOT to create dedicated page; however, one found that difficult to execute in Rails a dynamic page. Professionals might have different viewpoints, but one don't. Therefore, specific pages it is.
There are just so much stuffs learnt during these few days, so much head cracked, so much blood burns (it seems like there's a heat wave here currently, it gets very hot to the point ones' sweat pores refuses to sweat, hence heat energy gets trapped inside ones' body and burns oneself.) before an MVP is completed. Hopefully with this MVP, one can go forward to make other MVP's easier. With experiences, one will update the technical blog linked to this non-technical explanation article as we move forward.
For the website, visit https://near-greeter.herokuapp.com/ to play with it! You need a NEAR testnet account, though. You can make one at https://wallet.testnet.near.org/ (make sure you memorize this http address; there are lots of scam website out there so it's better to type the address than to go to google and search for "near wallet" and click on a link that's may or may not be legit.)
View Functions: Functions that can be called by anyone, even one without a wallet, for free (no gas fee paid). It's a READ-ONLY operation.
Change Function(s): Functions that make modification on contract's state. It's a WRITE operation. Hence, it requires paying gas fee to make the change, and someone needs to sign the operation. Requires to hold function keys.
Full Access keys: The ultimate private key to your wallet. This key can be generate from the 12-words seed phrase for accessing your account in full. (Some wallet like Fantom use 24-words seed phrase, but it doesn't matter how many words there are).
Function keys: A limited-access private keys with limited functions. Usually, it is dedicated to only have certain access to your account, usually function calls. This key is held by someone else other than yourself so they can make the call with your consent. These keys have a limitation to how much money it can withdraw. (On NEAR, it's 0.25 NEAR by default, unless contract request for more). Upon exhausted, they need to asks for consent from you again to create a new function key so they can access more funds.
Client-side: End-user endpoint. Storing something here means it's "cache" on your browser.
Server-side: Server endpoint. Something that requires computing power to process are send here to process before sending back to client. For sensitive information like password, a "password digest" is generated before sending here, to protect from hackers. (Many more things it do, one could even write an article on it).
A blog post last month by Ruby committer Yuta Saito provided an update on WebAssembly/WASI Support in Ruby, and in it, Saito explained some of the reasoning and backstory. Ruby, Saito explains, was already supported in WebAssembly using Emscripten, but this implementation was heavily reliant on the host JavaScript environment. By moving over to WASI, Ruby can now be used not just in the browser, but also “in a variety of situations such as edge computing, embedded environments, and interfaces for plug-in systems.”
“WASI is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls,” Saito explains. “WASI does not rely on JavaScript at all.”
Comments
Post a Comment