I’m not usually one to post anything on the forums but said I might as well with this topic being so new.
I’m developing an app in meteor 1.3, and I’m currently rewriting it from the ground up with all the new import/export etc. This is already a big enough learning curve for me but I’m getting the hang of it now.
I’m also going ahead with using React, as I was previously, but now with containers/components. One thing that I see a lot of people having an issue with eventually is local application state, so I’ve read up and going to integrate redux on the client-side now.
Aaaaaaand finally with Apollo getting so big I read into GraphQL and the problems it solves etc. While I don’t necessarily see a big advantage for my application to go off and implement it, I may in the future especially since it will be more ‘future-proof’ as such.
However, I am finding it hard to get my head around parts of Apollo and it’s quite frustrating. Maybe it’s just my concentration lately with taking on so many new paradigms.
I’m just wondering really, how production ready IS apollo and if you were developing a new application from today would you start with Apollo or not - and why?
I’m going a bit off topic here, but you nailed it. If I was a Cognitive Psychologist and wanted an unlimited source of easy research material, I’d just watch developers living/dealing with the ever changing tech landscape. It’s really quite amazing how much of an impact having to learn so many different technologies quickly (and often times temporarily), has on our ability to continue learning. Constantly jumping from tech to tech reduces our ability to concentrate and stay focused, which really does seem to hurt us not only as developers, but also as humans. Speaking from personal experience, I’ve noticed that years of doing this has really impacted my ability to stay focused when dealing with other aspects of my life. It’s quite amazing actually - the funny/sad thing is that I’ve thought about really digging into this further and seeing how I could personally start to change this life direction, but then lose interest and move onto the next thing … Q.E.D.
Here’s my take on it. Apollo is production ready if:
You’re willing to accept that it’s still in a technical preview phase, which means breaking changes can and will still happen.
You have the time / budget to account for this on-going change, and don’t mind adapting your codebase as changes roll in.
You have a valid need for the advantages that Apollo gives you. Two of the biggest being the ability to easily work with multiple and varied data back-ends (including or excluding Mongo), and better control over how your data is being used, which leads to better scaling scenarios.
You’re able to dig into the Apollo code and find answers, when you get stuck. The docs are really coming along, and this forum and the Apollo Slack are great, but there are still gaps (the docs are being focused on right now by the Apollo team, so expect more on this front shortly).
Are you planning on using Apollo with Meteor? Great, but be prepared to have a bit of overlap in functionality, and understand that you’ll be bundling parts of Meteor with your app that you won’t necessarily be using (since those parts can’t be split out yet).
Staying on the topic of Meteor, also understand that the focus of Meteor 1.5 is Apollo integration. That will mean changes, but more importantly it will likely mean that if you wait a bit longer, your ramp-up with Meteor + Apollo will be much more smooth.
Not off topic at all. It really is something I’m struggling with lately. Beyond frustrated with how simple this should be to learn but it’s just not. It really is frustrating. Thank you for summing up the reasons why/if I should use Apollo. It is clear to me that I don’t actually need it right now (pub/sub works great), and if the need did arise in the future I could easily adopt it into an existing codebase.
I think what I need to do ultimately after I read that is just forget Apollo for now, focus on react / redux integration and be happy with that.
How do you find yourself dealing with constant change @hwillson? Since I am clearly unable to think logically about my own situation.
Yeah I agree with hwillson. I think “production ready” is a developer buzz word. Everyone’s “production” is different and based on the criteria you mention… “one man’s production is another man’s development”
we need a new set of vocabulary besides “production”… nothing too substantial but maybe three tiers
“critical production-ready”, or, you can use this in your new IoT artificial heart software, or for your new project with Bank of America’s checking account security systems. Think Java.
“general production-ready”, or, you generally won’t have to invest much time and effort to update this. I’m not sure of a good example… maybe react in it’s current state? here it is definitely okay to use with a client (in other words, you won’t be sticking them with some experimental library they need to find a specialist to fix down the road, or take on massive on-going maintenance).
“basic production-ready”, this would be like graphQL now I imagine… you can definitely use it in your app, but it may need more on-going attention than your average technology. Especially okay if you’re just doing a prototype. Maybe want to think twice if the project is for a client (i.e. you dont want to saddle them with the potential tech debt unless there is some major pressing need for the tech).
Those aren’t the best adjectives or framework for thinking about it, but something along those lines would be nice. It seems software is going in this direction, for example node is doing their long-term support thing for every x version (I forget what they call this).
