Hosting Decentralized Frontends with dAppling Network

All right, we're live. GM, GM, GM everybody. Welcome to what's going to be another great DevNTell. So if you didn't know, DevNTell is a 30-minute window for builders to showcase something they're passionate about or been working on in Web3. This could be an awesome project you've been working on, demonstrating new and testing best practices, automation goodies, smart contracts, how to structure a project, etc. Basically, if you've got a passion for something, this is your opportunity to share it with the community. And today I'm excited to have Russell from the dAppling Network on to show us how we can host decentralized frontends with dAppling. Welcome, welcome Russell, happy to have you on.

Happy to be on. I appreciate it.

My pleasure, my pleasure. Perhaps before we start into the meat of the presentation, you want to give a brief introduction about yourself to the crowd, how you got into Web3, and a bit about your background?

Sure, yeah sounds good. So for me on my background, I've been a developer for a while. I worked at a couple of large tech companies in the past; I worked as a software engineer at Capital One, I was a staff engineer at Wayfair, and I previously co-founded a startup in the Web2 space called Deep Hire. We were working on one-way video interviews for candidates so they could essentially upload a video resume when applying for a job. I got into the crypto space about two years ago or so, essentially read through the Ethereum whitepaper and saw the value of smart contracts and what you could build with them, which was really exciting. I essentially immediately became obsessed and spent all my free time learning as much as I could in the space, learning the dev stack, how to build things, and creating things in the Web3 space. For the last year and a half or so, I was working at Arbor Finance, which was a DeFi app that allowed DAOs and on-chain entities to raise debt-based financing. We had a couple successful issuances there—one with Ribbon Finance where they raised 3 million USDC, and also with Ichi and ShapeShift. Then about three months ago, I started working on dAppling, which is a tool for hosting decentralized frontends in a really simple way with good performance. I'll dive into that a bit more shortly, but that's the high-level about me. Oh, and last thing, dAppling team—we are currently a team of four: me and my co-founder Kyle, and then we also have Grace and Danny, who are both founding engineers helping us to build this product.

Wow, that's quite the distinguished background and yeah, really happy and excited to have you on to share all the goodies you have with dAppling. So I guess what can viewers expect from watching your content today? What can they leave with?

Good question. So starting out, I want to give a quick overview of kind of like what we're building and why, and then do a demo of the platform. Basically, show if you have a frontend on GitHub now hosted on Vercel, Netlify, or your own stack, how you can go through and deploy that on IPFS in about two or three minutes with dAppling. I want to do a quick overview of that, and then after that, I would love to dive more into the technical side on how things actually work. If there's any specific sections there that the audience is interested in, I would love to keep it audience-driven on what pieces we walk into. Let me actually share in the chat—I'll send this, let me know a number if you can see this. Oh no, I lost my formatting when I pasted in the chat. So there's one, two, three, four there; would love if there's any of these in particular that you would like me to prioritize when I'm walking through the more technical side on how any of these pieces work. But if there's any questions during the presentation as well, please send them in the chat; would be more than happy to answer and elaborate on anything there.

Awesome. Yeah, it looks like we're in store for a jam-packed session. Let's get right into it.

Nice, yeah sounds good. So kicking it off, we're building dAppling. Essentially, what dAppling is is a developer tool targeted at Web3 developers and makes it extremely easy to host your frontend site on decentralized infrastructure. We're prioritizing a couple different things. Number one is developer experience and making it extremely easy to actually deploy on decentralized infrastructure. Then we're focused on the performance and security side as well. Out of the box, how can this be as performant as possible for your users? And then also on the security side, how can you prevent common Web3 security attacks like DNS hijacking or phishing attacks and how can you help to prevent those? So that's essentially at a high level what we're building and what we're focusing on. I think next steps I'll just jump through, I'll show you an example of what it actually looks like to deploy a site and then I can elaborate some more on some of the other features.

All right, so I guess starting out, first step is just connecting your GitHub account, which I have done already here. Step two is clicking new project. Then from here, you just can select whichever project you would like to deploy. I'm going to choose this one, 'no-more-acronyms'. After you choose this, we do some automatic framework detection. So we look at whatever your frontend site is using and we're able to tell if it's using like Next.js, Create React App, Vite, etc., and we'll auto-detect this. But if you have custom build commands here for actually building your project, you can fill this out as well. But most of the time you can get to this page, kind of ignore everything here unless you have a custom config, and then click next.

