Built With Blockchains

Preston Brown

29 days ago by prestonbrown

With BSV being really the first blockchain technology I have ever had “developer” level experience with, I’m going to caveat this entry with my limited knowledge of the developer experience on other platforms. There are many pros and cons to BSV and I’d like to relate my experience. As a traditional software engineer, I spend most of my time writing full-stack services with both “traditional/legacy” architectures like REST with Spring Boot and Angular, and more bleeding edge stacks like GraphQL, React with Hooks, and Kafka.

BSV, unlike other blockchains with very high gas fees, is one of the easiest platforms to jump in and start testing things live on-chain. This makes it awesome to test out potential use cases with relative ease, and without having to throw a bunch of your money into a pit that might not see a return on investment. This also means whatever you build will not be hampered by gas fees, and people are more willing to try out what you’ve built as a test run, without feeling like they’ve overcommitted.

One of the troubles we ran into when building our very first private iteration of BitSurf was the unreliability of blockchain indexing services like Bitbus. Don’t get me wrong, Bitbus is free, and is easy to use, so my criticism is with that in mind. But if you take a look at the Atlantis Slack channel, there are constant issues with indexing and 500 errors that make Bitbus a huge question mark when it comes to using it in your tech stack. This meant that we eventually shifted to relying mostly on Twetch’s GraphQL server, but even then we deal with unreliability issues related to server changes, documentation related to encrypted posts, or expired image CDN addresses.

Another key issue we ran into was finding the best way to unify wallet access, without having to build a custom integration for every new wallet. We ended up using Twetch Pay which was a good first-iteration service. Later on, we discovered Paypresto, which is a great service we plan to integrate. Not only is the service easy to implement and use, but a significant portion of the brand has my name in it :). But even Paypresto has the same issues dealing with custom integrations as evidenced by the removal of Moneybutton. This is another level of inconsistency between service providers that creates uncertainty for businesses.

I know saying this is kind of taboo, as developers in this space are largely expected to help augment functionality and base services layer (largely through open source contributions), but I am not that interested in building low layer blockchain technology. I’d much prefer to consume libraries and services that already do these things, and build new products on top of that. For that reason, I am really excited to see Brenton Gunning’s announcement for the new Run Connect API. Run’s documentation makes it super easy to get started building cool stuff, and the introduction of a unified API reduces a lot of the concerns about working with a symphony of different (maybe competing) dependencies. I know that my attitude can seem selfish, but really my interest is in creating entirely new things using platforms like BSV, and if companies are busy reinventing the wheel on things like data caching and indexing, utxo management, and wallet unification, we will create dependency quicksand for emergent businesses.