long, project announcement
#ProjectToot: I've finally completed an initial version of dlayer, my graph query library; it's kind of like GraphQL, but without the Facebook, without the weird DSL, and without the weird monolithic "design your whole API at once" design.
Instead, it's an extensible, modular design; an API is composed at runtime of one or more modules, which may or may not be aware of each other's existence, and extend each other's types with extra attributes as well!
This makes it much more useful for collaborative projects where different people might design different extensions for a (semi-)standardized API structure, as well as organic development, rather than GraphQL's assumption that you have one "team" that "designs the API" - which I'm sure works great in a startup, but *sucks* for community projects.
It shares the same useful property as GraphQL does, however; it lets you very easily assemble a coherent API out of many different, inconsistent data sources, regardless of whether any HTTP is involved. (There's currently not even any HTTP anything!)
The current implementation is in JS, but the design (and extensibility method) are simple enough that I see no reason it couldn't be ported to other languages!
Here's a rough example of how it works, with some dummy "modules" and data: https://gist.github.com/joepie91/a01a59485cd399324e37e3c6f00ebf78?ts=4
I need to sleep now, but I'll post a link to the code and some initial documentation tomorrow, probably. Let me know if you're interested in testing this out though :)
re: long, project announcement
@joepie91 congrats!
does this also fit the db-backed CRUD thing that GQL probably does? (haven't looked at the impler-side of it much, just consumed an api or two using it rather naively)
i'm mostly interested in the "here is my db layer, i would like to expose an api for it, but with added modular quirks as i see fit" usecase, and `await $getProperty` feels like a lot [of cognitive load & such] to spend for that. (this is not a complaint but it is something to keep in mind)
thinking of:
app logic enforcement (js snips overlayed over the db passthru layer) crossover query api dsl
is that possible with your thing?
re: long, project announcement
@ckie It follows the same basic model as GraphQL, in that each property of a 'type' is specified independently as a 'getter', and you may bring your own cache layer to avoid repeated evaluations.
The expectation is that most dlayer APIs will be some combination of auto-generated types and manually-specified getters, but this is left unspecified; I do also separately have an abstraction for quickly building out multi-data-source types.
A similar abstraction could undoubtedly be built for eg. a known database schema, and leaving some room for custom properties, overrides, and so on. But that's all "bring your own" - the only job of dlayer is essentially the query scheduling, and it's relatively unopinionated about exactly what it's querying against.
(The $getProperty thing specifically is for 'internal queries'; that is, to evaluate one property of an object you must first obtain the value of another property and do something with it. This lets you go through the usual evaluation cycle without executing a full-blown query from within a getter, which might then require hardcoding API structure and mixing concerns.)
Hope that answers it?
