DEV Community: Kevin Swiber

Redefining the 3-Tier Architecture

Kevin Swiber — Mon, 15 Nov 2021 18:06:56 +0000

It's time to sit by the fire, grab some hot cider, and listen to a story. No, this isn't Are You Afraid of the Dark? fan fiction. On second thought... for some us, this is a horror story. 👻 Don't worry. It ends on a good note, with some thoughts on how the API landscape has changed the way we design applications.

Once upon a time, established software principles dictated a very simple model of delivering line of business applications. We called it the 3-tier architecture, a self-describing little thing named before software vendors learned to influence human psychology with buzz words.

3-tier application architecture from the late 1900s.

It made sense, a logical separation of concerns — as we say in design pattern books — and it reflected a big change that was already underway.

Wait, how did we even get here?

Let's take a joyride in the technobabble time machine! Data and logic were once colocated, situated on specialized mainframe hardware, living a blissful life ignoring network partitions... while solving other incredibly difficult problems associated with this architecture. User interfaces were text-based and delivered to the business user via simple teletype terminals. Programming languages — like COBOL — were run close to the data layer — often a relational database like DB2. This was really the start of the thin client pattern.

As time progressed, databases maintained the desire for single-machine consistency and availability. User interfaces were migrating from terminal emulators to more modern desktop (and eventually) Web experiences. This represented a conflict. How do we get mainframe data outside the terminal emulator? Part of this migration path involved moving logic out of the mainframe and into application servers, often with VT100 compatible terminal emulators connecting directly with programming language APIs via libraries.

Okay, wait... isn't all of this very boring? Maybe. But that's a trait associated with line of business applications. Boring is a long-term survival strategy for software architecture. 🙃

Increasingly, logic had to move closer to the client and farther from the data. This brings us to the fundamental desire for the aforementioned 3-tier architecture.

Presentation tier - Consumes logic produced by a Web or application server, carefully crafted to create the ugliest Web sites we've ever seen.
Logic tier - That darn application server. It's really this tier that spawned a new breed of Business Process Management software and integration tooling.
Data tier - Pick a favorite monolithic database: Oracle, MySQL, Microsoft SQL Server. Apologies if some of these names induce anxiety.

Let's hold on to our britches, because we're getting to the good part. Everything has changed.

Scrubbing the timeline a bit, skipping past some difficult years — SOAP vs. XML-RPC, MongoDB vs. CouchDB — let's look at some motivating aspects to the latest cool kid architectures. 😎

From the perspective of a multi-tiered application architecture, our human-facing interfaces are being driven by APIs. Based on Postman's 2021 State of the API Report, 49% of respondents said that more than half of the organization's development effort is spent on APIs. This is astronomical and represents an evolution that's been steadily growing around us.

We have arrived at a place of dumb connectors and smart components with respect to business logic. We are just now ingesting the concept of API-First. There are benefits to putting more smarts in the messages, but that's a different campfire story. 🏕🔥

Application developers are now often specialized in front-end vs. back-end, with a few of us shifting contexts as full-stack developers. In retrospect, this was all inevitable. The success of the medium was indisputable. As a result, the Web got smarter. And we all grew with it.

So what do we do with all these line-of-business applications as we move forward into solving new century problems? Well, as it turns out, API Gateways are the new VT100 terminal emulators. Let's look at how this all fits together, how we've redefined the 3-tier architecture.

Experience tier - Thick clients are all the rage. While our slick, new Web apps don't contain all the business logic, they often contain quite a bit. Decisions are now made in the browser.
Integration tier - We are utilizing API Gateways and iPaaS platforms to facilitate interaction between our new experience tier and the API data sources we've already built over the years. Experience APIs can be pieced together using façade and scatter-gather patterns in the gateway, backed by security, analytics, and message transformation.
Data source tier - CRUD APIs, database connections, message queues... If it can be accessed over the network, it can be accessed by an API Gateway. The database has become an implementation detail. Microservices have fortified this as the new reality.

Logic is now a vertically-oriented concern. Collaboration has never been more critical to achieving success in line-of-business applications. Here are some tips and tricks for how to manage this.

5 Developer Tips for Surviving API-First

Kevin Swiber ・ Nov 11 ・ 5 min read

#api #productivity #architecture #apigateway

We only see more exploration here, as folks look to federation, microservices, and even micro-frontends to achieve a sweet-spot of modularity and centralized data source access when crafting application experiences.

We can even create micro-frontends in Postman now.

Does this resonate? It does for a lot of folks. Again, we are in a time of migration. How long will it last? Well, the VT100 emulators and mainframes are still around, all these years later.

Transient technology, as it turns out, may never die. 🧟

5 Developer Tips for Surviving API-First

Kevin Swiber — Thu, 11 Nov 2021 20:33:43 +0000

The world of API-First has swept developer marketing by storm. With so much information scattered around the Internet — and managers inquiring about the API-First roadmap — a lot of pressure is being applied to squeeze out a reasonable strategy. We're all familiar with that Jeff Bezos memo. Paraphrased:

