Evaluate the purpose and structure of your project before selecting technologies. Determine whether you require a request-response setup or an event stream for information flow. Consider aspects like immediate versus long-poll processing and whether existing technologies meet your needs. Avoid defaulting to popular solutions like GraphQL without critical assessment, as this may lead to inadequate implementations. Analyze past experiences with tools, weighing the trade-offs of exposing databases directly versus implementing a designed API. Ensure customization options are in place for access controls and logic, to align the technology with specific application requirements.
Jerod is back with another “It Depends” episode! This time he’s joined by Kris Brandow from Go Time and they’re talking all things API design. What makes a good API? Is GraphQL a solid choice? Why do we do REST wrong? And WTF does HATEOAS mean, anyway?
Leave us a comment
Changelog++ members save 10 minutes on this episode because they made the ads disappear. Join today!
Sponsors:
- Neon – The fully managed serverless Postgres with a generous free tier. We separate storage and compute to offer autoscaling, branching, and bottomless storage.
- Sentry – Get $100 towards your error monitoring with Sentry! Use the code
changelog
.
- Fastly – Our bandwidth partner. Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform. Learn more at fastly.com
- Fly.io – The home of Changelog.com — Deploy your apps and databases close to your users. In minutes you can run your Ruby, Go, Node, Deno, Python, or Elixir app (and databases!) all over the world. No ops required. Learn more at fly.io/changelog and check out the speedrun in their docs.
Featuring:
Show Notes:
Something missing or broken? PRs welcome!