Recently I've been pondering a project idea that I've been wanting to share.
Two tiers — front-end and back-end
A lot of web apps utilize separate servers for front-end and back-end. That's why we have things like CORS, to ensure our apps can make cross-origin requests securely. However, more often than not, the front-end server just serves static assets and webpages, and maybe generates some server-side HTML from backend data to serve on the first load — a process known as hydration.
Personally, I think it would be neat if front-end had some actual logic in it too. Instead of hosting static assets and having the browser contact the backend directly, I want to try and make the front-end a kind of proxy that would make requests to the backend and render both HTML and JSON for frontend JavaScript.
Now, naturally, it would be more than a bit boring if the front-end just proxied the requests unchanged. So I've had a couple ideas what it could do:
- Authentication proxy. All the info about users and permissions can be stored on the front-end, and the back-end would receive a token (for instance, a JWT) with the essential user info. The front-end would have simple cookie auth.
- Translation proxy. I can have front-end API and back-end API as completely different entities, with different protocols and conventions. For instance, I can make a front-end with a simple REST API and use GraphQL on the server. I can use JSON on the front-end, and MessagePack on the back-end. I can even use a message broker like RabbitMQ to communicate between the frontend and the backend!
- Data assembling proxy. One thing I really like when working on an API-only application is that you can make pretty simple APIs. You need to focus only on the relevant data, and not worry about stuff like user data, or relation options for form selects. The front-end can make multiple requests to the back-end in one handler and then present the data nicely for the browser.
- Caching proxy. The proxy could store some data cached for the users and give it back as needed. Not only that, it can have the back-end server call it back once it's updated the data, and the front-end can update its own cache intelligently.
Stack ideas
I really want to implement the back-end in Clojure. I like the language and I feel a bit guilty for discarding it for one of my projects.
The front-end, probably Kotlin? The coroutine framework Ktor fascinates me, and the nature of coroutines & threaded language make them pretty useful for both synchronous and asynchronous data flows.
I intend to use at least some in-browser code… Though I don't really want to use JavaScript. I'd rather look at more refined languages targeting JS, like Elm, Kotlin, Dart or even Clojure.