Integration with aspnet core

[nmocruz]

There's any way to intregate with aspnet core? should be good to have a kind of middleware that we could use to integrate with asp applications like aspnet/javascriptservices ou our own framework or api.

[yatli]

The biggest issue is the isolation model -- GE local memory storage is process-level singleton so multi-tenant is not available at the moment. We had troubles to bring up a GE service within ASP.NET hosts due to app domain issues. However as there are no appdomains in .net core I think the situation might be different -- haven't tried myself but I think it's worth an investigation. You can try it out with the coreclr version of our nuget package (build_coreclr.bat). Disable the http port in the GE code (as we're going to leverage asp.net core http listeners), and use GE stuff in a http handler as usual.

[nmocruz]

Ok,

I was also thinking in some kind of middleware to use in aspnet core, so app.UseGraphEngine(options) should make the http protocol work on our website/api.

[yatli]

@nmocruz what about a client-server approach? We can have a WCF adapter in between.

[nmocruz]

not necessary WCF, it was almost dead, and was brought back to core maybe more because of the legacy system using that. I will try to build something and share

[TaviTruman]

@nmocruz , @yatli - you'll find that in Banks, Manufacturing, Bioinformatics, Energy and the like, at the enterprise level WCF and is till actively being used. There's lot's of legacy WCF app out there and they are being migrated to Azure Service Apps too - so no, WCF is not dead.

[nmocruz]

@TaviTruman I know that is not dead, I have a legacy system using SOAP (unfortunately) and I need to use it but as a client. But I don't think that someone at this point will start to build a server or a micro-service with a graph engine and demand it to serve soap or ws-*.
HTTP, REST, JSON etc. will be must popular choice for a while, HTTP2, binary messages, and websocket can become popular choices to in a near future. Aspnet core will try to support all this, so will good to have some kind way to use this in our server.

I have project, basically is kind of scheduler engine, employees, tasks, plans, skills, constraints, shifts, etc. A graph seems a better approach, because we want to put intelligence in the system, like suggesting employees, tasks, to fill tasks or replace someone, or auto-generate quickly schedules based on rules, skills, or constraints.

The project is using aspnet/JavaScriptServices to deliver the front-end and the api will be json aspnet core. the api can be described with the TSL language but not sure how to take advantages of aspnet core to bind json request to c# objects, (and reverses), route REST (PUT, POST, GET, etc) request to graphengine handlers.

Other cenario is subscribe changes in the graph, using websockets, or signalr.

Other interesting technology that I saw, but is not so important is GraphQL.

[TaviTruman]

@nmocruz yeah you can use the GE TSL to model material concretiity of the *MemoryCloud and you get the extremely high performance codegen DSL (type-smart) API surface from GE. The GE App model is a computed coded workflow (client/server) for the developer as such some atypical challenges; Yatao and I are developing VS-plugins for general use and for GE on Service Fabric.

I can see that aspnet core would need it own GE-aspnet core project plugin and template set. We are also writing a low-level server and client WCF adapters and connectors; the goal is to make the use of differing protocol declarative and nearly transparent for devs - looking to have very little friction on the server and client.

You can also use the FanoutSearch and LIKQ aspects of the GraphEngine to superpower your app (btw very cool app!). We also looked at GraphQL and quickly removed it from consideration due to object pressure/bloat and performance of very large RDF structures.

Looks like you understand the limitations typical database driven design; graphs are much more mutable, lower impact on design and cheaper to own; as they are different from DB design a bit more time up front is required to architecture.

FYI - next year I will release a full RDF, OWL 2 technology stack entirely based on the GraphEngine; it will come with full featured OWL 2 DL and Full Reasoner and it will support CLIF FOLP expressions.

[yatli]

@nmocruz I see that your backend logic is integrated with frontend user interaction (listening for changes on websockets etc.) -- a graph store is indeed more suitable in this situation than a traditional db, as @TaviTruman also mentioned. GraphQL integrates nicely with frontend technologies, but you will need to find your own backend server implementation -- it is only a standard, plus a reference implementation in javascript. We may investigate the feasibility of rolling up a GE-based implementation, leveraging our own facilities like strongly-typed stores, distributed / HA infra, query languages, RDF support etc.

[yatli]

Closing the issue due to low activity. Feel free to reopen it when you have something to add.