Fleek Network Developer Guide Part 2: Services

Welcome back to the Fleek Network Developer Guide series. Building on the Fleek 101 foundation laid in Part 1, in Part 2 we will look at the main developer-facing layer of Fleek Network - Services.

A Service is a modular piece of edge-enabled software that runs on (and utilizes the features of) Fleek Network. These services could be considered the user/developer interface of the network.

In this guide, we will explain what services are, how they work, and walk through a few examples of how to use them in your tech stack either as standalone web services (ex. Edge Functions, CDN, etc.), or combined to power a wide spectrum of use cases (ex. hosting Next.js apps, running AVS’, Provers, etc.).

Let's jump in.

What is a Fleek Network Service?

Services are composable, auto-scalable, permissionless pieces of software that come in the form of lightning-fast, edge-optimized versions of various web services most developers probably use or recognize today. This includes services like CDNs, Serverless and Edge Functions, VM’s, etc.

Services in Fleek Network are comparable to the services provided in AWS such as Lambda, S3, or EC2. Similar to how most software and applications today are essentially just different combos and usage of the underlying services provided by cloud platforms, the same mental model can be used for Fleek and the services available on the platform.

Services can be used as stand-alone web services, or combined to power a wide spectrum of use cases from hosting Next.js apps to running nodes, AVS’, Provers and more.

How Do I Use Fleek Network Services?

Using Fleek Network Services is pretty much the same developer experience as using AWS or any other cloud platform. For example, each Service comes with its own interface and SDK that can be used to interact with the functionality of that Service from any client.

Access to Fleek Network for clients is securely managed through a variety of network transports -  HTTPS, WebTransport, WebRTC, Custom TCP, and much more, acting as the entry point for external client communication with nodes and services.

The handshake component is an important element to explain here because it listens for connection requests over a secure transport layer, facilitating the exchange of public keys and negotiating access for the session. Clients are free to terminate the connection at any point or connect to multiple services at the same time while maintaining the connection. They could also have multiple different connections to the same session.

Fleek Network SDK

The Fleek Network SDK (Software Development Kit) is what developers use to facilitate seamless development of client apps leveraging Fleek Network Services.

Apps leveraging Fleek Network Services can run a plethora of logic and services within the app itself. This is in line with most modern client-facing apps where robust software development kits live inside and power the functionalities of the app.

The SDK automatically connects client-facing apps with Fleek’s network of edge-optimized nodes. All nodes can run all Services, which means work can always be routed to the best/closest node (determined by the location of the user making each request). This helps contribute to the high performance and low latency of Fleek Network. The SDK also helps ensure that all client apps auto-scale without any need for DevOps or infrastructure maintenance.

Ideas for Services & Use Cases

Now that we understand how Services work and how to use them, let’s explore some cool use cases that you can build on top of Services.

CDN

CDN (content delivery network) was the first service built on Fleek Network. Given the high-performance demands of the modern web, if you were to build a cloud platform from scratch today, you would probably do the same (start with a CDN). The reason being is that almost all other web services can benefit from faster movement of data. In Fleek Network the CDN is exactly that - a core service that can be used as a standalone, but it’s also used and benefits almost every other service and use case built on the network, including all the other examples mentioned below.

What’s unique about Fleek Network’s CDN is Verified Bandwidth - the data is streamed (using blake3 hashing) and cryptographically verified in real-time. It’s essentially an advanced version of the fair data exchange protocol recently proposed by a16z here. The other unique thing is that given Fleek’s robust geo-distributed node network, it will most likely end up having an order of magnitude greater POP location coverage than traditional CDN and Edge Networks, which should result in lower latency in a significant percentage of geographies.

Edge Functions

Fleek Network allows developers to deploy and host runtime environments that support programming languages and serverless and edge functions built in these languages. The core team chose JS edge functions to start because it is the most popular developer language and is easy enough to build with and get started as a developer.

