Open petrsvihlik opened 3 years ago
There simply was no need for it yet. It definitely makes sense to support other end-points. Maybe it's best to first think about what that would look like in code for people using Kontent.Statiq?
I suggest we keep this one open and collect feedback here. I'll definitely have some input myself soon and it was already mentioned by one of our team members too :)
Single /item
endpoint makes sense for me.
Currently, I am using this a a workaround:
new Kontent<Root>(client)
.WithQuery(
new EqualsFilter("system.codename", "root"),
new LimitParameter(1),
new DepthParameter(3)
);
This might be a single-use purpose, but /items-feed
would help me for bigger datasets for my Kontent - Statiq benchmark.
Or maybe use Paging API for that purpose.
More context here: https://github.com/Kentico/statiq-kontent-collaboration/issues/18
I have datasets for:
@Simply007 I added very naive support for items feed, this is the result:
I'll see about optimizing this a bit.
Well, looks like the second run was already a lot faster. I'm assuming that's due to caches being primed from the first run (?). Running the test in a release build shaved off another couple of seconds. I tried profiling but did not see any significant slow downs in the Kontent.Statiq module. Here's the result. I'll push my changes as well.
Is there a reason why there is support only for the
/items
endpoint? Was it a deliberate choice or was it just because of the lack of time and it's still the plan to support them at some point?I can see that for larger projects it could be handy to implement the
/items-feed
as well. The same goes for the taxonomies... (not to mention other endpoints)