We Keep Coding

architecture for get and store api request data

This is more of a architectural questions. An external platform had product and price information for let's say, books. There is an API available to get this information.
What I read is that it should be possible to create a function in Javascript and connect the Javascript to a page where you want to show the data on my own website. This would mean that for each page request an API-call is made. Since the requested information only changes once a day maximum this does not sound the most efficient solution.
Can someone advise a better solution? Something into the direction of a similar php or javascript function that does the request on the background, schedule an update and import the data into mysql? If so, what language would be most common.
I need the solution for a Joomla/php/mysql environment

Here's a simple idea - fetch and store results from the API (ones you think aren't gonna change in a day), either on disk, or in the database, and later use these stored results to retrieve what you otherwise would've fetched from the API.
Since storing anything in frontend JS across page reloads isn't easy, you need to make use of PHP for that. Based on what's given, you seem to have two ways of calling the API:
via the frontend JS (no-go)
via your PHP backend (good-to-go)
Now, you need to make sure your results are synced every (say) 24 hours.
Add a snippet to your PHP code that contains a variable $lastUpdated (or something similar), and assign it the "static" value of the current time (NOT using time()). Now, add a couple of statements to update the stored results if the current time is at least 24 hours greater than $lastUpdated, followed by updating $lastUpdated to current time.
This should give you what you need with one API call per day.
PS: I'm not an expert in PHP, but you can surely figure out the datetime stuff.

It sounds like you need a cache, and you're not the first person to run into that problem - so you probably don't need to reinvent the wheel and build your own.
Look into something like Redis. There's an article on it available here as well: https://www.compose.com/articles/api-caching-with-redis-and-nodejs/

Using WordPress, have dynamic query, want to avoid caching the results

I do not want to turn off caching for a site, but I do want to avoid caching in some areas. Wondering the best way.
First, I pull data from an API to check the "online" status of an advisor.
Next, I store that (and any other data that may change) in a CPT.
At the same time, I store a random string of characters (that I can sort on later giving the appearance of random order).
I pull the data from the API on every page load, because I need real-time data. This makes me cringe, but I don't know any other way. This part isn't cached.
However, when I display the list of "advisors", I sort them by online status, then the random string. This is meant to give fairness as to who is above the fold, and near the beginning of the results.
Well, that is all generated with PHP, so therefore the resultant HTML is cached.
I read a bit about the WP Rest API, and perhaps that will help with the speed of the query, but that won't help with the cached HTML right?
So, regardless of how I query the data (REST API, WP_Query), am I to assume that I must iterate through the data with JavaScript to avoid it being cached by the Full Page Cache solution of the server?
If I use WP_Query still, and I use PHP to display the results, can I just call the PHP function from JavaScript?
Every page of the site will display some or all of the advisors (ex: homepage 8 advisors, the "advisor" page shows all, the "advisor" category pages, and 4 advisors in the footer of every other page), so it doesn't make sense to turn off caching.
Any direction would be greatly appreciated! Thanks in advance.

Are you not better of doing it with AJAX?
Or, I'm pretty sure there's like a line of PHP that you can add to pages so they won't get cached. Woocommerce sometimes needs this for example. I guess it depends on which caching plugin you are using. Which one are you using?
Or, for example WP Super Cache has an area where you can exclude certain pages from caching. Under Settings -> WP super chache -> Advanced -> Accepted Filenames & Rejected URIs.

Define in Smarty the format to be returned by AJAX

I have a html form in a Smarty template. A select in the form is populated via AJAX. I would like to specify in the Smarty template, the format to be returned by the AJAX-call. This way I can use the same request-url for different purposes. For example if the select contains users, sometimes I might be interested in knowing the user's email address (format: "{$Option->GetName()} ({$Option->Email})"), and other times the user's organisation (format: "{$Option->GetName()} ({$Option->Organisation})").
I have a few ideas of how to achieve this:
Store the format in html/js in the template. Then the AJAX-call can send the desired return-format along with the request. Drawback: A malicious user can change the format in the request, which might be a security issue.
Pass along the entire $Option object, and do the formatting using JavaScript. Drawback: Cannot use the PHP object's methods, such as $Option->GetName().
Store the format in a separate template file, and reference to this file in html/js and send along with the AJAX request. Drawback: The reference to the template file can be changed by a malicious user, but probably no damage can be done. This approach requires extra template files, and the presentation logic will be spread over different files.
Create a Smarty plugin that automates the process of item 3. Then the presentation logic will not be separated. Drawback: The reference to the template file can be changed by a malicious user, but probably no damage can be done.
Do anyone have any other/better ideas, or any experience with doing something like this?

I don't think you need to set some format. You can create a javascript function with 3 parameters. The <select> tag identifier, the name of the key used for options value, and the key name used for options text. The function will make the ajax request. That way you can call the function with settings you need for particular situation.
Further details depend on your current code.

I ended up using option 4, and I'm very happy with the result.
If anyone come across this and need information on how I implemented it, just post a comment, and I'll try to explain.

How to show a friendly error message using Open-flash-charts2?

If my JSON data-file comes from a database result set and that result set is empty, how do I tell OFC2 to display an error message, instead of crashing because of a malformed JSON string?

