If you’re reading this then you are a participant in the modern web. The web we are experiencing today is much different than what it was just 10 years ago. How has the web evolved, and more importantly – where is it going next? Also, why do any of these things matter?

If history has taught us anything, these changes will matter a lot.

In this article, I will lay out how the web has evolved, where's it going next, and why this matters.

Think about how the internet affects your life on a daily basis. Consider how society has changed as a result of the internet. Social media platforms. Mobile apps. And now the internet is going through another paradigm shift as we speak.

The Evolution of the Web

The web has evolved a lot over the years, and the applications of it today are almost unrecognizable from its most early days. The evolution of the web is often partitioned into three separate stages: Web 1.0, Web 2.0, and Web 3.0.

What is Web 1.0?

Web 1.0 was the first iteration of the web. Most participants were consumers of content, and the creators were typically developers who build websites that contained information served up mainly in text or image format. Web 1.0 lasted approximately from 1991 to 2004.

Web 1.0 consisted of sites serving static content instead of dynamic HTML. Data and content were served from a static file system rather than a database, and sites didn't have much interactivity at all.

You can think of Web 1.0 as the read-only web.

What is Web 2.0?

Most of us have primarily experienced the web in its current form, commonly referred to as web2. You can think of web2 as the interactive and social web.

In the web2 world, you don’t have to be a developer to participate in the creation process. Many apps are built in a way that easily allows anyone to be a creator.

If you want to craft a thought and share it with the world, you can. If you want to upload a video and allow millions of people to see it, interact with it, and comment on it, you can do that too.

Web2 is simple, really, and because of its simplicity more and more people around the world are becoming creators.

The web in its current form is really great in many ways, but there are some areas where we can do a lot better.

Web 2.0 Monetization and Security

In the web2 world, many popular apps are following a common pattern in their life cycles. Think of some of the apps that you use on a daily basis, and how the following examples might apply to them.

Monetization of Apps

Imagine the early days of popular applications like Instagram, Twitter, LinkedIn, or YouTube and how different they are today. The process usually goes something like this:

1. Company launches an app
2. It onboards as many users as possible
3. Then it monetizes its user base

When a developer or company launches a popular app, the user experience is often very slick as the app continues rising in popularity. This is the reason they are able to gain traction quickly in the first place.

At first, many software companies do not worry about monetization. They strictly focus on growth and on locking in new users – but eventually they have to start turning a profit.

They also need to consider the role of outside investors. Often the constraints of taking on things like venture capital negatively affect the life cycle, and eventually the user experience, of many applications that we use today.

If a company building an application takes in venture capital, its investors often expect a return on investment in the order of magnitude of tens or hundreds of what they paid in.

This means that, instead of going for some sustainable model of growth that they can sustain in a somewhat organic manner, the company is often pushed towards two paths: advertisements or selling personal data.

For many web2 companies like Google, Facebook, Twitter, and others, more data leads to more personalized ads. This leads to more clicks and ultimately more ad revenue. The exploitation and centralization of user data is core to how the web as we know and use it today is engineered to function.

Security and privacy

Web2 applications repeatedly experience data breaches. There are even websites dedicated to keeping up with these breaches and telling you when your data has been compromised.

In web2, you don’t have any control over your data or how it is stored. In fact, companies often track and save user data without their users' consent. All of this data is then owned and controlled by the companies in charge of these platforms.

Users who live in countries where they have to worry about the negative consequences of free speech are also at risk.

Governments will often shut down servers or seize bank accounts if they believe a person is voicing an opinion that goes against their propaganda. With centralized servers, it is easy for governments to intervene, control, or shut down applications as they see fit.

Because banks are also digital and under centralized control, governments often intervene there as well. They can shut down access to bank accounts or limit access to funds during times of volatility, extreme inflation, or other political unrest.

Web3 aims to solve many of these shortcomings by fundamentally rethinking how we architect and interact with applications from the ground up.

What is Web 3.0?

There are a few fundamental differences between web2 and web3, but decentralization is at its core.

Web3 enhances the internet as we know it today with a few other added characteristics. web3 is:

• Verifiable
• Trustless
• Self-governing
• Permissionless
• Distributed and robust
• Stateful
• Native built-in payments

