The approach used by Samplestack and some other applications is to have a Node.js middle layer running on the same server. Node hosts the HTML, JS, and CSS, and passes requests along to MarkLogic. Having Node (or something) in between your end user and MarkLogic also allows you to controll access to the REST API in a pretty granular way. You can probably set up Apache the same way, passing requests to /v1/* or /v2/* to MarkLogic.
-- Dave Cassel<http://davidcassel.net>, @dmcassel<https://twitter.com/dmcassel> Developer Community Manager MarkLogic Corporation<http://www.marklogic.com/> MarkLogic World Tour: Washington, Amsterdam, London, Boston, Tokyo, Chicago, Houston, New York<http://world.marklogic.com/locations/> From: Shannon <[email protected]<mailto:[email protected]>> Reply-To: MarkLogic Developer Discussion <[email protected]<mailto:[email protected]>> Date: Monday, May 4, 2015 at 3:53 PM To: General MarkLogic Developer Discussion <[email protected]<mailto:[email protected]>> Subject: Re: [MarkLogic Dev General] Moving REST API Instance module code to a directory in Modules database Hi Erik, No problem, it was a great workshop. Thanks for the information. In that case, I don’t know if it’s worthwhile to submit an RFE to put code on the file system instead of a modules database for an HTTP app server with the RESTful interface. My only concern is the extra time it takes to save edits, 1-2 seconds via WebDAV (mounted as a volume in OS X) vs. virtually instantaneously with Sublime Text locally. Alternative ways to keep the code on the file system would be to use standalone Apache and modify the HTTPD config file to allow for cross-domain requests. Or perhaps use JSONP requests in Angular—is that the only workaround for the security if I were to use a MarkLogic HTTP app server? In that case, would it actually be a 3-tier architecture even though the app and database servers are both on the same MarkLogic instance? Thank you very much in advance for your time. Best, Shannon On May 3, 2015, at 11:07 AM, Erik Hennum <[email protected]<mailto:[email protected]>> wrote: Hi, Shannon: When a resource service or transform extension is installed, the REST API generates some declarations and wrappers. So, no, at present neither the file system nor WebDav would work for such extensions. For libraries installed as /v1/ext/YOUR_PATH/YOUR_MODULE.js or xqy, it _might_ work to put the same resources in $MARKLOGIC_INSTALL_DIR/Modules/v1/ext/YOUR_PATH/YOUR_MODULE.js, but that's a hack I've not tried. Even if that hack happens to work now, you wouldn't want to build up any infrastructure around it because it could stop working in the future. Erik Hennum PS It was a great to meet in person, and thanks for toughing it out through the logistical hiccups. ________________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Shannon [[email protected]<mailto:[email protected]>] Sent: Friday, May 01, 2015 3:18 PM To: General MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] Moving REST API Instance module code to a directory in Modules database Hi Erik, is there any reason why the code can’t reside on the file system as opposed to a modules database? I tried this to no avail. When developing locally, I’m able to save edits to files a lot faster on the file system than over a WebDAV server. Just half a second to a second, but that adds up. For one AngularJS app, I started with a plain vanilla HTTP server, and then when I was ready to work with $resource, I setup a REST server on another port. I thought I’d be able to develop the app on the file system on the HTTP server, but of course I ran into cross-domain JS security, being on two different ports (using a 2-tier architecture). So I conflated the servers, but that meant moving the code to a modules database. BTW, thanks again for all your help in the workshop :-) Best, Shannon Hi, Danny: The REST API doesn't support sharing modules databases between REST servers or providing an interface for renaming managed resources in the modules database. There could be a number of issues (for instance, permissions on the options file), but working through the issues on an unsupported operation would be guesswork. Part of the rationale for the one-to-one relation between modules databases and REST servers was to make it easy to package up a REST implementation on a development environment and push it to a production server. Can you expand on the issues you're running into with that one-to-one approach? Thanks, Erik Hennum ________________________________ From: general-bounces at developer.marklogic.com [general-bounces at developer.marklogic.com] on behalf of Danny Sinang [d.sinang at gmail.com ] Sent: Wednesday, April 29, 2015 8:12 AM To: general Subject: [MarkLogic Dev General] Moving REST API Instance module code to a directory in Modules database We have a REST API instance running on port 9042 on our DEV cluster and it works fine. When this instance was created, a new modules databases called 9042_imagechallenge-rest-modules was created for it by ML. I'm trying to avoid minimize the number of modules databases we have, so I : 1. Copied the code from 9042_imagechallenge-rest-modules to a new directory called "/imagechallenge_rest" in our Modules database. 2. Reconfigured our 9042-imagechallenge-rest app service to use /imagechallenge_rest as its root and Modules as its modules database. After step 2, I visited : http://marklogic-dev.mycompany.com:9042/v1/search?q=published:true&options=image_challenge and now I'm getting this error : <error-response xmlns=" http://marklogic.com/xdmp/error"; <status-code>400</status-code> <status>Bad Request</status> <message-code>REST-INVALIDPARAM</message-code> <message>REST-INVALIDPARAM: (err:FOER0000) Invalid parameter: No configured options: image_challenge</message> </error-response> I checked the /imagechallenge_rest directory and this "missing" option file is indeed under : /imagechallenge_rest/Default/9042-imagechallenge-rest/rest-api/options . What could I be missing ? Regards, Danny _______________________________________________ General mailing list [email protected]<mailto:[email protected]> Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected]<mailto:[email protected]> Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected]<mailto:[email protected]> Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
