nathandao / ginatra Goto Github PK

Currently, commits are stored and read from files. Support for using Redis as data store as an option can boost up performance especially when there are many repositories.

What I have in mind at the moment:

• Add "redis" option in config.yml, which takes the redis database url.
• If "redis" is defined and valid, use redis data store instead of file storage.
• How commits are stored in redis is still debatable :)?
• The 2 functions that are handling writing and retrieving commits data are Ginatra::Repository.get_commits and Ginatra::Repository.create_commits_data

As the use for our front-end dashboard varies depending on designs, layouts and requirements, it'll be useful to separate front-end completely and provide an optional demo or boilerplate front-end (most likely a ReactJs app) as an option through rack task. Something like rack ginatra:demo_app

Restructure Ginatra code base so it cae be bundled as a ruby Gem.

This way, getting a Ginatra dashboard up and running can be as easy as:

gem install ginatra
ginatra install demo_app
cd demo_app & bundle install
bundle exec rackup

Need documentation for all the Web API.

In most cases, the get parameters can be in, by, from, till, and also "limi" once the limit parameter (mentioned in issue #8) is implemented.

So we know it's cool :)

The client-side application could be separated into a repository of its own, e.g. ginatra-client.

Should the existing application be transferred, or should we start with a clean slate? What say you, @nathandao ?

In order to do this, we'll need to add an additional "limit" params to the api.

• From my first iperssion, since the web API passes all params through to Ginatra::Repository, we'll only need to add the "limit" param option there.
• Once the web API is available, add an additional row to the RepoInfo react component to pull the latest commit message (possibly with author name as well?)