hi. There are many approaches to optimizing GraphQL. Adding pagination and limiting the depth at which you can query is a good start. Also adding a layer between the resolvers and the database is preferred. Some data almost never change and can be put in a cache and some other needs to be reread each time. As for loading linked entities, EF will only load what you ask for with include operator, so you need to be very specific what you actually want. Unless you have "lazy loading" enabled, which I don't recommend. I mean a lot of these things depends on how many records will be in each table, how will it be used etc. I wouldn't use this article's code in production unless at minimum paging is in place. I would also be very conservative how many levels I would allow a client to query for. This needs to be a living conversation with backend team and any consumers of this API.
I have made some apps like ...
Bibips.com - Community site in style of Reddit
Topbeers.club - App listing best beers of Quebec
Mini List - ToDo mobile app on App store and Google Play
Hi Chris, Thank you for great article:) I have followed it and just found your comment "I wouldn't use this article's code in production unless at minimum paging is in place."
Can you please let me know optimized structures for in production and guide me with source code examples such as Github repositories?
Thanks! :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
hi. There are many approaches to optimizing GraphQL. Adding pagination and limiting the depth at which you can query is a good start. Also adding a layer between the resolvers and the database is preferred. Some data almost never change and can be put in a cache and some other needs to be reread each time. As for loading linked entities, EF will only load what you ask for with include operator, so you need to be very specific what you actually want. Unless you have "lazy loading" enabled, which I don't recommend. I mean a lot of these things depends on how many records will be in each table, how will it be used etc. I wouldn't use this article's code in production unless at minimum paging is in place. I would also be very conservative how many levels I would allow a client to query for. This needs to be a living conversation with backend team and any consumers of this API.
Hi Chris, Thank you for great article:) I have followed it and just found your comment "I wouldn't use this article's code in production unless at minimum paging is in place."
Can you please let me know optimized structures for in production and guide me with source code examples such as Github repositories?
Thanks! :)