Teraform d1
I havent used teraform before but decided today to give it a whirl, I wanted to create a web hooked API route
which could be called by the other service. The API needed to have multiple routes linked to multiple lambda scripts
which would in turn be linked to multiple triggers for the web hooks. Each one will do a different thing, ie.
update a person table will trigger the /person API route I create, same for locations triggering /location etc.
So building this structure (along with all the IAM roles) surrounding it would take a bit of time and leaves the window
for me making mistakes. I actually think the teraform code was hard to read, and simplifying it with defining blocks/templates
where I can use JSON on a level above this to define the stuff I care about was more important. Everything which wasnt
shown in my high level JSON wasnt important for the overall architecture of the code. Getting a nice snapshot at what it does
and how it works was what I wanted. Running plan, apply and destroy helped me mess around with IP blocking also without having
to completely dismantle my structure, teraform added what extra was required.
I think after day 1, having small maintainable "projects" for teraform is the best. Everything being in there is good, but I need it split up otherwise it is too complicated. The hosted "state", keeping note of what has already been done by teraform on your cloud/monitored resources is a cool idea also. Honestly I dont think it would be too hard to program this myself, knowing that the API's are pretty simple and most of the teraform code simply passes through, OR creates a boilerplate which works with several clouds.
Was fun to mess around with, very heavily engineered for such a simple project however. I dont know if it was required in all honestly. Good learning for me, none the less.
Thanks for reading!
Bryn Lom • Software Engineer