DEV Community: Morgan Faget

Should I share my love for regex ?

Morgan Faget — Tue, 02 Aug 2022 11:59:09 +0000

Today, and probably for the 10th time since January, somebody asked for help with a regex. And I was, as usual, happy to help.

I LOVE regex, they feel like building a solution for a puzzle. It can be making sure that a pattern is followed, replacing large amount of data in a document or even extracting data.

I've been thinking about writing a series of post about how they work and how to build them.
I would love to hear from you what you would like to see in these posts.

Is a front-end and back-end team split a mistake

Morgan Faget — Tue, 14 Jun 2022 09:11:17 +0000

Currently there is a tendancy in our industry to specialise in front-end or back-end development and stick to it, it often comes down to interest or education. On top of this companies now tend to create two disctinct teams to take care of their applications and websites.

This split was effective or put into place in the last companies I've worked at and I wanted to give my two cents on this trend. The split is not obvious and should not be done lightly.

Why would we want to ?

This trend follows the logic that has been the default go-to architecture for websites and applications in the latest years. We build a stand-alone front-end that communicates with an API. No only does this give the possibility to release those two components independantly but it also gives the opportunity to develop other applications on top of the API without having to put in the effort of building a new back-end system to communicate with.

And since we have two different code base, two different deploy pipeline and two different applications it looks like the two team split makes sense.

The benefits

As mentionned, the fact that, in the end, the front and back end side of the application become two independant part of the same product means that there is no need to have the same team tackle these two development.

One of the major benefit is the fact that you can hire experts in their fields, language or framework. It brings efficiency in their team as well as the insurance that the project can move forward avoiding some of the hurdles those project usually encounter.

Communication also benefits from this. The team focuses on the same codebase, talk the same language and have a wider knowledge of the codebase since they're always working on the same one.
A smaller team also means that voices are heard more easily and the ideas flow faster. It helps with productivity and reactivity on new features or bugfixes.

A smaller and often underappreciated benefit is the added quality to documentation. Since the front-end team and the back-end team need to easily communicate, usually a standard way to communicate how things work is put into place.
But we can easily see how this could be a problem in certain situations.

The drawbacks

The communication within the teams benefit from this split, but what about the communication between the two teams. And what about the communication between each team and other actor of the company.

When building a project from scratch, or even developing new features, the communication between both teams and the product team must be crystal clear. And if it is not, it can lead to conflicts in what each team has understood about what needs to be developed.
If the teams are in a configuration where they both have a manager and those manager don't communicate a lot and prefer going through their common superior, the slowness of the loop might create a divergence in the objectives of the teams and lead to changes or even large rewrite of the applications.

In my experience this has lead to one of my biggest fear when this split is done, the front-end and back-end team are tired on waiting on each other and develop the parts of the application that both of them judge as the most critical and when the time comes to put things together, a huge refactor is necessary to be able to present the tiniest thing.

So... Should we do it?

I am not pretending to have the perfect answer to this but I think that this decision should not be taken lightly.

From experience, I've been able to see it work extremely well and very poorly.

It worked when the split was done at a point in the company where they wanted to grow and build something new on the front-end without having to pull resources from the back-end.
It worked because the API was already designed, functional and documented. The front-end team was able to design their new application without having to wait on the API to be functional, and when it came to adding feature, the team knew how the API was designed and could ask for endpoints that were aligned with how the API worked.

On the other hand it has gone very poorly on a full rewrite of an application. Both teams started working on their architecture for a while, this time was used by the product team to define the scope of the new application.
The issue came when both teams did not finish their research at the same time. Some hurdles were encountered by one of the team and since the management wanted to keep a hard delimitation between the front-end and the back-end, resources were not moved around to help. And since the situation did not resolve, the product team was moved to other tasks and the time to answer grew longer.
This stalling resulted in the project collapsing onto itself when this rewrite was necessary to help the company grow into new segments. Instead the failure pushed to drop the project and keep developping on the old stack.

TL;DR: When doing a split, consult with the team members, make sure you have a strong plan and don't be too strict with it. The benefit of being able to hire more efficiently can be outweighted by the difficulty of communicate.

