I spent 4 Months at Credit Suisse office in Cabot Square, Canary Wharf, London and as a Full Stack Drupal 7 Developer I joined a brilliant Team of other 7 people, 2 Drupal Developers, 1 project Owner, 1 Project Manager, 1 System Admin, 1 Business Analysts and 1 Testers.
The project was to create a new Drupal 7 Internal API Market Place Portal using Apigee API Reverse Proxy Technology to support all the CREDIT SUISSE internal member of the staff to promote, share and use their APIs.
Credit Suisse offers Financial Services mainly to private companies rather than retail customers. Therefore the APIs Market Place was used meant to be used mainly by their Internal Developer's teams.
To implement our Solution we used Apigee as API Management Tool from where Producers can publish and deploy a API using a simple Swagger Definition File which is uploaded into the Tool which generates web pages inside the Apigee Drupal 7 Portal. The Tool also provides a predictive analytics software to see the usage of the APIs.
The Process was to Upload first the Swagger Definition File into the Development Environment and then create an automated pipeline process which was automatically generating a RFC (Request For Change) request to release the APIs to the Production Environment.
As part of the Project, I created some customs module to create administration screen in order to:
- Upload the Swagger Definition File.
- Publish the APIs into Apigee.
- Allow the admin to add a policy to the APIs.
- Allow Developers to register for an App.
- Generates a public Key.
- Differentiate APIs between SPID based and normal APIs.
- Custom Administration Forms.
- Categorise Models and APIs using Taxonomy custom Views.
- Create a custom view page for calling the APIs.
One challenge was that because the Spid API requires OAuth 2 authentication, the process for generating the key was slightly different and I had to create 2 custom screen for these 2 types of APIs. When the user register for an App usually he gets a client_id and client_secret which they are used for the client authentication.
OAuth is directly related to OpenID Connect (OIDC) which requires that the client has to specify:
- client_name, required
- client_uri, required
- scope, optional, space separate string of scopes.
- redirect_uri, optional, list of valid URLs.
The purpose of OpenID Connect (OIDC) is to allow users to be authenticated directly by the Apigee which is a sort of relying parties, or RP and using all third-party services, eliminating the need for handling all the secure authentications on each specific site, and allowing developers to log into multiple unrelated websites without having to have a separate identity and password for each.
Another challenge was that by default Apigee generates a separate web page for each API defined inside the Swagger File (the Model Page), but the requirement was to show all these APIs inside the same same Model page.
Therefore I created a custom template that was displaying all the APIs inside an Accordion and each element of the Accordion was allowing the user to call the API without the extra step of loading another page.
The logic to test / call the APIs was built in custom JavaScript provided by Apigee custom modules, in this new Accordion page the Developer could see the definitions of all APIs and test it using the required parameters then the Tool was showing on the screen the results sent back from the APIs.
Basically Apigee works like a Reverse Proxy and it creates an interface to Developers so that they do not need to know the real location of the backend APIs but they can simply use the virtual URL location which is defined into the Drupal Portal and then the administrator can define the settings for all the API Gateways which handles those mappings.
Moreover, Apigee also handles the security to how to access on the APIs so the developers who implements the backend part do not need to worry about implementing authentications and security issues. In fact with Apigee it is possible to create an API proxy that requires an API key, then the developers who want to use the API must register for an app and generate a key, then the Developer can call the API using that API key.
Day to day activities
In order to achieve the success on the implementation of this Drupal API Market Place Portal, my day to day Tasks were:
- Continuous integration Tools such Apigee, Jenkins, GitLab and Jira.
- Full stack technology: Php / Drupal 7 / MySQL / REST APIs / OpenID Connect (OIDC) / jquery / HTML / CSS.
- I liked the Apigee and OIDC technology and the challenges and solutions that involved.
- Using my range of expertises to import new swagger files into Api Models using the service contributed module.
- Research and use always latest technologies, champion innovation as a technical expert.
- Follow the PSR-2 Coding Style Guide, best practices and processes in Delivering Code.
- Code reviewed with pull requests, Deployed and Built using automated custom script.
- Data Base Design and Building new Custom REST APIs for Integrating Drupal with Apigee.
Among all different challenges I was efficient in communicating and co-ordinating the tasks with different people across different teams and technologies. Starting from implementation of the new Admin screen to allow Producers to upload Swagger files, designing the new Custom Modules for the Developer's request App key screens, and creating all the Back-End CMS Management screens in a very proficient Drupal 7 full stack role.
