Apollo and GraphQL are specifically targeted at solving the problems people experience with REST.
3 Likes
GraphQL is a query language with schemas, batching and is supposed be used with a single endpoint, very different from REST
MDG has been specifically hell-bent on NOT duplicating work, thatâs why the stack is changing so much
1 Like
I think if you looked at Feathersâ solution more, itâd make sense. REST isnât the problem, beyond the fact that itâs not realtime. REST been well-accepted for some time, especially since you donât always need a realtime connection. Use realtime when you want to (e.g., make a socket connection) and use HTTP when itâs more appropriate for the use case.
The service abstraction leaves the transport as an implementation detail. You really arenât even aware which youâre using when youâre querying in the client (beyond instantiating the client, which you do specify the transport in 1-2 lines of code). I probably should have clarified that, with feathers + websockets, you can subscribe and receive realtime changes to any of your services, and update the UI accordingly.
Comparing feathers client querying interface, it seems to be reminiscent of the old Meteor.collection API, while also achieving the level of functionality. You have to say, the apollo client looks a little more complex when compared to the old interface and there are already other frameworks achieving Apolloâs purpose. But thereâs nothing really wrong with that, I suppose. Angular 2 is still a thing and I donât see why theyâre bothering (a little late to market). Itâs probably just not the most efficient use of resources, especially if youâre going to build on top of React anyways, why not also build on top of feathers.
very well saidâŚ
thanks for reminding us that as long as it work for our needs then why worry about the future =)
âI donât think youâre doing your job as a programmer.â not sure this kind of comment has a place in this forum⌠âcriticize ideas, not people.â. Iâll let your read the forum rules again and think about the way you engage people here. I donât remember attacking personally anyone.
As for the rest I started writing a long, thoughtful reply which I ended up deleting halfway. Meh why even bother at this point
Hi @taken, Sorry, youâre right, I was more abrasive than I needed to be. When I say âyouâ I mean âany person in generalâ. We view a software application a kind of machine, and we use packages when building our machines if it looks like it would save us some time. But often the package is only an 80% solution, and to get the machine we want we need to write code to address those shortcomings or to workaround undesired behaviors. Thatâs all I meant. Ultimately we have a machine to build, and weâre going to build itâwith or without someone elseâs packages.
So please, do continue with your post. Maybe we can assuage your fears because, as I mentioned, weâve been running on Meteor since version 0.6 and have worked through a lot of issues, and on the whole itâs worked out pretty well for us.
If a package gets abandoned, yes, thereâs a chance that your app might break when you update Meteor i.e. from version 1.0 to 1.1, or whatever. Thatâs happened to us many times. But there are several ways to deal with it. Often the problem affects other developers too, so someone else in the community may fix it with a pull request or else publish what you need to do to patch it yourself. Changes between Meteor versions are well-documented, so often you can research the error and find out exactly what needs to be changed i.e. a deprecated function was finally removed, so you need to make a change to use itâs replacement. Or it could be a syntax change in a mongodb query.
But I understand that not everyone has the same tolerance for these kinds of disruptions and uncertainties. So itâs always possible that some more stable framework is a better choice for your particular style. Weâve been operating in this environment for so long that the churn-rate feels normal. Web application development is like drinking from a fire hose.
2 Likes
Break things and move fast.
I think MeteorJS is moving fast, and also actively & positively embracing the ecosystem, integrating with webpack, react (native), npm & many other very great tools.
Meteor is evolving towards the right direction and in a fast pace with a community of high talents, I believe Meteor has a bright future.
1 Like
HiâŚi am new user here. As per my experience with Meteor, the ground is still shifting beneath my feet it has to be, to some extent, if I want my stack to evolve. However, instead of having to sort through a dozen different options when a core piece of the system changes, full-time curator/integrators and an awesome community. Who are smarter than me and/or care more about the specific aspects of the system are keeping abreast of the broader changes, making concrete recommendations, and providing solutions that work out of the box. And everybody who is using Meteor is trusting them to do a
great job of it.
I have just started out the other month and this is my (rather inexperienced) take on Meteor so far.
I am designing a LOB application with a Micro Service architecture in mind. Not being a JavaScript/Node.js guru, Meteor seemed to be a good fit to quickly learn and build what I needed. The benefits I saw as a newbie were in particular DDP, the accounts packages and the easy build process plus I really liked the responsive community.
As I read through tutorials and github repos I learned about libraries that seem to replace one by one the USPs of the Meteor stack or which could be used along, e.g. Webpack, Passport.js, React, React-Router, Redux or recently Apollo.
I have built an example app incorporating the above mentioned libs on top of a fresh Meteor application and now I wonder what exactly I need Meteor for in that mix in the first place.
What I am trying to figure out, without meaning to open Pandoraâs box, is, whether the JavaScript community has caught up with what made Meteor unique like say two years ago.
I understand that Meteor can still get you off the ground very quickly of course but with all those new libraries and a complex application on the todo-list, I am not sure if it is the right choice in the long-term. Welcoming your thoughts.
-act
1 Like
curious as well, what does meteor still do?
Helps you build an awesome app, through isomorphic JavaScript, fast Websocket server-client communication, and by eliminating a mountain and a half of boilerplate and callbacks that youâd typically have to write.
2 Likes
No offence to anyones thinking or more accurately feelings but I personally think there is a lot of FUD in this form. My personal experience with the framework thus far is that:
-
Meteor delivers: clients are happy because we can deliver fast, real clients donât care about React.JS or the underlying stack, they want results! weâre not Facebook, I personally donât need complex re-usable components or the most flexible GraphQL API (larger project and enterprises will need that), we need something simple that allows us to focus on client needs and Meteor does exactly that.
-
Meteor is a pioneer: reactivity, real-time, optimistic rendering things that client use with joy coming out of the box 4 years agoâŚthings end-user will appreciate, try to explain the value of React.js to an end user which is in my opinion an overly hyped technology that is being sold as the solution for everything. Facebook solution to web problems is to work around them⌠DOM is slow? create a virtual DOM in memory (which is a bad strategy for mobile web apps due to memory consumption), and what was their solution to slow mobile web apps? abandon the web all together and compile to nativeâŚinstead of embracing the web standards and helping to evolve it they work around it and/or abandon itâŚyes bypassing the web short term would work, but longer term the web platforms catches up and those workarounds fades awayâŚ
-
Meteor has a great community: itâs really amazing to see how people stepped in to support Blaze because it is a solid well design technology that many found useful and built businesses around.
It is obvious that the Node ecosystem is maturing now and itâs different than what it was 4 years ago, Meteor is aligning it self with the future and theyâre doing that incrementally, MDG has lot of experience in their disposal since they started why ahead of the rest of the community to build real-time connected clients and I hope they keep an eye on [Progressive Web Apps] (https://developers.google.com/web/progressive-web-apps/) that I think will deliver more benefit to the end users then the overly hyped React ecosystem. I also hope that MDG leaderships provide some sort of announcement in the the near future that would ease some of the fears and uncertainty behind post like theseâŚ
Just sharing my opinion, alright back to work 
7 Likes
agreed, but thatâs the âoldâ version , what will the future versipn bring (donât take Apollo into account).
genuinly curious.
The future is with apollo, you cannot ignore that. And it will bring a lot:
- easier data handling in component driven apps
- support for multiple databases and -sources
- in general more security and stability, because it is more easy to reason about what data is used in any component, so less bugs and security-flaws
- better interoperation with other services that exposes REST or similar.
- better maintainability
If you do not need any of these, you will be fine using the classic meteor way that has also itâs benefits.
1 Like
Didnât mean to ignore it, but just that Apollo is âclearâ. Meaning, I get that part. Great stuff and makes sense. But I believe it has been discussed before in other threads, but Iâm guessing more people like me are asking themselves what will âMeteorâ be. If we take out Blaze, DDP, Collections, Tracker, Packages, etc⌠What is actually âmeteorâ then. The build tool?
Iâm not trying to trash Meteor in any way here, genuine question. Changes are coming fast and itâs hard to keep up with all the different things going on in Meteor at the moment. Itâs true that âclassicâ will work (for now). But for me thatâs bad advise. Itâs end of life. No reason to start using it for new projects anymore.
2 Likes
yes, youâre right, i did not follow everything here 
I asked myself the same question. Meteor is a platform, where you run your app. It provides a build-tool and a server. The server part is not to be ignored, thatâs still a lot of work. But you are right, it seems to do less than it did before.
By the way, packages are just replaced by npm. Isomorphic packages (client and server) are still possible on npm, so i think there will be meteor-specifc isomorphic packages on npm, just like on atmosphere before.
Really? Iâd like to see an example of one of these. Not being facetious ⌠Iâd actually like to see how the repo is structured. Iâve got a bunch of packages on atmosphere that use isomorphic code and I havenât yet seen an easy way to achieve and maintain the same sort of thing on NPM.
Check featherjs. They use that intensivly if I remember correctly
Hey all, I think this topic has been exhausted. Please open new threads about particular issues or ideas you have so we can keep to one topic per thread!