Preparing web 2 for web 3.

Web 3 is on its way… like it or not

Those that are sitting comfortably inside of their well designed 2010 web application can either ignore it for approximately 3 more years or start to take notice now.

Most of us understand technology is not the place to get comfortable else you risk being left behind, and when that happens, it gets ugly real fast. Ask Yahoo.

So, at the very least, keeping up with information ABOUT new technology even before it’s viable can keep you and your team in the conversation and ready to take action when the time comes.

With that said, if you’re still solely relying on AJAX server requests with PHP, you should probably start learning new stuff now.

In this post I’ll cover three general areas that make up the full stack web 2 application, how they will be affected as the web 3 transition approaches, and how to prepare:

The front end, server-side business logic, and databases.

The front-end

Front-end user facing systems are going to become, if it isn’t already, THE most important part of your application, and this statement goes well beyond the obvious “because it’s user facing” argument. There are currently three main front-end varieties right now:

• Static with no user input
• Static with user input
• Stateful with a variety of user interaction

Static, content driven web pages are currently delivered to computers either from a single storage facility such as your own server, web host, or the like, or from a network of storage facilities we refer to as CDN’s, or content delivery networks.

The former is a completely centralized system while the latter is a quasi-decentralized system with the difference being that copies of your html/css/js files are kept in several locations globally for faster delivery to the client depending on their location.

Web3 is going to take CDN delivery of your webpage files to the max. Not only will they be stored in multiple locations globally, they will be broken all the way down into byte chunks so to speak and spread across a global network of connected computers like powedered sugar on french toast.

This distributed storage system will be able to piece your files back together on demand as they are delivered to any requesting agent. The good news for you as a web page developer is that you don’t have to learn anything new if you choose not to. The delivery software takes care of everything behind the scenes.

Those currently developing static pages with user input, however, are in for a rude awakening. My best suggestion is to start learning asynchronous javascript programming immediately.

I’m not sure how many of these are still out there and thriving, but I can’t imagine too many because most internet users have migrated to sites managing user experience through asynchronous programming; and for good reason.

Nobody likes to sit around and stare at a grey screen waiting for communication between client and server to complete and nobody will wait for any application that freezes the interface while a blockchain transaction confirms, state channels or not.

This concept brings me to the camp of developers already using stateful front-end systems, which any application taking user input should already be in. While web3 will bring many amazing things on a global scale, one thing that it will not bring anytime soon is processing speed.

The key innovation for distributed networks is global acceptance of state and does not include how quickly state changes will be accepted, for now at least. There are several ongoing projects that are specifically geared toward scaling out confirmation processes but the reality is front-ends will be required to make up for lag time.

This, however, is only the tip of the front-end iceberg web3 is ushering in, so let’s continue this discussion with server-side logic below.

How to prepare for web3 UI’s:

The only change for static webpage developers will be how and where to upload your files. Familiarize yourself with the concept of distributed storage by looking at IPFS and/or the ConsenSys article about IPFS here, Swarm being developed by ΞTHΞЯSPHΞЯΞ, or Storj by the folks at… Storj.

The way we call domains will change as well but this is not necessarily a change for the webpage publisher, this will be a change for everyone using the internet at some point.

For websites taking user input and publishing dynamic content you should become familiar with asynchronous javascript programming and tools such as React from the Facebook Design team. The good news is these things have already become commonplace thanks to Node.js and websockets creating better experiences over http, but if you’re not familiar, it’s time to start learning.

Business Logic

The server side processes of your web application are going to see massive changes. I propose that the back-ends of today’s systems are going to split into two genres, a front back-end and a back back-end. Obviously maybe not in those terms specifically, but in today’s mental framework that’s the best way to understand it. Let me explain:

In today’s centralized application server world we are free to take advantage of absolute control over everything in our system. How information is taken, parsed, processed, delivered, displayed, etc, etc… everything.