And then here on this part, we just do some checks to see if there would be any issues for actually deploying your site to IPFS. Because with Create React App, for example, there's a change you need to make to your package.json file for it to actually deploy to IPFS, and we'll give a warning here if we detect anything that will stop it from being able to be deployed on IPFS well. All right, cool. So click deploy. Now this kicked off our job on our side to actually build the site and we'll be deploying it on IPFS in the background. I can show you this when it completes in a couple of minutes, but just for saving time, I can jump straight into one that has already completed that I built already.

So here's our blog—like a fork of our blog site. Here you can see the GitHub repo for this. I went through the same flow for this that I just showed you, but you can see here this site has already deployed. When this deploys, you get a unique production URL for the site. So anytime you update the site, you merge back into main, then this URL will update with the newest version of your site. You also have the ability here to add your own custom domain. So you can set up whatever you want here, then point your DNS records at us, and you can bring your own domain name. And just yesterday, we added ENS support as well.

You can see here for this project, I actually connected my ENS name 'bookland.eth'. So if I open this up, this is pointing at this blog site that I deployed here with dAppling. This gets automatically updated in the same way; any merges into main on this repo will update the content that is on bookland.eth.limo. In a bit, I'd be happy to dive more into like how that actually works on the technical level. But yeah, before I get to that, what else is there? Here on the deployments, we have something called preview builds. Here on the test dAppling blog site, I made a change earlier today, but if I actually make a PR for this change, it will kick off a process here where we look at each of these commits on a PR and we create a preview deployment URL for each of these commits. This makes it really easy if you're working on a team on your project, you make some frontend changes, we create a URL that whoever's reviewing your PR can just click on and they can see what the site would actually look like after those changes.

If I go back here and I look at the currently deployed production build, you can see the IPFS CID for this deployment because we're also deploying everything to IPFS. How this works is for this domain that we have right now, the way that we think about this is it's the centralized deployment of the site. And then we also want to provide additional access points that you can use to access your site, and using the IPFS CID is an example of one of the alternative entry points. You can imagine this is useful where for whatever reason—the reason we have the centralized deployment piece right now is to help ensure speed and resiliency for the users. We've found it's extremely important for most apps for the site to load 100% of the time and really fast for users. But then we wanted a version of the site to also always be available through IPFS if there's issues with the centralized deployment, if there's censorship, etc. Like if there's a time-sensitive operation that people need to make in a DeFi app, then it's a pretty bad situation as a user if you can't access—like if there's an outage of one of the services and you can't access the centralized deployment for whatever reason. So there's always this fallback on another way that you can access the frontend for the apps.

Yeah, so I think that's pretty much it for an overview. Oh, I guess last thing we just added is we added an analytics package. This is a package on GitHub that you're able to just install and wrap your app in, and then we'll also track any page views and unique users that actually visit that site. That happens automatically after installing the package. So cool. If anyone has—I think I'm going to pause here on the demo piece, look at the comments for priority for what to go through next, and happy to dive into kind of the technical details now of how the different pieces are implemented.

Yeah gang, if anybody has questions please post them in the comments and we'll bring them up here. I guess before we get into the technical side of it, is there any particular reason you chose IPFS over some other storage protocol?

Yeah, so we looked into the different storage protocols and IPFS was what we found made the most sense starting out from the performance aspect of loading the content quickly. We are considering adding support for some other storage protocols in the future like Arweave is one example; we're also going to look into what it would look like to integrate with Filecoin. But IPFS seemed like the natural first place to start with, and yeah, that's essentially it at a high level. We covered this in more detail if you actually go to our blog page. There are some issues with like padding and how paths work with IPFS that's different. For example, if you're using Create React App and you're using Page Router, you actually have to use Hash Router instead for the routing to work correctly. And there's some other weird edge cases around that. But the biggest thing—I guess there's two things that we've seen were the most common. Number one was having a specific configuration set in your package.json file if you're creating a Create React App. And for Next.js apps, there's an option called 'trailingSlash' that needs to be set true for the routing to work correctly when you deploy it on IPFS. How we're handling that right now is we actually inject those commands into the package.json file if they're not there. That's to help with the experience where someone wants to deploy their site, it looks like it's deployed successfully, but the routing's broken. That's a pretty bad situation to be in. So we're focused very heavily on how can we make this work out of the box on the first time for someone who's trying to deploy their site.

Awesome. Yeah, great response.

