All Projects → IBM-Cloud → Todo Apps

IBM-Cloud / Todo Apps

Licence: apache-2.0
Sample ToDo application (various languages) running on IBM Cloud

Programming Languages

python
139335 projects - #7 most used programming language
java
68154 projects - #9 most used programming language
swift
15916 projects

Projects that are alternatives of or similar to Todo Apps

Nodejs Mean Stack
Solution tutorial: Modern Web Application using MEAN stack on IBM Cloud
Stars: ✭ 37 (-81.03%)
Mutual labels:  cloud-foundry, bluemix, mongodb
swift-buildpack
IBM Cloud buildpack for Swift
Stars: ✭ 33 (-83.08%)
Mutual labels:  cloud-foundry, bluemix
bluemix-go
Go library for accessing the Bluemix API
Stars: ✭ 37 (-81.03%)
Mutual labels:  cloud-foundry, bluemix
Tomatoes
Pomodoro Technique® online time tracker
Stars: ✭ 344 (+76.41%)
Mutual labels:  mongodb, rails
Postfacto
Self-hosted retro tool aimed at helping remote teams
Stars: ✭ 224 (+14.87%)
Mutual labels:  cloud-foundry, rails
Zend Diagnostics
Universal set of diagnostic tests for PHP applications.
Stars: ✭ 192 (-1.54%)
Mutual labels:  mongodb, couchdb
Hibernate Ogm
Hibernate OGM - Domain model persistence for NoSQL datastores
Stars: ✭ 299 (+53.33%)
Mutual labels:  mongodb, couchdb
Nosqlmap
Automated NoSQL database enumeration and web application exploitation tool.
Stars: ✭ 1,928 (+888.72%)
Mutual labels:  mongodb, couchdb
Stratify
Rails + MongoDB app for building a consolidated timeline of your data from disparate sources (e.g., Twitter, GitHub, Foursquare, etc.)
Stars: ✭ 97 (-50.26%)
Mutual labels:  mongodb, rails
Nodbi
Document DBI connector for R
Stars: ✭ 56 (-71.28%)
Mutual labels:  mongodb, couchdb
Phpfastcache
A high-performance backend cache system. It is intended for use in speeding up dynamic web applications by alleviating database load. Well implemented, it can drops the database load to almost nothing, yielding faster page load times for users, better resource utilization. It is simple yet powerful.
Stars: ✭ 2,171 (+1013.33%)
Mutual labels:  mongodb, couchdb
Pifpaf
Python fixtures and daemon managing tools for functional testing
Stars: ✭ 161 (-17.44%)
Mutual labels:  mongodb, couchdb
Firecamp
Serverless Platform for the stateful services
Stars: ✭ 194 (-0.51%)
Mutual labels:  mongodb, couchdb
Grails Data Mapping
GORM - Groovy Object Mapping
Stars: ✭ 194 (-0.51%)
Mutual labels:  mongodb
Carrierwave Aliyun
阿里云 OSS Ruby 上传组件,基于 Carrierwave
Stars: ✭ 192 (-1.54%)
Mutual labels:  rails
Obevo
Obevo is a database deployment tool that handles enterprise scale schemas and complexity
Stars: ✭ 192 (-1.54%)
Mutual labels:  mongodb
Mongodb Adapter
MongoDB adapter for Casbin
Stars: ✭ 194 (-0.51%)
Mutual labels:  mongodb
Couchdb Docker
Semi-official Apache CouchDB Docker images
Stars: ✭ 194 (-0.51%)
Mutual labels:  couchdb
Action Cable Testing
Action Cable testing utils
Stars: ✭ 192 (-1.54%)
Mutual labels:  rails
Mongoose
Mongoose module for Nest framework (node.js) 🍸
Stars: ✭ 191 (-2.05%)
Mutual labels:  mongodb

about

The ToDo sample apps are meant to be simple demos of how you can take advantage of Bluemix and a database service. In addition it shows how to take advantage of both the built-in and community buildpacks to deploy your app using whatever runtime you choose.

The ToDo app is pretty simple, it allows you to add an persist ToDos that you need to get done. As you complete different ToDos you can mark them done and eventually delete them from the list. The ToDos are stored in a database.

All implementations support two different database backends, Mongo DB and Couch DB via Cloudant. If you want to use Cloudant see the section of this README titled "Couch DB and Cloudant".

background

The front-end UI for the ToDo app uses a slightly modified version of the Backbone sample from TodoMVC.com. The main change was to change the collections/todo.js file to not use localStorage, but to instead set the url to apis/todos, so that the ToDos are retrieved from the server instead of from localStorage.

The original collections/todo.js file is here.

There are various implementation for the back-end of the ToDo app. We have implemented the back-end currently in Java, Node.js, Sinatra, Python, and PHP. If you want to contribute a backend in another language we enchourage you to do. See the "adding new implementations" section.

