Rails API is coming to Rails 5 | Hacker News Reader

Rails API is coming to Rails 5

github.com

126 pointscolinbartlett36 comments

Context: https://rubygems.org/gems/rails-api

This gem was created because this feature was going to be in Rails a few years back, but was pulled out by DHH before release. But, as you can see, he's cool with it now.

Why was it pulled before release?

It's been a very long time, so I don't remember the specifics, to be honest.

IMHO this is nice code, nothing against the devs, but I just don't see why its getting added. As someone who has built lots of rails apis, I don't really see any benefit other than perhaps speeding up bootstrapping. But as is, right now its incredibly easy in rails to require the action-X packages you want and setup middleware how you like it. Maybe I'm missing something though...

There's a lengthy explanation here: https://github.com/rails-api/rails-api#why-use-rails-for-jso...

EDIT: sorry, I mis-read your post. This is just "Why Rails and not Sinatra," not "this is easy enough to do on its own, why bother."

I wasn't directly involved in the decision, so I cant' tell you, to be honest.

this justifies the library's existence but does not justify it's inclusion upstream.

Because Rails has become bloatware and has been since they lost sight of the future of the web and stagnated on innovating...

DHH talks about this in The Changelog #145 (2015-03-06) starting ~01:14:15.

https://thechangelog.com/145/

This is good, DHH basically is talking about making rails (in the future version 5ish) more flexible for all those people building just backend rails apis that are consumed by seperate client frontends, mentions integrating websockets too. So it sounds like this is the first step in that direction.

I don't think you're missing anything, but I think you (as many have before) are forgetting about one of Rails earliest and biggest selling points: curation of best practices for creating specific kinds of applications. While the ease with which skilled practitioners can configure the framework to work well for an API-driven application is a testament to its flexibility, the out-of-the-box conventions have been in need of some love for awhile.

I don't think this is a huge deal, but it will definitely be nice to have official support for this configuration.

This provides some more context: http://wyeworks.com/blog/2015/4/20/rails-api-is-going-to-be-...

I love this. I find that Rails-API sometimes does/needs some screwy stuff because it has to be 2nd class citizen. This promotion of it is great news because it will obviously be kept in sync way better.

Regardless, SPAs are fast becoming the best way to develop and this sort of thing (rather than the bandaid of turbolinks) gives me a lot of hope for the future of rails. I can even see rails eventually replacing views with a presenter layer (though something like that would probably wait for 6).

Reminds me of what someone once said about America: "they always do the right thing, after exhausting all other possibilities".

There is also sinatra, which has had a stable API for years.

Rails has bigger community and they are pioneers for alot of things that each new framework takes inspiration from. Practically i think ruby wasn't going to be this famous without rails. So its cool that Sinatra had it early on, but now we have it in rails.

Not really: https://twitter.com/maccaw/status/576437511729221632

If you want true stability you probably have to switch to a language with a stronger type system. That Sinatra bug proves that even small codebases can suffer from basic type errors.

uh, it appears that a chance to Rack's API caused that bug, no?

Same problem, though. Ruby's dynamic typing comes with some wonderful advantages (yay metaprogramming!) but some pretty bad disadvantages as well.

Definitely. I like things like contracts and optional type annotations very much. Some code is just hard to understand without those kinds of things, which leads to bugs.

Actually a good testing suite fixes that issue. It's probably the most bogus "issue" strong type addicts bring up.

The only thing better than having tests is not needing tests. That's what a robust type system gives you.

Type systems don't eliminate all testing, but they do eliminate a large swath of possible errors that need to be tested for, like the one that has (had?) been afflicting Sinatra.

You might want to watch this talk for some data on this subject: https://vimeo.com/74354480

