I started as a developer (later architect) at a medium sized enterprise which had it’s own flagship product. The job mainly focused on developing this product. The domain we worked on was pretty big (finance).
Now, the product had history. Years worth. And like with any software that has a long history, it has technical debt. But what it was also missing was technical leadership. Formally, at least.
Recently I got to work with DynamoDB once again. The service I had to build was rather simple: fetching data from a third party API and using DynamoDB as a cache. If we get a cache hit for the same type of request, we could simply return that and not have to request it from the third party.
For this service we had two identifiable access patterns:
Recently I’ve been working on multiple microservices. Some of these have been small Lambda functions, triggered either by SQS or SNS, and their job is to process the event, then dispatch it forward.
For a long time something always bothered me with Lambdas. I believe it was the fact that I couldn’t get my head around how they should be properly tested. It always seemed incredibly difficult to mock the dependencies, which I could not inject, so we developed routes in the code to get around that. That was way over a year ago.
As I had to work with…
Last week I took it upon myself to try and find out a suitable online documentation tool for our small team of three developers. Our code base had split into four repositories already and I wanted to make everyone’s work a little bit easier. Everyone worked on separate repositories, but needed information on all of them.
There were a few requirements:
I’ve been building Wordpress websites on and off for nearly a decade. It’s quick and easy for a small site, but I would never recommend it to be used for bigger solutions.
At some point, developing those PHP templates gets really boring. You do the same stuff over and over again with very little flexibility.
When a customer orders a website from me, I often do the design, development and deployment myself. Full package. Because of this, I develop templates from scratch. …
As of late I’ve been working with Material UI for a React project. I find such frameworks incredibly helpful when developing an application. I don’t have to write every front-end component myself, nor do I have to write much CSS. Everything works out smoothly and I can just throw a custom theme on top of the framework and it doesn’t look like another Google app.
The repository for this demo can be found on Github.
DataLoader-PHP repository seems abandoned, having it’s last commit made over a year ago. However, for our needs it works just fine. You can search for a more up-to-date repository or build a solution yourself if it does not suit you.
First off, install DataLoaderPHP using composer:
composer require overblog/dataloader-php
Now we have to add a
This tutorial contains two parts.
Considering you’ve made it so far as to implement GraphQL, I am assuming you have basic knowledge of what GraphQL is and how to use it.
If you are already too advanced to read through this and just want to look at the code, you can visit the repository I’ve set up for this article.
To start off, this is my first article here. I’ve thought about writing it for a while now. Ever since we planned and implemented what we call a moderately secure way to actually authenticate client-side requests against our API where authentication tokens are refreshed and old ones are rapidly expired.
I thought I’d share the idea. I will not be diving into much detail here by using big code examples.
We use JSON Web Tokens as authentication tokens. Tokens are generated when the user logs in with his credentials and contains information such as his username (or id). …