Glow - A Versatile Flow Development DSL in Golang

[robbie-wasabi]

Glow

Grant category

Please select one or more of:

• [ ] Open source maintenance
• [x] Developer tools / services
• [ ] Educational material

Description

Flow development in Golang! A versatile DSL to test your contracts/txns/scripts on Mainnet, Testnet or the embedded emulator.

Problem statement

Bjartek's Overflow (https://github.com/bjartek/overflow) makes building, testing, and deploying smart contracts less intimidating and relatively straightforward; however, its opinionated structure and functional restrictiveness are constraining for developers who are working with multi-project repositories or need high levels of configurability. The Flow Go SDK (https://github.com/onflow/flow-go-sdk) provides more versatility but is quite verbose for developers who are trying to simply develop and test smart contracts. I believe that a third golang alternative, one that supports multiple project scopes and ease of use functions like creating disposable user accounts for testing on Testnet/Mainnet would not only be a welcomed addition to the ecosystem but a necessary one.

Proposed solution

An open source DSL for developing, testing, and deploying smart contracts called: Glow (https://github.com/rrossilli/glow). Please give the repo a quick run-through!

For almost 2 years now I've helped NFT Genius develop, test, and deploy NFT projects to their curated marketplace, Gaia (https://ongaia.com/). During this time, I was also building a passion project in my free time, Glow. This library has helped us build and deploy numerous projects to the Mainnet. With each project, I was able to gain new perspective and hone the library to fit a Cadence developer's needs.

Milestones and funding

Milestone	Deliverables	Timeline	USD Proposal
1 - Update	It has been about 9 months since Glow received much love - and we know a lot has changed. We'll start by getting antiquated with the most recent changes/standards and updating all of the libraries. Since we don't know what we don't know, it is difficult to estimate how long this will take. We'll make sure to update the flow team provided that this takes less time than anticipated. In such a case we can either decrease the budgeted amount or allocate the extra time elsewhere.	~2 weeks	~$4,000
2 - Code Refactoring	We've proven that Glow is lightweight and versatile but it can be better. We'll spend some quality time in the bowels of the codebase to make sure everything is neat and tidy so that the code is readable and inspires contribution. We'll also add some commonly used helper functions that provide useful shorthand for developers, implement a reliable way of specifying a configuration (similar to a hardhat.config.json), and build out a "wrapped client" that allows for method chaining - something highly requested by other flow developers. Furthermore, we'll build build out 100% test coverage of Glow features and implementation examples so that we can maintain confidence in the codebase after each update.	3 Weeks	$6,000
3 - Documentation/Tutorials	A good library is nothing without clear and thorough documentation. We will spend a good chunk of time writing thorough docs with plenty of examples.	1 week	$2,000
4 - Social Media Promotion	Sharing more information via social media posts: tutorials, medium articles, flow forum, etc... to bring more attention to Glow	1 week	$1,000

Team

Name	Role	Relevant Background	Contact
Robert Rossilli	Lead Developer	Cadence developer for NFT Genius, wrote contracts for NFL All Day and numerous NFT projects for Gaia. (https://ongaia.com/, https://nflallday.com)	rob@talostec.io

Final Thoughts

Glow was my passion project for months but I had to stop working on it when I was pulled in a different direction. I want to maintain it but am left with little time to do so these days. Any financial support would allow me to continue development and maintenance of the codebase. I want nothing more than to get Glow in the hands of some salacious Flowsters like myself and inspire further development through open source collaboration!

[franklywatson]

HI @rrossilli - we took a look at the proposal and we think it looks good. We would like to suggest that you add another milestone (4) where you spend time promoting and sharing this on social media, through blog articles etc so that we can make sure there's a focus and attention being brought to this. Could you update this with the suggested change?

[robbie-wasabi]

That's a great idea! Let me know if there are any other changes you'd like me to make

[robbie-wasabi]

@franklywatson any update on this?

[franklywatson]

Hi @rrossilli we'll be sending out a grant letter for this later this week. Thanks

[robbie-wasabi]

@franklywatson perfect, thanks!

[franklywatson]

From discussing this a bit we would more specifically like understand the rough task breakdown for milestones 1 & 2. Would be most helpful to see them articulated as issues in the Glow repo. Is that something you can provide?

[robbie-wasabi]

@franklywatson knocking those out now, please take a look here: https://github.com/users/rrossilli/projects/1

[robbie-wasabi]

@franklywatson I also updated the first 2 milestones to be a bit more descriptive

[robbie-wasabi]

@franklywatson milestone 1 is complete.

merged PR: https://github.com/rrossilli/glow/commit/fb1e5a4461560c34de24c0162b95e7c624e2ebcc

issue #15, #20: https://github.com/users/rrossilli/projects/1

[franklywatson]

Thanks, have reviewed and marked the milestone as accepted

[robbie-wasabi]

@franklywatson just checking in, any idea when I'll be contacted about this?

[franklywatson]

@rrossilli are you asking when the milestone will be paid? It will be this Friday

[robbie-wasabi]

@franklywatson great! appreciate the update

[bjartek]

Can you elaborate on this please?

its opinionated structure and functional restrictiveness are constraining for developers who are working with multi-project repositories or need high levels of configurability.

[robbie-wasabi]

Can you elaborate on this please?

its opinionated structure and functional restrictiveness are constraining for developers who are working with multi-project repositories or need high levels of configurability.

Howdy sir! Nice to meet ya - big fan. So it looks like I may have been mistaken here, that assertion was most likely based upon my experience with your library when I used it last (quite a while ago). I'm assuming that the ScriptBasePath/TransactionBasePath constructor args - among other notable changes - would allow overflow developers to organize multiple project scopes into a single monorepo. Is that assumption correct?

Edit: For example, if I had a monorepo with several "projects" (a set of contracts, transactions and scripts for a particular initiative) and those projects had defined golang functions that referenced cadence scripts/txns. I would be able to call those functions from elsewhere - other than the project in which the function was defined - correct?

[bjartek]

Hey, thank you for your kind words.

I think you should be able to do what you are asking but I am not sure. You could always make multiple overflow clients with different base paths for the different parts of your mono repo. It is also totally possible to override the base path for a single interaction (script/transaction)i belive, if not that builder option is really easy to add.

[bjartek]

You could also use go:emed and just embed all your scripts/transactions/flow.json from the library and use it in the other places. See here for a naive example

client: https://github.com/bjartek/embed-test-client/blob/main/main.go server: https://github.com/bjartek/embed-test/blob/main/foo/main.go