Top 5 Predictions for Meteor in 2016

community
16

This is because Meteor is no longer the opinionated framework it once was! Meteor=npm now.

Don’t worry, Blaze, livedata, etc. will be supported for a long time (no, I’m not affiliated with MDG, but I suspect they’re committed to providing backwards compatibility for a long time for all their big corporate clients). It just won’t be top choice for building large, scalable apps…

…which it never was, anyway! Meteor was always best for small apps used by a limited number of users, it was never meant for building the next Instagram or Facebook. (Whether you draw that line at 100, 1000… 100000 users, it depends on how much $ you want to spend on hardware/memory – and time optimizing your app).

So, while I get your nervousness about what’s going on, rest assured your project is built on fine technology, things are just changing very quickly, for everyone. I bet you will be better off upgrading an old Meteor app than upgrading an Angular 1.x app.

17

Working on the bleeding edge means sometimes you will get cut. I recommend being upfront about the state of Meteor before suggesting it as the main stack for a project, then you can deflect potential blame down the road when things change.

18

I have apps in Mongo too. The problem is that when the solution calls for a relational database and other frameworks offer better built in support.

There are many relational vs non-relational debates already. RethinkDB offers much better relational support than Mongo.

1 Like
19

@vonwao

I don’t have a ton of experience with RethinkDB (only 3 prod apps using it for ~6mo) but here’s my take:

TL;DR RethinkDB seems to be Mongo done right, plus realtime specific features. The entire architecture is based on a push philosophy rather than a request/response philosophy.


> I'm curious why you think Rethink is much superior to Mongo.
  • Joins between tables at the DB level (one of the first for noSQL DBs)
  • Changefeeds make realtime easy and more efficient
  • Easier for devops to maintain
  • Really nice ‘functional’ API shines with comples queries (mongo is nice too but complex queries are a mess)
  • Hindsight allows them to fix mistakes made by other noSQL databases
  • They run Jepson tests against each release while in development
  • The company seems to be very forward thinking while MongoDB… not so much

How do I know Rethink is not the “shiny new thing” that everyone is attaching to?

A lot of the hype probably probably is. However, it does solve a lot of problems well (mainly Realtime and joins).

I heard Rethink is working on a more granular oplog feature,

I haven’t heard this yet but their mechanism for realtime is using a ‘changefeed’ that watches queries. The entire database was designed around this in mind so that the DB knows at a very low level when a changefeed has changed. From what I hear it’s a lot more efficient. Unlike the raw oplog, this allows anyone to get realtime updates without the livequery system like Meteor. You just need some kind of pubsub to send results to a client.

They’re also working on a software layer that sits in front of RethinkDB to give you basic Firebase like auth/permission things and eventually GraphQL.

… making it easy to gradually upgrade my app… but DB is different, you have to fully commit to one or the other.

It was actually fairly easy to migrate an app from MongoDB to Rethink. I had a client that was scared by the recent bad press of Mongo and wanted to switch to something else. Rethink was one of the ones that made migratio easy (compose even has a converter). If you’re app level code is using a facade like Post.update(docId, data) then it’s easy to swap it over. Making the primary key _id instead of id prevents a lot of headaches.

To be fair, I don’t understand the critiscim of Mongo design decisions to make a great decision. I’m only using RethinkDB in new client apps to prevent future issues. This Quora post is a great summary of complaints (valid or invalid).

This is a great podcast explaining what Rethink does and how it differs from other noSQL/SQL databases:

http://softwareengineeringdaily.com/2015/08/19/push-databases-with-rethinkdb-ceo-slava-akhmechet/

2 Likes
20

I truly hope Meteor becomes the foundation on which to build JavaScript apps on. Having to reinvent the wheel, gather parts, compile, and everything else with build tools or use boilerplates is currently a nightmare. I would love to see Meteor take care of installing NPM packages, compiling, connecting databases, models, views, view refreshes, deploying and minifying, and everything else. The JS community really needs a standardized way of doing all of this that makes sense and is easy to get going.

6 Likes
21

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.

1 Like
22

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.

13 Likes
23

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.

3 Likes
24

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.

1 Like
25

You are right, react-native team does not market it as production ready.
IMHO it’s already better than cordova, which calls itself production ready.

1 Like
26

I like those predictions. There catches though.

  • 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. :sweat:

  • 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.

3 Likes
27

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.

3 Likes
28

Good to see you working on that.

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 :grimacing: ,he uses golang based database(something build inhouse , kudos to kadira team, they aare awesome!)

1 Like
29

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.

1 Like
30

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 :wink:

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).

1 Like
31

Love the work you have done for Meteor’s ecosystem. Are you looking for any collaborators for Mantra?

3 Likes
32

Of course yes. Let’s me work on the initial draft :slight_smile:

3 Likes
33

But how without observers ?? I need observers!

34

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.

1 Like
35

Great Post @arunoda. Recently starting using Mantra and we lovvvvve it :slight_smile:

1 Like