Joins, ok, I guess I worked with noSQL long enough I don’t miss joins that much. But it does make me wonder, is Rethink fundamentally different from every other DB? If not, what makes it fundamentally better? Or, on the flip side, does their implementation contain "leaky abstraction” that will encourage me to write bad/inefficient code? Like if I try to combine SQL and noSQL paradigm, will I just shoot myself in the foot?
I’m just playing devil’s advocate, I guess I need to listen to that podcast to give an educated answer.
But, so far aside from joins and “Changefeeds make realtime easy and more efficient” which sounds like the same as oplog+livequery… it smells like a lot of hype.
As always, i think Arunoda is spot on.
MDG started as a full stack framework who wanted to fund his work trough hosting.
They developed the framework, it was brillant (albeit a few problems), but then they had to start making money, and so they put 90% steam on the hosting solution development. It took them loooong time, during which there was no progress on the JS framework and the JS world moved on.
At a point, i guess they decided that it was not worth it to continue to develop a framework that was not ubiquitous enough (remember their goal is to become the new Java EE !), and which was starting to lag behind the Facebook and Google offerings.
So i think they have changed their plan completely and that the JS framework is pretty much abandonned.
MDG then becomes an hosting company, which offers some sort of “distribution” of up to date JS technologies, presented in a “batteries included”, easy to manage, one line install.
I understand their move, but i’m not sure i’m sold on that.
I see Meteor as the low level OS for rapid web development, which offers hosting and support as a revenue stream for MDG. Not a hosting company with one click installs. I’d much rather develop a react app on Meteor, than build it from scratch with build tools.
DDP is good. Microservices is nice. But I don’t think that’ll be a trend in 2016 for Meteor.
We may not see much use of DDP servers in other languages.
Meteor module system wont work like the rest of the ecosystem – theres no entry specific entry point. This probably means that building an distributing meteor package through npm will still likely be incompatible with the rest of the npm world. Possibly – I’m not entirely sure about this, but it seems like a problem
User accounts is intimately tied to both Mongo and Tracker. I tried separating the two and it as a nightmare. So good luck with that.
The infrastructure prediction is interesting. Its definitely the direction I think they should go as a company. But this would involve a pretty big pivot for them. The would need to start thinking about how to support different databases in the build tool, and the deployment process. They’d need to make user-accounts database-agnostic. They’ll need to separate minimongo from other mechanisms. I’ve thought about building an app on top of meteor but ditching nearly every core package. But its a pain in the ass from the very start. There is no entry point for the module system. What if I want to use some fancy webpack loaders for loading inline svgs? How do I start and stop my RethinkDb instance with the local instance of meteor? Then deploying… Too much work and not enough help. I may as well just do it all myself.
We have actually been working on this: https://github.com/cortoproject/web. This package contains a light weight DDP server for C applications. Node / Meteor / MongoDB is a pretty heavy stack (my hello world Meteor app uses no less than ~270MB RAM). Our server (1.3MB RAM) is better suited for resource constrained environments. C++ and Python support are work in progress.
The Meteor stack as a whole is not designed for microservices, though:
is IMO totally conceivable. Using DDP for microservices that exchange data in realtime is I believe better than writing a custom protocol from scratch. I would applaud any effort that furthers this use of DDP.
i think meteor is good to start of . but as you grow start delgating work to other stacks via ddp or some other solution (GRPC sounds nice, but no support in meteor). and i think the meteor community shoould embrace other stacks.
As a side note: Isnt C harder to code for (server) while golang enables faster iteration(via faster build times) and is simpler. I saw some repos on while stalking on @arunoda 's github ,he uses golang based database(something build inhouse , kudos to kadira team, they aare awesome!)
That’s a good idea on the Transport. But we need to have a schema, which does standardize the API and document it.
with HTTP, REST is a good solution, for others I believe GraphQL is a good solution. I think it’ll use something otherthan JSON and use protobuf(or similar) for server to server communication.
I won’t argue that. However, with Corto I definitely went out of my way to “ease the pain”, and provide an almost meteor-like experience that would hold its own against golang (example).
The most prevalent reasons I picked C were:
low footprint and excellent performance
it is most easily imported into other languages (C++, JNI, Python/C)
we want to avoid garbage collection in infrastructure components where we can
Once the Python & C++ bindings are done you’ll be able to use the DDP server from those as well. golang is not on my own development horizon yet, but would be an awesome contribution
I agree. I’m fine with JSON though if it’s generated from a strongly typed source, and is validated “at the gate” by the receiving server against (a potentially different version of) the model. In such a setup JSON pretty much achieves the same benefits as protobuf (albeit a bit more bulky).
Meteor will become much closer to the JavaScript ecosystem.Starting with Meteor 1.3, we’ll be able to use NPM modules very easily with Meteor. We could use NPM modules from the very early days, but with the new module system, building a Meteor app will be closer to building a normal Node app.Also, we’ll starting to see the use of NPM modules instead of Meteor packages.
,he uses golang based database(something build inhouse , kudos to kadira team, they aare awesome!)
