Date   
Invitation: EdgeX: Go Lang Bi-weekly Meeting @ Every 2 weeks from 12pm to 1pm on Tuesday (PDT) (edgex-golang@lists.edgexfoundry.org)

Brett Preston
 

EdgeX: Go Lang Bi-weekly Meeting

When
Every 2 weeks from 12pm to 1pm on Tuesday Pacific Time
Where
https://zoom.us/j/556290937 (map)
Calendar
edgex-golang@...
Who
(Guest list has been hidden at organizer's request)
Hi there,

EdgeX Foundry is inviting you to a scheduled Zoom meeting.

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/556290937

Or iPhone one-tap :
US: +16699006833,,556290937# or +16465588656,,556290937#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
Meeting ID: 556 290 937
International numbers available: https://zoom.us/zoomconference?m=KBfzW5JEH81D7_DcchwL7x7Yow6FqceS

Going?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account edgex-golang@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.

Giving EdgeX Microservices Some Architectural Love

Drasko DRASKOVIC <drasko@...>
 

Hi all,
now that we are getting into Go re-write, I think it is a good
opportunity to address some of the architectural issues also.

Jim and Dell team already did great job putting all EdgeX in place,
but for example there is still tight coupling between microservices as
they share data models. In order to do Export Services re-write I am
currently re-defining some of Java classes even from Core repos.

Sharing data libraries between microservices is not a good idea:
https://blog.philipphauer.de/dont-share-libraries-among-microservices/
- they should be loosely coupled, independently scalable and thus have
separate data models. It of course affects directly possibility to
write microservice in some other programming language.

But this is not the only problem I spotted. There is also sharing of
database instances - for example ExportDistribution microservice will
tap directly into ExportClient's DB:
https://wiki.edgexfoundry.org/display/FA/Architecture--Export+Services--Distribution.

To give a few references why this is bad practice:
- https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/,
chapter "Create a Separate Data Store for Each Microservice"
- https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/data-sovereignty-per-microservice
- http://www.ben-morris.com/a-shared-database-is-still-an-anti-pattern-no-matter-what-the-justification/
- http://enterprisecraftsmanship.com/2015/01/10/how-to-build-microservices-wrong/

Instead of sharing the DB, I would propose that ExportClient exports
an API for accessing it's DB, similar to this REST-based integration
pattern: http://hecodes.com/2017/04/integration-patterns-microservices-architectures-good-bad-ugly/

In any case, I would suggest better decoupling of microservices:
- No shared libraries (data models, Java classes, etc, ...)
- No shared storage (databases)

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: cavium go work

Drasko DRASKOVIC <drasko@...>
 

On Tue, Oct 10, 2017 at 2:51 PM, Fede <fclaramonte@...> wrote:

Two ways we can take:
1) We set-up an official repo and I upload the code, then we take it from
there
2) You send PRs to my repo for now, as Tyler already did:
https://github.com/drasko/edgex-export/pull/1
Any of both options are fine with us. Maybe the second is best until it is
completed and can be moved to an official repo.
Great, please send PRs.


I was also asking about what can we work on, like helping you with
distro(how) or start implementing some of the missing microservices.
I am only only maintaining Export services for now, as Dell is working
on Core. Once Dell opens the Core we can start working on this,
probably Jim can give us more insight on this.

ExportDistribution microservice is priority - I practically did not
touch it yet. And since all needed Export Java classes will be ready,
you can
start on ExportDistribution right away.

Apart from Export services, I think other interesting field are Device
services. This way once Dell opens up the Core we will have whole
vertical. I would propose that we all begin with Export services
though, in order to establish best practices and agree on
technologies, packages and patterns, and later switch to other
services applying the same code style.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: cavium go work

Fede Claramonte
 

ExportDistribution microservice is priority - I practically did not
touch it yet. And since all needed Export Java classes will be ready,
you can
start on ExportDistribution right away.
We have started to look to distro, but we had some questions:

- There isn't a go 'native' library to use zeromq. There are some go wrappers for the C library like https://github.com/pebbe/zmq4.  Do we will have some policy about c code in the go port? What library is being used in the core-data go port?

