This is what I wanted to say too. If your backend team is incapable of rapidly adding new endpoints for you, they probably are going to create a crappy graphql experience and not solve those problems either. So many frontend engineers on here saying that graphql solves the problem they had with backend engineers not being responsive or slow, but that is an org problem, not a technology problem.
I think the point here is, if you have to involve a backend team to add restrictions to the graphql endpoints and try to make good educated guesses where those might be, then the idea of frontend not needing backend engineers to query whatever they need becomes less of an advantage. So is the complexity of setting up graphql and then having your backend team try and make sure no frontend engineers can do terrible queries better for the software than custom rest APIs where needed and standard resource APIs everywhere else. Obviously it depends on the project. But I find the complexity of setting up and managing graphql often isn’t worth the pain, especially with schema first resource api designs and tooling like Google’s AIP linter.
Is the flexibility worth the tradeoffs? Maybe in a company where you are adding new pages all the time with deeply nested relational data needs. But I would argue this is more rare than not. And I often find that frontend engineers aren’t as familiar with database queries and the load they are putting on the system with some of the graphql queries they are making. Flexibility for frontend has its own tradeoffs and I totally understand why a frontend engineer doesn’t want to have to wait for an endpoint to be finished. But this article outlines some of the issues you encounter later as you scale your team and system.
We use a schema first design where I am at and if a frontend person needs a new endpoint because the resource-only endpoints aren’t enough then they submit a pull request to the schema repo with a design for their endpoint they need. It gets approved and boilerplate is auto generated. Yes you have to wait longer, but 90% of the time (for our software) the resource endpoints work great.
Awesome idea, and awesome product! The blog post mentions CF for SaaS will have these features as well. Does that mean if I have primarily SaaS customers, I can expose this feature to their custom domains as an addon?
My guess is that it is because of the mono-repo. Since it would take some work to figure out what changed and what to build, they just did it the easy way and re-build everything :-)
Because these private companies have monopolies on their infrastructures and use protectionist measures to keep it that way. And on top of that, companies like Comcast have created a huge conflict of interest by owning content providers like NBC. Is it fair if the only high speed internet in an area is Comcast, and they make CBS video load slow because it is a competitor? I run a VoIP company. Should comcast be allowed to charge me so my clients get quality phone service since Comcast offers its own VoIP service? The Internet should be treated as a utility. If you want to be an ISP, you have to treat all sites equally.
I am not saying I agree with this, but allowing gay people to be married gives them rights to adopt children. If you believe that the foundation of society is traditional family and that children should be raised, when possible, in a traditional family, you could see why someone would appose gay marriage.
Yup, same belief. Because that archaic thinking is going away. I don't care if he donated $1000 to the KKK. If it isn't affecting his role as CEO, then who cares. But I support gay marriage and I still eat at Chic Filet, so what do I know.
I agree. PIP in python is great, but has some extra overhead and difficulty with it, like having to setup virtual environments for each project. NPM by default installs to the local project only and with a quick --save will put it in package.json dependencies (similar to requirements.txt with pip). Node package management is awesome because it is so simple.
What about scalability? Trying to cluster and shard MySQL is a very difficult task, but with MongoDB it is trivial. No schema can be good, but scaling out easily is the big plus I see.
The difference in this case is that Android can be customized and tailored however a carrier or manufacturer wants, because the source code is in fact available. Windows never allowed for that.
I think prices are lower than they would have been without android. Without debating the openness of the software, Android still gave phone manufacturers a huge code base for their smart phones that they would have had to develop otherwise, and their software probably wouldn't have been as good. Just look at the selection of "free" smart phones from T-mobile: http://www.t-mobile.com/shop/phones/?shape=smp
I doubt the diversity and quality of those phones would have been possible without Android.