Hi All The downside of this approach is the lack of consistency on how you write an API in given 3 approaches. Let me re-iterate the approaches as I understood.
1) API fully designed using the UI. 2) API designed using the UI and implementation written as functions. 3) API that was fully written by hand. So the potential problem is if a user wants to switch between these approaches they would find it confusing. ie. I have an API designed and implemented using the 2nd approach and then some point down the line I need to add more resources by hand since I am now more comfortable with Ballerina. In that case, I would prefer to write the implementation in the resource itself instead of calling another function within the resource. For a user, it will be more intuitive if we can stick with core language construct ( service ) and practices when we define the API in API Manager, instead of bringing in extra structure or specific organization of the code. As a solution to the problem with managing generated code and the handwritten code, I would like to propose to look at the composer APIs which will allow you to manipulate a Ballerina program programmatically and serialize to source-code. Will it be possible to share a generated source of an API to have a look. Regards Jo On Mon, Aug 20, 2018 at 12:00 AM, Nuwan Dias <nuw...@wso2.com> wrote: > Hi Roshan, > > Both options you mentioned are available. (1) is actually available even > today and (2) is something we are working on. I'm actually referring to a > 3rd option which is where a user starts implementing an API on API Manager > using a Design First approach. In here the user first starts the > development by using our UIs to create the interface and then wants to take > control of the request and response message flows. > > Thanks, > NuwanD. > > On Thu, Aug 16, 2018 at 10:18 AM Uvindra Dias Jayasinha <uvin...@wso2.com> > wrote: > >> +1 for the approach suggested by NuwanD, this gives us a best of both >> worlds scenario separating user code from generated code. >> >> I believe we can even handle Roshan's requirement for non technical users >> in this way. Uploading Ballerina functions that will be associated with a >> given resource can be an optional step(For injecting custom API logic). By >> default an API will simply act as a pass through API proxy for the endpoint >> that it is fronting. This allows non technical users to define API proxies >> for their existing APIs without writing any code. For all other >> scenarios(mediation, transformation, implementing the API on the Ballerina >> gateway itself, etc.) you will need to get your hands dirty. >> >> >> On 15 August 2018 at 20:12, Nuwan Dias <nuw...@wso2.com> wrote: >> >>> Hi, >>> >>> This is regarding the implementation of APIs on API Manager v3.0 using a >>> Design First Approach. The API Publisher Portal of API Manager will have >>> the UI constructs required to design the interface of the API including the >>> resource paths, verbs, base paths, etc. This version of API Manager uses >>> Ballerina as its API implementation language. When it comes to implementing >>> the API logic, our plan was to allow users to edit the full Ballerina >>> source of the corresponding API. The sequence of actions in performing this >>> operation would be as follows. >>> >>> 1. User creates API definition (interface) using UI. >>> 2. Server code gens the Ballerina source corresponding to the above >>> definition. >>> 3. User edits the Ballerina source of the corresponding resources. >>> >>> Since this leads to a situation where the user edits an auto generated >>> code and re-auto generation leads to complications related to merging auto >>> generated code with user written code, this has led to rethinking how to >>> want to enable implementation of APIs from the API publisher. >>> >>> An alternative approach is to let the user implement Ballerina functions >>> offline and upload them to the API Manager. These functions should be >>> written according to a function template (signature). They can then be >>> linked to a particular resource. A function each can be linked for >>> processing the request and for processing the response. This is similar to >>> the model that we have today of uploading sequences for a given API, but >>> more powerful in terms of capability due to how the Gateway engine behaves >>> (Synapse vs Ballerina). This way a user does not edit auto generated code. >>> The code gen process would link the auto generated code with the user >>> uploaded code and create a consolidated Ballerina source to be deployed on >>> the Gateways. >>> >>> Another advantage here is that this model does not require us to have a >>> web based Ballerina editor. Users defining functions could use any editor >>> supported by Ballerina offline. >>> >>> I am opening up this idea for thoughts and suggestions. >>> >>> Thanks, >>> NuwanD. >>> >>> -- >>> Nuwan Dias >>> >>> Director - WSO2, Inc. http://wso2.com >>> email : nuw...@wso2.com >>> Phone : +94 777 775 729 >>> >> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Nuwan Dias > > Director - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- -- *Joseph Fonseka* WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 772 512 430 skype: jpfonseka * <http://lk.linkedin.com/in/rumeshbandara>*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
