I've been down this road and have extensive experience in both but more in Xojo.
First I would recommend our (1701 Software) Rapid Services product. It makes API building a breeze in a visual manner.
I will go through your list here and try to provide meaningful feedback.
A few notes.
- this is part of a startup.
- I am designing and writing the API.
- needs to be scalable.
- love how node is completely self contained and I dont need a webserver, or anything else installed on the server to serve up the API.
- my partners 100% agree with #1-5 above. Especially #4.
NodeJS and Xojo scale in essentially the exact same way. Neither can use multiple cores concurrently. Node does abstract this a bit with the ability for a master process to spin up slave processes. So in theory it is a bit easier to handle without a load balancer.
With a load balancer which I recommend for several reasons the differences are less interesting. The only real distinction is in Xojo you would have to spin up say 10 background processes where Node could do it for you.
Node is no more self contained than a Xojo Web binary which bundles in a web server. If you use Xojo Web say with Rapid Services then you are using Xojo's home baked HTTP server along with my quick and fun REST API builder. However if you go Xojo console and use one of the open source HTTP libraries it would be akin to NodeJS' Express framework or otherwise. What I mean to say is NodeJS HTTP server is VERY low level and almost everyone uses Express or similar to get access to simplified routing, content types, API handling, etc. Express is a bit easier than using HandleURL in Xojo but NOT easier than Rapid Services.
Currently we are hosting at DigitalOcean. But if this takes off, we will host in multiple vendors.
In my experience scaling up on big machines and then multiple big machines is easier. At the end of the day unless you use distributed DNS and even then you have to have a couple focal points which are your load balancers. So sure you might have 100 little machines but if 1 of your 2 load balancers go down the site is effectively down.
Bigger hardware means redundant drives, redundant power, redundant network, etc. Just easier to scale up and also throughput is faster when load balancing on a virtual network as opposed to who knows how many vendors and networks. Technically though the way you do this is essentially the same.
Now I want to note that my partners on this are not developers. They all have coded in the past (either in school or as a hobby to do something). So they are "programming friendly". But wont be doing lots of the coding. That will be me. Now they are going to try to help me as much as they can. None of they know Xojo. Only heard of it because they talk to me and I tend to talk about Xojo.
I need to write the API server so I can then write the Website/WebUI server.
Starting off with the API Server, why would I stick with Node.JS (over Xojo)? or Why should I switch to Xojo?
PS> I know you all will ask how much code do I have in Node.JS. I have "minimal" code in Node.JS. I have been writing and re-writing the code to find the write framework to use to do what I need to do. There is only 10,000 frameworks and a dozen new a day. And most of them are a flash in the pan. So switching or staying due to code written is not a factor.
If I was starting green field API server and did not have a preference I might consider Elixir/Phoenix framework if you like functional programming. The fact that you consider NodeJS says you are not too invested in object oriented which may come back to haunt you later when you arrive in callback hell. Java and JVM languages are eh. PHP 7 is nice. Ruby on Rails has some great conventions and API capabilities.
At the end of the day though you can build a great API server in any language if you understand the HTTP stack. I would recommend whatever YOU are most comfortable with to be most effective in. The API clients don't care how the JSON was created and "speed" or "performance" is moot point when you factor in network speed for most clients.
90% of the challenges will be in how you upgrade, maintain, and scale it and not at all the code layer. Why add code complexity to the list?