-
Notifications
You must be signed in to change notification settings - Fork 3
Application Services
This app exposes two basic services:
- A Data Service for routes, content, and models.
- A Mail Service for queuing and sending outgoing mail.
The data service that provides the content and data for this example is just a Github repo referred to in the code as FRED (stands for Flux React Example Data, the name of the repo). FRED exposes a simple application resource model that defines routes, content, and models. Content and models can change with each app route.
A github repo was chosen for this example to present a simple, familiar backend. You can understand the data model format and relations at a glance by browsing json, without any specific CMS knowledge.
Two types of routes are used in this example. Both route types have additional models associated with them for consumption by various areas of the application. Additional models can be created and associated, and these can vary per-route.
-
Simple Content which is a markdown document. This type of route references the
ContentPagecomponent for consumption, found at/components/pages/ContentPage.jsx. -
Complex Content which is a json response. This type of route requires a specific component for consumption. In this example, that is the
Contactcomponent, found at/components/pages/contact/.
The action creators that use the Data Service are /actions/page.js and /actions/routes.js. In this example, the page action runs on the client and the routes action runs on the server.
The page action is the main application action executed when a navigation occurs. It is responsible for getting the content and models from The Data Service and updating the page title. Content and models are cached in stores/ContentStore.js.
The page action is the only action currently available for reference from the backend data service. Actions are made available for reference from the backend in the /actions/interface file.
Interestingly, routes could be included in the actions interface for referencing on the backend. This would enable routes to dynamically reference other routes (and so on).
The mail service for this example consists of an MQ service on the application tier to collect the outgoing mail, and defaults to Mandrill for the actual mail service - It could use any well-known mail service.
The action creator that uses the mail service is /action/contact.js.
These services are a made seamlessly available both on the client and server via Yahoo's fetchr and fluxible-plugin-fetchr.
In addition to the services exposed by the app, an image processing service is consumed directly on the client side. The current live reference on Heroku is configured to use Cloudinary.
This example consumes images from an image service for the backgrounds. The requests originate from components/Background.jsx and are indirectly requested whenever a size action is executed.