Scaling
If i wanted to scale the backend server or put it behind a load balancer, how should i go ahead about doing it?
21 Replies
Hi @isidor. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Hmm, I don't know enough to give you a confident answer yet. The provided knowledge sources do not contain specific information about scaling the backend server or putting it behind a load balancer in the context of Wasp. I recommend checking the official Wasp documentation or reaching out to the Wasp community for more detailed guidance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @isidor, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
Hey @isidor, to avoid a potential XY problem, let's try to figure out what the key issue is
Do you need scaling? If so, why? Where's the bottleneck of your app (server connections, database, something else)?
Or do you need a reverse proxy for some other reason (e.g., managing multiple apps on a single domain)?
Or is this just a hypothetical? 😄
Hi @sodic thank you for answering! Hypothetical!
At this point we are just evaluating wasp for our current and future needs
During the last 20 years of building we 've seen all of the above problems haha and surely it is not a xy problem 🙂
The question we are trying to answer is whether it makes sense for us to build new products with wasp
and for that we need to know if we can handle scaling without ejecting the app or trying to "fight" against it.
Right now from what we have seen it makes sense to keep very specific business logic in wasp and use other microservices for things that need to scale but maybe I m wrong
Ok, fair enough!
Pardon my initial deflection - we encounter many new users asking "buzzwordy" questions (scaling, SSR, SEO) based on the latest trends, so I have to eliminate that possibility before investing time into a more detailed analysis 🙂
I'll try to be objective as possible, but remember, I do work for the team that's building Wasp (so a certain amount of bias is unavoidable).
Let's dig in!
Putting Wasp behind a reverse proxy
Assuming we're still dealing with a single server instance, there are no special considerations here.
The client and the server are two separate apps. The server is an express app, and the client is a React app. Wasp allows you to configure how the client talks to the server using environment variables, so deploying your Wasp app comes with the same freedoms as deploying two regular JS apps (the apps don't care how they're deployed, all they care about is the other app's URLs).
This isn't likely to change anytime soon, and even if it did, I'm fairly confident we'd make sure there aren't regressions in ease of deployment.
Scaling the backend servers
We don't yet offer first-class support for any kind of horizontal scaling.
So, if you build a Wasp app and find you need another backend instance, some "fighting" with Wasp will be necessary. Let's see how much.
The good news is that, when built, the server is still a regular JS app. You can build it with Wasp (
wasp build) and deploy as many instances as you want.
Since that's not a pure vanilla setup, it disqualifies you from our one-command-deployment features (like we have for fly.io).
Still, for most experienced developers this isn't an issue - their setups are never pure vanilla and they know how to deploy JS apps without Wasp (and even if they need a refresher, we have docs that guide you through it).
So, deploying multiple instances of a Wasp server shouldn't be a problem. After that, all that's left to do is:
- Place the Wasp server apps behind a well-configured load balancer.
- Configure the Wasp client app to talk to the load balancer (instead of a single Wasp server app). Again, you can do this through an env var.
Usual caveats
Sessions
Wasp uses Lucia, which keeps session data in the database. So, as long as all the servers connect to the same database (configurable through the env), there's no need for sticky sessions or any kind of smart infra.
OAuth
This is the only special case you'll need to handle in a horizontally-scaled setup. One step of the OAuth exchange features the server sending a one-time-tokento the client, and the next step has the server receive it back and verify it. Therefore, if you want your app to use OAuth and do it through Wasp, you'll have to configure your load balancer to ensure that those two steps happen on the same Wasp server instance.
.
Other than the OAuth quirk, I don't see other obstacles to horizontal scaling.
It turns out there isn't that much fighing after all. All you have to do is handle one edge case through the load balancer (and only if you're using OAuth) 🙂
One thing to keep in mind: Wasp servers are still web apps at heart. Despite being easy to scale horizontally, they'd still be a bad fit for small microservice and non-web-app tasks.
And, finally, we are planning to add native support for horizontal server scaling to Wasp, but I can't make any guarantees on the timelineawesome, thank you very much for taking the time to write this detailed answer!
That makes sense, that's what we expected and it explains my previous question about ejecting /using the build version as we see fit - I hope that this will not change in the future! 🙂 On the other hand I would greatly appreciate blog posts/information on the architecture of the generated code.
In any case my main concern is covered, we wanted to make sure that wasp was not just a beginner friendly "vendor" lockin which seems to NOT be the case. Building on this it would be beneficial for this information to be transparent to help developers who DO want to fast track their development but also do have scaling concerns. This is to make sure that wasp does not appear just as a quick way to MVP but as a quick way to bootstrap enterprise quality webapps
again, thank you for your time!
@isidor You're welcome!
Just to be clear, what you need (horizontal scaling) won't require you to eject. You'll still be 100% using Wasp and won't have to change anything about how Wasp works. Using the built code is a completely normal (and default) part of Wasp's workflow and not at all exotic.
As mentioned, we do offer a deployment command that does some of this work for you, but it currently only supports fly.io and basic setups. The default way for deploying anywhere else is exactly what I described above: build and do what you want (and the steps are well-documented).
Btw, it's also possible to fully eject the code, which means "I want to stop using Wasp altogether, just give me the code you'd generate for the current project and I'll take it from there."
This is a radical option because there's no going back once you eject. Your app ceases to be a Wasp project. I've already mentioned this to someone today (I now see that was also you 😄: https://discord.com/channels/686873244791210014/1277314571903701086/1277609739240341537).
So, yes, you can even eject the code too and continue working on it and entirely leave Wasp. It won't be the best possible code for your particular app, but it won't be machine code either.
Still, from what I got, that's not something you'll need for scaling, but it is available as a last resort.
As for the architecture docs... Yeah, we're a little short on that front, but I can offer this (in order of usefulness):
- The introdution docs that explain how Wasp works on a high level
- This PR's description explores the generated code's architecture (read until "Running the prototype"): https://github.com/wasp-lang/wasp/pull/1584
- The attached graph that explains what each module imports and uses.
-
waspc/README.md that explores how some parts of the compiler work.
This is to make sure that wasp does not appear just as a quick way to MVP but as a quick way to bootstrap enterprise quality webappsAnd finally, thanks for the tip! That's a problem we've been thinking about for a while now and a prominent blog post that explicitly addresses the issue is a fantastic idea.
Yeah ejection was sometihng we mentioned before more, as we wanted people to know they have that option, but I don't think it matters that much anymore because at this point there is very little reason to eject from Wasp, similar like you would not expect to eject from any other framework.
@sodic awesome explanations, do yhou think any of this should go into the docs? If so, quick way is to first capture it in a GH issue and we can then later move it to the docs. If it makes sense.
@isidor we certainly want people to know Wasp is not just a starter kit but a web framework built in mind with enterprise apps! Do you have a more concrete advice how you would make that clear? Landing page, page in docs? Maybe wording that you tihnk would make it clear?
Btw blog post is maybe not the best fit for this as it is more on the side and not updated the same way landing page / docs are, so to me it sounds like docs / landing page are the right place for this.
Hm yeah we could have "Production and Scaling" page in the Docs!
I added a bit of info about this in GH issue here https://github.com/wasp-lang/wasp/issues/2201
Btw I am just looking at our landing page and I wonder how clear is it at all that Wasp is not a one-shot code generator but a proper framework.
For example that diagram we have, if you look at it quickly, looks like it is code generator, not a framework.
Seems to me like one would have to read the landing page quite carefully to get the right notion!
All right I made another issue here for improving the landing page in this respect: https://github.com/wasp-lang/wasp/issues/2255
GitHub
Make it clearer on our landing page that Wasp is proper framework a...
Motivated by this convo on Discord: https://discord.com/channels/686873244791210014/1277607531363172496/1277645496743231550 . we wanted to make sure that wasp was not just a beginner friendly "...
Thank you again @sodic @martinsos for giving your time to discuss our concerns!
IMHO you have managed to perfectly market wasp to MVP builders, so it makes perfect sense to try doing the same for other types of products/devs (e.g. enterprise).
I think adding additional details for the “Production / Scaling” part of the docs would indeed be the best choice since you can pretty much explain what I was told here, that basically people have nothing to fear because at the end of the day they can use the same tools they could use directly from the JS ecosystem for scaling or tackling similar concerns (even if you don’t have internal solutions for that at this point).
In general, in these docs I would want to be reassured through that production section that Im “buying” into a framework(lang?) that takes care (or at least does not stop me from doing it) of security, scalability, maintainability since Im already sold on ease of use, speed and efficiency.
Actually that would solve a major issue of choosing to develop (backend) in the JS ecosystem in general not just wasp hehe 😄
Awesome, thank @isidor that helps a lot! I will add this to the Github issue for creating such page in docs and it will help us do a good job with it.
Indeed, that is a part of what we are hoping to do with Wasp: offer a full stack solution that has security, scalability and maintainbility in mind and backed by the company that is there for support.
Just curious, what is your ecosystem so far?
spring boot (java) with heavy vavr usage (might recognise the library being a FP gang) 😄
Oh nice, I like how vavr is Java turned upside down :D. Hah yes I am Haskell enthusiast: before Haskell, Java and OOP were my main weapons, but now my brain defaults to FP instead of OOP and JS/TS also lends itself to it quite well, so sometimes I have hard time rememgering the times I used Visitor or similar pattern :D.
Spring Boot is a quality, battle tested framework -> what is motivating you to go for Javascript/Typescript ecosystem?
it is, it is also kinda boring 😄
Kidding aside, we will not switch to TS for our main projects:
we just wanted to find a fun alternative for smaller scale projects that also ticks the boxes of enterprise requirements
TBH the closest equivalent to our current ecosystem is nestjs but it looks like java with extra steps 😄
so yeah, long answer short, we wanted a fun, faster but also professional alternative for smaller scale projects (that should have the ability to grow though).
also we are FP enthusiasts so your Haskell backend caught our attention 😄
Thanks, that makes sense, and I think Wasp should fit the bill nicely! Thanks for sharing the view, it is quite valuable learning for us :).
@isidor btw one extra question: how did you find out about Wasp, do you remember?
through opensaas
And how did you learn about opensaas :D? Reddit, or searching for saas starter, word of mouth?
i believe it was from searching for saas starters yes
Awesome, thanks :)! OpenSaas is really doing a good job on search it seems!