I know that the documents say that UD is good for medium to low traffic projects but what does that really mean? If I write an API in UD and expose it to my org how many concurrent requests will it be able to handle? Obviously it will be slower than a fully compiled application but what if I want to give 10,000 users the ability to pull data via the UD API?
@Mr_New_Vegas Welcome! I think this might be tuff for anyone to answer because there are just too many variables to consider. I would suggest developing your prototype API and then build a test client to call the API and measure the performance.
Hi,
There is a discussion around Load Testing here: UD Load Testing
While this is not relevant to API use, it’s around testing the capacity of UD UI use, with relatively simple dashboards that make calls to sql.
UD can always be scaled (whether you throw more resources at your server, or you scale out horizontally behind a load balancer with sticky sessions - or both), but I think that the suggestion around ‘medium to low traffic projects’ in the documentation may refer the the feasibility of that scaling - I suppose everyone’s requirements and resources are different, but for me there’s a limit where it is no longer cost effective (although UD more than meets my requirements currently).
If you are doing something on this scale, particularly for 10,000 users, you should always consider testing to make sure it is feasible before hand, the last thing you want is to spend time developing and then realize you hit problems when you get to the 500 user mark after everything is place. So in that I’d mirror cadayton’s comments. If this is 10,000 concurrent connections i would say you would very much struggle without some sort of considerable load balancing.
I would ask what your end goal is, why you want to achieve this, what are the alternative options?
If it’s just data you want to expose and UD was your choice due to its ease of use to expose that data, i would consider alternatives. You can still use UD for api’s and web ui’s but maybe consider exposing your data via sql or ssrs or some other method that may be more tailored to your needs at the same time - with both methods interacting together.
Might add if my goal was just to have a pure REST API without any traditional web pages being served, I would implement this with what ever programing language you desire. For higher end performance requirements, I would consider a compiled language. If I was to embark on this task today, I would consider either Go or RUST. I think JS would work too, but I’m not that experienced with it. Maybe others can chime in about JS being a candidate to handle high traffic volume.