By Alejandro Ballesteros, Decasonic
During the summer after my junior year of college, I interned at a very exciting biotech startup. LanzaTech was working on creating processes to recycle atmospheric carbon emissions by converting them into ethanol. The entire conversion process depends on the success of several important metabolic pathways in strains of bacteria. Furthermore, these processes can be optimized and improved through successful experimentation and iteration, a major focus of the synthetic biology team at this startup.
I was tasked with developing an application that would allow scientists to input experimental metabolite data and output a time series visualization of the process for presenting and comparing trials in real time. I developed this application using Django with Bootstrap and CSS for the front end. It was pretty straight forward using a traditional Model-View-Controller (MVC) framework.
Web applications consist of two portions that are commonly referred to as front and back ends. The front end is the code that will run on the user’s web browser, while the back end handles the code that we want to run on our server. In Web2 applications, the server side or back end code is typically the code that manages and stores the “model” that we are keeping track of with this framework. This code typically consists of data storage and handling from one or more centralized databases. There are many tools available for building Web2 apps that can be used depending on the exact use case of an application and prior knowledge of the developers working on it.
source:https://towardsdatascience.com/top-10-in-demand-web-development-frameworks-in-2021-8a5b668be0d6
For example, I chose to use Django at the time of my internship because I had prior experience with Python and found the framework intuitive. Using Django allows users to develop the front and back end of a web application with ease in Python. Python is an object oriented language, which means that it is designed to be used modularly by allowing us to abstract logic into “classes” and rely on them later by instantiating that logic as “objects”; this is what makes code so versatile and generalizable. Python is very user-friendly, easy to read, and easy to understand. As a result it is great for new programmers or use cases like predictive modeling that require fast prototyping with limited access to low-level concepts like memory and resource allocation. Django can also be used in conjunction with JavaScript to create dynamic user-friendly front-ends for applications.
Transitioning to developing a Web3 application, many of the same tools are used for the front end. The big difference is that instead of calling a centralized API, the data will flow to and from a decentralized blockchain. If we’re building something on the Ethereum network, we can do this by using Web3.js, an open source Ethereum JavaScript API. Instead of handling logins, passwords, and databases on a centralized server, we end up managing wallets and transactions between different addresses on a decentralized blockchain under the hood. It’s really that simple! You can have the same beautiful front ends we have now for Web2 applications, but all of the data and functionality can be stored on a decentralized blockchain.
In order to create a Web3 application, we need to understand how smart contracts work as they are the fundamental building blocks of Web3 apps that allow us to interact with decentralized blockchains. A smart contract is just a functional executable program residing at an address on a blockchain. You can think of it like a digital vending machine on a blockchain. It has built in logic that allows users and other smart contracts to interact with it in pre-specified ways.
The basic building blocks of a smart contract include state variables, functions, and events.
Source: Scientific Research Publishing (https://www.scirp.org/journal/paperinformation.aspx?paperid=85741)
State variables allow the contract to keep track of all the data that is necessary to accomplish the smart contract’s intended purpose. You can think of them as stored values. For example, if I need to keep track of the total balance of Ether transferred into my smart contract, I would create a state variable to do this.
Functions allow us to specify the actual behavior of the smart contract; whether specific functionality is internal and only accessible to the smart contract itself or accessible to other addresses on the blockchain. For example, we could create a function that flashes a smart light bulb when someone deposits Ether into our smart contract.
Events allow smart contracts to communicate that certain behavior is occurring in the smart contract to the front end of the application and build in asynchronous functionality. For example, if I create an event in my smart contract to alert my front end when someone has transferred ether into the smart contract, I can immediately update the front end to display the updated value of ether in my smart contract to a user.
Here is a very basic example of a smart contract that accepts funds for a community of users and disburses them when a target amount of funds are raised:
In this example, the state variables are the desired funds we’d like to raise in the account, the wallet addresses of all of the members of the community, and the total funds in the account at any given time. Notice that I’ve used the access modifier “private” so that other addresses on the blockchain cannot access these variables.
In our case, there are only two functions: one for receiving ether, and one for disbursing funds to every member of the community. Additionally, if we were designing a front end we would want to know when funds were deposited and disbursed, so we’ll keep track of that using events.
We can see that Solidity is object oriented and has similar syntax as other object oriented languages such as C++ and JavaScript. Like C++, Solidity is statically typed and has access modifier keywords like “private” and “public”.
Building Web3 Applications isn’t that hard!
The content of this material is strictly for informational and educational purposes and is not meant to constitute investment advice or a recommendation or solicitation to buy or sell any asset or to make any financial decision. Nothing in these blog posts should be considered legal or tax advice. You should consult with your own professional advisor before making any financial decision. Decasonic offers no warranties on any content in the material posted in these blog posts, including that it is accurate, complete, or correct. The opinions expressed in these posts are those of the authors and do not necessarily reflect the views of Decasonic. Decasonic is not liable for any errors or omissions in the content of this newsletter or for any actions taken based on the information provided herein.