Decide where to host

[EvgeniiaVak]

We need to place somewhere our app for people to be able to reach it. Even during the development, I think it will be great to have it, so that not only coders can interact with it and give feedback in telegram. Options:

1. (for development stage only) GitHub or vercel (these are old web2 solutions, but during the development, I think it'll be good to have one - they have freemium easy to setup ci/cd pipeline (with next.js vercel is easier than github for personal accounts, I don't know about ogs yet))
2. flux
3. fleek

[timanrebel]

Can I throw in Cloudflare as an option as well? Their Pages set up works really well for frontend-only apps and afaik it's completely free for all basic features. Also supports Next.js

Astrolescent and Defiplaza fully run on Cloudflare. We do have a paid plan for some more advanced features, but we don't spend more than 20 to 40 USD a month on it in total for each project (Cost at Astrolescent mostly comes from the algorithm running on Cloudflare workers and it gets called around 500k times a day)

[fliebenberg]

We need to pick up this issue now that we are getting closer to MVP release. We will need to host the MVP somewhere for the community to interact with it. Server's etc are not my field of expertise, but I just wanted to get this conversation going again.

[Radstakes]

I like the idea of CloudFlare that TIman suggested, perhaps worth a look if the free plan gives us what we need initially. CloudFlare Plans. Do we want to consider a decentralised option, like IPFS from launch, or maybe for the MVP we just stick to web2 servers?

[Radstakes]

Also this just popped un in the Runs on Radix Discord channel. As much as I don't like AWS, could also be an option...

[EvgeniiaVak]

I would go with the easiest option for testnet deployment. We don't even need a pretty domain for that. And I think it should be alive and separate from the live deployment:

1. deploy the test version somewhere that is cheap and easy to set up (I know how to do it on vercel and github, aws will probably also be easy), this version works with testnet AlphaDEX and will continue to work with testnet only, I would vote for this version to be deployed even right now, or after fixing known bugs (even though we don't have the layout yet, the functionality is there), we may need to hide it from the search engines #36
2. wire up the automated updates, so that when we have something merged to main - our community can try it out
3. do some research on where to really host when we go to production (I vote for something closer to web3)

[Radstakes]

I agree - getting the test version up with automated updates would be amazing. If you are happy to get it hosted on Vercel then I'd vote for that.

I will look further into IPFS hosting, so we have a decentralised solution for production. I'll also look at our domain options. We already have the XRD domain, but that currently requires our users to have the Chrome/Firefox extension to resolve dexter.xrd to our app so maybe we want to secure a web2 domain as well (dexteronradix.com for example).

[timanrebel]

NextJS is by Vercel, right? So Vercel would be a great option. And they have a free plan as well...

I have no experience with Vercel, but I can teach it myself in no time if you need help.

[Radstakes]

Excuse my lack of understanding of development, but is it possible to export DeXter as a static website? I can only deploy it by running the node engine, is this correct? I was hoping to build it and export as static html pages that we could then host on IPFS, but I couldn't get it to work, Am I doing something wrong, or is this just the nature of a nodejs app?

[EvgeniiaVak]

@Radstakes it is possible to export as a static site if running npm i followed by npm run build (for example locally on your machine) - it will result in files that can be used the way you want. Alternatively you can wait until we set up a ci here in github, that will result in the static files (for example in releases).

[Radstakes]

Yeah I did try that and it compiled successfully but it didn't generate any static html files. Maybe something else I need to configure in the next.config.js but I haven't figured it out yet. It seemed to me that you still need to run the nodejs web server to render the site, which rules out IPFS deployment.

[EvgeniiaVak]

@Radstakes ah, yes, sorry, forgot this line in the settings https://github.com/DeXter-on-Radix/website/pull/67/files

this will result in the static files (not only html) in out folder

[Radstakes]

OK so updating the config attempts to export static files, but there's some pre-render issues currently preventing the pages being generated: prerendor-error

I'm not sure what the error is, do any of our pages require server side rendering? Maybe best I wait until we're closer to a release for testing?

[EvgeniiaVak]

@Radstakes yes, we'll need to have a closer look to the build process with the current version, we'll need the ci anyways (regardless of where we host the resulting files), tracking it in #36 planning to do it this weekend

[EvgeniiaVak]

@Radstakes the build on main branch is working now, you can try again with npm run build and the resulting out folder if you want. Warning: it's quite ugly (no styles applied) and the position size %s shortcut do not work correctly yet.

[Radstakes]

Thanks @EvgeniiaVak - Just tried my first trades on DeXter, but sadly had to build it using npm run dev. When I use npm run build, it compiles OK and produces an 'out' directory but when I try to view the index.html I just see this...

Using run dev works fine for testing locally though, this is what I get...

It's connecting fine and executing trades is working great. One question I have on the manifest, what's the second output shown here?

[EvgeniiaVak]

@Radstakes ah, this is because you need some server that knows how to respond to the pages requests. All the cloud providers do (I'll probably push something to vercel later today or tomorrow). The local OS unfotunately doesn't (it serves you the html you clikced all right, but all the other files like js and css - no). I'm not sure about IPFS, never tried it, very interested to see how that would go. Locally you can serve the build files with npx serve out (it'll ask you to install the serve thing if you don't have it yet) or if you have python istalled you can use its built-in server:

cd out
python3 -m http.server

[Radstakes]

thanks @EvgeniiaVak - that was my concern, as IPFS is just file storage, anything that requires a server to run is not going to work there. I think Fleek might be an option so will look into that, otherwise we will need a web2 server to host the site, which is not ideal, but I guess will be fine for the MVP. We can still provide instructions for people to run the front end locally if they want a completely decentralised experience.

[Radstakes]

Update @EvgeniiaVak - managed to host the website using Fleek. So we're now on IPFS and any updates to main will automatically redeploy. Pretty cool - if you want to test it, here's the link: https://purple-grass-3772.on.fleek.co

I also had a chat with Wylie, he thinks the issues I'm having with the static deployment is because SSR is still enabled. There's a flag you need to specify at build for static generation apparently. He's going to pull the repo and try and troubleshoot it for us.

Fleek will work fine for us, but even better if we can get the static deployment working and host it on IPFS manually too.

[EvgeniiaVak]

Yes, we have SSG, which is something like SSR but for generating static sites. It will be helpful later for SEO and performance, but currently we don't use that much. I'm very interested in other people reviews of this 👍

[Radstakes]

I've created a subdomain and linked it to the deployed site (will need to use an IPFS ready browser like Brave): ipns://dev.dexteronradix.com/

Will be good to test if it updates automatically the next time some revisions are committed.

[EvgeniiaVak]

@Radstakes

otherwise we will need a web2 server to host the site,

not really, there kind of can define 3 types of creating a website:

• a single .html file - could be opened by directly from a folder in your browser locally, for some reason the industry decided it is not the way (maybe because of performance reasons, I don't really know) but the thing is, almost no framework can build to it by default, you need to jump through hoops to achieve it, very inconvenient for small projects btw, when you just want to share a prototype with a colleague
• static site (this is what we have) - which is just a collection of files, (html, css, js, images etc.) and does not run any logic on the server, the only thing that is required from the server is that it's able to give that particular file for that address. SSG (static site generation) - happens during build time (when npm run dev is running), it generates static (meaning they won't change while a user is interacting with the site, all the js code executes on the client-side - in the browser) files, that we can serve from any place that is capable of resolving domains (it is also possible with just chrome and the files in out folder locally, but it's more complicated than using a console command, here is how to https://www.linkedin.com/pulse/how-use-chrome-local-server-mohammad-althayabeh/ ) So if the additional files (js, css, etc.) have the same domain as index.html, they should be served all right.
• server powered app - when some logic executes on the server, that one would really require us to have some custom server running, but we are not doing that in DeXter, all the server-side logic is covered by AlphaDEX

[EvgeniiaVak]

@Radstakes I guess for the sake of simplicity we will be hosting both testnet and mainnet versions on netlify for now? What is the build process there? can we specify environment variables for the build stage?

[Radstakes]

@EvgeniiaVak yes I think that would be the easiest route. For mainnet we probably want to publish manually for safety. I'll have a look at setting environment variables too, should be able to get back onto this in a couple of days.

[Radstakes]

Hi @EvgeniiaVak - Update on hosting... Unfortunately I can't add you or any of the other team members to Netlify unless we upgrade to the Pro plan, so I would suggest that for now I retain access alone on the free tier until after we launch and hopefully then the treasury can fund the hosting costs and I can add you or anyone else as a collaborator.

In terms of build, these are the settings we currently have: So perhaps we should create a new branch for mainnet, and set this to deploy manually? We could auto generate a deploy_preview of mainnet releases, but only push to dexteronradix.com when we're happy. What do you think?

If there's any environment variables you want to set, I can add these quite easily. There's some guidance in the docs here: https://docs.netlify.com/configure-builds/environment-variables/

[EvgeniiaVak]

@Radstakes

So perhaps we should create a new branch for mainnet, and set this to deploy manually?

Yes, we can create a new branch.

We could auto generate a deploy_preview of mainnet releases, but only push to dexteronradix.com when we're happy.

Sounds great! Do we need the new branch for this? or can this be done from the same main branch that deploys to test.dexter... as well, just changing the env var values?

[Radstakes]

The simplest option seems to be that we create a new branch for mainnet releases and have this automatically publish to the domain (dexteronradix.com) like we currently do for main on Stokenet.

We can then use deploy-previews for any other branches.

Env variables could also be used if there's a preference to do it that way.

[Radstakes]

Should we use a subdomain for the app, like app.dexteronradix.com or just use the root domain (dexteronradix.com)? We might want to have a landing page or something in future?

[EvgeniiaVak]

@Radstakes @nguvictor Ok, new branch it is. How should we name it? Here are a few options:

• make the main branch the branch for mainnet, and rename the current main branch to develop
• production
• mainnet

About the subdomain, I think it's ok to have just dexteronradix.com, we can have the landing page on it later (when we have the page), and the current trading page we can move to dexteronradix.com/trade. Alternatively, if we do use subdomains, how the testnet version would look like, something like test.app.dexteronradix.com?

[Radstakes]

mainfor mainnet and a duplicate developbranch makes sense to me.

I'm also happy to use the root domain for the app, like you say we can always change it later. Unfortunately we can only assign one domain with the free tier on Netlify, so our production branch will use dexteronradix.com and the test-deploys will have to use a Netlify link. If we later go for the paid tier, we can then usetest.dexteronradix.com for these deploys.

[EvgeniiaVak]

@Radstakes maybe we don't even need the develop branch, while we don't have test.dexteronradix.com (btw, how much would it cost?), maybe what we need is to change test.dexteronradix.com to dexteronradix.com in the current deployment and that's it. We could also require at least 2 reviews before merging into main branch.

[Radstakes]

@EvgeniiaVak yes that would be the simplest way forward. I can update the domain records and then when we merge into main we will be on mainnet. I think it would be good to keep test.dexteronradix.com going, but at the moment we don't need a paid tier. The Pro tier is $19/month and that will give us much more bandwidth and subdomain support. I think ideally we would make a proposal to the DAO/treasury to cover this cost, once the treasury is a bit more healthy.

[EvgeniiaVak]

Closing this as we are hosting on Netlify. We may reopen it later if we need something else