[meeting] API-first initiative meeting 2020-03-03 [#3118067]

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 so I can give you d.o credit for attending)

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 @mglaman (edited)
prestonso (he/him)	:wave::skin-tone-3: Preston in :statue_of_liberty:
matt_paz	Here ... lurking
ylynfatt	Yannick :flag-jm: (axle_foley00)
eli-t	I'm in the studio this week, will catch up afterwards
e0ipso	Hello all!
zrpnr	:wave: Peter in CO
gabesullice	Hello! gabesullice Denver, CO :snow_capped_mountain::us:
pwolanin (he/him)	HI, pwolanin, Philadelphia, USA
gabesullice	Whoops, I forget to put @mglaman in my reminder
wimleers (he/him)	:wave:
mglaman	:wave: Matt from WI here
gabesullice	Thanks everyone! Feel free to finish your convos, the official meeting has ended.

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

pwolanin (he/him)	I’m considering writing a module to handle multiple patch objects in one request for performance, anyone else doing that? (edited)
e0ipso	I think it would be interesting to know how many of the people here are talking in Minneapolis about decoupled Drupal.
e0ipso	@pwolanin (he/him) yes
e0ipso	there are at least 2 projects
e0ipso	Subrequests and JSON:API Operations
pwolanin (he/him)	ok, thanks, I’ll take a look
matt_paz	Here's a link to subrequests:https://www.drupal.org/project/subrequestsNot sure I'd run across the ops one yet ...https://www.drupal.org/project/jsonapi_operations (edited)
wimleers (he/him)	FYI: with https://jsonapi.org/format/1.1/, the concept of “profiles” and “extensions” is being added, which makes it more likely for this to be standardized
wimleers (he/him)	Although @gabesullice can speak to that with far more authority :slightly_smiling_face:

:two: Announcements? (edited)

prestonso (he/him)	This is the last week for Decoupled Days’ Call for Papers! All proposals are due on Thursday at 11:59pm EST — and I know we have a ton of folks who should submit in this group :smile: https://docs.google.com/forms/d/e/1FAIpQLScgdojEbV_I_tB1AmeOxkO7-5UzSkV_...
prestonso (he/him)	I’ll do another blast on Drupal Slack in general today and tomorrow (edited)
gabesullice	:+1:

:three: JSON:API 8.x-1.x EOL

gabesullice	https://www.drupal.org/project/usage/jsonapi
gabesullice	Ha went back UP?!
ylynfatt	:frowning: didn’t expect that
ylynfatt	I had to do a double take
wimleers (he/him)	usage stats are flaky
wimleers (he/him)	:slightly_smiling_face:
wimleers (he/him)	But yeah … I’d say it’s still trending down, but definitely far too slowly.
wimleers (he/him)	@gabesullice @e0ipso @ylynfatt There, asked the question: https://drupal.slack.com/archives/C51GNJG91/p1583251202051800
ylynfatt	:+1::skin-tone-3:
e0ipso	Thanks Wim.
pwolanin (he/him)	The upgrade from 1.x to 2.x was pretty painful for us
pwolanin (he/him)	I expect a lot of people don’t have the capacity
wimleers (he/him)	@pwolanin (he/him) Can you elaborate a bit on how it was painful?
wimleers (he/him)	You need to already have pretty advanced client code written before the migration becomes painful
wimleers (he/him)	So I’m really curious what that advanced stuff was.
wimleers (he/him)	And … I’d love you to tell me I’m completely wrong too :slightly_smiling_face:
pwolanin (he/him)	the clients were not advanced really
pwolanin (he/him)	the move from nid to internal__nid alone required changes in lots of places
pwolanin (he/him)	the change of ID and UUID attributes similarly (edited)
pwolanin (he/him)	we also had a little custom code subclassing a normalizer I think
pwolanin (he/him)	we had a mix of PHP and JS integrating that both had to be fixed
pwolanin (he/him)	using it in PHP for data sync across sites, or populating options in forms for old integration using jquery (edited)
wimleers (he/him)	Normalizer subclass → that’ll surely be very painful, but we always discouraged this, and I doubt many people have gone that far.
e0ipso	the move from nid to internal__nid alone required changes in lots of places
e0ipso	I remember this being controversial at the time.
wimleers (he/him)	So it sounds like the majority of the changes was the ID vs UUID and internal__* attribute renaming. And that was painful especially because there was PHP + JS + old jQuery JS. Makes sense.
wimleers (he/him)	I remember this being controversial at the time.Yep. Also the only way to be spec-compliant.
pwolanin (he/him)	I understand the point of moving nid, just was not trivial to find all the places we used it
wimleers (he/him)	Painful once, now smooth upgrade sailing :slightly_smiling_face:
wimleers (he/him)	@pwolanin (he/him) Yep, totally get that! A big codebase, with lots of things referring to it. That’s definitely not eays.
pwolanin (he/him)	yes, other than performance when we want to update 1000 nodes
wimleers (he/him)	Yep, I get that
wimleers (he/him)	You could create a custom resource specifically for that for now: https://www.drupal.org/project/jsonapi_resources
e0ipso	when we want to update 1000 nodesthat is pretty ambitious
pwolanin (he/him)	@wimleers (he/him) we were talking before about options including the subrequests module, or yes will write a custom thing
wimleers (he/him)	haha yeah, because that’s also 1000 hooks fired
pwolanin (he/him)	but need to handle many possible fields int he PATCH
wimleers (he/him)	well, 1000 subrequests …
wimleers (he/him)	:smile:
wimleers (he/him)	I don’t think that’s gonna fly
wimleers (he/him)	I didn’t see the “1000” before.
pwolanin (he/him)	ha, better to avoid it perhaps, but can’t do multi node save anyhow
wimleers (he/him)	So I don’t think @e0ipso would recommend subrequests in taht case
wimleers (he/him)	Right, @e0ipso?
pwolanin (he/him)	doing 1000 with 1 by 1 patch requests is biting us worse
wimleers (he/him)	Also, the Drupal Association folks replied to my earlier question: https://drupal.slack.com/archives/C51GNJG91/p1583252096052600?thread_ts=... /cc @ylynfatt @e0ipso @gabesullice — so … no way for us to know.
e0ipso	you could try to batch 1000 in several parallel requests of N (<1000) (edited)
wimleers (he/him)	doing 1000 with 1 by 1 patch requests is biting us worse@pwolanin (he/him) but at least those 1000 requests fail or pass individually. 1000 simultaneous internal requests … I don’t know about that :sweat_smile:
pwolanin (he/him)	yeah, it’s no fun either way
e0ipso	In any case, I sense a paragraphs-like content model with nodes
e0ipso	(perhaps?)
pwolanin (he/him)	no…
pwolanin (he/him)	this is for chemical inventory management, each node is an inventory item in a space
pwolanin (he/him)	need to e.g. update something about them all, or mark them all as deleted, etc
pwolanin (he/him)	query to build the list might be more complicated than just the space relation
gabesullice	I would use JSON:API Resources + Hypermedia to create a custom/jsonapi/node/inventory_item/{uuid}/flag-as-foobar idempotent route that takes an empty POST. Add a link with hypermedia, then fire off all those requests async, as fast as possible with retries. (edited)
gabesullice	The hypermedia link can update from /flag-as-foobar to flag-as-foobaz as needed or just disappear depending on the state of your system
gabesullice	Use JSON:API Resources to also build the custom listing of inventory items rather than building the query with filter[foo]s (edited)
pwolanin (he/him)	the async requests are also causing issues for us - too many in parallel already
pwolanin (he/him)	we are rebuilding some meta info about the inventory each time a node is saved - doing one by one is causing that to hammer the DB
pwolanin (he/him)	if we could do it all in one go after updating 1000 would be better for performance
gabesullice	respond with a https://httpstatuses.com/202in your custom idempotent resource and throw something in a queue
pwolanin (he/him)	yes… that’s an option. people want immediate updates, however
wimleers (he/him)	look for “optimistic updates”

:four: multiple mutations in a single request cc: @pwolanin (he/him)

gabesullice	Subrequests is the more flexible, more mature module @pwolanin (he/him) Operations is based on the upcoming version of JSON:API which will have an official extension to do what you described. However, it lacks some of the nice features of Subrequests (like selectors for data in the previous operation result)
pwolanin (he/him)	@matt_paz metions https://www.drupal.org/project/jsonapi_operations and https://www.drupal.org/project/subrequests I’ll note that one of my thoughts was to NOT return the full entity in the response potentially do avoid the overhead of loading/serializing them all when not needed. (edited)
e0ipso	@pwolanin (he/him) Subrequests does not assume anything, beyond that Drupal is returning JSON.
e0ipso	it's not even tied to JSON:API.
e0ipso	I is also implemented as an Express middleware
pwolanin (he/him)	yes, I see the that. Not sure there is a way to tweak the PATCH response from jsonapi
e0ipso	https://github.com/e0ipso/subrequests (edited)
e0ipso	You should be able to do what you need in Subrequests.
pwolanin (he/him)	I’m not sure I understand what that is - can be used with Drupal?
e0ipso	@pwolanin (he/him) are you fronting your Drupal with a node app?
pwolanin (he/him)	no, no
pwolanin (he/him)	it’s just Drupal
pwolanin (he/him)	some pages amped up with e.g. a VueJs page instead of Drupal for better UX
gabesullice	@pwolanin (he/him), you might like https://www.drupal.org/project/decoupled_pages to save yourself some boilerplate (edited)
pwolanin (he/him)	hmm, well we only have a couple so far - think I’d rather code it by hand
wimleers (he/him)	(I should’ve commented here instead of at https://drupal.slack.com/archives/C5A70F7D1/p1583250751146000?thread_ts=... — but I see @gabesullice of course already said all that :D)

:five: who's speaking at DrupalConNA?

e0ipso	cc @wimleers (he/him)
pwolanin (he/him)	me, but not about headless per se.
gabesullice	I'll be talking about decoupled application design and how to use hypermedia to shift more responsibility and control back to the back end. https://events.drupal.org/minneapolis2020/sessions/hyperdriven-drupal-be... (edited)
wimleers (he/him)	I’m talking about meta things: https://events.drupal.org/minneapolis2020/sessions/there-be-dragons-all-...
prestonso (he/him)	I’ll be talking about RTC: https://events.drupal.org/minneapolis2020/sessions/real-time-collaborati... (edited)
mglaman	I’ll be talking about Centarro’s pushing of JSON:API https://events.drupal.org/minneapolis2020/sessions/jsonapi-%E2%80%93-cre... (edited)
ylynfatt	Not speaking or able to attend DrupalConNA but will definitely try to watch your talks when they are posted afterwards. Have fun and all the best with your talks. :+1::skin-tone-3::+1::skin-tone-3:

:six: @jibran had asked for someone to review this before the meeting https://drupal.slack.com/archives/C5A70F7D1/p1583231110126700 (edited)

gabesullice	:clap: thanks Yannick!
gabesullice	@wimleers (he/him) I started to take a look at this, but I think you have a comparative advantage since a lot of this touches HAL/REST