My Story: Why Meteor is Awesome!

community
1

I Senior developer and went from stack to stack (C, PHP,Java,Ruby, Python then NodeJS)

I have tried many framework and some the most complex Zend Framework (PHP stack)

and stumbled upon Meteor 4 years ago when it was just under v0.x and I was searching for framework and trying them, there was two major good ones MeteorJS and ExpressJS.

I fell in love with Meteor since it was simple intuitive and had that instant real-time feature…

But these last two years I am fully on Meteor and no more on PHP or Python.

and I love it!it has everything that’s need to build a good app, from the amazing accounts package to the new wonderful Apollo/graphQl thing to the integration with many other front-end framework.

It is just amazing!

What’s there not to love?

6 Likes
2

Yes, its better than ever - just needs to fit one’s use case
For greenfield projects (for me) its come to a choice between monolithic (Meteor) and fragmented (‘serverless’).

Interesting that whichever way I go, Apollo is always there too :slight_smile:

1 Like
3

I totally agree with you :slight_smile: and yes Apollo is awesome and part of Meteor so we love it :wink:

4

What’s so special about apollo/graphql?
I never understood how it should make things easier from a developer point of view.

2 Likes
5

It is awesome my dudes :smiley:
well because it has an abstraction of the database type and logic so you can use any type db like mysql or Cassandra or whatever… and it is not tied to a specific stack! so you can use it with whatever you want :wink: and pretty easy to query too.

6

It makes my projects more organized. All the relations from the DB are in one place and simple to write. Then on the client I say “give me this json”.

I was a graphql/apollo hater before I tried it but now I love it.

1 Like
7

Does this mean, that you are usually working with multiple databases within one project?
Otherwise I always see the two additional layers, increasing the amount of bugs.

1 Like
8

Have you encountered any issues when fetching from the tree/query like this query depth: friend-of-a-friend-of-a-friend type of query…? or when creating an API with GraphQL or Apollo? …and handling rate-limiting, authorization, authentication…etc and all API related functionalities are hard to implement and wrap around the brain.

{
 me {
     firstname,
     lastname,
     friends {
          firstname,
          lastname,
          friends {
               firstname,
               lastname,
               friends {
                     firstname,
                     lastname,
                     friends {
                            firstname,
                            lastname,
                            friends {
                                  firstname,
                                  lastname,
                                  friends {......}
}
  }
     }
        }
           }
               }
            }

Also realtime subscription still requires some implementation at every stage and places you need to. Meteor makes this a breeze and currently Meteor shines very well in terms of pub/sub performance when used with Redis (redis-oplog). Meteor brings ease of development to everyone, and not even GraphQL/Apollo have been able to match that. Until they do, Meteor remains my go-to with all the right optimizations. Using multiple data layer shouldn’t be my main concern unless the application requires it, and the latest announcements for Mongo 3.6 with Change Notification and other important performance optimizations will make Meteor the darling again for everyone.:blush:
80% of apps don’t currently require Facebook-like performance to stay relevant, so not all app requires GraphQL or Apollo. I usually don’t jump at every technology because Facebook wants everyone on it. I use technology to achieve happiness during development for developers and production for end users :grinning:. Again, have you seen Relay Modern? - It’s wobble jumble :sweat_smile: not fun to use. I believe software development should be simple and enjoyable.

2 Likes
9

No but it means you can use a cheap advanced MySQL database which well known for performance and used in a lot of apps!

10

Hmm, but you do not need apollo/graphql for that?

2 Likes
11

Well, I think under the hood meteor and graphql are doing the same thing for that friend of friend of friend query right? It’s just a matter of how/where you organize the code. They’re both still doing the same mongoDB query at the end of the day.

Meteor methods === apollo mutations or queries. They’re functionally analogous… you can use methods to do CRUD and you use mutations/queries to do CRUD.

In terms of security, it’s again not really any different than meteor. You’re just writing/organizing the code differently. You write resolvers for each field, and inside that resolver function you have access to the root document (the friend) and the current user record, etc… so you would do some authentication work there potentially (if current user is in role X, then don’t return anything, if they are in role Y, then do this). In meteor you write virtually the same if/then statements either in your publications or your methods… graphql gives you the root, args and context right away, so you may even have to write less code to do authentication (a couple less find statements)

I user apollo + meteor. So I have the meteor accounts system.

I’m not against meteor or implying it’s obsolete, just saying I’ve enjoyed using graphql/apollo. And I agree that there are some things in apollo that seem over-the-top complicated. I spent at least a day on a few simple CRUD issues.

But overall, I find my projects are more organized and I write less code with apollo + meteor vs just meteor.

2 Likes
12

I love querying GraphQL but I’m still waiting for a way to set it up which doesn’t involve 17 “easy” steps.

3 Likes
13

GraphQL gives enormous power to clients. But with great power comes great responsibilities :spider:.

Take a look at some of my concerns about GraphQL Security here - Timeouts, Maximum Query Depth, Query Complexity, and Throttling -
All of which are hard to implement perfectly.

2 Likes
14

Good points. I wonder if somebody from the apollo team could chime in about how they (or graphql community as a whole) intend to tackle some of these issues.

It seems like most of them are relatively easy to solve once a spec is agreed upon. Like adding a maxDepth field to a config somewhere.

But, all good points you bring up. For sure. Thanks for the link.

2 Likes
15

Meteor has made me lazy .

1 Like
16

Meteor has made my life easier. It’s released time which I’ve spent on a deeper understanding of the tech I use everyday. That’s a virtuous circle: better understanding -> better product -> fewer bugs -> more time -> more research -> better understanding …

8 Likes
17

The client query language is a big selling point. Instead of doing

“get me X from collection A, and Y from collection B, then pull out the fields and use them to populate a model”

you can do

“give me only these fields in this exact object structure”

You can query multiple data sources at once, without having to know or care where they originate from, but also how you want the data to be structured

2 Likes
18

Well Meteor is not that awesome . MDG needs to get a lot of things together

19

Like what? be more explicit…

20

Why don’t have there own Router ?