Building Performant Solutions in Nextworld

Nextworld Platform How Tos
1

Building performant solutions on Nextworld isn’t just about speed; it directly impacts your customers’ experience, your solution’s scalability, and your reputation as a partner. Use this post as a reference during design and before go-live.

Tip #1: Clean Code in Logic Blocks

  • Keep each logic block focused on a single purpose.
  • Reuse logic instead of recreating it — avoid doing the same thing in multiple logic blocks.
  • Use inputs & outputs to reduce extra data fetching.
  • Every action should serve a real purpose and be executed in the right order. Unneeded actions slow things down, especially in reports.

:light_bulb: See the Logic Block Performance Best Practices article in NW Help for more.

Tip #2: Fetch Smarter, Not Harder

  • Use filtering criteria to get only the data you need — avoid long-running fetches.
  • Use Limit=n when applicable. Fetching only what’s needed is much faster than fetching everything. See Limits on fetches vs performance Community post for additional information on this topic.
  • Apply filters on the fetch, not inside the loop. Use Exit Loop when the data you need is found.
  • Only sort when your logic requires it (e.g., group-breaking logic).
  • Align index order with your logic flow for large datasets.

:light_bulb: See the Fetch Performance Best Practices article in NW Help for more.

Tip #3: Avoid Logic Blocks Over Header/Detail Tables

Unless your logic block is called directly by the UI, build over Header and/or Detail tables:

  • Add header/detail tables as inputs/outputs
  • Fetch detail records in a child logic block

Tip #4: NATE Considerations

  • Design logic blocks to run with and without NATE.
  • Use NATE for background processing only when necessary (e.g., background logic blocks and workflow definitions).
  • Consider Fetch Records instead of Fetch Detail Records for detail tables — Fetch Detail Records incurs extra updates to the header record. If using Fetch Records on a detail table, include the nwHeaderId filter expression and add an explicit Update Record.

Design-Time Performance Checklist

Table Fetches

  • Will data accumulate over time? If so, what’s your plan for purging it?
  • How fast does the feature need to work?
  • What guardrails are needed? (e.g., preventing the generation of a 3.7 million-page report PDF)
  • Are you fetching the minimum number of rows necessary?
  • Are you looping over the same data more than once?
  • Can you use Limit 1 on your fetches? Is a sort absolutely necessary?
  • Are you validating in the appropriate place — and no more than necessary?

Workflow

  • Could any Automatic transitions be moved to Logic Block-controlled transitions?
  • Do you have long-running logic in a workflow transition that should move to a background task?

Job Queue / Processing

  • How many transactions will this push to the job queue in a short amount of time?
  • Should you enable Asynchronous Processing for large transactions?
  • Are all inline validations necessary?

Performance Testing

  1. Identify key areas — Where do speed and efficiency really matter in your solution?
  2. Set goals — Define response time targets and throughput expectations.
  3. Establish baselines — Test with realistic data volumes using integrations (e.g., Excel uploads) or API imports (Postman / Python scripts). Use Application Monitoring to execute tests and analyze counts and times.
  4. Optimize — Apply the tips above and reference additional resources in NW Help.

Testing Prep Questions

  • How many records need to be processed per second/minute?
  • How many records will be in the tables the feature queries?
  • Which parts of your design should be tested with Application Monitoring?
  • What should your test data look like?
  • Which tables will be fetched, updated, or inserted — and how many of each?
1 Like