Adam Miskiewicz was on the GraphQL Patterns podcast discussing how Airbnb slowly replaced a monolith Rails application with GraphQL. One of the key take aways from the episode is that GraphQL is not all or nothing, you can replace items slowly. Instead of worrying about how the backend resolves the data, focus on the implementation from the frontend/consumer.
Adam references an article and talk by NAME, both are well worth your time. The article, , explains. Accompany that article with his talk at GraphQL summit, there are both packed with useful information on schema designs.
Listen to GraphQL at Airbnb feat. Adam Miskiewicz https://overcast.fm/+OzkqecbOk
I subscribe to MobyCast, a podcast on all things Docker and a lot of AWS. Recently, they took a deep dive into the origin and history of DynamoDB.
Chris Hickman and Jon Christensen of Kelsus and Rich Staats from Secret Stache offer a history lesson on the unique challenges of data at “Internet scale” that gave birth to NoSQL and DynamoDB. How did AWS get to where it is with DynamoDB? And, what is AWS doing now?
These episodes are well worth a listen, even if you are not a "NoSQL" person.
When following agile, people abuse the "Agile" methodology and focus on being too itterative.
Agile does not mean you don't plan... - Jason McCallister
I see this often with a lot of companies... "we are agile so let's figure it out later". As an experienced software engineer, this drives me insane. Someone once told me "...10 minutes of planning saves an hour of implementation". Hearing that made me really think and changed the way I tackle projects.
As engineers, we love to jump in a get started but think about every time that you have started a project with a vague idea - how did your code turn out? Odds are... not that great and you probably had some rather messy code.
Its easy, I get it. We love to write code, that is why we do what we do. However, its ok to have a larger plan to achieve a strategic goal. Planning does not mean you are not being agile. We know things are going to change during discovery, so plan for change but be clear in your overall vision. I have seen so many projects go from a great idea to fail during implementation.
If you are still not convinced, do you remember a project that had only a small amount of planning. Do you remember launching the project and then the client asks for a huge change? How did you feel about going back to modify that code, and hopefully you had decent test coverage.
Agile is an excellent way to get down to the nuts and bolts of a product, but it does not mean you should not plan ahead.
Recently I had a need to use PHP to interact with the Google Spreadsheets API. With all things Google, it can be a little overwhelming to research. Luckily the folks at Twilio published an article on their blog (by Matt Stauffer) on interacting with Google Spreadsheets, well worth the read.