Improved File Resolution

We introduced improved file resolution in ssc 0.5. If you are familiar with various static file http servers, or other popular static website hosts, you've no doubt come across various redirect and pretty URL options for serving up files from disk. Many http servers come with built in support for directing traffic from urls like:

/foo/bar/

to serve the contents out of files with names like this:

/foo/bar/index.html

Additionally, inside of /foo/bar/index.html you can use relative anchor tags to navigate easily to other pages, even without knowing their names or directory structure. In this case, an anchor tag like <a href='../'> would navigate to to /foo/. Support for these built in relative navigation short-hands is a core building block in most static websites.

Furthermore, these static file servers will also support redirects when you link to almost the right name. For example

/foo/bar

will redirect to

/foo/bar/index.html

if /foo/bar/index.html is present.

Some static file hosts even support "Pretty URLs", where html files with names can be treated similarly to index redirects, but without the "ugly" html portion:

/biz/baz

would server the contents of:

/foo/baz.html

if /foo/baz.html exists. Note that when viewing content from /biz/baz, your relative links resolve as if you are in the /biz/ folder, which is slightly different than the index.html example above where your HTML actually lives in its own folder.

This is a lot of words to spell out a few simple things:

• You need to be careful about relative linking, and the URL the http server serves your HTML from. A slash at the end can be the difference between page resolution and a 404!
• There are a whole slew of static file assumptions baked into the different static website ecosystem, which all need to be supported for everything to "just work".
• Edge cases exist and behavior can differ slightly between various http server configurations and static file hosts.

Socket runtime resolves this for you

As of 0.5, ssc implements most of these rules by default, so your various multi-page app frameworks should "Just work". If it uses the 'index.html' pattern, it works. If it uses /biz/baz.html named pages, accessed at /biz/baz, those also work (this is what Next.js does). If it has an http dev server following similar rules, the static file output behavior should match up well. The goal here is to make it match up with expected behavior found found across all common static file servers.

Why though?

When shipping application code all the way to the edge (stored and served from users actual device), some of the common website serving optimizations make less of a difference. But that's not the point here. The point is that if you architected a multi-page app, you shouldn't have to re-architect it much to have it work in the Socket Runtime. By supporting many of these assumptions so its now possible to more easily port multi-page apps to ssc with less modification to an existing codebase. If your next.js app builds in pure static mode, you can now bring your codebase into ssc without making dramatic changes, and everything still works with the built in next dev server (hot reloading and all!).