• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Todos 06-Building the Backend

Page history last edited by Richard Hightower 13 years, 7 months ago

The UI is looking pretty good.  Now let's get a server going for the app to communicate with.  

 

SproutCore applications are usually fairly independent of their backend server.  In fact, most larger teams will often split into two groups, with one group working on the backend server and the other group working on the SproutCore app.  Given how far we've gone in this tutorial without needing a server to talk to, you can imagine that groups that split like this can often wait until fairly late in their development cycle to really get the two pieces working together.  

 

This is one of the biggest benefits of using the "client-server" model of web development made possible by SproutCore.  It allows your team to move and double pace without interfering with one another.

 

 

Backend Requirements

 

The backend server needs to support a few basic operations. We will design this service following REST principles, so the basic URLs will be as follows (note that actual URLs used by a particular technology may vary, but the essential purpose will be the same:

 

  1. GET /tasks – This request should return all of the tasks defined for the current user.
  2. GET taskURL – Returns the task for a specific URL.
  3. POST /tasks – This request will create a new task, assigning it a unique guid. It should return a 201 with a Location header for the new record.
  4. PUT taskURL – This request will update the state of a specified task
  5. DELETE taskURL – This request will delete the specified task

 

For our design, each task’s GUID will be the URL that it actually belongs to.

 

Each request above accepts and posts JSON as its primary payload. You can easily design services that accept and return multiple formats, but the fastest most convenient format is JSON . You can generally design a SproutCore application to work with any backend format that you like.

 

Here are the JSON formats we'll adopt for our server:

 

Each record is formatted as a simple data hash like so:

 

  "guid": "/task/123",   

  "description": "Task description"   

  "isDone": true | false 

 

For requests that involve a single resource, you could simply pass this data hash, but this would not allow you to pass other meta-data about the resource that might be useful for debugging or other purposes. Instead, data hashes are usually passed as a content property. Here is the example format when you retrieve the data for a single task:

 

{   

  "content": {       

    "guid": "/task/123",     

    "description": "Task description",     

    "order": 1,     

    "isDone": false  

  } 

}

 

For the index request (that returns all of the tasks), the content property is simply an array of data hashes:

 

{   

  content: [      

    { 

      "guid": "/task/123",       

      "description": "Task description",       

      "order": 1,       

      "isDone": false 

    },      

    { 

      "guid": "/task/345",       

      "description": "Task description",       

      "order": 2,       

      "isDone": false 

    }    

  ] 

}

 

Choose Your Own Adventure!

 

SproutCore is backend agnostic. It can work with any backend server technology that you want to use. In fact, once it is deployed, SproutCore apps contain only standard HTML, JavaScript and CSS.  You could deploy an entire app using nothing but Apache.

 

At this point in the tutorial, we are going to play “choose your own adventure”. Depending on the backend technology you want to use you can choose any tutorial listed below. If a tutorial for your favorite server technology is not listed here, consider following another tutorial and then writing a version for your favorite technology and adding it here.

 

NOTE: If you want to proceed with the SproutCore tutorial without writing your own backend server, then we kindly invite you to use ours instead!  Just open the "Buildfile" in your todos project and add the following line to enable the built-in proxy:

 

proxy '/tasks', :to => 'todos.demo.sproutcore.com'

 

Then restart the sc-server so the proxy becomes active. This will proxy all requests from your local development server beginning with "/tasks" to the shared server running at http://todos.demo.sproutcore.com.  Note that because this is shared, you might find the data set changes frequently due to other developers working.  If you want to avoid this, follow one of the instructions below to set up your own server instead.

 

We’re going to start with Sinatra, because it is simple to use.  Choose from any other backend that you like from the list below.

 

 

FOR CONTRIBUTORS: If you write a tutorial for your favorite tech here, first of all, thank you! Second, please name the starting page “Todos 06-Building with X” where X is your technology, link to it just like the Merb example above, and insert your link so the tutorial list appears in alphabetical order. Thanks!

 

Once you built your server, you can move on to Step 7 to add a data source to your app.

 

Continue to next step: Step 7: Hooking Up to the Backend »

 

Comments (5)

Dirk Neumann said

at 8:34 am on Dec 9, 2009

Hi,
"proxy '/tasks', :to => 'todos.demo.sproutcore.com'" doesn't work, nothing happens, no output on the console. When I write "proxy '/', :to..." every request is sent to sproutcore.com. Can I debug it somehow?

Thanks

Charles Jolley said

at 9:22 am on Dec 9, 2009

proxy /tasks, :to => 'todos.demo.sproutcore.com' definitely works.

You can verify that todos.demo.sproutcore.com is up and running by visiting http://todos.demo.sproutcore.com in your browser. You should get a JSON document. Also if you look on your console where you are running sc-server, then when you try to visit:

http://localhost:4020/tasks

you should see something logged there telling you that the proxy is forwarding.

If you get a JSON document when you visit the above localhost URL, then something is wrong with your SproutCore app.

Dirk Neumann said

at 9:55 am on Dec 9, 2009

Hi Charles, thanks for your quick answer, but I must apologize for my blindness. If I had used my brain, I would have followed step 7 of the tutorial before trying to fetch records from the server.
Thanks again

Sanket said

at 11:03 am on Jan 11, 2010

proxy /tasks, :to => 'todos.demo.sproutcore.com' gives following error in server console.

Errno::ECONNREFUSED: Connection refused - connect(2)
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/net/http.rb:560:in `initialize'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/net/http.rb:560:in `open'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/net/http.rb:560:in `connect'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/timeout.rb:53:in `timeout'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/timeout.rb:93:in `timeout'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/net/http.rb:560:in `connect'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/net/http.rb:553:in `do_start'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/net/http.rb:542:in `start'

Is this some kind of proxy issue. As I was trying from within the a proxy.
I am able to open http://todos.demo.sproutcore.com directly within the browser.

Nalin Sharma said

at 12:32 pm on Dec 16, 2010

You can build the back end with WebObjects, so its apple all the way

here is the link: http://wiki.objectstyle.org/confluence/display/WONDER/SproutCore+and+ERRest

I am testing this out and hope to report back.

You don't have permission to comment on this page.