If you’re familiar with web development, chances are you’ve heard the terms ‘client side’ and ‘server side’. Both are terms that describe where application code runs, and make up something called the client-server model - where user devices establish communication through a network to centrally located servers for acquiring necessary data, as opposed to direct communication with each other. In this model, end user devices (laptops, phones, etc.) are designated as 'clients' engaging with servers, similar to customers using services from a company. Requests for webpages or applications are initiated by the client device, and the server responds by providing the requested information.

For example, imagine you’re exploring the internet and search for pinata.cloud via the search bar. What’s really happening behind the scenes is:

1. A request is made to the DNS (the phonebook of the Internet)
2. The DNS then translates your entered domain name (pinata.cloud) to an IP address and serves it to the browser
3. The browser then makes a request to Pinata server via the IP address for all the content that should appear on the page
4. The Pinata server will then deliver that content to the browser and load the page on the client device

To put it another way, imagine you’re sitting at a restaurant table. You order food from the kitchen and servers take your food back and forth between the kitchen and the table. In this scenario, the kitchen is the ‘server side’, you’re table is the ‘client side’, and the servers going back and forth between the two are APIs. In both the internet and restaurant example, the basic structure of transferring information from one place to another is the same.

Client Side vs Server Side

In web applications, ‘client side’ refers to everything displayed or taking place on your device when you’re viewing a website. This means everything you see and every action that takes place within your browser is considered ‘client side’. A good example of a client side application could be a React app, where the server delivers bundled JavaScript and builds the HTML CSS in your browser. This was a breakthrough when servers were slower and apps started needing reactivity without refreshing the whole page. Back to our restaurant example, you can think of it like the server putting the food together at your table, and sometimes going back to the kitchen to get an additional piece here and there.

‘Server side’ refers to everything that happens on the server, the computing behind the scenes, rather than on the front-facing client. With server side applications the HTML CSS and JavaScript are put together before being delivered to the client, and any kind of interactivity is happening on the client side as well. Again in the restaurant, the kitchen is building a complete dish and the servers are just putting it on the table. This approach has become more and more popular over client side application infrastructure because servers are faster than they used to be, and the ease of use has made frameworks like Next.js very popular. However, when you try to port a server side app to IPFS, that’s where things break down.

How Does This Model Fit With IPFS?

Since IPFS is a distributed file sharing network it only accepts static content. Server side content is constantly ‘moving’, there’s necessary behind the scenes computing to be done. The kitchen has to cook the food before it’s sent out to the customer. With IPFS, there is no kitchen, and there is no single point of entry either. You can think of it like food delivery services that might transport premade food from lots of different kitchens. Each computer running an IPFS node is one of those delivery workers, helping transport and distribute premade food. So if you wanted to host a website on IPFS, you’ll need to bake it first, and share the finalized ready-to-go HTML CSS and JavaScript.

This is why some server side frameworks like Next.js are not compatible with IPFS, because they require an ability for the server to serve dynamic content. In other words, if your app has some kind of backend logic, it won’t work because backends can change data, and IPFS is purposefully designed with data immutability in mind.

Conclusion

While some are focused on what needs to happen in order for IPFS to become more than a storage network, it’s important to focus on what IPFS is exceptional at and why that matters. IPFS is known for it’s content-addressable nature, something that allows for portability, increased verifiability of content and records, and distributed content delivery. IPFS solves that problem by distributing the sharing of that files across nodes and using the Content Identifier (CID) to ensure immutability and verifiability. If you’re working with static, immutable websites, IPFS is actually a great fit and we’ve done several tutorials on how to host static sites on IPFS which you can check out here.

Pinata stands behind the value of IPFS and has worked hard to make it accessible, easy to use, and reliable for developers building Web3 applications. Whether you’re building a decentralized website, a blockchain game or a decentralized social media, we’re here to help you every step of the way.  Sign up for a free account today and experience the power and speed of IPFS in your workflow!

Happy Pinning ✌️

‍