Stop Building CRUD APIs
Most APIs are shaped like a database, and the clients pay for it.
Most Laravel APIs start the same way: a resource controller, a few routes, and a clean set of CRUD endpoints. It looks good - until real behaviour shows up. In this live coding session, we’ll take a typical CRUD API and push it to its limits, exposing where it starts to fall apart. From there, we’ll refactor it into something that reflects how systems actually work - focusing on actions, intent, and clarity over convention. We’ll cover where CRUD works (and where it doesn’t), why “update” endpoints become a dumping ground, how to model real behaviour in your API design, and a practical structure you can apply in Laravel today. No slides, no theory overload - just real code, real problems, and better ways to approach them.
Reliable API Calls Without the Stress
The third-party call that does not fail, it just gets slow, and takes your workers with it.
Most advice about calling somebody else's API is about failure: catch the exception, retry with a backoff, put a circuit breaker in front of it. The calls that hurt in production tend to succeed. A dependency that starts answering in eleven seconds instead of two hundred milliseconds still returns a perfectly valid 200, so nothing retries and nothing trips, and every worker you have ends up sitting inside that call waiting for it. Laravel's HTTP client will wait thirty seconds by default before it gives up on one.
This talk works through the two problems retries do not solve. The first is the dual write. You save a record and tell another system about it, and whichever order you do those in, there is a gap where one happens without the other. We close it with the Outbox pattern in Laravel, so the call is made from committed state and still goes out when the queue falls over. The second is the slow dependency, where the fix is a timeout somebody chose on purpose and a cap on how much of your capacity any one integration is allowed to take. You leave with patterns you can apply to the integrations you already have, and a way to tell which of them need it.
The Rewrite You Should Not Do
Why the team proposing the rewrite usually already knows, and what to do instead.
Every mature codebase eventually produces a list. The test suite mostly hits the database, one model is load-bearing for six features, the bulk tool and the endpoint disagree about the same rule, and there is an interface that has never had a second implementation. Somebody reads the list and says what somebody always says: we should rewrite it.
A rewrite looks cheap because it compares the good parts of a new system against all of the old one. The old one holds years of corrections nobody wrote down. Every strange branch is there because something happened in production, and a rewrite rediscovers each of them one incident at a time, while shipping nothing until the day it is finished. This talk covers what to do instead: strangle the parts that genuinely need replacing behind a seam you can move traffic across, fix in place when a change is provably behaviour preserving, and write down and leave alone the parts nobody goes near. The deciding factor is churn. Coupling only costs you when you touch it, one git command shows where the team actually spends its time, and the overlap between that and the list is your real backlog. It is usually much shorter than the list you started with.
Scaling APIs in Laravel
Finding the call that is actually costing you, rather than the one the dashboard shouts about.
When an API gets slow, the usual response is to scale all of it, with bigger servers and a cache in front of everything. The cost usually sits in one or two calls, and the one getting blamed on the dashboard is often not one of them.
This talk works through an API using the tools Laravel already ships with: route structure, response shape and filtering, caching, and the write operations that start to hurt first as traffic grows. Each change starts from the same question, which request is costing you and why, so the work goes where the time is actually going rather than where the graph is loudest.
