Forem: Kyam

Laravel: Bind an interface based on request parameters

Kyam — Thu, 26 Nov 2020 05:07:05 +0000

Recently at work, we encountered a problem that I couldn't find a solution to anywhere. So I thought I'd share our process and solution to help anyone else who might come across the same problem.

The Problem

We have an application with a small set of users. For reasons I won't go in to, if one user hits a certain Service class, we wanted the service to call one of its dependencies, DependencyA. However if any other user came through we needed the service to use DependencyB. The service looked something like this

private $depA;
private $depB;

public function __construct(DependencyA $depA, DependencyB $depB)
{
    $this->depA = $depA;
    $this->depB = $depB;
}

public function buildRequest(Request $request, string $user)
{
    if ($user === 'userA') {
        $stuff = $this->depA->doThing($request);
    } else {
        $stuff = $this->$depB->doThing($request);
    }

    return response()->json($stuff);
}

Which looks reasonably neat. However, the problem for us lay in the fact that in no scenario will both of this classes dependencies be used - UserA will hit depA but never depB, and UserB will hit depB but never depA.

Ideally we want a scenario where the service only knows about the dependencies it needs for a given operation. We could implement a separate route, and service, for the two user groups, but we felt we could fix this with a code solution with minimal duplication.

Only care about interfaces

So, where do we start? Well, both dependencies do a similar job, just different results, they both have the method doThing. So we could make them both implement a shared interface and type hint our service dependency by the interface:

private $depA;

public function __construct(Thingable $depA)
{
    $this->depA = $depA;
}

public function buildRequest(Request $request)
{
    $stuff = $this->depA->doThing($request);

    return response()->json($stuff);
}

Neater, right? Or at least less code.
Previously, when our service needed DependencyA and DependencyB, the Laravel IoC container would find those concrete classes and inject them into our service. However, now we only type hint by the Thingable interface, how does Laravel know what to inject? Somewhere, based on the request params, we need to tell it something like:

App::bind(
    'App\Thingable', \\ The interface we want to bind to
    'App\DependencyA' \\ The implementation - or DependencyB.
);

At this point it is worth knowing that the users name is being discerned by the URL they are hitting, eg api/kyam/url

So we need to do the above somewhere where
a) we have access to the Application and
b) we have access to the request parameters.

What we tried

Middleware

We currently have some middleware that checks for the user name, so maybe we could hook into that flow and set the binding at that time?

public function handle($request, Closure $next)
{
    $userName = $request->user_name;

    if ($userName === 'userA') {
        App::bind(
            'App\Thingable',
            'App\DependencyA'
        );
    } else {
        App::bind(
            'App\Thingable',
            'App\DependencyB'
        );
    }
    return $next($request);
}

So, while we definitely have access to the user name here, we had problems setting anything with the application. It seemed like the App hadn't booted up yet, and so we couldn't set anything up on it. This makes sense, because we are in Middleware, which all happens before we hit the actual application, so it stands to reason that we can't access application code yet. Moving on.

App Service Provider

This is where you are supposed to set your application bindings, in the register method.

public function register()
{
    $userName = $request()->user_name;

    if ($userName === 'userA') {
        App::bind(
            'App\Thingable',
            'App\DependencyA'
        );
    } else {
        App::bind(
            'App\Thingable',
            'App\DependencyB'
        );
    }
}

Here we definitely have the ability to set Application Bindings, so no problem there. However, getting parameters off of the request proved to be a problem. A Laracasts thread from 4 years ago suggested some solutions, but we couldn't get any of them to return us what we needed, and so this solution wouldn't work for us either.

Controller

Next, as a bit of a stab in the dark to get something working, we tried to set dependencies in the Controller before the code hit our Service. This did not work. The problem here was that the Controller depended on the Service, and the Service depended on a Thingable which wasn't bound yet, and so the Application struggled to load before we could set our dependency. We were in last chance saloon, and soon we were going to have to revert to our two-dependency solution we started with, for fear of dumping endless time into an unfixable problem.

App Service Provider, Revisited

Looking on the Laravel docs, we found out about Contextual Binding. We weren't sure that this would work, but we were willing to try anything at this point! Our code looked like this:

public function register()
{
    $this->app->when(Service::class)
        ->needs(Thingable::class)
        ->give(function () {
            return request()->user_name === 'userA'
                ? $this->app->get(DependencyA::class)
                : $this->app->get(DependencyB::class);
        });
}

What is this doing? It is setting that when the App needs to make a Service class that needs a Thingable, run the following callback function. This will then do our user check logic, and return the correct dependency.

This worked. Why? Well, I don't really know. I presume that we are running this after the app is booted, and so request() returns us what we expect. But we haven't constructed the Service class yet in our code, and so we are able to make changes to its dependencies. This is also nice because we are still able to set these dependencies where we are supposed to, in the AppServiceProvider.

And that's it! Hopefully this is helpful to anyone else who might find themselves in this situation, but going through this problem helped me understand how Laravel dependencies are loaded and hopefully it did you too.

And if anyone has any more details to fill in the I don't really know why... bits of this, or another approach to solving this problem I'd love to learn more!

Advice to myself a year ago

Kyam — Tue, 11 Jun 2019 19:05:36 +0000

Hey, it’s me - you a year in the future! I know, you've just finished your coding bootcamp and that previously your experience with programming wasn't much grander than getting your laptop to run “Hello, world” in Python, but soon you will accept your first job as a programmer - and you’re going to love it! You're going to do a great job, but you could have done even better, and so I thought I’d pass on to you the gift of hindsight to help you make the most of your first year in the industry:

Get stuck in - You're not going to get a job at a brand-new startup, so you are going to have to get to grips with some ☠️legacy code ☠️. It can be a staggeringly difficult to navigate your way around, while keeping in mind what you have found and what you are looking for (and why you ever even started...). It can be incredibly daunting to look at the hundreds of lines of code, and it’s entirely natural to feel overwhelmed. The only way to get over this is to get stuck in - start wading your way through (by yourself, where you can), trying your best, and you'll get used to the code and how it has been written - you will soon realise that you know more than you thought you did.
Get bored - Read my blog post here about why I think it is important to allow your mind to wander. The TLDR is: try and let your brain recover by giving it some time, every day, of peace where your mind isn't getting saturated by podcasts, twitter or reddit. Get bored and let yourself relax for a bit. It has done wonders for my state of mind.
Get feedback from your peers - You are going to join a team where your colleagues have a lot more experience than you. Rather than feel disheartened or discouraged by this, you should make the most of this opportunity and take advantage of their knowledge. Try and expose yourself to their skills by teaming up for some pair-programming, ask them for some feedback on your approach by regularly asking for it, and (more importantly than anything else) get them to review your code. Having your code reviewed not only gives you confidence that you aren’t going to break the product, it also lets you know where your shortfalls are and gives you an opportunity to know how your colleagues would approach problems in ways different to your own. It can be quite easy to be offended initially, or take code review comments as a criticism of something that you have created, but it’s important to view the code not as your baby but as something that your whole team are working together to create and perfect.
Give yourself a break - Programming is hard, and no-one knows everything. It’s really important to acknowledge this early, as you will be working with people who know a lot more than you which can lead to you feeling inferior or that you aren’t actually good enough (also known as imposter syndrome - something I’m not going to try and get into, but these blog posts might help you feel a little better about it). Remember that you are brand new to this, and still learning, and at some point in the past those really experienced guys in your team were also in this position once and they made it - so can you.
Look stupid - So, you hate asking questions that you know everyone else already knows the answer to, and you don’t want to waste everyone’s time (or look stupid) by speaking up. The thing is, no-one cares to remember you asking that question, and may actually respect you more for having the guts to speak up. Also the chances are good that someone else in the room doesn’t know either and you are helping them out as well as yourself. So ask, fill your knowledge gap and potentially unwittingly help someone else who is afraid to speak up. If I still haven't convinced you, make notes throughout the day of anything you didn't understand and read up about it when you get a chance.
Don’t put off starting that project - It’s really easy to think up that cool project you’d love to start but can't shake the “I’ll just wait until I know (insert technology here) better”. By the time you know that technology better, you’ll also want to perfect your other tech skill too, and you’ll never get there. Just dive in and start something; you'll probably realise that you need to know more about yet another technology along the way anyway - but at least you will have started something and know exactly where you need to focus your energy and time.
Plan your study time - One thing that I wish I had done early on is to plan what I was going to study. I’m really lucky that my workplace offers specific training time each quarter, and one thing that I do now is plan out specifically what I am going to use that for a year (or more) in advance. This means that I have to know where I want to be and what I want to know a year in advance and means that I don’t bounce between learning technologies that might not actually help towards my long-term goals. This also allows me to plan any out-of-work reading that I want to do to support these quarterly sessions. Also don't get caught in a tutorial trap, where all you do is learn the basics of something shiny and new - put those skills into practise and make something yourself.

