Some questions and thoughts regarding Hosted Targets development / deploy / updates

[ignacio_rojas]

Description: TLDR I want to know if is it possible to update hosted target files without re deploy or updateing a apiproxy

To give some context we have today a very large app running as a node target in apigee today (9.1 MM/24 HS). We are moving the app from the nodescript to hosted target as deprecation is coming soon.

There are some quirky things with the new hosted target, nothing to died for but still...

I struggled finding out that putting your app running in port 3000 wont work, if port 3000 is not available at least you could mentioned it in the docs.

With node apps you could upload your app in zipped bundle and on deployment, apigee would unzipped, deploy, do whatever, etc...

Rumbling aside what I would like to know if there is a way in which we could hot update or update files directly to the hosted target with out redeploying or updating the apiproxy such as the is a way to do it with javascript policies files.

E.G.:

$ curl https://api.enterprise.apigee.com/v1/organizations/myorg/apis/weatherapi/revisions/6/resourcefiles/j...  -u email

Is this possible to do with hosted target files,

We are using maven to deploy plays nice with jenkins, sadly apigeetools is more for baby apiproxies.

Any insight from any experts, cause apigee support wasn't that helpful.

[dchiesa1]

You raise good points in your rumblings.

I would like to know if there is a way in which we could hot update or update files directly to the hosted target with out redeploying or updating the apiproxy such as the is a way to do it with javascript policies files.

First, the answer: No, there is no way to update "just the Hosted Target code". (or if there is, you shouldn't use it)

A few additional points regarding your question.

HT was intended to supplant the Node runtime; logically it's part of the API Proxy bundle even if the node code does not run within the message processor. Because the HT code is part of the proxy bundle, it was never a requirement to allow the HT stuff to be updated independently of the proxy bundle.

If you want to update the node code independently of the proxy bundle, then... I suggest you migrate from Trireme (node target) to App Engine, or Cloud Run (http target).

As you point out, today it is possible to update a single apiproxy-scoped resource file. But, you should take care when doing that. Apigee is moving to a new architecture in which the apiproxy revision is actually immutable, which many people would say is the "right way" of managing revisions. (It doesn't make sense to have revision 7 of a proxy have potentially two different versions of a JSC file.) So I would suggest that you avoid the use of that API call.

Related to that, I think we should document that API as deprecated, and I'll raise a ticket to do so.

[dchiesa1]

@Prithpal Bhogill

@srinandans - Just making you aware.

[ignacio_rojas]

I completely agree with revision been unmutable, specially for prod, but focusing on development, the amount of wasted time waiting for deployments is absolutly absourd. But I guess having our node app in hosted target is a bad choice to begin with. Just wanted to know if there were any options from the time being to improve our dev quality of life. This is a key component for our digital ecosystem as change is difficult to make/implement etc.

We have a inhouse built tool that when detects a change in your local resources/jsc autosyncs with the api proxy you are working on so you don't even have to restart trace to test what you are developing... right know there is no other way to reflect changes on HT other than deploying a new revision.

[dchiesa1]

right now there is no other way to reflect changes on HT other than deploying a new revision.

correct. Unfortunately, that's the case.

[dchiesa1]

The amount of wasted time waiting for deployments is absolutly absourd.

Pardon me, I didn't mean to ignore this comment. I should have said: I appreciate this feedback too. I know what you mean. We are working to make deployments faster, and in particular in the cloud today deployments do succeed much faster. But there's still room for improvement and room for making the developer experience better.