Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Crnk does too much for us

See original GitHub issue

Sorry, this is a bit lengthy.

So, you may have noticed from some of my other comments, that we created a (big) API starting back then with katharsis. Crnk has evolved a lot since then. But many improvements and features don’t work for us. In fact, we need to work around them.

I’d like to see a more layered or modular approach to features that can be turned off and on.

Some of my wishes would be:

  1. Do not parse parameters that where passed in the URL. I’ll use the raw ones from the request (Map<String, Set<String>>).
  2. Do not make any assumptions or restrictions on filter parameter shape or semantics. spec does make recommendations, but they are only recommendations, and Crnk’s default behavior is not happy with a filter like GET /comments?filter[post]=1 (correct me if I’m wrong).
  3. Allow me to do things, that don’t comply with jsonapi spec, at least parameter-wise. We need data aggregating endpoints (building sums, averages etc) and therefore require parameters that allow us to ‘group by’ different criteria. Crnk should never drop any parameters but provide means to access non-compliant ones too.

crnk-jpa is indeed a very cool thing, if you can make do with the offered functionality. Unfortunately, we can’t. And crnk itself imposes restrictions and conventions, that make sense for crnk-jpa, but not if you have different things in mind. I get the impression that quite some crnk-core functionality is optimized towards crnk-jpa.

Right now I’m in the situation where all parameters get parsed, some throw a parsing exception which I have to ignore, and in the end, I have to pull parameters from the raw map because it’s the only way to really get everything that was passed (eg. grouping parameters). Performance wise it may not be a big issue, but if feels terribly wrong to do so. I am kind of writing a miniature framework inside crnk framework, to get what we need. Which is time consuming and also brittle.

Just recently I tried to add support for page[size] and page[number] parameters, instead of the default offset and limit params. That worked fine enough, even though I had do do very, very similar things as the OffsetLimitPagingBehavior (shared base class maybe?).

Yet, if a URL like ‘/api/persons?filter[name]=earl&page[size]=10&page[number]=0’ was requested, then the next link will be rendered as ‘/api/persons?filter[name][EQ]=earl&page[size]=10&page[number]=1’. Note the added ‘[EQ]’. While this is fine within the crnk world, it breaks my own parameter handling.

Summing up, I have two questions:

  1. Would you consider to ‘do less’ in crnk, and give framework users more control over which things they want to use?

  2. If there are no plans to work on 1) - which behavior / classes could be changed such that I get the flexibility I need? With which classes should I start and can I make crnk use them over the default ones easily?

Thanks for reading this! Looking forward to your answers.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:1
  • Comments:9 (9 by maintainers)

github_iconTop GitHub Comments

remmeiercommented, May 6, 2018

QuerySpec serialize/deserializer have been merged to have everything at one place, which in turn allows to more easily implement more customized url/parameter handling as requested here. And paging can be configured globally. There are a few smaller follow-ups:

Probably worthwhile to close this in favor of smaller more targeted tickets.

weaselmetalcommented, Apr 19, 2018

Well, filter[person][hasChildren]=true was an overly simplified example. A better example would be filter[person][hasSilverSpoons]=true.

Which, according to your reasoning should be something like filter[person][apartment][inventory][spoons][material]=silver.

We do have cases where we need to filter on data that is 4 hops (and more) away from the root object. While the latter approach is certainly not wrong, it was our design decision to rather use filter[person][hasSilverSpoons]=true. We even have filters that aren’t expressible through a relationship chain at all! This is where your suggested approach ultimately stops working. Not every relationship should / can be modeled bidirectionally. Which shouldn’t prevent one from defining a filter (where you will have to start with a DB query on a totally different table). Our API is not only used by our own app, we also have customers that communicate with our API directly. So a simplification of otherwise complex filter criteria is definitely important for us. Therefore

I think it is actually quite rare for a filter parameter not be associated with one of the fields in one way or the other.

… is an assumption which doesn’t hold true. We have plenty such parameters.

And didn’t mean to say that crnk should also start using FilterDefinition objects (although I am very happy with that idea), I was just trying to explain why the type-from-resource-deduction doesn’t work well for us and how we infer the type.

I’m happy to hear you’re open for change!

Read more comments on GitHub >

github_iconTop Results From Across the Web

crnk-io/Lobby - Gitter
Hi everybody. Currently, I'm using crnk for let's say "/admin-api", so far everything is good. Now there is a need for completely another...
Read more >
Crnk Documentation
In many cases Crnk repositories are used along regular JAX-RS services. In such scenarios it can be worthwhile if Crnk repositories and JAX-RS ......
Read more >
Filtering bidirectional relationship in CRNK - Stack Overflow
Currently this is something a repository has to handle, one way of doing it is to make getter/setter become bidirectional, so a Task....
Read more >
Hadassah Calls From Waste Management - Crank Yankers ...
A couple defends their right to use their bathroom as much as they please. ... YOUR CONTENT WILL RESUME SHORTLY. Crank Yankers.
Read more >
What is the best crank length for cycling? - BikeRadar
I use 140 and 145 mm cranks, these lengths seem to be optimal for me. I have tried as short as 125mm, but...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found