Backend setup

Weacast core module provides a helper to quickly initialize what is required for your server application. The core module provides the ability to initialize a new Weacast application instance, attach it to the configured database and setup authentication:

import { weacast } from 'weacast-core'

// Initialize app
let app = weacast()
// Connect to DB
await app.db.connect()

Authentication

Weacast includes a built-in local authentication strategy based on the Feathers authentication module. It also automatically configures the Feathers OAuth2 plugin for GitHub, Google, OpenID Connect and Congnito if you provide them in your configuration file.

You can read this article to learn more about the underlying process.

HTTPS support

Adding the right configuration like below you can easily Weacast run under HTTPS:

https: {
  key: path.join(__dirname, 'server.key'),
  cert: path.join(__dirname, 'server.crt'),
  port: process.env.HTTPS_PORT || 8084
}

Client setup

Weacast client module provides a helper to quickly initialize what is required for your client application.

import { weacast } from 'weacast-client'

// Initialize API wrapper
let api = weacast()
// Retrieve a given service
let probes = api.getService('probes')

Application API

.getService(name) - backend/client

Retrieve the given service by name, should replace Feathers service method so that you are abstracted away from service path (i.e. API prefix) and only refer to it by internal name.

On the client side this is also used to instanciate the service on first call.

.getElementServices(name) - backend only

Retrieve all forecast element services related to a forecast model (or all if not provided) instance by name.

.createService(name, app, modelsPath, servicesPath) - backend only

Create a new service attached to the application by name and given a set of directories where to find model/service

This assumes you have created a models and services directories containing the required files to declare your service, e.g. your folder/file hierarchy should look like this:

  • index.js
  • models : constains one file per database adapter you'd like to support, e.g.
    • serviceName.model.mongodb.js : exporting the data model managed by your service in MongoDB
  • services
    • serviceName
      • serviceName.hooks.js : exporting the hooks of your service,
      • serviceName.filters.js : exporting the filters of your service,
      • serviceName.service.js : exporting the specific mixin associated to your service (optionnal)

Only MongoDB is officially supported right now although we had an experimental attempt with LevelUP as well. Please contact us if you'd like to support more adapters.

.createElementService(forecast, element, app, servicesPath) - backend only

Internally used by forecast model plugins, similar to above but using the built-in forecast element model.

Application Hooks

The following hooks are globally executed on the application: Application hooks

results matching ""

    No results matching ""