All of the implementations are similar; they serve up the files in the frontend directory as static web resources - html, css, js files. And they also expose an api at the uri api/todos to query and modify the ToDos.

Note that this isn't really a realistic ToDo app, at present, since it maintains a global list of Todos that the entire world shares. The intent is just to show using an existing simple front-end application with a simple database back-end. A real example would probably include user authentication, storing ToDo's on a per-user basis, etc.

getting the code

To get the code you can just clone the repo.

git clone [email protected]:IBM-Bluemix/todo-apps.git

The repository contains a directory for each implementation, and the frontend directory contains the web resources that are used by each implementation.

running the samples

To run the samples on Bluemix you must have signed up for Bluemix and have installed the Cloud Foundry command line tool. To sign up for Bluemix head to bluemix.net and register.

You can download the Cloud Foundry command line tool by following the steps in the README file.

After you have installed the Cloud Foundry command line tool you need to point it at Bluemix so it knows where to deploy the applications. You can do this by running

cf login -a https://api.ng.bluemix.net

This will prompt you to login with your Bluemix user ID and password which is the same as your IBM ID and password. You should only need to do this once, the command line tool will remember this information.

Most of the projects use build technologies that are specific to the runtime the ToDo app is written in to deploy the app to Bluemix (Maven, Rake, Paver, etc). The assumption is that these are tools developers who are using these runtimes are familiar with.
Under the covers they are using the Cloud Foundry command line to deploy the apps.
The benefit is that you don't need to remember verbose commands (in most cases) and continue to use tools you are comfortable with. See the individual runtime folders (java, node, php, python, sinatra) for more details on how to deploy the various versions.

adding new implementations

Feel free to expand upon this project by adding new implementations in your favorite runtime or framework. Below is a simple specification you should keep in mind when adding new implementations.

REST Endpoints

  • The server implementation should support GET, POST, PUT, and DELETE.

GET Request - Gets all ToDos

GET /api/todos

GET Response The response should be a JSON array of all ToDos.

[{"completed":false,"id":"001fbbe7bd708a34624b47526cd6ac89","order":1,"title":"test"},{"completed":false,"id":"4d6153cf4bc3bdaf9c6c7eebf42d67a6","order":2,"title":"1"},{"completed":false,"id":"be3855e004dd5d74c802992c09ea8d28","order":3,"title":"2"},{"completed":false,"id":"e7cb7149098961e5dc182715f1cb0e9d","order":4,"title":"3"},{"completed":false,"id":"9368ccc4629a1c8dfd99a9e741d01c44","order":5,"title":"4"},{"completed":false,"id":"e5752d462b83f13da3d8dced1c15eb43","order":6,"title":"5"}]

POST Request - Creates a new ToDo

POST /api/todos/

POST Body

{"title":"another","order":7,"completed":false}

POST Response The response should be a JSON representation of a ToDo with the id field populated.

{"completed":false,"id":"f76424cc41f1ee8c2682a37069098794","order":7,"title":"another"}

PUT Request - Updates a ToDo

PUT /api/todos/[id]

PUT Body

{"completed":true,"id":"4d6153cf4bc3bdaf9c6c7eebf42d67a6","order":2,"title":"1"}

PUT Response The response should be a JSON representation of the updated ToDo.

{"completed":true,"id":"4d6153cf4bc3bdaf9c6c7eebf42d67a6","order":2,"title":"1"}

DELETE Request - Deletes a ToDo

DELETE /api/todos/[id]

DELETE Response The response should be a 204.

Mongo

  • The Mongo implementation should use a collection called "todos".
  • You should create a Mongo DB service with the name "todo-mongo-db" or "todo-compose-mongo-db", depending on which Mongo provider you choose.

Setting Up a Mongo DB server Locally

It will most likely be useful to have a local Mongo DB server for testing when adding new implementations.

See the Mongo DB install instructions for your platform to install a local Mongo DB server.

Couch DB / Cloudant

  • You should create a Cloudant service with the name "todo-couch-db".

  • The name of the Couch DB / Cloudant database to use is "bluemix-todo".

View

The application code should create a view document, if one doesn't already exist, in the bluemix-todo database with the following JSON.

{
  views: {
    allTodos: {
      reduce: "_count",
      map: "function(doc){if(doc.title && doc.completed != null){emit(doc.order,{title: doc.title,completed: doc.completed})}}"
    }
  }
}

Setting Up CouchDB Server Locally

It will most likely be useful to have a local Couch DB server for testing when adding new implementations.

Relax, this is very easy!

Head over to the official home of CouchDB - http://couchdb.apache.org/ - and click the red "DOWNLOAD" link. Follow the instructions to download a verison of CouchDB for your platform.

When running the Mac version of CouchDB, you'll have a menu bar tool-button you can use to start and manage the database.

The implementations will run locally as long as the CouchDB server is running. By default the Couch DB will be running at http://127.0.0.1:5984.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].