Getting Started with API Extension Building
I've been using
AshJsonApi pretty much since I started with Ash. My goal was to make some improvements to it and continue on.
Long story short, I'm integrating with a... let's just call it "legacy" system and for a number of reasons—some sensible, some not—I'm going to need APIs that better resemble the existing infrastructure. I can't even really call these a "standard" so much as... I don't even know.
Additionally, there's a team here looking to standardize internal service communication using gRPC.
Both of these require creating API exensions, I presume. The legacy JSON one should be the easiest starting place. Where is the best place to start (besides just diving into the source, which is going to have to happen anyway)? I didn't see an obvious guide (although missing something that already exists would be par for the course).
And any tips for where to start to get something quick and dirty out quickly? (The "legacy API" would basically but like... "spit back the resource as JSON" and "deserialize a JSON object" in most cases.)4 Replies
There isn't a guide for it, and how you tackle it depends on a lot of factors
You don't necessarily need an "extension", per-se
Its all just going to be a matter of how concrete or how abstract it is.
i.e you could just write some controllers, w/ classic deserializers for input and serializers for output etc.
Depending on how many endpoints you're modeling, and how they work, that may very well be the most economical solution
I would ultimately like to use a variation of the sort/filter/include logic. The APIs here have varying degrees of support for it (every bloody service in this web has their own take on it though).
Perhaps the correct first question is: what does building an extension do for me? Should I even pursue this? (I mean, I feel like I should for gRPC but perhaps it's genuinely overkill for the other use case beyond being educational for both mucking with JSON:API more and working on a gRPC layer.)
Extensions in Ash don't actually do that much
All that extensions do is act as data extensions for your resource/domains
Essentially allowing you to do what we do for all other things and colocate the data that drives some piece of logic with the resource.
Everything else is just good old fashioned code, which, 99% of the time is operating generically over a resource, resources, domain or domains etc.
And using introspection functions to ask questions about it
So you might generate protobufs based on resource introspection, and use a resource extension to customize that process, for example.
Okay. Sounds like I can just muddle my through it, mess around, look at that's there and make some cool stuff, lol. If nothing else it seems like I'll get a better handle on the introspection piece. I feel like most of why I have cared about that at this point has been taken care of, more or less, for me in things like the JSON:API extension.