-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider renaming this project to substrate-rest-api-service #1144
Comments
More options for new name:
|
I personally would be up for calling it something more descriptive, too! 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. |
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: Couple of notes to think about:
|
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. |
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. |
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:
substrate-rest-api-service
Goal:
The text was updated successfully, but these errors were encountered: