Evolving an API Without Breaking Everyone
Most teams retire part of an API by deleting it and finding out who cared.
Renaming a field feels like a refactor. To every integration reading that field, it is an outage nobody warned them about. Once enough people depend on your API, every behavior you expose is part of the contract, including the ones you never meant to promise. Most of what keeps an API safe to change is decided long before you need to change it, so that is where I will start: designing the contract before the code, keeping your database schema out of your responses, and making errors look the same everywhere with Problem Details. Then response shapes and pagination with room to grow, rate limits a consumer can read without guessing, and idempotency keys for the operations that must not happen twice. I will argue for versioning from the first commit, and show why fixing a bug can be a breaking change.
Then the half that usually gets skipped, which is retiring things properly. We will build middleware that sends Deprecation and Sunset correctly, and those two headers do not take the same date format, which I found out by getting it wrong. We will work out which consumers are still calling a deprecated endpoint, and use brownouts so that removal day turns out to be a non-event. The examples are Laravel. The ideas work on any PHP API. You will leave with changes you can make to an existing API next week, and a way of evolving it that does not punish the people who built against it.
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
What a fresh Laravel install already gives you for a fast API, before you add a single package.
Most of what makes a Laravel API fast is already in a fresh install. Before reaching for a package or a bigger server there is a lot to be had from the framework and the language on their own, and every package you do not add is one less thing to wait on when the next Laravel version lands.
This talk builds an API up live with nothing beyond a new Laravel project. Versioned route files, so a single endpoint can move to v2 on its own. API resources and simple pagination that send a client what it needs, without the link labels and active flags it never reads, in a response shape that stays consistent, which matters more than whichever standard you pick. Caching that never goes stale, stored indefinitely, cleared by a model observer when the data changes and warmed on a schedule. And write operations pushed to a queue, answering 202 Accepted instead of holding the request open while the database catches up.
