Home

• API - REST API
• Architecture - Code architecture
• Configuration - Application configuration

Next Steps

There are still many mongo API calls to be added: createIndex, distinct, findAndModify, etc. (See here for the full list)

Issues

The major project issues can largely be found in the github issues. Smaller issues (e.g. edge cases) may also be found as TODOs in the code. Below is a selected listing of larger issues.

Essential

• #82 - Chromium returns identical res_ids on creation
• #83 - Multiple session IDs created per user
• No malicious query protection
  • No maximum collection size per user
• No back-end garbage collecting of unused back-end resources
  • Unused resource IDs
  • Old user session IDs

Notable

• #107 - Specify browser compatibility
• #96 - Move user authentication to decorators
• #67 - Warn user when keep-alives fail
• Multiple successive statements to the shell may not print the output in the order they were called because some requests are asynchronous. See mongo.Shell.prototype.evalStatements().
• The client <-> server error handling is not well-thought out or robust. It may be a good idea to reconsider the API for this, as well as the error handling code at both endpoints.
• The CORS code in mongows/mws/views.py, standalone_server, and the actual client <-> server interaction has no automated tests and is no longer well tested by hand (see Architecture for more details on this interaction pattern).
• Output to the shell can be pretty inconsistent with the real shell.
  • Error messages returned to the user from input evaluation is bad.
• There is no integration testing.

Optimization

The application has yet to be optimized for performance. Below are some potential improvements:

• Fixed by #317 - Returning a subset of results to clients - Rather than returning all the results to the client (which can be of any size), return a subset up to some max size and have the client keep track of which items the user has or has not seen
  • Cursor caching - If returning a subset, the same query will need to be made multiple times to the server, starting at different locations. As such, it may be beneficial to cache the cursor used for the initial query for a short time (and just requery the database if the cursor is not available)
• Reduce request count by rewriting excessive JavaScript queries (i.e. for (var i = 0; i < 100; i++) { db.c.insert({key: i}); } => db.c.insert([{key: 0}, {key: 1}, ...]);