Skip to content

Node Service Recalculation ​

Use this pattern when a server-side Node service accepts an uploaded or internally generated workbook, recalculates it, and returns either values, diagnostics, or a saved workbook. Choose Native Node when deployment can build or stage a platform binary from the source tree; choose WASM when portability matters more than native throughput.

Pick the runtime by deployment

Native Node avoids copying workbook bytes into the WASM heap, but it needs a .node binary built from packages/npm-native for each target platform. WASM deploys the same way on every Node environment. Formula results should match; a difference is a bug or a documented compatibility gap.

Flow ​

01HTTP upload / internaljobUploaded or generatedworkbook02ValidateByte-size policy beforeloading03Load bytesCell-count policy afterloading04Set inputs and profileProfile such as win-365-en_US05recalc()Check the status beforereading06Read checks and valuesValues and diagnostics07RespondJSON, or a saved workbook01HTTP upload / internal jobUploaded or generated workbook02ValidateByte-size policy before loading03Load bytesCell-count policy after loading04Set inputs and profileProfile such as win-365-en_US05recalc()Check the status before reading06Read checks and valuesValues and diagnostics07RespondJSON, or a saved workbook
The service boundary enforces size and cell-count limits and pins the profile, so a recalculation is reproducible.

Runtime choice ​

ConstraintPrefer
Large workbooks, high request volume, controlled deploymentNative Node
Serverless or portable Node deploymentWASM
Same code path as browser uploadWASM
Avoid building/staging a platform-specific native binary todayWASM
Can this deployment build or stage a .node binary today?@libraz/formulon-nativeYes. Built from source per platform@libraz/formulonNo. Same on every NodeenvironmentCan this deployment build or stage a .node binary today?@libraz/formulon-nativeYes. Built from source per platform@libraz/formulonNo. Same on every Node environment
Choose Native Node only when the deployment can supply the binary; formula results should match either way.

Native Node and WASM share the core calculation flow, but their Workbook method sets differ. Check the Surface matrix before choosing a binding for table authoring, AutoFilter XML, or addCellStyleXf; typed AutoFilters and setCellStyle are available on both. The Native Node integration page shows status checks and explicit disposal for the service path.

Service boundary ​

At the API boundary, make the conditions for reproducible recalculation explicit:

  • reject files that exceed the byte-size policy before loading, then enforce the cell-count policy after loading;
  • pin the engine version and compatibility profile, for example win-365-en_US (the default);
  • control volatile inputs such as the clock and random values when reproducible output is required;
  • separate host failures from cell-level Excel errors;
  • keep the original bytes until save() succeeds;
  • decide how to handle unavailable service functions before accepting production traffic.

Compatibility gate ​

Not every Microsoft 365 function can execute inside a Node service. Formulon has 511 real implementations among 526 recognized names, including state-dependent CELL and INFO. Functions that need external services or live connections, including COPILOT, PY, IMAGE, WEBSERVICE, STOCKHISTORY, RTD, and CUBE functions, are recognized but return deterministic unavailable errors.

For user-uploaded workbooks, surface this as a workbook compatibility issue. For internal templates, fail CI when those functions appear in the formula snapshot unless an explicit exception exists.

Operational checks ​

  • Put recalculation behind request timeouts and queue limits.
  • Log the Formulon version, profile, workbook fingerprint, and failure class.
  • Snapshot representative templates in CI before upgrading Formulon.
  • Compare important templates against Excel-derived fixtures when patch releases mention formula or file-format behavior changes.