atomic-server icon indicating copy to clipboard operation
atomic-server copied to clipboard

Dealing with changing URLs in local context - improve local development setup process

Open joepio opened this issue 3 years ago • 0 comments

Although atomic-server is primarily designed to run on some publicly accessible, DNS hosted domain, developers will probably run in locally. If they do, they are likely to run into problems.

On initialize (which is run the first time you start the server), resources are created for that domain. By default, that is localhost. If a developer will change this (e.g. by changing --domain or --serverurl or --port), there will not be a resource available when the developer opens his browser.

How to fix this?

Also, relates to auto-detect IP #272

Check if the root Drive resource is available on starting the server

If it's not there, create it. This means there are now two Drive resources. The first one probably did not contain important stuff, but it just might. The developer will not have a way of finding this data now.

Context-depdendent Subjects

Make the first part of local resources' subjects dynamic, depending on server setup. One approach is to always replace localhost with the domain value at runtime

This means the subjects will change. This also means that some Values must change, or else we're left with broken links. Dealing with this is far harder to implement, but still doable.

We could change all local subjects to /path instead of https://localhost/path. We can check if the string starts with / and do things differently when handling data. When running add_resource, we should check if it starts with server_url, and if so, we rewrite the string. Same for get_resource. But we also need to do this for setting values, and that's where things get really complicated.

Or we could change the datatypes for Subjects from String to something else (perhaps an enum, either external or internal?).

joepio avatar Jan 04 '22 12:01 joepio