ETA for Node.js support

Nothing related to Node.js integration has really changed for 2 weeks, Serhat.

Hello.

I’m new here. I’m interested in knowing what node.js support is being requested that what’s being discussed in this link doesn’t provide.

Thanks,
George

Ding

Our server side framework called Server Connect support various server side languages like PHP, ASP.NET and Classic ASP.

In this topic people also request support for NodeJS as server side language.

So we will be adding that soon as well.

1 Like

Still no improvement for node.js? @George

We are currently reevaluating the support NodeJS.

Can you explain why you need NodeJS for that you can’t do with the current Server Models?

Also note that NodeJS have a completely different workflow.

  • You have to deploy with server side install of node modules
  • You have to restart your node server on each change
  • Node Server have to run behind a web proxy server or existing web server, that servers the static content
1 Like

In voip projects, api was very important to us and now we do everything about api very quickly and perfectly with wappler. Likewise, I have to use web socket and node js modules in billing, chat and IoT applications. yes, we can do many projects with php and asp.net. but unfortunately I have to for web socket and nodejs. Now I have to do IoT and chat application but I want to use node js with wappler. I no longer want another framework.:slight_smile:

I hope the re-evaluation result will not be negative.

@George,

Below are highlights from this article explaining why someone would want to use Node over other languages/engines.

Ryan Dahl, the creator of Node.js, was aiming to create real-time websites with push capability , “inspired by applications like Gmail”. In Node.js, he gave developers a tool for working in the non-blocking, event-driven I/O paradigm.

Node.js is not a silver-bullet new platform that will dominate the web development world. Instead, it’s a platform that fills a particular need . And understanding this is absolutely essential. You definitely don’t want to use Node.js for CPU-intensive operations; in fact, using it for heavy computation will annul nearly all of its advantages. Where Node really shines is in building fast, scalable network applications, as it’s capable of handling a huge number of simultaneous connections with high throughput, which equates to high scalability.

When discussing Node.js, one thing that definitely should not be omitted is built-in support for package management using NPM, a tool that comes by default with every Node.js installation. The idea of NPM modules is quite similar to that of Ruby Gems : a set of publicly available, reusable components, available through easy installation via an online repository, with version and dependency management.

Additional reasons for Node.

The main and most often voiced advantage of NodeJS is the npmjs package manager, based on npm, and the common module repository. The number of NodeJS modules (and other JavaScript libraries) added by users since 2010 is over 190,000, which exceeds the entire Perl CPAN repository that was collected for more than 20 years. Thus, usage of npmjs significantly reduces the time needed to create software and instead focuses the activities of backend programmers exclusively on the development of the specific functionality. This is a key part of the NodeJS operation. It allows each application to have the necessary modules in its own dependency tree. Each application can have its own set of modules, which resolves the dependency conflicts.

2 Likes

There is no doubt NodeJS is amazing technology. We use it our selves a lot!

I’m just looking for the best way to integrate it in Wappler.

Currently we plan to make the exact same functionalities and actions in NodeJS that are available in other Server Connect languages like PHP and ASP.NET

This will include the regular database connectivity and routing.

But as it will be exactly the same as the Server Connect other languages, a doubt arises of its usefulness and additional value.

Reactive/Realtime Databases is a different topic and we will be addressing those with integration of PouchDB and the Client Side Flows. So there won’t be any need for NodeJS on that.

Also with the availability of App Connect Flow - you are actually having full client side availability of whatever you will ever need in NodeJS/Server Connect. So Flow is ideal for Mobile and Desktop Apps.
We will be adding more and more components to Flow to make everything possible (like more Cordoba Plugins or native integrations)

Also for PWA’s will Flow be great options to glue everything together.

So what is left for nodeJS will be to just make your own REST API.

Furthermore each hosting provider / hosting panel has its own ways of integrating NodeJS. So it is very difficult to build a universal way of publishing and restarting the NodeJS server.

Using more standard based services like Google Firebase Functions and AWS - makes this more easy.

1 Like

I remember asking this same thing here.

I didn’t see so much added value in dedicating so many resources adding another server model to have everything abstracted behind Wappler’s framework.

It’s true it has neat features but that those neat features are not exclusive to nodejs.

Websockets is something that Wappler is missing at the moment that is true, but there are good php libraries that could be integrated by the team.

As I said php is not going anywhere anytime soon and I am sure it will adopt some of nodejs features through core or libraries.
Ok. Maybe not as natively and optimized. But for 99.99% of our use cases it will serve.

If we ever become the next world leading real time app I am pretty sure the team understands that we will have to graduate from Wappler and build something specific for our needs with our own team of 10000 engineers :slight_smile:

But until that time arrives maybe we shouldn’t use bazookas to kill mosquitoes and be wise about what we ask the team to build. It will probably take a huge amount of resources to build and maintain.

Instead of asking for nodejs why don’t we tell them what our specific use cases are? Then they can identify the actual needs and look for the proper tools to integrate with the current server models?

7 Likes

@George and @JonL,

TLDR; I’m open to suggestions on alternative ways to build my app, but I believe node.js is the most appropriate to consolidate on one language/platform for both server part of app and desktop part of app – and allow for all email processing to happen within the desktop (i.e. Electron) app without any interaction/processing happening on the server.


Here’s what I am wanting to build and why I think I need node.js, and why php will not work. I’m open to suggestions on alternative ways to build it.

A major part of my app will be an email client. It will allow users of Gmail, Microsoft, and others to connect their work email account and use it as their main email client. I plan to build additional features (chat, task management, and more) that will reside on a server, but email is a major part of the app and this data needs to stay of the user’s device while also interacting with data stored (tasks, chats, contacts, clients, etc.) on the server so all users of an account will interact with the same data.

I already built this app on Bubble, but last year I ran into a major roadblock with gmail. Google enacted new security rules that made a web-based app that stores gmail data impossible. In order to bypass an extremely expensive, annual, third-party security review, any developer who wants to interact with a user’s gmail data must store the data on the user’s local machine. This meant that I could no longer use Bubble for a big part of my app and the main reason I moved to Wappler – using it to build a desktop Electron app, in addition to the SaaS part of the app.

Since Bubble uses node.js and allows you to build plugins using anything in npm, one of the plugins I built was for email parsing using https://nodemailer.com/extras/mailparser/.

So, now that I must build an Electron app for part of my app, and since Electron also uses node.js, it seems most logical to me for Wappler to allow building the app using javascript and node.js for everything, as php is not possible in Electron – please let me know if my understanding is not correct or if this wouldn’t even be possible with node.js.

Additionaly, npm has many packages that could be used to help all Wappler users build apps faster, whether their app was server-based or client-based, so it seems like a worthwhile effort to develop the functionality in Wappler and possibly help others transition from Bubble to Wappler in the future.

To summarize, I think javascript/node.js is most appropriate, but I’m open to suggestions to build the following:

  1. Build a desktop/mobile app as the client part of my app, which will retrieve/process/store email data locally – without any involvement from a server – and interact with other data (chats, tasks, contacts) on a server.
  2. Build a server that stores various data (chats, tasks, contacts) and has APIs for the desktop/mobile app to interact with the server-based data.
2 Likes

Don’t get me wrong. I see the value in nodejs.

I just see that a lot of things on the roadmap would be sacrificed in order to add a new server model that is just sitting there behind Wappler.

But apart from some libraries(npm) and that you want to maintain your code base simple(only js).

Is there anything specific available only for nodejs that you need? Remember npm is just a package manager like composer for php.

I have seen several php email parsers over the years so I am guessing there is something out there that will fit your needs.

I remember a post from a Slack(the app) engineer explaining why they used php for nearly all the server side. Realtime apps are a thing on PHP too. I don’t know if they still do but they made it work in the past for sure. Their desktop app was also built with Electronjs.

Php cannot be used in Electron. I need to be able to process email data directly in the Electron app. Since Electron uses node.js and since node.js already has a robust email parsing package, it seems like the only choice.

Slack’s Electron app is basically, for a lack of a better term, a “dumb” app. All processing happens on the server with pushes/pulls between the app and server.

It can if it is being run server side otherwise Server Connect would not work… And believe me it all works just fine, we have many very happy clients. Unfortunately sharing these apps here is prohibited by a bunch of non disclosures which we have to abide by otherwise we wouldn’t have many clients… I’d love to showcase them personally but the consequence of this is not worth considering. I shall build a showcase outside of clients projects and share that here instead, just as soon as I have the time to do it. We run dozens of Node packages without any issues. We check for online status when the app is started and have an option to run in offline mode with limited functionality, and using local storage once online other features are enabled and the local storage is transferred to the back-end, no problems reported and all working absolutely fine.

1 Like

@Dave, you may have missed it, but this is the most important part and why php will not work. I cannot send it through, or store it on, the server.

Yeah. I got it now too. No server side email processing :slight_smile:

1 Like

We haven’t tried with Gmail but then it wouldn’t be possible anyway if the app was offline regardless? A quick search reveals a few options, maybe something like:

https://developers.google.com/gmail/api/quickstart/nodejs

and StackOverflow of course (obligatory ReCAPTCHA to see answers):

Have you checked php-desktop ?

1 Like

Keith,

NodeJS Server Model won’t help you an Electron desktop app. As it is for running web servers only.

The new App Connect Flow is however exactly what you need! There you can create your client side workflows for all the actions you need. We will be adding more and more components to Flow so you will be able to do much more with cordova plugins and other native components.

2 Likes