I would say that working as a programmer in a corporate environment is a bit similar to being paid to be a novel writer by people who don't know how to read, but absolutely want to tell you how to do your job properly.
The bar for things happening in the world isn't "do we really need this", it never has been. It's more like "does anyone have any incentive to do this", and with AI plenty of companies and people do.
I think like with any technology, it’s not so much “we need it” but “who has access to it”. Unless you consider genAI totally useless (which is a stretch) effective access is an impactful consideration, society-wise
Listen, have you ever observed a troll writing a book?
Really? Currency is a scam. You get paid in paper, pay taxes on it, which gets stolen( sorry in edged) in corrupted corps, with a debt system where you are just a slave of your mortgage - unless you're a clever troll, and you bought 10btc 10 years ago, write a book to put the price down, while at the same time, being the most biased possible to trigger HN readers in the hope of getting a Google page rank.... Pathetic.
As a contractor choosing max 3 months contract after more than a dozens of quits.
In my experience, 95% of tech team are disfunctional beyond repair. It pisses me off everytime, and I chose to let it go, stopping the energy hemoragy, and I usually take 2-3 months off, recharge. Now it's been 18 months, no income, enjoying life in SEA. At the end of the day, month, year, decade, I own less, but my life is much more interesting than dealing with mediocre people who knows how to fake it very well, knowing they'll never make it, happy to take the pay check.
Take long holidays. 6 months minimum traveling around.
if you have a family, or a tight mortgage - I'm sorry for you. As I don't have a straight answer. but 6 months away from keyboard is a strict minimum.
Well said.
I would also add that it is perfectly fine to have a list of red flags, and it is perfect fine to define your own bondaries.
Graphql is a red flag for me too, as well is React and node.js, and even git to some extend.
I love simplicity when designing web apps, their backend, their frontend and the deployment process in between.
Although the tech is old , I came up that vue3+pouchdb+quasar is an amazing combination for a stable replicable dev environment, pwa, supports offline usage, and introduces possible p2p replication between browser's pouchdb instances trough webrtc.
React , imo, is a good over engineered library suffering from fragmentation.
Angular is less fragmented, and Vue is the most elegant, performant and versatile of the 3.
Good Devs choose Vue after having worked with both react and angular.
React Dev never tried Vue, nor Angular Dev try React.
Vue Dev usually know all 3.
Having a red flag like graphql can tell a lot about technical overview and experience in failure.
Graphql solves a caching issue that Facebook has. Makes the frontend team life easy, making the backend team life hell , big big hello. Scope changes in the backend are terrible.
Unless your team is engineered driven, and engineers take tech decision, and setup the sprints, going graphql in the backend is a recipe for disaster.
This is like hating HTTP. GraphQL is a spec, not an implementation. GraphQL doesn't even mandate a network transport.
Solutions like Prisma, Hasura, and Postgraphile make GraphQL dead simple to implement compared to REST when exposing relational data.
AWS AppSync allows for a fully managed "serverless" experience as long as you're willing to do the schema creation grunt work and write Velocity templates. (FWIW, I'm not a fan, but it's still an option.)
Apollo (and Netflix DGS) are for when you're writing everything yourself, and you just need a simple API to tie in to the GraphQL spec in exchange for having to write/optimize/maintain it all.
The bright side to GraphQL is that you have choices, and when you present your "menu" of options, clients can grab what they need. Whereas on the REST side, any new requirements in calling requires direct interaction with the backend team and a new endpoint.
Honestly, server-based data access doesn't get any simpler than Postgraphile, but I totally see how you could get burned by an ill-fitting solution. However that is not GraphQL's fault. You might as well blame HTTP for problems you've had with Node/Express even though you've got other options in every programming language not to mention "pre-baked" solutions like Apache, Nginx, etc.
It's just a spec defining interaction, not a prescription for how that spec is implemented. It is also not a silver bullet. Right tool, right job, and all of that.
First time thinking about the situation, sounds to me like you'd need to just make a new set of roles no? I can't imagine they'd have version support for that, not like the underlying datastore does
Nowadays a full stack dev is an intermediate Fe dev, with junior backend skills. He will make your backend un-maintainable. Get a proper master on a proper contract rate to design your architecture.
I totally agree, the list of frontend pro is super cool, especially the subscribe real time API, but on the backend, it is a pure nightmare, either using very cutting edge third parties, the authorization is a super big pain in the butt to implement. Cool you got a graph, now you need to make sure only user a can edit row b, there is the shortest path, but the data storage is still centralised.
And I doubt there will ever be any PWA POSSIBLE with graphql, so no offline usage, no local storage , nothing cool toward the web6 decentralised stack.
