Feedback Fort shows how to build a feedback collection applications that use Outseta for user management while storing application data in a separate database system.

The Feedback Fort application provides these core capabilities:

  1. User Authentication: Secure login/signup via Outseta
  2. Feedback Submission: Authenticated users can submit feedback
  3. Voting System: Users can upvote feedback items
  4. Status Tracking: Feedback items have statuses (new, in-progress, completed, etc.)
  5. Responsive UI: Works on mobile and desktop devices

This article explains the core architecture and design decisions behind Feedback Fort and acts as a basis for the different implementations.

  • Outseta + React + Supabase: Code | Live Demo | Article
  • Outseta + Astro + Airtable: In progress
  • Outseta + Wized/Webflow + Supabase: To do
  • Outseta + React + Xano: To do
  • Outseta + NextJS + Airtable: To do
Screenshot of the Outseta + React + Supabase demo

The Big Picture

Feedback Fort uses a split architecture:

  • Outseta: Manages accounts and people (your users)
  • Your Database: Stores feedback items and votes

This architectural separation maintains clear boundaries of responsibility. Outseta handles user management functionality while your database focuses solely on application-specific data. Feedback Fort connects entities through UID references rather than duplicating user information across systems, which often leads to synchronization challenges.

Of course, there are legitimate use cases where duplicating user data becomes necessary; however, ensure it's truly needed, as it significantly increases system complexity and creates potential for data inconsistencies.

What Outseta Brings to the Table

Outseta provides authentication, user profiles, billing, and so much more out of the box. There is no need to reinvent the wheel!

The demos showcase:

  • User registration and login
  • User profiles

Outseta has the concept of both "people" and "accounts". Think of an account as an organization or team, while a person is an individual with a unique email address. A person can be connected to multiple accounts, and an account can have multiple people. When logging in, a person will select which account to represent (if more than one possible account).

We've decided to link the votes and feedback to the person, meaning an account with multiple people gets more than one vote. Depending on your needs, you might want to connect the votes and feedback to the account instead, giving each account only one vote!

What Your Database Needs to Handle

Your database needs to store:

  • Feedback items: Title, description, status, etc.
  • Votes: Who voted for what

Both need to reference the Outseta Person UID. This creates the bridge between your database and Outseta as discussed above under The Big Picture.

Basic schema requirements:

  • Feedback table with a reference to the Outseta Person UID
  • Vote table with a reference to both the feedback and the Outseta Person UID

Connecting the Two Systems

A crucial component of this architecture is having server-side code that verifies authentication before allowing access to your database.

Your backend needs to:

  1. Validate the Outseta JWT (JSON Web Token) to ensure it's legitimate and not expired
  2. Extract the user information from the validated token
  3. Use this information to authorize data operations (create, read, update, delete)
  4. Prevent unauthorized access to feedback data

For Feedback Fort, we:

  • Allow anyone to view (read) all feedback and votes
  • Only allow logged-in (authenticated) users to submit (create) feedback
  • Only allow logged-in (authenticated) users to place (create) votes
  • Only allow the user who submitted the feedback or placed the vote to change (update) it
  • Do not allow deletion, but use a soft delete approach instead by adding delete metadata to the item

Without this validation layer, anyone could access or modify your data. Each demo either includes the needed backend functionality or utilizes the service surrounding the database.

A typical flow looks like:

  1. User authenticates through Outseta in the browser
  2. The Outseta Access Token is included in the request for data
    • Or an exchange for a service provider-specific token is executed, and that token is included in the request for data
  3. Your server validates the token before processing any data request
  4. When a user submits feedback, your server verifies their identity and stores the Outseta Person UID with the feedback

Foundation for Multiple Implementations

This article establishes the architectural foundation for all Feedback Fort implementations. Each demo app follows these same principles while showcasing different technology choices. Whether using React, Astro, or Webflow on the frontend or Supabase, Airtable, or Xano for data storage, the fundamental approach remains the same.

Ready to see these concepts in action?
Check out our first demo using React and Supabase (Code | Live Demo)!