feat: add migration instructions #211
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
@gabrielmer are you able to build the website locally without any issue? |
Was able to debug the issue locally and now everything should work :) Thank you! |
There was a problem hiding this comment.
Thanks for that! I think I may lack some more context to understand the change better.
I've added some comments that I hope you find useful.
Also, I'm a little bit worried that we might need to maintain this page. I think it'd be better to address people towards the nwaku's CHANGELOG.md and then only maintain that CHANGELOG.md.
|
|
||
| In order to migrate your existing application, you need to: | ||
|
|
||
| 1. Make sure that your clients are sending messages to pubsub topics in the required format. |
There was a problem hiding this comment.
Maybe we can elaborate a bit more about how to validate that a client is sending messages
There was a problem hiding this comment.
Please take a look now. The idea here was that if an user interacts with a node via REST clients or js-waku, that they use valid pubsub topics.
It's hard to get into details because there's so many ways of interacting with a node. But at the end it boils down to REST and js-waku usage. And when using any of them, valid topics should be configured.
Let me know if you have a better way of explaining it :))
| In order to migrate your existing application, you need to: | ||
|
|
||
| 1. Make sure that your clients are sending messages to pubsub topics in the required format. | ||
| 2. When running a node with the `--pubsub-topic` CLI flag, the values provided should comply with the static sharding format. |
There was a problem hiding this comment.
Interesting if we could add an example about the "static sharding format".
There was a problem hiding this comment.
I added the definition of the static sharding format right above it, in
do you think we should repeat that point?
|
|
||
| 1. Make sure that your clients are sending messages to pubsub topics in the required format. | ||
| 2. When running a node with the `--pubsub-topic` CLI flag, the values provided should comply with the static sharding format. | ||
| 3. If your application relies on nodes or clients that may not be updated immediately, keep your node on an older version while subscribing to both the current pubsub topic and the new pubsub topic that will comply with the static sharding format. In that case, you can keep backward compatibility for a migration period. |
There was a problem hiding this comment.
Sorry but my single neuron can't quite follow that. Maybe we can have an example :)
There was a problem hiding this comment.
Lol, this was proposed by @fryorcraken , I didn't think about it before. But if some application relies on nodes that use named sharding to interact with the network, if we upgrade our nodes and stop allowing named sharding, then all the traffic by outdated clients will be rejected.
Sometimes people want to give a longer and smoother migration period and give more time for users to update their clients. So by running nodes that support both the deprecated naming version and the new version, traffic can be relayed for people with outdated and with updated clients. Once there's almost no outdated clients, then they can update and completely break support for them.
Does it make sense? If so, do you think that adding an explanation like this would help? Thinking on how can I word an example for this without deviating too much from the main point
gabrielmer
force-pushed
the
feat-add-migration-instructions
branch
from
3f84fa3
to
58a1310
Compare
Adding section with instructions on how to migrate a node after new releases