Should my backend be logging the user in by receiving the email and password from the client and then forwarding that information to Appwrite OR should the client be logging in directly and skipping my backend so it can obtain a Session object?
Background context: Backend is written is Swift using Vapor framework. Client is macOS and iOS also written in Swift. createEmailSession is not showing up in the SDK when using it on the backend, haven’t checked macOS/iOS yet. I’m relatively new to backend development so I may be missing some foundational knowledge.
Usually people have their front end talk directly to Appwrite. If you have that swift server in the middle, you can use Appwrite like you would any other database and connect to it with an API key.
You can have the client create the session and then generate a JWT token to pass to your swift server to make API calls on behalf of the user.
Understood. Thanks for the reply 🙏🏽 I just wanted to clarify, is it bad practice to have my server be the middleman between the client and Appwrite? My thinking was that if I port my app to Android, I wouldn’t have to worry about rewriting the logic.
it's a tradeoff. i think it complicates things a lot putting that layer in the middle. Maybe you can use Functions for any complex logic (i'm not sure what kind of logic you need).
All the Appwrite SDKs work mostly the same so if you're porting, you'd call the same method.
Got it. Thanks!!
[SOLVED] Email login: From backend vs from client
Recommended threads
- Rec'd a "phishing" email that apparently...
I received an email attempting to convince me that my password expired - and the link wanted to send me to an appwrite instance: (https://updating-projects-ads....
- function subdomain ssl certs
The generated subdomain isn't getting a valid ssl cert, I was wondering if appwrite automatically generates one or uses a wildcard for *.functions.domain.com? ...
- HackByte X AppWrite
I am Om an Organiser at Hackbyte, Central India's largest hackathon. We are an MLH acreddited hackathon and this is our 4th iteration. Last year we had around ...