Lotus, a web framework for Ruby

Sinatra is the perfect REST API server language for a client application. Given the way apps are going these days, I'm not sure why everyone isn't building single-page web apps that put 90% of the responsibility on the client and use only simple JSON communications with the server for persistence or authentication.

Sure. I have been thinking about writing up a blog post about our work since it may be of use to others. A quick summary of some of our current microservices:

- Single sign-on. We have a service that abstracts users into identities that map to one or more actual logins. It facilitates the OAuth interaction with providers. To add login in any app, you just redirect the browser to the microservice's /auth/:provider API; it redirects through FB or whatever.

- For sites that don't want to rely on providers like FB, we also have a simple OAuth provider that has a basic user database with salted passwords, email/password management, etc.

- Data store. We have a structured, hierarchical document-oriented data store that is a thin layer on top of PostgreSQL. Most apps don't have their own database, but use this data store.

- Security. We have a common, path-based security model across apps that can be validated through calls into a central security microservice; it's mostly a registry of what apps delegate responsibility, and when you ask the security service about whether, say, you're allowed to modify the object at path acmecorp.blogapp.posts.1, it asks every app that is registered to be the authority for that path. For example, acmecorp.blogapp might use a role-based security system, but a different path exampleinc.cmsapp might use LDAP.

- Voting. For Reddit-style voting and kudos we have a small microservice.

- Search. We wrap our data store in an indexing system that uses ElasticSearch.

- Organizational management. We have a microservice that handles members, groups and their roles. It plugs into the security system so that we can delegate access to very precise parts of the system. For example, any user can see comments, only the author can edit a comment, and editors can update anything.

- Email/texting. We have a microservice that abstracts text and email, currently supporting things like Mailgun and Twilio. It allows us to swap out the implementation without the app knowing.

- GIS/map stuff. We have a separate microservices for geocoding and storing GIS features.

- Image/audio/video processing. We have a wrapper around ffmpeg and other tools that processes transcoding requests.

An important piece of the system is the extensive use of pub/sub via RabbitMQ exchanges to asynchronously publish and listen to events. For example, any microservice can listen to changes to any part of the data store (based on path or event). For example, our search microservice automatically populates ElasticSearch with content from the data store.

Lastly, every app has a microservice as its own backend; for example, if the app is a blog system, we have a frontend (eg., a Node.js desktop/mobile web UI), and a separate backend tailored to that frontend; the frontend treats the backend like any other microservice.

It's not "completely" silly at all. For "normal" users, it's true that they may never need to do this. It's also a largely "safe" assumption that your site's visitors will have JavaScript enabled.

However there are security concerns when dealing with JavaScript. For example, if you've ever surfed the darknet, disabling JavaScript is highly recommended to avoid present and future exploits that could compromise your anonymity, funds, etc.

> If you look closely, rendering presentation layer on the server side and then sending it to the client is a hack and we've been doing it for a long time. It's time for changes.

From the view/presentation layer's perspective, it shouldn't matter where the rendering happens, and as a programmer working on these systems I'm tired of baking assumptions about the data layer into the view layer.

I actually think there's a best-of-both-worlds solution that we'll converge on at some point, which is this:

We have the option of rendering in both locations with the same code.

This allows the initial render to be offloaded to the server (so that the app's initial state is totally established and can be sent along with the app itself in a single HTTP request), and then subsequent rendering updates could happen mostly client-side (fetching only the raw data from the server where necessary).

This allows the JS-everywhere crowd to build their entire app as if all logic is running in-browser (with only a basic API on the server), but it appeases the more old-fashioned developers who want to be able to construct mappings between URLs and actual HTML documents (that don't have to be spun up and re-constructed using client-side scripting). There's obviously a huge debate here as to whether or not the latter is worth it, but I'd say it would be nice if only so that I don't need to have a flash of unloaded content or a "loading" indicator before the app is ready to be used.

I also don't like having to use PhantomJS to scrape data from a website that could very easily consist of HTML documents instead of a blob of JS, but that's probably not enough to affect most people's opinions.