OK, here goes. I'm not saying that we made the right choice all over, but this is what we currently have:
For the API we use ServiceStack (v3, because v4 is paid and has a ridiculously high license fee). It is the best-designed REST API library I've ever seen, in any language. Its focus on data and not on verbs makes it easy to build well-designed APIs and difficult to build crappy ones.
The API is the executable, self-hosting an HTTP server (using ServiceStack's support for the .NET HttpListener). We'll probably switch to FastCGI soon. In any case, we have an Nginx in front to serve all static assets, which proxies API calls through to our API.
The database layer is very lean: we rely heavily on Postgres stored procedures for much of our data logic. This way, we avoid a lot of roundtrips to the DB and back. We go as far as using Postgres's multiple cursor feature to return hierarchical data without repeating lots of data in a giant single JOIN. We then use C# to tie the pieces back together (e.g. imagine a blog example, if we'd have a query for certain posts AND their top 5 comments, we'd get one cursor for posts and one for all comments, in order, and then we tie each post to a set of comments in C#-o-world while mapping it to DTOs).
The queried data goes from what the stored procedures return straight into the DTOs that ServiceStack returns, so we have no "domain model" class structure or a heavy weight ORM. We use Dapper for easily mapping stuff to simple classes.
We insert/update data with ServiceStack.OrmLite - just simply adding rows. Often, an API DTO matches a DB table close enough that this just works without any extra mapping.
I general, we're convinced that heavy-weight ORMs don't make sense for backends which are little more than data-stores for single-page web apps.
We manage DB schema changes (and all stored procedures) using hand-written SQL scripts, much like how the Play framework does this (1.sql for the initial DB, 2.sql for changes since v1, etc). This works amazingly great, and gives us far greater control than any ORM ever gave me.
We host it all with Docker containers: one for the DB data (Docker's "data-only container" pattern), one for Postgres itself, one for the backend (running Mono 3.2.something on ubuntu 14.04), one for Nginx, and one for our static assets (so we can redeploy frontend code without restarting the nginx container). Currently, we're host it all at http://orchardup.com but we're not too happy with their very slow (but friendly) customer support. Docker has given us a bunch of headaches (for example, that data only container pattern is a lot less easy to set up in practice), but none .NET/Mono related.
Our frontend is a single-page web app, optimized for mobile, built with React and TypeScript.
For the API we use ServiceStack (v3, because v4 is paid and has a ridiculously high license fee). It is the best-designed REST API library I've ever seen, in any language. Its focus on data and not on verbs makes it easy to build well-designed APIs and difficult to build crappy ones.
The API is the executable, self-hosting an HTTP server (using ServiceStack's support for the .NET HttpListener). We'll probably switch to FastCGI soon. In any case, we have an Nginx in front to serve all static assets, which proxies API calls through to our API.
The database layer is very lean: we rely heavily on Postgres stored procedures for much of our data logic. This way, we avoid a lot of roundtrips to the DB and back. We go as far as using Postgres's multiple cursor feature to return hierarchical data without repeating lots of data in a giant single JOIN. We then use C# to tie the pieces back together (e.g. imagine a blog example, if we'd have a query for certain posts AND their top 5 comments, we'd get one cursor for posts and one for all comments, in order, and then we tie each post to a set of comments in C#-o-world while mapping it to DTOs).
The queried data goes from what the stored procedures return straight into the DTOs that ServiceStack returns, so we have no "domain model" class structure or a heavy weight ORM. We use Dapper for easily mapping stuff to simple classes.
We insert/update data with ServiceStack.OrmLite - just simply adding rows. Often, an API DTO matches a DB table close enough that this just works without any extra mapping.
I general, we're convinced that heavy-weight ORMs don't make sense for backends which are little more than data-stores for single-page web apps.
We manage DB schema changes (and all stored procedures) using hand-written SQL scripts, much like how the Play framework does this (1.sql for the initial DB, 2.sql for changes since v1, etc). This works amazingly great, and gives us far greater control than any ORM ever gave me.
We host it all with Docker containers: one for the DB data (Docker's "data-only container" pattern), one for Postgres itself, one for the backend (running Mono 3.2.something on ubuntu 14.04), one for Nginx, and one for our static assets (so we can redeploy frontend code without restarting the nginx container). Currently, we're host it all at http://orchardup.com but we're not too happy with their very slow (but friendly) customer support. Docker has given us a bunch of headaches (for example, that data only container pattern is a lot less easy to set up in practice), but none .NET/Mono related.
Our frontend is a single-page web app, optimized for mobile, built with React and TypeScript.