So for projects using Custom Modules, the new Wappler deployment cannot be used. Is that understanding correct?
Custom modules yes. External dependencies no.
Currently yes - but you can easy switch in the project development target options at any time.
Note this is only for your local development - in live environments the live node and node modules are used (and they are installed there)
We are investigating also maybe an easy automatic switch of the local node server, like as long as you don't use custom modules it uses the wappler built-in nodejs server and otherwise just switch to the regular nodejs server.
I see this new server option causing more issues than resolving.
I donât know how difficult is it to work with the previous options in Mac, but I had 0 difficulty in Windows.
There was already confusion around Docker & NodeJS, and this change will only amplify it.
It is actually solving many issues especially for new / inexperienced users.
Example:
Another example - no need to install node and homebrew, no need to know how to install them and no need to install anything additionally. No system checks. No errors about missing components.
Just select Wappler Local Server, click OK and your node server is up and running with all the modules compiled and notarized by Apple.
1 Like
I think the right name for target is environment and the action of copying data, services and code should be called deployment. You could have an undefined number of environments and they can exist in any machine(local or remote).
But what you did with the new version is not an environment as itâs self contained in the Electron app. A new name/concept should be defined for this. Letâs call it WSDE (Wappler self-contained development engine) for now.
So one could start developing in WSDE right off the bat. Then he can create different environments and deploy to them i.e. local, staging, integration, pre-production, production, etc Whatever suits his needs.
Or he can skip the WSDE and work on the local environment as it was before the introduction of it.
Also, how about calling a wizard form when you create a new project and a new target instead of presenting all the options in a tabbed form? It would help new people get on-board as you guys would control the flow.
2 Likes
You guys definitely have better insight on that. Looks like Mac-world issue though.
1 Like
The new Wappler node server seems an obvious great improvement -- get new users engaged and displaying a hello world page with as little friction as possible. So defaulting to the Wappler Local Server on new projects makes sense. It's also okay that custom modules with external requirements won't work as a new user won't hit that for a while (although documenting this difference is important, perhaps along with differences between php/asp/node).
As for terminology...
I like the idea that "Target" becomes "Environment", and I would leave Deployment as-is. Environment matches with environment variables and seems to describe well the entirety of all choices. Target seems to introduce a new entity in the development world, when we already have environments.
But when creating a project (not editing an existing one) you might consider wrapping Deployment and Server Model into a section labeled something like "Development environment" as it represents the first development environment created ( and is not a choice for the entire project.) This to avoid mistakenly choosing what the production environment will be.
I
Alternatively I could even argue the case that Deployment should not even be an option when creating the project, just default to wappler local server so it works. Additional targets(environments) can be added, and deleted, but the user will be reluctant to do that until they understand what they are doing. If it is an option on creation, then new users will be comfortable to make a choice which might not suit them well....but again, labeling Development environment might already fix that.
1 Like
Yes. I think more or less we have the same idea/concept.
I see the new concept as an improvement to builder and I think itâs better if itâs not even considered an environment as such because itâs self contained and it will only work while wappler is running meaning you canât serve a site if wappler is not open. Same happens with the internal node server.
While an environment I see it as a full stack thingy that can serve any of your projects even if wappler is not running. Environments can be local or remote as the needs of each person can be different.
To summarise:
- Anything that requires Wappler to be running to serve content -> Not Environment, itâs part of the builder stack.
- Any machine(local or remote) where I can deploy my app and doesnât require wappler to run -> Environment
For 1) wappler could even change the host file so you can reach your project from the browser in http://mycoolproject.wappler instead of http://localhost:3000
3 Likes
Post a short addendum document/comment in the remarks and keep bringing us new videos!
Weâve changed this option to Development Environment in 4.5.2 as the most logical description of this option.
1 Like
Quite obviously the biggest Upgrade in 4.5.2 is giving us
Development Environment:
in the Project Settings
Outstanding! 
Kudos to @mebeingken, too!
Development Environment it is.
As I understand it, Ken, the Wappler provided server at localhost:3000 is just to view a file in a browser. I donât use it because the Localhost Database server is the next thing I want to set up in a Project.
I know my database will be Mongo, Maria, PostgreSQL or MySQL â so I get set up quicker to already have Mamp installed on my Mac.
Iâve already got a specific new database with some initial tables I will need.
So setting up a new project in Wappler goes quickly at localhost:8888 and database localhost:8889
For you guys doing nothing but Node I understand that Wappler has really stepped up its game with the Node server.
I Hope to be jumping in to that after this last little php project is over.