Web Frameworks

@After is advice that runs after a matched method finishes — whether it returned normally or threw an exception. It behaves like a finally block, so it is used for cleanup. It cannot see the return value or the exception.

@AfterReturning is AOP advice that runs after an advised method finishes successfully (returns normally). It does NOT run if the method throws an exception. It can read the returned value but cannot replace it.

@AfterThrowing is an aspect advice method that runs only when the matched method (join point) exits by throwing an exception. If the method returns normally, it does not run.

@Around wraps a method call. It runs code before and after the target method. You must call proceed() to actually run the target method; if you skip it, the target never executes and you return your own value instead.

@Before advice is aspect code that runs before a matched method (the join point) executes. It's used for things like logging entry or validating arguments. It runs before, then the real method still runs.

embeddedServer starts Ktor from Kotlin code, with the engine, host and port passed as arguments. EngineMain is a prebuilt main function that boots the same server from an application.conf or application.yaml file instead.

Install Authentication and configure a named provider, then wrap the routes in authenticate("name") { }. Inside a handler, call.principal<T>() returns whatever the provider's validate block produced; routes outside the block stay public.

Construct an HttpClient with an engine, then call the suspend function client.get(url). It returns an HttpResponse: read the code from response.status and the payload from response.bodyAsText() or the typed response.body<T>().

Ktor's pipelines natively handle only bytes, text and form data. ContentNegotiation registers converters that map a media type to a class, so without it no converter exists for User and both the receive and the respond transformation fail.

Ktor's install() adds a plugin to a pipeline and runs its configuration block once at startup. Plugins can be installed application-wide inside a module, or — when the plugin is route-scoped — on a single route so only that subtree is affected.

Register a model in the app's admin.py with admin.site.register(Ticket, TicketAdmin) or the @admin.register(Ticket) decorator on a ModelAdmin subclass. The change list shows the columns named in ModelAdmin.list_display, defaulting to the object's str.

is_staff lets an active user into the Django admin; is_superuser makes has_perm() return True for every permission. They are independent: a superuser with is_staff=False cannot log in to the admin, and a staff user with no permissions sees nothing to edit.

QuerySet builders such as filter(), exclude() and order_by() run no SQL, so they stay unchanged. Calls that execute a query use awaited a-prefixed versions: aget(), afirst(), acount(), acreate(). Iterate with async for.

Declare a function-based view with async def. For a class-based view, declare its HTTP handlers such as get() and post() with async def, leaving as_view() alone; the handlers must be all async or all sync.

authenticate() checks credentials against the configured backends and returns a user or None without changing any state. login() takes that user and records it in the session, so later requests arrive with request.user set. A sign-in view needs both steps.

Authentication classes identify the caller; permission classes decide access. DRF tries each class in order, and the first returning (user, auth) sets request.user and request.auth: for TokenAuthentication, the token's user and Token instance; otherwise AnonymousUser and None.

DRF's default permission is AllowAny, so an unconfigured view accepts anonymous requests. Set DEFAULT_PERMISSION_CLASSES to IsAuthenticated in REST_FRAMEWORK; a view's own permission_classes then replaces that list rather than adding to it.

DRF throttles nothing by default: list the classes in DEFAULT_THROTTLE_CLASSES and give 'anon' and 'user' rates like '100/day' in DEFAULT_THROTTLE_RATES. A throttled request gets 429 with a Retry-After header and a 'Request was throttled.' detail.

DRF catches APIException subclasses raised in a view and returns a Response with the class's status_code and a body of {"detail": message}. Django's Http404 and PermissionDenied are mapped to 404 and 403; other exceptions propagate as a 500.

A DRF generic view passes its queryset through each class in filter_backends: DjangoFilterBackend (django-filter) handles field filters like ?remote=true, SearchFilter handles ?search= over search_fields, and OrderingFilter handles ?ordering= limited to ordering_fields.

Subclass ninja.security.APIKeyHeader, set param_name to the header, and implement authenticate(request, key) returning the partner or None; pass an instance as auth=. Ninja stores the truthy return value in request.auth, or answers 401.

NinjaAPI is the API; each app defines a Router whose decorated functions are operations; api.add_router(prefix, router) mounts each router; and urls.py includes everything once with path('api/', api.urls), which also serves /docs and /openapi.json.

Django Ninja validates every declared parameter before calling the view, collects the failures into ninja.errors.ValidationError, and NinjaAPI's default handler for that exception returns 422 with a detail list of type, loc and msg entries.

The most specific auth= replaces the others: operation, then the add_router() mount, then Router(auth=), then a parent router, then NinjaAPI(auth=). Settings are never merged. auth=None on an operation or router makes it public.

Django Ninja applies rules in order: an explicit Query/Path/Body/Form/File/Header/Cookie marker wins; a name in the path is a path parameter; a list, set, tuple or Schema is body; any other scalar is a query parameter.

