6 p.m.
Hi Ondrej,
On 07/01/2016 09:45 PM, Ondrej Zizka wrote:
+1 to getting this straight before getting deep into Windup 3.
To those 4 approaches in the document, I would suggest one more.
Kind of a hybrid.
The point of this, I assume, is to reduce the repetitive patterns in the
chain: graph -> Java Model -> Java service -> DTO -> REST -> JSON ->
TS
service -> JS model -> Angular 2.
So we should reuse the information already contained somewhere.
Yes, that is basically correct.
The most frequent scenarios I can forsee are:
1) Query by property, get the resulting objects, optionally with some
nested objects.
2) Start with a set of objects, query some other objects in some
relation to those.
3) Start with one object and get a tree starting with that object, based
on some recursive relation.
4) More complex queries.
Maybe, although I think that the main focus here needs to be on updates.
Queries can be handled pretty easily with gremlin, I think.
I suggest to stick with something simple, so for 4), we could have
custom services.
For 1) 2) 3), we could have a simple "URL to objects" schema, not trying
to be a generic query tool.
It could reuse the Models.
Examples (made up):
1) /graph/File{path=...}!out:fileToProject,getClassifications,:...
-- File objects with given properties with objects from relations
defined behind ! attached to it.
2) /graph/Project/id=[1,2,3]/out:projectToFile/{path=...}
3a) /graph/Project/id=1//in:parent!out:fileToProject -- will query
what's under that relation
3b) /graph/Project/id=1//in:parent!getProjects -- will use the method
to attach the objects.
I think that it is important that the information in this system is
completely separate from frames. Frames mix implementation details with
data representation, and that is bound to cause issues for a generic
service like this.
I have sent a little sample of what I was thinking of here:
https://github.com/windup/windup-web/pull/17
Feel free to analyze the idea and let me know your ideas here.
Thanks,
Jess
Maybe it's quite similar to what's proposed in the doc under 4, only a
bit more type oriented, and also more use-case oriented and less generic.
my2c.
Ondra
On 1.7.2016 23:28, Jess Sightler wrote:
> I don't think we ever discussed this in the Thursday meeting. My mic
> problems probably didn't help with that (sorry about that). I have
> started a document to discuss a few different approaches to building
> REST services for the web application.
>
> Keep in mind the following high level requirements:
>
> - Support querying of data easily for both the global configuration
> graph (eg, projects, groups etc) as well as for the individual graphs
>
> - Support persisting new data to the graph for the configuration graph
>
> - Support easy marshalling to/from ECMAScript objects
>
>
> I have added these to the document as well:
>
>
https://docs.google.com/document/d/1jJz-NuTI00A7VcP7K58Gv6sWGyC8CuMsc5MVl...
>
>
> Feel free to add your thoughts as well.
>
>
> Thanks,
>
> Jess
>
>
>
> On 06/26/2016 07:26 PM, Ondrej Zizka wrote:
>> Hi devs,
>>
>> How about creating a layer that would query the graph based on a REST URL?
>> I.e. instead of creating a REST endpoint for each service, we could do
>> something like
>>
>> localhost//windup/rest/graph/ProjectModel/id-48984/out-projectTofile/with-...
>>
>> Or some subset of Gremlin perhaps...
>> Just an idea.
>>
>> Ondra
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev