> Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.).
Your perception of the strong points of rails are very different from mine. The strong points include rapid data and logic modeling, json serialization (jbuilder), robust libraries for user management (devise) and many other things, built-in security, routing logic, easy testing, and meta programming. You still get rapid prototyping in api mode, with a rails generate scaffold quickly capable of creating tables and a json rest api for that resource in a single line with no additional work necessary (assuming you had no business logic, which is generally easier to write in ruby as well).
Yes, I was highlighting my view.
To respond to the advantages mentioned:
- Roda (or Sinatra) gives routing. Actually it's very advanced routing that can be composed
- JSON serialization can be achieved more easily with Hash + Array and a subset of basic types (boolean, numeric, string, nil), which are easier to generate than with jbuilder, and it's also more performant. That being said, nothing stops developers from using tilt-jbuilder (gem) to get immediate support from Tilt for jbuilder, which can be used from Sinatra and Roda seamlessly, and can also be called everywhere, not just views
- Rails testing is actually _harder_ than normal Ruby testing. On top of my mind, a glaring example of this is the impossibility to instantiate a Controller and do dependency injection on them, which should be normal for any object. This is not a problem if dealing with just Ruby. Rack-test gives the same "request specs" that are present in Rails (actually it's built on top of that). As usual, the option of choosing different testing frameworks is available, given that it's normal Ruby. There isn't a need for special testing framework integration, so it's possible to use the beautiful Test Bench: http://test-bench.software/
- Devise is actually a bad choice for Rails API. It's poorly documented when used in API fashion (authentication through token), providing a whole set of utilities for sign up that are unneeded for API. However these endpoints do expand the attack surface, reducing security. The performance is also reduced, when authentication can be achieved with Redis instead of an SQL database as backend. The amount code needed for secure and well defined authentication can be written in ~5 hours of production quality code, with extensive testing (I did this quite recently). Either way, `rodauth` is available for every need
- Rapid data and logic modeling, presuming I understand what it's referring to in this context, it's given by ActiveRecord, that gem can be used with anything, there is no necessity to use Rails. This brings data migrations. For logic modeling, that is a Ruby feature, not a Rails one: Rails doesn't provide any utility from the logic perspective. In addition, putting logic into ActiveRecord models is very dangerous and known to be a problem by the community
- Rails doesn't provide metaprogramming, Ruby does. That is available with any Ruby application
- Rails does provide the scaffold command, but if the amount of tables that needs to be written is so large that this command is actually providing a benefit over duplicating a file (the activerecord model. ActiveRecord already provides the command for generating migrations wherever it's used), then the cost for writing a Rake task that generates a migration and a new file with an empty ActiveRecord model is negligible (1 hour)
With Roda I see other advantages:
- Highly performant webserver (13 times faster than Rails API, 10 times smaller memory footprint: https://roda.jeremyevans.net/)
- Incredibly faster application load speed. Restarting the server is not a problem, running the test suite is not a problem either
- No autoloader, while preserving the ability to reload code. Now Ruby `load` behaves like the normal Ruby load (not monkey patched). This prevents a gigantic amount of problems reached as soon as the app starts to grow, related to how Rails loads constants: https://www.honeybadger.io/blog/avoid-these-traps-when-nesti...
- Using traditional tools for handling javascript, CSS and public assets, which Frontend developers are familiar with (webpack, parcel)
- Very small project, with ~4-5 files the whole setup is ready
- A tremendously smaller API surface (API as in "application programming interface", not HTTP), this greatly helps reducing bug surface and cognitive overload
Now if the application's need is form-over-data (so, not a JSON API), then sure, use Rails. But in that case you must be using ActiveAdmin, to get real advantages. In that space, there is a large amount of competitors in other languages or no-coding tools that Rails has to face. On top of my mind: Forestadmin, Hasura, PostgREST, Django with Django Admin.
Your perception of the strong points of rails are very different from mine. The strong points include rapid data and logic modeling, json serialization (jbuilder), robust libraries for user management (devise) and many other things, built-in security, routing logic, easy testing, and meta programming. You still get rapid prototyping in api mode, with a rails generate scaffold quickly capable of creating tables and a json rest api for that resource in a single line with no additional work necessary (assuming you had no business logic, which is generally easier to write in ruby as well).