Fork me on GitHub
#yada
<
2019-10-16
>
jeroenvandijk13:10:18

Do people use Yada in combination with AWS Cognito? (I think obtaining JWT tokens via Cognito using those tokens for Yada authentication)

jeroenvandijk13:10:13

ok I cannot find examples, but it looks rather simple

mccraigmccraig14:10:35

we don't use cognito, but do use JWTs for yada auth ( with funcool/buddy ) - all very straightforward

jeroenvandijk14:10:42

@mccraigmccraig thanks for confirming that

raymcdermott15:10:19

a question about versioning via Accept a la github API v3 https://developer.github.com/v3/#current-version

raymcdermott15:10:21

I would like to use Yada to process something like Accept: application/vnd.funcky-api.v1+edn

raymcdermott15:10:38

tbh we have an interceptor to retain raw payloads at the moment so I don't need yada to read the edn but just want to check whether there are any known issues with this approach - which is quite common in the API world

raymcdermott15:10:01

I can just parse the header myself and put the parts back on the ctx

dominicm16:10:03

I seem to recall adding support for that

raymcdermott16:10:07

do you remember what the support offered? ie did it allow routing per version?

raymcdermott17:10:47

or was it just adding the data to the context to allow for later interpretation (which is what I'm doing)

raymcdermott17:10:33

I have added a map {:name api-name :version api-version :data-format api-data-format} under [:request :accept-data]

dominicm18:10:55

It was making the parsing work for the spec of extension types

dominicm18:10:24

Might have been a pull request that I reviewed, I don't think we merged it

malcolmsparks18:10:46

I don't think you don't need suffix support. You just declare in yada the versions you are able to produce and in the Accept header the versions you can process. Content negotiation does the rest.

dominicm18:10:40

Oh, missed that you already have something that reads the edn

raymcdermott20:10:07

@malcolmsparks do you have an example?

raymcdermott20:10:23

apart from 'application/edn' where can I specify that the consumer expects v1 or v2? or are you saying that a client should never express that?

malcolmsparks20:10:08

Ah, I see. You'd offer to consume either of application/vnd. funcky-api.v1+edn and application/vnd.funcky-api.v2+edn.

malcolmsparks20:10:41

A v2 api wouldn't necessarily be different routes, or it might. The routes would be contained in the representation of the initial response from /.

malcolmsparks20:10:00

That representation would reflect its version.

malcolmsparks21:10:57

That's a problem if clients code themselves against specific URLs, rather than generating those URLs in representations.

malcolmsparks21:10:42

Which is why Swagger/OpenAPI isn't REST, which prioritises evolution of services on the web. However, in-house services, codeveloped along with their clients, can benefit from establishing the OpenAPI contract up-front. I think that's still a poor strategy long term - not much progress made since IDL really.

malcolmsparks21:10:25

Because ultimately, even in-house services can last decades.

malcolmsparks21:10:03

But today's culture is dominated by moving fast and building 'MVP's

malcolmsparks21:10:53

Tomorrow's culture maybe more cautious and spend thrift

raymcdermott23:10:32

the goal is mostly to express the fact that various clients in the wild will produce and consume v1 / v2 payloads without the need for out of band schemas so maybe the question is posed badly

raymcdermott23:10:25

if we find a bug or a security problem with the encoding of data by v1 we need a way to tell the customers to upgrade the SDK to v2

raymcdermott23:10:18

I'm happy to keep tending the sprawl on the back end 🙂