Hello BitCar enthusiasts!
This article follows on from our last #BitCarTEC 2 article, which focused upon the backend architecture and progress to date. Since that article was released, the team has grown to include a dedicated front-end developer (Rowan) and a Chief Product Officer (Will). Part of Will’s role will be to provide more consistent updates and a link between our technical team and the broader community, so that they can focus upon development of the BitCar Platform. This article provides a progress update and an understanding of some of the challenges thus far.
Front-end Development
The major update on 3rd September, stated that development progress was being hampered by the lack of infrastructure around Ethereum for decentralized platforms and the difficulty in getting and retaining suitable software engineers. Due to this we changed our recruitment drive to find an expert frontend developer, who was interested in learning Blockchain — knowing that we have some of the best Blockchain developers already, who could help train and mentor where required to allow the user interface (UI) to interact with Ethereum smart-contracts. This drive was successful, allowing development of the front-end to start in earnest, with Rowan providing the missing element to our team skillset.
Since joining the team, he has focused upon building his knowledge of the BitCar Platform, starting to map out the frontend technology stack and beginning to prototype screens, whilst the rest of the team have continued to develop and test the back-end smart contracts, which will be deployed to the Ethereum network.
Challenges
Rowan has described some of the challenges he has faced developing a frontend for The Platform, including moving away from a traditional web / API model and understanding the nuances of a decentralized web platform, as discussed below.
Web to Ethereum Interaction
With a background in ‘traditional’ web development, designing the frontend for BitCar has been very different, requiring interactions directly with the smart contracts on the Ethereum Blockchain. Rather than having a direct set of API’s to call, the front-end has to get and set data utilising these smart-contracts, requiring an understanding of available frameworks to make this easier, such as ether.js or web3. Leaning on both Alejandro and Nuno’s knowledge, Rowan has quickly got up to speed and has already developed a prototype for retrieving data from these contracts, with the next milestone being to register a user onto the test platform.
No Centralization
Typically, web applications have a centralized or distributed server architecture, with a DNS address providing an entry-point for users. Developing a decentralized application (Dapp), requires a different mindset around how to deliver content to end-users, including what is required to provide bug-fixes or new releases. Several decentralized storage providers are being looked at to deliver the frontend content, along with ways to provide transparency to end-users as to the technology being used.
Progress
Although we would all like to see more momentum, obviously Rowan is only just starting to ramp up the UI for The Platform. Additional progress has still been made on the smart contracts since the last update and we expect a jump in UI progress over the next few weeks. Hopefully some screen shots will also be available soon to whet your appetites!
The diagram below shows the current Platform progress:
With the frontend architecture being finalised, refined milestones should also be reportable soon, allowing a much granular level of progress tracking.
Questions from our Community
This section of the update will address any technical questions which have come from our community, today we have two that have been answered by our team..
”Maybe you guys should look at running your platform on Hashgraph?”
Although we are constantly looking at the latest and greatest ways to deliver The Platform, Hashgraph is a relatively young technology. The team feel that it is currently un-proven for a production-critical system such as BitCar and would only increase the delivery timeframe for the Platform. Although we will continue to monitor the progress of this technology for the future, it is not something we feel would provide any immediate advantage.
“Can’t see my Bitcar in MEW??? > Need to add it manually.”
The team have been completely focused upon delivering the platform as quickly as possible, however, to answer this request we have just submitted pull-requests to list the BitCar token as a default token (so you do not have to add manually) onto both the MyEtherWallet (MEW) and MyCrypto wallets. This should then cascade into the Tazer hardware wallet too as it uses the same MyCrypto code listing. Additional wallets do not have these direct inputs for us to add manually, (such as Jaxx and Coinomi), so we will need to wait for the volume to force the recognition of the BitCar token.
We value your technical input, so please continue to put forward ways in which you feel we could make the BitCar platform even better.
For now, the team are striving to get a Platform up and running, which is decentralized and built to perfection. This will be the first of more regular updates and we hope to engage with you all more, so please continue to message us in the telegram group with any feedback or comment below, as all constructive criticism is welcomed.
As always, follow all of our social media accounts to stay up to date with the latest happenings, and join our Telegram group to speak directly to the BitCar team.
If you have liked this article please don’t forget to ‘clap’ and share it on your social media pages — the more followers we have, the more successful we will all be.
