Also, the end paragraph mentions some cloud-based graph management system. Is there any chance they could do a decentralized graph management system (something like https://github.com/brysgo/graphql-gun ) instead of some centralized solution?
I don't want my GraphQL data getting locked in to some vendor. Any reason why I shouldn't worry about this? Thanks!
Meteor, as a framework, was solid for its time. I don't think they could've envisioned how much the JavaScript ecosystem would change after its launch. It tried to solve a great deal of problems that ultimately were solved in smaller, more focused libraries.
I would add: now it's everyone else's job to make those smaller, more focused libraries work together. The time wasted is unfathomable, but the blame for misconfiguration now falls on individual developers, rather than monolithic frameworks. Progress?
At least in terms of tooling, you see things like create-react-app, vue-cli, etc. These toolkits, and their accompanying CLIs, abstract away configuration of babel, webpack, etc.
These are good, but if you need to customize further, you interface with the toolkit (which only allows you to go so far), or you eject entirely.
Many people think it's time wasted to really understand how to setup and use (individually) webpack and babel and friends. I disagree because if you ever do need to dig in to these tools, since you've used them individually, you understand what you need to change.
If you eject from a toolkit but don't understand the underlying tools, you could be up a creek without a paddle. So you can certainly make things simpler, but you can't replace having the experience and understanding of what each individual tool does, and how to interface with it.
I would say the ecosystem changes, in aggregate, are probably a loss for new programmers. You have a much wider API surface to be aware of when using all the tools and how to integrate them. But for a senior front end engineer, it's unlocked the ability to have very fine grained control over the bundles you're creating.
The power comes in two fronts. The ease that the cli tools you mentioned to help you gather a solid baseline of these smaller packages, and then, giving you the ability to decompose the features into interchangeable parts by ejecting or just by virtue of how small the packages are. The problem with monolithic frameworks in my opinion lies with the second part, they develop to he opinionated and for valid reasons, but sometimes that create really intense friction when changes need to happen in particular ways.
Absolutely not! We depend on it internally (engine.apollographql.com is a Meteor app), and Galaxy hosting revenue is THE reason we didn't have to raise money until we felt like it, which is why we got to pick our investors in this round.
Behind the scenes, as the lead developer for both Apollo Client and Meteor, I am constantly borrowing technologies from one to benefit the other. Meteor may move more slowly these days, but that's because it's relatively mature. Apollo has to move more quickly because we're still making (and remaking) fundamental decisions.
Even as community enthusiasm for Meteor has slowed, Galaxy revenue has not, and it's honestly not the worst thing for an open-source project if people who came for the hype either (a) find real reasons to stay, or (b) take their hype-thirst elsewhere.
I have some ideas for increasing Meteor contributor engagement that I'll be giving a talk about at the next Meteor Night (tentatively July 9th in SF).
(Re: Meteor) Our company is scaling up and we're worried that Galaxy won't be able to handle growing demand - do you have any thoughts on making the meteor system more scalable and affordable as companies get larger?
I love meteor, and don't really want to move our stack off it but it's becoming a more real thing that we have to face in the near future as it's hard to see how it can grow with us!
I can only imagine the reason galaxy revenue is increasing is that the companies started off Meteor 2-3 years ago are now becoming real. I know a few companies in our YC batch that use Meteor.
Does this mean Meteor is dead?
Also, the end paragraph mentions some cloud-based graph management system. Is there any chance they could do a decentralized graph management system (something like https://github.com/brysgo/graphql-gun ) instead of some centralized solution?
I don't want my GraphQL data getting locked in to some vendor. Any reason why I shouldn't worry about this? Thanks!