
When Should You Not Use Rails? - luu
http://codefol.io/posts/when-should-you-not-use-rails/
======
jeff_vader
Anecdotal random story bits from my current company on why you should stick to
Rails:

\- All of our "lightweight Sinatra(and similar) API" services eventually start
to look more and more like Rails apps. Rails does many small developer
convenience things well. Which you do not notice until you build this
lightweight API yourself. E.g. console, logging, migrations, database
connection pooling, rspec integration, i18n.

\- No one likes to work with your arbitrary personal project structure
conventions. Where's the code? 'lib'? 'core'? 'app'? 'api'? Also, no one wants
to learn your lightweight "data mapper" pattern written from scratch because
you thought ActiveRecord is too bloated and "does not scale". That being said,
there's quite a few things you can arbitrarily pick in Rails projects as well
which others will find surprising. But the spectrum of those choices is little
narrower.

\- Developers most of the time assume database connection pooling just
magically happens. Sysadmins do have no desire to debug your apps. After
couple weeks of back and forth you may realise that Rails does database
connection pooling for you. And simply requiring 'activerecord' and
establishing connection in your Sinatra app does not.

\- One day someone doing production maintenance wanted to remind themselves
rake task name. And ran 'bundle exec rake' forgetting to add '-T'. Default
task was rspec. It dropped production database. That day many learned that
Rails has safeguards against things like this, while none of those
"lightweight arbitrary structured APIs" had any. Though the lesson was clearly
not very good, since we did this again couple years later.

~~~
vbsteven
This.

There are so many things that are required in a modern web app that these
"batteries included" frameworks provide for you that it just makes sense to
use these for most standard projects.

I personally use Spring Boot as my default stack because just setting up a
basic boot starter project gets me:

* Routing

* Server side templates

* i18n translation files

* database connection pooling

* database migrations

* ORM

* Logging

* Json serialization

* unit testing, integration testing, mocks

* CSRF

* Validation framework

* Dependency injection

* SMTP email sending

and much more, all compatible with each other

If I would start with a blank Sinatra/Express project I would have to piece
together all of these myself from various libraries and my own code.

~~~
bzb3
But those frameworks force you to do things the way they want you to. As soon
as you need to deviate a little bit, and very often you'll have to, you'll
have to rewrite the entire thing.

~~~
dwheeler
I think that depends on the framework and what deviation you want.

I agree that if you use Rails and constantly override its conventions, you
will have a bad day. But following conventions is usually a strength, not a
weakness. Most websites are not shocking cutting-edge things that have never
done before, but relatively boring simple tasks that involve grabbing data
from databases and showing them to users via templates. Every decision you
have to make is a cost, and if you have a small team, having basic naming
convention decisions and directory location decisions already made accelerates
development. There's a big advantage to following conventions when you want
others to work with you, because different Rails applications look quite
similar in many ways.

I have not had trouble overriding Rails when I needed to override something
specific.

Btw, I like the original article. There's nothing that's good for all cases,
so it's very important to understand what something is good and not good at.

~~~
philwelch
Sometimes, Rails’ conventions are just wrong, though.

Databases can have various constraints (uniqueness, etc.) enforced at the DB
level. ActiveRecord also allows for uniqueness checks, but these are separate
mechanisms. If you want to validate for uniqueness, two processes each running
the same Rails app might concurrently check for uniqueness, assume validity,
and then independently insert two non-unique records. At this point, your DB
will throw an error. (Edit: Rails actually wraps this exception now, but if
you follow the idiomatic pattern and don’t bother catching it, it just 500’s
the request.) Rails is (edit: still) not wired to treat this as a uniqueness
violation at all; it just has its own uniqueness validation mechanism that
doesn’t even work in the most common use case for Rails.

In a concurrent environment like this with a shared DB, the only way to avoid
check-and-set conditions is to just try the insert and only complain about
uniqueness violations when the insert fails the DB-level uniqueness check.
(Edit: Rails provides a wrapped exception for this use case, but that’s
certainly not the conventional Rails way of handling uniqueness validations.)

Conventions are fine when those conventions work and actually enforce good
practices. ActiveRecord in particular falls short of this. And without
ActiveRecord, the rest of Rails doesn’t do much to distinguish itself from
alternatives. It’s fine, but it’s not necessarily anything special.

~~~
projct
> Rails does not, or did not when I encountered this issue, recognize the
> error as anything other than “whoa dude, MySQL/Postgres/whatever is
> complaining, check this out”

