A while back I made some utilities I developed to help with managing the API Platform. At the time we didn’t have access to an IDCS based environment, so credentials worked using basic auth (I.e. user name and password). But with environments managed by IDCS tokens are used.
As a developer with a Java background I have to admit to liking Groovy over Python for scripting, not to mention for the API Platform groovy is part of the gateway deployment and SDK. Meaning it is readily available in its 2.x form (3.x is relatively recent and aligning to the latest Java idioms). We haven’t tested against Groovy 3.0
Thank you to Andy Knight for sharing with us some Java code which I adapted to be pure Groovy (removing external dependencies for processing JSON). The result is a script that can be taken can be taken and worked into other scripts (which is what we have done for our previously provided scripts – Understanding API Deployment State on API Platform, Managing API Policy Versioning in Oracle API Platform, Documenting APIs on the Oracle API Platform). But this script can be used to get a token and display it on the command line or write it to file. Writing tokens to files is generally not good practise, but as a temporary measure when working on developing scripts arguably a managed risk.
The script can be found at https://github.com/mp3monster/API-Platform-Utils/tree/master/getToken and all the details on using the script can be obtained by passing -h as a parameter. The important thing is to understand how to obtain the Client ID and Client Secret, the details of which are described at https://docs.oracle.com/en/cloud/paas/api-platform-cloud/apfad/find-your-client-id-and-client-secret.html
We have been developing some advanced custom API policies for a client and in the process picked up on a few insights that didn’t even make into the API book. One of these policies is to provide an optimization around caching of API calls. The rest of this blog will talk about the tricks we have specifically applied to link an API Gateway to a caching mechanism and why.
Before I go into the details, I’d like to thank the Oracle product management team and particularly Glenn Mi at Oracle for their support getting through the deeper undocumented elements of the capabilities of the API Platform SDK.
Caching comes in may forms, and is motivated by varying reasons and not always the wanting the same behaviours. When getting into the subject of caching it is surprising how polarised people’s view points can be about which cache strategies are correct. The following diagram illustrates the diversity of caches that could appear in an end to solution solution.
Bringing together a caching technology in the Reverse Proxy model and an API Gateway makes a lot of sense. Data being provided to API consumers needs to be protected whether it comes from a cache or an active back-end system. At the same time you also want to exploit an API Gateway to provide analytics on API traffic, so any caching needs to be behind the gateway. But, if In front of an application layer then we can reduce the application workload.
When it comes to caching technology to partner with the gateway, there are a number of options available from Coherence to ehCache, memcache and Redis. We have avoided Coherence, whilst the gateway currently runs on a WebLogic server, we don’t want to need to unduly distort the performance profile and configuration of the Gateway by forcing a cache onto that server. In addition to which as Coherence is a licensed addition to WebLogic it raises difficult questions about licensing when deploying gateways (with gateways licensed based on logical groupings and API volumes but Coherence is licensed by OCPU). We also know that Oracle is moving towards having a micro-gateway which may mean we see the gateway engine moved onto something like Helidon (but this last point is my speculation).
We have elected to use Redis for several reasons –
- Available as a PaaS service with several cloud providers (AWS & Azure) so no setup or management effort but can also be deployed on-premises,
- Has an out of the box deployment that means cached entities can have a time to live (TTL) rather than needing to implement separate processes to expire cached values,
- The ability to make it scale through clustering,
This caching model also allows us to optionally allow application development teams to push into the cache directly results. So rather than waiting on TTL the cache can be refreshed directly or even primed, rather than having to create fake requests to prime a cache.
With the start of December comes the UK Oracle User Group conference, or to be more precise the Independent UKOUG. This year the conference is back in Blackpool, a slightly smaller venue than the ICC in Birmingham, but in many respects that made the event feel more vibrant and busy.
The user group also announced some of the changes it is making going forwards reflecting the changing needs of its members – SIGs being largely superseded by multi-stream single day events (Summits) with the Call for Papers for the first of these here. A wider list of Oracle related Calls for Papers is available here.
Of course being a UKOUG Volunteer, I have been presenting and co-presenting. The slides from my presentation sessions can be found at:
This was an abridged version of the an update on my presentation here
My second presentation was a review of Oracle Integration Cloud, in which I presented some customer use cases of OCI as part of a wider presentation on OIC by Sid Joshi.
This was followed on the second day with two API based sessions, the first being a deep dive into custom API Policies on the Oracle API Platform.
The final session, was another short one looking at Apiary which was primarily a demo of what the solution can do.
On top of trying to keep up with my usual workload – a very hectic couple of days.
My next Packt project (via O’Reilly) is not a book, but a short online training course about good API design, API 1st and some tools that can support an API 1st methodologies. Register for the session here.
It includes a closer look at cloud tools such as Oracle’s excellent Apiary (sorry if this sounds like a sales pitch, but it is a good tool and the words of the found of RestLet confirm this) along with SwaggerHub and a few other options.
A good API goes beyond just the payload definition and I’ll walk through the other considerations and explain why these other areas are important.
Last night we ran the latest of the Oracle Developer Meetups in London. This time Luis Weir presented on GraphQL, which got an very engaged discussion about the strengths and weaknesses of GraphQL, in-depth points about how the error paths should be handled among many other things.
The presentation material Luis used is based upon his Devoxx session earlier this year and can be seen here:
The links to Luis’ examples can be found on his GitHub account – https://github.com/luisw19/graphql-samples
After a insightful and thought provoking presentation on GraphQL the Drones with APIs project had its latest update. Providing a lot of laughter to the evening’s proceedings. Including demonstration of flying the drone using REST APIs published via a gateway and Go back-end. This included the DroneDash presenting a visual presentation of the commands being issues via REST, as seen here:
All the code, API definitions and documentation for people to add or extend can be found in the meetup’s GITHub – https://github.com/oracledeveloperslondon/.
A few of the useful links used or mentioned last night are:
- Apollo Express
- GraphiQL – GraphQL Design Tool
- Cheerios Library for screen scraping
- Oracle JET toolkit
- Luis’ GraphQL Samples
- GitHub repository with all the drone resources
- API Documentation for the Drone, and the Drone Dash
- Request Bin (capture and display HTTP requests) https://requestbin.fullcontact.com/
The next meetup is planned for Monday November 19th. Topics will be published soon.
As a middleware (to use a fading term) or technical architect, I preferred not to get too involved in the detailed OS layer considerations when it can be helped (my Infrastructure Architect colleagues will always know more about NICs, port bonding, kernel versions etc etc than I ever will) and why I prefer to work with PaaS over IaaS.
But there is an undeniable trend where having a greater understanding of the OS is necessary, this is because we’re seeing PaaS expanding to cover code abstracted solutions such as Oracle’s Integration Cloud, Mulesoft, Dell’s Boomi etc. down to every things as code in the form of Terraform, Kubernetes, Docker and of course microservices.
So what does this have to do with OpenShift? Well to apply those heady aspirations we’ve had with middleware of “I can build my solution and run it on my platform anywhere” means in the world of microservices I need to find a common denominator on which I can be portable. This comes in the form of Kubernetes and Docker and we’ll probably see service meshs in due course (Istio, Linkerd etc). Docker obviously brings the need to understand the OS albeit not at the level of bonding network connections, but still a good level of OS knowledge to do things properly. Over the last couple of years there has been a fair bit of work to achieve this with the inertia of Cloud Native Computing Foundation (CNCF), Open Container Initiative (OCI).
After months of labour, the arrival of new family members for a couple of the authors the Implementing Oracle API Platform Cloud Service book as finally been published. The book has been included into Packt’s Expert series so, earns(?) the privilege of having photos of the authors on the cover. The book can be purchased directly from Packt (go here) or from book retails such as Amazon (here).
It has been an interesting experience. Whilst working as part of a team of four authors lightened the writing load, a lot more energy went into communication so things were lined up. If you want a challenge, why not read the book and try to work out who wrote which chapters!
It’s a bit controversial to say ‘Microservices are not simple’ given much is said about using Microservices to simplify and accelerate software delivery. So, how can this statement be made? It is a point actually stated in Chris Richardson’s excellent new book Microservice Patterns (avalable here and here), indirectly in Eric Evan’s Domain Driven Design (here). Martin Fowler in one his blogs says that they come at a premium (here). So, I’m not the first to say this, and wont be the last.
But the assertion that Microservices done right are simpler, and allow rapid delivery and evolution of solutions – a bit of a contradiction. As they say a picture is worth a thousand words, so take a look at this …
I have been wading through Eric Evan’s Domain Driven Design Book. As with many design and architecture focussed books I try to mindmap as I go so I have a quick reference resource. The mindmap for this book can be seen below and is linked to the WiseMap version which is dynamic.
In terms of of a review of the book, it contains lots of nuggets of helpful ideas and information but it is a rather heavy going to read. Some points feel over laboured such as the use of consistent language, at times it feels like half the book is dedicated to this one point. Whilst Chapter 14 – Maintaining Model Integrity sounds unadventurous as a chapter, I found this to have a lot of really helpful content such as going into the details Bounded Contexts and so on which is highly relevant to the world of microservices.