I am envisioning to start programming a solution (one of them, if I get the contract, could lead to paid consulting, I am also open to share the code we will develop, because I wish to develop a datadriven site building method, such as that, among other advantages, it could be driven by a drag-n-drop wysiwyg desing UI) that would include: Meteor+Svelte+Grapher and a reactive DB.
I do not know much about these components:
Do I need Redis as database, rather than MongoDB, to make Meteor using oplog and be really data display reactive among different users?
Is it right that Grapher could be used as the request manager in that context?
Any comment on that stack selection? (is it enough, coherent, complete, etc.?)
Although not exactly the same topic and forum section, I am noting that I am looking for partners/consultants or networking for such technology cocktail who could be as close to Montreal, Canada as possible, or where ever they are.
Chiming in here as I use a similar stack of Svelte + Meteor + Grapher.
Answering each point:
Meteor requires Mongo to function in most cases. It’s a core architectural dependency that’s a pain to decouple (you can try it, but often it’s better to use Mongo if you can manage with it). Where Redis plays a role is with helping with concurrency and handling larger numbers of subscription clients. With redis-oplog, you get a drop-in replacement to use Redis to manage your pub/sub updates for publications/subscriptions in a much more efficient manner, while still using Mongo as the primary datastore (as opposed to having to use an inefficient memory and CPU intensive implementation called a mergebox to handle subscription updates). Trust me this is a game changer to quickly make your application performant.
I’m not quite sure what you mean when you mention request manager in this case, but Grapher’s main advantage is that it lets you define relationships between collections in a NoSQL schema, so you need to use a slightly different query syntax to retrieve data (Grapher does a lot of work to make it easy to structure a nested query in a single retrieval)
It’s hard to say whether this is the perfect stack, but I can share that I prefer this stack as I find it extremely efficient to build a robust and performant solution with a very small team. The nuances of what you want to achieve with the UI may or may not be feasible with what Svelte can do today, but from my experiences, for most scenarios its sufficiently capable.
There’re a lot of opinions of what’s the best stack to build with, but my 2 cents is it comes down to what you value most. As I’ve shared, I value developer efficiency most so I prefer using a stack that lets a very small team manage the development.
Meteor is isomorphic so devs have to be full-stack and build the front-end and backend. Yes, the downside is that you need to have better communication within the team to avoid duplication of backend code, but that’s easy to manage with few people.
Svelte is super nice cause of the learning curve, and simplicity of its syntax. Having used Blaze, Vue and now Svelte with Meteor, Svelte to me feels most aligned to what Blaze was leading towards if MDG has continued to develop it up. Vue is nice, but Svelte is just way more responsive and performant. Warning though: it’s a bit of a bitch to get up and running with PostCSS, but once you get it configured it’s a breeze.
Grapher is great when you have a lot of relational data retrieval and want to reduce query overhead in retrieval. And it’s really performant, and I loved how efficient it was to setup complex nested queries, and also enforce strict access rules within exposures through firewalls. It was really straightforward to enforce acl logic this way. Not to mention the simplicity with which it lets you setup indexes to make lookups a lot quicker and easier. All-in-all a fabulous tool to complement the Meteor stack for making enterprise applications IMO (as a lot fo enterprise data is relational).
Do ping if you want to chat or need any help. We’re based in India, but work with folks the world over on stuff so it’s a regular part of what we do anyways.
Good work @diaconutheodor on the x-framework, ambitious as usual. It seems to me like a cross between FeatherJS/Meteor with a personal touch. Personally, I’m still not a big fan of Graphql, but hey, it has its merit and use cases.
Do you think the existing libraries you created for Meteor/NPM would still be maintained? Lot of folks here (including myself) love your work, so I’m really hope so.
Thank you @alawi . I tried to learn from Meteor, Nest, Feathers, Symfony and extracted what I think is the best solution to have the same Meteor’s beauty and elegance when it comes to isomorphic databases and live-data that just works.
Regarding Meteor packages, yes, they will still be maintained. I always kept an eye out for critical issues, and will likely do so in the future. When we can no longer maintain them I will pass the torch . I understand how dependent the Meteor ecosystem has become on redis-oplog and grapher and will not abandon
Honestly, I tried doing this (Kaviar) in Meteor , because I love this framework so fucking much. After Tiny bought Meteor I was in discussions with them pushing the fact we can rejuviate it and what would be the steps to do so, I wanted redis-oplog to get merged officially. These guys showed zero interest. I felt discouraged, I thought being such an evangelist of Meteor my words and advice would weigh more. This kinda forced me to pursue my vision with a framework that allows me to do so, I had to reinvent many wheels and jump many hoops before Kaviar took this shape. But I am confident that this is the future.
Kaviar works with Meteor, because Kaviar is NPM. But it has its own “opinions” about Security, Live Data & others. A seamless integration, while possible, is very unlikely to be of interest.
Sounds like a reasonable step forward to me, I think Meteor should have various pub/sub-strategies (redis one of them, but we could also have cloud-based strategy) with a facade API, another interesting approach would have been an independent hosted Redis pub/sub SaaS with dashboard for Meteor apps, similar to Monti.
Anyway, maybe it was a bit early for the Tiny team they had a lot on their plate at the start. Anyway, I’m confident you will be successful whatever path you decide to pursue, and would love to see Kaviar mounted on Meteor build (among others) as well since it NPM.
Thank you for clarifying @diaconutheodor and keep it up, JS is fortunate to have you!
. I understand how dependent the Meteor ecosystem has become on redis-oplog and grapher and will not abandon