641–650 of 721 posts
Earlier quoted context omitted.
The options we have today are not the options we had at the time Facebook introduced React. React solved tons of browser shortcomings that are finally being fixed in the actual browser.
I don't think that's true, web components are not equivalent to libraries like react and vue.
Earlier quoted context omitted.
I'm not pretending anything and I hate XML. I would still rather use it than HL7, because it's a hierarchical tree of data and HL7 is not. OP's point is that almost nobody wants to use XML anymore; my point is that almost nobody wants a Ford Model T as their daily driver anymore either, and yet it was still the future, in a certain sense.
Do you think FHIR is acceptable? It feels like a cross between JSON and HL7 to me.
Some things were a bit weird. From memory it had big lists of records all mixed together as the implementation of references.
Earlier quoted context omitted.
Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code
Sounds good in theory. In practice, what I've seen is people don't just do single page endpoints with shared services, they follow this all the way down into the services and so you end up with lots of duplicate looking code. This isn't a problem until the application gets big enough and now you have business logic that should be the same spread out across an app. This leads to weird bugs where something that should…
There is no easy or simple or final solution. The solution is to do the hard work of software engineering and catch this stuff at code review time or to plan and do refactoring later when you realize something needs normalization. I wish developers would just accept that software engineering is hard and do the hard work necessary.
There's that whole "the best software engineer is lazy because he will automate stuff", but that does not give anyone a license to automate stuff in an unmaintainable way. Automating stuff is hard and there is no easy way out.
I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…
One of the things that really burned me out over the years is how many times I would say something to the effect of "Maybe using GraphQL is over complicating the process and we should just use the old tried and true methods" and I would get drowned out by everyone chasing the latest thing or derided for not wanting to try something new. "Maybe implementing CORBA for message passing is over complicating it." "Maybe us…
Earlier quoted context omitted.
Mongo is great if you want a distributed replicated log. Existing tools sorely lack. (Postgres and Kafka are broken by design.)
Curious as to why you think Kafka is broken by design?
2. No reliable way to handle queue overflow.
Combine both and you are 100% guaranteed to have an incident. (I guess it keeps devops and sysadmins employed, though.)
Earlier quoted context omitted.
The problem with XML is precisely that it is so much more than simple hierarchical, nested trees of data. The fact that in a casual conversation XML is reduced to hierarchical trees of data pretending the rest of XML does not exist more than proves OP's point.
I'm not pretending anything and I hate XML. I would still rather use it than HL7, because it's a hierarchical tree of data and HL7 is not. OP's point is that almost nobody wants to use XML anymore; my point is that almost nobody wants a Ford Model T as their daily driver anymore either, and yet it was still the future, in a certain sense.
XML is so much more than hierarchical data serialization format. In a typical conversation XML generally means "JSON-compatible subset of XML" as if the other parts do not even exist. Like in the meme "Javascript vs Javascript the good parts".
XML never really took off, only the parts that make up "different flavor of JSON".
Earlier quoted context omitted.
> In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple. You should log deprecation warnings. But also if the client is composing urls/params manually then you are not doing REST, you are doing RPC. Rest APIs should mainly use HATEOAS hyperlinks to obtain a resource.…
REST is just a short name for RPC over JSON. Nobody does real Fielding's REST.
Earlier quoted context omitted.
This is why the Rails community should be applauded in my book, for their dogged determination that we should keep it a “one person” framework. Yes it may not be as performant, type safe or flashy on the front end but my god it’s productive. At my startup there are 7 devs who can all do tickets across the stack and as we grow I think it would be good if we could resist the pressure to silo and specialize
> but my god it’s productive. It really is. Regrettably, I've drifted away from it in large part because of client requirements for more "modern" and "maintainable" solutions (e.g. Python or Node; I'll take Python every time, thanks). Django comes very close in terms of productivity (and is better in some ways: auth, admin, etc.) but the Rails CLI, generators and community (not sure if this is still relevant) give it…
I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…
Earlier quoted context omitted.
GraphQL "solves" the ability to ignore an unneeded field in a response? Revolutionary.
Even in REST, I’m sure you don’t use every field from every request? In fact, such tight coupling between FE and BE in REST is strongly advised against. And “wasted fields” was never a problem graphql was trying to solve.