Readit News logoReadit News
Seattle3503 commented on GraphQL: The enterprise honeymoon is over   johnjames.blog/posts/grap... · Posted by u/johnjames4214
jakubriedl · 8 hours ago
I 100% agree that overfetching isn't the main problem graphql solves for me.

I'm actually spending a lot of time in rest-ish world and contract isn't the problem I'd solve with GraphQL either. For that I'd go through OpenAPI, and it's enforcement and validation. That is very viable these days, just isn't a "default" in the ecosystem.

For me what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution especially in M:N client-services scenario in large systems. Having the mindset of "client describes what they need" -> "graphql server figures out how to get it" -> "domain services resolve the part" makes long term management of network of APIs much easier. And when it's combined with good observability it can become one of the biggest enablers for data access.

Seattle3503 · an hour ago
> For me what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution especially in M:N client-services scenario in large systems. Having the mindset of "client describes what they need" -> "graphql server figures out how to get it" -> "domain services resolve the part" makes long term management of network of APIs much easier. And when it's combined with good observability it can become one of the biggest enablers for data access.

I've seen this this solved in REST land by using a load balancer or proxy that does path based routing. api.foo.com/bar/baz gets routed to the "bar" service.

Seattle3503 commented on Price of a bot army revealed across online platforms   cam.ac.uk/stories/price-b... · Posted by u/teleforce
mmooss · 10 hours ago
> They argue that SIM card regulation could help “disincentivise” online manipulation, and say their tool can be used to test policy interventions the world over.

Their solution is to deanonymize communication, which you're probably familiar with. That's not a tool for social good, but for government power. We could give government virtually any power, if we assume it will be used only for good.

What's a solution to online manipulation that is actually a social good or cannot be misused? What's a freedom-promoting technology that can replace the disaster that is current social media?

Seattle3503 · 6 hours ago
Yeah I don't think we should expect cell networks to secure or protect these third parties.
Seattle3503 commented on Why Twilio Segment moved from microservices back to a monolith   twilio.com/en-us/blog/dev... · Posted by u/birdculture
dragonwriter · a day ago
> If your software solves a tightly connected business problem, microservices probably aren't the right fit.

If your software solves a single business problem, it probably belongs in a single (still micro!) service under the theory underlying microservices, in which the "micro" is defined in business terms.

If you are building services at a lower level than that, they aren't microservices (they may be nanoservices.)

Seattle3503 · a day ago
How do people usually slice a single business problem?
Seattle3503 commented on Why Twilio Segment moved from microservices back to a monolith   twilio.com/en-us/blog/dev... · Posted by u/birdculture
GeneralMayhem · a day ago
I worked on building this at $PREV_EMPLOYER. We used a single repo for many services, so that you could run tests on all affected binaries/downstream libraries when a library changed.

We used Bazel to maintain the dependency tree, and then triggered builds based on a custom Github Actions hook that would use `bazel query` to find the transitive closure of affected targets. Then, if anything in a directory was affected, we'd trigger the set of tests defined in a config file in that directory (defaulting to :...), each as its own workflow run that would block PR submission. That worked really well, with the only real limiting factor being the ultimate upper limit of a repo in Github, but of course took a fair amount (a few SWE-months) to build all the tooling.

Seattle3503 · a day ago
I've heard horror stories about Bazel, but a lot of them involve either not getting full buy in from the developer team or not investing in building out Bazel correctly. A few months of developer time upfront does seem like a steep ask.
Seattle3503 commented on Why Twilio Segment moved from microservices back to a monolith   twilio.com/en-us/blog/dev... · Posted by u/birdculture
mjr00 · a day ago
> If you communicate with one another you are serializing and deserializing a shared type.

Yes, this is absolutely correct. The objects you send over the wire are part of an API which forms a contract the server implementing the API is expected to provide. If the API changes in a way which is backwards compatible, this will break things.

> That shared type will break at the communication channels if you do not simultaneously deploy the two services.

This is only true if you change the shared type in a way which is not backwards compatible. One of the major tenets of services is that you must not introduce backwards incompatible changes. If you want to make a fundamental change, the process isn't "change APIv1 to APIv2", it's "deploy APIv2 alongside APIv1, mark APIv1 as deprecated, migrate clients to APIv2, remove APIv1 when there's no usage."