Add tags for javascript and actionscript-3 to this question and you should get a load more views and useful responses than you currently are, with more precise details than I am giving. Post the actual JSON string that is causing you the problem and that you would like to be guarded against. That way people can suggest a regexp to catch it, treating it as a string rather than as JSON data at some point before JSON.decode() happens.
In more detail:
You can catch it in two places. One route is to switch over to using the javascript interface to OFC2 and use client side javascript to detect the bad string. This allows you to modify the JSON string client side. See http://teethgrinder.co.uk/open-flash-chart-2/tutorial-5.php for that approach. One downside is that the clients must have javascript enabled for this to work.
Alternatively, since OFC2 is LGPL, you or an actionscript developer can dive into the OFC2 source code and do the same thing there. I am not an actionscript developer so you are better off ensuring you get a reply from one.
The main thing is to add those two tags to this question. 22 Views is way too low for a question with a bounty of 500. Hope this helps.

Several solution avenues are possible, depending on your level of access to the server and your knowledge of JavaScript and/or any server-side platforms.
With access to database
Depending on the kind of data you are displaying, it might be possible to add dummy records for those queries that would otherwise have returned an empty set. If you have access to the query definition, you may check for the empty set in the DB-query. For example, if you're on MS SQL Server you could check the condition with some T-SQL statements.
With access to server
If you have access to the server side script generating the dataset, add a condition that returns some default value that OFC2 will handle correctly.
With access to another server or serverlocation
If you don't have access to the specific script, you may consider creating a new script at another location that queries the original script and replaces empty results with the default value.
Client-side only
You can add the JavaScript open_flash_chart_data function (see tutorial) to replace empty datasets. OFC2 can use that function as data source.
Hope this helps.

Best practices for returning and displaying data from AJAX calls

I have some jquery/php interaction set up on a page. It submits some data to the server and gets back records of data which are then to be aligned on the page for comparison and possible action beyond that.
My question is what is the best practice for returning the info and then displaying it?
Return JSON object and then create
html on the fly with js and display
the data?
Return JSON object and then
put that data in already created
containers for the data on the page?
Return pure html from the server and
just put that on the page?
I was rolling these through my head last night and couldn't really figure out if one way would be better for any particular reason.
I'm not a js guru so wasn't really sure the pros/cons and caveats to these different methods.

I think it ends up depending on your app.
Pure HTML is the easiest, you just drop in in place and viola. JQuery makes it a breeze to add the proper events and what not.
However, whenever I've used AJAX it's always evolved into returning JSON and building elements on the fly. If you are populating a tree for example, it may become messy to get the proper nesting. This forces you to have to do client side code anyway at which point simply using JSON from the start is cleaner.
Also, If you plan to use the data calls from other pages then using JSON is the way to go because the HTML will bee fixed.

This completely depends on the way you have things set up in your application. I, for one, prefer to return JSON (second approach in your list), because I have an 'error code' parameter that I check in onSuccess function before updating the content on the page, and if it's not zero then I notify the user of the error, including the error message that came back from the server (server-side validation, database timeout, etc.).

I think you're missing a perfectly valid option, one which I use often. This is my typical schema and it has yet to fail me... :-)
Here's the basic jQuery template I use:
$(function() {
$.getJSON('/some/page',{foo:bar,bar:foo},function(json) {
if(json.outcome == 'success') {
$('body').prepend(json.html);
} else {
// Somehow let the user know why it didn't work
alert(json.error);
}
});
});
Here's the basic backend (PHP in my case) structure I use:
<?php // Page: '/some/page'
/* Blah Blah Blah... do whatever needs to be done... */
// If everything turns out okay (assuming '$output' is the HTML
// you want to display...
echo json_encode(array('outcome'=>'success','html'=>$output));
// If something goes wrong... just do:
echo json_encode(array('outcome'=>'error','error'=>'Uh oh... something is broken'));
Naturally, you'll want to be more specific with your error by putting them into some variable or something. But, you should get the idea. Also, of course you can add more information to the json output. You can have some pre-made HTML and also some other information like a 'success notice' or a new class name for some element, I dunno... whatever... the possibilities are endless.
Anyways, the reason I choose this route is because it's usually faster (based on my experience) to append pre-made HTML to the DOM rather than looping over JSON and inserting the stuff unless it's just, like, a bit of text to replace into an element. But, the method I've shown is, IMO, the best of both worlds. You can attach HTML as a string to one of the JSON properties.
Happy jQuerying :-)

The "possible action beyond that" part of your question makes a big difference. If you need to do other things with the data besides display it, returning as JSON is a clearly better option because you can work with the data as a native JavaScript object instead of having to traverse the HTML DOM. If all you ever intend to do is display it, I don't see any reason to go through the trouble of building that display in JavaScript; just build the HTML in your presentation layer on the server.

This came up recently and possible a dupe: The AJAX response: Data (JSON, XML) or HTML snippet?.
If you are going to be creating HTML then you may as well be returning HTML directly and inject it into the DOM. However, there are times you need to work with objects which is where JSON comes in handy.
If you return a Person object for example then you can greet Person.Name and show Person.Preferences which is really handy. It depends on your design but the general considerations should be to keep HTML out of Javascript unless you're building RIA.

I have used all three and have come to the conclusion that returning HTML is better when introducing new elements to a page.
My experiance is that when building HTML with javascript I am usually replicating work that will have already have been done for the non javascript user journey.
I still prefer parsing json for updating existing elements or creating javascript only functionality. I tell myself this for bandwidth, but I think it just because I love javascript.
As a forth option, I read a great post about how Flickr deal with vast quantities of data with string concatination. Basically just parse a big o' string down the pipe and chop it up on the client. This significantly reduces the on the server, with only a marginal increase on the client.

Returning pure HTML is the best solution. For the most part gzip should neutralize any difference in bandwidth, and rendering via javascript on the client can be slow if the client is a crappy machine. Finally, writing javascript to render HTML is hard to work with compared to using something nice like a view if you use MVC.