REST APIs from small, deployable functions
One function per slice of surface area—ship routes without redeploying the whole API.
Situation
Monolith drag
Large apps couple unrelated routes; incidents take longer to bisect.
Scaling the whole binary for one hot endpoint wastes memory.
Why workarounds fail
Microservice sprawl
Too many repos and pipelines also hurt—there is a middle ground.
How Inquir fits
Function per route group
Group routes that change together; keep critical surfaces small.
Share authentication configuration at the gateway layer.
Capabilities
API hygiene
Rate limits
Protect shared dependencies from abuse.
CORS
Configure browser clients explicitly.
Versioning
Use path prefixes before breaking changes.
Steps
How to expose REST APIs from Inquir functions
Design resource map
Prefer nouns and consistent error envelopes.
Implement handlers
Validate input at the boundary.
Load test
Measure concurrency per route, not only aggregate RPS.
Code example
JSON error helper
Consistent errors simplify client SDKs.
export function jsonError(status, code, message) { return { statusCode: status, body: JSON.stringify({ error: { code, message } }) }; }
Fit
Good fit
When to use
- Internal APIs
- Partner integrations
- B2B multi-tenant surfaces
When not to use
- When a framework monolith is already working and team size is tiny
FAQ
FAQ
Can I expose GraphQL from a serverless function?
Yes—a single function can host your schema and resolvers; rate limits, auth, and cold/warm behavior still apply at the gateway.
How small should each REST function be?
Group routes that deploy and fail together; splitting every path into its own function can explode ops noise—find a balance your team can own.
Where do API keys and JWT validation live?
Prefer gateway-level auth hooks where possible so handlers assume already-authenticated context and stay easier to test.