The importance of business knowledge for developers

Morgan Faget — Fri, 14 Jun 2019 14:46:26 +0000

Have you ever been in a situation where you produced some code without understanding the whole context of what you were doing? And later realised the implementation that you created was not inline with the direction the business was steering? Well here is a thought on why it is really important to know the WHAT and the WHY to master the HOW

Business Knowledge

We don't need to know everything

BUT it is important that we understand what the company we work for does. Not only the work we will deliver will be better in quality but it is also likely to improve maintainability and flexibility when the business will ask for new features.

And it's not as hard as it could seem at first sight. Of course our job is first to understand the code base and architecture to be efficient in making any change, but it is essential that we understand the business basics, and a bit more when needed.

Knowing what the company does or sell is the first intro that we will have to the company usually even during a job interview. Once we are sure of what the company creates or sell we will have a good idea of its product(s), that's the WHAT. This knowledge will enable us to find out competitors and potentially find out what our business is trying to do better or differently than them, that's the WHY.

This knowledge will give us basic understanding of the business mission, its goal. Now do we, as developer, want to know everything about the strategy of the company or the financial details of all operations? Not really...

Get useful knowledge

It is true we don't need extensive knowledge of all the business details. But here is the trick, sometimes it is important to know more than what is given in a ticket or a project description. Often developers are perceived as machines to build code and whatever is thrown our way will be done, sometimes good, sometimes buggy, but often done without discussion. Now if you have the chance to have a great lead and a product manager who know how to do his/her job, we sometimes feel like all the specifications have already been discussed and that there is nothing else to be done. But this is not always true.

This is when it is important to understand our business well. Understand all the implications of the project. If it is a product we never worked on before, let's understand who it is for, how it is used, what impact it will have on our business. The thought process or the questions generated by figuring this out will sometimes (if not often) lead to an implementation plan different than the one you would have had.

What does this mean for your code

Coding with a goal in mind

Having the large picture in mind will have two nice effects. On one side it will make you avoid dirty hacks when a new feature comes along that would have been easily implemented if the architecture was more flexible. On the other hand it will enable you to see edge cases or isolated cases that should not require extensive over-engineering and loose of focus on some other important matters.

Understanding hacks and edge cases

And that's why we should always consider wether or not it is worth it to refactor a piece of code that needs a new feature or if a hack will do because this piece of code is being deprecated by the business or because another project has this refactor in its scope.

Sometimes the dirty hack is OK, it needs to be documented well, explaining the what and why of it, but it's OK because we understand that its lifespan is not worth the effort.

Avoid infinite feedback loops

Finally, the main benefit of understanding the business well is to win a lot of time in feedback loops.

Instead of developing the feature and then wait for the business to validate, ask for change and you implementing these changes over and over, you want to take steps to prevent this.

First, starting by asking all the necessary questions will help you and your stakeholder realise what you may have missed during the definition of the project, and you'll be sure that you understand each other and have the same vision.

Then, when you're developing the feature and testing it, you'll know what it should do and how it should feel like rather than having to wait for business feedback to realise.

TL;DR

Ask a lot of question, make sure you understand not only what you work on but also who you work for and why you do it. It will save you a lot of time and improve the quality of the work you deliver!

What were your best and worst onboarding experience?

Morgan Faget — Fri, 14 Jun 2019 10:23:49 +0000

I am currently building a new onboarding experience for our new hires, and I thought I would love to know more about other people experiences.

What were your best or worst experiences with onboarding?

Any experience is welcome, it does not have to be a technical story :)

My first experience with React, NodeJS and Azure

Morgan Faget — Tue, 04 Jul 2017 14:28:13 +0000

This is my first ever publication describing my first ever experience with commercial NodeJS, React and Azure. It has been a very fun journey understanding how all those pieces work together.

A bit of context

I started this project because I wanted to find a better and more comfortable way for my colleagues and myself to work.
Right now we are working with only a master branch that holds the latest version of the code on our whole code base.
This is a problem in two ways. First, we can't work independently on each project in our code base because they are all in the same git repo. Secondly, having only a master branch that we build from and publish to our environment means that if there is a live issue, we can't come back in time to tags and make hot fixes unless no one has merged any work in since the last release (spoiler alert, this never happens when you have a team working on the repo). I have been thinking about those problems for a long time and after some research and failed experiments I finally got my chance.

