Managing Multiple Localhost Domains in Wappler

[JonL]

Summary

I am proposing the development of a feature within Wappler that enables us to manage multiple localhost domains across different operating systems (MacOS, Windows, and Linux). This would automate the manual configuration of the hosts file and could potentially introduce a reverse proxy setup for localhost domains for port forwarding and certificates , hence making the management of multiple projects smoother and more efficient.

Basic example

A user interface within Wappler where developers can easily manage their localhost domains. Users should be able to add, list, and remove local domains for their projects.

# Add a new domain 
Wappler > Localhost Manager > Add Domain > website1.local /path/to/project 
# List all domains 
Wappler > Localhost Manager > List Domains 
# Remove a domain 
Wappler > Localhost Manager > Remove Domain > website1.local

Motivation

Currently, all projects are running on the same local domain and port which creates several issues with browser cookies, cache, DNS, and potentially more. It also causes confusion with password managers and other browser plugins. While you can change this manually automating the process of domain configuration within Wappler would significantly reduce these problems, enhance user experience, and increase efficiency.

Detailed design

This feature could be implemented as a new module within Wappler’s interface. It would leverage OS-level commands to modify the hosts file, and potentially introduce a reverse proxy setup to handle different localhost domains. This would ensure compatibility across different operating systems.

Main alternatives

1. Centralized Localhost Manager

A dedicated interface for managing all localhost domains. This manager would allow users to add, remove, and list domains for each project from a single location.

2. Per-Project Localhost Configuration

Wappler would provide the option to manage localhost domains within the settings of each individual project.

Requirement List

Must Have

1. An interface within Wappler that allows users to manage localhost domains.
2. Capability to add, list, and remove domains for individual projects.
3. Cross-platform compatibility for MacOS, Windows, and Linux.
4. Automation of the manual configuration of the hosts file.

Should Have

1. The ability to introduce a reverse proxy setup for managing localhost domains to not only handle the local domain but the port in order to avoid given admin privileges for ports below 1024
2. Seamless integration with existing local server configurations.
3. Comprehensive documentation and tutorials to guide users on how to utilize the new feature.

Could Have

1. A centralized localhost manager for a consolidated view and management of all localhost domains across all projects.
2. A per-project localhost configuration option for granular control over domain settings.
3. A hybrid approach combining both centralized and per-project configurations.

Drawbacks

The main challenge would be ensuring seamless operation across different operating systems. Additionally, this feature might increase the complexity of Wappler’s interface and potentially introduce new bugs. However, the productivity gains for users would outweigh these potential drawbacks.

Other Alternatives

1. Refactor Local Server Management : Consider a refactoring of the current local server management. Introducing a section in the resource manager to handle them could streamline the process.
2. Central Server Control : A new section where you can control servers for all your projects in a centralised way might be useful to be able to start local servers for different projects.
3. Command Line Interface (CLI) Tool : A CLI tool could provide advanced users with more flexibility and automation options.
4. External Localhost Manager Integration : Wappler could provide integration with an external localhost manager tool.

Adoption strategy

If the team implements this proposal, they would need to provide detailed documentation and tutorials to help users understand and leverage this new feature effectively. This would probably need to be set as an experimental feature for some time.

Unresolved questions

• How to ensure seamless operation across different operating systems?
• Should we introduce a reverse proxy setup for localhost domains?
• How to design the user interface to provide the best user experience?
• How would this feature interact with the existing local server configurations?
• Would a centralised management system for all local servers be beneficial for the users?

[Apple]

Lando uses Traefik for localhost

Home

So each project has its own local domain

[JonL]

Looks nice and has a cool name
I don’t mind using an external tool if it has a small footprint and doesn’t interfere with Wappler but the FR would be nice for others who don’t want to work with CLI and yaml config files.

Do you use it?
Any considerations when using it with Wappler? What does it replace effectively?
How do you prevent wappler starting the server? By removing the handler?

Lando would be a great example of why this FR could change everything for Wappler:

