Comment by adamsea | Hacker News Reader

Comment by adamsea | Hacker News Reader

Parent Full thread

React I have been thinking about, having worked with it a lot and also recently done a React / TS / GraphQL (GraphQL may have been the poorest choice I made; time will tell) project.

I think React itself is awesome and I've always enjoyed it. While I'm not an expert, it's conceptual foundations and core abstractions felt right, and I do think it makes lots of frontend tasks simpler, especially for non-small projects.

At the same time the frontend ecosystem is a mess, as we all know, and as my CSS skills advance I see more just how much could be done with HTML / CSS / limited use of JS and your classic REST app, that's not a single-page app, and how much complexity might be able to be avoided and thus time saved.

At the same time, I don't think it's just "trendiness" that has caused the growth of React and SPA's. I think they give us various wins that we probably take for granted because we're now used to them.

So, the short answer to my long ramble is, I don't know.

But I do think React itself, specifically, hit a sweet spot in terms of being a powerful yet understandable tool, and still remaining a tool, as opposed to a framework.

I have that rant daily at this point.

Dev A: I need an API to CRUD

Me: But we've been doing CRUD for 30 years without an API this is a small project

Dev A: But I don't know how, its not best practice, my team lead agrees, here is a medium article, get with the times, etc.

Me: Ok so you don't know how to do your job.

Dev B: Here, put the React SPA in a Docker container and run it on some cloud its easy...

Me: But all I need is still CRUD, I dont need to scale it, I dont care if its isolated, it should have been 100 lines of code

Dev B: its not best practice, my team lead agrees, here is a medium article, get with the times, Docker run everywhere, etc.

Me: But what I need to connect it to internal resources and use DNS?

Dev B: load balancer! If only you have an AKS cluster!

Me: We work in a 25 person company that needs some very basic CRUD. It will never scale past one deployment, ever, if it does, dont worry we will pay someone to do it right because we will be swimming in money.

The problem is that people are starting to not know how to do simple things. So you get grumpy admins losing their marbles over the complexity of this BS. Most of the time things could be fixed faster, easier, deployed and managed easier using simple technologies that have been around for 20+ years.

But lets wack it with the Python, Docker, React, NoSQL, GraphDB, K8S hammer because...? Not only that, the juniors don't know multiple technologies anymore they just know X. So sysadmins complain that devops is pushing more roles on them, while I have developers that have written full Node.js sites and dont know that IP or a Port, or TCP, UDP, is...

So basically, same shtick different decade.

So how would you operate each of these bespoke services? One service uses TCP, one uses UDP, one uses SCTP. What happens if your buffer sizes are incorrect? What about if your keep alives are too aggressive? What happens if a problem in your TCP connection pool makes it seem like there's a networking issue and so you play around with your network settings only to have all your other protocols dive in performance?

I sympathize with the OP for single developers or small teams (by small, I mean a team of 5 not in a larger corporation), but whenever you have more than a single team, you want to keep system management overhead low. Unifying around a single paradigm like gRPC and Docker containers means that not every team will have their own bespoke chroot configuration and you won't have to retune an HTTP client every time you interface with a new service.

I think there's in general too little representation from small-scale or indie developers. I spend a lot of time working with the Gemini protocol outside of work and I appreciate the simpler approach that the protocol takes. I would love to see these sorts of stakeholders have a say in greater net architecture as well, but let's not pretend like this is all complexity for complexity's sake; this stuff is needed at scale.

>So how would you operate each of these bespoke services? One service uses TCP, one uses UDP, one uses SCTP. What happens if your buffer sizes are incorrect?

Such bullshit. Since when we use UDP for a CRUD service ? Since when SCTP is even considered outside of the telecom world?

HTTP and Rest-like API have been able to handle properly simple CRUD API since 20 years without problems, way before gRPC was even a thing.

gRPC has its usage for large, complex API that required a proper RPC framework. But in 99% of the case, yes it's an overkill.

"HTTP and Rest-like API have been able to handle properly simple CRUD API since 20 years without problems, way before gRPC was even a thing."

There is the problem. "Twenty years old? How can that be any good" is a common POV in my experience

> Such bullshit. Since when we use UDP for a CRUD service ? Since when SCTP is even considered outside of the telecom world?

You're making a strawmam out of this. I'm responding to the following:

"while I have developers that have written full Node.js sites and dont know that IP or a Port, or TCP, UDP, is..."

But thank you for the insult.

> HTTP and Rest-like API have been able to handle properly simple CRUD API since 20 years without problems, way before gRPC was even a thing.

Hm, what are you talking about? Are you talking about the client? Are you talking about a load balancer? I don't think anyone is proposing that a simple static blog use gRPC to serve content to its users.

> But in 99% of the case, yes it's an overkill.

Compared to what? I'd argue that CRUD over HTTP is wrong. In fact, folks have been writing CRUD over TCP for ages. Why do we need to massage CRUD syntax over HTTP when we can just stream requests and responses over TCP? In fact, TCP predates HTTP by 20 years, so if you're using the historical argument, raw TCP is even older. How much bullshit is there around AJAX and Websockets and HTTP multipart and HTTP keep-alive when we're just trying to recreate TCP semantics?

So why are you drawing the line at HTTP? Seems arbitrary to me.

That's a very good argument against the modern framework-conatiners-k8s stack. We used to be able to keep an organization wide track of things such as tcp services, buffer sizes, timeouts etc. but now it's all a black box deployed by a guy who cut and paste some yaml from a Medium article, at best.

It's probably acceptable to not learn the details of what you're doing, as hardware is cheap and all that, but it also constitutes a glass ceiling for how much the organization learns. That's a bigger problem in the long run.