In web3, developers don't usually build and deploy applications that run on a single server or that store their data in a single database (usually hosted on and managed by a single cloud provider).

Instead, web3 applications either run on blockchains, decentralized networks of many peer to peer nodes (servers), or a combination of the two that forms a cryptoeconomic protocol. These apps are often referred to as dapps (decentralized apps), and you will see that term used often in the web3 space.

To achieve a stable and secure decentralized network, network participants (developers) are incentivized and compete to provide the highest quality services to anyone using the service.

When you hear about web3, you'll notice that cryptocurrency is often part of the conversation. This is because cryptocurrency plays a big role in many of these protocols. It provides a financial incentive (tokens) for anyone who wants to participate in creating, governing, contributing to, or improving one of the projects themselves.

These protocols may often offer a variety of different services like compute, storage, bandwidth, identity, hosting, and other web services commonly provided by cloud providers in the past.

People can make a living by participating in the protocol in various ways, in both technical and non-technical levels.

Consumers of the service usually pay to use the protocol, similarly to how they would pay a cloud provider like AWS today. Except in web3, the money goes directly to the network participants.

In this, like in many forms of decentralization, you'll see that unnecessary and often inefficient intermediaries are cut out.

Many web infrastructure protocols like Filecoin, Livepeer, Arweave, and The Graph (which is what I work with at Edge & Node) have issued utility tokens that govern how the protocol functions. These tokens also reward participants at many levels of the network. Even native blockchain protocols like Ethereum operate in this manner.

Native payments

Tokens also introduce a native payment layer that is completely borderless and frictionless. Companies like Stripe and Paypal have created billions of dollars of value in enabling electronic payments.

These systems are overly complex and still do not enable true international interoperability between participants. They also require you to hand over your sensitive information and personal data in order to use them.

Crypto wallets like MetaMask and Torus enable you to integrate easy, anonymous, and secure international payments and transactions into web3 applications.

Networks like Solana offer several hundred digit millisecond latency and transaction costs of a small fraction of a penny. Unlike the current financial system, users do not have to go through the traditional numerous, friction-filled steps to interact with and participate in the network. All they need to do is download or install a wallet, and they can start sending and receiving payments without any gatekeeping.

A new way of building companies

Tokens also brings about the idea of tokenization and the realization of a token economy.

Take, for example, the current state of building a software company. Someone comes up with an idea, but in order to start building they need money in order to support themselves.

To get the money, they take on venture capital and give away a percentage of the company. This investment immediately introduces mis-aligned incentives that will, in the long run, not align well with building out the best user experience.

Also, if the company ever does become successful, it will take a very long time for anyone involved to realize any of the value, often leading to years of work without any real return on investment.

Imagine, instead, that a new and exciting project is announced that solves a real problem. Anyone can participate in building it or investing in it from day one. The company announces the release of x number of tokens, and give 10% to the early builders, put 10% for sale to the public, and set the rest aside for future payment of contributors and funding of the project.

Stakeholders can use their tokens to vote on changes to the future of the project, and the people who helped build the project can sell some of their holdings to make money after the tokens have been released.

People who believe in the project can buy and hold ownership, and people who think the project is headed in the wrong direction can signal this by selling their stake.

Because blockchain data is all completely public and open, purchasers have complete transparency over what is happening. This is in contrast to buying equity in private or centralized businesses where many things are often cloaked in secrecy.

This is already happening in the web3 space.

One example is the app Radicle (a decentralized GitHub alternative) which allows stakeholders to participate in the governance of their project. Gitcoin is another that allows developers to get paid in cryptocurrency for jumping in and working on Open Source issues. Yearn allows stakeholders to participate in decision making and voting on proposals. Uniswap, SuperRare, The Graph, Audius, and countless other protocols and projects have issued tokens as a way to enable ownership, participation, and governance.

DAOs (Decentralized Autonomous Organizations), which offer an alternative way to build what we traditionally thought of as a company, are gaining tremendous momentum and investment from both traditional developers and venture capital firms.

These types of organizations are tokenized and turn the idea of organizational structure on its head, offering real, liquid, and equitable ownership to larger portions of stakeholders and aligning incentives in new and interesting ways.

