Swarm City Dev is hard at work on bringing Boardwalk V2 from idea to fruition. As mentioned in past updates, to get there Dev needed to rebuild everything from scratch. Even functionalities included in the Terminal release; for example sending SWT, the shortcode, and creating a profile, are being overhauled. Also, one of the main challenges revealed with the release of Boardwalk V1 was how the app managed interactions with Ethereum. It became clear this required some rethinking as well.

Boardwalk V1 acted as a direct conduit to the Ethereum blockchain, and what Dev found was this was a cumbersome setup. The frank assessment is the Ethereum platform is so new that tools for managing interactions between a more humanistic front end app and the Ethereum machine do not yet exist. How this manifested to the end user was slow response times, and even dropped or stuck transactions. To solve these issues, Dev created a buffer layer to exist between the V2 front end and the blockchain. This layer is the Swarm CIty API.

Swarm City API

In a nutshell, the Swarm City API is a service layer that lives between the app’s front end (where user interactions occur) and the Ethereum blockchain. To simplify things, it helps to think about what is actually going on from the user perspective. Users engage with the Swarm City app because they want something; for instance they want a good or service, and they create a deal in order to get it. That action, “create deal”, is registered on the Ethereum blockchain. So in fact, what the user is doing is interacting with the blockchain by way of the Swarm City interface. The API is the bridge between a user that “wants” things, and the Ethereum network. The API listens to the user and interacts with the blockchain in order to give the user what they want.

Boardwalk V1 connected directly to the blockchain, and as mentioned above, one issue with that approach is it makes interactions really slow. The API remedies this by taking and storing snapshots of the blockchain, so the Swarm City app can interact with the API for anything that doesn’t involve registering transactions. An example of this is when the app needs to load the user’s token balance. The API makes the front end quicker and more reliable, which means an improved user experience.

Network agnostic

Another important feature of the Swarm City API is it acts like a router. What that means is dev is able to easily plug the app frontend into other Ethereum networks. Since the price of gas has gone up considerably, Dev has decided to use Rinkeby, the Ethereum testnet, while V2 development is ongoing.

But an interesting question came up as Dev began to use Rinkeby. What if they were able to bridge the two networks to get the benefits of both? The Ethereum mainnet is where value is transferred, but is currently challenged by high gas prices due to scaling inefficiencies. The testnet on the other hand is almost infinitely efficient because its gas is infinite. If transactions that take place within the Swarm City ecosystem could occur on a parallel network, transaction costs would be 0.

In collaboration with several other teams including Parity Technologies and Giveth Dev will begin working on bridging the mainnet with a parallel Ethereum network in March of this year. We believe this is a promising temporary solution to Ethereum’s scaling issues.

Swarm City Dev actively contributes resources to help solve ecosystem-wide issues. Their number one priority will always be to deliver the Swarm City app in full, as intended, with industry-best performance. This requires participation with the greater community, because scaling affects all projects, and it will be solved much quicker together.

Connect With The Dev Team

The Dev Team is always on the lookout for other developers who want to get involved. If you have Polymer or Solidity experience, feel free to reach out to #devhive in Riot. You can get a peek at the project by reviewing Github, here. To hang out where our community is, join us in Swarm City Slack.

More to come soon. Cheers!