diveanon

43 ms·

421.
by diveanon 6y ago
You're getting downvoted but this is exactly on point. Places that emphasize culture usually do so to compensate for their other failings. As an older dev I don't really care about culture, but instead prioritize boundaries, compe
422.
by diveanon 6y ago
Because I'm not making an assertion from a self acknowledged position of ignorance.
423.
by diveanon 6y ago
Yes, because I am the only person on the planet advocating for gql, and more broadly advocating against allowing individual developers to drop data into "buckets" or whatever point you were trying to make about how freelancing in
424.
by diveanon 6y ago
And that is why you used gql codegen and typing to limit their capability to do so. Part of the benefit of gql that people often overlook is its self documenting nature and when tied with automation tools its ability to provide a lot of fle
425.
by diveanon 6y ago
I have seen many people try to solve the "too many requests" problem by slowing expanding rest responses into "god" objects. GQL solves this problem elegantly by allowing you to specify the data that you need in a single
426.
by diveanon 6y ago
So not liking the tools your employer uses makes you less appealing as a candidate? Also, React is a hype stack now?
427.
by diveanon 6y ago
OP stated: "At best it's a band-aid around dysfunctional inter-team working." I would absolutely discount a candidate for having a moronic opinion like that.
428.
by diveanon 6y ago
GQL has solved legitimate problems for us at scale, and is flexible enough to be used on some of our smaller projects as well. I don't see the tradeoff that people are talking about, with GQL there has been nothing but upside.
429.
by diveanon 6y ago
It wasn't a threat, just a suggestion that denigrating some extremely useful tech that is saving organizations tons of time and money may not be a winning career strategy.
430.
by diveanon 6y ago
And then 50 people stuff data into different "buckets" and call them "integration points" and you spend months refactoring their horrible choices after you have identified why your services can't scale. Non sexy &qu
431.
by diveanon 6y ago
Thats the whole point, REST facilitates and often encourages bad design.
432.
by diveanon 6y ago
Some people do need to solve the same problems as FAANG, and GQL is a excellent solution to those problems. Some people also want an agile api surface so they can iterate quickly, GQL is an excellent solution to that problem. It is also an
433.
by diveanon 6y ago
What would you like to know? We have a pretty robust unified graphql api that handles millions of requests per second. Its has recently replaced siloed REST api's and now provides a common interface and RBAC for all of our data, which
434.
by diveanon 6y ago
They aren't. There is just a lot of anti-patterns floating around because of tightly coupled API / DB's. People apply this same logic to GQL and get confused.
435.
by diveanon 6y ago
This problem is solved at the db layer. If your data is not queryable in an efficient manner from the DB then it doesn't really matter if you use REST or GQL.
436.
by diveanon 6y ago
Front end developers are api consumers in the same way that a third party client is. As others have stated persistent queries are the answer. You can disable them in local dev if you want to give your devs more flexibility, but I have found
437.
by diveanon 6y ago
Because swagger docs are defined via proprietary yaml definitions whereas graphiql exposes a more useful interface that is actually derived from your code, which in most cases is automatically generated from your DB model. I've written
438.
by diveanon 6y ago
If you are writing code before reading the api docs you are doing it very very wrong. Maybe for a toy project you can just jump in and start hacking, but then who really cares what tech you decide to use?
439.
by diveanon 6y ago
Its an amazing product with an equally amazing team behind it. I am a happy customer and am in the process of converting the rest of my organization. It scales up really well and is one of the few pieces of tech I have used in the last few
440.
by diveanon 6y ago
Because those conventions are rarely ever followed. That freedom to do wrong is not a perk for most organizations, and having an opinionated and consistent data layer provides a lot of value to large teams. That coupled with GQL automation
441.
by diveanon 6y ago
I don't see how that is in any way specific to REST or GQL.
442.
by diveanon 6y ago
gRPC is coupled to individual services whereas graphql gives you an abstraction layer that allows you to expose your data in a controlled manner while allowing you the flexibility to refactor the underlying services whenever you want.
443.
by diveanon 6y ago
Graphql has already changed the world, it is used by several of the largest platforms on the planet.
444.
by diveanon 6y ago
Can you define "real proper documentation"?
445.
by diveanon 6y ago
I disagree, we are using Hasura heavily and most of our business logic is in stateless functions called via db triggers and hasura actions. It is very easy to provide additional graphql schemas that expose business logic as a remote schema.
446.
by diveanon 6y ago
I disagree 100% Graphql coupled with graphiql is extremely easy to explore. So easy in fact that we have replaced all of our api documentation with graphiql instances that we provide to our clients. I would encourage you to learn more about
447.
by diveanon 6y ago
Then why post this comment?
448.
by diveanon 6y ago
Graphql is a huge improvement over REST, and I don't see myself or any team I manage going back. We provide legacy REST api's for some of our clients, but we are using Graphql internally. Coupled with Hasura ( https://ha
449.
by diveanon 7y ago
I am talking about diving theory, not the actual activity.
450.
by diveanon 7y ago
Just quit and do something you love. Software is overrated as a career. Save yourself years of depression and find your passion and pursue it. Your friends and family will understand when they see you happy and enjoying life.

More ›