[fennecfoxen]

Sinatra is all well and good until you have an application complex enough that you want to start applying some interesting methods of code reuse across several routes, and want to share several facets of, say, object loading and authorization, or something around page rendering. At that point you run into the fact that all your tools for manipulating the request and response are built into a singleton object (your instance of Sinatra::Base) which begins to inhibit several very useful forms of code reuse (such as most OO inheritance schemes, for a start).

If I had a dollar for every minute I wasted rewriting things that I could have for nearly-free with (for example) Rails and CanCan and a quick call to load_and_authorize_resource in my ApplicationController, or a lame hacked substitute Rake task for ActiveMigration... that'd be a distressingly accurate description of way too much of my career.

Of course if you really are just building just the one microservice and don't have any complexity to manage, then yes, Sinatra all the way, 100%.

[hardwaresofton]

Would you mind giving a semi-specific example? It sounds like general use of ruby-based Dependency Injection is the solution to your problem, not necessarily rails.

Also, OO inheritance has some well-documented flaws as a code-reuse mechanism. I couldn't point exactly to what favoring composition over inheritance would look like in ruby (I've seen some approaches, but have an unhealthy dislike for the word "Factory" so they didn't seem great), but maybe there's a better way to share that code you're trying to share? Also, I don't think the solution is mixins because once you have too many of them how they interact becomes very hairy -- but regardless, I think a ruby solution exists to that problem as well. There is also the "has a" vs "is a" distinction but I digress.

Of course, there is a point where you shouldn't rebuild the wheel, but I don't think "shared functionality", or "access to persistent objects across requests" is that point.

To expand on what I mean, if these are the things you want to do:

- Respond to requests like an API server

- Serve static files

- Serve templated files

- Shared information across request

- Share application-relevant objects across requests (ex. marshallers, keystores)

- MORE STUFF

- ...

I think the point where rails makes sense is at/after "MORE STUFF", and possibly in "..." range.

[fennecfoxen]

Semi-specific example: I worked at a place that operated on a marketplace model. It was desirable for all marketplace submissions to be reviewed by a set of humans who were paid for that effort by the review. The existing system for doing this was in a bad state. By "bad state" I mean coded in a legacy system with no tests or even separation of concerns (think of a system that iterates over the results of a query, making additional queries and rendering JavaScript snippets to the page in this loop) and hitting scalability limits as it made exciting joins across the company's master database.

The company's architectural model dictated that the new version should take the form of a (non-micro) RESTful service layer handling the data in its own database (also facilitating the application of the problem to new lines of business for different varieties of marketplace item under different brands, improving visibility to the review process to sellers, and leaving open an avenue to outsource or automate certain parts of the problem.) We would migrate the legacy code over to use this layer instead, then we would write new frontend code with better workflows, then we'd coordinate with other teams to review new classes of marketplace item with different review criteria, then some year we'd have room for the pie-in-the-sky machine-learning-assisted review (assuming that something more important didn't come up instead.)

The result of this was a modestly complex set of abstract business-data objects, including marketplace items, all the metadata associated with them (editable by reviewers in this system), owners of items, reviewers, reviews, internally visible comments associated with the reviews, feedback associated with the reviews, review escalation, reviewer-supervisors, and a variety of other things which I forget right now.

I say RESTful: while not as pure as it could be, it actually did a half-decent job of being hypermedia-y and not merely "throw some JSON around over HTTP". Things had URLs instead of just IDs. Lists of objects were paginated with consistent ways to get links to the next/previous page.

Sinatra left us with uncomfortable choices between having excessive code duplication and the quality/maintainability issues it would bring, or writing our own logic to ferry Sinatra's various handles to the request / response / templating engine. We chose the latter, and I don't regret it - I regret that we sunk as much time as we did into that piece of code instead of building it on top of something with richer abstractions. It was the wrong choice for this particular application.

[hardwaresofton]

Thanks so much for the example, I understand why you made that choice!