4 ms·
Rails developers seem to be having this revelation a lot recently. I don't think it's a particularly new idea, and I don't see why Rails vs Node vs Java has an
by masto 14y ago
Rails developers seem to be having this revelation a lot recently. I don't think it's a particularly new idea, and I don't see why Rails vs Node vs Java has anything to do with it. MVC is ok for a backend that's "just an API" (although there are probably better ways to structure things, such as CQRS). The language is irrelevant apart from the reasons it's always been relevant (speed of development, ease of deployment, testability, etc.).
I think the point at the end is worth expanding on, though: as long as your API is an API and not a thin connector to a specific backend technology, you can in theory swap out parts or the whole thing. Some time ago my company decided to build a new "web application", and there was some debate over how to structure the communication between (at the time) Flash and the backend. Some argued in favor of a proprietary protocol that makes it very easy for Flash to talk to Java and share data structures. Had we gone with that approach, we would have: 1. not had an easy path to having an "external API" by leveraging the identical internal API already built, 2. been stuck with Flash or at least had a much harder time converting to HTML when it became obviously the right thing to do, and 3. been stuck with Java on the backend and no clean service interface between the backend and fronted models.
It's always necessary to take some shortcuts in development, and I believe it's very important to choose the right shortcuts. Compromising on interfaces and encapsulation is almost always a terrible idea; better to spend the time hiding an ugly implementation behind a clean interface so that you at least have the option to fix it later.
- pjmlp 14y agoWe had this revelation already back in 2002! Back then, I was working for a startup that had a product similar in concept to Rails but based on Apache/TCL developed around 1998. The initial architecture ideas were taken from AOL Server, in case anyone still remembers it. Around 2001 we reached the conclusion that it wasn't scaling any longer for the type of loads that we needed, and more a better language infrastructure was required. After some research, the framework was ported to .NET, on those days still beta, but their JIT could already yield much more performance than our home grown solution.
- davidw 14y ago> Back then, I was working for a startup that had a product similar in concept to Rails but based on Apache/TCL developed around 1998. The initial architecture ideas were taken from AOL Server, in case anyone still remembers it. Which Apache Tcl thing? Who are you, by the way? Your profile doesn't show anything. BTW, Rivet can be scaled, like anything else can, although you're right that given the same resources, a compiled language is going to be more efficient. These guys use Rivet successfully: http://flightaware.com/ http://flightaware.com/ - A former developer of Apache Rivet.
- pjmlp 14y agoThis was way before Rivet was known, at least in Portugal. I'll be sending you an email describing how it was.
- tlack 14y agoAh AOLserver and ArsDigita, the heartbreaking technology tale of the early web. Such great ideas ruined by branding. What ever became of all those people and what are they working on now?