Routes are generated as numbered strings e.g. `/kv...

# kvision

[rocketraman]

Routes are generated as numbered strings e.g. /kv/routeFoo1, /kv/routeFoo2. Does this imply that changing the order of methods in the interface breaks compatibility with existing clients? For both compatibility reasons and clarity of debugging in the network inspector, does it make sense to give routes names based on the target method name: /kv/routeFooSomeMethod and/or an annotated name?

[Robert Jaros]

As far as I remember the routes names were generated from the method names and it was working fine with the legacy compiler. But it stopped working with IR, because the names returned by reflection on the JS side were different. So the only solution was to use automatically generated counter. And yes - the order of methods can now break existing clients (and the other way - the new client can be incompatible with the old backend).

[Robert Jaros]

Still the whole thing is designed to be simultaneously compiled on both ends.

[Robert Jaros]

And you can always use annotations for custom routes names if you need.

[rocketraman]

Ok, thanks for the clarification. In my case, even though the code is compiled simultaneously, it is not deployed simultaneously because my front-end and back-end are served from different places. Plus browsers could be running older code.

So its a corner case but one I need to consider.

[rocketraman]

Oh, what is the annotation for the custom names?

[Robert Jaros]

https://kvision.gitbook.io/kvision-guide/6.-full-stack-development-guide/common-code#using-annotations-to-change-http-method-and-or-route-name