Making create-fuels apps deploy-ready (and other ideas)

[Dhaiwat10]

Just wanted to open this discussion to share some context before filing any issues around this.

Currently, the create-fuels is great for local development but it has many limitations.

Major Limitations

1. No Wallet Connections
   The app uses a private key for a local pre-fauceted account under-the-hood which is great for quick local debugging of your Sway programs, but not so much if you are trying to build anything more than that - inlcuding hackathon projects or prototypes that other people can use online.

2. No Direct Way To Deploy To Testnet
   Let's say you create a full-stack Fuel dapp locally that you now want to deploy to beta-5 using the same source code. This is very tricky at the moment, and not supported out-of-the-box.

Both of these limitations are related to the same topic - proper deployment support. The DevRel team has also requested this feature next as a top-priority on the roadmap for the tool.

We want more people to build dapps on Fuel easily, and deploy them easily. This is the goal.

This is an idea dump that I have until now after the EthDenver week:

I will be more than happy to continue working on this but I just wanted to share this briefly with the team for an open discussion to see if anyone has any more ideas, or critcisms.

[arboleya]

About the two points you listed:

1. I think this makes sense, but should we provide both options or only one?
2. Two other questions come to mind:
   1. What are the current limitations? Shouldn't the deploy work for any providerUrl?
   2. Would we be moving away from TS-specific tooling and overlapping with forc?

[Dhaiwat10]

1. Only one - the wallet connection flow. I think it's better if we do that because it more closely resembles how Fuel dapps are on testnets and will be eventually on mainnet. It will also get more people to be familiar with the Wallet SDK gradually rather than suddenly having to pick it up when they try to go from localhost to testnet. I have a few ideas on the design and the implementation of this - I can create a proposal when I open an issue for this.

2. The deploy should work if you just swap out the URL. But the UI should adapt to that too. We should create two environments in some sense - localhost and testnet. I'm not sure about the design for the deployment and your comment about moving towards forc territory. I will think about this more and come up with a design and ask for feedback once I have something. Ideally, I will try to use the fuels CLI only to accomplish everything here.

[Dhaiwat10]

And just to quickly elaborate more on the 'environments' and the UI here - I want to make it very easy for people to deploy this to somewhere like Vercel and still have a great local environment for prototyping that doesn't have anything to do with the actualy deployed project. Kinda like the two environments we have for the TS SDK - one that we get locally when we run pnpm dev and one that's on npm for everyone to use.

[arboleya]

1. Agreed 👍
2. Wouldn't the use of env variables be enough? (example)

[Dhaiwat10]

@arboleya env variables would certainly be a key part of implementing this, but there would be several other things that would have to be changed in the UI too including certain UI elements and some of the scripts like build and prebuild

[arboleya]

Oh yeah, sure. I was thinking about the config file in isolation, my bad.

[petertonysmith94]

@Dhaiwat10 pretty sure we've addressed all these points so closing this discussion 🚀 .

Please feel free to reopen if that isn't the case 😄