Hopefully any organization that decides to use k8s goes into it understanding what they're getting into, but yes if you just get onto the hype train without thinking, you'll probably have a bad time when scaling.

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.

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.

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.

> 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.

Dude! You need to run more servers. 250 should do it. I realize its just a simple page with a pair of boxes for name registration, but that's irrelevant! All the cool kids agree. You need infrastructure. It needs to be done as complex as possible! Complexity-as-a-Service won't just happen, you have to want to make it happen. You don't want to be uncool, do you?

Looks at a specification on the desk Yep. We'll keep the first and last page. Everything else is gibberish. Next!

Edit: Looks like a few people disagree. Perhaps they might like to explain why I saved a bunch of companies around 100k in AWS fees just by pruning their server requirements? No? And yes, one of the projects was a simple set of web forms that required 7 servers to run. We pruned it down to 3 and that was just for redundancy and load. That's just one example.

If you disagree state your why.

i didn't downvote you, but since you're asking – the first part of your comment is needlessly snarky and doesn't really add much beyond "yeah, i'm frustrated by people adding unnecessary complexity just because it's trendy". on the other hand, the part added in the edit sounds like it could be an interesting story! expanding on that would make for a more interesting comment:

> I saved a bunch of companies around 100k in AWS fees just by pruning their server requirements. One of the projects was a simple set of web forms that required 7 servers to run. We pruned it down to 3 and that was just for redundancy and load.

EDIT

and if that thing about cutting down the specification really happened, just tell the story – no need to wrap it in a performance piece:

> I've actually had people come to me with specifications so over-engineered that the whole 20-page doc could be simplified down to a single page without loss of functionality!

EDIT 2

and i'm not saying "never use hyperbole"! just don't make it the whole point of your comment :)

I made that comment once about "Soylent". (Remember Soylent? The nutritional drink?) That company made a big deal about their "tech stack". Not for manufacturing or quality control, but for ordinary web processing. Their order volume was so low that a CGI program on a low-end shared hosting system could do the job. But they were going to "scale", right?

Amusingly, they eventually did "scale". They started selling through WalMart in bulk, and accepted their fate as yet another nutritional drink, on the shelves alongside Ensure Plus and Muscle Milk. Their "tech stack" was irrelevant to that.

That's an amusing story. I suppose the Soylent board met a good salesperson, and the pitch worked. So when the team landed the contract, they had to justify their costs some way... I suspect almost every software project in existence is in some way a victim (or beneficiary...) of fanatical marketing.

I remember working on an simple CMS site, amongst other things, for a pretty large company. When we begun the project, we were tasked with re-purposing an overworked Plesk instance to host the site. We eventually managed to do it, but then found the small amount of disk space that was left to us was getting chewed up by logs.

So I reported this to my project manager, suggesting that we procure more HD space. I think I said something about us 'running out of memory on our hard drive'. The PM promised to feed this back to the client... A week later, our PM said that he and the client had resolved the issue. The client will pay for a new server with a stonking 96GB of RAM!!!

That ought fix our 'memory' issue, right!!?

I mean, it also came with a 1TB HD, a second box for redundancy, dev time for migration, and additional dev time for a switch to Journald, or Logrotate, so I wasn't rushing to point out the misunderstanding... Working with the second box over RedHat Pacemaker was all new to us though, and a complete PITA.

But it was also another 'feature' to sell back to the client. They loved the sound of that. A site that couldn't go down... We made it work, but there was absolutely no real technical need for a Pacemaker cluster and 96GB*2 of RAM. It was just a simple CMS backed site.

Occasionally, that's where such complexity comes from. Not the developers themselves, but some loose cannon of a saleperson. That said, these 'sales people' may even be developers themselves. I often think that's a large part of how and why questionably complicated software exists...

Dev B: Here, put the React SPA in a Docker container and run it on some cloud its easy...

I have 100 different devs telling me "do this thing, it's easy" and it's easy for them, but now I have 100 different things to think about and make work together and devs never think about how their tiny thing fits into the big picture.

99% of web apps could be pure HTML + CSS on the front end, and Flask or something on the back end, talking pure SQL to Postgres. Really. That's all you need. And probably 99.99% of those apps that run internally to one company.

Docker facilitates the "throw a Dockerfile onto Ops and that's their problem now" mentality. That's perhaps not intentional, but choosing to over-optimize the developer experience makes life very hard for those who have to support and run the application over time.

Docker facilitates the "throw a Dockerfile onto Ops and that's their problem now" mentality. That's perhaps not intentional, but choosing to over-optimize the developer experience makes life very hard for those who have to support and run the application over time.

It also enables pushback along the lines of "your container doesn't run, and it's 100% your fault, as it is supposed to contain all its dependencies". So developers have unwittingly played into the hands of ops there ;-)

Agreed, mostly. To be fair I think that, based on my limited experience with React and Docker and Python, those 3 technologies have valid use-cases in smaller orgs. The other technologies I'm not familiar enough with to comment on.

Also if I was gonna complain about someone I wouldn't complain about devs, I'd complain about team leads, engineering managers - the folks who should be guiding devs - and, the people at the business level who choose the team leads / engineering managers.

The devs are at the bottom of the food chain; it's not their fault.

Full agreement with you on those technologies.

GraphQL is unfortunately still part of a low grade hype cycle where more and more companies are using it because "it's the next REST". But if you don't have a real need for the advantages it offers (for example a mobile app whose client side requests you can't easily change in sync with your API, or a data model that really is graph-like), it can be more cost than benefit.

React on the other hand: I've lost count of the number of small prototypes I've started in vanilla JS, thinking "this time I can just roll it myself", then ended up pulling in React. Even the simplest things are easier and simpler with it, and hugely complex applications are also easier and simpler with it. It has a fantastic API surface.

Exactly - that's my take on React.

Reply on news.ycombinator.com