Deploying to both Web and Device

Here we talk a little about some differences in deploying to native devices over the web, and what is required from the codebase to do so. We then explore some potential solutions to solve these issues.

Building for native devices

One main caveat of building for native devices is that the final build needs to be able to run completely clientside. Another is that deploying a new build requires submitting to the app stores and being manually reviewed and approved.

This makes building for devices more cumbersome than deploying to the web, and means the following must be followed when deploying:

• No serverside rendering in the codebase
  As the build must be able to run completely clientside, we cannot have serverside rendering in the codebase.
• Generating new builds are not quickly deployed
  A common paradigm on the web is to use serverside generation to build an app from stable data, then push the bundle to the web. This is then re-generated based on CMS changes or other triggers to ensure a static site that can stay up-to-date.
  As deploying to the app stores is much slower than to the web, this approach likely will not work anymore.

This means, in the codebase that will be deployed to the devices, we recommend using ssr: false, and not using serverside rendering at all.

If serverside rendering is required on the web, the simplest solution is to create two Nuxt projects: one targeting the web with SSR/SSG, and one targeting devices.

Further Solutions

Having two completely separate codebases to target web and device is a little cumbersome, so there are some potential solutions you could explore.

These solutions are outside of the scope of this module, but are provided as guidance on improving your own DX in these cases. We'd love to hear about if you implement these successfully.

A single codebase

It may be possible to have a single codebase with both SSR and a fully static application in-tandem, with code-switching based on configuration. E.G. when building for the web, setting ssr: true, and when building for devices, setting ssr: false.

You may need further wrapping around other SSR-aware code and utilities, such as useAsyncData().

A monorepo

You would likely be able to reduce the burden of two separate Nuxt apps by utilising a monorepo. The majority of your shared code could exist within a core package, while having two Nuxt apps, one to target Web with ssr: true and one to target devices with ssr: false.

A possible directory structure for this may look like:

- apps
  - nuxt-web
    - ...
    - nuxt.config.ts
  - nuxt-device
    - ...
    - nuxt.config.ts
- packages
  - core
    - components
    - composables
    - ...