hgwood / falcorception Goto Github PK

The current design eats a lot of vertical space and that's good for wide screens (the main target). Proposal: contextual stuff (title, properties, metrics) in a left-hand corner; main content takes the rest.

:)

Those vars should be usable to query the source.

• Create route
• Set pattern
• Choose source
• Configure query

flatly.css is checked in the repo. It would be better to either get it via npm (npm i -S thomaspark/bootswatch or npm i -S jozefizso/bower-bootswatch-flatly) or use a CDN.

Use browserify with watchify (or something equivalent) to build the app bundle in order to:

• get rid of the module = {} hack in index.html
• eliminate the need to insert more and more files into index.html

Users can only see their own APIs.

Both first and last API of the list are the same one (the new one I think).

See https://github.com/koajs/koa.

Would it be possible to import a swagger or raml to start an API ?

• Firebase (#22)
• Rest (#17)

It would be great to support some syntaxic mechanism in parameters fields.

For instance, we need to set args field something like ["arg1", "arg2"].
It wourld be far greater if we could set this field like arg1,arg2

We now have a good idea of how components are written in this app. There are 2 types: the ones that are invoked from a template, and those that are invoked from a route, with Falcor resolvers. Functions should be written to take care of the boilerplate for each of those type.

The 4-input Falcor client can be confusing. Use tabs to separate get, set, multi-set, call.

• Third party libs pulled from CDN
• Minification of browserify bundle
• ...

Related to #20.

This will allow for cloud deployment. Firebase could be a good choice.

As of yet there is only one text box and it is require to enter a string that resolves to all the desired paths. It could be easier for the user to enter paths using several strings.

All modules are imported in index.js. It would be cleaner that each module import the modules it needs.

That's because the model is created in the API page controller. It should persist in a service.

Preferably using jwt and a cloud service (auth0?).

For example :

• matcher: movies[{keys:titles}]
• query should be rendered with each title that is requested

If you come back to the API page, the route list does not include the new route.

To rename APIs, routes, sources.

The ng1 router does not allow to get a promise from a route change to display a loading indicator while the router is resolving the data required by the target route. ui-router does with $state.go.

Add a link

Even non configurable ones. Just a simple API with fake values.

Those relative requires are annoying (require("../../...")). We need a node_modules folder to avoid them.

New proposed folder structure:

• move filters and services to components folder (components/falcorService.js, components/healthFilter.js, ...)
• move components to a new src folder
• rename components into node_modules
• update all requires

For now, status should always be "Running" as all APIs are gonna be run all the time, but it's important for the user to know that the API is up. One way to make sure the API is actually running (instead of Falcorception "thinking" it's running) is to make this status part of the running API, instead of the Falcorception API.

Requires #21.

• What is Falcorception?
• How does it work?
• How to start it?
• How to contribute?

As of now, the Falcorception API is usable from the Falcorception app but is still is a "special" API, as it is not handled like other hosted APIs. It could be interesting to express the Falcorception API in Falcorception terms.

Related to #6.

Forked from #29

This is a never ending issue meant to signal contributors that I'm open to any proposal on UI/UX. Submit your idea, big or small!

Have a view that allows to make requests to an API.

Would it be possible for the user to import à JSON Schema to start an API ? All routes to primitive values could be created and then the user could link them to a data source.