Tue 24 Nov 2015 7:52PM

Rails Backend?

RP Rylan Peery Public Seen by 244

Rylan Peery Tue 24 Nov 2015 7:52PM

@elliottjf mentioned porting to Rails for the API / service layer to enable faster development and compatibility w/ the Working World.


Scott Nelson Tue 24 Nov 2015 8:38PM

I tend to agree that Ruby/Rails makes more sense for this type of project. It’s certainly a good option for server-rendered web applications and I think it’s also a great tool for creating synchronous request/response style REST APIs (should Seed evolve into a client-side app). If there’s a need for async (i.e. some sort of server push) then down the road we can always spin up a separate Node service to handle that part.

If you’re rebuilding from scratch I would also suggest sticking with a relational database like Postgres. If you need schemaless storage for something there are plenty of flexible and performant options within Postgres for that (hstore, jsonb).


Ethan Winn Fri 27 Nov 2015 3:04PM

I'll play counterweight for a moment.

If we are moving away from server rendering toward an API tier, is this still the case? I know Joshua has mentioned that plan elsewhere.

My one concern about moving to rails is it will reduce the # of CoLab folks we can contribute, but I don't know if that's a blocker.


Rylan Peery Fri 27 Nov 2015 3:38PM

Could also give us a chance to improve our skills in a second stack per the other dev thread with Scott


fabrice armisen Sat 28 Nov 2015 8:40PM

My understanding was also that we were moving toward client side rendering using something alike react or riot and use the backend to serve an API + provide admin screen. I am currently setting up a new project that uses a very similar layout (react/redux/ES6 on the client, rails for API and admin) and I should have something we can re-use by the end of the week end if we go that route.


Rylan Peery Sat 28 Nov 2015 10:23PM

I think it makes sense both for us to have a rails practice and for the app to go in this direction.


Ethan Winn Sat 28 Nov 2015 10:58PM

I'm not opposed. Especially given the % code contributed by Joseph and Fabrice to date.

Errata: "Joshua" above should have been "Joseph".


Joseph Elliott Sun 29 Nov 2015 7:31PM

I see a need for both client-side and server-side rendering. We're going to have an evolving level of internal admin functionality which I think will be much easier to develop on rails than node, and there will also likely be a growing level of customer facing campaign management screen which are not public facing and don't need the same level responsive UI and could be sufficiently and more easily implemented with rails.

It also looks like there are some decent websocket and other async solutions now available for rails. And I'm also interested in trying out jruby which opens up access to the whole JVM ecosystem, and in particular much better concurrency support than MRI (cruby) offers.
My general sense with node so far is that is has it's benefits, but has a much more narrow 'sweet spot' of projects for which it's the most efficient development environment than rails.
I'd like to see what Fabrice can factor out as a skeleton project with a react client and rails backed api/admin. As far as persistence, I like postgres with hstore as a nice balance of structure, flexibility and performance.


Tomaž Korenika Thu 3 Dec 2015 5:41PM

If the majority of the developers are good in Rails, then i dont oppose it. Curious why the decision to switching to Rails though.

I agree with what Scott said above actually, with another potential useful feature. What we did in Kick And Push is an SDK module, which digests REST APIs and allows us to do server-side rendering along with direct-function calls. This allows us to reuse the APIs directly in code, without writing additional helpers which are not needed.


Joseph Elliott Thu 3 Dec 2015 6:28PM

One of the other motivators for an eventual switch to Rails is anticipated collaborate and shared technology with Sassafras and The Working World project. There is already a strong culture and product synergy between Seed Coop and that project. It is being built out as an open source rails project, leveraging code which Adam built probono a couple of years ago, and now being funded the The Working World. I will also be a key developer on that project and will be looking for ways to nurture this alliance.

When we discussed potential collaboration with the Kick and Push project, the conclusion was that the proprietary code ownership and for-profit equity structure was a barrier and that we needed to keep the code base and development efforts separate.

If there are portions of the Kick and Push code base which can be factored out with a friendly license, then I think that would be great for future CoLab node projects and possibly even useful for the Seed Coop MVP which we still plan on completing over the next few weeks with the current codebase. It certainly would have provided a huge boost if that had been clearly available for the initial development.