Comment by firecall | Hacker News Reader

Comment by firecall | Hacker News Reader

This seems like a good place to share a horrific experience I'm currently enduring:

I recently took over a a Django API + React front end project.

What should should have been a basic CRUD application with some calendaring and video calling added turned into a nightmare and costs of over a million dollars for my client.

I'm a Rails and iOS dev mostly, so I have a bias, but here we go:

1) Using GraphQL for a business process CRUD app is a nightmare. Building on Django's ORM with Graphene, then on the frontend with Apollo Client, Queries/Mutations, and React with some Redux mixed in is a nightmare of hard to know database and business logic paths.

2) On the Django side, having their Views and Models (mostly Models) handle business logic, and then constructing a Graphene based GraphQL layer to be consumed by another layer GraphQL Queries/Mutations via React is a mess, for what is essentially a bunch of forms on the frontend

3) Splitting out React Components into Atoms/Molecules/Organisms/Pages/Templates and more has been a nightmare to work with. Seriously - do you really need to build an Atom for a button that you pass the title text too?

The whole project is impossibly fragile.

Say what you will about Rails, but you can build a robust and functioning CRUD app that solves business problems without the need for developers to hack through a jungle of abstractions!

Sorting this all out for client has almost killed me and burned me out!

> Using GraphQL for a business process CRUD app is a nightmare

Could not agree more. GQL is such a big mistake in so many use cases.

Care to elaborate?

In my experience, it’s unnecessary layers of abstraction for benefits that are not realised unless you are at some level of scale where you know it does.

Facebook invented React and GraphQL for good reasons. But many of those reasons don’t apply but the implementation does add development time and code complexity.

In a React and Django Graphene API situation, you have to write GraphQL queries and mutations on both sides.

The idea being you might write a GraphQL query that only retrieves exactly the data you need and nothing more.

Which is great when those optimisations improve customer experience, but for most of the SMEs I work with, they do not make any perceivable difference.

GraphQL is layering on complexity and additional libraries when a good old fashioned REST API does everything you need anyway!

I guess GraphQL is fashionable right now!

"Mit Kanonen auf Spatzen schießen" : shooting sparrows with a cannon.

This is the story of software development, nobody uses a shotgun to get the job done quickly, because afterwards they're out of job.

It's borderline criminal but all the nonsense is about scamming your employer to pay you hefty money for many years to build the Kaiser Wilhelm Gun.

And the "geniuses" disappear right when the project gets to be delivered. Like the past few projects I worked on, the original developers that shall remain unnamed would spit out code like there was no tomorrow, always latest fashion and of course throw one or two badly broken ad-hoc domain specific languages pulled out of their ass. Get paid for two years or so and in 6 months before scheduled release, suddenly "be assigned to an uttermost important project", in fact another two years of jacking off with no responsibility. While their piece of art gets transferred to suckers like me who only need to do the "easy" finishing touches and get it released. If it succeeds, praise is in them, if it fails, it's my fault.

Where do I get one of these jobs where you make every task take longer than it should but get promoted instead of fired?

DM me when you find out ;-)

If you're providing an API that's well defined and constrained in scope (i.e. a typical CRUD API where you're creating/modifying normalized objects in a non-changing object hierarchy), then graphql is usually just a shitload of unnecessary overhead.

Examples that come to mind:

1. An internal API where you own all the clients (you own every query; optimize them.)

2. An API that deals with objects where scopes aren't going to vary (i.e. if your clients are fetching the same 6 basic queries every time, you're not getting benefits out of GQL).

3. APIs that are write/update heavy. Every mutation is the same amount of work (or more) that a REST controller would have to deal with, but you have the overhead of the GQL library on top.

Basically: everything is just JSON on the wire anyway. Stop paying the overhead penalty of GQL unless you have a zillion clients and a massive object graph that's going to be queried in unpredictable ways. Typical REST libraries make backend code management and structure MUCH cleaner than GQL, with much more obvious points for caching, query optimization, etc.

What's the plan, full (parallel) rewrite or refactor?

First order of business:

1) Fix the issues with email notification logic

2) Get them off of the very expensive & complicated AWS stack We've migrated staging and testing to a DO Droplet with DO MySQl/Redis stack. Moving to DO with plenty of headroom is a 10th of the cost of AWS!

3) After that, not sure at this stage. Most likely we will refactor low hanging fruit.

A ground up rewrite would require knowing all of the business logic. We'll just begin cleaning it up and getting it into a manageable state. We don't know what we don't know yet! :-)

I'm in a similar situation to yours, and I've kind of settled on a similar approach: put out the most pressing fires and reassess 3-6 months down the line. At first I had thoughts to refactor but now I just don't want to deal with the complexity, not to mention I have end-users pressing me. I'll have to tolerate the spaghetti, but at least make it produce correct output.

Best of luck with the migration to DO :)

Reply on news.ycombinator.com