Figure out domain name situation when extending to multiple disaster events

[nihonjinrxs]

Hurricanes? What about tornados? Earthquakes? Fires? Floods? Droughts?

So far, proposals have included:

• Single domain for API, but separate event-specific domains for front ends
• Single domain for all, with subdomains for API and each event's front end
• Single base domain, but heavily namespaced base URLs for API and event front ends

What are we doing here?

[miklb]

cc @GovInTrenches

[nihonjinrxs]

@GovInTrenches @tdooner @omnilord Let's make some decisions on this so we can get started implementing #73 -- do you all have thoughts/preferences?

[miklb]

I’m down with some form of “shelter tracker” as a domain.

[miklb]

To follow up on this, I'd like to start working on the map code again. Right now we just have what was open in the API when Michael wound down, and the MichaelResponse.org site. I'd like to start a clean new map site where we can fork and go for each event, use config settings to allow easy edits for event/storm name, etc. Would be nice to have a full demo site with all of our shelters in the database available to view on a map to demo.

Would make sense to do that after we have decided on a domain structure. I was thinking event.year.domain.tld so florence.2018.sheltertracker.org for example

[tdooner]

One problem I remember during the Irma response effort was that it was impossible to get any semblance of organic traffic to the site, via SEO or otherwise, due to the fact that the domain had been registered just a day before the outreach began. Other technical problems also came up with the "fork and redeploy" model - for example I remember being stymied during development of a Facebook Messenger chatbot by Facebook's manual review of new chat apps.

If there were a single "product" that could support multiple disasters, I think that would help us out quite a bit. Imagine- the site for hurricane N gets linked from a Red Cross page, and if the site is something like sheltertracker.org/N then we'd have a base to build upon when hurricane N+1 comes by.

I'm not sure the behavior of subdomains with SEO, so perhaps that could be an option. The subdirectory option could also be implemented via a reverse proxy.

I've been tuned out to the development here for quite a while, but if you all think it is a good idea to move in the direction of a single sustainable product, I could contribute to making that a reality. What are the tradeoffs of re-deploying a new instance every time?

[miklb]

That’s actually the plan, a single product that can respond to multiple events.

As to SEO, I’m not sure an iframe for the map helped or not. I also know Google had their own map with data that closely resembled what we had.

I think right now deciding on a name so we can start solidifying api documenting and updating (some places still have Harvey if I recall)

I’m also thinking about a better demo with the new map that’s native with MapboxGL instead of stale 2018 that’s available via the live APi endpoints

Also to SEO, if we come to a consensus on a domain if shelters are the focus, that will be a narrower target than hurricane response which is extremely broad. I think.

[miklb]

Apologies. I think I misread some ideas sometime back. I thought we wanted a single domain and instance for the API and allow it to pull specific feed for that event, then use either subdomains or subdirectory for the front end.

I thought we were just trying to decide on the domain name.

[omnilord]

@nihonjinrxs I think we solved this issue with the hurricane-response.org URL and putting the API on the api subdomain and using hurricane/event naming for the front end mapping sites. Should we close?