Running alongside separate authed API?
Has anyone ran WASP front end alongside a separate API? My plan is to run WASP as the front end interface to a data visualization app and manage paying users in it. I have a standalone data API server already in place. My thought is that my other data API would need to interface with the WASP user management system to make sure that users requesting data and certain pages are actually at the right user tier to do that. Does anyone know if that's possible? Perhaps I could have my data API reading user rights from the same database or just calling a WASP api of some sort?
6 Replies
oh interesting.
yeah I think setting up a custom Wasp api endpoint for your seperate server to hit, that can query the user info might work. https://wasp-lang.dev/docs/advanced/apis
or you could alternatively program your separate server to accept user data from your wasp app, e.g.
id, email, userRole, hasPaid, etc., and only perform the actiions if the user has the correct privelegesCustom HTTP API Endpoints | Wasp
In Wasp, the default client-server interaction mechanism is through Operations. However, if you need a specific URL method/path, or a specific response, Operations may not be suitable for you. For these cases, you can use an api. Best of all, they should look and feel very familiar.
One option is also to just use your existing "data API server" as a "service" -> meaning that from Wasp's server code, you would call your data API server and interact with it.
So normally, Wasp app works like this:
Wasp client <-> Wasp server
And you would do
Wasp client <-> Wasp server <-> your existing data API server
This way, you can do all the user / auth check in Wasp server logic (actions, queries), and then just from there do HTTP requests toward your existing data API server.
Regarding security, you can make it so that there is a secret key that you have on your existing data API server, and that only it knows, and then you also have that secret key available as an env var to your Wasp server, adn it will be sending it along in each request. So that way your existing data API server allows access only to the Wasp server, and you know Wasp server is handling and distrubiuting that data correctly due to user checks you have there.
This is really a quite typical micro-service concept -> you have one main/proxy server (Wasp server), and then one or multiple servers(services) that are specialized for specific tasks and are not directly exposed to the user's, but are instead communicating with the main/proxy server, and are "hidden" in that way.
This sounds exactly right to me, thank you for spelling it out. Exactly what I want but just couldn't conceptualize it in my head. Very much appreciated! Depending on architecture my existing data API server could remain off the WWW and only available from within my wasp network as well.
so in my case of wanting different tiers accessing different levels of the API the wasp server > my API call could include the user tier level and verify and modify the response based on that as well
Yes, exactly!
When you say "my API call could include the user tier level" -> do you mean your API call from Wasp client (React) to Wasp server (query/action), or Wasp server (query/action) toward your existing data API server?
If you meant the second -> yeah, you could also do that!
Yep the second, I can shove anything from the wasp server to my server that may be relevant!
Wohooo @nickjantz, you just became a Waspeteer level 1!