Frequent, small changes are really a good practice.
Then we have things like trunk-based development and continuous integration.
Frequent, small changes are really a good practice.
Then we have things like trunk-based development and continuous integration.
The key is to hold the same schema on the database as on the graphql and use tooling that can translate a gql query into a single query.
This appears as an opinion rather than an argument. Could you explain what you find bad about the design?
In any case, I believe a DB per backend service isn't a decision driven by the frontend - rather, it's driven by data migration and data access requirements.
With SQL you need to explicitly test all queries where the shape granularity is down to field level.
When you map data onto an object model (in the dto sense, not oop sense) you have bigger building blocks.
This gives a simpler application that is more reliable.
Obviously you need to pick a performant orm - and it seems a lot of people in these threads have been traumatized.
Personally, I run a complex application where developers freely use a graphql schema and requests are below 50ms p99 - gql in translated into joins by the orm, so we do not have any n+1 issues, etc.
I've most often seen this countered through data loaders (batched queries that are merged in code) instead of joins, or query whitelists.
Deleted Comment
EGreg didn't mean to say that VS Code used to be Atom, or is based on Atom, though I agree his wording was a bit ambiguous and it could be interpreted that way.
During that time, Atom was released (2014). But I don't recall it ever being especially popular - at least outside of the JS ecosystem. For one thing, it was kind of slow on release (people still complain about Electron!) and while it offered a lot of customization, these customization often seemed to worsen its performance. It was VS Code that really seemed to draw a wider audience from my perspective.
That said, I switched to vim around the time Atom came out, so I may be out of touch. I doubt there are any solid stats anywhere...
This doesn't make much sense to me.
To put the strongest face on it, by "cracked" youtube, you mean a version that shows the cracker's ads and maybe somehow generates extra clicks (or whatever) so they can get money out of it?
Cracked spotify? In my mind that's just like YouTube, almost entirely server-side. I guess you're talking about hijacking ads here, too? I feel like a "real" crack of Spotify would let you listen to music for free, but that should be impossible (unless their SWE's are incompetent).