This is our first post here in dev.to as an organization, make sure to give us some love!
TLDR;
- We are releasing a new version of Bulldozer.
- It comes with a new UI that matches our brand.
- We're exploring web2 tech for better Dapp UX.
- It introduces collaborators and real-time updates for all clients.
- We added workspace treasury to pay for the rent of all accounts inside a workspace.
- We're working on a GitHub integration that enables Bounties.
- Bulldozer CLI and API are on the way to boosting local development.
Looking for a thread-like post instead? We got you fam.
Heavy Duty Builders@heavydutybuild
Hey fam, how’s that building going? We’re more than excited to show the new Bulldozer to y’all! We got a new creative member on the team that gave us a whole new spin on the UI.
Check this out 👀
youtube.com/watch?v=vK8nYC…21:30 PM - 25 Apr 2022
Intro
If you've been following our moves, you know what's up with Bulldozer, but let's make a quick stop to remind us about it.
Bulldozer is a low code platform to build Solana programs powered by Anchor. Our goal is to make it possible for "no-code" contracts to actually land. While making the experience fun and almost game-ish, with a bit of real-time collaboration to make things 🔥.
Back in 2021, we won 2nd place for Solana's IGNITION Hackathon and since then, we quit our 9-5 and went nose-diving into web3.
Our initial version was basically a prototype, which we have been constantly tweaking and improving, looking for a specific UX.
Take a look at our latest promotional video and make sure to like it!
Real-time collaboration
For us, real-time collaboration is a huge thing. We started using the RPC's socket events which in localhost worked fine, but we kept hearing from more seasoned Solana developers to not trust those events.
Guess what? As soon as we started testing in devnet, all kinds of weird shit started to pop up. Some events were not coming through, we didn't know why, so we decided to take a step back and follow what Jordan told us in Prague's HH.
Dude you should go web2 on it.
This was hands down the best thing we could've done, we didn't go full-on web2 tho, we just created what we called the Broadcaster, a topic-based WebSocket Server that enables clients to propagate their transactions to other clients.
It works like a charm, but when we were talking to Jordan back then he said:
How would you show each "collaborator" cursor in real-time?
You can imagine our faces after hearing that. 5 minutes before we weren't even considering showing the cursors in real-time. Even though we felt the Broadcaster was a valid solution, since then we knew that we'll need more power to get to a Figma-level of collaboration.
The Broadcaster kept clients synchronized. But we had an issue, you could only interact with your own workspaces. This brings up the next new feature.
Collaborators
We know that building software is all about joining forces with other builders. Being able to collaborate with others makes the job easier and more enjoyable. This is how Bulldozer does it:
- Workspace owners can add builders as collaborators.
- Workspace owners can approve and reject collaborators.
- Builders can request the collaborator status.
For now, there's generic workspace-wide write permission. Our goal for a future release is to have fine-grained permissions and roles, enabling more intricate and complex development processes.
This leads us to a new concern. If there are multiple collaborators working together and each of them pays rent for the accounts they create, we have to either:
- Prevent collaborators from closing accounts and getting back their rent.
- or; Allow collaborators to close accounts that could potentially break a workspace.
Since both options sucked so bad, we went back to the whiteboard to discuss a better alternative.
Workspace Budget
What if there was a way for the workspace to pay for the rent?
Follow us here, each workspace has a "budget" at a PDA, anyone can donate to a workspace's budget and we'll later use that budget to pay for rent. On paper it sounded really nice, it turns out it wasn't that straightforward to implement, at the moment Anchor doesn't support PDA payers.
Our current solution is basically hammer-fisted:
- The collaborator pays for the rent.
- Budget charges back collaborator for expenses.
- The workspace owner can withdraw from the budget.
- Closed accounts rent goes back to the budget.
We know we have a solid solution here, but can you imagine paying the rent with any token that you want? We do. Right now we're limited to using only SOL for the rent, but we're thinking of something more versatile. Something that allows the workspace budget to accept multiple tokens while Bulldozer makes a user-transparent swap transaction at the moment of paying rent.
What's next?
If you know us, you already know it, we are just getting started. Right now we're cooking some really good shit. Our website is getting re-done, we just started sending a newsletter, and we're already working on a new set of features.
Github Integration
In order to decentralize the way software development works, we need to have a good incentives program. This could potentially lead a huge number of developers to transition toward a new way of working.
That's why our current focus is to set up a bounty program that's baked into Bulldozer, but at the same time has a high level of compatibility with GitHub. This way our bounty program will be available not just for Bulldozer but for other projects.
The GitHub Integration is halfway there, we have a potential name for it already: "Drill".
Bulldozer CLI
Bulldozer right now has a major ergonomy issue when it comes to local development, every time you change something on your program, you have to re-download and manually replace the things that changed.
Our focus with Bulldozer CLI is to give builders the basic tools they need for an improved local development experience:
- Build a workspace
- Deploy a workspace
Bulldozer API
When we started with Bulldozer we had decentralization as a top priority, as time passes we realized that some parts can be centralized in-order to boost UX. In the current state, Bulldozer generates the workspace files on the client without an external API.
While this works, we can't "build" the workspace. Clients have to download, manually compile, and only then they can deploy. We want to change this by introducing an API that returns:
- Source files for a workspace
- Compiled output for a workspace
NOTE: All these API functionalities are coming from the CLI but we need an interface that we can interact with through the web client.
Don't take our word for it, check it out yourself! It's OSS.
heavy-duty
/
platform
Monorepository of Heavy Duty Builders.
Bulldozer 
Bulldozer is a low code platform that uses abstractions that are common for developers to build Solana programs, it’s powered by Anchor Framework. It gives developers the ability to manage their program’s ecosystem through a UI, hiding all the gory details so they can focus on the business logic.
It consists of an Anchor workspace and an Angular application, the Anchor workspace holds the content of the Bulldozer program, it's used as decentralized storage. The reason we store all the data on-chain is that we want to unlock real-time collaboration while building systems.
Running Locally
Bulldozer has only been tested in localhost, if you want to give it a test drive, make sure to have a local validator running using solana-test-validator.
In order to run Bulldozer in your local environment, you'll need to make sure you have installed globally these dependencies:
- @project-serum/anchor
- mocha
- ts-mocha
- typescript
- npm
- node
Clone…
If you get this far, join our Discord. There's so much more where this came from.
Heavy Duty
Check out the Heavy Duty community on Discord - hang out with 47 other members and enjoy free voice and text chat.
discord.com
Follow us on Twitter to stay up to date.
Top comments (4)
when you say about the problems of the events you mean to the ones you can use on Anchor/Solana? I've read a little/nothing about that, so for the moment is preferable to not use that right? do you think it will be useful in the future with more development?
At first we explored using Anchor events and we didn't find enough information, so we decided to try something else.
Our next option was to use the WebSocket client from @solana/web3.js but later found out that it's common for RPCs to miss some events.
At the end we were given the recommendation to use something custom, like our own WebSocket Server and make sure we keep track of what the users are doing.
The WebSocket Server was the only solution that worked reliably. If you want to take a look at the implementation, it's open source in GitHub and feel free to ask any question in our Discord.
Regarding usage of the Anchor events, I think they're probably really useful is just a matter of knowing how they work and their use cases. Although, given how blockchains work, I think it makes sense to have additional services making sure everyone is in sync, rather than sourcing that problem to the blockchain
top notch guys! waiting for more updates :)
Thanks!! Make sure to follow us on Twitter for more updates..