The front-end is the new back-end?
Nine months ago I wrote about a service called Firebase which hinted at eliminating the need for a server-side application in your product’s software set-up. This is a bit hard to digest for most programmers, especially since the back-end of your software architecture is usually considered to be the “application” itself. But let’s examine why you need server-side applications in your services. Is it because you need a “catch all requests” funnel? Ultimately, network requests from the client are destined to interact with the database; but since the database often lives separate from the application, it almost seems that a system which employs “more direct lines” from the clients, straight to the database, could make more sense. So what do we need the server-side application for?
Surprisingly for some, the answer has less to do with the business logic, and more to do with code security, processing power, and guaranteed abilities of the machine running the code. In theory you could have the front-end connect straight to the database. You would need to write all of your business logic and execute it from each client to achieve this. Of course, you would then need to rely on a cacheing system also implemented on the client to get fast results. A cacheing system on the client? Hey, that might actually be a good idea if you coupled it with database-level cacheing somehow. However, the real problem is that your business logic now lives on the front-end, which means your business code can now be exposed to the public. This also means that the “code secrets” you use to access your database (like connection strings, and passwords) can be compromised. Ouch. Furthermore, expecting every client that runs your code to have the proper processing abilities and device capabilities is just not reasonable.
But before you close the book on this topic, consider this presentation I saw by Martin Gontovnikas (@mgonto) on webtasks, as food for thought: He wanted to hook up his new application-less website to a back-end, but didn’t want to actually have to go through the pains of creating a back-end application server. So he and his team came up with a way to keep the node.js code in the browser: To achieve this, you have to move the business logic of the application to the front-end. Having removed it from the back-end, you still have the main processing power and operating system left behind. So now all you need to do is create a very small code runner that could live in an application container on the back-end, which could receive code to run via requests and output a response. You could deploy it using docker, a platform for distributing apps using “containers” that live in a single OS instance. This of course raises many questions:
Does this mean code has to be sent from the front-end to the back-end on every request? No it doesn’t it. In fact you would actually only send a URL of the code down to the back-end code runner, which would then retrieve the code, cached from a CDN.
But what if some bad guy tries to run some code on the code runner after recovering some URLs from the front-end? To get around this, the server has to generate an encrypted JSON web token via a special endpoint, to be used by the front-end every time it tries to send code to the back-end code-runner.
Finally, is doing all of this really saving me any time or effort? If you utilize an already existing code runner, then the answer is a definite yes! In fact, the site http://webtask.io was created for this very purpose! Again, like Firebase, we see another opportunity for third-party services to provide all of your back-end needs for you; however, using web task code runners, you can still write your own back-end logic without the need of actually creating a back-end application! Now let that sink in for a minute…
