<story><title>GraphQL kinda sucks</title><text>Graphql is great, but is totally over hyped. This is probably more of a rant or a frustrated dev outburst.&lt;p&gt;but beginner to mid level developers are lead down the path of USE GRAPHQL especially on youtube... and this is just unfair and wrong.&lt;p&gt;The good:&lt;p&gt;- It makes working with describing the data you want easy&lt;p&gt;- It can save you bandwidth. Get what you ask for and no more&lt;p&gt;- It makes documentation for data consumers easy&lt;p&gt;- It can make subscription easier for you to use&lt;p&gt;- Can let you federate API calls&lt;p&gt;The bad&lt;p&gt;- It is actually a pain to use, depending on the backend you are using you&amp;#x27;ll have to manage&lt;p&gt;two or more type systems if there are no code first generates in your language&lt;p&gt;- It doesn&amp;#x27;t support map&amp;#x2F;tables&amp;#x2F;dictionaries. This is actually huge. I get that there might be&lt;p&gt;some pattern where you don&amp;#x27;t want to allow this but for the majority of situations working with json api&amp;#x27;s you&amp;#x27;ll end up with a {[key: string] : T} somewhere&lt;p&gt;- No clear path for Api versioning you&amp;#x27;ll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03&lt;p&gt;Don&amp;#x27;t use Graphql unless you&amp;#x27;re managing a solution&amp;#x2F;problem set that facebook intended graphql for&lt;p&gt;Invest your time in a simpler solution then running to GraphQL first&lt;p&gt;thanks for reading my ted talk&lt;p&gt;please any senior dev&amp;#x27;s drop your wise words so that any new dev&amp;#x27;s can avoid tarpits</text></story><parent_chain><item><author>breckenedge</author><text>I get specialization, but are there any other good reasons to divide product teams between frontend and backend? I guess it also helps establish patterns and contracts, but I think those are only helpful above a critical mass that I haven’t reached in my career yet.</text></item><item><author>mabbo</author><text>Whether it was the intention or not, I find GraphQL solved a fascinating problem: it let front end developers move faster by greatly decoupling their data needs from the backend developers.&lt;p&gt;Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they&amp;#x27;re querying on the fly, get more or less as they see fit.&lt;p&gt;It lets everyone move faster.&lt;p&gt;But as a backend developer, I actually fucking hate it, myself.</text></item></parent_chain><comment><author>TheAceOfHearts</author><text>It depends on the kind of application and scale. Consider a large and complex application like Discord or Figma. Past a certain point, it&amp;#x27;s hard for anyone to know how every single detail works.&lt;p&gt;You should probably be comfortable enough to work with both ends of the spectrum, but specialization allows you to do a much deeper dive into complex subjects.&lt;p&gt;A backend engineer probably has a much deeper understanding of every little nuance of their prefered database. A great backend engineer can make sure that you&amp;#x27;re getting near-optimal performance from every important query.&lt;p&gt;A frontend engineer probably knows about various UX techniques along with how to avoid unecessary reflows and repaints. A great frontend engineer can implement a UI toolkit as well as advanced techniques such as windowing.</text></comment>
<story><title>GraphQL kinda sucks</title><text>Graphql is great, but is totally over hyped. This is probably more of a rant or a frustrated dev outburst.&lt;p&gt;but beginner to mid level developers are lead down the path of USE GRAPHQL especially on youtube... and this is just unfair and wrong.&lt;p&gt;The good:&lt;p&gt;- It makes working with describing the data you want easy&lt;p&gt;- It can save you bandwidth. Get what you ask for and no more&lt;p&gt;- It makes documentation for data consumers easy&lt;p&gt;- It can make subscription easier for you to use&lt;p&gt;- Can let you federate API calls&lt;p&gt;The bad&lt;p&gt;- It is actually a pain to use, depending on the backend you are using you&amp;#x27;ll have to manage&lt;p&gt;two or more type systems if there are no code first generates in your language&lt;p&gt;- It doesn&amp;#x27;t support map&amp;#x2F;tables&amp;#x2F;dictionaries. This is actually huge. I get that there might be&lt;p&gt;some pattern where you don&amp;#x27;t want to allow this but for the majority of situations working with json api&amp;#x27;s you&amp;#x27;ll end up with a {[key: string] : T} somewhere&lt;p&gt;- No clear path for Api versioning you&amp;#x27;ll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03&lt;p&gt;Don&amp;#x27;t use Graphql unless you&amp;#x27;re managing a solution&amp;#x2F;problem set that facebook intended graphql for&lt;p&gt;Invest your time in a simpler solution then running to GraphQL first&lt;p&gt;thanks for reading my ted talk&lt;p&gt;please any senior dev&amp;#x27;s drop your wise words so that any new dev&amp;#x27;s can avoid tarpits</text></story><parent_chain><item><author>breckenedge</author><text>I get specialization, but are there any other good reasons to divide product teams between frontend and backend? I guess it also helps establish patterns and contracts, but I think those are only helpful above a critical mass that I haven’t reached in my career yet.</text></item><item><author>mabbo</author><text>Whether it was the intention or not, I find GraphQL solved a fascinating problem: it let front end developers move faster by greatly decoupling their data needs from the backend developers.&lt;p&gt;Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they&amp;#x27;re querying on the fly, get more or less as they see fit.&lt;p&gt;It lets everyone move faster.&lt;p&gt;But as a backend developer, I actually fucking hate it, myself.</text></item></parent_chain><comment><author>dasil003</author><text>The reason is to scale teams.  It’s not the only way to do it—you can also have vertical teams—but it’s a common one because frontend and backend have different technical considerations.  The downside is the product can lose cohesion as developers get tunnel vision.  Of course all big teams suffer from a version of that problem depending how the lines are drawn.</text></comment>