Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Major refactoring on Citizen-integrator-track #377

Open
hodrigohamalho opened this issue Dec 5, 2019 · 4 comments
Open

Major refactoring on Citizen-integrator-track #377

hodrigohamalho opened this issue Dec 5, 2019 · 4 comments

Comments

@hodrigohamalho
Copy link
Contributor

hodrigohamalho commented Dec 5, 2019

Major refactoring focusing on 3Scale and Fuse Online.

The motivation about it is that most part of the audience is in their first experience with Red hat Integration, so we need to make it smoother exploring more the core of Red Hat Integration (3Scale and Fuse on that case).

Proposed agenda:

  • Design Locations API (same)
  • Mock the API (same)
  • Implement the API on Fuse Online (new)
    • List and Create methods
  • Import this API on 3Scale (new)
    • Do all the mapping and use user-key authentication
  • Register on the developer portal the locations app (same)
  • Deploy the Locations web app
  • User starts to create the API methods on 3Scale to see they discriminated on Analytics dashboard (new)
  • Create a different plan and enable billing (new)
    • Register a new application on that plan (new)
  • Bonus Lab (Secure your application with OpenID)
@weimeilin79
Copy link
Contributor

Are you suggesting removing the developer track? And focus just on Integrator Track?

@hodrigohamalho
Copy link
Contributor Author

@weimeilin79 no. But my suggestions are specific for improvements on the Integrator Track, maybe we should open another issue to consolidate some to Dev Track.

@GrooveCS
Copy link

GrooveCS commented Mar 4, 2020

@weimeilin79 I vote to keep them separate. Change the integrator track to engineering or administrative path is a possibility. I believe they have distinct interests different from developers.

@GrooveCS
Copy link

GrooveCS commented Mar 4, 2020

Propose for discussion the following be considered for web service gateway, proxy, and management.

  1. OpenAPI, SOAP/WSDL and/or OData/GraphQL definition be used as an example use-case
  2. Intranet & Extranet example use-case
  3. Aggregation of public services use-case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants