Expose configuration as environment variables

[niccoloraspa]

Currently, the process to connect the frontend to a new testnet is:

• create a new PR
• have Vercel deploy it
• adapt the code to make the required changes (change RPC, LCD, chain-id, etc...)

However, this process is not optimal, and it tends to be repeated multiple times:

A better approach would be to generalize the changes made in this PR https://github.com/osmosis-labs/osmosis-frontend/pull/793, allowing users to configure the frontend using environment variables as input. The environment variable should be used at RUNTIME and not during the BUILD.

By doing so, we can quickly create different environments specifying only different environment variables and possibly use a different deployment solution than Vercel.

[daniel-farina]

This is something I'm currently exploring. Ideally we would do something like:

{
      rpc: process.env.NEXT_PUBLIC_OSMOSIS_RPC,
      rest: process.env.NEXT_PUBLIC_OSMOSIS_REST,
      chainId: process.env.NEXT_PUBLIC_OSMOSIS_CHAIN_ID,
      chainName: process.env.NEXT_PUBLIC_OSMOSIS_CHAIN_NAME,
      bip44: {
        coinType: 118,
      },

However nextjs is not picking up these variables from a .env file. It's supposed to happen automatically.

[jonator]

Have you looked at master?

From the Bridge Integration I've added a NEXT_PUBLIC_IS_TESTNET env var that may solve for the most common need of having the above setup. When you build the app, it will use testnet config for ALL chains that have a IBC connection to our testnet. Also, it provides a way for the app to know it's in testnet mode, which is needed when using the Axelar APIs.

I may be wrong, but shouldn't prod and testnet nodes largely remain the same? And if they need to be changed, it's not too difficult to go into the config file.

[daniel-farina]

well, I think out setup is not just simply testnet vs mainnet, it could be a number of different environments. The NEXT_PUBLIC_IS_TESTNET should be kept in a .env file as well but we need more flexibility in order to spin up more nodes and frontends as needed for each releases.

I'll submit a PR shortly with some suggestions that would solve our issues on the DevOps side.

[jonator]

OK. I wouldn't know the needs of our ops.

Just an idea to keep complexity and maintenance down.

[niccoloraspa]

💯 agree with what Dan said, and the snippet posted is very much in line with what's needed.

The ability to specify different environments has a lot of net-positive effects and it's a simple, yet crucial, piece for creating common staging environments between frontend <> chain-dev for the next minor and major osmosis releases.

[jonator]

How would this apply to configuration on non-Osmosis chains? Like for Axelar? Which has testnet IBC connections.

[niccoloraspa]

I'm missing some details on this part, so forgive me if I say something wrong.

As I see it, at least at the beginning we would use whatever RPC/LCD osmosis we provide via ENV VARIABLES but still connect to the non-Osmosis chain test environments.

We would need on the infra side to set up the appropriate relayers/nodes/whatever it's needed from the new osmosis testnet to the non-osmosis testnets.

Long term, ideally, we decouple all configurations from code.

For example, most of the configuration in https://github.com/osmosis-labs/osmosis-frontend/tree/master/packages/web/config is hardcoded in variables, and we only make a distinction from IS_TESTNET and ! IS_TESTNET to get the right values.

We can generalize this and allow the possibility of populate this variables from a configuration file rather than having it hardcoded in the source code.

This could allow the cherry pick which assets/connections we want enabled.

[daniel-farina]

How would this apply to configuration on non-Osmosis chains? Like for Axelar? Which has testnet IBC connections.

This is something that does not work on v12 currently or any chains other than testnet or mainnet, so it does not really make a difference. We are aware that Axelar currently supports mainnet, testnet.

Once v12 is tested, it should then go to the common testnet where additional testing is done with other integrations such as Axelar. The v12, v13, v14 will cover 90% of frontend test cases such us the ones we found for v12 which were breaking changes for the frontend.

We cannot have V12 merged directly into our testnet and break it, this is why a lower environment is first created to get rid off the nasty bugs first.

Draft PR here: https://github.com/osmosis-labs/osmosis-frontend/pull/812

PS: I need to draw a branching strategy & tier promotion process for the front-end and chain.

[daniel-farina]

I added env variables for Axelar so that we can configure the application to work with Axelar's testnet.

• Added Axelar variables
• Remove IS_TESTNET from packages/web/config/chain-infos.ts

https://github.com/osmosis-labs/osmosis-frontend/pull/812/commits/ea451e1a3008d9a65c38279c8f235c624e980656

I also added docs about env variables with a link to Next.js docs

https://github.com/osmosis-labs/osmosis-frontend/pull/812/commits/69341d095425f0ed2661d1c397aa2cf886aad19c

[daniel-farina]

@niccoloraspa After having a good conversation with @jonator, we have decided to use a simpler approach and safer that unblocks devops automation.

NEW PR HERE

@jonator I created a new PR here and deleted the old PR because it was configured to go to master directly. (I think we need to setup a rule that does not allow merging to master directly from feature branches).

[jonator]

You should be able to change the target branch by clicking edit at the top of the PR

[jonator]

@daniel-farina was this included in our testnet work with v12 upgrade?