Thanks! I’ve thought about writing a “learn Elixir” book as a first language but it seems like so much work. I’m also really considering making a Learn GraphQL with Meteor course similar to reactforbeginners.com where it’s very distilled, simple, and fairly jargon free.
I guess i’ll dip my toes in the water and try it out with the free migrating to apollo screen cast which will just be me migrating enough to make a spike (as a learning tool for me for using Apollo my other projects). If that screencast is well received i’ll start planning out a full course This would also include techniques to produce maintainable apps since that’s typically hard to do.
Great Ideas and strategy. I’ll be attending/watching and try to provide as much constructive feedback as possible. Techniques to produce and maintain apps I think would be well received too.
At this point and under these new circumstances, I feel like I need some resource to help me make the right Meteor + React + Apollo choices. It almost feels like I’m lost again, like I was before Meteor came along (when I looked outside of the .net world of course). Someone, tell me the right way to do things again, give me structure!
At this point and under these new circumstances, I feel like I need some resource to help me make the right Meteor + React + Apollo choices. It almost feels like I’m lost again, like I was before Meteor came along (when I looked outside of the .net world of course). Someone, tell me the right way to do things again, give me structure!
Haha, I feel your pain! I’m very passionate (obsessed?) with making my workflow as fast as possible so I have a set of boilerplates and tab triggers that i’ve made that follow a strict set of rules (part of why it’s fast), as well as a file generator to spit out tedious boilerplate (React works best with many small components).
As part of my freelancing I have to be able to jump into any client app at any given time so making things consistent and maintainable is high on my list. It also help when working with a team.
As time goes on it’s always evolving but basically the same. I’m most likely going to open source these once I shake out the dust with the React Native boilerplate (routing has changed a bit for the better). In theory you can run a script and you’ll have an API, RN app, and Client side app (api + client combined with Meteor) with all the auth and basic pages ready to go so you can signup/login to a hello world page/view.
Hmm maybe a course on building a small app doing all this would be the way to go haha.
Anyway I guess i’m drifting off topic but GraphQL is one of the things that help tie everything together… a central (Meteor) API that sends data to a web-client, React-Native app, and other Meteor micro-services. The strongly typed nature also makes things predictable, which brings speed over time (at the cost of a bit of setup).
I think people have explored this idea a bit, but I don’t think we have seen a serious attempt at reducing the setup for a GraphQL app yet. I’ve heard the Reindex guys might be open sourcing something soon, but in my ideal world the setup would be like:
Write my schema
The backend is generated automatically on top of, for example, MongoDB
As I develop my app I can fill in a more legit backend over time
I just mean that for me and my work, it’s a no brainer as a default. It has quite a few features over REST endpoints and a lot of flexibility (not true with pubsub and integrating with native, RN, other services, etc…).
Ok. But this I can also get with the SimpleSchema checks, right?
For the most part. GraphQL’s schema is more granular as you have to define all the keys in an object… having object as a type isn’t allowed. The type system also gives you an auto-complete IDE to create/test queries (GraphiQL) as well as in editor tooling to tell you your query is invalid before it even runs.
It’s really more of a SimpleSchema for your Meteor method inputs if you want a closer comparison. The GraphQL schema can be 1:1 with your data but it doesn’t have to be. You could use SimpleSchema for your data layer and the GraphQL schema could be for your API schema.
This might be the case if you have a lot of “virtual” fields that dont exist on the database model itself. For example you could add a field viewerCanEdit and that field runs a field resolver that does some kind of database check to see if the user can edit something. If you have a lot of these then having a sep schema for data (like SimpleSchema) and GraphQL can make things very explicit (albeit verbose). Personally i’ve used the GraphQL schema in place of SimpleSchema/Ecto-Schema and have relied on GraphQL rejecting bad input data.
Hopefully this makes sense, I realize it’s a bit abstract. The tldr is that you don’t have the use SimpleSchema unless you want to.
It’s not like an ORM but more like a replacement for AJAX and a clientside cache. It also has the optional react bindings to give you that nice co-location of views and data fetching.
The schema itself lives on the server side and is not Apollo specific.
I feel like GraphQL is one of those weird looking things that only makes sense once you build something with it. Much like React.
Yep, it’s actually quite cool that the original designers of GraphQL and us at MDG arrived at basically the same design for how data updates should work.
I love the concepts behind GraphQL, but I would stay far away from implementing it into a project until it gets way more mature and best practices are formed. Unless you are greatly in need of its benefits… if not, what’s the rush? If you don’t know much about it and how to implement it, I think running with it as your core data layer is a huge mistake.
The problem is: right now I have to rebuild large parts of our system and it would be sad if the new code would be outdated right when Meteor 1.5 comes out.
No, we’re also using Apollo in production. Both technologies are good for production. Depending on your needs, one or the other might be better for you.
What @sashko said. If all my mongo code was outdated because of Apollo, I’d probably go jump off a bridge They are two very different approaches and technologies. I’m guessing the Mongo code will still be the recommended way to build Meteor apps for quite some time longer.
There is now an “experimental” way for reactivity in Apollo. I started playing with Apollo, it’s a great project but it does not have a stable API yet and for now it is far from doing things automagically like the good old Meteor. So no rush for me.
This would also include techniques to produce maintainable apps since that’s typically hard to do.
