Note
For Finnish speaking folks: Tekninen dokumentaatio on saatavilla ainoastaan englanniksi.
Introduction to Dream
This manual is for the technical user who wants to understand how the platform is built and how it can be used to build services. Visit www.dreamplatform.fi for more information about Dream Platform, the history, where to use it and explore the reference systems with Dream under the hood.
Dream Platform consists of working models, UX guidelines, and ideas of how to create services which empowers the user to manage his/her own data, access everything from one place, and ease the everyday life.
Dream Platform is mainly written in Python using the Django Framework.
By utilizing the open source Dream Platform, you can build or have built for you a web-based system from your needs. Dream Platform offers a set of ready-made building blocks for your system, but also a collection of finalized service solutions. There’s also a bunch of integrations for other systems already made.
Dream is designed especially for systems with focus on tasks, work and material, and the related communication. Thus, the platform is utilized in education and learning environments, as well as ERP systems.
The goal is to enable better use of the existing and upcoming tools appearing in the market. Core principle for Dream Platform is to be the glue that holds all other pieces together.
- Green boxes in the diagram are part of Dream Platform.
- Blue boxes are written and designed by you.
- Yellow boxes are from 3rd party we rely on.
By looking the diagram from the top we can see how two services are stacked together. User sees domain id.service.com or app.service.com. This is usually the case that id service is separated from others. It is easier to build the system this way as SAML likes to have separate domains for Identity Provider and Service Provider. Also it is common sense to separate identity management from other services.
App on the other hand combines three service templates from Dream Platform. It has desktop, messaging, and diary functionalities combined to one service under one domain. This depends totally on the customizations and service design on top of Dream Platform.
There is one library which extends below desktop, messaging and diary: dream-sso is a common library for all services. It connects the service to the userdb and provides account management.
Using Django and Celery
Dream Platform is based on Django web framework. Django is described as:
Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. Built by experienced developers, it takes care of much of the hassle of Web development, so you can focus on writing your app without needing to reinvent the wheel.
Django has the concept of reusable apps. Each Django app contains database models, view logic, templates, static files for the UI and so on. This same concept is used in Dream Platform. Each Dream-library is a self-contained Django app. There are of course dependencies between apps, but the idea is that each app does one thing and provides abstractions and API for other packages.
Dream Platform also uses Celery extensively. Celery is described as:
Celery is an asynchronous task queue/job queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well. The execution units, called tasks, are executed concurrently on a single or more worker servers using multiprocessing, Eventlet, or gevent. Tasks can execute asynchronously (in the background) or synchronously (wait until ready).
By using Celery and background running tasks gives Dream Platform easy way to scale. Each server is stateless and Celery workers can be added easily.
Stateless servers
Servers must be stateless for scaling to be easy. Servers can be added and removed based on load, not based on data or state.
There are basically two types of servers running actual code:
- Web request handlers
- Celery task workers
Web request handlers are behind a load balancer and they receive requests from browsers or other clients.
Celery task workers are waiting tasks from message queues. There can be multiple queues and multiple workers per queue. Again easy ways to scale based on actual load.
Multitenancy
Dream Platform is designed to be multitenant. Dream Platform uses Organisation as the concept of tenant. Meaning there can be multiple separate groups of users inside one system. User can belong to multiple organisations or be tied to only one organisation.
Organisations don’t know about each other. They have separate configurations. Everything in Dream Platform is tied to organisation some way.
It is possible to build services which have only one organisation. Dream Platform has a concept of active organisation for a user. If there is only one organisation then you can hide the concept of organisation from the UI altogether.
Common experience
User must always feel safe and navigation must be easy to follow. There should be always easy way back home.
The desktop is usually the home for the user. From the desktop user can move between services and parts of services.
Another good home for the user is her profile in Dream UserDB.
The dream-widget provides the functionality to handle navigation over all services. Dream Widget, when used, is part of Dream UserDB to have access to user profile and service information.
There is dream-widget-client which is used in all services. It is simple snippet which is put to all pages:
<script src="https://id.example.com/dream.js"></script>
This single line gets the Dream Widget and injects it into the page.
Most Dream packages have basic styles and templates for you, but black text on white background may not be for you in all cases. When you are designing your system you should write design guidelines and style guide. These guides should be followed by all services in the system.
Identity Management
User information is usually scattered to multiple directories. Dream UserDB makes it possible to gather that data from all sources, manage it centrally, and provide the data from one API to everybody. Each Organisation can have different source of users. The data flow is managed centrally via a single management interface.
Single sing-on API support means users need to authenticate once to Dream UserDB and then all services get the identity information when user moves between them.
Services
There are several service templates. These templates can be combined, customized, or use as is. It is up to you, the service designer to decide.
- Dream UserDB
- User authentication, account information and permission management.
- Dream Desktop
- The home for the user. List of all services and important information.
- Dream Messaging
- Ubiquoitus messaging between users, services and devices. All of them can use all of the multiple interfaces to access the central hub for messagning.
- Dream Diary
- A place where content and information is gathered from different services. Diary has three levels of data. You can use those for example to create learning networks, collections of networks and then the actual material. Material can be anything from any service.
- Dream Store
- Manage who has access to which service and functionality. Users can ask for access.
Deployment
Dream Platform has guidelines and best practices also for deployment and hosting. Deployment of the Dream platform can vary widely based on the needs of the system which is built with it.
Package reference
The complete reference manual for all packages in the Dream Platform. Each package is a separate repository. The documentation is generated from these repositories.