I recently joined FL0 to help with marketing. I couldn’t be more excited because I started my career as a developer, and my inner developer has been doing a little dance for weeks now. The downside to having been a developer, and a pretty good one if I do say so myself, is I rarely get excited about technology – and it’s really hard to market technology when you’re not interested in using it yourself.
Now, I should continue by writing a few more paragraphs touting my past accomplishments and how great FL0 is (blah, blah, blah). I should, but I won’t. Instead, I’m going to write a few blogs sharing my perspective on backend development and how FL0 is being built to improve it.
Let’s go back to the early 2000s. Note: I wish we were starting in the 90s. Nirvana. GoldenEye on N64. Pulp Fiction. Maybe next time.
Anyways, the first web application I worked on as a developer was a monolith in every way possible. It consisted of 100s of JSPs and servlets. To call it spaghetti code would be way too kind. About a year into it, I introduced the team to MVC and ORM because I wanted development to be easier and faster.
Fast forward several years, and my focus had turned to building RESTful services. I no longer had to worry about the frontend. However, truth be told, the frontend wasn’t completely decoupled yet. It was just a separate module within what were still monolithic applications. Note: This is just before I joined the dark side, became a marketing professional and stopped writing code full time.
I started writing code again earlier this year (I missed it). I ended up building demos and PoCs as microservices. I felt like I was able to move faster because I had a much narrower scope and focus now. I was happy to replace a large application server and countless lines of code with a lightweight runtime and far less code.
Then I came across FL0, and it hit me.
Today’s backend is simply a set of services consumed by different clients, whether they’re browsers, mobile apps or connected devices. In my opinion, everything becomes a lot simpler and a lot clearer when you look at the backend from this perspective. As a backend dev at heart, all I want to do is build services – nothing more, nothing less.
What’s a service?
In the backend, a service is simply a discrete unit of work. It could be a RESTful service. It could be a microservice. It could be both. It could be neither.
A service has three primary building blocks. First, resources such as databases, message queues and other SaaS services. Second, a function such as “create an account”, “add a payment method”, “place an order” and so on. Third, a trigger such as an HTTP request, message delivery and recurring time.
A service is simply a combination of these. It could be an HTTP endpoint on top of a “create order” function which persists orders to a database. It could be a “delivery status update” function that sends a notification to the customer when it receives a message from the shipper provider.
If we agree building a backend is really building a set of services, then we have to ask ourselves a couple of questions.
Should we be using the same tools and processes we did with monolithic apps?
How can we make building and shipping services easier, faster and more enjoyable?
Stay tuned. These are the questions I'll be tackling in my next few posts.