Location>code7788 >text

SaaS Architecture: Open Platform Architecture Design

Popularity：508 ℃/2024-10-12 14:45:08

Hello, I'm Master Tang~

Today we talk about open platform architecture design.

Why you need to build an open platform

Enhanced product capabilities

The open platform enables three-way developers and partners to develop new applications or services and increase the capabilities of the original SaaS product. This allows more user needs to be met, thus increasing user satisfaction and stickiness.

Promoting innovation

Three-way developers are able to build on the standard SaaS offerings to create new solutions and bring innovative business models to the platform, all of which may lead to more profitable opportunities for SaaS companies.

Building ecosystems

The open platform enables the establishment of an ecosystem centered on SaaS standard products, attracting developers, partners and other interested parties to participate in building a mutually beneficial ecosystem.

Reduced development and operating costs

By inviting three-party developers to create and extend product capabilities, they can effectively share the development and operational costs of SaaS companies and focus more on core product optimization and innovation.

Who does the Open Platform serve?

Open platforms for SaaS companies typically include the following key user roles:

Third party developers

They expect to quickly onboard the open platform and build apps to gain revenue from users subscribing to the apps. Therefore, they need API documentation, SDK tools, and developer backend to help developers build, test, and deploy applications, and utilize platform resources to promote their applications.

Customized Customer

Customized customers are generally enterprise customers with self-research capabilities, with customized functional requirements, such as connecting with internal systems (e.g. ERP, CRM) to realize the enterprise's own business processes.

Platform Operator

Platform operators need to serve three-party openers and enterprise customers and help them solve problems, so they need customer management, application application process management, service configuration, parameter configuration, role assignment, financial reconciliation management and other product capabilities.

Open Platform Operation Process

The operation process of the SaaS open platform involves the management and maintenance of the platform, providing services to enterprise customers and three-party developers, including attracting and managing three-party developers, providing the necessary development tools and support, reviewing and managing the applications created by the developers, evaluating the health of the platform and the activity of the users through data monitoring and analyzing, ensuring the provision of effective service support, and maintaining the security and compliance of the platform. Compliance.

The following figure shows the overall operation flow of the open platform, and the actual open platform project can make changes based on this flow.

Open Platform Overall Architecture Design

management back office

Layers provide different management backends for different roles:

  • Developer backend: a workbench for three-way developers, including application management, API access, development tools, data analysis and testing tools.
  • Platform operation backstage: a workbench for the platform operation team to manage the whole system, including customer management, authority control, billing management, system monitoring and other functions.
  • Merchant Backend: The backend system for SaaS enterprise customers, mainly used for subscribing to the three-party applications of the application marketplace, authorizing the applications, and using the service capabilities provided by them.

service layer

The service layer provides core service capabilities for the upper management backend:

  • Developer Access: Provide API documentation, SDK tools, development guides, registration and management of applications.
  • Operation management: including platform user information management, permission settings, user profile management. Audit the applications submitted by developers to ensure the quality and safety of applications. Manage platform billing and settlement, collect and analyze platform operation data.
  • Monitoring Center: Includes server, application, network, database, security, middleware and storage monitoring. These functions ensure the stability, performance and security of the open platform, and support effective management and maintenance by the technical team through real-time monitoring and alerts.

API Gateway

The API gateway is the traffic portal for the entire open platform, and the capabilities it provides ensure secure, stable and efficient management of the platform's operations.

Business openness capabilities

Business open capabilities are provided by individual business domain systems that provide the ability to interact with core business data/functionality.

Open Capability Design

Open capabilities can be categorized into the following types:

  • Front-end extension: developers can create personalized front-end H5/small program pages to meet the needs of enterprise customers in different scenarios of different industries.
  • API Interface/Message Push: API interface allows developers to interact with the platform system through defined interfaces to realize data and function integration, such as product creation interface. Message push refers to the platform system actively notifying the three-party system, such as order status change notification.
  • Back-end extensions: developers can freely embed custom process nodes to build personalized business logic through extension points.
  • Data Model Extension: Allows the data model of the three parties' systems to be integrated into the platform system, where the data of the three parties can be viewed or processed in the platform system.

Take the commodity system as an example and list the usage scenarios of different types of open capabilities:

  • Front-end extensions: page cascading, customized merchant detail components, customized product details, customized B-side management pages.
  • API Interface/Message Push: Commodity Release Interface, Synchronized Store Interface, Query Commodity Detail Interface, Commodity Price Modification Interface, Commodity Modification Interface, Commodity Attribute Interface, Commodity Up and Down Interface, Commodity Category Interface, Commodity Creation Message, Commodity Change Message.
  • Back-end extensions: commodity verification class extension points (e.g., when the commodity is created, verify that the commodity code meets the specifications of the customization requirements), and extension points for calculating the customized information of the commodity (e.g., calculate the weight information of the commodity through an external interface).
  • Data Model Extension: The commodity model extends and stores personalized field information.

Open API Design Principles

RESTful style API

RESTful APIs are a way of designing APIs that follow the principles of REST, a set of constraints and principles proposed by Roy Fielding in his PhD thesis in 2000.

