Live data from Hacker News

Rails is just an API

blog.alexmaccaw.com

81–90 of 114 posts

Re: Rails is just an API

#81
post #80
post #46

Let's say you have a website and let's say that website serves a lot of traffic. Now let's say you relegate Rails to act as just your API because clients are fast now and you want to do some new cool stuff with Javascript also, you're convinced your site is more like an "application". So you build this system and it works really well, except for one thing. The first time you load the page it takes a second or two min…

because you know who you are? Twitter No, I'm not twitter. Since when is their incompetence a metric for the capabilities of a technology stack? You could hand them a top10 supercluster and they'd still failwhale it. Remember, this is the same company that failwhaled for the better part of 2 years(?) on a pubsub app (one of the most researched and understood areas in computing, cf. telco industry, financial industry)…

I don't fully understand your point. My quote you're using is meant to be rhetorical. So you're not Twitter... are you implying that you could build an all JS application and avoid all of the problems that Twitter ran into at Twitter's scale? If so, I'd love to see you execute your ideas successfully and explain them so we could all learn from you.

Re: Rails is just an API

#82
post #46

Let's say you have a website and let's say that website serves a lot of traffic. Now let's say you relegate Rails to act as just your API because clients are fast now and you want to do some new cool stuff with Javascript also, you're convinced your site is more like an "application". So you build this system and it works really well, except for one thing. The first time you load the page it takes a second or two min…

Why does a client-side app hand wavingly take a second or two minimum to load compared to the 400ms server-side rendered one? Exactly the same work is taking place on the server apart from template processing. It makes no sense. If your API is going to be taking 2 secs to build a response, so will your server-side rendered one. There's no real overhead to DOM insertion and simple template output. If you're doing craz…

DOM manipulation can be very expensive, especially on IE 6 and 7.

Re: Rails is just an API

#83
post #49

Earlier quoted context omitted.

Rails isn't even participating in the fight It never did and it shouldn't. Rails became popular because with it developers had the ability to cut down on soul-sucking activities in their day to day jobs, like building yet another authorization system, or yet another admin. That some people ran with it and scaled it to its limits, that's only because they felt in love with its ease of getting things done. That's its m…

> Rails became popular because with it developers had the ability to cut down on soul-sucking activities in their day to day jobs, like building yet another authorization system, or yet another admin. I beg your pardon, but... what?! Out of the box, Rails has none of this. Rails is almost a meta-framework. Honestly taking your two examples: Devise is horribly complicated and the half-dozen admin frameworks that had a…

"but it still ends up being soul-sucking in numerous others where you have to either delve into needlessly complicated stuff or implement it yourself."

This is a false equivalence IMO. With rails i spend far less time on incidental complexity than I do with anything else I've tried.

Re: Rails is just an API

#84
post #50

Decent post with the wrong conclusion. Why do I need an MVC to make a RESTful API?

MVC for server-side APIs is still useful because you still need separation of concerns, validations, access control, session management, data crunching, etc on the server.

Re: Rails is just an API

#85
Let's talk about context switches here: OMG! it's going to be sooo hard for developers to switch from a model where all the logic happens on the server and where the client is just a dumb display to a model where the all the logic happens on the client and the server just serves as a coordinator.

Oh wait. That already happened, and it was called the switch from mainframes to PCs (or whatever the fuck you want to call it). The point is: developers adapted, and got over it, and you will too.

The question I (and everyone in this community) have (or should have) is - are there strong technical foundations for this switch? Is Javascript the right client-side interpreted language to support every conceivable application over the next 10 years? Is HTML the right display/templating language?

My answer: no, not at all. But it's hard as hell to fight the momentum of an unstoppable force. Even with an immovable object.

Re: Rails is just an API

#86
post #29

Earlier quoted context omitted.

The problem with fat client-side models is that allows malicious users to potentially break your code. Inject bad things. Re-assign users. Etc. We'll always need some sort of server-side last-mile, tamper-proof validation. So given that, I'm not sure the benefit of duplicating it on the client side.

This. You duplicate validation logic on the client side in order to provide rapid feedback to the user. But it's a huge mistake to not let the backend have the final say.

Are you saying duplicating code is ok if only to make the app appear faster? I've often wondered that myself.

Re: Rails is just an API

#87
I'd love to know what people think the current "state of the art" stack is for rich and highly scalable web applications, something that has been proven to work great in production by big projects. Is it nginx + Rails + Backbone? When I think of fast rich web apps, Facebook and StackOverflow come to mind, and as far as I remember, neither use the above-mentioned tools (not that it means they're bad in any way).

Just a couple of years ago Rails-generated HTML pages were super hot, and now people are almost insulted if you don't have a fairly complex Javascript framework running the show.

Re: Rails is just an API

#89
post #46

Let's say you have a website and let's say that website serves a lot of traffic. Now let's say you relegate Rails to act as just your API because clients are fast now and you want to do some new cool stuff with Javascript also, you're convinced your site is more like an "application". So you build this system and it works really well, except for one thing. The first time you load the page it takes a second or two min…

Why does a client-side app hand wavingly take a second or two minimum to load compared to the 400ms server-side rendered one? Exactly the same work is taking place on the server apart from template processing. It makes no sense. If your API is going to be taking 2 secs to build a response, so will your server-side rendered one. There's no real overhead to DOM insertion and simple template output. If you're doing craz…

One reason would be if you use a compiled language server side that could be a reason its faster than javascript. another reason would be that rendering pages is usually lighter weight, you already may have a lot of objects in memory on the server, especially if using orm layer caching, etc, as I understand it, a framework like backbone has a slight delay in configuring itself

Re: Rails is just an API

#90
post #60

Earlier quoted context omitted.

You might find these demoes of Flask with pjax interesting then: http://flaskpjax.herokuapp.com/automobiles https://bitbucket.org/a2c/pjax_flask/overview

If you go down the API route, Flask-Restless[0] and simpleapi[1] are also worth a look. [0] http://readthedocs.org/docs/flask-restless/en/latest/ [1] https://github.com/flosch/simpleapi

Is there any of this solution that bundles with an easy mobile library/sdk? I was asking for something like a semicomplete backend opensource solution here http://news.ycombinator.com/item?id=3735387 but unfortunately I got no responses
Post reply on HN