Сlient module

[pomadchin]

Overview

This PR adds a stac4s api client module.

Checklist

• New tests have been added or existing tests have been modified
• Changelog updated

Notes

It is a WIP pr, any suggestnions are appreciated.

Closes geotrellis/geotrellis-server#288

[jisantuc]

I'm very excited to have an API client and I might borrow this in my R&D instead of hand rolling a the few endpoints I need methods for

[jisantuc]

I'm a little confused -- what's the purpose of a dependent Filter type?

[pomadchin]

@jisantuc the trick here is to have it in the shared package. To put STACClient into the shared package we only need to have SearchFilters compiling for both JS and JVM backends.

SearchFilters should countain jts.Geometry type that is why we need to maintain a spearate implementaion for the JS backend.

I wanted to have an abstraction of the Filter type (since it is very backend and implementation dependent). Having this Filter type hidden helps to simplify the STACClient signature.

StacClient[F] signatures makes sense, but StacClient[F, SearchFilter] looks extremely confusing.

The alternative to that can be found here 0647db7 (maintaining two 95% equal STACClient implementations but with a different SearchFilters type)

[pomadchin]

Btw we can have a quick call if you want me to walk you through this decision

[jisantuc]

This is correct for Franklin's implementation of pagination, but only for Franklin's -- the particular pagination strategy is left open to implementers. So there are a few things that are a bit weird as a result --

• client side search filters can't assume that the value in next will be a json PaginationToken, since it will just be an opaque string by the time it reaches the client. This means this is probably wrong for any other STAC API implementation.
• the thing Franklin actually sends back in this field is a base64 encoding of the pagination token, so decoding it probably won't work client side (not sure if you had a chance to test that)
• the thing Franklin expects is for the client to have a hold of the opaque token, so it does a base64 decode to get the json out

https://github.com/azavea/franklin/blob/f5be8ddf48661c5bc43cbd22cb7277e961641803/application/src/main/scala/com/azavea/franklin/api/schemas/package.scala#L84-L85

So I think this shouldn't work

[pomadchin]

I'd say this is fine; since it is a default implementation (i.e. if smth doesn't work user can always define theirs own STACClient with a redefined search filters: see https://github.com/azavea/stac4s/blob/7f6abceeebea59dfc9a605891c73fc121116610b/modules/client/jvm/src/main/scala/com/azavea/stac4s/api/client/SttpStacClient.scala#L9-L13 - they only need to define their own version of SearchFilters), if smth won't work in the future with other STAC Services I think we should handle it later (?).

[pomadchin]

Opened an issue for that #198

[jisantuc]

I'm not really talking about streaming here though -- I don't think this pagination encoding will work, and the tests included here don't exercise pagination. Since the pagination implementation here isn't exercised and I think won't work, I think it should just be omitted until someone is working on #198

[pomadchin]

Oops forgot to push not tested codecs

[pomadchin]

@jisantuc added it into the issue description #198

[jisantuc]

confirmed, build tooling is not smart and doesn't know about scalajs decorators in shared/ 😢

I think users who want the JS version will need to create a client and export the methods they want from it.

[jisantuc]

🎉 Is #198 prioritized / anyone's responsibility? It would be good to tackle that while we still have context pretty well loaded

[pomadchin]

@jisantuc we don't have it on the radar right now, but we'll have some time in terms of the other project to handle that. I'll assign it on myself in order not to forget about it.