Wappler Studio embedded nodejs server w/ project context

This topic: Got me thinking about how to integrate secret managers as each cloud provider has it’s own solution (Google, Amazon, DO, etc) and also there are several self-hosted solutions out there(hashicorp vault, doppler, infisical, etc) each one of them handles their API in a different way. How about creating a small nodejs embedded server based on Server Connect (w/ a subset of actions) that runs in the context of a project? Then you just need to place hooks all over the UI logic to give…

I could create a SC workflow to manage lando CLI from a custom SC action that spawns a child process:

const { exec } = require('child_process');

exec(‘lando start', (error, stdout, stderr) => {
  if (error) {
    console.error(`exec error: ${error}`);
    return;
  }
  console.log(`stdout: ${stdout}`);
  console.error(`stderr: ${stderr}`);
});

[Apple]

I’ve used it when I was developing in Laravel. Haven’t tried using it with Wappler

It would essentially allow running multiple projects at the same time without colliding ports. To use with Wappler, one would need to prevent Wappler from starting the NodeJS server on its own. Behind the hood, Lando takes a base docker-compose file (generally a bundled one, more advanced users like us could specify one manually) and puts Traefik tags so a domain with the name of the project is available on localhost

[George]

Actually you already can use the *.localhost as local domain name.
Like my-fancy-project.localhost

It is already implemented on the most OS

It comes from this propasal:

Let 'localhost' be localhost.

[JonL]

It is still not adopted by all browsers. It doesn’t work for safari for example. You still need to modify your hosts file for it.

And it doesn’t solve the port forwarding problem. You would be able to access all apps at any domain:
app1.localhost:3000
ihatecats.localhost:3000

They would resolve to whatever app you have running which interferes with cookies, cache, DNS, password managers.

Therefore it’s not a solution for the FR proposed.

[sid]

Keeping in mind that I don’t have detailed understanding of things listed here… I do take away one point from this FR - to be able to run multiple apps without having to keep switching between projects.
Is that the gist of it?

Or is it just talking about running each project on a different domain/port but only one at a time?

[JonL]

Both features in fact.

To be able to start and run the server for any project in a centralized and streamlined way so they would need to run on different ports(3000, 3001, etc)
To be able to configure your OS to run those servers in port 80(or any other) and in different local domains. Be that .localhost or other.

[sid]

That would be a huge time saver. Right now, I not only have to keep switching projects, but waiting for the project updater dialog is another pain.

[George]

Maybe this project can help, we can use ti as wrapper for our local server:

GitHub - KishanBagaria/localhost-mapper: 🔗 Run your dev servers on addresses...

[JonL]

Looks nice, but not very active. Maybe it has some implications too that are unknown given that there isn’t much documentation about it.

Also only for express so I can only think of reverse proxies to cover all server models.

Right now I’m fiddling with Nginx Proxy Manager as I’ve used it before for homelabs and has a nice and simple UI, but you guys probably have more expertise on Traefik.

Lando is docker based so it leaves behind local and internal servers.

I think the option to add a reverse proxy in front of all development servers could kill a few birds:

1. Better looking development domains(paired with programatically modifying hosts file)
2. Running servers for several projects at the same time(ports 3001, 3002, 3003, etc)
3. Certificates

[Apple]

@JonL

Better looking development domains(paired with programatically modifying hosts file)

Are you sure you want to modify the hosts file instead of using a subdomain of .localhost?

[JonL]

I would prefer using a subdomain and not have to deal with the hosts.

But webkit doesn’t support it yet so for testing browsers it could become a problem.

Maybe by the time this is implemented, if it’s implemented, they will support it.

[George]

Yes Safari is the only one not being able to handle localhost subdomains, there is a bug there reported for already 7 years: https://bugs.webkit.org/show_bug.cgi?id=160504

Other than that all other browsers support localhost subdomains, so you can already use it by entering as Web URL in your project settings in Wappler by just changing the default http://localhost:3000 to for example http://my-project.localhost:3000