ActiveRecord has thrown ActiveRecord::RecordNotUnique for this and done the
right thing for over 11 years (the exception definition got moved to a
different file at that point so idk exactly how old it is.)

> ActiveRecord in particular falls short of this

> without ActiveRecord, the rest of Rails doesn’t do much to distinguish
> itself from alternatives.

Callbacks are pretty bad but it sounds like Rails went through several near-
complete rewrites worth of changes since the last time you used it. There's a
lot more in Rails 6 compared to Rails 2.

~~~
philwelch
> ActiveRecord has thrown ActiveRecord::RecordNotUnique for this and done the
> right thing for over 11 years

I had these issues in Rails 3 when that was the newest version. I found the
git blame you’re referring to here and it may have been _written_ 11 years
ago. Odd. It looks like maybe Rails 4 finally fixed this?

More to the point, the broken uniqueness validation is still there, as is the
idiomatic “validate then write to the DB” race condition that leads to this
issue in the first place. There’s zero correlation between stating in your
ActiveRecord model that you would like uniqueness (or any other constraint)
and actually enforcing that constraint in the database, where it actually
works. Having an actual wrapped exception to catch is an improvement but it
doesn’t fix the problem.

~~~
dwheeler
I think this is pretty clearly documented:
[https://guides.rubyonrails.org/active_record_validations.htm...](https://guides.rubyonrails.org/active_record_validations.html#uniqueness)

"This [uniqueness] helper validates that the attribute's value is unique right
before the object gets saved. It does not create a uniqueness constraint in
the database, so it may happen that two different database connections create
two records with the same value for a column that you intend to be unique. To
avoid that, you must create a unique index on that column in your database."

It's pretty clear from that text that if you want a unique index in a
database, it has to be a uniqueness constraint in database itself. But that's
true for any such system, that's not specific to Rails.

In most applications there are simple isolated validations you can verify
_without_ consulting the database, and other validations that can only be
validated by consulting the database (such as uniqueness). Rails can do that,
as can many other frameworks. I don't think that's broken, that's how things
are.

~~~
philwelch
Rails not only has to consult the database to validate uniqueness, but it
still doesn’t know for sure even then whether the row will remain valid. So
why not just insert the row and see if you get away with it?

Simply removing the uniqueness validation and relying exclusively on database
indices would be strictly better. ActiveRecord dynamically infers from the DB
schema which columns your tables have; it could also infer foreign key
relationships and uniqueness guarantees and use them to generate pre-insertion
“best guesses” about validity if the user wants to run those without
necessarily inserting. But Rails is supposed to be an opinionated framework,
and “just try to insert and we’ll let you know how that worked out for you,
since we can’t make any guarantees otherwise” is a perfectly valid opinion.

------
renewiltord
Funny, I never bothered to not use Rails because I can go from zero to
everything running on Heroku in 15 mins now with SSL on a domain and all the
shit. Being incredibly lazy I do this even for non-DB stubs, using the free
Heroku Postgres add-on. So I don't even know if it's possible to run Rails
without a DB. I did try `nulldb` last time but migrations broke, which is odd.

Honestly, even if doing JSON API -> React frontend, I'd still do it. It's too
easy to get it right with Rails.

~~~
davedx
Yep, I built a salary calculation app with Rails and React, using it as an API
and it still saved me tons of time, and the business logic was well suited to
Ruby with some nice unit tests

------
nurettin
> I’d still start out in Rails, personally. If you’re building something
> quickly to see if anybody cares, I know of no framework that comes close to
> its productivity.

I've used RoR for 5 years, spring boot/kotlin for 2 years and Django for a
year. Once you've set up the workflow, there isn't much difference in terms of
productivity. The pain point is setting up the base project and keeping it
updated as library versions change.

What django and spring boot are missing are the commandline generators for
entities, controllers and views and a quick setup.

Django and spring boot need a little bit of careful setup. Django needs its
settings, applications array, middleware declarations, etc. Once you get over
this and start adding your entities, views and routes it goes fine.

Spring boot requires a rigid folder structure, application property files, a
careful setup for migrations and logging. Liquibase setup, etc. It doesn't get
off the ground easily. Once you start writing your entities, repositories,
controllers, services, views it goes smoothly thanks to lazy initializers.

~~~
evnix
springboot? it cannot get easier than this:
[https://start.spring.io/](https://start.spring.io/)

I personally choose Java/SpringBoot, it has a steep learning curve, but has
strong typing, runs as fast as most C++ code out there, plus you can do async.

and if you want something fast but that is as easy as Rails and runs on
Java/Groovy/JVM, use Grails.

~~~
treis
>springboot? it cannot get easier than this:
[https://start.spring.io/](https://start.spring.io/)

That doesn't seem easy at all. Immediately I am presented with 5 choices and
then a list of 50 things that I might want to add to my application. Some of
those 50 choices seem to be mutually exclusive and I don't have any way of
knowing which I might want or why.

Rails? Just rails new myapp.

~~~
cogman10
To be clear, your choices are:

Build system, Language, Spring version, Java packaging, Java version

The rest is naming.

That is not complex to me.

As for the dependency options... well, they are dependency options. I'm sure
you have no problem with adding gems to a rails project, even though there are
thousands of them that may be mutually exclusive! A non-ruby dev might not
know which gem they want and would have no way of knowing what they want or
why!

rails new myapp is exactly the same as doing this with no dependencies.

------
yakshaving_jgt
> Ruby isn’t designed for a team of 200 programmers where you don’t trust some
> of them.

Never mind a team of _200_ , even on a team of _one_ person I don't trust
_myself_! That's why I'm using typed FP. I don't trust myself not to make
clumsy errors. I don't trust myself to be disciplined and write all the tests.
I don't trust myself to not design a naïve architecture which I'll have to do
a huge — and dangerous — refactoring on later.

This is why I'm not using Ruby/Rails any longer.

~~~
rgoulter
I think "refactoring is much safer in strongly-typed languages" is a point
against using Ruby. It's my understanding that some of what counts as "writing
tests" in Ruby would be covered by static types in other languages. -- But
it's also not the case that that having types excuses the developer from
having tests. (Maybe with dependent types?).

This point reminds me of some essays from Steve Yegge where he argued that one
way of categorising programmers was into two groups: 'conservatives' who liked
languages like Haskell where you could have confidence the code worked if it
compiled, etc. and 'liberals' who liked languages like Ruby, where if you
notice something breaks you just fix it; just write some feature to see if it
works or not. \-- I'd think for prototyping it's nicer to have the latter
attitude, and it's more reasonable you'll have an understanding of the system
since it's so fresh. For long term maintenance, the former is surely better

~~~
jmchuster
The Rails/Ruby community has probably the most developed testing culture out
of all the programming communities out there, because tests are so critical
when you're writing in a dynamic backend language. You don't have the built-in
"tests" from a compiler that check every argument and method reference. And
then you don't have as fast and obvious a feedback loop as you do with
frontend languages.

------
slowmovintarget
I can't imagine developing an application this way anymore.

From the article: "Rails has less to offer an API server that speaks JSON over
the wire."

Everything we do works this way now (JSON over the wire). Everything is a
RESTful API first. We build a UI that uses the API, but the business function
is served completely from the API. Why? Because if the function is valuable,
then some other program will likely want to exercise it programmatically. _All
of our capabilities are built to be composed programmatically by default._

The additional effects this has on our organization is that we can often turn
around new integrations in hours. They're all API calls. Other developers can
kick the tires through fully secured Swagger UIs before a pretty application
ties it together. And everything we build can be combined into multiple
different UIs anywhere in our suite of applications.

Every API is built with the assumption that it is out on the public internet,
subject to all the security and scaling problems that entails. What it has
driven us to do is get very good at standing up hardened, simple services that
host a consistent API-style.

We build UIs, but we assume the real value is in the functionality and the
data, not in one specific form of its presentation.

~~~
lostcolony
Less doesn't mean none. Rails (and frameworks like it) serve multiple purposes
-

One is serving server side rendered pages. One is providing non-functional
requirements such as security (including browser based security, some of which
is tied to the pages served, i.e., CSRF tokens). One is providing CRUD
functionalities.

The first one, and some of the conveniences of the second, you'd not benefit
from. The last one, and some of the core functionalities of the second, you
would. So, less to offer, but not 'nothing'.

------
vvillena
The article points out a nice pivotal moment where Rails stops being as
useful: when the server costs are higher than the engineering costs. I'd add
that this shouldn't be a comparison based on a prediction, but on an actual
monthly report. Until then, I find Rails to be a perfect tool that enables
devs and companies to keep working on what matters.

~~~
AlchemistCamp
I totally agree with the thrust of this. There is one other concern, though. I
actually just submitted my own blog post on how infra costs can break a
business. [https://questinglog.com/costs-are-part-of-
scalability/](https://questinglog.com/costs-are-part-of-scalability/)

If your business model brings in $X per unit of usage your hosting costs
_need_ to be < $X per unit of usage or else no amount of engineering will make
your business profitable.

One of the founders of Twitch recently tweeted about how using Amazon's new
service for Twitch-like video streaming simply wouldn't be feasible for
building your own Twitch.

------
silviogutierrez
You can pretty much substitute "Django" for any case where Rails is not
appropriate. That is, they go hand in hand and both have similar uses.

But there are very few cases. Fewer I'd say than this article lists. Low level
programming, and yes perhaps event-based systems. [1]

I find people just like rewriting their own batteries and conventions. Fun, no
doubt, and a good learning experience.

I challenge any microframework / library user to surpass the productivity of a
mature framework like Rails or Django. I argue nothing comes close.

And I don't mean "for the 5 second MVP". Perhaps your app won't need some of
the batteries, but your app _will_ need logging. It _will_ need database
migrations. It _will_ need forms and inputs. It _will_ need media uploads. It
_will_ need to send email. And so on.

Future proofing too much is an issue in the industry. YAGNI after all. But
this is the opposite case. I deem it: YAEGNI. You are eventually going to need
it.

[1] Django 3.1, just released yesterday, begins treating async as a first
class citizen. I was initially opposed to this, given 99% of the time you
don't need async. But I suppose it's nice to have and drop down to.

~~~
darkhorse13
It is very difficult to explain to someone who has not used Django/Rails just
how productive they are, especially Node.js devs. I started off with Django,
so when I moved to Express for a project, I was immediately slapped with the
reality that I needed to write my own forms and admin site. These are some of
the things that you simply do not have to worry about with the aforementioned
batteries included approach of Django/Rails.

~~~
silviogutierrez
Exactly. Every NodeJS tutorial starts with: "look how easy it is to write a
server and listen on port 3000".

Yea it's easy. But why are you writing a server? That should be the least of
your concerns.

~~~
doteka
Well, I need to write a server if my requirements don’t fit a server side
rendered application and/or my usecase does not fit the absolutely anemic
performance of Rails, which also applies when using it only for an API (it’s
not Ruby’s fault btw).

The classic response is “zomg premature optimization bad”, but some of us work
on more complex applications than simple database CRUD.

------
jakuboboza
Well if you need full package of migrations, html rendering etc... Rails is
still a good choice. It is 2020 not 1996 we have choice now and picking up
framework/solution based on our needs is standard.

Ruby/Rails and Elixir/Phoenix has one big thing, REPL. No matter what you
choose. C++, Go, Rust, Node etc... getting solid easy to use REPL is effort
and not built in feature.

in Rails/Phoenix you get it for free. That is a great perk!

~~~
rubber_duck
How is REPL not a built-in feature of node ? Adding a REPL to any interpreted
dynamic language should be trivial.

~~~
p_l
Semantics of execution can vary wildly. Node is somewhat usable except for the
"REPL is not async context" which leads to annoying tricks, but for example
Python is very non interactive due to code reload behaviour

~~~
rubber_duck
>Node is somewhat usable except for the "REPL is not async context" which
leads to annoying tricks

What do you mean by this ? It's been a while since I was able to use await in
REPL, maybe you are referring to something else ?

~~~
p_l
Was either Node v10 or v12 (I suspect the latter), as it was in december 2019
or so and I tended to use latest stable. Await in REPL definitely didn't work,
maybe there's tooling to fix that? Unfortunately Node is not my main, or even
third-line tool, but I had to work with Strapi and it was definitely a common
issue that I couldn't use "await" on a function.

------
jonnycat
I've used Rails for various products for 10+ years (and plenty of other tools
for comparison) and really appreciate it for the productivity, conventions,
philosophy, etc. But after spending most of this year with Elixir/Phoenix, I
don't think I'll ever go back.

In my opinion, Phoenix competes well with most of the strong points of Rails,
and avoids many of the downsides - including the ones discussed in this
article. It's also built on a more performant and robust foundation
(Erlang/OTP). You may not truly "need" some of those advanced foundation
features at first, but at just the same point where a Rails project starts to
struggle, Phoenix really shines.

Phoenix is not the solution for every app, but for every app where I would
have used Rails in the past, it's looking like Phoenix from now on.

------
spion
Personally once I started working with TypeScript, I don't want to go back to
an untyped dynamic language. Its just too painful, even for personal projects,
and tests don't fix the pain (at least not at the expense of not doing test-
induced design damage which is also painful)

------
lukecameron
Has anyone heard of good resources that teach you "when to use X" instead of
"why you should use X"?

It's somewhat understandable that the official websites of
frameworks/tools/libraries/languages/services tend towards espousing the
advantages of the thing and leaving out most of the drawbacks. That's just how
the incentives are aligned. But even the average blog article about a tool
posted on HN rarely talks about what situations it is most effective, and what
situations it should potentially be avoided. I suppose it's a natural
consequence of blog authors only knowing so many tools, no single person knows
them all.

I'm not saying this information isn't out there – just that it seems like the
exception rather than the rule.

~~~
nickjj
> Has anyone heard of good resources that teach you "when to use X" instead of
> "why you should use X"?

One of the goals of a podcast I started last year was to answer that type of
question and more.

It's mainly a podcast where I talk to someone new every week to get a better
understanding of why they chose a specific tech stack to build their app but
it also goes into the "how" since we talk about how they build and deploy
their app, lessons learned along the way, etc..

A list of episodes can be found here:
[https://runninginproduction.com/podcast/](https://runninginproduction.com/podcast/)

Each episode has a "Motivation for using ..." time stamp so you can jump to
that part of the discussion. It's usually within the first 5 or 10 minutes.

The goal here is to have a bunch of real world examples of why and when
someone used X and they usually spend a few minutes talking about why they
chose that instead of something else too. There's episodes ranging from solo
developers working on a side project to high traffic services handling
billions of requests per month.

The idea is to have loads of practical examples instead of trying to theory
craft hypothetical scenarios.

~~~
lukecameron
Thanks for that! Coincidentally I’ve had that podcast on my list for a while,
guess it’s time to give it a listen.

~~~
nickjj
No problem.

Around 4-5 months ago I implemented a custom player so now it's really easy to
listen at 2x speed, and there's always been timestamped links to quickly jump
around to specific topics.

------
JoelMcCracken
Curious, what does the author mean here:

When It’s ‘Just’ an API Server: Rails has less to offer an API server that
speaks JSON over the wire. A lot of its HTTP security doesn’t matter for that
case (e.g. SQL injection safeguards, XSS prevention.)

It seems to me that SQL injection safeguards would still be needed in an API
service. OFC XSS isn't relevant though.

(I word it like this to be charitable in case I misunderstand what the author
was trying to say, but if they are trying to say what I think they are, I
think they are wrong.)

~~~
jholman
I have no idea what TFA meant, but if they meant what you assume they meant
(and I tend to agree with you) then the whole premise is broken. I'm not aware
of "preventing SQL injection" as any particular advantage of Rails (nor even
of ActiveRecord).

Obviously if you write sufficiently bad ActiveRecord method calls, you can
trick it into doing SQL Injection. So it's not magic. (Indeed, I view that as
a strength of AR; it has robust escape hatches. I hate ORMs, but I hate AR
less than any other ORM.)

And equally obviously, every credible database driver written in at least the
last 15 years has robust support for prepared statements and tolerable
documentation on how to use it that can be understood in literally a few
minutes. Which, of course, is exactly how AR gets it right in the first place.

(And I only have to say "in the last 15 years" because of the dumpster fire
that was turn-of-the-century MySQL.)

------
tluyben2
Is Rails still (I have not used it since 2016) incredibly hard to migrate
after a couple of years? I have java/spring, asp.net (core) and php (no
framework) in production and I can upgrade after a decade not touching and
everything still works. I had Rails upgrades after 1-2 years that were
absolute nightmares. I'm not sure about other people here but I really don't
want to suffer through that 'for fun' while I don't have to. Speed of
developing is not so much faster that I would take this for granted. But maybe
things changed.

Edit; it was a question, what's with the downvotes? It used to be bad; I'm not
the only one saying that. It's normal (Laravel, Node etc have it as well; it's
fast moving).

~~~
Ecco
I don’t get why you’re being downvoted. You’re right, a while ago that was a
major headache. The good news is that it’s now much better!

\- Bundler makes keeping track of gems trivial

\- Rails defaults are explicitly version-bound. E.g. you can update to Rails 6
and keep using Rails 5 defaults.

\- There are now extensive official guides on how to update.

~~~
tluyben2
Good to hear, thanks! Maybe i'll try it again as it was quite nice outside
updating/upgrading.

------
going_to_800
Just another critical article without substance to steer up rails community
and get some readers.

That API part in particular is dead wrong. Gives the feeling Rails is not good
for anything.

~~~
jakuboboza
The scaling factor for each app is really the way it interact with slowest
part of the API. If it is Database than no matter how optimal your Rust code
is, you might fare in the end not that much better than Rails just because you
hinged everything on eg. Postgres.

~~~
throwaway189262
Db is slow anyways is the default excuse when using slow web backends.

The one I'm currently working on is blazing fast and were truly hitting
postgres limits... At nearly 50k requests a second.

The DB is rarely a bottleneck if you have sane structure and indexes.
Ironically the slowest frameworks also tend to generate terrible queries
(ActiveRecord, SQLAlchemy), so you end up with a slow database and web
framework

~~~
dimgl
I agree with you. I don't think anyone can convince me to use these bloated
frameworks on any project ever again in my life.

------
rm_-rf_slash
Something not touched on in this post but I’d like to know is the preference
for using Rails with a Single Page App built in a framework like React.

When our team determined React to be the way to go for the front end, I looked
at all of the parallel dependency management and the backend complexity (one
might call “sophistication”) of Rails, and ultimately decided to make the
backend in Node instead.

Has anyone here experienced pleasant success with RoR+SPA?

------
out_of_protocol
Phoenix as a Rails successor does fix most of these issues, in a right way.

------
diehunde
You can build "API only" apps with Rails using rails-api[1]. It removes all
the bloating that comes with a typical html rails app.

[1][https://guides.rubyonrails.org/api_app.html](https://guides.rubyonrails.org/api_app.html)

------
jholman
I think this is a pretty reasonable and balanced article, actually, and I
think it straight-up admits what many instructors lie about:

If you already can write a Hello World back-end in some other
language/framework, and you're now learning Rails just so you can do
Rails+React, that's a dumb waste of time.

(I'd say the same thing about most frameworks for most purposes, but it's
especially true with Rails. But doing Rails+React when you're already fast and
competent with Rails, that's a very sensible choice in most situations.)

------
musaffa
I use Ruby to create API servers these days. For a couple of APIs, I used
Rails API. Now I use a combination of dry-rb, rom-rb, roda and other pure ruby
libraries to create APIs. There's a growing movement within the community to
move Ruby off Rails.

Before the API thing, I also developed websites with fullstack Rails. The
experience with fullstack Rails and Rails API have helped me a lot to
understand the requirement of a backend framework. I'm forever endebted to
Rails for this.

------
lovetocode
I love Rails and it has done a lot for my career. However, after 6 years of
Rails development I find myself far more likely to be reaching for ‘dotnet
new’ rather than ‘rails new’.

~~~
karmakaze
What language/framework does that use?

I played with F# and liked it enough but didn't use much of a framework
(Giraffe). Biggest hurdle was there wasn't a good up-to-date setup guide I
could find for macOS.

~~~
cutler
ASP.Net Core 3.1 is perfectly usable on OS X and by the end of the year .Net 5
promises to be truly cross-platform.

------
donmb
I agree with the article. For instance, I was using Rails a lot in the past
when I was bootstrapping small shitty projects to get a "taste of the user"
and validating my ideas. For more complex projects I am using Ruby business
oriented frameworks (trailblazer is a great choice here!) but I flavour it up
with some ActiveRecord and ActionMailer as its very convenient. In general,
the whole Rails framework became too much for my projects and to blown up.

------
greatjack613
>>When It’s ‘Just’ an API Server: Rails has less to offer an API server that
speaks JSON over the wire. A lot of its HTTP security doesn’t matter for that
case (e.g. SQL injection safeguards, XSS prevention.)

I disagree on the SQL injection part, Api calls can contain user input which
in turn can be used to perform SQL injection, I am not sure what the
difference between a website and an api server is in regard to this concern.

------
pmarreck
Answer: When Elixir/Phoenix exists

~~~
AlchemistCamp
That's sure the answer I arrived at.

~~~
pmarreck
Did Rails for at least a decade, but won’t go back after doing elixir/phoenix
for a couple years now

