Consider renaming this project to substrate-rest-api-service

[PierreBesson]

Proposed Change or Idea

The current name: substrate-api-sidecar is misleading to the real nature of the service and is pushing users toward the wrong deployment model. This is actually a stateless service that can be scaled vertically and so the right way to deploy it is not as 1 sidecar for each node.

---

Definition of a sidecar from Designing distributed systems chapter 2:

---

In our case, we don't fit the definition as we don't rely on any shared state between the "sidecar" and the node as all communication happens over RPC and as such is already decoupled.

This is causing some confusion for the Parity Devops team and must be similarly confusing for other teams adopting the sidecar.

For example in our node helm-chart, we deploy the sidecar as an actual kubernetes sidecar (see source). This has a lot of disadvantages compared to the helm chart currently provided by this project in the helm directory which uses a separate deployment that can be scaled vertically and that provide rolling upgrades automatically. However when you deploy the service as a "container sidecar", you will incur downtime each time you upgrade the sidecar as you have to restart the pod running both the node and the "substate-api-sidecar".

Proposal:

• Rename the project to a clearer name, eg. substrate-rest-api-service
• Externalize this project helm chart to Parity's Helm-chart collection where it will be properly packaged

Goal:

• Clarify this project function by using a more accurate name
• Make it easier for operators to deploy the susbtrate-api-sidecar in a reliable way

[BulatSaif]

More options for new name:

1. substrate-api-proxy
2. substrate-rest-proxy
3. substrate-api-adapter
4. substrate-rest-adapter

[jsdw]

I personally would be up for calling it something more descriptive, too! substrate-restful-api, substrate-json-api, substrate-rest-proxy or something like that sound most descriptive to me.

I don't think that "sidecar" is wrong personally (The text in that screenshot says it pretty well; "The role of the sidecar is to augment or improve the application container, often without the application containers knowledge". The text doesn't mention anything about shared state, but does mention colocation which is obviously not a requirement (though perhaps a suggestion) for this project). But "sidecar" is also a term that has specific meaning in things like Kubernetes, and I can see how this can lead to confusion.

But yeah, that all said, "sidecar" just doesn't capture the essense of what the project actually does very well.

[TarikGul]

Yes, I would be more than willing to make this transition for this service. For the most part I agree with the overall sentiment. I do like the following suggested names: substrate-restful-api, or substrate-rest-api-service

Couple of notes to think about:

1. Can we redirect the repo name of substrate-api-sidecar -> <new_name> when searched in github? Or are there other solutions to ensuring people can find the repo.

2. Updating the NPM package should be pretty simple. Just requires a change in the package.json. Our best approach would also be to continue with the same versioning. Might be confusing for some, but we can handle the integration part for teams.

3. Polkadot wiki will need to be updated.

4. Substrate dev will need to be updated.

5. Public, and private instances will need to be reconfigured.

[IkerAlus]

After quickly checking with the relevant team/people, I see an agreement about the renaming.

Apart from the technical points raised by @TarikGul , I also contacted our product marketing experts to ensure the renaming causes no friction for existing users. I will update this issue with the their input.

[jsdw]

Re the github repo name change, I think github will automatically redirect from the old name to the new location (not sure how long for without checking) so from that side, old URLs etc should keep working for a while at least.