Every business application has two halves. One is the part that makes it yours: the idea, the workflow, the screens your customers pay for. The other is the part every application needs before the first one can be trusted with real customers. Rhino 4 builds the second half for you.

You describe an app to an AI coding tool on Friday. By Sunday there are screens, a database and a demo that works. The demo is real, and so is the problem: what you can see in a demo is not what makes software safe to give to customers.

When a customer asks "is our data safe with you?", they are really asking three smaller questions. Can other companies see our data? Can the wrong person inside our company see or change it? And if something goes wrong, can you tell us what happened? Rhino 4 answers each one with a built-in feature.

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.