So, in my mind, one of the primary flaws, or rather a lack of consideration up until this point, is how exactly our application is going to talk to the blockchain backend. Throughout this process I had always pictured the application talking directly to the blockchain. I guess I had been considering the blockchains use as a simple database. However, this isn’t correct in either form or function. While it is true that the blockchain will hold the data and is a database in that sense, accessing the data is significantly more obtuse than accessing elements of a simple database.
So I took this thought and looked at the Hyperledger Sawtooth API. The API shows that you can setup the blockchain implementations as a RESTful API server. This is near perfect for our group, but the issue remains that the specific calls you can make to the API are limited, and we will be unable to change those calls to more application specific ones. This would leave the bulk of the data accessing and storing in the hands of the application, and that’s a lot of heavy lifting for a mobile application, at least in my mind. So I think the secondary approach is what our team should consider.
Basically I would create a RESTful API webserver that would handle all calls from the application to access the data in the blockchain. This would keep a solid separation of responsibilities in my mind: the application as the the front end, the server as the controller and backend, and the blockchain as the database. In addition to the solid seperation, this would allow for ease of access for future development. If our project partner wished to later access the blockchain with a website or some other application, this RESTful API server would make the interactions a lot simpler and would still work just as well for our application. The only concern that our project partner brought up is the extra security risk, but we’ll discuss that another time.
