Reading through some of these comments I agree: It is probably a good idea to add in a 'why to use' section on the repo. The purpose behind this was that I found it cumbersome to work with dataets in JavaScript so this framework lets you pull them into a schema that has metadata to handle relationships between tables, aggregation methods, sorting and filtering. As for competing frameworks: I have seen some of this in other larger frameworks but I build this out so I can work with data in JS without pulling in monolithic data visualization libraries.
If only there were some kind of... structured query language of sorts... maybe call it SQL. And there will be relations... with data... and the data will have schemata, so you can make certain inferences and assumptions... oh, if only someone would create this!
I can see a use case in my current work. We're building a dashboard visualisation for our product.
I'm writing the REST API backend for it - and trying to make that API as easy to easy to use for the front end (inhouse customer) as I can. However, I'm finding that I'm writing a lot of endpoints that are variations on the same data.
We will circle around, identify the common patterns/variations and consolidate a bunch of the code. But something like this, that facilitates sorting, grouping and filtering on the front end, could be useful.
15 comments
[ 10.2 ms ] story [ 559 ms ] threadWhat is this for? Talking to a REST API? Serializing and de-serializing data? Acting as an in-memory DB? What library does it compete with?
I'm writing the REST API backend for it - and trying to make that API as easy to easy to use for the front end (inhouse customer) as I can. However, I'm finding that I'm writing a lot of endpoints that are variations on the same data.
We will circle around, identify the common patterns/variations and consolidate a bunch of the code. But something like this, that facilitates sorting, grouping and filtering on the front end, could be useful.