Discussions about "when to use decoupled architecture are plentiful and important, but it often assumes or ignores another tricky decision: "Where" to decouple. This post will discuss the "Decouple Line" and how moving it around provides some amazing features to your API.
When designing a content API, the assumption is often that decoupling must take the form of an API that matches your data model, where tables in your data store are mapped to resources in your API (think, /author and /posts). This is often helpful and necessary for exposing the raw data that our UIs need, however, in a cross platform scenario where teams are all building similar features, this can lead to a lot of duplicated efforts and discrepancies between the apps. All of these platforms will be writing similar queries, denormalization logic, business logic, and A/B tests, and then finally render the UI with their respective component libraries. This can lead to platform specific bugs, inefficient queries, and design inconsistency across platforms.
Components as Data moves the "decouple line" further toward the frontend to absorb queries, denormalization, business logic, and A/B testing into the backend. In practice, the API serves JSON structured in terms of the tree of UI components that will be used to render the respective data. In doing so, it becomes a quasi frontend in its own right, but it renders JSON instead of HTML or native views. This enables some amazing features:
Simpler, presentational frontends
Centralized business logic
Centralized A/B Testing and Feature Flagging
Design consistency via a "Design Schema"
Finally, this pattern opens the door for writing a cross platform UI library that implements the "design schema" and can be used as the rendering engine for each platform.
Looking for an attractive & user-friendly web developer? HourlyDeveloper.io, a leading web, and mobile app development company, offers web developers for hire through flexible engagement models. You can **[Hire Web...
APIs can be as simple as 1 endpoint for use by 100s of users or as complex as the AWS APIs with 1000s of endpoints and 100s of thousands of users. Building them can mean spending a couple of hours using a low-code platform or months of work using a multitude of tools. Hosting them can be as simple as using one platform that does everything we need or as complex as setting up and managing ingress control, security, caching, failover, metrics, scaling.
With the rapid development in technology, the old ways to do business have changed completely. A lot more advanced and developed ways are ...
You name the business and I will tell you how web development can help you promote your business. If it is a startup or you seeking some...
Measuring website activity provides only half the story. See how to best track the developer's journey and what funnel stages makes sense for API-first products