My Feedback 4.5.1 - the new Wappler Local Server for NodeJS

[ben]

My first reaction: GGGRRRRRR!!!

Three months ago I created a video explaining the 2 minute wait while Wappler configures the NodeJS environment. With 4.5.1 this process takes just over 2 seconds!.

In the same video, I explained that the Hosting Type should remain as Custom Hosting.

In 4.5.1 this becomes Deployment: Wappler Local Host

Are these improvements? My word they are!

Does this mean that I should redo the video? Feedback would be greatly appreciated. The video in question is:

3. Dynamic Site

As a last observation, when I go to project settings, I see Hosting Type instead of Deployment while there is no mention of Wappler Local Server and Own Server

Should this be rectified @George?

[NewMedia]

DEPLOYMENT – Meaning of:

By deploying an application, service, or component, you distribute it for installation on other computers, devices, servers, or in the cloud. You choose the appropriate method in Visual Studio for the type of deployment that you need.

From the viewpoint of Wappler Home Office Headquarters distributing Wappler for download or automated installation is certainly “deployment”.

But it sets me up to think when I see DEPLOYMENT used as the Label of the Category of my whole brand new project that the choices offered are for MY OWN Deployment.

I am choosing, in other words, the Remote Server where I will DEPLOY the finished project.

Well, that is obviously not necessarily the case if you are familiar with previous versions of Wappler.

But for the new user having to immediately set up a Deployment target is counter-intuitive.

Custom hosting happening on my localhost or Wappler own server host should be the first choice for a new project.
In other words, I agree with Ben. It’s just Hosting Server. Targets can take care of the Remote or Deployment Settings.

Sometimes it is helpful not to even set up the Deployment/Remote host until later in development.

[George]

Yes sorry Ben - seems we missed one option in the general tab. The Hosting type there should be removed.

We now have renamed it to “Deployment” and it is available per target. It actually means how do you run your web server.

Initially on new projects we are only making a local development target, so it actually means what local server you want - the build in Wappler or your local NodeJS server or third party services.

Maybe we should make that more clear? Do you think the old “Hosting” name is better than the new “Deployment”?

[NewMedia]

Project Build Server?
Master Development Server?
Default Local Server?

Whatever – but “Deployment” whenever I have seen it used typically means the finished, bundled up, remote server files final destination as a running application.

DEPLOYMENT actually makes more sense as an alternative for REMOTE target.

Remote Deployment Server.

[George]

Well it s choice how to run your web site, so the deployment options are:

• Wappler Local Server
• Own server
• Google Firebase Hosting
• Heroku
• Docker

That is why calling it deployment seemed more logical than hosting.

but if everybody thinks “Deployment” is unclear we can rename it back to “Hosting”

Only you are not “hosting” a docker project or a local wappler dev server - you just use it to run your project on.

[cy2]

Is there a way you can add ‘Update/Changes’ documentation (or video) into to beginning of the playlist, Ben? If not, just add a link in the YouTube description where people can see images/descriptions of what’s changed with the timestamp where they appear in the video series.

With Wappler changing all the time, it might be an idea to create new playlists with that in mind. Start off by telling viewers to check the documentation in the description to see what’s been updated. That way you can just add on any changes to the documentation (or video) until it’s worth redoing the entire series?

[NewMedia]

This was already GENIUS!

[George]

As indicated above the “Hosting Type” in the general project options - was a left over and should be removed.

[NewMedia]

Already the TERMINOLOGY is a problem here:

Well it s choice how to run your web site, so the deployment options are:

Most of us SETUP Wappler to Develop in a closed, non-public location all housed in a folder wherever it is ultimately running.

But we are not choosing “how to run your web site”.

2 basic settings – where to put your Wappler files – base folder as Wappler requires.
And then publishing online. With 3rd or 4th etc targets which we distinguish by naming.

Deployment to me has always meant the final destination where it runs as an application for use.
Deployment can also mean a repository on GitHub, of course.

So using Deployment as the name for the very first setup for Wappler seems an unnecessary extension of the meaning for Wappler"s BASE project setting.

[George]

@ben

Does this mean that I should redo the video? Feedback would be greatly appreciated. The video in question is

With the new build-in Wappler Local NodeJS Server - we are actually solving a lot of problems for beginners and let them start right away.

before that a NodeJS installation was required and also all the node modules had to be installed per project. Some native node modules installations gave a lot of starters also compile problems - specially on the new Apple MacOS with the M1 Arm processor.

Now this is all in the past! NodeJS all runs directly from Wappler preinstalled! So for starter projects you can just choose to use the Wappler Local Server.

You can always switch per target to different deployment options - or use the “own server” option as before to run your own NodeJS local server.

Well if we all agree on the terminology, and clean up the UI a bit more in the next update and then you can see what to change in your video.

@mebeingken your feedback is also greatly appreciated.

[JonL]

@George is there a way you can make the external dependencies load into Wappler as the core ones so custom extensions have less friction?

[George]

No, we only added the NodeJS core modules needed by Server Connect in Wappler core. Those need also to be specially compiled for Wappler (Electron) if native.

If you really need special custom NodeJS modules, you will have to switch to use the regular NodeJS own server and install the regular node modules per project as it was before.

[JonL]

Thanks! I wasn’t aware they were being compiled at build time. That would explain the speed

Nice work for the beginners!

Is it impossible for the new Electron server to read and require from disk external dependencies project1/node_modules if needed?

@george what if they are installed globally on disk? Would electron have access to them?

[George]

@JonL

Is it impossible for the new Electron server to read and require from disk external dependencies project1/node_modules if needed?

@george what if they are installed globally on disk? Would electron have access to them?

Will see what is possible. You can also try it out and investigate the possibilities. We want to make it as easy as possible.

[JonL]

Yep. I believe it’s the right move indeed. Including everything in electron is a great and better for adoption.

But the friction of having to change to own server if you want to extend and use external dependencies might be a nuisance. I will check also options and provide feedback.

[George]

Great - and share you opinion about the used terminology as well

[Marc]

My view regarding terminology change from hosting type to deployment makes perfect sense. The focus is on the where the runtime is, not the runtime type. Deployment means copy runtime to somewhere, so it runs the developers creation somewhere, this also applies to local development environment, it is no different.

Every target environment we run in requires a deployment including our original development environment, and for beginners it is perfect as they simply select “Deployment” Wappler Local Server and it runs, even if they don’t understand, it just simply runs, therefore they can create something and see it working straight away in the browser.

If a beginner did not need to select a “Deployment” at project creation time then this would confuse them more because now their creation won’t be in the browser, and raise questions.

Later when they understand more they can create new targets with new different deployments. Just my 2 cents worth.

[George]

That is why we made it default on new projects. Deployment to Wappler Local Server and Server Model to NodeJS.

You just hit OK and your new project runs directly - no additional setup needed.

We might even improve also the project folder selection, so that it is under a default location (like My Documents) and then with appending the project name. The default location changes once you select some other location. This is how VS code does it.

So eventually you just enter project name - hit ok and are good to go!

[Marc]

@George

That is why we made it default on new projects. Deployment to Wappler Local Server and Server Model to NodeJS.

That’s even better, haven’t tried new project so wasn’t aware.