|
|
|
|
|
|
by chvid
3663 days ago
|
|
|
How is authentication/authorization handled in this example? The code hits a web api that sends out a batch of emails. Doing this from client side has an obvious set of problems, whereas had it been on server side one can assume a stricter use and thus have a simple security model. |
|
|
``` 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).