Question - And a really dumb one... about api-designer HOT 9 CLOSED

Hi Jem,

First off, thanks for checking out the API Designer and taking the time to ask questions - we're glad to be able to help bootstrap the RAML community.

The default storage layer is actually using the LocalStorage API to mock a file system and persist your content in the browser. If you use developer tools you should be able to look at this directly. I've attached a screenshot from my local build, using chrome developer tools.

We are also thinking about what a good out-of-the-box, more robust persistence layer would be for people running this tool locally - do you have any thoughts? We're trying to make sure people can continue using this without a lot of setup, but it would be great to provide some additional middleware options.

from api-designer.

I was in exactly the same situation for the last hour. Looked through all the code but I am a java guy.. looking for the spring.xml. :) Where does the persistence mechanism get set to local storage?

when I say grunt server and I am in the api-designer directory does the api-designer where that api-designer directory is? If so.. how about a files directory in api-designer that gets populated with saved RAML files?

from api-designer.

Hi,

Thanks for the response.

From an 'enterprise' perspective i (and i do see some contention with http://apihub.com) i assume the following..

• The raml, schema files, and markdown documentation would all be mastered in some SCM such as GIT.
• A developer might want to use their particular tool-of-choice to edit those definitions.
• The run-time and documentation artifacts are being built and published by some CI process.

So that would mean if the desire is to keep any-and-all of the processing logic on the client-side then it would need the ability for the browser to read/export from/to the local file-system.

In an idealistic world i i might open my browser, point the server-side at my GIT repo, let the server clone/fork the repo (assuming GIT), allow me to edit/develop as appropriate, and then have those changes committed on the server-side and subsequently pushed back into GIT along with a PULL request to get the changes back into the mainstream. I think using a fork/pull model might ease some of the permission issues around code repository but does raise interesting issues around change-tracking.

Jem...

from api-designer.

If you are interested in running API-Designer locally and need a network store I have added my raml-store REST API to github at https://github.com/brianmc/raml-store

Also there is a persistence sample which interfaces between the api-designer and this raml-store API: https://github.com/brianmc/raml-store/blob/master/sample-designer.html

I need to add installation instructions and other documentation so I'll do that in the next day or two.

from api-designer.

@JemDay Also was asking myself this question diving into raml... hence it might be good if you could rename the title of this issue so it's easier to spot from the issues list to maybe help others find this discussion quicker.

@comptly First of all, thx so much for creating this - i cannot say how much i'm currently falling in love with the spec, the tools, the process of api design with raml which to a huge amount attributes to this all-in-one yet to-the-point IDE

My two cents / features reg. persistence:

1. knowing this sounds sooo lame and 1980s - first thing i thought of was PostgreSQL...
2. a. Save to Disk
   b. Copy to Clipboard

Guess 2a. and b. are real low-hanging-fruit here, as i guess we'd just need an export proxy script on the node server and get a button for Clippy integrated into the editor

from api-designer.

Just started today experimenting with the API Designer locally, I think that the readme should have a small sidenote explaining where, by default, the files get stored (perhaps in the section where it's explained how to override the default persistance configuration?).

As for persistance options, directly interfacing with svn of git would mean that the API Console would have to somehow deal with conflicts from updates/pulls or commits/pushes.

Nevertheless having the ability to specify a remote svn or git folder and have each save be a commit (svn) or commit+push (git), and each application refresh an update/pull (limited to the specified folder) would be very cool indeed.

from api-designer.

Hi! Since this is more like a discussion as a real issue, could we move it to http://forums.raml.org/ and close this one? cc/ @usarid

from api-designer.

Anyone else has some opinion on that. What about letting people decide where they want to store there files. We could implement some hooks to enable people develop their own "repository" and add that to our API Designer. Then you can configure the API Designer to use a specific "repository". There are many implementation out there which we can merge to that like @brianmc or the local filesystem one I have also seen somewhere on github.

My guess is this would also solve the version control issue as if you use a filesystem repository "plugin/adapter/hook", you can just reuse the tools you already have for git or svn or whatever. It doesn't need to be integrated into the designer. I think that is a lot of overhead and therefore not necessary.

What are your thoughts? @alejandroschenzle @usarid @dmartinezg

It should be the browser cache for the MuleSoft hosted version by default, btw.

from api-designer.

related to #199

from api-designer.