https://kodeverk.com in Norwegian only (blog is en English though), but I do fractional CTO work for the local market. Lots of fun, and trying to package it in an atteactive way.

Agree whole-heartedly. The strong contracts are the #1 reason to use GraphQL.

The other one I would mention is the ability to very easily reuse resolvers in composition, and even federate them. Something that can be very clunky to get right in REST APIs.

Contracts for data with OpenAPI or an RPC don't come with the overhead of making a resolver for infinite permutations while your apps probably need a few or perhaps one. Which is why REST and something for validation is enough for most and doesn't cost as much.

re:#1 Is there a meaningful difference between GraphQl and OpenAPI here?

Composed resolvers are the headache for most and not seen as a net benefit, you can have proxied (federated) subsets of routes in REST, that ain't hard at all

> Composed resolvers are the headache for most and not seen as a net benefit, you can have proxied (federated) subsets of routes in REST, that ain't hard at all

Right, so if you take away the resolver composition (this is graph composition and not route federation), you can do the same things with a similar amount of effort in REST. This is no longer a GraphQL vs REST conversation, it's an acknowledgement that if you don't want any of the benefits you won't get any of the benefits.

There are pros & cons to GraphQL resolver composition, not just benefits.

It is that very compositional graph resolving that makes many see it as overly complex, not as a benefit, but as a detriment. You seem to imply that the benefit is guaranteed and that graph resolving cannot be done within a REST handler, which it can be, but it's much simpler and easier to reason about. I'm still going to go get the same data, but with less complexity and reasoning overhead than using the resolver composition concept from GraphQL.

Is resolver composition really that different from function composition?

Local non-utility does not imply global non-value. Of course there's costs and benefits, but it's hard to have a conversation with good-faith comparison using "many see it as overly complex" -- this is an analysis that completely ignores problem-fit, which you then want to generalize onto all usage.

People can still draw generalizations about a piece of technology that hold true regardless context or problem fit

One of those conclusions is that GraphQL is more complex than REST without commensurate ROI

Yeah, that’s a huge over-generalization

That was a fun little game! The hinting felt appropriate, only thing I didn't really like was that it got a bit "cramped" towards the end moving things around. Will try it again tomorrow. :)

Thanks! Yeah it’s tricky since I wanted to make it work the same on small phone screens as large computer screens, so the place is limited.

I want to explore a future feature where dropping a tile “pushes” other tiles out of the way that will hopefully make it feel less cramped

It’s probably the same way monks copying books felt when the printing press came along. “Look at this mechanical, low-quality copy. It lacks all finesse and flourish of the pen!”

I agree with you that it is sad. And what is especially sad is that the result will probably be lower quality overall, but much cheaper. It’s the inevitable result of automation.

Many things have become higher quality with automation. Eg. consider CNC machines, metal machining etc.

Thank you for taking the time to do a thorough read, I just skimmed it, and the prose is certainly not for me. To me it lacks focus, but as you say, this may be the style the readers enjoy.

And it also, as you say, really reuses words. Just reading I notice "phosphorescence" 4 times for example in this chapter, or "ooze" 17 times (!).

It is very impressive though that it can create a somewhat cohesive storyline, and certainly an improvement over previous models.

Sad to see it go! Especially with recent improvements.

Anyone know how large the team was behind this app? The delivered impressively!

Is it not more likely the # of deaths are related to obesity for example, where US has 5-7 times as many obese as Japan for example. Which matches the % deaths statistic you have there quite well.

In other words: it's not easy. There are many factors at play.

I discounted 10x to 2x, or 20% of the effect.

While I’m not a consumer of this product, I met some of the product designers at the medieval week in Visby, Sweden today. And that the company supports a project like this, which is clearly a passion project, displays joy. After this I think teenage engineering is a great place to work. Not just a SV product factory.

The web distribution certainly makes it much more viable to offer apps outside the App Store, and have reasonable conversion rates. Now PornHub or similar could easily offer their app from the website.

With this available (which is a much simpler system), all of the App Marketplace-convoluted setups seems redundant.

Looker might look attractive, but it is missing so many basic features it is not competitive. You can't even query a view in BigQuery, you can't use window functions in data sources. All error messages are entirely opaque. Access management is very limited etc.

PowerBI / Tableau is much more full-featured.