3 ms·
We don't plan on supporting custom domains, because we don't think people will serve up content directly from these scripts. (We think of them more as APIs, so
by smarx 14y ago
We don't plan on supporting custom domains, because we don't think people will serve up content directly from these scripts. (We think of them more as APIs, so typically invisible to end-users.)
That said, my startup's other product (www.site44.com) is great for serving up content and does support custom domains. We plan to add support to Site44 for forwarding API calls to Webscript. So you could build a full HTML app with content served from Site44 and API calls handled by Webscript, all with a custom domain.
- blacktulip 14y agoIt is actually not about serving content. Custom domain makes the fail over much easier. For example, someone uses webscript.io as his app backend. If webscript.io goes down for whatever reason, he can simply point the URI to a backup server(provide he has one) if he uses a custom domain. Without custom domain all he can do is wait.
- smarx 14y agoAh, good point; thank you. We'll give this some more thought.
- hashtree 14y agoClever ideas, on both counts (webscript and site44). I wish you and Todd success.