This may seem arduous, but the reality is that most monoliths already deal with this limitation! Don't believe me? Think about a typical n-tier architecture with a backend that talks to a database; how do you do a naive, simple rename of a database column in e.g. MySQL in a zero-downtime manner? You can't. You need to have some strategy for dealing with the backwards incompatibility which exists when your code and your database do not match. The strategy might be a simple add new column->migrate code->remove old column, including some thought on how to deal with data added in the interim. It might be to use views. It might be some insane strategy of duplicating the full stack, using change data capture to catch changes and flipping a switch.[0] It doesn't really matter, the point is that even within a monolith, you have two separate services, a database and a backend server, and you cannot deploy them truly simultaneously, so you need to have some strategy for dealing with that; or more generally, you need to be conscious of breaking API changes, in exactly the same way you would with independent services.

> The logical outcome of this is virtually identical to a distributed monolith.

Having seen the logical outcome of this at AWS, Hootsuite, Splunk, among others: no this isn't true at all really. e.g. The RDS team operated services independently of the EC2 team, despite calling out to EC2 in the backend; in no way was it a distributed monolith.

[0] I have seen this done. It was as crazy as it sounds.

Seattle3503 · a day ago
Managing two services is very different than managing 140. And databases have a lot of tooling, support, and documentation around migrations.
Seattle3503 commented on Why Twilio Segment moved from microservices back to a monolith   twilio.com/en-us/blog/dev... · Posted by u/birdculture
threethirtytwo · a day ago
Yeah. that's a bad thing right? Maintaining backward compatibility to the end of time in the name of safety.

I'm not saying monoliths are better then microservices.

I'm saying for THIS specific issue, you will not need to even think about API compatibility with monoliths. It's a concept you can throw out the window because type checkers and integration tests catch this FOR YOU automatically and the single deployment insures that the compatibility will never break.

If you choose monoliths you are CHOOSING for this convenience, if you choose microservices you are CHOOSING the possibility for things to break and AWS chose this and chose to introduce a backwards compatibility restriction to deal with this problem.

I use "choose" loosely here. More likely AWS ppl just didn't think about this problem at the time. It's not obvious... or they had other requirements that necessitated microservices... The point is, this problem in essence is a logical consequence of the choice.

Seattle3503 · a day ago
> Yeah. that's a bad thing right? Maintaining backward compatibility to the end of time in the name of safety.

This this is what I don't get about some comments in this thread. Choosing internal backwards compatibility for services managed by a team of three engineers doesn't make a lot of sense to me. You (should) have the organizational agility to make big changes quickly, not a lot of consensus building should be required.

For the S3 APIs? Sure, maintaining backwards compatibility on those makes sense.

Seattle3503 commented on Denial of service and source code exposure in React Server Components   react.dev/blog/2025/12/11... · Posted by u/sangeeth96
awestroke · 3 days ago
Vanilla react, ts-rest
Seattle3503 · a day ago
Gotcha, that makes sense. Thanks!
Seattle3503 commented on EFF launches Age Verification Hub   eff.org/press/releases/ef... · Posted by u/iamnothere
stvltvs · 3 days ago
Is your question about what authoritarian states do with information about everyone's private lives?
Seattle3503 · 2 days ago
No, it's a question about how a government would break cryptographic protocols, or force others to.

If the identifiers are pseudonyms, if the government compelled someone to share their user IDs, all the government would see are basically a bunch of UUIDs keyed to that provider.

So what specific actions are you talking about. What is your threat model?

Seattle3503 commented on SQLite JSON at full index speed using generated columns   dbpro.app/blog/sqlite-jso... · Posted by u/upmostly
Seattle3503 · 3 days ago
It says full speed, but no benchmarks were performed to verify if performance was really equivalent.
Seattle3503 commented on Denial of service and source code exposure in React Server Components   react.dev/blog/2025/12/11... · Posted by u/sangeeth96
awestroke · 3 days ago
We're migrating away from both Next and Vercel post-haste
Seattle3503 · 3 days ago
What are you migrating to? Vanilla React?

u/Seattle3503

KarmaCake day2121April 16, 2021View Original