3 posts tagged with "Laravel"

Rhino 4 ships as three server libraries: rhino-laravel, rhino-rails and @rhino-dev/rhino-nestjs. They share no code. What they share is a wire contract: the same URLs, the same query parameters, the same status codes and the same error bodies. This post walks through one model in all three, and then the client that cannot tell them apart.

Two requests push most teams out of a generated API and into hand-written controllers. One is "a list, but with a query too complex for filters". The other is "a number for the dashboard". Rhino 4 has a declarative answer to both, and since 4.8 and 4.9 both answers take arguments.

Until 4.10, a Rhino model validated itself. That worked for static format rules and for little else: the rules could not see who was asking, which organization they were in, which app the request came through, or what the record looked like before the update. Rhino 4.10 moves validation into a request class that can see all of it.