Serverless Backend Generation: Using a Generic CRUD Layer to Eliminate Traditional Backend Development

The author, Yuan Xinyu, a Ph.D. from Zhejiang University, shares a "no‑backend" approach adopted for a high‑availability online pharmacy project, aiming to reduce backend effort by generating code from a generic CRUD layer.

Faced with a lack of backend developers and the need to comply with GSP regulations, the team chose REST over RPC and GraphQL because of its abundant code‑generation tools and lower learning curve.

Standard RESTful CRUD conventions are outlined (GET list, POST create, PUT update, GET item, DELETE delete) and the limitations of plain REST for batch, pagination, sorting, and related‑table operations are discussed.

To address these gaps, the author proposes extensions:

Batch create, update, and delete operations with dedicated URLs (e.g., /table_name/batch_update) and JSON payload formats for single and multiple records.

Enhanced query syntax using parameters such as s[field]=value, s[like[field]]=value, s[date[field]]=value, s[range[field]]=value, s[in[field]]=value, and s[cmp[field,field]] to support precise, fuzzy, range, and comparison queries.

Pagination ( page, per), sorting ( order), and count ( count) that can be combined freely.

Foreign‑key queries using dot notation (e.g., s[company.name]=test) and the ability to retrieve related parent or child records via a many=table1,table2 parameter.

Cascading create and delete for master‑detail tables, with JSON structures that include both the master record and an array of child records.

Database naming follows Rails conventions (plural table names, id primary key, table_name_id foreign keys) and adds project‑specific rules for multiple foreign keys and cross‑database references.

Associations are inferred from naming patterns, supporting one‑to‑many relationships; the discovered relationships are serialized into belongs.yaml and many.yaml for runtime loading.

The code‑generation pipeline reuses Rails scaffolding to provide:

Basic CRUD for each table.

Single‑table query handling by injecting where clauses based on the extended query parameters.

Batch CUD operations implemented via loops over individual record logic.

Association‑aware CRUD, including validation of foreign keys.

Join‑based queries for related tables.

Startup modifications for eager loading, JSON validation, and multi‑database configuration.

The article concludes with a Q&A covering the nature of REST, comparisons with SOAP/XML‑RPC, Java equivalents, performance considerations for the extended API, and deployment configuration (database YAML files, environment‑specific settings, and optional Memcache).