From jsightle at redhat.com Fri Jul 1 17:28:37 2016
From: jsightle at redhat.com (Jess Sightler)
Date: Fri, 1 Jul 2016 17:28:37 -0400
Subject: [windup-dev] REST <- graph api?
In-Reply-To: <577064AB.6090809@redhat.com>
References: <577064AB.6090809@redhat.com>
Message-ID: <112fbfe0-fbb0-47c2-9470-08fa54decb66@redhat.com>
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-NuTI00A7VcP7K58Gv6sWGyC8CuMsc5MVldRrc6Y/edit#heading=h.9hob5uguvtqc
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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From ozizka at redhat.com Fri Jul 1 21:45:30 2016
From: ozizka at redhat.com (Ondrej Zizka)
Date: Sat, 2 Jul 2016 03:45:30 +0200
Subject: [windup-dev] REST <- graph api?
In-Reply-To: <112fbfe0-fbb0-47c2-9470-08fa54decb66@redhat.com>
References: <577064AB.6090809@redhat.com>
<112fbfe0-fbb0-47c2-9470-08fa54decb66@redhat.com>
Message-ID: <57771CBA.7000604@redhat.com>
+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.
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.
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.
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-NuTI00A7VcP7K58Gv6sWGyC8CuMsc5MVldRrc6Y/edit#heading=h.9hob5uguvtqc
>
>
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
From bdavis at redhat.com Sat Jul 2 12:10:48 2016
From: bdavis at redhat.com (Brad Davis)
Date: Sat, 2 Jul 2016 12:10:48 -0400
Subject: [windup-dev] REST <- graph api?
In-Reply-To: <57771CBA.7000604@redhat.com>
References: <577064AB.6090809@redhat.com>
<112fbfe0-fbb0-47c2-9470-08fa54decb66@redhat.com>
<57771CBA.7000604@redhat.com>
Message-ID: <1BB862E3-7D74-4350-8A17-8413A0BB704C@redhat.com>
patternfly for the UI?
Thanks,
Brad Davis
Director of FSI Solutions, Red Hat
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
> On Jul 1, 2016, at 9:45 PM, Ondrej Zizka <ozizka at redhat.com> 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.
>
> 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.
>
> 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.
>
> 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-NuTI00A7VcP7K58Gv6sWGyC8CuMsc5MVldRrc6Y/edit#heading=h.9hob5uguvtqc
>>
>>
>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20160702/bff2b399/attachment.html
From mnovotny at redhat.com Mon Jul 4 03:18:45 2016
From: mnovotny at redhat.com (Marek Novotny)
Date: Mon, 4 Jul 2016 09:18:45 +0200
Subject: [windup-dev] REST <- graph api?
In-Reply-To: <1BB862E3-7D74-4350-8A17-8413A0BB704C@redhat.com>
References: <577064AB.6090809@redhat.com>
<112fbfe0-fbb0-47c2-9470-08fa54decb66@redhat.com>
<57771CBA.7000604@redhat.com>
<1BB862E3-7D74-4350-8A17-8413A0BB704C@redhat.com>
Message-ID: <d2fef671-4797-e0fa-0228-e6ed8a5bf3c1@redhat.com>
yes, it is already configured in windup-web.
On 2.7.2016 18:10, Brad Davis wrote:
> patternfly for the UI?
>
> Thanks,
> Brad Davis
> Director of FSI Solutions, Red Hat
> Email: bdavis at redhat.com <mailto:bdavis at redhat.com> | c: 980.226.7865
> <tel:980.226.7865> | http://www.redhat.com <http://www.redhat.com/>
>
> On Jul 1, 2016, at 9:45 PM, Ondrej Zizka <ozizka at redhat.com
> <mailto:ozizka at redhat.com>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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-NuTI00A7VcP7K58Gv6sWGyC8CuMsc5MVldRrc6Y/edit#heading=h.9hob5uguvtqc
>>>
>>>
>>> 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 at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
--
Marek Novotny
--
Windup team member
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno
From jsightle at redhat.com Tue Jul 5 19:00:18 2016
From: jsightle at redhat.com (Jess Sightler)
Date: Tue, 5 Jul 2016 19:00:18 -0400
Subject: [windup-dev] REST <- graph api?
In-Reply-To: <57771CBA.7000604@redhat.com>
References: <577064AB.6090809@redhat.com>
<112fbfe0-fbb0-47c2-9470-08fa54decb66@redhat.com>
<57771CBA.7000604@redhat.com>
Message-ID: <2e70cdb0-d09e-3432-1a22-ec548ff6a5b2@redhat.com>
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-NuTI00A7VcP7K58Gv6sWGyC8CuMsc5MVldRrc6Y/edit#heading=h.9hob5uguvtqc
>>
>>
>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev