search

VeteransOnWatch / veterans-on-watch-server

MIT License
0 stars 0 forks source link

1-scaffold-new-rails-server. Scaffold new Rails application. #1

Closed ztbrown closed 10 years ago

ztbrown commented 10 years ago

Using Rails for the server is just a suggestion. I'm interested in hearing feedback from the other developer-owners. @VeteransOnWatch/owners

ztbrown commented 10 years ago

So, I made a mistake on some of these branch names. This branch should be called 1-scaffold-new-rails-server. Our convention should be < issue-name >-< feature-branch-name >.

baroldgene commented 10 years ago

I'm curious about what is the client here v. what is the server.

Also, did you use scaffolding or just rails new?

ztbrown commented 10 years ago

My idea was to do a JSON API on the Rails end and a thick JS client for the front-end (phonegap wrapping an angularjs/ionic mobile app).

ztbrown commented 10 years ago

just did rails new

ztbrown commented 10 years ago

client is over here: https://github.com/VeteransOnWatch/veterans-on-watch-client/pull/1

ztbrown commented 10 years ago

Any final thoughts on Ruby/Rails vs other languages/frameworks?

@BDS1400 @baroldgene @dswingle @lightmedium

dswingle commented 10 years ago

Go for it.

BDS1400 commented 10 years ago

Nope.

baroldgene commented 10 years ago

Nope what?

ztbrown commented 10 years ago

I think he was saying, "No final thoughts". Right @BDS1400?

BDS1400 commented 10 years ago

No final thoughts.

ztbrown commented 10 years ago

ok, I'm going to :ship:

lightmedium commented 10 years ago

Hi everyone, sorry I've missed the party so far! I just got off the phone with someone at Twilio (I'm two blocks from their HQ right now), hoping to get them jazzed about our project. I was talking to the wrong person. Apparently "Business Development" means "Sales" nowadays.

@ztbrown - I'm down with a Rails server. What do you think about Relational vs Document db for this? The most relevant discussion I've seen was all the buzz a while back about the decision to move Diaspora from MongoDB to MySQL, but I'm not 100% convinced that it was a wise move.

https://www.google.com/search?rlz=1C5CHFA_enUS503US503&espv=210&es_sm=91&q=diaspora+mongodb+mysql&spell=1&sa=X&ei=zD5DU5vnNoSfyQH_04DQCw&ved=0CCUQvwUoAA

Regarding the JSON API and thick client... I agree with the structure. Let's keep the API encapsulated so that we can add to our offerings someday with native clients for Android, iOS, Windows, The Rebirth of Blackberry, and the next amazing smart watch from whoever we can't imagine down the road, without having to refactor the server to remove all of the html/css/javascript integrations we unwisely allowed to bleed into it. On that same note, we should put as much business logic as possible on the API for the same reason. Every bit of business logic we write on the client side will have to be duplicated on every platform we adopt, and our ability to expand into new platforms with speed and agility is critical. Our client-side code should, as much as is wise and possible, rely on the service when it comes down to what to do and for whom while the client handles the platform-specific view logic.

I'm sorry for the lecture, but I'm still reeling from my experience at Chase, where we had WAY too much business logic duplicated across the iPhone, iPad, Android, Windows Phone, Blackberry, and Mobile Web apps. We were virtually paralyzed by the complexity of the client-side code and, just like the logic, that paralysis was duplicated across all of our front-ends. Granted, the front end for an enormous bank, that is actually an amalgamation of many banks, that offers just about every consumer and business finance service known to man is an extreme case, but it doesn't make it any less true for this app.