Will atomic operations be supported here long-term?

[acorncom]

Hey @lindyhopchris, appreciate all your hard work on this (and the previous version as well). Was curious if the atomic operations extension to the spec (https://jsonapi.org/ext/atomic/) is on the radar as this gets built out? Poked around a bit and wasn't seeing anything mentioned, so thought I'd ask. I'm contemplating a long-term stack migration a client may need so thinking through our options there.

Thanks!

[lindyhopchris]

Hi! Thanks for flagging that up, I hadn't realised that they'd actually published that as an extension.

So the short answer is yes, because I have production APIs where that functionality would be exceptionally useful.

The longer answer is it slightly fills me with dread because I've just spent a considerable amount of time sorting out the new package, and issues are already starting to build up! I'm going to need help going forward to add significant functionality like that extension, so my question for you would be - if it's important for you to add, is it something you'd be able to collaborate on?

The only problem I foresee with it, is I've just moved all the validation to Laravel form requests, to make things more Laravel-y, which is a change I wanted to make because some of the feedback on the previous version was that it had too steep a learning curve.

The problem with those operations is we'd need to validate each operation in turn... which means access to the validation rules for a resource. Which are currently in a form request, which Laravel automatically validates when resolving from the container. So we'd probably have to extract the validators to a separate class again. Which feels like I've wasted a load of time adopting form request, d'oh.

[acorncom]

So the short answer is yes, because I have production APIs where that functionality would be exceptionally useful.

Understood and same.

The longer answer is it slightly fills me with dread because I've just spent a considerable amount of time sorting out the new package, and issues are already starting to build up! I'm going to need help going forward to add significant functionality like that extension, so my question for you would be - if it's important for you to add, is it something you'd be able to collaborate on?

Fully understood on it filling you with dread, it's going to take some work to revamp things to account for the new wrinkles that adds. As far as something I'd be able to collaborate on, I would very much like to. Sadly, although I see needs for it on various client projects, I don't have a burning need for it and things are pretty busy at the moment, which means I'm afraid I don't have the time to give this the focused attention it would take 😢

[lindyhopchris]

@acorncom no problem. I can definitely commit to doing atomic operations at some point in the future, just can't guarantee when.

Out of interest, you mentioned when opening the issue that you're thinking through options. What other options are you looking at?

[BenWalters]

@lindyhopchris I know you've stated that you cannot guarantee when you might be able to deliver atomic operations, but figured I'd ask since your last post was back in Feb. Is this on your radar/likely to be delivered in the foreseeable?

We've got a situation where I think atomic operations is the answer. I probably have a solution but it has drawbacks that I'd rather avoid (goes against spec/naming conventions are broken, etc.)
Thanks!

[lindyhopchris]

@BenWalters thanks for your question. I'm also keen to use atomic operations. However, as my open source time is pretty limited at the moment, I'm only planning to implement them once they have definitely been added to the spec - i.e. JSON:API 1.1 is tagged.

Basically I don't want to spend the time dev'ing it for it to then be modified before being tagged. Even if I dev it, I wouldn't want to tag this package with it until it was tagged in the spec. Hope that makes sense!

FYI it will be quite a big refactoring. This is because I went with Laravel form requests when implementing this package, as I wanted to use standard Laravel conventions as much as possible. The problem is that couples create and update operations to the HTTP request. So basically, I'm going to have to separate that out to implement atomic operations.

I'll be keen to do the work once they tag JSON:API 1.1, but I just can't afford to spend the time doing it when I don't know when they are going to tag atomic operations.

[Westie]

In the mean time, I've put together a really hacky controller that can be used to implement a subset of the atomic:operations spec.

https://gist.github.com/Westie/9dbdc82468c25dc4567e6d89f75036d7

For clarity, this is just essentially just a mapper for the actions traits

[lindyhopchris]

Update on this: JSON:API v1.1 has now been tagged, with the Atomic Operations extension in it.

It is a priority for me to add this to Laravel JSON:API - I need to use it in production applications as much as everyone else here who is keen to use it! Plus also "How do I do multiple operations in a single request?" is probably the most frequently asked question on Slack!

I need to be honest about my time at the moment - that really is the limiting factor! I've moved to a job in an organisation that doesn't use JSON:API, so I have no work time on this package. So anything that needs doing is entirely in my free time (though will still happen as my personal projects all use JSON:API).

Atomic Operations is a big refactor - because of the current coupling of the implementation to Laravel form requests.

So TLDR: I will get to this, please be patient and understanding 🙏

[atapatel]

@lindyhopchris appreciate your afford towards making this beautiful package.