"Some programming language theorists would have us believe that the one true path to working systems lies in powerful and expressive type systems which allow us to encode rich constraints into programs at the time they are created. If these academic computer scientists would get out more, they would soon discover an increasing incidence of software developed in languages such a Python, Ruby and Clojure which use dynamic, albeit strong, type systems. They would probably be surprised to find that much of this software—in spite of their well-founded type-theoretic hubris—actually works, and is indeed reliable out of all proportion to their expectations."

The politest put down ever?

As someone who worked with Ruby since ~1.8.1, has written a ridiculous amount of OSS Ruby and now works mostly in Scala, this is the exact opposite of my experience.

YMMV, but I've never seen the Ruby project that didn't suffer from stupid bugs even the most basic type system would have caught.

One of the biggest advantage of type-systems for me is that they don't suffer from No True Scotsman. If you don't have a test that covered this bug, people are happy to tell you you're doing it wrong. The type-system doesn't have that problem. It doesn't "rot". It expresses only what you tell it to. It enforces maintenance and rigor in a way that tests, as non-integral code, fundamentally can't.

But that's just my opinion man.

What's your thought on something like contracts or facebook's flow (for js) ?

I can't watch because no subtitles, but man that intro is condescending. Not saying that academics are completely innocent either, but maybe if the description focused more on the substance of the data, it wouldn't seem like the smugness was a cover-up for trying to rationalize their choice of language.

Anyway, I'm no PL theorist, only a schlub that's a better programmer because of ML. Yeah yeah, sample size of one...

I'm not a programming language theorist or in any sort of functional-programming-static-type-system ivory tower – I just want to catch more bugs prior to runtime without needing to write tedious mechanical tests of method contracts. I find good type checking insanely refreshing. I find that I need fewer tests, they are easier to write, and they test more essential attributes of the program.

I've written lots of useful stuff in Python and Ruby, but I've also sunk lots of time into tests that I would have preferred not to need to write.

Let's not forget Grape either: https://github.com/intridea/grape

You could see this move towards JSON APIs way back in 2012 as I suggested here: http://paulbjensen.co.uk/posts/2012/07/11/thoughts-on-rails-....

Some poo-pooed the notion, but you can clearly see that the popularity of realtime frameworks and the way that apps are built client-side heavy is pulling Rails in this direction.

Performance is still the key factor here, and I suspect that's half the reason why you've got some people who espoused Ruby in the past now playing with other languages beginning with Ru, but that have a much less friendly syntax compared to Ruby.

Some welcome changes though nonetheless, especially on the WebSockets front.

I've recently switched from Sinatra to Grape for pure REST microservice development. Grape does a lot of things that turn into wasteful boilerplate in Sinatra. Haven't gotten far enough with it to find the downsides yet.

I've down API dev in Rails too, but it really feels like killing a fly with a hammer sometimes. And as I shift strongly to microservices (thanks Docker!), I want my API code to be as minimalist as possible. Grape/Sequel feels simple, which is good.

> Grape does a lot of things that turn into wasteful boilerplate in Sinatra

Would love to see a few examples

> I've down API dev in Rails too, but it really feels like killing a fly with a hammer sometimes

More like creating a few extra layers of abstraction to confuse the fly.

Like the concept, but the name is confusing. I get it is coming from a separate gem, but hopefully it is renamed to convey what the intent is.

I dont have time for the Video, has anyone written a post on what's coming in Rails 5 yet? ( Apart from Rails API )

What is the best Rails solution for javascript modules and package management these days??

Probably https://rails-assets.org/, you add it as a source in your Gemfile and then add gems based on the scheme "gem 'rails-assets-BOWER_PACKAGE_NAME'"

I'm a huge fan of https://rails-assets.org/. Requests components from the Bower registry and packages them as gems.

I've used a few different approaches, and Rails-Assets works really well both from an ease-of-use and dependency version management standpoint.

I recommend just using webpack or browserify... the workflow supports super fast on-the-fly bundling. Most reasonably large Rails apps end up embedding v8 anyway.

Reply on news.ycombinator.com