Dev's Log: "Hello API"
We've been pushing StackorSpend forward on different fronts and this is an account of where we landed with our "backend".
I put backend in quotes deliberately because while it was designed to be consumed as a server, it also works perfectly well as a library to be imported in our mobile app since it leverages an SQLite database.
The API
These are the methods we ended up implementing to be able to properly deliver our app. Some are pretty meaty, while others are simply a wrapper on the external wallet services we connect to. As a reminder, StackorSpend leverages already existing wallet APIs and doesn't bring with it any wallet infrastructure of its own. It's simply an alternative view on already existing wallets.
syncTxns: Our Core Method
This is probably our heaviest endpoint in the API. Its job is to fetch transactions from the source wallet and record them into our own database alongside stack data that we calculate. It has to ensure that all transactions from wallet provenance are pulled so that a correct stack price is calculated, and it is also tasked with persisting all these transactions in our local database alongside calculated state.
Read Methods
The fetchTxns
, getStackCost
, checkPlannedStackTxn
and checkPlannedSpendTxn
methods all read from synced data from the prior method and return some insight from this data. They are used to return transactions, check costs, and to give some idea of the potential savings for a planned stack/spend.
Action methods
These methods all have to do with sending or receiving sats via the connected service. These would be the easiest to implement and are simply wrappers around the existing service's own methods.
The idea of including these methods is to make StackorSpend feel like a full-fledged wallet that you optionally never need to leave.
Accessing the API
Our intention is to simply copy this package into the mobile app and adapt it to our React Native code at first, with the eventual goal being to make it its own standalone published npm package.
The benefit of doing this in this way is so that we have very neat separation of concerns across the team:
-
our design team: simply produces designs
-
our frontend devs: simply implement the designs and connect to the API
-
our backend devs: design and implement the backend API to be connected in the frontend
We've found that this approach has been great for being able to iterate on our ideas and move efficiently since we have access to specialized persons for each of these categories.
The API is still WIP, but you can follow along on GitHub: https://github.com/vindard/stackorspend-backend