In my previous post I introduced my entry for the OST Alpha III developer challenge, Helping Hands. This developer challenge is being put on by the team behind the Open Simple Token (OST), and so far has been an intriguing experience. In this post, I’ll give a brief update on my progress, along with a quick overview of my plan for the next week.
Getting Whitelisted
On their blog post, the OST team promises to approve all submitted applications within 48 hours, however I got a reply and an all-clear within 24 hours, which was awesome. Once I was whitelisted, it was time to start hacking.
Minting A Token
The first requirement of the developer challenge is to mint a branded token. Since I’m calling my app Helping Hands, I opted to go the original route and named the token “Helping Hands Token”. Once the token was all configured, it took a few minutes to get everything set up on the various networks. This didn’t bother me too much though, as I really enjoyed the explanation video that was presented as an alternative to watching the progress bubbles spin round and round. I was so captivated by the content of the video that I didn’t even notice when my tokens had completed the setup process. My only complaint with the video is that the audio was a bit difficult to hear at times.
Getting Connected
The process for getting connected to the API was relatively streamlined, and followed the same route as most other API systems that use a key and client secret. One thing I like is that these are incredibly easy to locate in the dashboard, unlike some other services that make you go digging for your credentials. Overall, the documentation on this portion was more than adequate, and I was able to grasp the entire flow after a couple runs through the quick start guide.
System Architecture
Once I had grasped the requirements for connecting to the OSTKit backend, I was able to start to solidify an overall system-level design. Generally speaking, this is how all the major pieces will fit together.
graph TD
subgraph OST API
OST(OST Kit Endpoints)
end
subgraph Helping Hands Backend
OST-->BE(Loopback Server)
BE---OSTApi(OST Client API)
end
subgraph Desktop Client
BE-- Loopback SDK-->C(Browser Client)
C---D(HTML5)
C---E(Angular)
end
subgraph Mobile Client
BE-- Loopback SDK-->M(Mobile App)
M---ns(NativeScript)
M---ng(Angular)
end
Backend Technology
I’m a huge fan of using Loopback for my backend code, so naturally, my first order of business was to investigate the OST JavaScript SDK. I was really hoping this would work, as I was absolutely dreading the thought of implementing the API spec myself. Not that it would be all that difficult; just more tedious and time-consuming than I’d like on such a short deadline. I want to spend my time building MY app, not fiddling with service integrations.
Much to my delight, the JavaScript SDK seems to be working as advertised so far. Granted, my testing at this point hasn’t been terribly thorough, but I have confirmed that I can at least put in my API credentials and make some basic requests.
Client Technology
I’ve been using Ionic to build my production mobile apps for a number of years and have been looking for a low-risk opportunity to try out something a bit more modern. As this challenge is largely for fun, I plan to implement the mobile clients using NativeScript paired with Angular 5. I expect the road to be a bit rocky here, but am hoping that I can get things rolling quickly once I wrap my mind around the new architecture.
I should also mention that at this point, I have no intention of building a browser-based application for the competition, however I do have some ideas as to how one might be useful in the long term. I think it’s likely that I’ll be pushing the time limits with just a mobile app, so I’ll be focusing my efforts there for the duration of this challenge.
Wrapping the API
One unfortunate aspect of the API is that the client secret and API keys are meant to be just that: secret. Ultimately, this means that I can’t use the APIs directly in my client applications, but rather need to wrap/integrate it in the backend services. This isn’t a major issue currently, as I need a backend service anyways to store application-specific information about users. This will be used for things like name, bio, avatar, etc. I just needed to add an additional field to track the ID of the user on the BT network.
You’ll notice in the screenshot below that Sally’s Person record in the application has a property btId that maps to her user account on the BT network. The current plan is to use application IDs in all of the client code and then map these to the correct BT ID when submitting anything to OSTKit. Currently, I think this mapping only needs to happen for items that I’m explicitly duplicating in the application which at this point in time is only users (Person).
Testing the Endpoints
Once I added wrapper RPC functions for each of the major SDK operations, I used the loopback explorer interface to do some very basic testing. Using this (cumbersome) interface, I was able to confirm that the following actions work through the app wrapper:
- create new users
- list all users
- get user details
- airdrop tokens to a user
- monitor airdrop status
- check user balances
- view user ledger
The only major building block that is missing at this point is the events. However, it seems like implementing this should be relatively low risk, as the integration of all of the other functionality thus far has gone so smoothly.
Next Steps
Over the next week I will be working on getting a simple mobile client app prototyped out that can interface with my bare-bones application server. Since the NativeScript/Angular combo is new for me, I’m expecting things to be a bit slow-going at first. My hope is that I’ll be able to pick up speed after a couple of days and make some good progress. The app will initially consist of the following components (in no particular order):
- login screen
- registration screen
- home screen (current balance and basic nav)
- basic ledger screen
- send tokens screen
- shopping screen
Be sure to check back at the end of next week for another progress update.