Serverless Framework - deploying multiple AWS cloudfront distributions - node.js

I want to have multiple (based on stage param) AWS cloudfront distribution.
So if --stage dev passed it would deploy a different CloudFront dist than --stage qa.
Each stage should update/create a distribution based on the stage params.
Is it possible to achieve with serverless.yml?
I have found the following plugin serverless-api-cloudfront , not sure it will create additional distribution if domain name is changed, and not sure it is possible to add origins with this plugin.
Thanks

Is it possible to achieve with serverless.yml?
Yes. Yes it's possible and it's already built in. Your config will be simpler if you use the plugin serverless-api-cloudfront (rather than declaring a AWS::CloudFront::Distribution resource yourself). You will get one distribution-per-stage, without having to jump through any hoops.
** EDIT
Expanding on my original post: It does seem that the serverless-api-cloudfront plugin's README is lacking in usage examples (at the time of this writing). I do suggest that anyone reading this post should go to the plugin's github and help the author by PR'ing a better README.
Here's a link to a blog article I found that shows an example of how to write up a AWS::CloudFront::Distribution directly in your serverless.yml. It's only 1 resource, so you may not even want to depend on a plugin anyway. https://medium.com/yld-blog/caching-in-with-cloudfront-using-serverless-5a174651ab14

Related

Environment specific configurations for Spartacus on ccv2

I have a requirement to use a different apiKeyGigya per environment specific configuration for Spartacus on ccv2.
I tried to solve this by using multiple environment.xxx.ts files in which I defined the apiKey. However, in ccv2 environments only one command is being executed which is "build:ssr" in the build process.
I use the following tags for the corresponding environments:
Environment Production "build:ssr"
Environment Development "build:ssr-d1"
Environment Staging "build:ssr-s1"
Does anyone have a solution for this case?
Could you support me, please
Does anyone have a solution for this case?
There is no support for different build targets in Spartacus and SAP does not offer an official solution for this.
A possible solution to this, is moving your environment specific properties to your backend properties files. With the manifest, you can load in different properties files in the different environments.
You then create a new OCC endpoint, where you fetch your environment specific configuration based on the environment key. This can contain different values per environment.
For performance reasons, you could also have this endpoint serve all configurations in 1 response, cache this in Spartacus and use accordingly.
There were quite some discussions on this topic on the github repo. https://github.com/SAP/spartacus/issues/5772

I have a GitLab self hosted running, but how does the frontend work?

I set up a GitLab self-hosted instance and its working fine, my problem right now is that I don't really understand how the frontend works. Mostly because I've been focusing on the backend and because I couldn't find documentation about it either. I wish to understand how I can comment out things I don't want to show for the user or in the overall design, change aspects and text, and overall have control of the frontend.
I'm running on Debian 9, the setup was made with Bitnami using Google VM. As far as I understand I have to manually change the files I want, but I really don't understand the structure of this type of frontend.
What language do I need to know here and where should I find the documentation, how to find the correct directory and files, etc.?
While GitLab doesn't officially support any type of "custom frontend", what you can do is:
Fork GitLab
Use the GitLab Development Kit to implement your changes
Run a Source Install of your fork
The frontend is mostly written in HAML (for the server-side bits) and Vue.js (for the client-side bits).
Note: Even an Omnibus install copies raw ruby and javascript files somewhere, and since they’re physically on the system, they can be manually manipulated and hotpatched, but that’s not really a sustainable way of introducing changes to the codebase.

Octoperf - Specifying custom / third-party dependencies - where does Octoperf pull dependencies from?

I am exploring the option of using Octoperf as a hosted solution.
One thing that I need is the ability to call some custom libraries (either Java or Javascript / Node.js).
In the SCRIPT PRE and SCRIPT POST examples in the Octoperf documentation I see calls being made to import com.google.common.base.Stopwatch. However, it is not clear to me how Octoperf knows where to pull this dependency from.
Does anyone know if there is a way to specify this and how?
this dependency in your example is already included in every JVM. If you need to add other dependencies in OctoPerf, just place them in the files menu of your project and they will be copied to lib/ext when the test is started:
https://doc.octoperf.com/design/edit-virtual-user/configuration/files/

Hapi Swagger skip certain endpoints

Since the npm module hapi-swagger doesn't support file upload endpoints I need a way to skip certain endpoints in my tests.
I've checked the docs and there's no beforeEach or any way to check which endpoint is which during the test runs.
Currently I've just got my environment set to TEST and have an if in the target handler but that's messy and complicated.
Is there any way to skip endpoints?
I am not quite sure of what you are trying to achieve above. The use of tags can create groups of endpoints. Its often used for pre-release or beta groupings. This maybe of use to you.
The latest version of hapi-swagger now also supports basic file uplaods, so you maybe able skip this issue.
Both tags and file uploads are cover in the project readme and code examples of there use can be found in the https://github.com/glennjones/be-more-hapi project.

Sandboxed plugins for Node.js

I'm a complete Node noob, so I apologize if this question has an obvious answer.
I'm looking to create a web app that will run plugins from untrusted sources (i.e. community submissions). So I need to lock down those plugins into a sandbox where only certain access is allowed (can't write to disk, etc.). Ideally, the plugin would only be able to use certain approved node packages and APIs.
Is this possible in Node? If so, can you point me toward a package or documentation that will get me started?
Here is a small list of projects that can help you:
https://github.com/gf3/sandbox
https://github.com/hflw/node-sandbox
https://github.com/bcoe/sandcastle
https://github.com/wearefractal/boxy
I suggest the first one (sandbox) since it's more mature.
I would also contribute to the list with my library: https://github.com/asvd/jailed. In addition to the sandboxing of the untrusted code (in a restricted subprocess), it gives an opportunity to export any set of functions inside the sandbox thus defining a custom API for the sandboxed code.

Resources