The design of the RESTful API relies on network protocols, primarily HTTP, and it uses HTTP's native features (such as HTTP verbs and status codes) to perform operations. Here are some of the key features of RESTful APIs:

  • Resource-Oriented: In the REST architecture, all content is considered a "resource" and each "resource" has a unique URI (Uniform Resource Identifier).
  • Stateless: The RESTful API does not save state, which means that each request should contain the information needed to execute the request. The server does not save any information from the client.
  • Unified Interface: RESTful API should have a unified interface, client and server interact based on the interface to achieve decoupling. Interaction is usually realized through HTTP verbs, such as GET (get resource), POST (create resource), PUT (update resource), DELETE (delete resource).

The three significant advantages of RESTful APIs are as follows:

  • It is built on the HTTP protocol, the protocol is simple and easy to use, and has been widely used.
  • The interface design is resource-centered, making the interface easy to understand and use, and more intuitive.
  • Data exchange is in XML or JSON format, which greatly simplifies the process of data processing and transmission.

However, strictly following the RESTful API style has some drawbacks:

HTTP protocol with restricted verbs

When business requirements become complex, relying only on HTTP's verbose methods to operate on resources may not be sufficient, and further differentiation by interface name is often required. In addition, some specific HTTP requests, such as PUT and DELETE, may be intercepted by certain firewall devices during network transmission.

URL contains parameters, poor readability

Embedding parameter placeholders in the URL (e.g. GET /Api/Orders/{id}/OrderItems/{id}) reduces its readability. If you need to count the number of calls to the interface based on the URL, you need to do additional processing for different parameters with the same URL.

Poor expressiveness of HTTP status codes

Using standard HTTP status codes such as 20X, 30X, 4XX, 5XX, etc. is not sufficient to describe the status of complex business scenarios.

It is recommended that the interface design follow the guidelines below:

  • Limit the use of HTTP methods to GET and POST only.
  • Avoid including parameter placeholders in the URL, and try to use the URL's parameter passes as much as possible.
  • Use custom business status codes to provide richer response information.

API Grouping Principles

Open APIs are grouped according to business areas. For example, Store API, Product API, Inventory API, Order API, Logistics API, Customer API, Marketing API.

SaaS standard products are generally based on DDD for architectural design, and it is a commonly adopted best practice to organize open APIs based on business domains. When there is a need to improve or change the functionality of a specific business domain, developers can directly find the relevant API group to make changes without affecting the APIs of other domains.

For three-way developers, it's easier to find APIs related to a particular business function because they are logically organized through the division of business domains.

version management

In order to uniformly and clearly identify different versions of the same interface, it is recommended that the version number be placed at the end of the interface path, as exemplified in the following:

  • Older version:/item/create_item
  • New Version:/item/create_item/v2

Return data

The response data for each interface shall follow a uniform JSON or XML format specification and shall contain at least the following key fields:

  • Code: Indicates the overall result of the request, usually used to identify the success or exception status of an operation.
  • Message (msg): Provides a detailed description of the status code to help understand the specific outcome of the request.
  • Data: Contains business-specific information and data relevant to the request.
{
"code":200,
"msg": "OK",
"data":{
"item_id": "123456",
"product_name": "Cream Cake"
}
}

security measure

interface signature

Assign AccessKey (developer identification to ensure uniqueness) and SecretKey (for interface encryption to ensure that it is not easily exhaustible and the generation algorithm is not easily guessed) to the developer.

Arrange the non-empty request parameters (including AccessKey) in ascending alphabetical order by request parameter name, and splice them into the string A using the URL key-value pair format (i.e., key1=value1&key2=value2...).

String B is obtained by splicing Secretkey at the end of string A.

Perform MD5 operation on string B to get Sign value. The request carries the parameters AccessKey and Sign, and can only be released if it has a legitimate identity AccessKey and a correct signature Sign. This solves the problem of authentication and parameter tampering, even if the request parameters are hijacked, due to the failure to obtain the SecretKey (used only for local encryption, not involved in network transmission), you can not forge a legitimate request.

data encryption

Sensitive data, such as user information, should be protected using encryption algorithms, commonly used encryption methods include RSA and AES.

access control

At the API gateway accessed by the interface, access control should be set up to allow requests only from the whitelist authorized by the merchant. Merchants can manage their whitelist autonomously through the merchant backend system.

push message

Message push is a mechanism by which the platform proactively notifies the three-party system to provide data updates to satisfy the three-party system's need for real-time information. For example, when a merchant successfully creates an order, the three-party system can obtain the current status of the order through the order query interface.

If the three-party system wants to get the order status in real time, it can choose the timed query interface, but this is inefficient and consumes a lot of resources. This problem can be effectively solved by actively pushing order status information through the system. However, message pushing also brings some challenges:

  • Sequential issues: Orders may go through multiple states, and these states have a specific order in the business. Network delays may cause the statuses to arrive at the three-party system in the wrong order, at which point the three-party system needs to ensure the accuracy of the order statuses by verifying the order statuses and determining whether the changes are in line with the business logic.
  • Message Loss Risk: The current system usually uses message queues to send messages asynchronously to push, and despite the mechanism of message middleware to ensure the reliability of messages, network problems in the three-party system may still lead to push failure. Solution: The three-party system can periodically query the order status in full, and perform reconciliation processing on the bilateral order status to ensure the integrity of the data.

This article has been featured on, my tech site: Inside there are, algorithm Leetcode detailed explanation, interviews eight stock text, BAT interview questions, resume templates, architecture design, and other experience sharing.

<Previous Next>