Posts

Improve your local web app development with Docker

Have you ever had a situation where there was a bug in some deployed application, but the simple act of running that application locally made the bug impossible to find? It could've been that there was no local infrastructure (e.g. databases) to back the running services. Or port-configuration was hard-coded into the application (so it collided with other ports on your host machine; people love to hard-code to port 8000 , 80 or 8080 ). Or, scarier still, the application was never actually run locally because it was deemed too difficult in the first place (in which case, you wonder how the deployed application worked at all)? In an age where we have Docker to effectively ship the containerized machines that our applications run on, there really isn't an excuse for making local development a more consistent experience. If there is greater confidence in running code locally, it becomes quicker to spot and fix bugs. It becomes quicker to onboard new developers and make them pr

Shifting from OOP Web Components to FP: A brief look at Elm

A couple of months ago, someone asked on the JavaScript subreddit how functional programmers handle dealing with unavoidably immutable actions, like DOM manipulation. I gave my $0.02 , saying that imposing functional programming constraints on your DOM-specific code is more trouble than it's worth, and to leverage FP on the boundaries of your code that don't interact with it. I ended with a recommendation for Elm , which is a neat little functional language that compiles to JavaScript, if someone is fully intent on writing more of their application in a functional style. Recently I've spent some time playing more with Elm, and I've actually been enjoying it quite a lot! The documentation has improved immensely over the last few years and it is a lot more friendly getting on-boarded. I learned functional programming about 6 years ago at university -- learning Haskell for the FP course and Principles of Programming Languages course) -- but never spent time applying it

Using the POST method for HTTP search queries

When designing RESTful services where data is queried , we tend to map this querying functionality to an endpoint that uses a HTTP GET method. This is good because GET is specifically designed for data retrieval . However, there are scenarios where this isn't a sufficient solution. For example, if the search query becomes too complex -- or long -- to reasonably specify in the URI, we may want to send a request body instead: putting the query inside the payload. This isn't part of the HTTP specification though: Not all requests have one: requests fetching resources, like GET , HEAD , DELETE , or OPTIONS , usually don't need one. so it is unreliable to assume that you can send data in this way and have it interpreted correctly by servers. Another situation is when the query contains data that you don't want to expose in the URI: if there is personally identifiable information (e.g. a person's home address, which you are using for an insurance query), then

The Value of "Value Objects"

Herberto Graça recently wrote a great summary on Value Objects , and I commented on it on Reddit , saying: ...something that could flesh out the case for value objects [is] the fact that it allows you to model complex rule interactions by representing the concepts of the core domain and letting them interact as they would in said setting . This results in code that reads very much like "business-speak", making it easier to translate back and forth from the stakeholders to the developers. The comment has its own illustration of the idea, but I wanted to expand on the utility of value objects in a bit more depth in this blog post. If you need a primer on what value objects are in the first place, Graça's article is a great start. A lightning-fast DDD reminder Within Domain Driven Design , we separate our code into at least two distinct models: The Application Model , which crystalises the top-level use-cases (or commands ) of the system (e.g. ApplyForFinancialLoa

HATEOAS in the context of microservices

In the rise of RESTful, microservice-based architectures in our web applications, HATEOAS seems to have fallen out of favour. This is curious, given that the creator of REST specifically advocates for HATEOAS , going so far to say that REST isn't truly REST without it. There have also been articles disparaching it as a practice , claiming that there isn't a sensible alternative to the current practices. So this article will re-evaluate HATEOAS's usefulness, specifically in the context of modern microservices. I'll quickly outline what HATEOAS is first, and then walk through a case study which will justify its usage. What is HATEOAS HATEOAS is a long, needlessly intimidating acronym for *H ypermedia a s t he E ngine o f A pplication S tate*. Hypermedia is: ...an extension of the term hypertext , [...] a nonlinear medium of information that includes graphics, audio, video, plain text and hyperlinks. and hypertext is just text that you can view on your computer