Open mdconaway opened 6 years ago
@mdconaway Thanks for posting, we'll take a look as soon as possible.
For help with questions about Sails, click here. If you’re interested in hiring @sailsbot and her minions in Austin, click here.
Hey @mdconaway, we've moved this proposal from Waterline to Sails (balderdashy/sails) to keep a closer eye on updates and boost exposure. I appreciate the time and effort put into this case and welcome any further updates from the community.
Waterline version:0.13.1 Node version:6.2.0 NPM version:5.5.1 Operating system:Ubuntu 16.x
Hey guys,
This is more of a suggestion than a concrete issue!
Recently, my team and I have been streamlining a lot of our clients, policies and other internal services that we develop for our growing colony of sails based servers. As one of our efforts to make our ecosystem more DRY, we developed a common JavaScript module called "json-forge" that we now use heavily in our Ember applications, and in our policy and service modules within our sails servers.
Among other things, this new json-forge now allows us to transmit complex data types from clients to servers in a reliable manner. (Anything from mongo Id's to date objects)
I just open-sourced the simple library here: https://github.com/mdconaway/json-forge
Previously I have dug through some of the query-forge code in waterline and I know it is performing some operations that might be more intuitively handled through a forge instance created using this new library.
Currently json-forge is lacking some features that would be needed to fully reduce the stage2 and stage3 query forges, but I think anything needed by waterline can be added to the json-forge library to enable the recursive forge operations to be configured in flat maps instead of large recursion functions and switch statements.
I would love to enhance the capabilities of json-forge to meet the all waterline query forge requirements, but will need input from the waterline team to make sure the features are fitting with all of the low-level concerns of waterline itself.
One thing that I know will be necessary will be expanding "types" in the case of [] => $in: [], and { a: b, c: d } => $and: [ { a: b }, { c: d } ] , but I do have some fuzzy ideas on how to accomplish this in a configurable manner.
Additionally, I envision sails/waterline being capable of generating many json-forge instances to create unique compressors and maps for each model represented in a project.
Let me know what you think! I would love to collaborate on this.
-Mike