API all the things or get pelted with rotten tomatoes.

And now this mega-rich guy is taking William Shatner to space. Clearly, it's time to get serious. A lot of us may be thinking, wow, okay, this memo came out in 2002. According to StackOverflow's 2021 Developer Survey, a large number of professional developers were between the ages of 6 and 15 at this time. Y'all were playing with Bratz dolls or looking up GTA: Vice City cheat codes while APIs were being mandated from on high. Don't bring this up to your manager.

Instead, communicate a strategy using these 5 tips!

Know your audience

The first key step in any software project is to find the stakeholders. These are the folks — both business and technical — who will set the game board, make the rules, and let you know if your team is actually winning. Once established, here is a sample of the questions to ask 🕵️:

What do we feel a successful API-First strategy enables?
Which of those benefits is most impactful?
What's motivating an API-First strategy today?

When business stakeholders answer questions, we do not interject with a correction we believe is more technically correct. Let's take this up with our developer compatriots when ironing out the details. This keeps us all out of trouble. 🙏

It may be too early to know in the beginning, but a question to plant in everyone's mind is:

How do we measure success when moving to an API-First strategy?

Let's not leave ourselves out of the equation! As members of the development team, our insight is important here, as well.

Speak the language

Sometimes, we just nod and smile when we don't understand each other. And maybe that's fine if we're video chatting during the awkward networking phase of our favorite virtual API conference. When it comes to building software, finding a common vocabulary is a productivity hack.

In Domain-Driven Design, this is known as the Ubiquitous Language. Domain experts know more about how the business functions, and this creates information asymmetry.

According to Eric Evans:

Translation blunts communication and makes knowledge crunching anemic.

When we're building APIs, we should be mindful of this common language.

Should the property be called state or status?
Is it a soft_delete or an eviction?
Is it a retrospective or a harbinger_of_death?

As we go through this exercise, we will often run into undefined behavior. This is a great opportunity to work together and discover if any shadow processes exist in the business today. Then we can effectively model those workarounds in the API. Beep boop. 🤖

Understand the building blocks

Distributed systems are hard. When we spend time weighing the options, we take a proactive approach to architecture. It takes a lot of practice before we can speed-run our way to victory.

Single Page Apps (SPAs) and APIs are everywhere. They're the de facto standard for new applications. We could just slap together a quick API to turn SQL query results into a JSON payload. Ship it! 🙈

There are more than a couple of elephants hidden in this labyrinth.

Which component owns application state?
What are the trade-offs related to storage, compute, and data transfer?
What are our API consumer use cases?

SPAs are thick clients in a client-server architecture. A common approach is to let the API act as a thin layer over data storage while moving compute to the Web browser and taking on more costs for for data transfer.

Thinking about our consumer use cases, we can make a decision on which properties and trade-offs make the most sense. Where we give control, we give complexity. If we want to delegate much of the control to the thick client, we can look at a solution like GraphQL. The trade-off is pushing query and mutation decisions to every client application. If we want to centralize that complexity on the server side, we can look at patterns such as materialized views.

Whatever decisions we make, let's make them deliberately. Documenting these motivations, system capabilities, and trade-offs can give us a cheat code for the next API-First project. And yes, by the time you're done reading this sentence, the documentation is already out of date. We're still working on that one.

Plan for next steps

Whew. We did it! Spot bonuses all around! jk jk... No matter how fast or slow we move when building software, one thing is always certain: we got it wrong. Either we missed a requirement or the business needs changed or legislation was introduced or... or... The list is never-ending.

Some of us use humor as a defense mechanism. Here are a few ways we can protect our systems without therapy:

What are our scalability vectors?
Where can we find performance opportunities?
How can our APIs evolve?

HTTP is the most successful protocol of its kind. Let's steal from it.

Use the network. Communications move through several network layers. We can take advantage of this, often transparently. API Gateways are proxies that apply security, message transformation, custom routing, and more to centralize policy management.

Figure out a caching strategy. This isn't just part of a terrible whiteboard interview to optimize a search algorithm. HTTP allows caching at the client, the server, and intermediaries. Bust out that Cache-Control header! It's a quick performance win.

API evolution is a big topic. For now, it's good to remember that most JSON parsers are forgiving by default. It's easier to add a field than to remove one. We can take advantage of this. There are also various deprecation signals to evaluate, such as the Sunset header.

Design with intention

There's always room for exploration and improvement, so let's do it collaboratively.

API definitions offer a great medium for discussion (not just automation).

Rapid protyping of APIs is only getting better. We can author an OpenAPI definition, generate a mock server, collaborate on design, and start the next iteration all within the same tool.

Examples of Postman collections generated from API description formats:

Success emerges from a combination of many disciplines working together to solve problems and create opportunities. We should make intention explicit. Look to processes like:

The term API-First can have different meanings to different people. Don't go into the API-First strategy unarmed! To recap:

Know your audience.
Speak the language.
Understand the building blocks.
Plan for next steps.
Design with intention.

Follow these 5 tips, and you'll be the next person to take a trip on that CEO's weird-looking rocket! 🚀✨