Also we should support and give an option to full api load at startup. Basically we should support lazy loading and full loading which can be switch via a configuration. Full loading may important for some cases which need first api call return fast, but not important of having auto scaling of gateways and satisfy with manual scaling.
+1 BTW, images are not properly loading ... Re-attaching the missing images 1 and 2 respectively. [image: Inline image 1] [image: Inline image 2] Thanks & Regards, Ishara Cooray Senior Software Engineer Mobile : +9477 262 9512 WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware On Mon, Jan 30, 2017 at 2:28 PM, Lakmal Warusawithana <[email protected]> wrote: > +1 for the approach, this is lazy loading. > > Also we should support and give an option to full api load at startup. > Basically we should support lazy loading and full loading which can be > switch via a configuration. Full loading may important for some cases which > need first api call return fast, but not important of having auto scaling > of gateways and satisfy with manual scaling. > > BTW, images are not properly loading ... > > On Mon, Jan 30, 2017 at 2:06 PM, Ishara Cooray <[email protected]> wrote: > >> Hi, >> >> I am working on $Subject and following is the use case and the approach >> we are going to address. >> >> *Motivation:* >> In order to reduce the server startup time we thought of not loading the >> apis at the server startup. >> Then we need a way to validate api requests to avoid DOS attacks such as >> api requests with invalid context, passing to the api core level. >> >> *Solution:* >> Therefore we are planing to load summary of all apis(name, context, >> uriTemplates) into memory at server startup so that when an api request >> comes to the gateway it will first validate the availability of that >> api/resource. >> >> To get the api summary info there will be Rest Service in APIM core. >> >> >> >> >> For newly added apis we can update the in memory cache via a JMS Topic >> (later we can support for other message brokers as well) . >> >> >> >> Following components will be written to address these scenarios. >> >> >> 1. REST Service to retrieve API summary - *API Core* >> 2. APISummaryLoader to load APIsSummary at server startup - *GW* >> 3. JMS Topic receiver - *Core* >> 4. JSM topic listener - *GW* >> 5. APIContextValidationHandler - *GW* >> >> >> Thanks & Regards, >> Ishara Cooray >> Senior Software Engineer >> Mobile : +9477 262 9512 <+94%2077%20262%209512> >> WSO2, Inc. | http://wso2.com/ >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Lakmal Warusawithana > Director - Cloud Architecture; WSO2 Inc. > Mobile : +94714289692 <+94%2071%20428%209692> > Blog : http://lakmalsview.blogspot.com/ > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
