People have strong feelings about Web3. There's debate over if Web3 is the future, a fad, a buzzword, a myth, meaningless marketing malarkey, or maybe even a scam. Yikes.
In this post, we'll try to take some of the heat out of the hot takes and focus on some of the basics of Web 3: what is Web3, the benefits of Web3, and the issues it currently faces. We'll cover what you need to know about Web3 from a frontend developer's perspective and offer some insights around improving Web3 UX.
Web3 (Web 3.0 if you're feeling fancy) is the term used to describe the supposed third iteration of the world wide web — one with a greater focus on decentralization and the removal of centralized oversight and control.
For many Web3 proponents, the vision is a more transparent and permissionless internet. To accomplish this, Web3 incorporates technologies like blockchains and cryptocurrencies.
So if that’s Web3, what about the first and second version of the web?
Web 1.0 (or Web1) was the first decade or so of the internet gaining popularity, from the early '90s up to the mid 2000s. In this era, there were personal pages (R.I.P., GeoCities) but the majority of people were firing up the ol' 56k dial-up modem to (slowly) peruse static pages with frames and tables.
Web 2.0 (or Web2) is considered the dawn of a more participatory, social internet — or the concept of the web as a platform. We're talking all things user-created: from Wikipedia and YouTube to community forums, MySpace, LiveJournal, Twitter, and Instagram. Web2 is typically considered the time from 2004 up through today.
Those who are passionate about the idea of Web3 maintain that it presents some potential solutions to many of the perceived issues with Web 2.0 (e.g., centralized control by a few "big tech" companies, surveillance of user activity, users generating content but not getting to share in the benefit of its monetization).
The creation of a more transparent and permissionless internet is happening right now, with thousands of developers working on Web3 every day. And champions of Web3 say that this model gives users more sovereignty over their data.
But while some areas of Web3 are showing promise, others are still lagging behind. Let's look at some of the benefits of Web3 — and the challenges it currently faces.
While still in its infancy,[** permissionless decentralization**](https://konghq.com/blog/web3-basics-what-is-decentralization)** permissionless decentralization** is a way to decouple infrastructure from applications. Everyone can add a node to a network, increasing its performance and reliability. In addition, the consensus algorithms of blockchain networks ensure that everything works correctly and is [difficult to attack](https://www.investopedia.com/terms/1/51-attack.asp)difficult to attack.
Application developers can then build upon this infrastructure without setting up subscriptions like the ones traditional SaaS businesses require. Every side of the equation can essentially do what its developers want, as long as they follow the global rules enforced by the network.
Web3 also introduces a native payment layer — potentially bringing an end to the need to build a system and then add third-party payment providers.
*Figure 1: Web3 enables trustless P2P interaction without a third party*
With decentralized payments via cryptocurrencies, money flows effortlessly throughout the network. A system with financial transactions at its foundation is a potential game-changer, Web3 fans say. Every transaction on a blockchain is accounted for and transparent. Those who champion Web3 point to this as an end to potentially shady business tactics of reselling data you left while using seemingly free services.
And finally, on a blockchain network, every interaction is signed by default. All data sent on the network can be traced back to an address, and all this data is publicly available. In short (and in theory at least) nobody can hide their deals behind closed doors.
But as the saying in Web3 circles goes: "We're still early."
With each innovation, Web3 proponents feel we get closer to the dream and Web3. And as technology like NFTs grab mainstream media attention, Web3 gains more recognition.
However, it's still difficult for the average, non-technical user to participate. Mass adoption won't happen until the user experience is close to what people experience when they use Web2. Even many Web3 fans will admit that we aren't there yet and that hybrid Web3 approaches are necessary to ease the onboarding flow and bring in new users.
We'll take a deeper dive into the challenges of Web3 below. But first, let's talk a bit about Web3 from a frontend developer's perspective.
As a frontend developer, when you check out Web3 for the first time, you'll probably become overwhelmed.
Not only are there new foundational concepts to understand— blockchains, smart contracts, IPFS, and more — but an entirely new ecosystem and toolset. And since this technology is so new, there isn't always a clearly defined starting point.
The good news is that much of your *frontend *work in Web3 remains the same as it was in Web2. JavaScript, HTTP, request/response — these are still the foundations of client-side development in Web3. However, there are some core differences you’ll need to learn, and a new set of concepts you'll need to understand.
Let's look at four key questions frontend developers new to Web3 may have:
First, let's look at some of the core concepts of Web3: blockchains and smart contracts. We'll also define decentralization and permissionless.
As a frontend dev, you most likely won't need to *implement *these concepts, but blockchains and smart contracts are where your data lives and where your computing is done. They are the servers, databases, events, and microservices of Web3 that your frontend will connect to.
So let's dive into a little detail to understand exactly how they work behind the scenes.
**Blockchains **use public key cryptography and consensus algorithms to enable trustless interaction for users. Transactions and other data are stored in blocks on a decentralized digital ledger. Each block is cryptographically linked to form a chain of information which can be easily verified by anyone. In most cases, anyone can spin up their own blockchain node to participate in the network if they have the required hardware.
**Smart contracts **introduce a programmable layer on top of this technology. These arbitrary blocks of code live on top of blockchains and only execute under the specified conditions. Smart contracts facilitate more complex interaction with a blockchain network aside from just storing and transferring value, such as digital ownership (NFTs), decentralized finance (DeFi), and on-chain governance (DAOs).
Together, blockchains and smart contracts act as a new form of backend infrastructure for Web3.
**Decentralization **is a way of distributing a system over multiple servers, with the primary goal of improving reliability and performance.
Like in traditional infrastructure, you deploy multiple instances of the same service to make it more performant and ensure that the system stays up when one of these instances goes offline.
In Web3, these servers are nodes in a blockchain network, all providing the same exact functionality (mining new blocks), all holding a complete copy of the blockchain's data, and all running thanks to a wide variety of independent people and companies. So if one or more of these nodes goes offline, the network still survives through independently owned, fully functional copies.
*Figure 2: Blockchain network*
This decentralized distribution protects against single points of failure, such as a government forcing a company to take down all domestic nodes — as [has been done in the past with Bitcoin](https://www.altcoinbuzz.io/regulations/a-timeline-of-china-and-bitcoin-and-chinas-attitude/)has been done in the past with Bitcoin. This resulted in Bitcoin having fewer nodes than before the ban. But because Bitcoin is decentralized, the nodes in other countries kept the network running.
**Permissionless **is a way of building publicly accessible systems. No one is in charge of the network, and anyone can participate. This removes the need for a central authority that manages access control and makes decentralization easier to implement because anyone can join the network.
However, while anyone can join a permissionless network, not everyone can do whatever they want. They have to adhere to some rules enforced in a decentralized manner by all network participants.
For example, permissionless blockchain networks — like Bitcoin and Ethereum — operate with consensus algorithms, like **proof of work** or **proof of stake**. Using these consensus algorithms, each node on the network can verify that other nodes work correctly. If an adversarial node tries to hack or change the network by providing false data, the network as a whole can vote to ban that malicious node from the network.
As explained above, the blockchain networks themselves are decentralized. They consist of multiple servers, called nodes, that run the blockchain software and hold all the blockchain data.
These nodes are how you connect your frontend to the Web3 backend.
Nodes usually only communicate with each other, so in order to access their data from the outside, we need HTTP gateways. These gateways translate the nodes' network protocols to HTTP so that we can use Web3 from a web frontend or a mobile app.
While HTTP gateway deployments operate in a decentralized fashion, they're usually controlled and maintained by centralized companies. Some gateways are permissionless (you can use them without an API key), but many require monthly subscription fees and access keys.
These additional costs can equate to a better dev experience with faster connections and scaling infrastructure. For example, [Infura](https://infura.io/)Infura is an Infrastructure-as-a-Service that provides a node connection through RPC URL endpoints. Their connections are much faster and more reliable than [publicly available RPC URLs](https://ethereumnodes.com/)publicly available RPC URLs.
Regardless of which service you use, you would connect your frontend to a blockchain through these HTTP gateways and interact with it through libraries such as [Web3.js](https://web3js.readthedocs.io/en/v1.7.0/index.html)Web3.js or [ethers.js](https://docs.ethers.io/ethers.js/v3.0/html/)ethers.js.
Of course, when first connecting to a backend, one of the first and most important steps is authentication and authorization.
In Web2 infrastructure, a signup and login procedure is the traditional method. You give your email address to a company, and they give you an API key linked to your identity. As you can see in figure 3, the service owner holds your account.
*Figure 3: Centralized identity*
In a permissionless system, **there's no central entity to hold your data, **so this traditional method can't work. Instead, public-key cryptography maintains identity.
Users sign all data sent to the network with their private key, and the network can use their public key to verify that it's genuinely that user.
In figure 4, you can see that cryptographic keys form the core of the identity mechanism and are held by the user. The user's **crypto wallet** manages the user's keys.
*Figure 4: Decentralized identity*
In Web3, a user connects to a decentralized application (aka DApp, dapp, or dApp — because sensical capitalization rules are *so* Web 2.0) using their crypto wallet. Any interaction afterward uses public-key cryptography based on the user's wallet address to verify they have access to perform certain actions. Meanwhile, each transaction is logged in the public digital ledger of the blockchain.
In more hybrid solutions, the user may sign a message with their crypto wallet to verify their identity with the application, rather than use a typical login system. The message is sent to the backend, which authenticates the user's access to the application through more traditional means, such as a JWT token.
The benefit of using a crypto wallet in both these cases is that it is nearly impossible to impersonate someone. Only the person who holds the keys to that wallet is capable of acting on that account's behalf.
The downside is that if you lose your private key, you can't ask someone to get it back. ([It happens.](https://www.businessinsider.com/james-howells-threw-away-bitcoin-dump-masterplan-get-back-2022-7)It happens.) And password resets aren’t possible: your private key is the *only* method of access.
They don't. Well, at least not in principle.
You access Web3 networks, which are the crucial part of Web3 backends, via HTTP gateways that behave just like regular HTTP servers. You deploy your frontend somewhere, open it in the browser, and it can connect to an HTTP gateway that in turn connects to a blockchain network.
The difference here is that your users need a crypto wallet browser extension. This wallet manages their private and public keys. Your frontend can use them to sign data it sends to the HTTP gateways.
While it's possible to interact with the low-level APIs directly, it can get quite cumbersome.
Web3 libraries, such as [Web3.js](https://web3js.readthedocs.io/en/v1.3.0/web3.html)Web3.js or [ethers.js](https://docs.ethers.io/ethers.js/v3.0/html/)ethers.js, abstract the interaction with the gateways and the wallet extension. First, they would connect to an RPC node through a service such as [Infura](https://infura.io/)Infura or [Alchemy](https://www.alchemy.com/)Alchemy. Then, they communicate with the blockchain and call smart contract functions using [JSON-RPC methods](https://moralis.io/remote-procedure-calls-what-is-json-rpc/)JSON-RPC methods.
Now that we've explained some of the concepts of Web3, how can you get started actually building? What do you have to learn in order to display, send, and receive data?
This is the nice part: you build Web3 frontends with standard web technology you already know such as HTML, CSS, and JavaScript. So you can reuse almost all of the frontend knowledge you already have.
Client-side rendering is the most popular method of parsing data in Web3. So, SPA frameworks like Next, Nuxt, or Svelte are still applicable. They do all their UI computations on the client side, so that the hosting service can be a simple static webserver.
Deploying static files means you can use the centralized services you already know to deploy a frontend. Still, you can also use decentralized static hosting services like [IPFS](https://ipfs.io/)IPFS, [Skynet](https://skynetlabs.com/)Skynet, and [Arweave](https://www.arweave.org/)Arweave. Since the space is so new, there currently is no Web3-native standard for hosting frontends.
Every new system starts at the foundation. Today's Web3 devs spend most of their energy ensuring that underlying protocols and infrastructure are working as intended.
But this leads us to Web3's current problem: **the networks are functional, but the user experience is lacking. **
For a user to interact with Web3 applications, they must use a crypto wallet. Most people hardly understand cryptocurrency, never mind the concept of private keys or mnemonic phrases. So how can we expect to onboard millions of new users to Web3 when people are used to the simplicity of Web2?
Depending on your target audience, your potential customers may not have a crypto wallet — let alone know what a wallet is. In these early days, your DApp (decentralized application) — might be the first time that a customer interacts with Web3.
Consider this scenario: you sell someone your idea, and they're about to convert to a paying customer. They click a sign-up link but see a wallet extension is required. They're confused, as the only type of wallet they are familiar with is the one in their pocket. This confusion turns into frustration, and the user gives up, abandoning your onboarding process. You just lost a paying customer.
This scenario might sound funny from a developer’s point of view, but it's happening today.
The average person likely doesn't care about decentralization or trustless, peer-to-peer interaction, so joining that type of network will not be the reason they download a wallet. Instead, users will download a wallet because you, or another DApp creator, will give them something they can't get otherwise — some service or asset that's directly valuable to them.
This problem requires you to do at least one of two things: either pour money into education to make sure your customers get up to speed with Web3 tech as quickly as possible or build your app in a hybrid way with Web2 and Web3 technology.
With a hybrid approach, customers can get some of the benefits your app offers without sitting down for an afternoon to learn about wallet security.
There are a couple of options for users to access blockchain networks.
First, you can permissionless-ly spin up a node and do all of your network interactions through your own personal connection point. Unfortunately, it's expensive, technical, and time-consuming to host your own node as part of a blockchain network. This barrier leads a user to connect to a blockchain network with either a free public gateway, or pay a gateway provider.
Free public gateways are just publicly accessible nodes that anyone can connect to, while paid gateways are node provider services such as[ Infura](https://infura.io/) Infura,[ Alchemy](https://www.alchemy.com/) Alchemy, or[ QuickNode](https://www.quicknode.com/) QuickNode.
If you go for the first (and obviously cheaper) option, you might quickly learn that many people use these public gateways, and they can become very slow. High latency is one of the main reasons customers leave an application. If your users have to wait for too long, they’ll go somewhere else. On the other hand, traditional Web2 applications run on centralized systems, which allows them to take advantage of optimizations that aren't possible in Web3.
A hybrid Web3 approach can help reduce latency, at least in some cases.
Web3 is still in its early stages. Because Web3 developers are so focused on the technology's core functionalities, its user experience is extremely lacking. Potential users may be put off by the steep learning curve and clunkiness compared to the Web2 applications they are familiar with.
But if you provide benefits your users can't get in Web2, and your UX is so good that they want to use your app, they will have to get a wallet to convert to paying customers.
Since your DApp may be a user's first interaction with Web3, you need to ensure their experience is as smooth as possible.
The similarities between Web2 and Web3 allow you to leverage Kong tools to improve the UX of some parts of your application.
While Kong can't help you build compelling frontends, it does offer the tools to improve communication between the backend and frontend. With [Kong Gateway](https://konghq.com/products/api-gateway-platform)Kong Gateway, you can get your latencies on par with traditional Web2 applications, and [Kong Mesh](https://konghq.com/products/service-mesh-platform)Kong Mesh assures that you're always up to date on the events of your system.
There's still a long way to go before we reach any kind of mass adoption of Web3, but with hybrid Web3 solutions, we can get there sooner.
Whatever you think of Web3, the idea of a more open, composable internet with decentralized and permissionless networks is one that many find appealing.
You can participate without asking anyone, and nothing can prevent you from building your Web3 app and hosting it on decentralized infrastructure. This also means that frontend developers can build alternative frontends for existing smart contracts without asking their creators for permission. Additionally, every interaction is cryptographically signed by default; the entire network knows who created something or edited it.
For those who do want to get involved in Web3, frontend developers can use most of the skills they already possess: HTML, JavaScript, CSS, and HTTP APIs are all technologies still heavily used in Web3.
But Web3 also has downsides, especially if we look at user experience (e.g., users and developers have to keep track of their keys themselves, and no password resets are possible).
Only time will tell if Web3 lives up to its promise (or if it's just more like Web 2.5). But the idea of Web3 is one that many developers feel passionate about. And, with a minimal amount of learning, traditional web developers can work toward building the applications of tomorrow today.
*Looking to go beyond the basics and build better, faster, and more securely? See *[*why Kong is king for modernization*](https://konghq.com/company/why-kong)*why Kong is king for modernization**.*
Multi-agent workflows live and die on context. Every agent-to-agent call and every agent-to-tool call is either a retrieval — fetching information the agent needs — or a mutation — changing state that downstream agents will depend on. At prototype s
Multi-agent systems are, at their core, context distribution systems. Every agent in your workflow is a consumer and producer of context. The interesting architectural questions are all about how that context moves. Two operations drive everything:
As AI adoption scales, applications evolve into complex systems of agents, orchestration layers, and context servers. Infrastructure lags behind — struggling with authentication, cost control, and data security across a provider list that change
You wouldn't expose a REST API without a gateway. What about Kafka? Before we talk about an event gateway, it's worth grounding ourselves on what an event is. An event is simply a record of something that happened. In modern integration, there are
What it is The Konnect Dev Portal Toolkit is a free extension published by Kong Inc. on the Visual Studio Code Marketplace (ID konghq.vscode-konnect-dev-portal-toolkit) and on Open VSX. Konnect Developer Portals are how teams publish API document
To follow along, you’ll need: Insomnia 13 or later An Insomnia project with an API design document An OpenAPI 3.x specification Note: In Insomnia 13, custom linting supports Spectral rulesets using the top-level rules and extends properties. Custom
The MSK exposure problem Amazon MSK brokers live in private subnets by default. That's the right default. Kafka's protocol wasn't designed for untrusted networks — it has no concept of rate limiting, no built-in field-level encryption, and its ACL
