Speed wise, probably not much of a difference.
Resource wise, now you are involving a third party server to retrieve that JSON.
Personally I try to avoid involving as many third party services as possible, because you are using their resources and relying on them being up and accessible at all times. If the third party API is down for any reason, then your app is basically unusuable until it’s back up.
If I can accomplish the same thing in a javascript column then I usually go that route. It keeps everything within Glide and that javascript actually runs on the user’s device, so it doesn’t use any Glide server or third party server resources. Usually it’s a lot faster too since it runs locally.
That just my personal opinion. I try not to stretch resources out across too many third party service if I can. You’ll very likely be fine, but you are still at the mercy of someone else maintaining that third party API and not enforcing any sort of limitations for access. At the same time, if you keep the code local, then you are also at the mercy of maintaining that code yourself and making any necessary adjustments rather than the third party making any adjustments for you.
Plus also consider what I mentioned in my first post on this thread regarding API keys and rate limits. By calling the third party API, you could have multiple users calling that same API from multiple devices multiple times. As long as GitHub is cool with that, then it’s probably not a problem, but if the run your own code locally, then you don’t have to worry about things like that.
Just depends on the situation. If it were me I’d probably keep what you have, but copy and store that JSON in a basic text column in your table, so you don’t have to keep going out to that third party just to get the same list every time you need it.
Good morning Jeff,
I absolutely agree with you about the risk shifting when it comes to outsourcing the data.
I could certailny also link a fallback to my server to ensure redundancy.
As you mentioned, storing the JSON code in a Glide text field would also be an option, but I don’t find it really practical to edit the JSON source code in it.
In my opinion, editing in a code editor is much clearer given the amount of data.
When I made changes to the “JSON data embedded in JavaScript” version, I often faced the problem that the input lagged and occasionally the cursor slipped to the end. This often had the disadvantage that letters were swallowed and the code didn’t work
With this private app, a maximum of 3 additional employees retrieve the color stocks.
I now have further questions…
-Why do external rate limitations apply?
-Can’t I compare this to looking at a website?
-The calculations don’t take place on the external server or am I seeing that wrong?
In the end, I’m “Glide” that in addition to the focused path, there are other options that you didn’t consider before.
Thank you for your active support and praise to the participating community.
Hi micheal,
no the original code is from here
I just created a github account and uploaded the file there, because what would happen if the creator delete the file
But what I still have to do is replacing the english colornames with the german ones. Optionaly i consider just adding an other row with Code_de
Thanks for the hint with p1 but there will be more colorsystems to chose from with identical codes. I’ll have to add a logic with if then and templates behind it.
Do you mean in regards to rate limiting? If you click the refresh button 10k times in 1 minute, a website may rate limit you too, but you are looking at websites at a much slower rate than code calling an API could. In fact, this discourse forum has rate limits. Since the forum tracks my usage, meaning it runs code in the back end to track and store what I read and when, it has actually rate limited me on occasion and cause me to wait a few minutes before I can use the forum again. That happens if I’m going through posts way too fast.
If you call a typical API, there is code that runs on an external server and in some cases returns data back to you. In your case, a user’s device opens a url to an external resource to download that JSON, but the JSON Query itself is ran locally on that device.
