My app has two clientele – admins and users. The admins use Supabase social login to connect and purchase. The users use phone SMS msgs & cookies to authenticate and use a limited subset of the app.
These to auth methods are colliding with one another fatally.
Splitting the app would solve all my problems, and create a new one.
How/where would I define my database and how will I share it’s use between the two apps?
Mentally probing the concept of two Prisma installations is spraying red flags across the thought patterns.
This is the first time I’ve ever tried to mix two authentication methods in one app – and it is NOT working well…
Pain! Pain!
- spock, devil in the dark
Also, I’ll have to maintain shared code between the two apps…
Thanks for any thoughts and ideas you can come up with !
Cannot your two front end client “sides” (lets call them web for admins and mobile for users) connect to the same backend api and that connects to one database?
I suggest one uses the standard GraphQL api for the admin and Supabase providers.
The mobile one can connect to the api using serverless functions which can then talk to the same services – but in the serverless function you consume the event (which has headers and cookies) and authenticate your mobile/phone users there … but not using the “auth.js” helpers.
Conceptually, this isn’t much different than a Webhook getting validated based on its headers.
Cannot your two front end client “sides” (lets call them web for admins and mobile for users) connect to the same backend api and that connects to one database?
I suggest one uses the standard GraphQL api for the admin and Supabase providers.
The mobile one can connect to the api using serverless functions which can then talk to the same services – but in the serverless function you consume the event (which has headers and cookies) and authenticate your mobile/phone users there … but not using the “auth.js” helpers.
Conceptually, this isn’t much different than a Webhook getting validated based on its headers.
That is a good way out of this pickle… And it’s a pattern I use already when some of my admin side calls AWS lambdas.
So I would have the [authenticated] /api side of the mobile app forward it’s requests to the /api side of the admin app with a server-to-server token for authentication. I would not have any actual db code in the mobile /api folders
Thanks for pointing out the obvious, I was circling the drain…
So I’m going to be running and developing on two Redwood apps at the same time - how can I change the port on one?
Are there any good ways to share some of the /web code between the apps?
Honestly, without seeing the codebase or some architecture diagrams, I cannot really make a determination – but that does seem rather complicated.
Right now in 1.0, Redwood only supports one web and one api side. In the future we intend to support multiple web sides and also a mobile side.
We haven’t yet begun to think how that might look like.
Is there a chance that your app is web/admin and api; then a separate repo and redwood app for phone/mobile that just has a web side that uses serverlesss functions and no graphql queries. It’s hard to know given what you trying to share … and it just may not be practical at this stage and some code duplication while not optimal, might have to be just given your particular case.
ajoslin$ cat redwood.toml
# This file contains the configuration settings for your Redwood app.
# This file is also what makes your Redwood app a Redwood app.
# If you remove it and try to run `yarn rw dev`, you'll get an error.
#
# For the full list of options, see the "App Configuration: redwood.toml" doc:
# https://redwoodjs.com/docs/app-configuration-redwood-toml
[web]
title = "Redwood App"
port = 9910
apiProxyPath = "/.redwood/functions"
[api]
port = 9911
[browser]
open = true
[experimental]
esbuild = false
useEnvelop = false
ajoslin$
ajoslin$
ajoslin$ yarn rw dev | grep -w api
api | $ /Users/ajoslin/Documents/Als/Development/production-candidates/2product/product/node_modules/.bin/cross-env NODE_ENV=development NODE_OPTIONS=--enable-source-maps yarn nodemon --watch /Users/ajoslin/Documents/Als/Development/production-candidates/2product/product/redwood.toml --exec 'yarn rw-api-server-watch'
api | $ /Users/ajoslin/Documents/Als/Development/production-candidates/2product/product/node_modules/.bin/nodemon --watch /Users/ajoslin/Documents/Als/Development/production-candidates/2product/product/redwood.toml --exec 'yarn rw-api-server-watch'
api | [nodemon] 2.0.12
api | [nodemon] to restart at any time, enter `rs`
api | [nodemon] watching path(s): redwood.toml
api | [nodemon] watching extensions: js,mjs,json
api | [nodemon] starting `yarn rw-api-server-watch`
api | $ /Users/ajoslin/Documents/Als/Development/production-candidates/2product/product/node_modules/.bin/rw-api-server-watch
api | Building... Took 442 ms
api | Starting API Server... Took 6 ms
api | Listening on http://localhost:8911/
api | Importing Server Functions...
api | NOTICE: Redwood v1.0 will make resolvers secure by default.
api | To opt in to this behavior now, add `REDWOOD_SECURE_SERVICES=1` to your `.env.defaults` file. For more information: https://redwoodjs.com/docs/services
api | /graphql 2694 ms
api | /jwtLogin 6 ms
api | /jwtLogout 2 ms
api | /jwtRefresh 1 ms
api | /jwtSignup 1 ms
api | ... Imported in 2706 ms