For example, Friends with Benefits is a DAO of web3 builders and artists, is about a year old, has a market cap of around $125 million as of this writing, and recently received a $10 million round of investment from a16z.

DAOs could encompass an entire post in and of themselves, but for now I'll just say that I think that they are the future of building products and (what we in the past thought of as) companies. Here is a good post outlining the current DAO landscape.

How Identity Works in Web3

In web3, Identity also works much differently than what we are used to today. Most of the time in web3 apps, identities will be tied to the wallet address of the user interacting with the application.

Unlike web2 authentication methods like OAuth or email + password (that almost always require users to hand over sensitive and personal information), wallet addresses are completely anonymous unless the user decides to tie their own identity to it publicly.

If the user chooses to use the same wallet across multiple dapps, their identity is also seamlessly transferable across apps, which lets them build up their reputation over time.

Protocols and tools like Ceramic and IDX already allow developers to build self-sovereign identity into their applications to replace traditional authentication and identity layers. The Ethereum foundation also has a working RFP for defining a specification for "Sign in with Ethereum" which would help provide a more streamlined and documented way to do this going forward. This is also a good thread that outlines some of the ways that this would enhance traditional authentication flows.

How to Build on Web3

I'm a developer who recently transitioned into the web3 space from a traditional development background. So I wanted to start building to get a sense of what the development experience felt like. And I wanted to get an understanding of the types of apps that we can build today.

I dove right in and decided to document some of the things I was doing in a couple of blog posts.

How to Get Into Ethereum, Crypto, and Web3 as a Developer – This is an introduction to the space in general, coming from a developer, for developers looking to break into the industry.

The Complete Guide to Full Stack Ethereum Development – This is a tutorial that teaches you how to build out your first dapp.

The Complete Guide to Full Stack Solana Development with React, Anchor, Rust, and Phantom - This guide dives into Solana to show you how to build a full stack dapp.

If you are interested in learning more about web3 in general, you can check out these posts:

The New Creator Economy - DAOs, Community Ownership, and Cryptoeconomics

The Value Chain of the Open Metaverse

The Rise of Micro-Economies

There is ever-increasing interest in and demand for Decentralized application (DApp) development. Therefore, I have decided to come up with a tutorial to help you get started with developing & architecting a modular DApp. We’ll use one of the most popular and widely adopted languages of the 21st century: JavaScript.

We will be working with the following technologies in this tutorial:

1. Nebulas: a BlockChain Platform which allows us to write Smart Contracts in JavaScript. Signup here to get the referral benefit.
2. Nuxt.JS: a framework built on the top of Vue.JS.
3. NebPay: Nebulas Payment JavaScript API. Both for PC and Mobile.
4. WebExtensionWallet: Used to interact with the Smart Contract for payment purposes.

I will be explaining the DApp creation process with the help of an existing DApp, Distributed Stories. It qualified for the new DApp reward on season 1 of the incentive program on the Nebulas Platform.

You can find the source code for the frontend of the DAapp here. The Smart Contract code can be found in the PayloadData here.

It’s not always enough to know about creating a simple to-do app. Sometimes we must also understand how to architect big modular applications.

Focusing on such an app, I will give you a high level overview of structuring a big modular DApp using Nuxt.js and Nebulas. You can get more in-depth by exploring and debugging the code shared above.

What are we going to build?

We are going to create a short story/poem collaboration platform, Distributed Stories. It will allow a user to create a new story by adding a line to an existing story and sharing the story on Twitter. Here’s a demo link.

I will be explaining the Smart Contract and Frontend Architecture in the upcoming lines.

The Smart Contract Code

The DApp Frontend communicates with the SmartContract in order to fetch and write the data. It is then the BlockChain Platform which syncs this smart contract data across multiple nodes in order to meet the decentralization and security needs. This syncing process needs a little time, and that’s why the write process costs time and money in the form of NAS.

Story Initialization

In the below section, I will explain to you the part of the smart contract which defines the Story Object:

"use strict";
/*
Story Constructor which will create the story by providing the necessary field fetched from the frontend using nebpay API explained at the end of this blog:
*/

var Story = function(text, image_url) {
    this.title = text;
    this.address = Blockchain.transaction.from;
    this.hash = Blockchain.transaction.hash;
    this.image_url = image_url;
    this.lines = [];
    this.votes = [];
};
/*  
Init function is used once while deploying the smart contract to 
initialize the parameters if required:  
*/
Story.prototype = {
    init: function() {

    }
};

As mentioned above, every story will have the following fields, out of which text and image_url need to be provided as an argument from the user. For the Address field, the hash can be obtained using the BlockChain APIs explained in depth here.

Data Structure and Storage used in the DApp

The storage module enables the data storage on Nebulas. It enables the permanent storage of data variables on Nebulas when a payment is made. You can read in depth about it here.

/*
With the help of the Storage Module, we are defining following maps and index property, which will help us to keep track of multidimensional data obtained from users. Nebulas recommend the capturing of multiple data points, which may help in improving Nebulas Rank and Search Feature.
*/
var Data = function() {
    LocalContractStorage.defineMapProperty(this, "favourite_stories");
    LocalContractStorage.defineMapProperty(this, "my_stories");
    LocalContractStorage.defineProperty(this, "s_index");
    LocalContractStorage.defineMapProperty(this, "stories_data");
};

Saving and Retrieving Story

Now we’ll look at two of the most important functions used for writing and getting the story on the Platform with the help of Story Constructor and Storage declared in the Data constructor above.

/*
stories_data hash map will contain every story stored against its unique index on the Platform storage module.
Every story index added by a particular user will be stored in a hash map my_stories, in the form of an array.
*/

Data.prototype = {

/* 
Initializing the index on Smart Contract. As soon as people will keep on adding a new story, s_index will keep on increasing. 
*/

init: function () {
        this.s_index = new BigNumber(1);
      },
save_story: function (name, image_url) {
var id = this.s_index;
if (name.length > 25) {
          throw new Error("Story Length error");
        }
if (name == "") {
          throw new Error("empty story title");
        }
var story = new Story(name, image_url);
this.stories_data.put(new BigNumber(id).toNumber(), JSON.stringify(story));
var my_stories_local = this.my_stories.get(Blockchain.transaction.from) || [];
my_stories_local.push(this.s_index);
this.my_stories.put(Blockchain.transaction.from, my_stories_local);
this.s_index = new BigNumber(id).plus(1);
},

/* 
get_stories method will be used to retrieve all the stories stored on the platform.
*/
get_stories: function () {

        var stories = [];
        var total = new BigNumber(this.s_index).toNumber();
        for (let i = 1; i < total; i++) {
          stories.push(JSON.parse(this.stories_data.get(i)));
        }
        return stories;
},

/* 
Remaining Functions can be found out in the Smart Contract Code here.
*/
};
module.exports = Data;

This completes the major parts of the Smart Contract. In the next section, I will be explaining the structure of the Frontend Code in Nuxt.js.

Frontend Architecture Design

As the project grows, and more functionalities get added, a proper architecture set up from the beginning can help us achieve our goal by making debugging easier.

The below approach is a good way to go about it:

/*
Go to the root directory in the source code here and find out the below-mentioned files. This Architecture helps in creating a big modular App/Dapp.
*/
pages/

 about / index.vue  : Static About us PAge

 contact / index.vue : Static Contact us Page

 create / index.vue : Page to Create the Story.

 favourite / index.vue : Stories Liked by you will be here.

 mystory / index.vue : My Stories Page.

 index.vue / index.vue : All Stories Page

store/
 index.js : Vuex code used to make API calls to Smart Contract

 neb_init.js : Importing nebpay and initializing Smart Contract     
               Address here, which gets used throughout the app.
layouts/
 default.vue: Every page follows an architecture where Header and   
              Footer are same. So setting up the default 
              architecture here.
components/

 Header.vue: Header component which is getting used in default.vue
 Footer.cue: Footer component which is getting used in default.vue
 ....

Making API calls to the Smart Contract

I will be explaining one of the API call using nebpay to interact with the Smart Contract and get all the stories’ data for the landing page.

Initialize Nebpay, to be used across the app in store/neb_init.js:

import * as NebPay from 'nebpay.js';
/*
Contract Address can be obtained after deploying the code on Nebulas Platform using their Web Wallet.
It needs to be the Mainnet Address.
*/
var contractAddress = "n1pQHv...................Pm1";
var nebPay = new NebPay();
export { contractAddress, nebPay, result,NebPay };

The below API call code can be found in the store/index.js file:

/*
nebPay API's can be used to interact with the Smart Contract and Chrome extension to perform read and write operations. More details about nebpay API's can be found out here.
*/
call: (store) => {
// args needs to be sent in below format.
var args = "[]";
nebPay.simulateCall(contractAddress, 0, "get_stories", args, {
 listener: function (data) {
  if (data.result != null) {
    store.commit("all_data", JSON.parse(data.result));
  }
 }
});
}

The above code is getting called from component/Allstories.vue.

/*
As soon as the Allstories component gets mounted, it dispatches the call action mentioned in the above lines, which then fills the Vuex Store all_data array and gets rendered in the All Stories Component.
*/
mounted() {
  this.$store.dispatch("call");
}

Like this, you can go around every section in the source code and understand the complete architecture of the DApp.

I hope this tutorial helped you in getting started with DApp development. For any queries, feel free to reach out to me.

When first starting a new software project, you normally choose a certain programming language, a specific framework and libraries. Then you begin coding. After 2 - 3 months you end up with a nicely working single application.

But, as the project grows and more functionalities are added, you quickly realize the disadvantages of a centralized system. Difficult to maintain and unscalable are some of the reasons which will make you search for a better solution. Here is where Microservices come in help.

What are Microservices?

Microservices are independently built systems, each running in their own process and often communicating with REST API. Representing different parts of your application, they are separately deployable and each part can be written in any language.

You can easily see how, by dealing with the problems of a monolithic system, Microservices have become a requirement for any state-of-the-art software.

I strongly recommend reading Microservices (by James Lewis) and On Monoliths and Microservices if you want to understand more in depth what are the key concepts in this architectural style.

What are you going to build?

This article will walk you through the process of implementing a Microservice using Google Cloud Platform.

Imagine you’re developing an application that accepts a text input from a user and determine the category of the key words within the input.

We’ll use an example to illustrate the functionality of the App. Consider the sample text below from the GCP Cloud Natural Language API website:

“Google, headquartered in Mountain View, unveiled the new Android phone at the Consumer Electronic Show. Sundar Pichai said in his keynote that users love their new Android phones.”

Our web App would accept the text above as input, and return the category that the key words belong to, as in the figure below:

_Source: [GCP Cloud Natural Language API website](https://cloud.google.com/natural-language/" rel="noopener" target="blank" title=")

This feature is quite likeable and people use it hundreds of times each day. Now, if you’re going to offer this functionality as a service that receives a high amount of daily traffic, you want to respond with a stable and reliable system.

That’s why we’ll build a lightweight Flask App, hosted on Google App Engine. Integrating it with Google Cloud Pub/Sub will help us handle all the asynchronous requests we receive and help us assure that users don’t wait too long for a response.

Create and deploy the application

Let’s first start with the Flask app (you can also choose Django, Node.js, Go or anything used to build server-side applications). If you’re not very familiar with developing a Flask App, this Flask Series can show you step-by-step how to set up an application.

For the purpose of this tutorial we will use this simple example:

This embed is from an external site and no longer seems to be available

First you need to install the dependencies pip install Flask gunicorn. You will be using **gunicorn** to run the application on Google App Engine. For local access you can run python text.py in the console and find the app on port 8080.

To deploy the app to Google App Engine, you need to take these steps:

• Create a project (follow the ‘Before you begin’ instructions from the documentation). Save the project id for later.
• Create app.yaml file (shown below), which is used by the Google App Engine to recognize the application.
• Run gcloud app deploy in the console.

The app.yaml file looks like this:

This embed is from an external site and no longer seems to be available

Line 3 is important, where you use **gunicorn** to tell Google App Engine to run the application **app** from a file called text.py (the Flask app). You can learn more about the .yaml file structure here. After deployment you should be able to access your project from https://[YOUR_PROJECT_ID].appspot.com.

When building production ready applications, you often want to test your code before pushing it live. One way to do this is to run your App within a server locally. A better approach is to have a development version of the app which can be tested not only from your local machine but also from a hosted environment. You can use Google App Engine versions for this.

Just deploy your App with gcloud app deploy -v textdev (for development) or gcloud app deploy -v textprod (for production).

Then navigate to https://textdev.[YOUR_PROJECT_ID].appspot.com or https://textprod.[YOUR_PROJECT_ID].appspot.com to access the specific version.

Scale to infinity

So far so good. You have a working application, hosted on the Google Cloud Platform. Now you need to add Google Cloud Pub/Sub and Google Natural Language API.

But first, let’s explain the architecture.

Once a request is received, the Flask app will publish a message with the text to a topic (created below). Then a subscriber (Python script) will pull this message and apply the Google Natural Language API to each text. Finally, the result will be saved to a database.

For multiple requests, the app asynchronously publishes them to the topic and the subscriber starts executing the first one. When ready, it picks the second one and so on.

Now you need to modify text.py file:

This embed is from an external site and no longer seems to be available

The code on line 15 and 16 creates the publisher. On line 18 it publishes a message containing the user email and text input.

You only need to fill in the project_id and topic_id (line 6 and 7).

Since the project_id was used earlier, just add it here.

For the topic_id you need to do the following:

• Enable Google Cloud Pub/Sub API
• Go to the Pub/Sub page of your project
• Create a topic and a subscription
• Use the topic name as your topic_id
• Keep the subscription name for later.
  You will need it as your subscription_id

Wonderful! Now you have a working publisher.

Let’s jump into setting up the subscriber. There are two files that need to be created: worker.py and startup-script.sh.

The worker.py looks like this:

This embed is from an external site and no longer seems to be available

The file is slightly larger but we will examine it step-by-step, starting from the bottom.

When the file is executed, the code on line 44 runs main(). This function sets the subscriber with your project_id and subscription_id and assigns a callback to it.

The callback (initialized on line 7) is going to receive all messages and perform the required task (to determine the category of a text). If you follow the code from the callback, you can easily see how the Google Natural Language API is being used.

The interesting line is 11 where message.ack() acknowledges the current message. You can see this is as if the worker is saying: “I am done with this message and ready to handle the next one”.

Now, you need to implement startup-script.sh.

This is a shell script with several commands:

This embed is from an external site and no longer seems to be available

Before explaining the code above, I need to clarify the process.

Basically, Google Cloud Compute Engine gives you the ability to scale an application by providing as many virtual machines (VM) as needed to run several workers simultaneously.

You just need to add the code for the worker, which you already have, and set the configurations of the VM. Together with the worker.py, you also need to add a startup-script.sh which will run every time a new VM boots up.

New VM instances are booted up to prevent delay in responses when a high number of messages is received.

For a deeper and more technical explanation of this process check out the documentation.

Now, let me walk you through the script:

• Line 1: means that the script should always be run with bash, rather than another shell.
• Lines 2 and 3: creates and enters into a new directory where all of the files will be stored.
• Line 4: copies the worker.py file from Google Cloud Storage into the VM (I will explain how to upload your files to the storage below).
• Line 5: here you need to specify a JSON string of your key so that Google can verify your credentials. In order to get this string you need to create a service account. Select **Furnish a new private key** and for **Key type** use JSON. A file will be downloaded to your computer. Copy the content and turn it into a JSON string (using JSON.stringify(key_in_json_format) in a browser console). Paste it instead of SERVICE_ACCOUNT_KEY.
• Line 6: exports the key as an environment variable which will be used by the Google APIs to verify your credentials.
• Lines 7 - 12: sets up configurations and installs the python libraries.
• Line 15: runs the worker.

Now you need to upload worker.py and startup-script.sh to your storage and set up the VM. To upload the files just go here and create a new bucket with the same name as your project id. Create a folder called workers and upload the scripts inside. Make sure to change the worker.py to a ‘Public link’ and edit the permissions of the _startup-script.sh_ to have your service account as an owner.

Configurations and testing

The final step is to set up the configurations of the VM and test the system. Just follow the ‘Create an instance template’ instructions from the documentation and you are good to go!

Once the VM boots up, you can try sending requests to your application and examine how it reacts by checking the logs.

Final thoughts

Going through Google’s documentation may help you a lot. Also check out this tutorial - you may find it useful while implementing some of the steps above.

I want to express my gratefulness to Logan Allen for helping me better understand this process. I hope you find it useful.

Leave any questions or suggestions in the comment section.