STORY
Dev's Log: "Hello API"
AUTHOR
Joined 2022.09.07
DATE
VOTES
sats
COMMENTS

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