[piercey4]

The way that I typically setup my apps is to have two parts of the server. Typically something like:

``` if (!process.browser) app.use(require('./api')) ```

Where the api is your typical REST based api with JWT auth tokens. Then the shared client side part of the api communicates with the secure part through "fetch" which works isomorphically (in the browser it is an ajax request, in the server it is a local http request to itself) you should checkout @rill/fetcher for what I currently use. In Rill there is no issue with having "client only" or "server only" routes, the main benefit is that the api is the same no matter where you are working. Take for example "@rill/progress" which is a progress bar that only does work in the browser, or "@rill/compress" which only does anything on the server or "@rill/logger" which works on both (although with completely different implementations). The goal is certainly to encourage code sharing where possible but to also not get in the way. You can use Rill as a standalone server only app if you want, or even just as an in browser framework, it doesn't really matter.

As for my example with emails it is certainly not real world and I don't recommend having public access to an email api but the point was merely to demonstrate that all of the code could be abstracted to work in either place (even without rill).