The app would present two actions: New note and Show notes.
When saving a note, the app would send an HTTP POST to the Firebase Realtime Database REST endpoint (https://<project>.firebaseio.com/notes.json), supplying the note text and the current timestamp as a JSON body. Firebase returns a unique key for the new record.
When showing notes, the app would send a GET to the same endpoint. Firebase returns all stored notes as a JSON object keyed by the IDs it generated. The app would sort the entries by date descending and display each one as YYYY-MM-DD — note text.
The Firebase project URL and database secret would live in a configuration file (e.g. .env.local) and be consumed only by a server-side Next.js API route, never sent to the browser.
Firebase database secrets must be kept server-side. A NEXT_PUBLIC_ env var would bundle the secret into the JavaScript delivered to every visitor. The correct architecture is a Next.js API route that holds the secret and proxies all Firebase requests — which is effectively a backend, not a static page.