-
Notifications
You must be signed in to change notification settings - Fork 5
Home
Lux is focused on creating an accessible environment for startups and front-end developers, enabling them to be more self-reliant and focused on developing technology at their speed. Lux is not just a backend as a service, but a full suite of products that are integrated into a single package that allows for creation of products, services, and business tools with a strong online presence. Lux is built to be facilitate growth; every aspect of lux can be easily tied together, while still being treated as a separate entity. This ability to grow and change with its needs allows lux to be a powerful tool, and big reason to make open-source a core aspect of the project.
| Priority Level | Description | Jake's Est | Team Mi Exp | Team Max Exp |
|---|---|---|---|---|
| 0 | lux should be useful in building any simple application, with or without client logins, with limited end-user specific functionality. These would be primarily static websites or application's who focus on information distribution rather than on functionality (A database website, a registration, or corporate webpage). | 17 | 34 | 66.5 |
| 1 | lux should be well-suited to building any single player game or non-realtime multiplayer game. This includes turn based strategy games, longer term games, and any single player game. | 31.5 | 63 | 123 |
| 2 | lux is appropriate to creation of any multi-player game with realtime game play functionality, including MMO games and real-time strategy games. This section may need to be revisited to improve functionality- but relatively large sets of user's (on the scale of 5,000) should be able to play this game without server-side interruption on a ec2 t2.micro instance. A larger AWS Instance would scale this number appropriately with respect to the number of processors and processor speed. | 41 | 82 | 154.5 |
| 3 | lux should be capable of handling most social games or applications, given the correct knowledge and usage. This also concludes the FOSS portion of lux, and some functionality is possible through this section, but not as simple or as well handled as it would be with the proprietary portions of lux. | 55.5 | 111 | 218.5 |
| 4 | This is the basis for the lux proprietary model and offers the ability to launch and pay for a lux instance through a web interface, so that internal and external developers can begin using lux to create their own applications. | 81.5 | 163 | 293 |
| 5 | This level is meant to add value to lux proprietary on top of the FOSS and the ease of launching a FOSS instance in the form of more APIs that are still generalized for use in all applications. | 99.5 | 199 | 356.5 |
| 6 | Priority 6 is meant to make launching and creating a non-technology business easier and faster in order to give incentive to use lux proprietary. These are APIs and tools more targeted at solving complex technology problems for non-technology business models. | 125 | 250 | 442.5 |
| 7 | This is meant to make rapid technology development more feasible on lux for less experienced front-end developers, who wish to build an application. The same tools can be used by more experienced developers in order to more quickly build and deploy games and applications on top of lux. | 155.5 | 311 | 531 |
| 8 | This level is designed to target application's towards more developed companies, making it possible for them to deploy games and application's with an automatically generated API and automated testing procedures, making lux more appealing to large companies. | 185.5 | 371 | 616 |
| 9 | This level is intended to help developers monetize their applications through lux by providing easier access to integrated advertising and advertising networks. This means that developers can build application's with passive revenue streams using only lux. | 224.5 | 449 | 724 |
| 10 | This level is meant to help small businesses rapidly deploy products on top of lux with a minimal number employees, focusing efforts on functional game or application development. | 258.5 | 517 | 812 |
| 11 | These are only extra functionalities to be added to make lux a full and complete package, as well as to increase the number of rapid development uses. This is the lowest level priority because most of these elements act as (almost) stand alone products which would need full development and are not really within the scope of this project. |
*All of the above Estimations are in 1 person 8 hour days and are cumulative *Descriptions are what lux should be capable of doing after this level is complete
The specialized skills that may be worth hiring for (All short-stay hires) in the near future are listed below, although some skills may have been overlooked:
- Advanced Multi-Threading and distributed computing
- Advanced HTML/CSS/JS for front-end development
- PayPal/Stripe/ Any Online Payment Gateway system experiance
- Advanced Shell/CLI Programming ability
- UDP/WebSocket optimization
- Real-time Streaming protocols (RTSP) building experience (not just interfacing with an existing)
- Other languages (for implementation's of SDK libraries)
Other skills that are always helpful or necessary for lux developers:
- AWS SNS
- AWS CLI
- MultiThreading
- Image Processing
- HTTP
- HTML/CSS/JS
- UDP
- RTSP
- AWS S3
- php
- WebSockets
- neo4j
- MySQL
- RegEx
- GitHub
- Python
- Mongo
- other languages
The lux project is an open-source project designed to grow and expand with the needs of the community. Contribution should be limited and monitored through GitHub, and will need a dedicated team to approve pull-requests from non-employee contributors. Affiliated contributors are in-house developers volunteering their time towards the lux project and maintaining the lux repository. The open source area of lux consists of the Back-end library on which applications are built, in this document they fall under the category of "API Calls For Lux".
The Open Source analytics platform is built into the API Calls For Lux, and is attached to it's own server-side processes. The Redux sections will be primarily open source, and given a marketplace around them- giving the ability to sell and profit off of redux functions. The data analytics framework is closed source, and not publicly available for modification.
The Open Source Community behind Lux will help to ensure that all possible features are developed and included in the lux library. Although any technology could theoretically be built on lux open source alone, the community is encouraged to use the closed source software as well.
Many Backend as a Service providers are focused on singular platforms or application types- hence Game Backend as a Service, and Mobile Backend as a Service. lux is designed to be applied to any sector or industry. Another theme in Backend as a Service providers has been to solve problems by increasing the amount of server-side hardware being utilized. Although this solution is unavoidable- lux should be able to scale well on a small server, and should not need an increase in hardware as it's only solution.
lux, unlike other backend services, should also have a heavy connection to it's analytics that creates an environment which not only services users, but also provides useful feedback about them and their interactions with the system.
- Developer: A developer working on top of a Lux instance to create an application
- Lux Developer: A developer working to develop Lux
- End-user: An application user who is using a third party application built on Lux by a developer
- lux Based products: Applications and Games Built on Lux.
Basic operations include:
- Upsert
- Create
- Edit
- Remove
- Query
However for most APIs these should be broken down into finer detail, allowing only a few parameters to be altered with any given call. For almost all calls, the user should specify specific key->value changes to be made, and the php should handle those changes. In general, "Add" or "Create" and "Delete" should not be used, instead a function for "Adjust" should be used for editing an existing, and will create if one does not exist, "Adjust" can also remove whatever property with either a "remove" tag, or leaving the update field blank. Unless Specified as ~access_token, all queries require an access_token. If access_token is optional (normally this changes behavior) then ~access_token? will be used. Any GET request can also be a POST request, however POST requests can not be GET requests in all cases.
Instead of Query, we should use get and fetch- where fetch is used when return value is dependent on user, and get is deterministic. Check should return a Boolean regarding the query (normally checking to see if a query is true or false)
The major exception to this, is Assets- which should be alterable via a direct Upsert so that they can remain as flexible as possible. For API wrappers (Social), the API should reflect the Social API as well as the users. The goal is to allow front-end developers to only use the lux API to create an entire application, and not need to interface with the server, or any other server, in any other way.
This document is for the exclusive use of the lux team. Any alterations should be noted in the comments, and then after discussion the changes can be made. APIs in the first section are ordered by priority, however some leeway is permitted for ease of development purposes. Please wait until you have discussed a section with the project lead before proceeding to build any aspect.
Priority is listed in the title of every API, and currently range from 0-8. Priorities 0-3 are considered to be part of the open source project, and 4-8 are considered to be part of the proprietary lux software. Each API is also marked with a difficulty level:
- Requires Only HTTP & Mongo Writes
- Requires a class which can be added to other APIs
- Requires Interaction with a non-Mongo database/third party service
- Requires Interaction with non-HTTP protocols to communicate with the End-User
- Requires server-side scripts to be running which will need to be multi-threaded and optimized
Priorities are superscripts
[TOC]
- Jake