Fleek Network’s core development team built an early POC of this use case - it was made by combining Fleek Network’s CDN Service and Edge Runtime Service (for executing javascript in a serverless environment). The functions were then pinned on IPFS so that Fleek Network could fetch the function based on the hash generated and serve it to any client application that requests the function. After the initial fetch, the function is served directly from Fleek Network’s cache layer (CDN Service) for maximum performance. You can view the impressive performance results here.

Next.js App Hosting

Next.js Applications can be compiled and executed on Fleek Network with a similar blend of JS-based runtime and CDN services on Fleek Network. Almost all the features on NextJS (Edge Functions, SSR, ISR, Image Optimization, etc.) can be powered using this service combination.

Leveraging Fleek Network to power this use case has the following benefits:

• NextJS prebuilds the ISR cache during the build process which can be available across the network. Data delivery is therefore very fast when a client requests the app, especially on Fleek’s edge-optimized network.
• Performant data streaming inside the NextJS application gives the user a smooth experience on the app, thereby increasing retention.
• Fleek Network allows different origins to feed files and data to the network that can in turn be quickly cached and delivered whenever a user requests for it.

We can utilize frameworks like OpenNext that help create a serverless deployment of the entire NextJS application and can be executed with a runtime. The modular nature of Fleek Network allows a developer to store the app on any origin (IPFS, S3, Arweave, Filecoin, etc), but with the plug-and-play nature of Fleek Network, the app will be compiled and executed on the decentralized cloud environment and cached on all the nodes to provide quick delivery to the end users of the app.

Virtual Machines

VMs, as a service, provide a very unique execution environment to the applications leveraging Fleek Network in their stack. This is because while Fleek Network itself is VM-less, it can power the logic execution of any VM built on top of Fleek Network.

Usually, VMs bind the developer using them to a specific flow and restrict the use cases to some extent– we have seen this happen with EVM itself which can only support smart contracts as logical computational units on-chain. But with Fleek Network, you get a modular environment to build custom logic inside your VM for your use case and leverage the scalability and performance capabilities of Fleek Network to avoid execution stack bottlenecks and keep your apps (communicating with that VM) seamless.

Nodes, Rollups, & AVS’

In the same way, EigenLayer allows projects to rent economic security, Fleek Network essentially allows projects to rent geo-aware, edge-optimized node infrastructure. The two projects are very synergistic, as renting economic security alone does not meaningfully reduce the technical burden of building a decentralized network but leveraging Fleek Network in conjunction with EigenLayer certainly would.

An EigenLayer AVS (Actively Validated Service) can leverage Fleek Network for its infrastructure needs. Fleek can facilitate this by actively running the AVS logic on the edge network and validating transaction state via EigenLayer. This allows AVS developers to avoid needing to build their entire own decentralized network (including node software, networking, p2p, etc.), and avoid needing to pay for the entire security and usage of their own proprietary node network. The result is they get all the same benefits of a normal AVS, but now they can get to market much faster, price their services cheaper, save a ton of time on DevOps/infra/scaling, and inherit all the performance optimizations of Fleek Network by default, leading to better overall products and user experiences for the AVS’ customers. Best of all the AVS would now no longer need to rely on cloud platforms like AWS; the AVS would be running entirely on performant, lower cost, decentralized infrastructure.

This same value prop applies not just to AVS’, but to a lot of the popular blockchain scaling solutions. For example, a lot of the infrastructure required to run rollups (ex. Provers, Sequencers, Nodes, etc.) could also realize cost, performance, time-saving, and decentralization benefits by running on Fleek Network rather than AWS (where the majority of this infra currently runs).

That concludes the Fleek Network Developer Guide Part 2! Stay tuned for Part 3 coming next week, where we will dive deeper into specific use cases and exactly how they are built and used

If you missed it, check out Part 1 of the Developer Guide where we explored the basics of Fleek Network: what it is, a look at the stack, and a comparison to centralized alternatives.

Follow along here on X for the latest on Fleek Network’s rollout ⚡

-Fleek Foundation