Split application into client side & server side

[cpursley]

[enhancement] Just saw the new OpenFarm mockups on kickstarter and wold like to get involved.

The new UI looks fairly sophisticated. I suggest splitting OpenFarm into a client side & server side application - or at minimum, use a js framework instead of rails views. Anyone open to Angularjs?

[RickCarlino]

Hey! It's good to see you again. It's funny- after you contributed to the project a while back, I kept bumping into you on github in comment threads (mostly Dokku related threads if I remember correctly).

We follow the 'heavy frontend' model on the web software that controls FarmBot and it's been OK for us, but I am still on the fence about the benefits about wether we need to go all out like that for an app that is just simple information storage and retrieval.

My main concern is that SEO will be a challenge. Bad SEO means less community involvement. I am aware that Google renders javascript now while indexing, but I imagine its still very early.

On the other side of the spectrum, I do think it would be good for a snappy, responsive user experience. It's been great on the Farmbot Web App. It also makes it easier to integrate with 3rd party services, like mobile apps or FarmBot devices in the wild that need to retrieve plant data.

If we did spilt it out into the backend, what's your preferred build process for the frontend? Particularly, how would you like to do things like:

• Handle user sessions for browser user?
• Handle CORS and the general finickiness of browser security?
• Build the frontend assets and package them to be served by Nginx?

I'm not really sold on one or the other (or that we can only have one or the other). Comments are definitely welcome.

[RickCarlino]

Oh and to answer your question, yes I am open to Angular. It's bordering on a religion for me.

[simonv3]

Hey, just like to contribute - the create guide page is currently powered with some AngularJS, though it's more touch up for a fluid user experience than full application.

I'm for separating the two more, as it'll allow for more flexibility in the long term - we'll have an API that people can tap into, and I see that API being the real power of OpenFarm.

I am interested and have little experience with building a user session around Angular, but I imagine that we can just power the same user session used right now? I've also used a simple technique to work around user sessions in the new guide page.

[cpursley]

@RickCarlino - yeah, did you see that flynn (dokku's big brother) is part of the ycombinator class?

---

Dope, I am just now seeing Angular in the guide pages....

If the OpenFarm is split, here are some potential solutions:

• Several ideas [here](https://medium.com/opinionated-angularjs/techniques
  /techniques-for-authentication-in-angularjs-applications-7bbf0346acec) and libraries like satellizer and devise_token_auth for user sessions
• rack-cors to deal with CORS
• prerender.io and other thoughts on dealing with web crawlers/SEO.
• gulp or brunch + divshot.io for frontend build process.

Perhaps this introduces too much complexity? No matter the direction, I'd like to help out on the UI related stuff. Where can get access to those new mockups and list of development priorities?

[roryaronson]

The most recent mockups are linked in the README here

I think the two highest priorities are:

1. Getting the frontend of the Guide pages up (which has been started)
2. Implementing the new data model to support the Guide pages

[simonv3]

Just to elaborate:

There's an outline of the guide page, and an existing data model that might need extending, but works for most of the parts of the guide that are necessary for, well, being a guide, mainly captured by has_many :stages and has_many :requirements, which are dynamic and simple data objects.

What's missing (and not that hard to implement) is a growing season for a crop to build the timeline.

Other than that, the forums, usage & recipes, etc. I think should be on the backburner.

It might make sense to have a "currently working on" in the readme that people periodically update with what they're working on? That alongside a "what needs work on"?

[roryaronson]

Forums, usage and recipes, etc can definitely be pushed aside until later.

For tracking what's being worked on, we have a waffle.io issue tracker setup. So all things being worked and on the "backlog" should be added there or in the GitHub issue tracker.

For the growing season/timeline, that will be based off of the growing degree days of the crop, and the Guide reader's location and projected weather.

Interesting, the second Google result for "Growing Degree Days" is this handy GDD calculator from weather.com!

[simonv3]

@roryaronson Looks like it isn't possible to move stuff around unless you're a collaborator on the project, is that a setting of waffle.io that can be changed?

[roryaronson]

Hmmm I can't find a setting in there. You have to log into Waffle with your GitHub account to use it. When you go to the link, there is a little person icon on the left sidebar, press it to login. Hopefully that works?

[simonv3]

Yeah, I'm logged in - I think it reflects the collaborator settings of github.

[roryaronson]

Ok, I've invited you as a collaborator with push/pull access. Let me know if that works!

[RickCarlino]

Hey guys- I think at this point we can build the API incrementally and scope it into /api. Right now, you can GET crops and POST guides. It will grow in the future as the need to implement the endpoints arise.

Once features are at a more usable point, I will implement CORs and API docs. I think incremental development of the API will be the best use of our time, but does need to be a priority.

I am going to close this one for now since it's not really a single task but rather a guideline for future development.