API-led development is a mindset that takes control away from the application and hands it back to the developer. It used to be that the application defined the bulk of the requirements. UI, platform, migration, future-proofing, deployment and lifecycle. By thinking API-first, a lot of that simply goes away.
The web has been in a constant state of evolution since its inception. Think of early HTML markup, the arrival of CSS, the development of Java and JavaScript.
We have seen countless different and (sometimes) better ways of doing things, and varying approaches to solving a problem, some of them game-changing and others not so great. (Remember table-based layouts for websites, and the single-pixel gif? I do!)
CSS was a way of separating style from structure. Non-synergetic CGI languages like Perl were slowly supplanted by markup-based languages like CFML and php, and in turn, these have also evolved as requirements, resources and expectations changed.
Evolution can be a tricky thing, though. In nature, when the environment changes, those who live within it must likewise adapt or face the possibility of extinction. The same holds true in the realm of web development - whether you are a designer or programmer, UX tester or systems administrator - and the requirement to "adapt or die" is just as real. We can find niches to hide in for a while, but eventually, we must all look beyond the familiar, and the safe. Like our technology, our thinking must also evolve.
At a conference I recently attended, I heard a speaker give what was possibly the worst definition of the differences between a "leader" and a "follower". In his mind, a leader invents, blazes trails, goes where nobody else has dared to, while all the rest are followers. Posh. What this describes is an inventor, and they are as mighty as they are rare.
It's not stagnation, so much as resistance to breaking something that doesn't need fixing.
A leader, I think, is somebody who recognizes change is coming, or needed, and acts to implement or adapt to it. We've all done this, pushed ourselves out of our comfort zones, let ourselves be a little less efficient for a while, with a look to the long view. This is leadership, introducing change not because there is no choice, but because there is a better one.
Following isn't much different, seeing people adopt a trend (for example, switching from vanilla CSS to using frameworks like Bootstrap or preprocessors like SaaS) and following along because it's the way the industry is trending - not because you want to, but because you feel you must.
It's hard, though, recognizing change, and seeing what's important. That's why it's often easier to follow rather than lead.
Why should you care about containerization? Because it removes a huge number of headaches we normally associate with managing and deploying a project.
We don't see the benefits, we're afraid of failure, we're comfortable where we are. It's not stagnation, so much as resistance to breaking something that doesn't need fixing. But that's not always healthy.
For example, let's look at two very important modern trends in development:
Containerization has been around for a while in various iterations. It grew out of the concepts of virtualization like VMWare, which provides isolated operating environments, and repositories on code management and version control services such as Git or Bitbucket.
Modern containerization, such as that provided by Docker, combines these ideas (and a few others) into a framework that allows entire project infrastructure, from the development stack (SQL server, web server, code engine, etc.) to the code itself, to be packaged into a single entity.
Why should you care about containerization? Because it removes a huge number of headaches we normally associate with managing and deploying a project.
How long does it take you to spin up a local development environment for a brand new project? If you have to move that project to a new computer, or have multiple people working on the project, how are their varying workflow and local environments going to affect the project? And then there's managing change (for instance, moving to a new SQL server), deployment (testing first, then production), and updates (to any part of the stack). All of these environment difficulties vanish in the world of containers, and these are only the smallest, most obvious benefits.
We've been doing APIs for years and years. Even before the web there were things like COM objects, those black boxes of functionality where we could send requests and get back … something.
API-led development also simplifies things. It makes managing code easier, and makes managing the front end applications easier too.
The problem is, these APIs have traditionally been embedded within heavy infrastructure, making them unavailable to anything but the wrapper they live within, so that the wrapping application contained an equal share of the overall functionality. This created cathedral-like monoliths that were devastatingly difficult to manage, dependencies that were all but invisible, and functional spaghetti that wrapped around itself so tightly we couldn't tell where one thing began and the other ended.
API-led development means business. It means separating all of the functionality into self-contained modules that are addressed in a very specific, often contextual manner. The functionality they provide is also very specific to their design. A data API will not render content, for instance. The biggest advantage to this is that any front-end "view" tier, such as a web page or mobile application, can access the API in the same way. The API doesn't care where a request comes from, it just listens and responds, according to specified parameters.
API-led development also simplifies things. It makes managing code easier, and makes managing the front end applications easier too. It makes adapting to whatever future consumers (VR headsets, and onwards towards those 2050 cybernetic implants) a moot "it's already done" challenge to solve.
Containerization and API-led development are the future. Evolving towards both of these new ways of doing things will require a bit of patience, and comes at a small cost in productivity, but the short- and long-term gains are huge.
The most important thing to remember, is they don't all have to come at once! Your evolution towards these things can be slow, and you will reap immediate benefits, so that eventually they will become second nature and all of their gifts will be yours for the taking.
We'll explore all of this and more in future blog posts and this upcoming webinar .
Mura 7.1 Documentation: docs.getmura.com/v7-1/
Related In Flow Blog Posts:
getmura.com/blog/evolve-your-game-the-api-led-path-to-development-freedom/
getmura.com/blog/super-fast-application-development-with-mura-7/