Frontend precheck
Useful for quick feedback when a username, email, or code is already taken.
Check Record Before Insert
Use uniqueness checks to guide users before insert, while still keeping the final guarantee on the server where duplicate data is actually prevented.
Introduction
Checking whether a record already exists before insert is partly a UX pattern and partly a data-integrity pattern. The frontend can warn early, but the real duplicate-prevention rule belongs on the server or in the database constraint. In Wappler, the strongest approach is to combine a helpful precheck with a final server-side guarantee.
Server guarantee
Still required, because two users can race the same value at nearly the same time.
Use early feedback to reduce wasted form effort.
Keep the final uniqueness check on the server.
Explain the conflict clearly so the user can recover.
Treat precheck and insert as related but separate steps.
Use precheck without trusting it too much
The precheck helps the user, but it is not the final gate.
Precheck for guidance
A lightweight lookup can tell the user that a value appears to be taken before they complete the whole form. This improves flow on signup and create-record screens.
Best use
Give early guidance where uniqueness matters to the user experience.
Use the server for certainty
The actual insert step must still reject duplicates. A frontend precheck can become stale immediately, so it should never be the only protection.
Concurrency reality
Two valid-looking submissions can still collide when they hit the server.
Help the user recover clearly
If the final insert is rejected, return a message the form can display cleanly so the user knows what to change instead of seeing a vague failure.
Actionable error
Tell the user which field conflicts and what to do next.
Next steps
Uniqueness checks belong with validation, submit feedback, and the broader server-side workflow that actually saves the record.