If there is one thing I hate about web development it is creating input forms. It’s something I’m bad at, mostly because I do not have a cohesive mental model about how to deal with input props. In this post I’m about to explore some techniques to make form creation using React somewhat easier.
During a month long refactor session on the Skyhop back-end I had upgraded all of my dependencies to their latest versions. Later during this process I discovered there was a dependency incompatibility between EF Core 5 and SqlKata. I weighted my options, and decided it would be easier to revert back to EF Core 3, than to solve this dependency compatibility issue in another way.
Recently I have been looking for more flexible ways to search through text within a SQL database, and I stumbled upon a suggestion which indicated to use the so called Levenshtein distance. This parameter is a value which indicates the number of changes to a string required in order to match the searched value. In a certain way it is possible to regard this Levenshtein distance as being a similarity rating between two strings, whereas the lower the value, the more similar it is.
A recurring question when it comes to dealing with filesystems is “where do I put this file, and where can I find it?”. This even more so when dealing with an app which is to be dockerized. How can I ensure these files can be accessed both during debug sessions, as well as when this app is running in Docker? To answer this question I have been fiddling around with an example project which you can find here, and the findings of which I describe in this post.
There are a surprising amount of use cases where it is beneficial to deal with disconnected entities in EF core. In my particular situation I’m dealing with a domain which is responsible for modifying data through an API. Reasonably enough, by the time this data returns to the server, the original
DbContext instance with which this data had been retrieved is no longer around, and therefore there is no change tracking.
EF Core tries to go out of the way, and most of the time it’s fairly easy to hook the entities back to the context, but with a single exception; when removing entities. Though this is not a problem when directly telling the context to remove a specific element, it is when the object contains a collection from which one of the children needs to be removed. Removing an object from a collection removes it without trace, and there’s no way Entity Framework may know there has ever been an object in there without verifying it with the database.
GraphQL is fairly flexible when it comes to API design. Sure, it’s not as flexible as OData, though that may actually be a blessing. Maybe it’s the restrictions in term of API structure which give GraphQL much of its power. In this post I’ll cover another subtle method which will improve usability and therefore the quality of your API;
Be notified when I publish something new by subscribing to this newsletter, or add my feed to your favourite RSS reader.
Don't worry, I will not spam you nor sell your email address to hackers!