Yeah, I socialized your concerns (as also indicated in my previous discussion about UTMs) about the DOS attacks to our Web Team.
They will be looking at that to ensure we are working around that risk.
It's impossible to work around, though. You have so few calls to give that metering them means your form becomes unusable.
For example, Marketo Forms are tuned to real-world legit activity and allow up to 30 form posts per minute per source IP. (You have to bear in mind that many people share the same IP addresses, in corporate networks and perhaps more notably at trade shows and other gatherings.)
30/min = 43,200/day = 4 times the base API limit of 10,000 (and that's making the huge and even irrational assumption that you aren't using the API for anything else). And that's for a single IP address! There's no way a system can enforce a posting limit that is low enough to stay under the API cap, while still allowing real-world use.
Sanford, doesn't the JSON array get overwritten every time though? I'm not clear on how we would get it there...I'll reread the docs and links you provided yesterday on the UTM discussion.
Nope, you use two fields: one for the individual JSON custom object as it comes in, another history field that's an array of all the past JSON objects.
The history field can either be append-only (if you use Marketo) or its internal objects can be updated (have to use FB for the updates).
A guide to how JSON interacts with Velo is here (also linking for Greg in a sec): http://blog.teknkl.com/marketo-json-fields-in-velocity/
On a related note, anything I should be reading up on to get better at dev? I read some people saying java, jquery, sql, etl, javascript, etc. Any other suggestions?
That's a tough one! jQuery: no. It makes you a worse developer to learn jQ before you learn JavaScript. I'm not sure anyone ever recovers from jQ. (Source: I interview developers. 
)
Native JS: absolutely. First priority IMO.
Java: Tough language to start with. Within the Marketo ecosystem, the advantage of knowing Java is that it will skyrocket your Velocity skills. But starting with Velocity and understanding which parts are equiv. to Java is probably better.
SQL: Hard to say. Database design and writing elegant SQL can take a decade to get right. Within the martech world (as a consumer of martech services, as opposed to authoring new services) I'm not sure this has much of a place.
ETL: A broad discipline. At the low level, includes SQL, REST/SOAP APIs, and even FTP and other file transfer stuff. At the higher level, it means becoming a power user of a package like MuleSoft, Boomi, et al. I think looking at the higher level is a good call, but I know that before I was a developer (I used to be a purely systems guy) those apps made a lot less sense to me.
If it were up to me, I'd recommend:
- Native JavaScript for the browser, meaning understanding the interaction between the HTML DOM, HTTP/Ajax requests, and JS. This has an immediate payoff in powering up Mkto forms and LPs.
- Native JavaScript without the browser, as in what you'd use in FlowBoost or other headless environments. It's exactly the same language, but since you're attacking pure data without the visual distractions, can feel totally different. Understanding objects and arrays... crucial.
- Velocity deep dive. So good for beefing up Marketo functionality. But not only that, it also helps you adopt efficient, collection-centric (heavy use of arrays/objects) coding practices that can be used in any modern language. If you don't code efficiently, Velo is really hard to maintain.
.png)