Development Update 007—Version 2.0 Stack
After weeks of planning we have decided on a solid development stack for version 2.0. This took a very long time to plan as we wanted to make sure everything would be future-proof going forward. If we decide on the wrong database for example, migrating to a new dataset could take a very long time and may even take the application offline while doing so.
So, without waiting any longer, introducing the version 2.0 development stack!
.Net Core — We decided to pull away from NodeJS for many reasons. Microsoft offer enterprise support plans for developers — so if we ever came across a roadblock during development, we could utilise their support to overcome the issues we’re having faster than it would usually take. Strictly typed and OOP was a must for us, and that is exactly what C# provides. We believe that .Net Core is a great fit for an enterprise level application, such as ours. There are reports online that companies have increased throughput by 2,000% with .NET Core over NodeJS. Debugging is also far easier and overall better with .Net Core over most other popular backend technologies and languages. Most of this backend project will be open source. Only parts will be closed off that could create security vulnerabilities, such as authorisation and identity based features.
Angular — Our entire front end will be built using the most recent stable release of Angular. This allows the platform to stay as a single page application (SPA) for better speed and usability. Angular allows for a complete MVC development environment on the frontend. We will also be integrating Angular CLI (uses Webpack under the hood) for build tasks and productivity. The entire front end application will be open source and available on Github once complete. We will also be using SCSS in the frontend — Angular and it’s CLI work very well with building SCSS on the fly, along with bundling styles per component, and tree-shaking unnecessary classes.
MongoDB — MongoDB gives us the ability to split and distribute our data across many nodes and regions, allowing for high availability, data redundancy and decentralisation. This is achieved through the use of sharding, which is a database architecture that partitions data by key ranges and distributes the data among two or more database instances. In essence, your individual data will be stored in different physical locations, with no single location holding a complete set of your data. In the future, we may create a solution that allows users to become part of this dataset. They will opt-in to the data network as a kind of “masternode” where portions of data in their region will be sorted. These participants will be paid in SCL for their services. This will further decentralise out platform. With WiredTiger for MongoDB, all data is encrypted to the highest level, so that the “masternode” participants cannot access or read the data they host.
Storj — All multimedia uploads will be stored on Storj, the blockchain based, encrypted, decentralised storage solution. Storj offers a great solution to decentralised and distributed storage, along with being blazingly fast with a “99.99999%” uptime. All multimedia, such as videos and images (and eventually audio), will be stored with Storj. We can even set up our very own streaming commands so that Storj can stream audio and video on demand with minimal waiting.
So far, we have started rewriting the backend APIs (migrating from NodeJS). Mizko are wireframing all screens for the brand new revamped 2.0 design in all viewport sizes. Once the new designs are completed, we’ll get an Angular expert in-house, alongside Jade, to begin componentising the entire application and hooking it into the new APIs that the backend crew are developing.
