Advice on Node.JS vs Xojo for Web functionality

  1. 2 years ago

    scott b

    22 Aug 2017 Pre-Release Testers, Xojo Pro local coffee shop

    This is not to start a FLAME WAR. But I have some serious questions about Node.JS vs Xojo. I am writing an API to front end a database (PostgreSQL right now but that could change in the futures).

    A few notes.

    1. this is part of a startup.
    2. I am designing and writing the API.
    3. needs to be scalable.
    4. I hate javascript as a language.
    5. 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.
    6. my partners 100% agree with #1-5 above. Especially #4.

    now my problem is I am learning Node.JS/Javascript as I write the "API server". This server is designed to be the API between the clients (Web page at first, then iOS/Android client later - not dropping Web page, just adding the mobile clients). I want the API server to be easily updated and have minimal impact when we do (like downtime, etc). I also need the requirements for the API Server to be minimal. Instead of putting a few LARGE servers, we rather scale up/down with SMALL servers. The standard WebScale or *aaS model.

    Currently we are hosting at DigitalOcean. But if this takes off, we will host in multiple vendors.

    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?
    Thanks
    sb

    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.

  2. scott b

    22 Aug 2017 Pre-Release Testers, Xojo Pro local coffee shop

    the API server will return the data as JSON (string).
    need to return HTTP status codes to identify if there is errors or not (like 500, 404, 401, 200, etc)

  3. Phillip Z

    22 Aug 2017 Pre-Release Testers, Xojo Pro Florence, SC
    Edited 2 years ago

    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.

    @scott b
    A few notes.

    1. this is part of a startup.
    2. I am designing and writing the API.
    3. needs to be scalable.
    4. I hate javascript as a language.
    5. 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.
    6. 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.

    Javascript is a fun language but if you are going to pursue this in a professional project you will want to investigate TypeScript to give you some semblance of object oriented programming and variable constraints. Secondly you will want to read up on and use javascript promises from ES6 otherwise you will quite literally be in callback hell. Many of the libraries you will use in Node will be older and not support promises yet so you will still have some callback hell. While Javascript is cross platform for Node not all NPM modules are as many like the most popular PostgreSQL driver actually includes native code. Sometimes this can create difficulties testing cross platform code.

    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.

    If your partners are not writing code then their feedback is purely moral support. They tend to want whatever gets the job done the fastest. However IF said startup expands it will be easier to get Node developers to help you. However much like PHP the quality of said Node developers will vary greatly. A Xojo developer due to the uniformity of the language is likely more equipped to be useful than a generic Javascript developer IMO.

    @scott b
    now my problem is I am learning Node.JS/Javascript as I write the "API server". This server is designed to be the API between the clients (Web page at first, then iOS/Android client later - not dropping Web page, just adding the mobile clients). I want the API server to be easily updated and have minimal impact when we do (like downtime, etc). I also need the requirements for the API Server to be minimal. Instead of putting a few LARGE servers, we rather scale up/down with SMALL servers. The standard WebScale or *aaS model.

    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.

    @scott b
    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?
    Thanks
    sb

    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?

  4. scott b

    22 Aug 2017 Pre-Release Testers, Xojo Pro local coffee shop

    @Phillip Z I've been down this road and have extensive experience in both but more in Xojo.

    that is why I asked the question here as I know people like you have been down this road before.

    @Phillip Z If your partners are not writing code then their feedback is purely moral support.

    They will write code for the WebUI/Website and potentially the iOS/Droid apps. The API is all (or mostly) me. And the reason is my own fault on that one. I have "data" and "data storage" designs in my head. Aka the tables and their scheme. They are willing but they are not professional programmers. So they defer to me. Now that I have said that, they are chomping at the bit to import the data into the database. We are using various definitions of import.

    @Phillip Z 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.

    I understand about the load balancers being a SPoF (Single Point of Failure). But we are looking at ways to mitigate that as much as we can. As for lots of little vs a few large servers, in my past experiences I have had more trouble with a single troublesome server in a (small # but large servers) environment vs the other. We were also able to find where the trouble comes from faster on the smaller servers. (we can can discuss the whys in another thread if you would like).

    As for the server hardware, these servers are all VMs. And for some of the servers in the application (not looking just at the API server layer), I would consider containers (like docker). We have ZERO bare metal/physical servers and do not want any. We are even looking at certain things being an *aaS product. Our most recent discussion around this has been around HaaS (Hadoop as a Service) to do data mining/analysis of our data. Personally I had never thought of or consider it was an option for HaaS until one of the advisors/consultants said "Hey look at...."

    @Phillip Z The API clients don't care how the JSON was created

    very true. hence why I asked for advice here..

    @Phillip Z "speed" or "performance" is moot point when you factor in network speed for most clients.

    networking speed and performance should be good since we are hosting all within one provider (at this point). When we go multi-vendor then this will be a big concern. And we will have to find ways to mitigate it (within reason).

    @Phillip Z 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.

    We are looking at Express and using an ORM (either Sequealize or ORM) to do more OOP type programming. Not true OOP but OOPish.

    As for RoR, PHP, etc. I have had too many bad experiences to consider them. So has the partners.

    Again thanks @Phillip Z for your very insightful response.

  5. Phillip Z

    22 Aug 2017 Pre-Release Testers, Xojo Pro Florence, SC
    Edited 2 years ago

    @scott b As for RoR, PHP, etc. I have had too many bad experiences to consider them. So has the partners.

    It is all about what you are optimizing for. Speed? Developer happiness? Long term maintainability?

    PHP is wicked fast and generally scalable with requests.
    Ruby on Rails is super fast to develop API's with a strong ORM but hard to deploy/scale.

    Another alternative to consider is Google Go which has an awesome HTTP pipeline and very easy to use. Much better programming environment than Node IMO. Go also supports concurrency on multiple cores, statically typed, etc. Great tool for this kind of work.

    As for Hadoop it is good stuff. At ServerWarp everything customers do runs inside a container whether it be a full fledged web server, Xojo standalone, SFTP server, we are 100% all in on Linux containers. So deployability is not as big of a concern as it used to be. However load balancing and doing it well still remains a single point of failure. Many cloud vendors sell load balancer as a service but it generally provides less than you can do yourself at no additional cost.

    Good luck on your project. :)

  6. Greg O

    23 Aug 2017 Xojo Inc scout.galaxy.barn
    Edited 2 years ago

    If it’s just an api framework you are after, you should look at SlimFramework. Yes it’s php, but it’s a very good system, and helps keep your api organized.

    https://www.slimframework.com

  7. 5 months ago
  8. I once created an experimental JSON-RPC server with node js that could load newly implemented services with no downtime.

    The key was:

    1. the server has to know where to look for a service
    2. a service's entry point should always have the same signature
    3. the JSON request should have a "service" member

    It's not hard to avoid "callback hell" either, just don't do that JS developer thing of nesting functions multiple levels deep, instead lay it out like this (this is a snippet out of context from a simple benchmark test but it should give you the idea. sdb and rsp are requires):

    // in each step the last argument is 
    // the callback for the next step
    
    function insertBench(req) {
        var begin_trans = function(r) {
            sdb.begin(r,insert_rows);
        };
        var insert_rows = function(r) {
            var sql = "INSERT INTO T1 VALUES (?,?)";
            sdb.execMany(r,sql,r.request.params,commit_trans);
        };          
        var commit_trans = function(r) {
            sdb.commit(r,confirm_done);
        };
        var confirm_done = function(r) {
            r.data.message = "Success";
            rsp.serviceResponse(r.response,r);
            sdb.close(r);
        };
        sdb.connect(req,begin_trans); 
    }

    If you start using JS regularly I think you'll grow to like it.

  9. Rick A

    Jun 18 Pre-Release Testers (Brazil. GMT-3:00)
    Edited 5 months ago

    Why Node/JS is a great option:

    1. Fast and easy native JSON serialization and deserialization.

    2. Works great for non blocking I/O event driven applications .

    3. Ever-growing 3rd party libraries and packages accessible through NPM for both client and server-side.

    4. Great for applications that require real time communication between client and server. Tools like socket.io make those things really easy. Very used along with IoT devices (Internet of Things), inside and externally.

    5. Natively supported on many new APIs and services like Google Cloud Functions and Google App Engine, or AWS Lambda, that auto scales.

  10. Rick A

    Jun 20 Pre-Release Testers (Brazil. GMT-3:00)
    Edited 5 months ago

    On the other hand, interestingly, soon I'll start to play with something like you, creating a small server and scale with time, and the language of choice was Dart. Powerful and much more elegant than Node. No callback hell included, object orientation is. No user interface, just API. User interface can be done with other tools like Xojo.

or Sign Up to reply!