Weacast

# Application

# Backend setup

Weacast core module (opens new window) provides a helper to quickly initialize what is required for your server application (opens new window). 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 (opens new window). It also automatically configures the Feathers OAuth2 plugin (opens new window) for GitHub (opens new window), Google (opens new window), OpenID Connect (opens new window) and Congnito (opens new window) if you provide them in your configuration file.

You can read this article (opens new window) to learn more about the underlying process.

# HTTPS support

Adding the right configuration like below you can easily Weacast run under HTTPS (opens new window):

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

# Client setup

The Weacast core module (opens new window) or the legacy Weacast client module (opens new window) provides a helper to quickly initialize what is required for your client application (opens new window).

WARNING

Weacast client module (opens new window) will not evolve anymore (see discussion here (opens new window)) and will only be maintained for the purpose of our demo application (opens new window). If you'd like to build client applications using Weacast you'd better use the client API layer in core module (opens new window).

import { weacast } from 'weacast-core/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 (opens new window) so that you are abstracted away from service path (i.e. API prefix) and only refer to it by internal name.

TIP

On the client side this is also used to instantiate 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.
  • services
    • serviceName
      • serviceName.hooks.js : exporting the hooks (opens new window) of your service,
      • serviceName.filters.js : exporting the filters (opens new window) of your service,
      • serviceName.service.js : exporting the specific mixin associated to your service (optional)

WARNING

Only MongoDB (opens new window) is officially supported right now although we had an experimental attempt with LevelUP (opens new window) 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

← Forecast model →