https://github.com/davidsielert/pfsense_fluentd

Built using Bootstrap 4.1, Font Awesome for frontend UX.

Backend is a Java Spring Boot Application utilizing JPA (Hibernate), Spring Security, Spring MVC.

I'll post a link when its finished!

Integration timeout	50 milliseconds - 29 seconds for all integration types, including Lambda, Lambda proxy, HTTP, HTTP proxy, and AWS integrations.

This can be somewhat conflicting if your new to lambda like I was, as the UI in Lambda has an option to configure the timeout for up to 5 minutes. What you need to understand is that this timeout is for the function itself. Amazon API gateway is a separate service that requires a response from the lambda function within 29 seconds or you will receive the infamous "Endpoint request timed out" response.

Your options are that you can use one of Amazon's other services like SQS to trigger the lambda function thereby incurring no timeout, but I'm guessing that like us, that would probably require a major overhaul to both your lambda code and what ever service is relying on it.

Luckily, we were able to put our heads together and figure out that even though the API gateway process times out the lambda function still runs (up to the 5 minute limit) it just has no way to return a response when the gateway times out. So we were able to quickly put our heads together and easily refactor existing code to POST to a callback URL. Problem solved!

$refs, while used on a normal HTML element will give you the DOM node, creating a ref on a component will give you direct access to its Vue instance allowing you to call methods, access properties etc.

export default {
    methods: {
        callChildComponentMethod() {
           this.$refs.myCompInstance.deleteSomething();
       },
       accessChildComponentData() {
           this.$refs.myCompInstance.someDataField.
       }
    }
}

This can really be useful, in my own cases instead of having to pass function refs back and forth between the parent and child as props. But just keep in mind the warning the offical documentation points out

$refs are only populated after the component has been rendered, and it is not reactive. It is only meant as an escape hatch for direct child manipulation - you should avoid using $refs in templates or computed properties.

So I have had the privilege of working with Vue + Vuex for about the last year or so. One of the more tediuous problems that I discovered early on with using these two libraries is that writing a getter and a setter for every form field and state value can get tedious really fast, and quickly become a nightmare to maintain! Read more on form handling from the Vuex documentation.

Solution

At first I remembered reading about Proxy Objects in ES2015 and I thought why not have a master mutator with a proxy object to set multiple fields, so I developed our own in house solution which worked for quite a while but then I discovered (Credit: Scott Conrad) the more fleshed out Vue-Deepset written by Branden Horiuchi.

How to setup

Branden's documentation on Vue-deepset is pretty good, but the Vuex implementation is a little bit confusing at first so heres a quick run down.

In your Vue Applications entry point (usually something like main.js).

import * as VueDeepSet from 'vue-deepset';
Vue.use(VueDeepSet);

Then in your store you want to wrap your global mutators in extendMutation so that deepset can insert its global mutator in the stack:

import * as VueDeepSet from 'vue-deepset';
const mutations = VueDeepSet.extendMutation({
//...mutators here.. 
 [types.MY_MUTATOR](state, value) { //old mutator 
        Vue.set(state.myVal, 'key', value);
    },
});

After this is done you have access to a couple new instance methods from your components

• this.$deepModel ( path:String ) - creates a proxy object from the given store path
• this.$vuexSet (path:String, value:*) mutates a value for the given path

So an example usage would be from a component

computed: {
    form() {
      return this.$deepModel("myModule.theForm");
    },

which will in turn let you use two-way binding via v-model directives on your form inputs like so:

As an added bonus $vuexSet is pretty useful as-well. Say you have a button that just needs to simply change a store value, this store value could be out of the scope of your current model per say, you could create a new $deepModel proxy object but instead you can do this

Toggle It!

I have found that pretty darned useful, and as a result I rarely clutter up my code with anymore one-off or single use mutators.
One of the great features as-well is that vuex-deepset works great with Vuex modules which I highly recommend using, for organization and separation of concerns.

Pro-tips

• Per the deepset docs and probably just general practice you should always create the objects that your deepModel and v-model references, I've gotten into a few nasty hard-to-debug exceptions by not doing so.
• Always create non-null (Usually Object or Array) value for the deepModel path I don't believe a proxy can be created on null values.

Hope this this is useful to someone!