It’s going to be a complete rebuild, across firmware, services, application, web UI, and mobile UI.
The way I planned to get started on the web UI was to get the build process and the entire client stack in place and tested on a minimal feature, and then grow incrementally from there.
The minimal feature could be anything - report the services version (using a mocked service for now), report connected devices etc… Mocked date for a graph, incorporating grafana. Basically get the web client development infrastructure and client stack in place.
Even though we are doing a complete build this will take many months. For more instant gratification, tackling some of the issues in the webapp repo is a good place to start. Just drop a note in the github issue that you’re taking on that issue. Welcome!
been following this project for a while even though I haven’t committed by buying the product yet.
I work as an integration developer in my day job, and have always been doing some sort of web frontend. Typically Java is a part of the project, but Rails was the thing for a long time.
Recently we started doing frontend in js based frameworks and Angular has been quite easy to get going with. Not least because of an abundance of resources.
Let me know once you get started. I’d be interested in helping out.
To add a bit of water to the mill, here’s how I’ve been developing my apps for a few years:
Django + Tastypie as a backend
AngularJS + Restangular for the frontend, using CoffeeScript
My feedback so far is that Django is pretty OK while now a bit too complete when its usage is stripped down to an API provider. Tastypie is loosing attraction in favour of rest-framework. I’ve been also developing new apps using a lighter and faster framework : aiohttp with API_hour (python3, asynchronous). It’s a pretty good combo to run on an embedded board I think. Also, I know mailman3 is using Falcon and they seem happy.
Concerning the frontend, Angular and restangular make the job very easy. Angular2 is about to be released and will break a lot of things. So if you’re going with it, maybe you should wait. React is pretty awesome too but maybe not necessary for this kind of project (there will be not so many updates triggered at the same time).
Anyway, I think the best strategy is to also follow the attention of the communities so it’ll be easier to attract new contributors. Sometimes it’s better to make a choice that favour potential contributions over technical perfection I think.
I woke up this morning with BrewPi and the future REST API in mind, so I had to draw something
Here’s how I see it atm and I was wondering if you had something different in mind.
Also, one question pops from this drawing: should the client make direct queries to the photons when configuring or requesting sensors info or should the raspberry API act as a proxy that then queries the photons?
The brewpi devices themselves won’t be sporting a REST API but rather use a space-efficient (compact code) protocol that talks to a Device Connector, which maintains device state and provides a REST API. We may later open up to a REST API on the Photon or other future devices where there is more program memory.
