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 :)
@joepie91 so, it looks like the actual queries are just normal JSON and not some stupid DSL? (my main immediate annoyance with GQL)
I'll certainly be needing something like this for my own project, knowing me I'll probably go with rolling my own complex thing, but still very interested in looking at yours when you publish.
@virtulis Not even JSON really; just a plain nested object structure (object/array structure for results). So there's a direct path to JSON serialization (and that will likely be the API format once this grows a HTTP layer) but you're also not *restricted* to it, since this sort of structure is representable in just about anything.
Also means you can return any sort of value as a result, custom types included, as long as there's some sort of defined translation on any serialization layers you might be using (which will be a separate library from the query execution core).
So yeah, no weird DSL. I fail to see why a DSL would be needed to represent what's ultimately a bunch of nested objects... might as well just use a bunch of nested objects 🙃
(Indeed this was also one of my annoyances with GraphQL, and how it essentially sabotaged abstracting over schema generation)
