Is this project dead?

[keatkeat87]

No description provided.

[RoccoDevs]

Wondering the same

[PaulBujor]

+1

[fbrum]

+1

[lenardchristopher]

+1

[DimaMegaMan]

+1 RIP

[TehWardy]

I got buried in other things, from what I understand things tailed off when Hassan left Microsoft.
I think there is some value in completing it though as it would enable a ton of better architecture options.

It's great to see there interest in this work though gives me a bit of a boost to want to up my schedules on projects.

[robertmclaws]

I didn't realize this project lost its daily driver. I'm down for helping out. I've had similar goals with Restier 2.0, so it might make sense to dig in a bit.

I'm gonna create my own fork and mess around this weekend. Get it updated to .NET 8.0 and see what's working and what's missing. At first glance it appears to be too dependent on EFCore, so I want to understand that a bit better.

@TehWardy Any suggestions on things I should take a look at to familiarize myself more with the prior plan?

[TehWardy]

Hi @robertmclaws I'm thinking the smart thing for us to do is to get a plan in place of all the features needed.
The key thing here is that we basically already have a standard and an existing implementation we can lean on.

I'd start with the major operations, so OData "select" i the first, next we should implement one of the other operators like "filter" which to my understanding should just map to a LINQ Where(t => ...) call so should be relatively simple.

The next logical place to go would be includes which leads to the hard problem ...
apply the recursion support to it (e.g. scenarios that embed one operation in the other),

I would like to get back in to this and hopefully where my time starts to free up I can catch up with @hassanhabib and we can kick it off again.

It would be a shame to see the huge value this project has lost.

[robertmclaws]

@TehWardy, So I spent some time looking at this project, and honestly I don't believe this is the direction we should be going. There is a lot of a single developer's personal architecture in here, vs making the right decisions for the platform.

The whole "Brokers" vs "Services" naming will collide with actual services when you get DI into the mix, "Orchestrations" vs "Foundations" vs "Coordinations" is going to be too much to explain to people who just want to build a queryable service against a database.

My personal opinion is that the code feels more like a doctoral thesis than an actual usable platform. Most of the code is the same boilerplate pattern repeated over and over again, and there are a lot of unnecessary non-Microsoft products bolted onto it.

If you actually dig into the code, seriously the majority of it is just throwing several dozen different types of exceptions. No real work is actually being done anywhere, not even in the OData.Query library.

Many of the things designed to happen in here (like querystring parsing) should actually be happening in ODL using Spans & optimized for speed. When you factor that out, what you're left with here is a vastly-overcomplicated architecture (like what Restier had once upon a time) that few people will be able to understand or maintain.

And speaking of databases, the fact that there is database code in the core libraries is a prime example that there is unnecessary scope creep.

I've been looking at how to build a modern OData pipeline with Restier 2.0, and I believe our approach of moving to a Middleware-based pipeline transformation architecture is cleaner and simpler.

Updating ODL to have a core set of functionality that can take a URI input and output a standard set of query commands would allow us to build an additional set of shared features that would work between Controllers, Minimal APIs, and Restier Middleware to achieve the same results in a fraction of the code.

I would recommend that this project be archived for reference, but no more time be put into making it work. The world has changed a lot in the 3 years since this started. It was a great thought exercise. It's time to think simpler, because simpler = faster.

[trojanmartin]

My personal opinion is that the code feels more like a doctoral thesis than an actual usable platform.

I have followed this project with great enthusiasm from the beginning and I completely agree with this statement.
From the beginning I had the feeling that it was more a presentation of a personal architectural style than a real product.

[callummarshall9]

Hi,

Just following up on this. I think all new software architectures probably feel more like a doctoral thesis project, especially when the code is so clean and you're trying to conceptually solve a problem from an completely different angle.

If we consider the existing solutions such as https://github.com/OData/AspNetCoreOData, you can see that is inherently tied into an controller architecture and while there is a pull request for a minimal API, there is a lot of cruft that goes into translating queries.

While running commands via Roslyn is non-ideal and there are inefficient routes taken, the existing solutions such as ODataLib are much bigger code bases that have far more lines of code to accomplish the same task. Especially such as https://github.com/OData/odata.net, where you can see there is an obsession with an IEdmModel used to describe an entity graph.

When you have a simple graph of endpoints that map almost 1 to 1 with EF Core Entities, the amount of work used to accomplish $filter=Name eq 'foo' using existing NuGet packages and solutions seems massively overengineered compared to just doing Set().Where(f => f.Name == "foo"), one of the goals of this project from my understanding was to provide the end to end solution of translating an OData query into tokens which was already accomplished and from my understanding is the role of ODataLib as you can see that tie into AspNetCoreOData SelectExpandWrapper.

If we take a look at Restier, it's also not easily able to plug in, all you want to be able to say is literally just one setup command and you're good to go, sure you can set it up, but it requires far more work than even Microsoft AspNetCoreOData with an controller architecture....

The idea was to rebuild the entirety of the OData pipeline into an easily extensible pluggable architecture.
So that means translating queries into tokens that providers could then subscribe to translating the tokens into the relevant technologies. Such as an EF provider or a Dapper provider.

Looking at the other side of graph translation APIs such as GraphQL, you can see GraphQL instead just lets you define a predefined set of questions & answers. In the earlier days of OData things like $apply also didn't work so it meant that if you wanted to define custom aggregate functions that the API didn't yet support, you were kinda out of luck..

So to my mind, most solutions out there already have a lot more code than the current actual source control of this repository. The testing approach may have been quite thorough but that's neither here nor there, the actual ratio of lines of code to achievable results is quite low. The current OData.Neo query parsing could probably do with updates due to Span but given the project timeline, this isn't that much work.

It's a shame enthusiasm has died for this because I see most people opting to use GraphQL due to OData limitations such as being able to easily aggregate OData commands between multiple microservice providers so I worry that outside of the Microsoft technology ecosystem such as D365 and a few large corporations. OData won't be adopted further due to the technical limitations of the current libraries.