So enjoy the next year - it isn't going to be easy, but you are going to learn more than in any year since you left school and have an incredible time along the way - make the most of it!

The importance of being bored

Kyam — Wed, 10 Apr 2019 19:02:16 +0000

For a long time I thought that an important part of working in tech meant that everything I did now had to be about tech. Subscribe to programming subreddits, listen to coding podcasts, be (doing nothing, probably) on my laptop all evening - basically fill my brain to the brim with nothing but technology and screen time.

Then one day I listened to an amazing (and yet, apparently impossible to find) podcast in which the guest proposes that in our modern world we never let ourselves get bored - we take any opportunity to cram a constant stream of content in through our eyes and our ears.

By occupying our minds every second of the day, we never give our brains time to rest. In boredom, our minds are able to wander and process and make plans - this is when we are able to do our most creative and original problem solving, and many of us never let this process happen regularly. They suggest that by not getting bored enough, we could be making ourselves ill.

“Not me”, I thought listening to this. Until I looked at how every day panned out.

6am - Wake up, listen to a podcast whilst in the shower. Watch television until leaving for work
7am-8am - Listen to a podcast, browse Reddit during commute
8am-4pm - Screen time at work
4pm-5pm - Listen to a podcast, browse Reddit during commute
5pm-7pm - Time with kids, music or radio on in the background (with a little screaming)
7pm-9pm - Television, browse social media
9pm-10pm - Browse reddit before bed

Not for a single moment was I allowing myself to be bored. Not for a second was I taking time to be away from some form of media or noise. And I could feel it - in my head, towards the end of the work day I would feel a little overwhelmed and I didn’t know why. Not long into the afternoon I was finding it difficult to concentrate, and (as I was brand new to my role) I was being trained up by my colleagues and it just wasn’t sticking. Also, my mind would drift off in meetings and I would snap back, having no idea what had been discussed for the last few minutes. It was actively affecting my mind and wellbeing, and I was attributing it to not being smart or capable enough to do my job. It was pushing me into imposter syndrome.

I decided to do something about it. I’m very lucky that part of my commute includes a 15 minute walk along a leafy footpath, bordered by trees and only occasional traffic. I began by militantly not allowing myself to use my headphones in between leaving the bus and getting to the office. It gave me at least half an hour a day where I could get bored, and be forced to think about what I wanted to achieve that day or further in the future, or who I needed to get back in contact with, or any number of things that previously would have been ignored for a podcast. It gave me some time in the day to relax in the sounds of nature.

Not long after I found that I was remembering a lot more of those things that my colleagues were teaching me. My productivity didn’t wane in the afternoon any longer, and I noticed that I was able to focus much more during meetings (well, depending on the meeting). I also found that when I got to work I already had an idea of what I wanted to achieve that day. I wasn't overwhelmed at the end of the day. Overall, my mind felt much clearer.

All it took was to take some time to let myself be bored.

So maybe have a look at when your mind gets time to wander each day. If, like me, it’s nowhere near enough, consider putting down your phone, taking out your earbuds and spending some time in the analogue world. It’s a small change that, for me, made a massive impact.

(Check out the awesome Bored and Brilliant podcast by Note to Self , in which a group of participants try to reduce their exposure to their mobile phones. I do see the irony of a blog post asking you to put down your phone then recommending a podcast...)

MVP AF

Kyam — Sat, 03 Mar 2018 21:43:58 +0000

So week 3 of Mayden Academy is over, and this week was our first full beginning-to-end site build. We were asked to design & create a portfolio website to showcase our skills to prospective employers, the coolest thing being that this was our first real implementation of Scrum from sprint planning to sprint retrospective, and all of the actual work in between. Also using Git within the context of an actual project made it seem a lot less scary (even if some of us had issues which had to be solved with...dark arts).

Hard stuff
I found the design aspect really challenging. Not only did I find it difficult to just to put pen-to-paper and decide on a wireframe, about halfway through the sprint I realised that I needed something very different to my design and spent about 15 minutes figuring out if I could start again (which, of course, I couldn't). So I had to carry on unhappy with it.

Good stuff
As much as I struggled with the design, I learned a lot from it (and let's be honest, that's why I'm at the academy). I tried to cram content into every part of the page, rather than exploit space & images, and also figured that it wouldn't be an absolute pain-in-the-arse to use portfolio images of varying sizes and aspects (of course it was). Also, I know that next time I'll try and make my initial page responsive to as many different screen sizes as possible before using a ton of media queries.

Other 'Good stuff' was that the team really embraced Scrum: nobody worked in their own world, we shared ideas & problems and the burden of code review was truly shared across the whole team. It was a refreshing way of working, and felt collaborative rather than competitive.

So overall some good stuff, some hard stuff, but we're still learning and growing and I can't wait to see what the next 13 weeks hold for us. And as much as I wasn't happy with my design, I still ended up satisfying all of the requirements. MVP, innit.

In scary news, at the end of this week we will already be a QUARTER of the way through...

The first two weeks at Mayden Academy

Kyam — Mon, 26 Feb 2018 21:13:39 +0000

I've previously alluded to the fact that I caused myself a lot more grey hairs in the weeks leading up to my time with the Mayden Academy than I really needed to; in fact the first 2 weeks have been (reasonably) relaxed. Sure, there's been a lot of content to cram in but Charlie and Mike (the two chaps who are running it) have let us learn at our own pace, leaving us plenty of time to ask questions & put into practice what we've been soaking up.

We covered the basics of HTML & CSS in week 1, including mimicking two web-pages (one being responsive) to apply those skills. Week 2 was all about Developer Essentials -think git, IDE's and more. What was really exciting was that this included Scrum Master training, an Agile framework that many workplaces in the industry work to. It was refreshing to see a new way of working and, while my last position gave us a fair amount of autonomy, I can't wait to work in a team using Scrum. We are now all Certified Scrum Masters - meaning that we can take this new skill into a workplace and help lead them to implement Scrum. Also we played with Lego, and you can't compete with that.

The upcoming week has us looking at building our first full website from beginning to end - a portfolio site designed to show off all of our progress and future builds. I am 100% concerned that I won't be able to design anything beyond a basic frame, but the guys have been pretty clear that we aren't expected to be designers (this is, after all, a course teaching us how to code, not design). I still can't help but feel a little useless when looking at others portfolio's.

I am a little worried about the upcoming weeks. I was hoping to be able to fit in some extra work most evenings just to recap the days content (luckily so far I haven't really needed to, but I expect that to change) but I have family commitments and a long commute: I have barely managed a minute of extra-curricular work. I've got my fingers crossed that I can find some solution. Also, american-isms like "gray", "math" and "color" keep slipping into use outside of the academy...that can't be healthy.

At least by the end of this week I will have something of my own that I have built from nothing - which, even if it is entirely rubbish, will be pretty cool and something that I could not have achieved before a fortnight ago.

A beginning

Kyam — Fri, 23 Feb 2018 20:47:37 +0000

I’d spent a large amount of the last 10 years regretting the fact that I’d wasted my opportunity of a university education in the most stereotypical fashion - I’d joined a band and abandoned my studies, spending two years of tuition getting nowhere except dingy pubs in England. Since, I’d resigned myself to careers in the unskilled sector - working in the service industry, managing in retail - jobs I enjoyed but was never fully happy in.

Recently I had been managing a team in a national supermarket, a position that enabled me to find my strengths and play to them. It was during this time that I realised that I enjoyed using IT and tech to make life easier. Although this was contained largely to spreadsheets, I was able to help streamline and automate local processes that otherwise would have been left as manual.

Although I obviously enjoyed it, I ruled out a career in tech because of my lack of a degree, and that was that - right?

I had worked behind a bar previously and one of my former colleagues had recently got a job as a developer. But he had no degree! How did he do it? It occurred to me - if he can do it, why can’t I? Seeing as we were both at one point bar-monkeys, surely I could follow in his footsteps?

As it turns out, I could. He attended a course run by local tech firm Mayden- they set about training up local coding-wannabees to help solve a local workforce supply issue. Also, as it turns out, I am just the sort of person that would pass their requirements tests and be accepted onto their Full-Stack web developer course.

I spent the last few weeks of supermarket work incredibly anxious of what it would be like: it had to be super intense and focussed at a screen 8 hours a day. There was no chance I was going to be able to keep up, and I was about to make a big mistake - putting my family in financial trouble and wasting the last 2 years of getting to a decent position at work. As such, I spent a good deal of my at-home time learning as much about the languages we were going to use as my head could fit.

I turned up 2 Monday’s ago and it was….relaxed. The pace has been realistic and, although I have found it incredibly helpful doing all that extra work in advance, I probably could have (just-about) survived without.

Now, 2 weeks in, I can start to see where my career as a developer might be. It may, of course, be nowhere - only by working hard and paying attention over the next 14 weeks will I be able to influence that, but at least I find myself on the right path.

What’s been good: Building with HTML & CSS, playing with Lego
What’s been painful: Nothing. Yet….
Looking forward to: Having OOP explained to me.