Nice. All right, so I see now there was some prioritization for that list that I sent earlier. It looks like the first one is how ENS/IPNS works. So I'll walk through that. How this works at a high level is for each project that is created, we create an IPNS key for that project. IPNS allows us to point to any IPFS CID. A user comes in here, they click to add their ENS name. Something pops up here, you connect your wallet, and then you click a button to set the CID. This will create a transaction for you on the ENS smart contract to set a specific field on your ENS name. I'll show you what it looks like for mine. If we look at my ENS name 'bookland.eth', you can see here this content hash field; it got set to this IPNS name. And you can see here this matches up with this IPNS key here. Now what happens is if you use a service like 'eth.limo', what their service does is they look at the subdomain, they look at the ENS record for 'bookland.eth', they look at this content hash field, they see that it's an IPNS name, they do a lookup to get the IPFS CID that this IPNS name is pointing at, and then they serve that content at that IPFS CID. The reason that we decided to set an IPNS record here instead of an IPFS record is so we could do gasless updates. Essentially, a user in our platform, you have to pay gas when you set this IPNS record in your ENS name here, but then anytime the site updates, we also update where this IPNS key points to. So here for this production deployment, it was pointing at this CID, but then we did this new production deployment and now it's automatically pointing at this new CID.

That's essentially how it works at a high level. We are using a service called w3name for this, by Web3 Storage, and it helps us with the republishing. There was also another service called dWeb Services and we were considering using this service but decided not to because of how their service works. It would have been easier to integrate with that service, but they have custody over the private keys that are used for updating the IPNS records, and we wanted to have custody of those on our platform to make sure that the IPNS names are always available and could always be updated. So we decided to use the w3name service for the republishing for the IPNS names. We are the only ones that have custody over those private keys and are storing them securely. And in the future maybe we add some additional IPNS infrastructure around it, but w3name works pretty well right now for our use case. I'm also in a process of writing a blog post about this. In about a week there will be an article going more in depth on what we learned about actually adding IPNS here. The IPNS piece was honestly a bit more complex than I expected it to be, but now it's live.

How analytics works is actually pretty simple. If you don't have this set up on an app already, you visit this page, it opens up our docs or the GitHub site that has a quickstart for adding it. Essentially we have this NPM package and as a developer you would just install this NPM package, import this analytics component, and then wrap your app in this analytics component. All this analytics component does is anytime there's a page navigation or a new page view, it makes an API request to our backend server which essentially just logs that request. It logs three things right now: number one, the site that was visited; number two, the where the user came from; and then we also for each analytic event generate just a random UID for that user and use that to track just unique users. But then we're not tracking any additional information about any users or anything, it's just pretty simple there. And then the backend side we just have a database that's keeping track of those analytic events and then from our frontend on the analytics page we're just querying that and showing it in a nice way for the user.

Yeah, we have about three minutes left. One thing that we are lacking that we are very excited to add sometime in the future is support for serverless functions. We're still figuring out how to do this. We want to use decentralized compute in some way like Akash Network or some of the other people working on decentralized compute. That's another thing that we really want to add. I'll pause there and see if there's any final questions.

Yeah, and I guess in terms of how to get started, is there like a pricing tier or is it completely free for folks to sign up at this point?

Right now we do have—it's going to be free for a majority of use cases. Like if you have a hackathon project or a portfolio site then your usage requirements are going to be low and you'll be fine on the 'Grow' plan which is free and will be free forever. Sometime in the future we are going to have this 'Bloom' plan mostly centered around team features. For most use cases free plan will be perfect and will be fine, but then we also have the Bloom plan if you're like working on a DeFi project with a team or are working on something more serious and that piece is paid above a certain traffic level.

And then for the ENS updates, are users expected to pay the gas on their behalf or do you cover those costs?

It costs money to set the IPNS record on the ENS name for the first time, but any updates afterwards are gasless and free. So there's like a one-time cost to basically whatever cost it is to set that content hash field on your ENS record, but after that no more costs.

Beauty. And yeah, that unfortunately brings us to time, but gang, if you have any further questions for Russell I have dropped his Twitter handle in the comments. It should also be in the YouTube description as well as the blog post. Russell just wanted to thank you so much for coming on. I really appreciate you taking the time to come on today and yeah, this looks very promising, basically like a Web3 Vercel is the vibe I got.

Exactly, that's exactly the niche we're trying to fill—a Web3 focused version of Vercel that makes it extremely easy to deploy performant sites.

Love it. Just before everybody leaves today, I want to share the QR code for you to fill out a form to be able to get your hands on the DevNTell NFT for being attendee today. Fill out this form which will be open for one hour. I just want to wish everybody a very happy Friday, happy weekend, and we will see you all here back next week. All the best.