AngularJS all the way? about samson HOT 24 CLOSED

I agree with the page-by-page approach. I think there is some question of how much load we'd add by having a bunch of live pages, but it would definitely be a much nicer UI experience.

from samson.

+1 We've used https://github.com/websocket-rails/websocket-rails with AngularJS successfully to keep data flowing smoothly between backend and frontend

from samson.

Let's do it!

from samson.

Hi @pitr, I saw your name in the core team member list of https://github.com/websocket-rails/websocket-rails, just wondering, should I be worried about the last update of this project was back in June?

from samson.

I did contribute some patches last year, but frankly haven't followed development of the project for some time. We use a year old version of it in production.

from samson.

@pitr thanks for the quick reply. Can we rely on you to merge PRs if we submit bug fixes?

from samson.

absolutely

from samson.

Cool! Thanks!

from samson.

+1, lets make things consistent and with a better UX

On Thu, Oct 30, 2014 at 12:22 AM, Po Chen [email protected] wrote:

Cool! Thanks!

—
Reply to this email directly or view it on GitHub
#177 (comment).

from samson.

Can I also suggest github.com/zendesk/radar as an option for doing realtime updates.

from samson.

I did think of that before when I was trying to get push notifications for deployment events. But I'm wondering would it be too onerous for non-zendesk users to have to setup Redis and the Radar project as part of Samson configuration?

from samson.

@zendesk-shender agreed. Also, integrating websockets with Angular is something new, if someone has done that with websocket-rails before, I say it's a better choice to go for.

from samson.

Feel free to use the right tool for the problem. But please not remain
under misconceptions. Radar is also open sourced by zendesk, and uses
engine.io which is the backend of socket.io. It is widely used in zendesk,
and has worked fine for a long time.

I don't think it is too onerous to setup redis or radar, considering how
widely both are used at zendesk. There is a lot of in company expertise
available for deploying and maintaining radar. That said, may the best tool
for the task win. I rest my case.

from samson.

I think we should give it a try and see how painful it is. As Vanchi says,
we want to use the right tool and doesn't make sense to push just because
we have it. But if it ends up we start fixing same problems that Radar has
already solved, then it is better we use Radar.

On Mon, Nov 3, 2014 at 8:13 AM, Vanchi Koduvayur [email protected]
wrote:

Feel free to use the right tool for the problem. But please not remain
under misconceptions. Radar is also open sourced by zendesk, and uses
engine.io which is the backend of socket.io. It is widely used in zendesk,
and has worked fine for a long time.

I don't think it is too onerous to setup redis or radar, considering how
widely both are used at zendesk. There is a lot of in company expertise
available for deploying and maintaining radar. That said, may the best tool
for the task win. I rest my case.

—
Reply to this email directly or view it on GitHub
#177 (comment).

from samson.

I think most pages do not need to be live / fancy and our feature velocity will be higher when doing simpl-stupid html instead of live angular/ember/xyz. Most the js I saw was just plain old js and the only really fancy thing we do is the progress display.

from samson.

@grosser
Aye, but more and more feature requests are requiring JS:

• Updating current-deploys badge on menu bar
• Allowing user to hide/show deploy-group selection on stage-edit page to override.
• Environment Dashboard auto-refresh
• Pipeline progression UI updates
• ....

I think we've done a lot with the current backend HTML rendering, but to make this app shiney and responsive, I think it'll require a clientside JS framework and Radar integration.

from samson.

@zendesk-shender Radar should be available now.

from samson.

We are waiting behind a carson deploy to get all internal references out of
radar_client_rb. Should be available very soon.. :)

On Tue, Mar 10, 2015 at 9:04 AM, Praveen Swadi [email protected]
wrote:

@zendesk-shender https://github.com/zendesk-shender Radar should be
available now.

—
Reply to this email directly or view it on GitHub
#177 (comment).

from samson.

Thanks @vanchi-zendesk

from samson.

For shiny feature we should use it, but what I want to avoid is making it
harder to add simple features.
Maybe some middle ground could be making static/simple things work
transparently,
but not sure if we realyy have to convert every last page or can just make
the fancy pages dynamic and the static pages static.

On Tue, Mar 10, 2015 at 8:16 AM, Shane Hender [email protected]
wrote:

@grosser https://github.com/grosser
Aye, but more and more feature requests are requiring JS:

• Updating current-deploys badge on menu bar
• Allowing user to hide/show deploy-group selection on stage-edit page
  to override.
• Environment Dashboard auto-refresh
• Pipeline progression UI updates
• ....

I think we've done a lot with the current backend HTML rendering, but to
make this app shiney and responsive, I think it'll require a clientside JS
framework and Radar integration.

—
Reply to this email directly or view it on GitHub
#177 (comment).

from samson.

In terms of code maintenance, it might start getting ugly if some of the
pages are stored as templates for clientside JS, while the rest is stored
as rails templates.

And the 2 main reasons I brought this up originally were:

• Of the clientside JS, it's diverging already into
  jquery/non-jquery/angular section, so settling on a single JS framework
  would help regardless.
• There was a requirement to have dynamically changing UI elements that are
  currently defined in the rails layout template, so if we change this to
  angular, then maybe it calls for a more global change?

On Tue, Mar 10, 2015 at 4:20 PM, Michael Grosser [email protected]
wrote:

For shiny feature we should use it, but what I want to avoid is making it
harder to add simple features.
Maybe some middle ground could be making static/simple things work
transparently,
but not sure if we realyy have to convert every last page or can just make
the fancy pages dynamic and the static pages static.

On Tue, Mar 10, 2015 at 8:16 AM, Shane Hender [email protected]
wrote:

@grosser https://github.com/grosser
Aye, but more and more feature requests are requiring JS:

• Updating current-deploys badge on menu bar
• Allowing user to hide/show deploy-group selection on stage-edit page
  to override.
• Environment Dashboard auto-refresh
• Pipeline progression UI updates
• ....

I think we've done a lot with the current backend HTML rendering, but to
make this app shiney and responsive, I think it'll require a clientside
JS
framework and Radar integration.

—
Reply to this email directly or view it on GitHub
#177 (comment).

—
Reply to this email directly or view it on GitHub
#177 (comment).

from samson.

Maybe the dynamic element in the layout can be implemented using jquery ?
Basically I'd prefer a static app with sprinkles of js over a full blown js
app.
But once it's no longer sprinkles but half the pages switching all the way
is certainly easier,
I just don't think we have reached this point yet and hopefully don't need
to reach it / don't need to make everything super shiny-realtimy.
For example refreshing a dashboard every 60s would be a far simpler
approach then building it with realtime support + makes debugging easier +
does not need another service + means we never have stale data because xyz
bug happened etc.

On Tue, Mar 10, 2015 at 9:34 AM, Shane Hender [email protected]
wrote:

In terms of code maintenance, it might start getting ugly if some of the
pages are stored as templates for clientside JS, while the rest is stored
as rails templates.

And the 2 main reasons I brought this up originally were:

• Of the clientside JS, it's diverging already into
  jquery/non-jquery/angular section, so settling on a single JS framework
  would help regardless.
• There was a requirement to have dynamically changing UI elements that are
  currently defined in the rails layout template, so if we change this to
  angular, then maybe it calls for a more global change?

On Tue, Mar 10, 2015 at 4:20 PM, Michael Grosser <[email protected]

wrote:

For shiny feature we should use it, but what I want to avoid is making it
harder to add simple features.
Maybe some middle ground could be making static/simple things work
transparently,
but not sure if we realyy have to convert every last page or can just
make
the fancy pages dynamic and the static pages static.

On Tue, Mar 10, 2015 at 8:16 AM, Shane Hender [email protected]
wrote:

@grosser https://github.com/grosser
Aye, but more and more feature requests are requiring JS:

• Updating current-deploys badge on menu bar
• Allowing user to hide/show deploy-group selection on stage-edit page
  to override.
• Environment Dashboard auto-refresh
• Pipeline progression UI updates
• ....

I think we've done a lot with the current backend HTML rendering, but
to
make this app shiney and responsive, I think it'll require a clientside
JS
framework and Radar integration.

—
Reply to this email directly or view it on GitHub
#177 (comment).

—
Reply to this email directly or view it on GitHub
#177 (comment).

—
Reply to this email directly or view it on GitHub
#177 (comment).

from samson.

I agree with moving towards a standard JS framework. The long term goal should be to have a full blown single js app running. But I also think that moving everything in one go is just too much work.
We will need to do some work regarding a real API if we decide to go that way (which I think we should).

Plain html pages without any JS behaviour should be trivial to migrate and we should not be worrying about those too much for now.

For anything new/refactored that uses JS behaviour, we should try to isolate them into a component and make them an angular directive, so that in the future the migration of that page, continues to be trivial.

Also, moving these components to an angular directive will make them easier to test (much easier than just JQuery).

from samson.

Closing this, as angularjs is starting to propogate through the pages organically anyway, so progress is being made.

from samson.