Evaluate Orbit.js

I do agree that it doesn't make sense to start from scratch.
At the same time, for a long term success, we should reduce the dependencies as much as possible. Especially when dependencies brings in their own bunch of dependencies which are not under our control.

I suggest we design a clear user friendly API for our client. We can use orbit.js or something similar under the hood though. This can later evolve into a plugin based architecture that helps you swap the transport layer if needed. But having a normalised API would help develop and maintain other parts that depends on the client, which is the 'main' goal if you ask me.

I don't want to reinvent the wheel if we don't have to. I also agree that we probably need to be extra careful with dependencies, especially for something like the base class in the project.

Still learning, but Orbit's JSON:API implementation seems to be pretty Orbit specific - as in it isn't really intended to be used out of the context of Orbit. And Orbit also seems to depend on a pre-defined schema.

Given that, I wonder if where Orbit would be most useful would be a little higher level. This project will still need to have a JSON:API client that can work with a not-yet defined schema. But we could also provide utilities to source JSON Schema data from Drupal (ideally aligning with @bradjones' JSON data/schema work for Core). That would make getting the schema data necessary for Orbit easier. And it could even be formalized as a Drupal Orbit package of some kind.

That's how I've been thinking of this effort - the more we focus on our extensible base (initially validated by creating a JSON:API client,) the easier it can be for Drupal to work with things like Orbit, and other similar solutions that may not even exist yet. Long-term if that allows one of the other things built on top of this to organically become the community standard rather than this first JSON:API client, that doesn't seem like a bad thing to me.

Not sure I follow here, Orbit sounds like it's specific to Orbit. But we want a general client (not Orbit specific). There might be value in studying their solution, but we may need to hack it to make it more general.

Am I following the logic her properly?

Re: #4, Orbit isn't specific to Orbit, and in fact it's maintained by one of the JSON:API spec maintainers so he explicitly designed Orbit to have internal storage that mimicked the JSON:API attributes/relationships model.

Some of the internal terminology is a little different (since, conversely, Orbit doesn't require JSON:API) but when you create a record for storage in Orbit, it is by definition JSON:API compatible and there is a first-class driver for interacting with a remote system in Orbit core.

I'll expand on this a bit over at #3365506: [Meta] Vertical Slice POC → , but wanted to directly answer your question here.

Closing as we've completed our 1.0 release and taken an approach that doesn't involve this library.