The local and server-side demos are essentially the same except one is performed locally, the other is performed via a server-side workflow action. The output destination for each demo is the multiline field on the page. Nothing is saved to the database in the demo.
I’ve modified the demo page for clarity and make them more similar to each other so its clearer what the intent is. I renamed the confusing state that was called ‘initial JSON’ to just ‘JSON’ which is the both the source and the destination of the JSON for each workflow,.
The demo is built this way is on purpose and demonstrates how you can read from and write to the same JSON object using the same workflow action step, by simply modifying the read parameter,
What type of action (server or local) should you use?
Local JSON step to work with JSON client-side (such as saving a bunch of user data to a page state (or local storage). You could then ship that data to the database one time based on an action. thus saving a bit on sever overhead constantly writing to the DB.
Server-side actions would typically be associated with API workflows. So if you need to work with JSON on a recurring basis or as part of a multi-step API workflow to help speed up page responsiveness.
Side note about server-side
All bubble server-side actions (including this one) have a nice benefit of simplicity in how they are configured in workflows. This is because subsequent workflow steps after the action has completed have the ‘result of step x’ available to them and you can select the JSON output from the plugin in subsequent steps. The downside of building your workflows this way with client-side workflows is that you tie up your server resources and must wait for the step to complete on the server. You’ll notice that the demo takes a moment to complete because of this.
Take a look and compare how client-side and server side actions work with subsequent steps after the JSON machine action has completed. You can then save your data to the DB after this.