[meeting] API-first initiative meeting 2020-02-18 [#3114441]

Hi all! This is the start of the weekly API-first initiative meeting. The conversation will take place across various threads.:zero: let us know who's here (please include your d.o username if it's not apparent so I can give you d.o credit)

wimleers (he/him)	:wave: Wim, Ghent, Belgium
gabesullice	gentle reminders to those who have attended in the past: @wimleers (he/him) @e0ipso @jibran @Lio Novelli @bradjones1 @prestonso (he/him) @matt_paz @skyred @zrpnr @morbus (they/them) @eli-t @ylynfatt
eli-t	Hiya! Eli here, Manchester UK
matt_paz	Here ... just lurking again
ylynfatt	Hi Yannick, Jamaica :flag-jm: here.
Lio Novelli	Hi, Lio here (usernamee on d.o) from Ljubljana, Slovenia
e0ipso	Hello!
jibran	Hi! Just lurking as well.
morbus (they/them)	’Ere, from the US.
zrpnr	Hi, Peter from Denver, US
gabesullice	Thanks for joining everyone! The official meeting is over, but feel free to continue any ongoing conversations.

:one: Please post any topics you'd like to discuss here and then I'll start a thread for them

wimleers (he/him)	JSON:API contrib module 8.x-1.x EOL in 48 days, but https://www.drupal.org/project/usage/jsonapi is not showing the usage declining :neutral_face:
wimleers (he/him)	JSON:API ecosystem: 9.x compatibility
wimleers (he/him)	Maybe @gabesullice can share a bit about the progress towards the 1.1 version of the JSON:API spec? (Recently some important commits landed, see https://github.com/json-api/json-api/commits/gh-pages 🥳) (edited)

:two: JSON:API 8.x-1.x EOL cc: @wimleers (he/him)

wimleers (he/him)	How worried are we that https://www.drupal.org/project/usage/jsonapi is not showing a real decline for 8.x-1.x?
wimleers (he/him)	IDK what else we can do though. It was announced on January 7, 2019 :shrug:
wimleers (he/him)	and blogged about it on Jan 7, 2020: https://wimleers.com/blog/jsonapi-1-eol + https://mateuaguilo.com/web-development/2020/01/07/jsonapi-1-eol/ (edited)
gabesullice	We could talk to the security team and see if we could send an announcement via their mailing list.
eli-t	Is it any worse than the behaviour for other unsupported modules?
gabesullice	@eli-t I think the only differentiator is that most other unsupported modules don't have a supported alternative in core. (edited)
gabesullice	I actually think we probably have a higher "success" rate of people leaving the EOL branch than most modules too
wimleers (he/him)	yeah I think so too
wimleers (he/him)	But I’d love to see that number get far below 1000
matt_paz	Might this as much a problem with getting people to update core as it is with getting folks to ponder jsonapi contrib update in isolation?https://www.drupal.org/project/usage/drupal (edited)
wimleers (he/him)	@matt_paz Interesting question! I wonder if we can ask the DA to correlate jsonapi 8.x-1.x with unsupported drupal 8.x uses … if all of them are on unsupported D8, then that’d indeed explain it! Hadn’t even thought of that :slightly_smiling_face: Thanks so much for this insight! :pray: :clap:

:three: JSON:API 9.X compatibility cc: @wimleers (he/him)

wimleers (he/him)	The most important contrib ecosystem module is of course jsonapi_extras — @e0ipso, could you add daily testing against 9.x to https://www.drupal.org/node/2873823/qa ?
e0ipso	done
wimleers (he/him)	The next most important modules are https://www.drupal.org/project/jsonapi_hypermedia (@gabesullice, could you add daily 9.x tests?) and https://www.drupal.org/project/jsonapi_resources (@mglaman, could you add daily 9.x tests?)
eli-t	Done for jsonapi_reference :slightly_smiling_face:
eli-t	to be fair, we need a lot more tests for that to have meaning!
wimleers (he/him)	Still, gotta start somewhere!
mglaman	doing so now!
mglaman	queued up https://www.drupal.org/pift-ci-job/1582973

:five: JSON:API spec version 1.1

gabesullice	Last week we ripped out lots of complexity around profiles and then introduced a second concept of "extensions"
gabesullice	Extensions are more powerful than profiles ever were in that they can add new, required functionality in a way that could be adopted into the spec itself.
gabesullice	Profiles are less powerful, but very useful. They're kind of like schema, not essential to funtionality but if you know they've been applied you can make more assumptions and do cooler things.
Lio Novelli	I'm sorry, where/when did that happen?
gabesullice	The first, major extension will be an "operations" extension for executing multiple dependent mutations in a single request. You can think of it kind of like subrequests module lite
gabesullice	@Lio Novelli in the 1.1 branch of the JSON:API specification
gabesullice	1 sec, I'll get a link
Lio Novelli	i already have it
gabesullice	https://jsonapi.org/format/1.1/
Lio Novelli	I presume that discussion was going on in #jsonapi channel
gabesullice	Actually it didn't really happen anywhere near Drupal
Lio Novelli	I see
Lio Novelli	But the specs will probably have to get implemented ...
gabesullice	Yes
gabesullice	When it comes to that, we'll definitely discuss it here
gabesullice	Drupal can leverage profiles and extensions for lots of things
gabesullice	For example, I think it'd be very cool to make an extension for our filtering syntax and have alternative syntaxes negotiable through the use of different syntaxes.
ylynfatt	@gabesullice could you expound on what you mean by the filtering syntax? Do you mean ?filter[field_name]=value&filter[field_other]=value ? What would an alternative syntax be for example?
gabesullice	@ylynfatt, yes, that's what I mean. An alternative could be something that looks like filter={field_name:{value:"foo"}} where there is only one filter query parameter but the value is a big JSON object
gabesullice	There are some node JSON:API libs that have a weird syntax like this one: https://github.com/ethanresnick/json-api#filtering (edited)
gabesullice	e.g. ?filter=(zip,:in,[90210,10012])