The company decided that it was time for us to have an API which means a complete rewrite of our client website. I was ecstatic! It was finally the time to split our code base in multiple projects and have a completely independent client that could be developed, built and deployed on its own side.
I took a look around and tried building applications with AngularJs, Vue.js and React. I know there are more solutions out there but the idea was to find a solution that would suit my main criteria: my colleagues comfort.

I had no experience with those framework before which was a good point to judge of the ease to learn and readability of each of these with very little experience. The story of my choice should probably be another blog post but I ended up choosing React and more precisely create-react-app to manage my project. The ease of building the client website and the ease of having a development environment with auto reload was a big plus.

Why Azure, and how good is it?

Currently our whole stack is using .Net MVC, so my first choice was to try to deploy my NodeJs client using Azure. I used this very detailed tutorial to do so. I was charmed right away by the fact that you could trigger the deploy script by pushing to a branch and also the fact it was a very scalable solution.

I decided that I would try to make a full proof of concept website using React and create a deployment flow with a development, a staging and a production environment.

Make everything work together

This was the point I hit the part where I am the less experienced. And where I struggled the most. Because on one side I had a React project using create-react-app and on the other I had the test project using Microsoft tutorial and I wanted to make my Azure WebApp serve my client.

I decided to recreate a React app in my Microsoft project. I now had a client directory where I could run npm run start but most importantly I could run npm run build and get a static website in the build folder.
From there I could easily setup my express instance to only serve the index.html from the build directory.

A rapid test on my local machine confirmed that after building I was serving the right thing.

And now the fun part - Update the build script

At this point I was amazed by how everything went fine all the way through the development of this POC. So the last part was to make sure that when pushing to my Azure branch the website would build before being deployed.
And this is when the things got a little bit more complicated. All the solution that I found were not was I was looking for.

This one was talking about copying the build directory using FTP. An easy solution but not at all good for a team of more than... 1 person.
I found one that was talking about using Gulp to create the build and run it by modifying the deployment script.

And this was almost all I could find (with countless re-blog), the other solutions I would find would be outdated or would not use create-react-app. So I decided to create a custom solution using the Gulp solution as a wire frame for my own.

What I had to do was to change the deploy script triggered after each push to the Azure branch. Those scripts can be downloaded at this address: [your-webapp-name].scm.azurewebsites.net in Tools -> Download Deployment Script. Those scripts need to be added to your root directory and will be executed instead of the default ones.

You want at this point to be aware that when we call npm run build in a create-react-app application it calls an npm package called react-scripts that is used to build the application.

It took a while to find the right way to do it. Obviously using create-react-app command line was impossible as you can't install global command line on a WebApp. I then tried to get react-scripts in my root project in order to use the react-scripts.cmd build command from my root project but you can't pass a context to this command which means that my first functional version was doing this:

Run npm install in the root project, that would install react-scripts
Move to the client directory
Run call ..\node_modules\.bin\react-scripts.cmd build

This worked for my first very simple react app because I had everything needed to build the application in my root package.json. But as soon as I introduced new packages in my client application I realised that my build would fail.
So I tuned my script a bit to install all the packages for the client and not include react-scripts in my root packages.json because it is not needed by the express app and should not be installed. And here is the current deployment script.

On top of that I ended up creating two more WebApp instances to prove this also works if we have different staging environment.

Conclusion

I am very happy with the way this proof of concept ended up looking. It was an interesting experience to discover all those new technologies and way to deploy applications.
Azure WebApp are (at least for this usage) a very good and efficient way to deploy applications.
On top of that I manage to reach all my objectives: Have a totally independent client code base, an easy way to manage staging environment using git branching strategies, while keeping everything easy to use and work with for my colleagues.

TL;DR: You can make your React app served by Express running on Microsoft Azure Wep App using this deployment script.

I hope this was interesting. As this is my first blog post, please feel free to make comments on the form of this post as well so I can improve it!