Inspiration
Imagine you have to fetch some information from your database through your smart contracts. In a traditional scenario, you would have to set up your own Chainlink node for a specific job task as well as a custom Chainlink adapter API. However, because you are currently writing a NEAR smart contract that makes it even more difficult, as all of the Chainlink documentation is for Solidity and Ethereum. Have fun doing all that on your own.
What it does
Our SDK for NEAR JS smart contracts gives developers superpowers. They can define schemas, build databases and execute queries the same way they do in a traditional web2 Node.js service with Mongoose / MongoDB client. And yes, we offer the same (almost) syntax and grammar.
How we built it
The SDK provides wrapper functions that under the hood emit logs per each query. On our back, there are two services: Transaction Interceptor and MongoDb Query Executor. The first one is listening for all transactions per registered smart contract on our platform. Whenever a log starts with a ‘QUERY:’ the interceptor attaches it to a package and sends all the queries from a transaction to the executor. The latter maps the queries to native mongodb functions and executes them on a database. Currently, this holds for a few users, but we can easily extend it to a lot more. Finally, a response is passed back to the interceptor, which calls corresponding callbacks per query.
Challenges we ran into
Firstly, something that you will notice is that when you call a function CollectionName.find(queryBody…, callback) you have to write the callback as a string. It was initially working directly with callback functions for which we were extracting the “.name” property. However, after upgrading to a newer version of the near-sdk-js this stopped working as the final generated functions were anonymous and didn’t have names. Therefore, we had to switch to the explicit string methodology. Secondly, a challenge was to connect everything: smart contract to interceptor to executor and all the way back. Currently, this is done through the HTTP protocol for the pure purpose of the Hackathon, but we definitely will switch to something more durable in the future. And many more.
Accomplishments that we're proud of
We support both primitive queries (the ones you are used to in traditional mongoose scenarios) and complex ones (our own definition). Imagine you want to leverage information from two collections (for example, two find / select queries) and use the responses to decide upon action. If you use manual primitive queries, they would invoke separate callbacks in different transactions and thus, you won’t be able to achieve that logic. With the complex queries, you can list multiple primitives, execute them in an ordered way and receive all of the responses. You can check that in the example-contract project.
What we learned
We learned basically everything about writing NEAR smart contracts in JS. Super cool! The next chapter is to conquer the Rust SDK.
What's next for Attik
Uploading backup versions of each mongodb to IPFS as the first step towards decentralization. The next one would be a protocol that is completely decentralized (perhaps a chain on Cosmos).

Log in or sign up for Devpost to join the conversation.