Server ToDo

Maaas.io account management

• Need ability to create account, login to that account
• Accounts need to be able to collaborate on projects (invite, join, admins to manage, etc)
• Apps under projects? Master account? Need some kind of organizing structure.
• Roles / permission (for example, only some people can edit and check-in code, only some people can deploy, see logs/metrics, etc)

Maaas.io documentation

• Need to publish Wiki to web site
• Use marked [https://github.com/chjj/marked] to process markdown
• Use highlight.js [http://highlightjs.org/] for code formatting/beautification
• Look at Dillinger - example of using Node/marked/Bootstrap together

Security

• Process isolation for apps (sep process required?, just context?, stubbing of globals?, custom require/loader?)
• Custom node_modules support (assuming no native code)?

Maaas app configuration and manangement

• Each app may have multiple targets (john-sandbox, test, staging, production, etc)
• How do version control branches factor in to this?
• Ability to spin up individual app sandbox for testing
• Server -> App -> Target (default target is production)
• Possibly use notation: appName for default or appName{target} for a specific target
• Refer to server/appName/target as "endpoint"?

Hotloading

• Working now, will need cluster IPC mechanism (pub/sub?) for clustering

Editor / Debugger

• Disable editing/saving of non-user modules
• Decide whether to allow edit/save of user modules during debug, implement
• Move breakpoints as user edits (to maintain position)
• Store breakpoints in session state so they can be set/seen when not debugging
• Implement module new/delete

Team / Source control

• Full version control (diff, change tracking, integration, rollback, etc)
• Page or entire branch
• Because all dev is online, need to maintain "local" changes on server (is this a "branch"?)

Deployment management

• Deploy from one target to another, for example: staging->production
• Revert / roll-back
• Probably tight integration with source control

Unit test

• App modules expose unit tests
• Test running in dev environment
• Automated testing on check-in and/or deployment (or by policy)
• Model fixtures/mock support (more explicit view-model/model separation?)

UX test

• Would be cool to have a web client (Knockout.JS style), which could also be used for UX test

Metrics/Analytics

Logging

• Provide client with logging APIs
• Integrate into debugger console
• Log viewing / log management tools?

Push notification / Badges

Resources

• Some mechanism to share static values between Maaas user modules
• Perhaps more sophisticated, like template fragments?
• Styles? - a set of attributes to be applied to a control, or all applicable descendant controls?

Asset management

• Primarily images (what else?)
• Provide facility for uploading/managing application assets
• At runtime, select proper asset instance based on locale and/or client metrics (including resolution/scale)

Localization

• Provide simple mechanism to maintain localized resources (strings, string templates, images)
• Use locale reported from client when mapping

Client builder

• Look at how Adobe does this
• User selects an app target
• User supplies details (app name, etc) and resources (icons, splash screens, etc)
• User optionally specifies capabilities (network access, location services, etc)
• Client builder produces built images for download
• Option to sign as Maaas.io or prepare to be signed by client (any way to sign as client or streamline this?)

Caching

• As needed based on observed performance
• View template cache (per-request, web-like, or we could manage more state on the server to be predictive)
• View templates are pretty small, and minimum round trip latency is probably the biggest cost
• Caching might make more sense for assets (images, videos)

Session management

• Session is per client + server/app (server/app{target}?)
• Session data should be persistent
• Client will store session-id (that's all the local state they will have)
• Session data access needs to be fast (table storage, if needed, fronted by cache service)
• Session data writes need to be fast (if needed, can use objectmon to determine if any diffs before writing)
• Possible solutions: Redis, Azure cache + table

Maaas test client

• Maaas branded, available in app stores
• Maaas welcome screen, list of previously used Maaas apps
• Would be nice to have per-Maaas-app icons to show, along with other details
• Ability to add new Maaas app (defined by server, appName, branch (optional), PIN?)
• When adding new Maaas app, verify with server and get details (description, icon maybe)
• Ability to remove Maaas app from list
• Select Maaas app to launch it
• If app times-out or dies, return to launcher. Other mechanism to force return (won't be any app nav)?