Issues

• One functionality of the iFrame is to validate that correct credit card (CC) information is entered, and upon failing to enter this data, we wanted to show a modal with the reasons for failure, but the modal was taking incredibly long to show up
• Upon entering valid payment information, the iFrame logic would validate this through Chase and call a function the callback file to redirect back to the home page, but even though the redirect via router.navigate was working, the styles and loading of data in the home page would be painfully slow
• Even after being rerouted back to the home page successfully, other options in the page, such as tabs, were not responsive, and if they did change pages, the data in those pages would be missing
• If you just allows the page to sit, after a while the data would load and the styles would load, and the page would look normal, but it was too long

First solution

Initially, it seemed like using tick() from ApplicationRef to "explicitly process change detection and its side-effects". This worked like a charm for the modals, and instead of them taking forever to load upon the iFrame submission detecting an error, it was as quick as expected. I thought I had won this war. However, when submitting the iFrame successfully and being redirected to the home page, I found that the slow loading issue continued! 🤯

Second Solution

This is when NgZone came into play. Looking back, it makes sense that this is the Angular service I needed to use, because it is a "...service for executing work inside or outside of the Angular zone". In my case, when the iFrame made the call to Chase to validate the payment information, succeeded or failed, and returned to call a function in the vendor provider callback file, that callback file was living outside of the Angular world. The callback file lives in a publicly available location, e.g. /assets/html so that the Chase iFrame can access it. Therefore, when the iFrame calls a function this callback file, that file is outside of Angular and needs to be told to run inside. Here is how this works for my use case.

i. In my angular component, I imported NgZone in the constructor:

constructor(
    private zone: NgZone,
    @Inject('Window') private window: Window
){}

ii. The functions that the callback file needed to execute, not only had to go on window.top, but needed to be wrapped the NgZone:

private setupWindowFunctions(){	(
	this.window as { [key: string]: any })['funct1'] = (res: VenRes) => {
		this.zone.run(() => {
		this.func1(res); 
	});
};

Now, when the iFrame comes back with a successful validation or error, their callback file on our web app's public folder, triggers the window.top function, such as func1, and since this function lives within the NgZone, it is executed seamlessly, avoiding the slow data load that I was seeing before.

I think is is a nugget of knowledge that only experienced Angular developers might know of the top of their hear, so hopefully it helps someone out there, cause I certainly did not know this and own it to my awesome team to have figured it out.

Today I learned the hard way, and much later than the ideal case, that the AWS CloudWatch event cron settings does not support advanced cron configurations!

I created an AWS Lambda with EFS and wanted to schedule it to run every other Monday. After trying different solutions in the cron settings, the only config I could make work was one to run the lambda every Monday:

0 14 ? * 2 *

If AWS supported more advanced syntax, then we I could have had two different jobs running the lambda, one on the first Monday and the second on the third Monday:

0 14 * * 2#1 * - to run lambda on the first Monday of the month.
0 14 * * 2#3 * - to run lambda on the third Monday of the month.

We can't have nice things, so this cannot be scheduled. Instead, the best I can do is, every 1,15 days in the month, which don't necessarily land on Mondays:

0 14 1,15 * *

The next best thing will be to execute the lambda every Monday and in my lambda code, check if the Monday is the 1st or 3rd Monday of the month and then execute the lambda code only in these cases.

🤷‍♀️

Will need to look into modifying my code, but it would be much easier if it could be done from the cron settings.

If you want to validate the query string of a request, it does not work do to:

export const mySchema = {
  $id: 'path/to/schema/file/mySchema.json',
  query: {
	properties: {
		url: {
          type: 'string',
          pattern: 'https?://.*',
	    },
	},
  },
  required: ['url'],
};

Instead, it has to be:

export const mySchema = {
  $id: 'path/to/schema/file/mySchema.json',
  properties: {
    url: {
      type: 'string',
      pattern: 'https?://.*',
    },
  },
  required: ['url'],
};

I don't think this was clear in the documents, but seems like an important detail to keep in mind.

Also, the pattern, which is a regex, must be surrounded by quotes 🤷‍♀️

Commands I find useful:

knex.raw(SELECT version())