Hacker News Reader

Comment by Nextgrid | Hacker News Reader

A company I used to work for needed a website. They already had a backend and a REST API (served on the same domain as the website should be) and the old website was served directly by the backend that also served the API.

I am not aware of why it was chosen to retire that and separate the website into its own service - maybe there was a good reason, so I won't comment on that.

However the approach they (or rather some frontend developer) chose was a React front-end (fair enough) with a Node.js backend that translated between the REST API and GraphQL (WTF).

The existing API was served on the same domain so the new React website could've directly interacted with it without any problems. But no, this guy wanted to put "GraphQL" on his resume and so introduced an unnecessary extra component and potential point of failure that the company now has to support.

View on HN

I made this same tech-stack decision while working for a company in the manufacturing industry. React, GraphQL, Node.js. There was a reason behind it.

The head of the company was pushing to modernize our process flow via software meant to drive manufacturing. We had contractors on site from three different companies who were each using us as a test-bed for their software/manufacturing integration. Every week or two they'd plot out some new data they'd need to move from sales to engineering, manufacturing, QC, etc.

In our case, having GraphQL as a translation layer for the sales website saved everyone involved time. However, I can also see many scenarios where that wouldn't have been the case.

It definitely comes down to using the right tool for the job. Knowing how to identify which tools fit and which don't is one of the skills it's very important to help new devs develop.

Yeah, GraphQL seems like a cool piece of tech that's overkill for 90% of the places it's used.

I'm a bit confused as to how it's become so popular for normal development when it seems to have a lot more boilerplate and setup than a simple REST API.

I feel like GraphQL is the new NoSQL. Not just that it's mistakenly adopted, but also that it is quite valuable for the right use cases, but the public doesn't seem to understand what those are.

Do you really, _really_ need to support queries? 99/100, I'd guess no, and thus constraining people to a more defined interface and access pattern is simpler.

Oh... you need to fill your RDMS with a bunch of JSON responses from your 3rd party API. So you can then decode them in memory because I actually need to select * where identifier = 'banana' to do analytics.

Meanwhile the API returns highly structured data perfect for a RDMS, but we dont know how to query SQL without an API in the frontend. So welcome to my hell.

It's a combination of resume-driven development and premature optimization.

The former doesn't need explaining but the latter can be explained as developers being concerned about requiring the benefits of GraphQL in some uncertain future and decide to include it from the start, even though in most cases they end up never actually reaping the benefits while still being plagued by the extra overhead of using that technology.

> The existing API was served on the same domain so the new React website could've directly interacted with it without any problems. But no, this guy wanted to put "GraphQL" on his resume and so introduced an unnecessary extra component and potential point of failure that the company now has to support.

There's a simple solution to this kind of problem: let the resume driven developer use his skills - fire him.

Reply on news.ycombinator.com