Long time no see!
- Improved security and filtering for body exposures
- Various consistency fixes like better error messages.
- Added support for a new concept: $postFilter
What’s next in Grapher?
Grapher is rock-solid. There are still many things to be added but this package, I can agree with that, but it already achieved, with great elegance, its purpose, it has matured. We are using it in every project we have. It proved it’s solidity.
So I am going to put a hold on new features and only focus on bugs, refactoring, documentation, code documentation, code quality and recipes on how to use this framework.
It added the essential layer over meteor’s data system that allows us to bring order and structure into data fetching. Besides that it innovated new ways of fetching relational data optimally in a NoSQL database. Something that did not exist and still does not exist (at least not open-source)
What’s next overall?
The next big problem in Meteor is the fact that if you want to create a CRM with lists, pagination, filters, sorts, forms. You have to write your stuff from scratch. And after that, you would like to re-use it, so you end-up with a mess. And we all re-invent these wheels every day. I come from Symfony2. And I’ve used a package called SonataAdmin. I was building CRUD’s and forms in minutes This is not the case with Meteor. It’s hard to do it perfectly and time-costly.
Grapher is now offering the essential backbone to do that. And we see this new “CRM builder” as the next stepping stone into the evolution of Meteor framework. I will be finishing the design plan for such a builder within the next 2-3 months. It’s more challenging than Redis-Oplog and Grapher put together. It will be using material design, grapher, react, and still pondering about uniforms.