Lotus, a web framework for Ruby

Not at all. We have apps that have their own private data stores either because they need complicated models with many inter-model connections, or because their data is completely private to themselves, and there is absolutely no benefit to a sharing it through an API.

The data store is intended primarily to be used for hetereogenous "content collections", for the lack of a better terms -- blog posts, comments, classified listings, products, articles, events, messages, etc. Anything that exists in bulk with simple CRUD semantics. It's less suitable for structural objects such as sites, users, groups, memberships, hierarchical, etc. where the semantics need to go beyond CRUD.

The data store model is extremely simple, and therefore somewhat poor in terms of possible interactions. There is very limited support for querying, for example, and no support for transactions. It essentially a slight step up from a key-value store. Interactions that require complicated queries need to go through other services such as ElasticSearch.

But there are benefits. One is that many apps simply don't need very complicated schemas. Another is that this sort of model forces you to optimize the schema in such a way that you avoid complicated joins. Thirdly, it's easy to integrate with a security system. Overall, it's just stupidly simple to get started. No setup, just start posting stuff.

However, we do see the need for a richer data store. A colleague mine is developing a new data store that is optimized for graph-like structures (probably layered on top of OrientDB), which may end up being a replacement for the current store because content can also benefit from being graph-like; blog posts have authors, for example. Another thing we have noticed is that the lack of schema validation leads to discrepancies, and it would be good to have this.

I actually believe rendering the presentation layer on the server side is preferable as it first off is (at this date) cheaper and it also allows for much better control over the presentation. Sending static content to the client is imho much more desirable than doing any kind of logic on the client side, potentially introducing more vulnerabilities.

I don't really get the whole hype about microservices and thick clients. Most use cases for microservices i've seen end up as a fragmented and hard-to-deploy collections of applications that benefit very little from the decoupling. Building out API based communications between apps instead of using an actual database leads to new and silly problems, especially related to transactional data and so on.

I've yet to come across a convincing example of why splitting your average webapp into microservices is a good idea, or why using repository pattern for persistence allows you to write much better code. I think it doesn't matter which kind of framework or tools you are using, its up to you, the engineer, to write decoupled code in a way that you want. I think that a lot of engineers are not able to do that properly, and they are looking for tools or guidance that would somehow solve the problem for them (like the whole MongoDB and designing proper schemas thing was at some point).