I am started to work with the riot api and so far I love riot for offering this possibility.
Can someone please help me how to write a rest call to get
- not the item parts but only the full item (like athene's unholy grail and not fiendish codex and chalice of harmony)
- the images for the items
- the item name
Here ist the website: https://developer.riotgames.com/api-methods/#static-data-v3
Or do I have to get all items and have to filter them by myself? Highly appreciate your help!
Thanks and see you on summoner's rift
You either need to query all items and filter from there or query an item by its ID if you know it beforehand.
For both of these options, you'll need to include the itemListData=image parameter.
Example: https://na1.api.riotgames.com/lol/static-data/v3/items?itemListData=image&api_key=YOUR_RIOT_API_KEY
I'd also suggest caching/storing the items object after the first request for faster access and rate limit efficiency.
If you use NodeJS, take a look at this (the source is available here).
Note that if you use the package above, your first request will go to the Riot Games API and the rest will be served from cache, that is until you restart your server. You may wanna implement permanent storage if you would like to frequently restart your server.
Related
I am creating a webpage in ReactJS for post feed (with texts, images, videos) just like Reddit with infinite scrolling. I have created a single post component which will be provided with the required data. I am fetching the multiple posts from MySQL with axios. Also, I have implemented redux store in my project.
I have also added post voting. Currently, I am storing all the posts from db in redux store. If user upvotes or downvotes, that change will be in redux store as well as in database, and web-page is re-rendering the element at ease.
Is it feasible to use redux-store for this, as the data will be increased soon, maybe in millions and more ?
I previously used useState hook to store all the data. But with that I had issue of dynamic re-rendering, as I had to set state every time user votes.
If anyone has any efficient way, please help out.
Seems that this question goes far beyond just one topic. Let's break it down to the main pieces:
Client state. You say that you are currently using redux to store posts and update the number of upvotes as it changes. The thing is that this state is not actually a state in your case(or at least most of it). This is a common misconception to treat whatever data that is coming from API a state. In most cases it's not a state, it's a cache. And you need a tool that makes work with cache easier. I would suggest trying something like react-query or swr. This way you will avoid a lot of boilerplate code and hand off server data cache management to a library.
Infinite scrolling. There are a few things to consider here. First, you need to figure out how you are going to detect when to preload more posts. You can do it by using the IntersectionObserver. Or you can use some fance library from NPM that does it for you. Second, if you aim for millions of records, you need to think about virtualization. In a nutshell, it removes elements that are outside of the viewport from the DOM so browsers don't eat up all memory and die after some time of doomscrolling(that would be a nice feature tho). This article would be a good starting point: https://levelup.gitconnected.com/how-to-render-your-lists-faster-with-react-virtualization-5e327588c910.
Data source. You say that you are storing all posts in database but don't mention any API layer. If you are shooting for millions and this is not a project for just practicing your skills, I would suggest having an API between the client app and database. Here are some good questions where you can find out why it is not the best idea to connect to database directly from client: one, two.
I am currently in the process of implementing pagination, sort and search functionalities in the project files/plans/sheets views of BIM 360 Docs integration.
Since I couldn't find any best practices regarding to these features, I thought I would reach out so that I don't keep stuck reinventing the wheel.
Background:
Most of the implementation uses https://github.com/Autodesk-Forge/forge-api-dotnet-client/ SDK.
Based on what I saw, pagination in Autodesk API is very basic and does not play well with filtered views. Please correct me if I am wrong, but it looks like there is no way to get number of items in the view and/or calculate total number of pages in the resultset.
If one uses filtering to limit types of items returned by the API (e.g. documents, sheets, project files), API applies pagination first and filters second. That causes holes in returned resultsets, e.g. one would request page 1 sized as 5 items, and get 3 items back, then request similarly sized page 2 and get no items back, then page 3 would yield 2 items.
The above mentioned issues force us to use dynamic lazy-loading paging, similar to how it's currently done in the BIM360 Docs UI.
Question:
Is there a different, better way to paginate? Or do we have to lazy-load results while scrolling, never knowing how much records the next page would return?
Unfortunately, paginating is not available for Forge MD API of BIM360 currently as I know. Apologizing for any inconvenience caused.
However, it's been logged as request id FDM-1769 a few days ago. I saw your name on the request list. So I think it will be supported in the future. Besides, a workaround is to fetch all data from the API, then paginate on the client side via Javascript.
I am currently playing around with feathers to see if its a good replacement for meteor.js in our POS back-office application.
It looks really great so far but i cam up with a thing i could not solve.
Sometimes i miss a simple thing if i do not find something on the net but I hope someone can help me to figure out:
The problem:
I am using feathers client and a observable client side to populate a data-grid with documents from the mongoose/mongodb based service. It works fine beside I make an UPDATE/PATCH on ANY of the documents contained in the "table".
That moment all (filtered) find results are replaced by just this updated document.
I know that i could cache the results in an array and then use the respective events to update the array, but i wonder if there is an easier way (as in meteor) that the find result remains intact and if it contains the updated document that is simply updated.
Any help appreciated
Greets from Manila
Ralph
How to keep the data up to date depends much on the frontend framework you are using.
The most framework agnostic solution is feathers-reactive which uses RxJS and works well with React (see this video) and Angular 2+
feathers-vuex for VueJS
can-connect-feathers for CanJS
For everything else you can keep the data up to date manually through the real-time events as you already mentioned.
I am new to programming and am trying to find some documentation on creating a GET REST API in php that can accept query paramters in the url. I have been looking for documentation and there seems to be a lot out there but not sure what I should focus on. I am looking for the API to take a url like this:
rest.php?format=json&action=courses
Once this url is posted I would like to make a query to my database to retreive the courses. When a url like this is make:
rest.php?format=json&action=students&course=id
I would like to query my database based on parameters set in the url. Can someone please point me in the right direction.
REST specifications are pretty vague in this regard.
However, if you have too many parameters then it is ok to have the method set as POST instead as per best practices.
There are many aspects that influence the way REST is implemented in the application. Totally depends upon the usecases and the way developer wants it to be, still there are certain REST Standards which will help you to keep your application adhere quality checks.
REST STANDARDS
Hope you can use this to relate to your scenario.
In the case of query params, they are usually recommended when you can take the risk of exposing the information and is usually used with GET calls. Instead you can use POST call and define the information in payload which can accommodate more data as well there is no risk of exposing information which you don't want.
Hope this clarifies the issue, if not please feel free to ask
6.30.15 - HOW CAN I MAKE THIS QUESTION BETTER AND MORE HELPFUL TO OTHERS? FEEDBACK WOULD BE HELPFUL. THANKS!
I am developing a web application that will handle/manage a VERY LARGE data set - Currently any kind of heavy load causes the browser to lock up - whether I'm in the Django Rest Framework API or in the Dojo/Dgrid. This is kind of a dual question.
I've researched and can't find a clear way to do this on either side.
How do I limit how much the database sends at one time to the Django Rest Framework and/ or The Dojo Dgrid. The Dgrid pulls the data from the Django Rest API. The DRF pulls data directly from the MySQL database.
If I can control how much data is sent at one time, then hopefully it won't lock up the browser as much. ANY suggestions, advice, help, examples would be very helpful. Thanks in advance!
UPDATED 6.22.15 -
Alright, I FINALLY Got the pagination to work and it display the limit/offset in the headers. :) YAY!!!! I can also see the data in the Response headers. HOWEVER... the grid won't populate and I keep getting this odd error:
TypeError: transform(...) is null
return transform(value, key).toString();
instrum...tion.js (line 20)
I've gotten this error before, but I've never been able to find a solution to it. After researching, there's not much I can find on HOW to fix or really even what it is. Any help with this would be greatly appreciated!! I'm SO CLOSE to getting this thing to work correctly after WEEKS and WEEKS of beating my head against a wall. Please help! :) Thanks in advance!!!
2nd Update - This was an answer from a previous post - but I'm still not sure how to fix it. When I addressed another issue - it went away for awhile, but I still have no idea how to correct the issue.
Problem 3: "transform(...) is null return transform(value, key).toString();"
This sounds largely tangential to the original issue, but the most common cause is a widget template that is referencing a property via ${...} that doesn't actually exist in the widget.
I don't know how to answer this on the layer between DRF and the database, but as discussed in other SO questions like this one, DRF allows you to limit the amount of data sent with requests via page or offset/limit parameters.
Based on the phrasing of your question, it sounds like the client side is actually requesting too much data. I'll outline how the flow should work, so hopefully you can spot what you've missed:
A dgrid instance is set up with a collection referencing a dstore/Rest instance
The dstore/Rest instance is created with appropriate properties set. In this case, based on the DRF Documentation:
useRangeHeaders: false (this is already the default)
rangeStartParam: 'offset'
rangeCountParam: 'limit'
As a result, when the grid renders, you should see requests sent to your server e.g. endpoint?offset=0&limit=25 - if you don't see those two parameters, that would be why you're getting too much data
The server will need to query the database with the respective OFFSET and LIMIT
The server must provide a response with the expected number of items (except if it reaches the end of the data set first, which should be reflected by the total property in the response, presuming the customization in the previous SO answer I linked is used)
Ultimately, if the service is working as expected, the grid should only be requesting a handful of items at a time, and should only be firing one or two requests at any given time.
Would add as a comment, but not enough reputation at the moment ....
Your question is pretty general, but one strategy would be to allow the user to select the number of items they wish to view at a time and then allow the user to page through the data with 'next x items' and 'prev x items' buttons. Your data object query would then use the current position +/- 'x' as the index range to reduce the number of data objects sent to the browser. This is the basic flow for Ebay, Amazon, Google, or any site with thousands of items to display. The 'next' and 'prev' actions could be wired as POST requests.