Closed baijum closed 2 years ago
I just found a Node.js library.
I also created a Python implementation using the above API.
On a closer look at the Node.js implementation, Java implementation, and my own Python, looks like it is a bit hard to standardize the client library. Every language/framework has its own needs/constraints. Probably we should leave it to the community and see how it evolves?
We should start to collect a list of adopters for services and app libraries that conform to the provisioned service or application projections sections of the spec (respectively).
Another application projection from QUARKUS: https://quarkus.io/guides/deploying-to-kubernetes#service-binding
I don't see much use of provider
value. I think we should work on the implementor's guide to explain the usage pattern.
I don't see much use of
provider
value. I think we should work on the implementor's guide to explain the usage pattern.
I just started working on a draft PR: #175
I think we should work on the implementor's guide to explain the usage pattern.
It will be actually much better to have mini sdk for each popular library done as part of the spec. Since spec now enforces large file structure with multiple files I always hear some from of negativism related to lack of single file or env variables. If there would be libraries that cover binding to object for every major language then this will be huge boost for overall binding popularity.
It will be actually much better to have mini sdk for each popular library done as part of the spec.
While I agree that we should encourage and support libraries for every major language, I strongly disagree that we as the spec community should provide them. There's a find line as a spec between fostering a community and being the community; we do not want to be "the" community. By starting to provide "official" libraries, it ends up discouraging third parties from developing their own support as it is hard to compete with the official libraries, even when it is outdated and inferior. Because we don't have expertise in every major language, they will inherently become outdated and inferior.
I was copying the experience I had in the GraphQL community which provides "community-supported reference implementations" that are still maintained by volunteers. I was thinking in terms of creating space for building such libraries - like repos and looking if there will be possible maintainers. For us is better to maintain this in the source rather than add some solutions into each open source project etc. Process of creating specifications involves measuring impact, breaking changes on libraries that exist.
The concept of reading files into configuration seems low on investment and maintenance free task that can be achieved without significant development effort.
Reference specification also forces spec proposals to be more practical and down to the earth, meaning that spec will not overgrow into corner cases that will not be widely supported etc. EDIT:
What is also good is that introduction of the different languages can bring a better perspective on how things can be done and provide a feedback loop to the evolution of the spec.
Go package: https://github.com/baijum/servicebinding
How the application developers consume the binding depends on the programming language of their choice. If there is a document that providers some API for few popular languages would help accelerate the adoption of the spec. Probably we can create some language-specific libraries. For Java, Spring Cloud Bindings library looks great.
This is my attempt to design API for Python and Go.
Python:
Go:
Feedback welcome!