A simple example of using nuxt for front-end development and ServiceStack for backend development
Switch branches/tags
Nothing to show
Clone or download
Permalink
Failed to load latest commit information.
backend Upgraded ServiceStack to v5 Dec 15, 2017
frontend Upgraded Nuxt.js to 1.0.0-rc11, and ServiceStack to 1.0.44 Oct 24, 2017
.gitignore Project commit Jun 14, 2017
LICENSE Initial commit Jun 10, 2017
README.md Fix Jun 14, 2017

README.md

Simple demo of using ServiceStack and Nuxt.js together

Modeled after https://github.com/nuxt/example-auth0, with a few additions (separation of backend from frontend, static/ssr page example, http proxy, role-based visibility and functionality ...)

In this demo

servicestack-nuxt-example-thumb-video

Development

Install node packages

# cd into the 'frontend' directory
$ cd frontend

# install dependencies
$ npm install # Or yarn install

Run the ServiceStack backend (will automatically run dotnet restore, build, etc...)

# start the ServiceStack backend in a terminal (from within the frontend directory)
$ npm run server

Alternatively, you can edit this script in 'package.json' to run dotnet watch, etc ...

Run the frontend

# serve with hot reload at localhost:3000, uses http-proxy to connect to ServiceStack api at localhost:5000
# make sure the backend is started first
$ npm run dev:local

# optionally serve with hot reload pointing to a live API url (make sure the API_URL env variable is set,
# uses http-proxy to connect to ServiceStack api)
$ npm run dev

Production

Front-end deployed to Node container

# build for production and launch server (make sure the API_URL env variable is set)
$ npm run build
$ npm start

Front-end deployed to ASP.NET

# generate static project and merge into ServiceStack asp.net project (generates and copies dist to wwwroot)
$ npm run server
$ npm run generate

Typically static pages would be generated against a remote API, in which case, setting an API_URL env variable in the command above would make sense, and there is no need to ever run a local version of the backend locally.

Furthermore, you could then separate the backend into it's own repo and split up nicely the dev effort between both for larger projects.