Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had a great week 😁
Start learning AI in 2025
Keeping up with AI is hard – we get it!
That’s why over 1M professionals read Superhuman AI to stay ahead.
Get daily AI news, tools, and tutorials
Learn new AI skills you can use at work in 3 mins a day
Become 10X more productive
🦥 GraphQL for Dummies
Facebook started developing GraphQL in 2012.
At first it was an internal alternative to REST.
One motivation was making it easier for clients—especially mobile clients—to request the shape of data they needed through a strongly typed schema. GraphQL can reduce some over-fetching/under-fetching and request-chaining problems, but whether it improves performance depends on how the schema and resolvers are implemented.
Later on in 2015 Facebook open-sourced it and now everyone from GitHub to Shopify uses it.
What Is GraphQL?
GraphQL is a query language and execution model for APIs built around a typed schema. Clients describe which fields they want; the server validates the operation against the schema and runs resolver logic to produce the response.
REST-ish HTTP API: resources/actions are often exposed through URLs and HTTP methods. The response shape is defined by that endpoint—though well-designed APIs can support fields, includes/expansions, pagination, and other ways to control data.
GET /users/123
GET /users/123/posts?limit=20
# The API decides what each endpoint returns.
# Some REST APIs also support sparse fields or resource expansion.GraphQL: operations are usually sent to one GraphQL endpoint, and the operation selects fields from the schema.
query {
user(id: 123) {
name # Only get what
posts { # you actually need.
title
}
}
}The 3 Concepts You Need To Know
type User {
id: ID! # ! means required
name: String!
posts: [Post!]! # [] means list
}2. Queries (Getting Stuff)
query {
user(id: 123) {
name
posts {
title
}
}
}3. Mutations (Changing Stuff)
mutation {
createPost(title: "Hello") {
id
}
}Schema + queries + mutations are the beginner core. Real GraphQL systems also have resolvers, variables, fragments, directives, pagination conventions, authorization rules, subscriptions in some systems, and operational limits.
Why GraphQL is Useful
A GraphQL operation can sometimes replace several client-side HTTP requests when the server schema exposes the related data efficiently.
// One possible REST-style client flow:
const user = await fetch('/api/users/123').then(r => r.json());
const posts = await fetch('/api/users/123/posts').then(r => r.json());
const followers = await fetch('/api/users/123/followers').then(r => r.json());If your GraphQL schema exposes those relationships, the client can express the desired shape in one operation:
query UserDashboard($id: ID!) {
user(id: $id) {
name
posts(first: 20) { title }
followers { count }
}
}That is one client request, but the server may still perform several downstream database/service calls. GraphQL moves aggregation responsibility into the API layer—it does not make backend work disappear.
The Gotchas
Caching: HTTP/REST-style GET endpoints map naturally onto browser/CDN caches because the URL and HTTP method identify the resource representation. GraphQL responses can absolutely be cached too, but a POST-to-one-endpoint model often needs application/client normalization, persisted GET queries, CDN-specific configuration, or server-side caching. Apollo is one option, not a requirement.
N+1 queries: A resolver that loads a child relationship separately for every parent can turn one GraphQL operation into hundreds of database/service calls. Batch/load patterns, joins, request-scoped loaders, and well-designed data-access layers help prevent this.
Authorization: A typed schema tells clients what fields exist; it does not mean every authenticated user is allowed to read every field. Enforce authorization in business/data-access boundaries and be especially careful with nested relationships.
Query cost and denial of service: Clients control query shape, so “give me every deeply nested relationship 500 times” can be expensive. Use pagination, maximum limits, depth/complexity/cost controls, timeouts, persisted/allow-listed operations where appropriate, and rate limits based on actual cost—not only request count.
Partial results and errors: GraphQL can return useful data and errors in the same response. Clients should not assume “HTTP 200 means every requested field succeeded.” Define how your application handles nullable fields and partial failures.
Pagination: Do not expose unbounded lists such as posts { ... } in production schemas. Cursor-based pagination is common because it behaves better as data changes, though offset pagination can still be appropriate for some use cases.
Schema evolution: GraphQL schemas are designed to evolve by adding fields/types and deprecating old fields rather than changing existing contracts underneath clients. Track field usage before removing deprecated fields.
When to Use GraphQL Vs REST
GraphQL:
Several clients need different combinations of the same connected data.
You want a strongly typed discoverable schema and clients to choose fields.
Your API layer can efficiently aggregate multiple backing services/data sources.
Your team is prepared to own resolver performance, query-cost limits, field-level authorization, schema evolution, and GraphQL-specific observability.
REST:
Resource-oriented HTTP endpoints already fit the product well.
Simple HTTP/CDN caching and standard HTTP semantics are especially valuable.
The API is straightforward and the extra GraphQL server/client machinery would not solve a real pain point.
Your team is already productive with REST-style contracts and can solve over/under-fetching with endpoint design, includes/expansions, or backend-for-frontend patterns.
The Truth
GraphQL isn't better than REST. It solves different problems.
GraphQL grew out of Facebook’s client/data-fetching needs, not because REST as an architectural style is universally bad.
Most apps can work well with REST-style HTTP APIs, GraphQL, RPC, or a mix. “This page makes 10 requests” is a symptom to investigate, not an automatic command to migrate: parallelism, caching, payload size, server aggregation, latency, client complexity, and backend cost all matter.
If you want to try using GraphQL, I think the best place to start is here:
If you want to keep learning
APIs explained — the foundation GraphQL builds on.
SDKs vs APIs — how developer toolkits wrap APIs.
Webhooks explained — event-driven communication when polling is overkill.
Amazing feedback as always!
Den: All of your chats, docs and agents in one place.
I thought this looked really cool and I hope this succeeds!
What is it?
Den is basically a platform that combines your chats, docs, and AI agents into one place.
Think Slack + Notion + AI agents/workflows.
Instead of copy-pasting between ChatGPT, Slack, and your documents/notes, you can have everything in one place.
You and your team can also create AI agents/workflows to automate tasks all without switching tabs.
They currently have over 50+ integrations and these agents keep working in the background even if you log off.
Which means you can multi-task or sleep, and come back to updated docs, analyzed data, and completed tasks.
Thanks to everyone who submitted!
andregarcia0412, Kauketz, bakzkndd, xanerin, M3dvidek, pixelated-sys, jw123450, GabrielDornelas, JamesHarryT, SabhyaAggarwal, and ariatheroyal.
The Actual Memory Size of Your USB Flash Drive
Create a function that takes the memory size (ms) as an argument and returns the actual memory size.
Examples
actualMemorySize("32GB")
output = "29.76GB"
actualMemorySize("2GB")
output = "1.86GB"
actualMemorySize("512MB")
output = "476MB"Notes
The actual storage loss on a USB device is 7% of the overall memory size!
If the actual memory size was greater than 1 GB, round your result to two decimal places.
If the memory size after adjustment is smaller then 1 GB, return the result in MB.
For the purposes of this challenge, there are 1000 MB in a Gigabyte.
How To Submit Answers
Reply with
A link to your solution (github, twitter, personal blog, portfolio, replit, etc)
or if you’re on the web version leave a comment!
If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!
New video coming out this week!
I’m almost done with it, hopefully I have it ready Thursday.
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.
