Back

Frontend or Backend?

  • 0
  • Databases
  • General
  • Web
  • Realtime
kathelia.dokgu
27 Jul, 2023, 18:48

I have a NextJS project I'm working on and I guess I'm not sure what flow is considered best-practice.

For context - most of the tutorials I've watched have used plain ReactJS or ViteJS so it's all frontend (auth, fetching data, sending data, realtime subscriptions, etc).

Since I am using NextJS I have access to a backend API as well, and my plan was to use the backend API to be the middleman between the frontend and appwrite. This makes sense for my auth because I have some additional validation I want to run before attempting to contact appwrite to authenticate the credentials. But for the other stuff like if a user sends a message, I don't really have any additional validation for it so I think it's fine to not bother with a middleman and just have the frontend send the message to appwrite directly. This also makes sense if I wanted to use the real time subscription for that collection. I don't think it's possible for me to have real time capabilities if I send and receive messages via a backend API first.

So is it common to only have a backend API for actions I need to perform additional validations for but for the rest, it will be the frontend and appwrite communicating with each other directly?

TL;DR
It's common to have a backend API as a middleman for actions that require additional validation or processing, such as authentication. For simpler operations like fetching data or sending messages, direct communication between the frontend and Appwrite is acceptable. It can also optimize performance and enable real-time capabilities. In your NextJS project, using the backend API for authentication makes sense, but for other actions, direct communication with Appwrite is sufficient.
joeyouss
27 Jul, 2023, 20:01

Amm yes, you can use backend API as a middleman. However, for actions that don't require such processing and are straightforward, it is perfectly acceptable to have the frontend communicate directly with Appwrite.

Here's an idea:

  1. Backend API for Additional Validation:
    • For actions like authentication or sensitive operations that require additional validation, using a backend API as a middleman is beneficial. The backend can handle user authentication, input validation, and other business logic before communicating with Appwrite.
  2. Frontend Direct Communication with Appwrite:
    • For simpler operations that do not require additional validation or server-side processing, it is entirely acceptable to have the frontend communicate directly with Appwrite. Actions like fetching data, sending messages, or retrieving non-sensitive information can be directly handled by the frontend, interacting with Appwrite's APIs.
  3. Real-Time Capabilities:
    • As you mentioned, if you want to utilize real-time capabilities, direct communication between the frontend and Appwrite becomes necessary. This is because real-time features often require WebSocket connections, and having a backend API as a middleman can introduce additional latency and complexity.
  4. Optimizing Performance:
    • Direct communication between the frontend and Appwrite can also help optimize performance by reducing the number of hops and potential bottlenecks in the communication flow.
joeyouss
27 Jul, 2023, 20:01

An example how to do backend (SSR) auth, and then backend (SSR), or frontend (browser) account.get(): https://next-js.ssr.almostapps.eu/

Source code: https://github.com/Meldiron/appwrite-ssr-next-js

D5
27 Jul, 2023, 20:31

Also SSR is beneficial for SEO

kathelia.dokgu
27 Jul, 2023, 20:39

Thank you so very much for the detailed guide. I guess I'm glad that my plan is on the right path. Thanks to the appwrite team! Amazing product and amazing support too!

Reply

Reply to this thread by joining our Discord

Reply on Discord

Need support?

Join our Discord

Get community support by joining our Discord server.

Join Discord

Get premium support

Join Appwrite Pro and get email support from our team.

Learn more