Unified API management UI

[brylie]

User Story

As an API designer I would like a unified interface to manage many aspects of my API design So that I can easily have an overview of the API components

Planning

There is an Unified API Management planning document for this issue.

[kyyberi]

+1

[ccsr]

+1

[brylie]

@kyyberi will you please help me create a specification document for this issue?

[brylie]

Just a follow up, please add any requirements to the specification document. We will be looking for a developer soon, and want to make sure our efforts useful.

[brylie]

@GUI will you please advise us on this task?

[GUI]

Sorry for the delay in following up. Just to clarify, are you looking at Restlet Studio specifically for integrating into API Umbrella, or are you looking for API Umbrella to more generally provide functionality like Restlet Studio directly as part of the platform?

In any case, API Umbrella currently doesn't really have a notion of all the individual API endpoints that it may be serving up. Right now, the API Umbrella admin is focused more on the server-level routing to different API backends, but API backends can serve up multiple API endpoints. So, taking the Restlet Studio example, API Umbrella might know how to route /pet/*, but presuming a single API backend is serving up all the pet-related APIs, then API Umbrella wouldn't really know about /pet/findByTags or /pet/{petId} from a configuration perspective. You're probably already aware of how all this currently works, but I just wanted clarify how things currently work.

I can certainly imagine some use-cases and benefits of API Umbrella having a more complete knowledge of all the individual APIs, but I'd also like to better understand your actual use-case. Is this the type of thing you'd like to see to enable new features and functionality in the API Umbrella proxy layer, or is the idea behind this mainly to make it easier for API builders to document their API at the same time they're adding it to API Umbrella? Or are there other benefits or use-cases you see for this?

Regarding Restlet Studio specifically, it seems like you could use that in conjunction with API Umbrella now, but I'd love to get your input on whether you think using API Umbrella and Restlet Studio as two separate tools would work, or if you see definite benefits to having that functionality integrated into API Umbrella directly.

Thanks!

[KrishnaPG]

In the latest build, I think most of the functionality is already currently present in the Admin dashboard (where Analytics for API by userID is possible).

Same functionality in Consumer dashboard that displays specific APIs that he is subscribed to and have access to should solve this.

In fact, IMO, instead of maintaining two separate Admin and Consumer dashboards, unite them into single one, providing:

• same oAuth login system for both
• same Analytics dashboards for both

except,

• normal users see everything admin sees, but only filtered to their ID
• Admin users will have the capability to define and create the API-backends, while Consumers will have the capability to create only Keys to access them.

This way, code reuse will increase and Admin just becomes another user/consumer with different ROLE.

[brylie]

@KrishnaPG that is the strategy we are taking with the Apinf project, which is an extension of API Umbrella.

[KrishnaPG]

Yes @brylie . Looked into it sometime back, it is a good effort. The only problem is, it is tightly integrated with Meteor. While Meteor is good for fast development (I liked it personally and used to be our first choice), the production / deployment problems with it are not worth the effort.

For example,

• DDP with mongo does not really scale that well (oplog tailing is not really built for realtime).
  • Rethink is much better choice as backend, but Meteor with RethinkDB has its own set of problems
• Meteor is phasing away from Blaze. Blaze was one of the reason why we liked Meteor in the first place.
  • ReactJS is not worth the hype or effort. Too bulky for simple productions, too slow for complex projects. There are much better lightweight and fast templating systems available
• CDN support for Front-end is still lacking ... so on..

With Meteor the problem is, it has this either all or nothing approach. That philosophy may work for back-end heavy full apps.

But for something like Apinf, which has more front-ending to do (than back-end), users may want to add-on or further customize to their front-ends, and Meteor comes in the way.

Wish you had kept it simple (the plain NodeJS backend + direct front-end layer that is customizable by users + optional database choices for realt-time, such as RethinKDB etc). It would easily attract many.

[brylie]

We work with Meteor because it has made our effort simple compared with assembling a custom node.js stack. It has also allowed us to write synchronous style code, so that we have not had to deal with multiple levels of nested callbacks. This means our code can be highly readable, which we have emphasize in our team almost to a fault.

A lot of discussion around scalability has been pretty vague, and benchmarked around super-popular applications such as Facebook. For Facebook-scale applications, much more custom code, infrastructure, and experience is necessary than a development framework such as Meteor could provide.

What aspects of Apinf do you see as needing to scale beyond what Meteor can provide? What types of scaling would you see as needed (e.g. some number of database queries per second, support for some number of concurrent users, etc.)?