As the lines between front-end and back-end capabilities have blurred over time we’ve been able to handle data just about any way imaginable. Well, as it goes, some of that will have to change because the benefits of globally managed state forces us to cede some of that control over data.

Front back-end/Back back-end

Let’s start with how we get to this concept by contrasting two different kinds of data handling.

First we have inter-state changing processes where you’re changing the state of data relative only to itself which includes parsing, type changes, groupings, etc.

Second we have intra-state changing processes where you’re changing the state of data relative to other data such as ownership, relative value, location, etc.

Parsing, for instance, is one major process we can get away with just about anywhere we find a processor. We can choose to keep input completely in the browser and let users basically interact with themselves or we can choose to take information into our own processors, make changes, then deliver it back.

While that isn’t going to change necessarily, the line between where the most correct location and least correct location to parse information is going to get a lot darker.

It’s no secret we have smart contracts on Ethereum that allow us to perform all forms of logic right now, and this includes parsing data. The problem with doing that is it’s just not efficient for reasons that require an entire post all unto itself but the bottom line is:

Any inter-state changing process you have on your server right now will be moving to the client agent, and any intra-state changing processes will be mainly left to the EVM or Ethereum Virtual Machine.

Now let’s not confuse this with the process of actually publishing new state, this only applies to logic parsing through and changing the data, we’ll talk about publishing state in the database discussion below.

How to prepare for front backend/back backend:

To fully understand what is going on here you will need to take a deep dive into blockchain technology and Ethereum. I suggest you do it slowly and in small bites.

Read until you feel confused, meditate on it, then read it again. Go to sleep, wake up and meditate on it, then read again and you’ll find a little more clarity. Do this for some time and you’ll surprise yourself at how much it makes sense.

Once you have a solid understanding of the technology you’ll need to ask yourself, or your back-end development team, who wants to code the inter-state processes in clients and who wants to do smart contracts on Ethereum. The answer to that question will form the basis for your new dynamic in web3 development.

Databases

To SQL or no-SQL, that is no longer the only question. Many have described the blockchain as simply as a giant database, and I say… OF COURSE IT IS!

When it comes down to brass tacks the blockchain is really a database containing bytes tied to a primary key, your memory address in the system, followed by a litany of foreign keys representing past addresses.

That’s it.

All value is drawn from the accurate and persistent recording of bytes in a giant database. This of course naturally leads to the question, are we replacing current database systems with the blockchain?!!? TO THAT I ANSWER….. nah.

Not now, not ever. Sleep soundly knowing your GraphQL/MongoDB/MySQL knowledge will not be deprecated anytime soon. You see, this giant database is really good at storing state and not much else.

Now, just like I said with parsing earlier, you CAN store large amounts of data on the blockchain but the fact is it’s inefficient, expensive, and not the purpose.

The new question for database management becomes what deltas, or changes, within your data should you push to the blockchain store and which should you keep to yourself. This question becomes important for resource management because it does not cost anything to read from the blockchain but it does cost money to store information on the blockchain.

But what about distributed storage mentioned earlier?

Distributed networks are absolutely giving us a new capability to store and retrieve information. While the main network of state management such as Ethereum mainnet is not an efficient method of storing blobs of data, we are developing ways to store data in storage networks. These networks are built for such purpose, labeling the data, and then pushing the labels onto the blockchain for lookup and retrieval.

With that said, this system will still not be a replacement for current database systems. Once data is put into a distributed network you lose control of that data and it could potentially persist for eternity even with attempts to pull it back.

This loss of control is not something that will sit well with us and for a long time. Especially when it comes to any private information no matter what encryption scheme you’re using.

So the irony of a revolutionary database technology lies in the fact that it actually displaces modern database technology very little… it’s everything else you have to worry about.

We’re busy building up for web 3 at Majoolr so check out our website at majoolr.io and see if we pique your interest. Follow us on twitter @Majoolr, our libraries and contracts are posted and documented on github, if you’re a front-end developer that wants to join the movement get in touch!