To avoid recurring DB calls for data that could be cached im looking for a method to cache returned data in shopware 6. Does shopware already provide a cache or do we have to use symfony cache extension towards a redis or the likes?
Kr Ole
Searched the shopware documentation without finding a good answer
Shopware comes with different layers of caching out of the box, you can find information on how to activate them and how you can configure them in the official docs.
Keep in mind that most of the caches are optimized for the Store-API/Storefront, so in general requests to the Admin-API are not cached.
Related
I need to purge my users on an OpenStack project easily, through an API call.
Just like this CLI command :
neutron purge PROJECT_ID
Which is available in the Neutron project docs, but with an API call.
I couldn't find the API, so actually my question is :
1. Isn't there such an API?
if there is not,
2.why?
Is there a specific reason for?
I checked out the source-code of the clients and neutron-server, but unfortunately there is no dedicated endpoint in the REST-API for this functionality.
This feature is only supported by the neutron-client, but not by the openstack-client. When you run neutron purge PROJECT_ID all what the neutron-client does inside the python-code of the client, is to list all resources which are related to the given project and then iterate over this list and send a delete to the neutron REST-API for each single resource. So its only a simple automatism in the python-code of the client and not a specific endpoint on server-side.
See the specific function inside the code here: https://github.com/openstack/python-neutronclient/blob/master/neutronclient/neutron/v2_0/purge.py#L63
Based on my experience with openstack and its community, I think it was done like this, because it was easier to add new code only into the neutron-client. When this should have become a new endpoint, this feature had to be implemented in neutron, openstack-client and openstacksdk as well. Each repository has its own team. This purge-feature is so small, that it was not worth to persuade all 4 teams. The more components you try to update for one simple feature, the harder it is, because the one who wants to bring the feature upstream, is responsible to bring the teams of all required components together and when only one within the core-teams have a problem with your implementation, you have to start nearly at the beginning. So it can easily take over a year or two to bring a cross-component feature like a new endpoint upstream, when you are not part of the core-team by yourself. So to bring the feature only into the neutron-client is quite easy compared to a cross-project contribution.
This is at least the reason, why I would implement this feature only in neutron-client too, or only in the openstack-client if possible, instead of adding a new endpoint, when I would bring this feature upstream.
I'm studying Laravel REST, but maybe this does not limit itself to Laravel only.
Reading through articles and questions like Laravel RESTful API versioning Design or How to organize different versioned REST API controllers in Laravel 4? (and a lot others) you get the concept that it's very important to version a API when building one.
But it seems to me that it may be a lot troublesome to manage different versions of your API using the separation of folders
/app
/controllers
/Api
/v1
/UserController.php
/v2
/UserController.php
Looking from a near future, I can easily imagine having 30 files at v1 and 40 files at v2, for instance where about 20~25 files might be identical. Doesnt' this cause more troubles than solution?
If the changes are large enough, they will probably warrant a new Controller. But if not, you could pass the version number to the Controller instance, and route to the same controller. Then use that number to change behavior.
We have a mobile app which calls a REST API to get the list of tiles to be displayed on the mobile primary screen. The authentication mechanism is AUTH Token using which we uniquely identify a user. The menu keeps changing depending on the version of the app. For this we have two approaches.
/api/tilemenus (Pass auth header only and not version)
Retrieve auth header and lookup the version of the app in the db table (We also store the user version in our database and update it whenever user upgrades the app) and return the data accordingly.
/api/tilemenus/1.2.2 (Pass auth header and version as well since client knows its version itself)
Here, no DB lookup is required since version is getting passed in REST request itself.
Which approach is better? I think approach 2 is better since we can pass the caching headers to cache this API for each version. For approach 1, there is no implicit way to discard this caching, when the user upgrades the app.
It is common to pass API version in the URI path (check out this question too). I'd suggest to use the second option, although rewrite it as /api/1.2.2/tilemenus, which looks more similar to how APIs operate on a bunch of popular websites.
In my opinion, #2 is better, because you enforce the guarantee that a specific URL always returns the same resource/data, and, yes, you can safely cache it.
Plus, it makes it easier to track version usage just by analyzing HTTP server logs.
And it even spares you the effort of keeping track of user version, since the #2 makes it explicit by the request URL itself
I am exploring the support and usage of CDN in a Hybris solution.
I am a Hybris newbie and am working through the wiki to understand the product better.
I am unable to find the answers based on my search of CDN in conjuction with Hybris.
What are the typical CDN Providers that are used in an Hybris solution? Any references would be helpful.
Appreciate any pointers.
PS: This is not a programming question. If this question is considered inappropriate let me know and I will delete this.
Why would there be any preferred CDN providers? You can choose any provider you want but take these questions into consideration:
How is the TTL defined? By cache headers (set by hybris) or manually set on the CDN’s side? The possible cache headers are Cache-Control, Surrogate-Control and Edge-Control. Akamai for example uses Edge-Control but I’m not aware that any other CDN uses this header.
The choice of your CDN will also depend on where the content will be required: do you need to serve it worldwide or do you want to improve your quality of service in certains areas only by adding POPs?
Does content sometimes need to be invalidated from the cache? If yes, check if there is an API to do so (will require work to make hybris communicate with the API).
The easiest solution would be a basic cache where the TTLs would be defined in the CDN’s configuration.
If you choose to go with cache headers, this is a quite simple solution to setup in hybris, you only have to define a request handler that will take care of them.
Hybris is usually used for some sort of ecommerce site. I have seen great results by using ImageEngine.io for an image specific CDN for Hybris. ImageEngine optimizes images on the fly which makes your site load faster. Worth a look: http://imageengine.io
Overview:
We have a rails REST API app that's gonna be published soon together with client app (single page app written in JS) . We intent to deploy new stuff on almost daily basis. For now the API is only used by us internally.
Questions:
How to manage deployment because we deploy each app separately?
Should we always deploy them together? Should we raise API version for each deployed change?
How to reload JS app when new version of API is available?
Should we not change the API version but keep backwards compatibility in mind? So only add new keys in JSON responses, no renaming, no deletions, no changing of URLs, ...
Are there any best practices described somewhere about this particular problem?
It is considered a best practice to only version a RESTful API when making a breaking change.
I would strongly suggest not releasing the API to the public until it has stabilized more. As long as it is internal-facing only, the frequent changes won't be as big of a deal. Once your API goes public, you'll want to limit the number of breaking changes (new versions) as much as possible, so work with your best customers before your public release to make sure the API is adequate, and try to design it with backwards compatibility in mind.
You should only need to pair the releases if there's a breaking change on the API side. Pairing them or not may be a business decision ("It's easier for our customers to have one version number to worry about than two").
You might also consider resetting the version number at release time so that the public is given the stable API at version 1 instead of 18.