Reusable client / server libraries for Pinning Service API

[lidel]

Let's discuss if it would be useful to have reusable libraries.

AFAIK go-ipfs and js-ipfs plan to implement clients for Pinning Service API.
It is very likely that some of pinning services will use golang or JS for the server side too.

Q:

• Would it be useful to join forces and have vendor agnostic client/server libraries for GO and JS?

cc @ipfs/wg-pinning-services @obo20 @GregTheGreek @priom @jsign @sanderpick @andrewxhill @MichaelMure @aschmahmann @achingbrain @Gozala @jacobheun

[MichaelMure]

It would make sense to me to have a reusable go package that implement the server side http request handling, errors and all that, and pass the queries to a go interface. Everyone would be free to plug there their own implementation with the guarantee to not deviate from the spec.

[MichaelMure]

and pass the queries to a go interface

... or a CoreAPI

[lidel]

We have wip client in ipfs/go-pinning-service-http-client#3. It is a thin wrapper on top of code generated by https://openapi-generator.tech/ that makes it easier to ensure golang API remains stable, even if generated code changes in the future, so it makes sense to maintain it.

@MichaelMure I am unsure how useful reusable server library would be, because the reusable part would be generated from OpenAPI spec (this ensures server conforms to the wire format), and everything on top of it sounds like vendor-specific things that would not be part of library anyway.

Perhaps you could give https://openapi-generator.tech/ a try and see if generated server provides what you need? If not, what vendor-agnostic features could be included to make it worth it to have a server lib? (We'd like to avoid maintaining a library if its only a generated code)

[codynhat]

We have generated a Javascript/Typescript client using the OpenAPI typescript-axios generator at Geo-Web-Project/js-pinning-service-http-client.

We have been using it in a simple app in the browser to add and list pins. It has been working well for us so figured I would share it here.

[Gozala]

I'm not sure there is much value in such library, at least on JS side of things given how opinionated community is around server library choice etc...

I think it would be far more useful to:

1. Have comprehensive test suite so that server could validate compatibility.
2. Have a server built into IPFS node, so that any ipfs node could be treated as a remote you can pin to. However that would imply doing access control and likely die in bikeshed.

[lidel]

• Test suite is being developed in https://github.com/ipfs-shipyard/pinning-service-compliance
• Client libraries (GO, JS): https://github.com/ipfs/pinning-services-api-spec#client-libraries
• IPFS Cluster support got merged (Support the Pinning Services API ipfs-cluster/ipfs-cluster#1213) and will ship in 1.0.0 – we will test in Add Pinning service provider: Test ipfs cluster ipfs-shipyard/pinning-service-compliance#13