- The data sent with the zeromq messages is a serialized java object (https://github.com/edgexfoundry/core-data/blob/ed14690aeecf0498387dfd5d7755f6431941090a/src/main/java/org/edgexfoundry/messaging/impl/ZeroMQEventPublisherImpl.java#L92) What should we do? Try to deserialize the java object to be compatible with the java version? Using a different algorithm to serialize the objects (json, protobuf,...)?

Regards
Fede

Re: cavium go work

Drasko DRASKOVIC <drasko@...>
 

On Wed, Oct 11, 2017 at 4:59 PM, Fede <fclaramonte@...> wrote:

ExportDistribution microservice is priority - I practically did not
touch it yet. And since all needed Export Java classes will be ready,
you can
start on ExportDistribution right away.
We have started to look to distro, but we had some questions:

- There isn't a go 'native' library to use zeromq. There are some go
wrappers for the C library like https://github.com/pebbe/zmq4. Do we will
have some policy about c code in the go port? What library is being used in
the core-data go port?
While we are there, may I propose switch to gRPC and protocol buffers
(https://grpc.io/) :)? Otherwise, I find nanomsg better approach then
ZMQ: https://github.com/go-mangos/mangos


- The data sent with the zeromq messages is a serialized java object
(https://github.com/edgexfoundry/core-data/blob/ed14690aeecf0498387dfd5d7755f6431941090a/src/main/java/org/edgexfoundry/messaging/impl/ZeroMQEventPublisherImpl.java#L92)
What should we do? Try to deserialize the java object to be compatible with
the java version? Using a different algorithm to serialize the objects
(json, protobuf,...)?
+1 for gRPC and protobuf. Performance matters, and gRPC is extremely
well supported in both Go and Java. There is much more than simple
socket connection patterns that comes with gRPC.

Otherwise, if we are sticking with ZMQ, maybe even JSON is not so bad,
for simplicity of implementation.

BR,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: cavium go work

Luca Capra
 

Dear,
I would suggest gRPC also, in m experience performs well and have good
support on many popular languages.

Regards
Luca

2017-10-11 17:26 GMT+02:00 Drasko DRASKOVIC <drasko@...>:

On Wed, Oct 11, 2017 at 4:59 PM, Fede <fclaramonte@...> wrote:

ExportDistribution microservice is priority - I practically did not
touch it yet. And since all needed Export Java classes will be ready,
you can
start on ExportDistribution right away.
We have started to look to distro, but we had some questions:

- There isn't a go 'native' library to use zeromq. There are some go
wrappers for the C library like https://github.com/pebbe/zmq4. Do we will
have some policy about c code in the go port? What library is being used in
the core-data go port?
While we are there, may I propose switch to gRPC and protocol buffers
(https://grpc.io/) :)? Otherwise, I find nanomsg better approach then
ZMQ: https://github.com/go-mangos/mangos


- The data sent with the zeromq messages is a serialized java object
(https://github.com/edgexfoundry/core-data/blob/ed14690aeecf0498387dfd5d7755f6431941090a/src/main/java/org/edgexfoundry/messaging/impl/ZeroMQEventPublisherImpl.java#L92)
What should we do? Try to deserialize the java object to be compatible with
the java version? Using a different algorithm to serialize the objects
(json, protobuf,...)?
+1 for gRPC and protobuf. Performance matters, and gRPC is extremely
well supported in both Go and Java. There is much more than simple
socket connection patterns that comes with gRPC.

Otherwise, if we are sticking with ZMQ, maybe even JSON is not so bad,
for simplicity of implementation.

BR,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang

Re: cavium go work

Drasko DRASKOVIC <drasko@...>
 

On Wed, Oct 11, 2017 at 7:03 PM, Luca Capra <luca.capra@...> wrote:
Dear,
I would suggest gRPC also, in m experience performs well and have good
support on many popular languages.
I do not know yet very well how do we use ZMQ and what connection
patterns are needed. But if gRPC usage is not possible, my second
choice would be nanomsg over ZMQ, as I mentioned:
- http://nanomsg.org/index.html
- http://bravenewgeek.com/a-look-at-nanomsg-and-scalability-protocols/

Good support in Go: https://github.com/go-mangos/mangos and Java.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

List of Issues for Go Export Services

Drasko DRASKOVIC <drasko.draskovic@...>
 

Hi all,
I have created a quick list of GitHub Issues for Go Export Services to
serve as a task list: https://github.com/drasko/edgex-export/issues

Please feel free to open new issues and add all that you think is
important and should be worked on or discussed.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

EdgeX Device Services in Go

Drasko DRASKOVIC <drasko@...>
 

Hi all,
since Export Client is practically finished and Cavium is looking at
Export Distribution, I have created EdgeX Device Services placeholder
for people interested to put their hands on this part of the system:
https://github.com/drasko/edgex-device.

Manuel from Mainflux (who did great contributions on Export Client)
will start now working on MQTT Device Service, following with BLE or
HTTP (REST).

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: [Edgex-devel] EdgeX Device Services in Go

espy
 

On 10/12/2017 06:02 PM, Drasko DRASKOVIC wrote:
Hi all,
since Export Client is practically finished and Cavium is looking at
Export Distribution, I have created EdgeX Device Services placeholder
for people interested to put their hands on this part of the system:
https://github.com/drasko/edgex-device.
Manuel from Mainflux (who did great contributions on Export Client)
will start now working on MQTT Device Service, following with BLE or
HTTP (REST).
Can we discuss this later today at our bi-weekly Go meeting? I've been working on a Go Device Service "SDK" (actually probably better referred to as a "Go package") which hasn't yet been released to github, as I'm leveraging some of the core go packages written by Ryan @ Dell which aren't yet public. I think starting to implement individual Device Services in Go prior to some discussion/review of my approach/code isn't wise.

Also as part of this work, BLE is one of my first targets for a Go Device Service SDK. That said, we should have some discussion as to whether or not it makes sense to re-write the Virtual Device Service in Go?

Likewise I'm also having a separate call later today with Keith and his team for some initial brainstorming around a C SDK.

Regards,
/tony

Re: [Edgex-devel] EdgeX Device Services in Go

James.White2@...
 

Dell - Internal Use - Confidential

Added to the agenda - thanks Tony

-----Original Message-----
From: edgex-devel-bounces@... [mailto:edgex-devel-bounces@...] On Behalf Of espy
Sent: Tuesday, October 17, 2017 11:17 AM
To: Drasko DRASKOVIC <drasko@...>; edgex-devel@...; edgex-golang@...; manuel@...; Janko Isidorovic <janko@...>
Subject: Re: [Edgex-devel] EdgeX Device Services in Go

On 10/12/2017 06:02 PM, Drasko DRASKOVIC wrote:
Hi all,
since Export Client is practically finished and Cavium is looking at
Export Distribution, I have created EdgeX Device Services placeholder
for people interested to put their hands on this part of the system:
https://github.com/drasko/edgex-device.

Manuel from Mainflux (who did great contributions on Export Client)
will start now working on MQTT Device Service, following with BLE or
HTTP (REST).
Can we discuss this later today at our bi-weekly Go meeting? I've been working on a Go Device Service "SDK" (actually probably better referred to as a "Go package") which hasn't yet been released to github, as I'm leveraging some of the core go packages written by Ryan @ Dell which aren't yet public. I think starting to implement individual Device Services in Go prior to some discussion/review of my approach/code isn't wise.

Also as part of this work, BLE is one of my first targets for a Go Device Service SDK. That said, we should have some discussion as to whether or not it makes sense to re-write the Virtual Device Service in Go?

Likewise I'm also having a separate call later today with Keith and his team for some initial brainstorming around a C SDK.

Regards,
/tony

_______________________________________________
EdgeX-Devel mailing list
EdgeX-Devel@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-devel

Go Lang project meeting today

James.White2@...
 

Reminder that the Go Lang project meeting is today at 2pm central time.  Find the agenda and connection information are available at:  

https://wiki.edgexfoundry.org/display/FA/Go+Lang+Microservices+Project+Group


Also, the initial Contributors page for Go Lang developers is provided at:  https://wiki.edgexfoundry.org/display/FA/Contributor%27s+Guide+-+Go+Lang

Comments welcome during the meeting.


Using Java Strings As Enums In Go

Drasko DRASKOVIC <drasko@...>
 

Hi all,
we have opened a discussion here:
https://github.com/drasko/edgex-export/issues/19 around the fact that
strings are used as enumed flags in Java, while Go does not really
have enums of this type. More info can be found here:
https://splice.com/blog/iota-elegant-constants-golang/


Here: https://github.com/edgexfoundry/export-domain/blob/master/src/main/java/org/edgexfoundry/domain/export/ExportCompression.java
for example you can see one of this enums in Java, or here also:
https://github.com/edgexfoundry/export-domain/blob/master/src/main/java/org/edgexfoundry/domain/export/ExportFormat.java.
And here is the proposed equivalent representation in Go:
https://github.com/drasko/edgex-export/blob/master/registration.go

My question is: do we really need this string values for the enum vars
like we use in Java, or maybe Java can switch to int types for these
flags and then be aligned with Go? I.e. why for a type of compression
we have to use string "NONE" or "GZIP" or similar, when instead we can
use just type codes - for example NONE = 0, GZIP = 1 - and then we
will know how to distinguish them (I have explained this in my
comments on PR here:
https://github.com/drasko/edgex-export/issues/19).

What do you think that it is the best way to handle this case?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

ZMQ for Go

Drasko DRASKOVIC <drasko.draskovic@...>
 

We mentioned on last Go group meeting this issue:
https://github.com/drasko/edgex-export/issues/10

Put there for the reference, please feel free to comment.

BR,
Drasko

Coupling Between Microservices

Drasko DRASKOVIC <drasko@...>
 

Hi all,
on last Go meeting we mentioned two problems:
- shared DB instances between microservices
- shared libs (data models, Java clases) between microservices

IMHO both are wrong. While almost everybody agrees that DBs should be
separated (duplicated), we did not have unison agreement on shared
libs.

I would kindly like to remind you that I have sent a (long) e-mail of
my research on the subject:
https://lists.edgexfoundry.org/pipermail/edgex-golang/2017-October/000001.html,
and I would like some feedback on this. Please follow the links in the
e-mail, I tried to select only the articles that look credible to me.

Dejan, Nikola,
as more experienced architects than me, can you please give some more
information why libraries (data models) should not be shared between
microservices, and also how is this problem solved in practice - is it
by data duplication in each of the services?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: Coupling Between Microservices

Car, Boran <Boran.Car@...>
 

Drasko,

You have a valid point, but there is a limit to it all. I'm taking this quote from https://blog.philipphauer.de/dont-share-libraries-among-microservices/:

"It's okay to have libraries for technical concerns (e.g. for logging or monitoring), because it's not likely for a business requirement to affect these concerns. But never move business and domain logic to libraries, because this will lead to frequently updates and deployments of all microservices. For instance, if the domain model classes are placed in a library and a new business requirement demands a change in this model we have to update all microservices using this model. Besides, in a microservice architecture, every microservice should be a bounded context anyway (see domain-driven design). Therefore, a microservice should have its own domain model. So there should be no reason for another microservice to use exactly the same domain classes."

And I completely agree with it. At Thales e-Security we're trying to prepare a template building block for microservices and have these aspect bits for logging and monitoring injected from a shared library. I'd say treat it as you would Aspect Oriented Programming and it's not a black and white approach. If two microservices of different kinds share the same business logic, that's better but that's also a potential refactor/redesign in the future, but aspects should be shared IMHO, with the ability to inject different aspect providers.

As for the database, I perfectly agree with you and have seen the concept breaking over eventually. Your solution with creating a data access API is sound, but we need to take some pragmatism. This data access thing may eventually become a shared aspect, too, and get injected. I don't know enough to recommend or take either side, but can present the case of Istio (https://istio.io/), which is a mesh network solution and it gets injected as a side-car (it's possibly the only side-car approach I like so far :) ) if it inspires anyone to take either side.

Regards,
Boran

-----Original Message-----
From: edgex-golang-bounces@... [mailto:edgex-golang-
bounces@...] On Behalf Of Drasko DRASKOVIC
Sent: 19 October 2017 16:08
To: edgex-devel@...; edgex-
golang@...; White, James (Dell); Tyler.Cox@...;
espy; dejan.mjc; Janko Isidorovic; darko@...; Nikola Marcetic;
manuel@...
Subject: [Edgex-golang] Coupling Between Microservices

Hi all,
on last Go meeting we mentioned two problems:
- shared DB instances between microservices
- shared libs (data models, Java clases) between microservices

IMHO both are wrong. While almost everybody agrees that DBs should be
separated (duplicated), we did not have unison agreement on shared libs.

I would kindly like to remind you that I have sent a (long) e-mail of my
research on the subject:
https://lists.edgexfoundry.org/pipermail/edgex-golang/2017-
October/000001.html,
and I would like some feedback on this. Please follow the links in the e-mail, I
tried to select only the articles that look credible to me.

Dejan, Nikola,
as more experienced architects than me, can you please give some more
information why libraries (data models) should not be shared between
microservices, and also how is this problem solved in practice - is it by data
duplication in each of the services?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang

Re: Coupling Between Microservices

Car, Boran <Boran.Car@...>
 

My mistake, I mean to say if two microservices of different kind replicate the same business logic, in line with the article you shared originally.

-----Original Message-----
From: Car, Boran
Sent: 19 October 2017 18:04
To: 'Drasko DRASKOVIC'; edgex-devel@...; edgex-
golang@...
Subject: RE: [Edgex-golang] Coupling Between Microservices

Drasko,

You have a valid point, but there is a limit to it all. I'm taking this quote from
https://blog.philipphauer.de/dont-share-libraries-among-microservices/:

"It's okay to have libraries for technical concerns (e.g. for logging or
monitoring), because it's not likely for a business requirement to affect these
concerns. But never move business and domain logic to libraries, because
this will lead to frequently updates and deployments of all microservices. For
instance, if the domain model classes are placed in a library and a new
business requirement demands a change in this model we have to update all
microservices using this model. Besides, in a microservice architecture, every
microservice should be a bounded context anyway (see domain-driven
design). Therefore, a microservice should have its own domain model. So
there should be no reason for another microservice to use exactly the same
domain classes."

And I completely agree with it. At Thales e-Security we're trying to prepare a
template building block for microservices and have these aspect bits for
logging and monitoring injected from a shared library. I'd say treat it as you
would Aspect Oriented Programming and it's not a black and white approach.
If two microservices of different kinds share the same business logic, that's
better but that's also a potential refactor/redesign in the future, but aspects
should be shared IMHO, with the ability to inject different aspect providers.

As for the database, I perfectly agree with you and have seen the concept
breaking over eventually. Your solution with creating a data access API is
sound, but we need to take some pragmatism. This data access thing may
eventually become a shared aspect, too, and get injected. I don't know
enough to recommend or take either side, but can present the case of Istio
(https://istio.io/), which is a mesh network solution and it gets injected as a
side-car (it's possibly the only side-car approach I like so far :) ) if it inspires
anyone to take either side.

Regards,
Boran

-----Original Message-----
From: edgex-golang-bounces@...
[mailto:edgex-golang- bounces@...] On Behalf Of
Drasko DRASKOVIC
Sent: 19 October 2017 16:08
To: edgex-devel@...; edgex-
golang@...; White, James (Dell);
Tyler.Cox@...; espy; dejan.mjc; Janko Isidorovic;
darko@...; Nikola Marcetic; manuel@...
Subject: [Edgex-golang] Coupling Between Microservices

Hi all,
on last Go meeting we mentioned two problems:
- shared DB instances between microservices
- shared libs (data models, Java clases) between microservices

IMHO both are wrong. While almost everybody agrees that DBs should be
separated (duplicated), we did not have unison agreement on shared libs.

I would kindly like to remind you that I have sent a (long) e-mail of
my research on the subject:
https://lists.edgexfoundry.org/pipermail/edgex-golang/2017-
October/000001.html,
and I would like some feedback on this. Please follow the links in the
e-mail, I tried to select only the articles that look credible to me.

Dejan, Nikola,
as more experienced architects than me, can you please give some more
information why libraries (data models) should not be shared between
microservices, and also how is this problem solved in practice - is it
by data duplication in each of the services?

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang

Swagger or RAML

Drasko DRASKOVIC <drasko@...>
 

Related to this: https://github.com/drasko/edgex-export/issues/21

I would like to hear community opinion, especially that Linux
foundation's Open API Initiative (https://www.openapis.org/) seems to
be aligned around Swagger.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: Swagger or RAML

James.White2@...
 

Drasko,
we looked at both while developing Fuse. Cloud Tsai from our team did a great job of looking at them both (and others). Tooling, at the time, provided the slight edge to RAML.

My feeling has been that someday, it would be nice to have API documentation in both RAML and Swagger (or even other formats if they have a significant following) - especially if we can get it to the point where that documentation is automatically generated from the code artifacts. The issue right now is that it still requires a fair amount of work (mostly manual work as the tooling we have found is not all the way there yet) to care, feed and maintain any of these document sets. The tooling we have in place to generate the RAML is far from perfect, but at least as of last year, it beat out what we found for Swagger.

The user community may have a preference, but we didn't see a strong enough pull to one or the other to trump our selection based on ease to create and make available the API documentation.

If you or anyone in the community would like to contribute and maintain the Swagger docs, improve automatic generation of either RAML or Swagger API documentation, or otherwise provide a better facilitate the sharing of the micro service APIs with the world, we would be extremely welcoming and grateful. Please consider making a contribution to make it so :)

________________________________________
From: edgex-golang-bounces@... <edgex-golang-bounces@...> on behalf of Drasko DRASKOVIC <drasko@...>
Sent: Thursday, October 19, 2017 2:07 PM
To: edgex-devel@...; edgex-golang@...; edgex-tsc@...; Dejan Mijic; Nikola Marcetic
Subject: [Edgex-golang] Swagger or RAML

Related to this: https://github.com/drasko/edgex-export/issues/21

I would like to hear community opinion, especially that Linux
foundation's Open API Initiative (https://www.openapis.org/) seems to
be aligned around Swagger.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang

Re: Swagger or RAML

Cates, Sol
 

We have started to standardize on OpenAPI as our spec, and have found go-swagger to be the best way to leverage it in GoLang, as the scaffolding for a client or server implementation is as simple as a simple 1 line command to generate. Then our devs have less stack to maintain or develop, and just have to focus on the business logic of the API.

We also liked RAML, but for the pattern of microservices written in GoLang, go-swagger had a lead from our perspective.



Sol Cates
VP of Technology Strategy, CTO Office
Tel: +1 (503) 756 1410
Email: scates@...
Twitter: @solcates

On 10/19/17, 12:30 PM, "edgex-golang-bounces@... on behalf of James.White2@..." <edgex-golang-bounces@... on behalf of James.White2@...> wrote:

Drasko,
we looked at both while developing Fuse. Cloud Tsai from our team did a great job of looking at them both (and others). Tooling, at the time, provided the slight edge to RAML.

My feeling has been that someday, it would be nice to have API documentation in both RAML and Swagger (or even other formats if they have a significant following) - especially if we can get it to the point where that documentation is automatically generated from the code artifacts. The issue right now is that it still requires a fair amount of work (mostly manual work as the tooling we have found is not all the way there yet) to care, feed and maintain any of these document sets. The tooling we have in place to generate the RAML is far from perfect, but at least as of last year, it beat out what we found for Swagger.

The user community may have a preference, but we didn't see a strong enough pull to one or the other to trump our selection based on ease to create and make available the API documentation.

If you or anyone in the community would like to contribute and maintain the Swagger docs, improve automatic generation of either RAML or Swagger API documentation, or otherwise provide a better facilitate the sharing of the micro service APIs with the world, we would be extremely welcoming and grateful. Please consider making a contribution to make it so :)

________________________________________
From: edgex-golang-bounces@... <edgex-golang-bounces@...> on behalf of Drasko DRASKOVIC <drasko@...>
Sent: Thursday, October 19, 2017 2:07 PM
To: edgex-devel@...; edgex-golang@...; edgex-tsc@...; Dejan Mijic; Nikola Marcetic
Subject: [Edgex-golang] Swagger or RAML

Related to this: https://github.com/drasko/edgex-export/issues/21

I would like to hear community opinion, especially that Linux
foundation's Open API Initiative (https://www.openapis.org/) seems to
be aligned around Swagger.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang
_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang