Derby with a RESTful API

Question

I'm very intrigued by derby and spent last night reading through the documentation. My current architectural thoughts are very much geared towards building a RESTful API which is used by the corresponding rich client application, or by anybody else with access to the API.

Derby impresses me not just because of its focus on speed, but because it works very much like the web is supposed to (with URLs matching pages). However with the move these days to have a mobile application that fits into a product, it seems that having an API necessary if one wants to develop both for the mobile and the browser sphere.

My question is twofold.

1. Could derby be used to interface with an API, essentially writing an API adapter and swap that out with the mongoadapter. I haven't looked at the adapter but the docs insinuate that writing an adapter isn't too difficult. Alternatively could derby produce a json response to the API call if the accepts header asks for json. That way it could play the role as an API along with serving the webapp.

2. Should derby be seen as an application as whole and not used at all for any other apps (ie mobile). Ie the common factor between a browser and mobile app will be the database, not the API. The downside to not having the API as a common factor would be that features might not be consistent across apps (not as in amount of features, but one might be buggy the other one not).

I'd very much like to use derby in our next project, but need some clarity whether it is the tool for the job. (Incidentally the project will be a big web application, but needs to have mobile integration. Having an API might also be a great idea but i'm not sure yet of its usefulness)

Answer 1

1. I think you can write adapter for derby to communicate with your api-app (where the data actually stored), but this adapter will have predefined methods and will not reflect your api. So business logic probably will be duplicated (derby app and api app) and you will not gain a lot from this solution.

2. I would recommend to use derby as api-app. From version 0.6 (that is coming soon) you can use client-side derby app without server-side, that means you can use it in phonegap for example. Also derby has built-in client synchronization with conflict resolution based on share.js. You can use it for web and phonegap apps "of the box", but for native mobile apps you should write share.js clients to use it. Also there is built-in rest api in share.js or you can easily implement your api based on express routes. So derby is perfect for api, web, phonegap apps and good for mobile apps.