A gate is a named closure registered with Gate::define for one-off checks not tied to a model. A policy is a class grouping one model's abilities (view, update, delete), found from the model you pass; most model rules belong there.

A guard decides how a request is authenticated and remembered; a user provider decides where user records are loaded from. The Laravel 13 skeleton ships one web guard (session driver) pointing at one users provider (eloquent, App\Models\User).

Auth::attempt($credentials) finds the user by the non-password keys, checks the password hash and, on success, signs them into the session, returning true or false. Regenerating the session ID defeats session fixation; Laravel 13's guard already does it in login().

App\Models\User must implement Illuminate\Contracts\Auth\MustVerifyEmail, users needs an email_verified_at column, sign-up must dispatch Registered, the verification.notice, verification.verify and verification.send routes must exist, and routes use ['auth', 'verified'].

Sanctum offers cookie-based session authentication for a first-party SPA on a stateful domain, and database-backed personal access tokens sent as a Bearer header for mobile apps and scripts. Your own SPA uses the session; the mobile app uses a token.

wire:click="addItem(42)" and wire:submit="checkout" send a request that calls that public method on the Livewire component. Arguments are JavaScript expressions sent as JSON; type-hinted models are resolved from ids and container services are injected. wire:submit prevents the browser submit itself.

Reading $wire.guests and assigning $wire.guests = 3 stay in the browser; the assignment rides along with the next Livewire request. $wire.$set() sends a request by default, and calling $wire.checkAvailability() always does, resolving with the PHP return value.

By default wire:model is deferred: typing updates only client-side state, and the value reaches the server with the next action's request, such as a wire:submit. wire:model.live sends an update as the value changes, debounced 150 ms on text inputs.

Pass props as attributes on <livewire:name /> (a colon prefix evaluates PHP) or in @livewire's array. mount() receives them by parameter name, or matching public properties are filled. mount() runs once, at creation, never on later requests.

Define an updatedQuantity() method on the component: Livewire calls it after it writes a new quantity sent from the browser, so it can recompute the total. updatingQuantity() runs before the write; generic updating() and updated() receive the property name.

Sinatra tries the routes for the request's verb in definition order and runs the first match. Named segments, splats, regexp captures, query and form fields all land in params as strings, readable by string or symbol key.

Define a helper that computes an HMAC of the raw body and calls halt 401 on a mismatch, then call it from before '/webhooks/*'. The halt skips the route, while after filters still run.

erb :receipt renders views/receipt.erb, wrapped in views/layout.erb when that file exists. The template runs with the request's app instance as self, so it sees instance variables and helpers; the locals option adds local variables.

halt stops the request at once and sends the status, headers and body you give it. pass abandons the current route so the next matching route answers, or a 404. redirect sets Location and a 302 or 303, then halts.

require 'sinatra' sends top-level DSL calls to Sinatra::Application and starts a server at exit when the file runs directly. A Sinatra::Base subclass is a plain Rack app with logging, method override and auto-start off, started by run! or a Rack server.

A Rack application is any Ruby object that responds to call(env). It receives the request as an env Hash and returns a non-frozen three-element Array: an Integer status, a Hash of lower-case headers, and a body that responds to each or call.

A Rack middleware is a class whose initialize takes the inner app and whose call(env) reads a monotonic clock, calls @app.call(env), writes the elapsed time into the returned headers under a lower-case name, and returns the triple; config.ru adds it with use.

config.ru is Ruby evaluated inside a Rack::Builder: use adds a middleware, run sets the innermost app, and map mounts a sub-app under a path prefix. The first use line is the outermost layer, so it sees the request first and the response last.

Rack::Request wraps the env Hash with readers such as params, path_info, get?, cookies and ip, caching parsed values in env. Rack::Response collects status, headers and body with helpers such as write, set_cookie and redirect, and finish returns the SPEC triple.

Rack 3 requires an Integer status of at least 100, a mutable Hash of headers with lower-case names and Array values for repeated headers, and a non-frozen response Array; rackup, Rack::Server and Rack::Session also moved into separate gems.

The Content-Type request header names the format, and the framework picks a body parser from it. A JSON body is one nested, typed value; a form-encoded body is a flat, percent-encoded list of string key/value pairs.

A multipart/form-data body is a run of boundary-delimited parts, each with its own headers naming the form field and, for files, a filename. The framework walks them in arrival order as field values or file handles.

Handler parameters bind from captured path segments, the query string, headers, cookies, form fields, or the parsed body. The framework picks the source from an explicit marker on the parameter, or infers it from the parameter's name and type.

The returned value models the body, not the whole response. The framework picks a writer for the negotiated media type, serializes the value, synthesises Content-Type and framing, then applies a default success status, conventionally 200.

A URL carries only text. The binder finds a converter for the parameter's declared type, runs it on the raw string, and passes the result in. A failed conversion ends the request as a client error before the handler runs.