Creating a Paper Trading Sinatra App
For my first Sinatra web app, I decided that I wanted to make a paper trading platform for Bitcoin. It would essentially be a website where users can create accounts and trade with simulated currency. They would have the ability to create multiple wallets where they can test various different strategies and compare the results. I also planned on making a system where users could compete with ‘competitive’ wallets. This essentially means that this type of wallet would not be able to be edited and would show up on the leaderboard where user’s balances would be shown. The more you make, the higher you’re placed on the leaderboard.
The first thing I needed to do was to create the database. I planned on having three different tables: users, wallets, and transactions. For users, I needed a username, email, and password column. For good measure, I also included a name column, just in case I planned on using it in the future. For my wallets table, the main columns were user_id, name, restriction_type, btc_balance, and usd_balance. The column restriction_type is the column that helps differentiate casual/experimental wallets from competitive wallets, which is important for preventing competitive wallets from being edited. The last table, transactions, has a wallet_id, order_type, amount, and price. I also added created_at and updated_at columns. By default, if you add these two columns, Sinatra automatically fills out those columns whenever you create or update a row. This is important because I want to keep track of when transactions occur and display that information when the user wants to view their transactions.
The relationships of my models are pretty intuitive and straight forward. Users can have many wallets, and wallets can have many transactions. Wallets belong to a user, and transactions belong to a wallet. This also means that users can have many transactions through wallets.
A large majority of the routes lie in the users controller. I created routes for users to login, logout, and sign up. I also created routes that allowed users to view, edit, and delete their accounts. The routes for the wallets controller were similar, with the essential routes carrying out CRUD (create, read, update, delete) operations. I added an additional route (get ‘/wallets/:id/transactions’) that rendered a list of a wallet’s transactions. The transactions controller had the least amount of routes, with index and show routes needed. This is because transactions can’t be created by a user directly, and are instead created whenever a transaction occurs.
One thing that was essential for getting my app running was a Bitcoin price API of some sort. After a lot of digging, I found one a public API from Bittrex that I was able to use. I then incorporated it into my app through a separate class and method which parsed a JSON response from the API into a float that I could use.
Overall, the experience of creating an app from start to finish helped me piece together a lot of the stuff I’ve learned about Sinatra and ActiveRecord. Being able to see why best practices are what they are through trial and error has been a really great learning experience that I feel solely studying cannot achieve.
