@gschmidt Iām gonna lay out a vision in a medium article for GraphQL and relay (influenced) stuff. Thereās a lot you can get from us for free that you are paying employees for.
I would love to somehow engage in your internal conversation. Even other developers (@aadams @dinos) have mentioned they would love for MDG to respond to ideas Iāve put out. That said, this isnāt only about meāIām just an example. I think in general, there is a lot of noise for sure and @sashko does his best to +1 ideas he supports. But heās only one guy. You chiming in here is also a move in the right direction. But in general, most of the communication is 1-way communication.
What we need is simply: RESPONSE TO WELL THOUGHT-OUT IDEAS AND PUBLICATIONS BY YOUR COMMUNITY. How come @arunoda basically has to operate as a loan wolf monkey-patching you all the time. I rarelyāif everāsee any comments/responses on his articles from MDG employees/partner. And thatās just using one guy as another example. So rather than more one-way communicationāwhere in the past all we got was an occasional blog articleāwhat we need is genuine listening to what we have to say.
There is great ideas coming from us that youāre missing and essentially paying people to find on their own. And with a lot more of us and some of us already passionately dedicated to certain areas (rather than just assigned to it), we may have a thing or two you havenāt thought of.
I donāt think you really listen to us at all. My perception is that you view most of us as a bunch of intermediate developers creating a lot of noise. Fine, but my recommendation is to sift through the noise and find the gems. Some of us might really have some insights about whatās best for the direction of Meteor. Itās a lot faster than waiting months for a few of your guys to research areas that community developers are already hyper aware about. At the very least, make sure as part of their research, they comment on such outside research. It shouldnāt just be limited to forum responses. In fact, the best stuff is likely coming out of Medium articles these days. Responses from core MDG developer precisely in that spot wouldāin my opinionādo the most to engage the community and flip our perception of MDG on itās side.
For example, hereās several recent posts of mine you may be able to find such gems in:
I have an idea of how youāre working, and really like it, but I got some tweaks to it. Basically it seems the way youāre working is youāre sending out developers to do thorough foundation-first reports on various emerging technologies, basically as scouts. Thatās smart. Your partner @dgreensp whose work Iāve been impressed by ever since he started appearing in Dev Shop videos wrote a great report on Webpack for example. That was extremely informative to me and basically did the trick of bringing me up to speed where most other material out there still left you putting pieces together on your own. So from what I understand you have @sashko and Justin Santa Barbara assigned to, what Iāll sum up as: ***ānextgen subscriptionsā***. Right. Again, this is Relay and GraphQL inspired stuff, but with a reactive subscription-based focus like Meteor has always provided through LiveQuery. Itās my opinion that this is the absolute biggest area of evolution in the Javascript community right now. Your guys, me, etc arenāt the only ones doing lots of exploration in this area, but Iāll get back to that in just a second. ā¦Basically, my recommendation is that you start Hackpads or similar from the start of these explorations, not after they are done; announce that you are starting them, and engage us from the beginning.
Itās always scary to address your constituents before you, yourself, have a voice. I get that. Iām not saying that @sashko shouldnāt do any preliminary research of his own. But basically do what you did with the Proposal for Blaze 2 Hackpadājust instead, actually apply what everyone came up with. That Hackpad really does seem to have been a successāthe cream of the best ideas rose to the top. If Blaze 2 ended up being built, and the result was something that got a lot out of that Hackpad, it would have been a big win towards the aim of stronger community coordination.
I think currently with the Relay + GraphQL inspired stuff we have the best example of a āhackpadā sort of situation we can start now. And we should open up such a Hackpad. Iāll leave that up to you.
Iāll kick it off with my findings:
Itās my personal opinion that ClojureScriptās Om Next has absolutely nailed this (far and beyond what Relay currently supports) and you should use that as the basis for what Meteor is doing. In addition, unlike Relay and GraphQL, it isnāt just a specification/protocol. Itās concrete all the way down!
Hereās what is great about Om Next:
- it combines what Redux and Relay offers into one
- it allows you to configure multiple state atomās as data sources (e.g. a client one for āUI stateā [Redux] and a server one for ādomain stateā [GraphQL])
- it has subscriptions out the box! Minus RethinkDB, which is just the DB portion, no open source product (reads: Firebase is excluded) ever really offered full stack subscriptionsānone that picked up steam at least (reads: Derby?? what is that?).
- it has full stack time traveling (not just client side time traveling like Redux)! This is thanks to the Datomic database, which keeps a record of every mutation ever mad, and which would be a challenge to replicate otherwise, but is definitely doable via snapshotting and the oplog for small development databases.
- it simplifies the boilerplate needed to get the Relay-inspired stuff up and running. To be sure, itās a major benefit that they arenāt trying to support multiple databases like GraphQL, but even then, it simplifies a lot that Relay requires you to do.
- it uses Datomic, which has built-in support for subscriptions (for the most part) and is the closest thing to the database described in the famous Turning the Database Inside Out video. Om Next is āobservables all the way downā now!
I think we should achieve that but using GraphQL and Relay so that you can take advantage of their ecosystems. From application developersā perspectives, they would be dealing with a wrapper of GraphQL on the server and a wrapper of Relay on the container. But underneath MDG uses raw GraphQL and Relay to take advantage of efficiencies it provides. Specifically, on the server (GraphQL) it will allow you to use Rising Stackās Mongoose and Graffiti and add additional DBs more easily and on the client Iām sure something will emerge that makes it a good decision to use Relay. But just to re-iterate, what application developers use is a condensed simplified opinionated version of such. I.e. a way smaller surface area. If you donāt provide such abstractions, there would be no value-add provided by Meteor, which would be a bad thing; there would be no reason to not just use NPM + raw React+Relay+GraphQL. So there needs to be a value add provided by Meteor in the form of a simplified abstraction. And, luckily, this isnāt just a solution to a problem that doesnāt exist, but is actually a problem needing solvingāif we thought React required more boilerplate, Relay and GraphQL requires 2-3 orders of magnitude more boilerplate!
Hereās an example of how Om Next simplifies the Relay-inspired stuff (notice primarily the query function):
(defui Person
static om/Ident
(ident [this {:keys [name]}]
[:person/by-name name])
static om/IQuery
(query [this]
'[:name :points :age])
Object
(render [this]
;; ... bla bla ...
))
This is a complex topic and requires deep knowledge of GraphQL, Relay, React, Redux and whatās going on in our functional programming counterparts: Elm, Cycle, ClojureScript (Om Next and Re-Frame), etc. I think this will be a major win for us all to talk this one out together. I think we should all share our findings via various Medium articles and respond to each other there as well. I think this is the perfect opportunity for MDG to come out of its shell. And generally the perfect time for Meteor to come out of its shell.
My Final thought is: as the greater Javascript/NPM ecosystem acquires what Meteor has exclusively offered for years, we need to come up with new opinions. Meteor was opinionated in an area that is now more generally abstracted (or at least in the midst of completing its final stages of which). Meteorās success relies on it being opinionated. Unfortunately (or fortunately, depending on how you look at it), we need a whole new round of opinions to offer a value proposition worth betting on instead of using ābare metalā NPM. It made sense that only MDG contributed to such opinions the first time around (since the community didnāt exist). Therefore, itās the perfect time for not just MDG but the whole community to contribute to them. A hackpad would be the perfect place for us all to form them.
https://hackpad.com
