[Github PR in motion] Help, I need two apps with one database!

I’ve coded myself into a corner here

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 !

Al;

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.

1 Like

That is exactly it – I’ve created two separate repos and am proceeding along these lines - feels like a clear path

How can I change the ports that a redwood app uses in dev ? I need one of these two apps to use something other than 8910

There’s a config for that!

1 Like

I run my app on two different ports, for admin and customer portal.

Use the following to run your app on another port. I run one API, and two web apps. I use a context variable to distinguish which app you are on.

CONTEXT=PORTAL_APP yarn rw dev web --fwd=\"--port=7910\"

1 Like

That’s cool !!

@thedavid

?? this only works for the /web side

filed as an issue: Redwood.toml doesn't control the /api port · Issue #3302 · redwoodjs/redwood · GitHub

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

which is confirmed by checking the open ports

ajoslin$ ~/open_ports.sh
rapportd    528 ajoslin    4u  IPv4 0x95ca426ac00c9f43      0t0  TCP *:51005 (LISTEN)
rapportd    528 ajoslin    5u  IPv6 0x95ca426abf016133      0t0  TCP *:51005 (LISTEN)
Dropbox     601 ajoslin   81u  IPv6 0x95ca426aa2a494f3      0t0  TCP *:17500 (LISTEN)
Dropbox     601 ajoslin   82u  IPv4 0x95ca426aa6715ce3      0t0  TCP *:17500 (LISTEN)
Dropbox     601 ajoslin   94u  IPv4 0x95ca426aa8d851a3      0t0  TCP localhost:17600 (LISTEN)
Dropbox     601 ajoslin  136u  IPv4 0x95ca426aa8d87923      0t0  TCP localhost:17603 (LISTEN)
Sonos      6369 ajoslin   25u  IPv4 0x95ca426a9f523303      0t0  TCP *:3400 (LISTEN)
postgres   6741 ajoslin    5u  IPv6 0x95ca426aba5ac653      0t0  TCP localhost:5432 (LISTEN)
postgres   6741 ajoslin    6u  IPv4 0x95ca426aa6713f43      0t0  TCP localhost:5432 (LISTEN)
postgres   6741 ajoslin    7u  IPv6 0x95ca426aba5aeb13      0t0  TCP anon23.local:5432 (LISTEN)
AMPDevice 38043 ajoslin   10u  IPv4 0x95ca426ac00587c3      0t0  TCP *:60704 (LISTEN)
node      73695 ajoslin   23u  IPv4 0x95ca426ac0e94303      0t0  TCP localhost:9910 (LISTEN)
node      73706 ajoslin   22u  IPv6 0x95ca426a96412653      0t0  TCP *:8911 (LISTEN)

ajoslin$ cat open_ports.sh

#!/bin/bash
lsof -i -P | grep -i "listen"

A PR is in motion to fix this problbem