Apollo seems to duplicate other frameworks that already are production-ready (e.g., FeathersJS). Feathers’ server-side framework allows you to rapidly build REST or Websocket interfaces via a’service’ abstraction that sits on top of support for many ORM’s (and therefore, many more actual database implementations). Also, you don’t have to use GraphQL, which doesn’t appeal to everyone.
Here’s what querying with their client-side package looks like:
const app = feathers()
.configure(rest(__API__) // could be websockets too
.superagent(superagent));
// a service is an interface for essentially
// accessing a table in a database, with
// CRUD (create, read, update, delete) operations
const messages = app.service('messages');
// find all of my messages
messages
.find({query: {userId: 'myUserId'}})
.then(function (data) {
// persist data to your store (redux, etc).
})
.catch(function (error) {
// not authenticated, no internet connection, etc.
});
If you’re already investing in webpack and react and redux, meteor’s value proposition (for the developer) has to come in the form of simplifying the server-side piece (easily building REST and websocket interfaces) and having accompanying client-side libraries that make it easy to consume those interfaces. I could be wrong, but it looks like feathers and apollo are an apples-to-apples comparison in that regard.
I guess it’s a little less clear to see what Meteor’s role is in hosting, it’s primary revenue stream. Meteor can’t be a walled garden, since that’d appeal to too few developers. People want to build vanilla nodeJS apps, so the recent direction with projects like Apollo makes total sense. But frameworks that essentially do what Apollo does already exist. At that point, Meteor is just scaling vanilla node processes (and there are many PaaS providers out there doing that). However, they would be notably differentiated from other PaaS providers in that they’re also building frameworks that facilitate the development process. But does that have any relevance to the revenue model when compared to other hosting providers? I don’t know.
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.
“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.
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.
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.
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.
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…
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.
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.
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!
