I would like to implement this in an Apigee X proxy and ....
Can you explain further about your goals w.r.t. "implement this in an Apigee X proxy"? The reference architecture is to use AppEngine (or Cloud Run or Functions) for hosting application logic, and use Apigee for API Proxies. The API Proxy is intended to do things like: validate inbound credentials, route to upstream systems, mediate security, transform payloads or API interfaces (act as a "facade"), and similar. It is not a good pattern to use an Apigee-hosted API proxy as a "container" for application logic that reads or updates databases.
- In terms of performance, is better option use Datastore with Service Callouts or use KVM as database?
I recommend that you defer optimizing for performance. First get the architecture right, get the building blocks right. Performance is a concern. It should not be the primary or sole concern when selecting the components and designing how they work together. So I think your first question is not a good question to start with.
A better question: What are the right components? The Apigee KVM is not a transactional database, and you should not treat it as such. It is not optimized for storing or caching application data. It's primarily intended to store metadata that can be used with API calls. Metadata might include: routing information, data associated to service-level, default values for particular clients or apps, and so on. So I advise you to not try to use Apigee KVM for storing general application data. It's not the right choice for application data. A good place to store application data is in one of the Google Cloud data storage options. If you want caching, a good choice for that is Cloud MemoryStore (a managed Redis or memcached), or... if you're committed to App Engine, and you find the programming model easier, then you can may wish to use the Memcache that is embedded in App Engine.
- to support multi-region, are the KVM datastores in the same region that the Apigee Instance?
the datastore backing the KVM is distributed and multi-region.
- do you think it is better option to to use Cache Policy or a MemoryStore instance of App Engine Memcache?
If I were designing a traditional system, that had application logic, data (with some ability to cache it), and APIs, and I would look at using
- Cloud Run or App Engine for application logic
- one of the appropriate data store systems for data. (here's a good review of options and guidance on deciding). You will notice that Google Cloud Datastore is not listed in that review. Per the website for Cloud Datastore, Google recommends that you consider using Firestore for document storage.
- MemoryStore for caching
- Apigee for API Management
There are other options. For example, you can build ALL of that capability into a single app. You could use Java, embed the ehcache library for caching, use JAX-RS for exposing REST, write your own logic for verifying OAuth tokens and logging analytics data, and embed SQLite for in-app data store. Or you could do something similar with C# as the language. Or nodejs. Regardless of your language, host it all on a VM, and boom - the problem is solved with just one application element. This WILL WORK. But what if you have requirements to handle concurrent load, to be consistent with an existing portfolio of APIs, to connect to existing data stores, to scale out, to allow a team of people to update the system, to have audit controls on changes to data or logic, to have other application modules that might access the same data, and so on... in other words, what if you have typical enterprise requirements? In that case, this design approach of embedding everything within a single code base may not be the best choice. In that case, using dedicated infrastructure for the different functional areas may be wiser.
LinkedIn
Twitter
