Flutter Full-stack dev > Flutter only developer

To be better at front-end, build on the backend

There’s an under-utilized way for front-end developers to improve their programming skills and overall effectiveness.

They can do this by simply learning to build and deploy backend software.

I’m not saying become exclusively full stack, you’ll get less done that way, but …

Fullstack developers have a broader knowledge base and can practice programming in different forms.

The reasons for a frontend dev to learn backend development are simple:

• It’s a purer form of writing software

• It highlights the importance of code separation

• It will teach you principles you can apply to frontend

In my experience the best developers not only understand the backend, but can technically talk and plan with backend developers, making them a more complete developer.

The good thing is, I actually think backend development is easier than front-end development, so it’s a good skill to learn.

Let’s dive into why:

The backend is almost as pure as it gets

I get asked often by newer/less engineer-oriented developers what they can do to get to the next level.

I’ve spoken to several developers who have been front-end developers for 4+ years and still feel like they’re just hacking stuff together.

My first recommendation is usually, to stop writing software using frameworks and go “primal”. Now I’m imagining a developer in a cave somewhere, haha.

I recommend to these developers to build CLI (Command Line Interface) applications.

The backend isn’t far off from a normal CLI application. In fact, a lot of “to-the-bone” backend frameworks like .netcore produce an executable that you run on a server through CLI.

With backend and CLI dev you have limited inputs, and precise outputs. It’s the perfect sandbox where you can practice engineering.

Putting separation of concerns in the spotlight

I have a rule that I stick to when I’m building Flutter applications.

Only the code in the UI file should look like Flutter, everything else should look like pure dart code.

At my first programming job, I had a senior who used to advocate for us to write our business logic and state against a CLI interface.

That way it’s completely separated from the framework and allows us to focus on constructing the solution only with the language and engineering principles in mind.

It was a great way to force us to:

• Separate state from UI

• Separate logic from business logic

• Separate application logic from business logic

The backend is a place where these rules are “naturally” enforced. Meaning, it would probably feel dirty if you saw the database being accessed directly where you’re deserializing the incoming response.

I’ve seen many tutorials where the DB is accessed directly from the UI file, there’s no enforced separation in the front-end realm.

The spaghetti monsters are real.

A fountain of engineering principles

Carrying on from the previous point, there are certain things you can do in the backend to fully express your engineering prowess.

The reason is due to its purity. There’s one language and one system.

With front-end you have to think about the UI thread, the other threads, the native operating system, the framework you’re using, the language you’re in, etc. There are separations you can’t introduce because the context won’t be available where you want to place the code.

But on the backend, man, on the backend you’re free, to do whatever you want.

Want to build your endpoint in modules? Go ahead, you’re working with primitive data everywhere so passing it to modules is natural.

Want to separate your serialization from the response handling? Go ahead, it’s all gonna be the same language, running on the same system.

Because of that you’ll come across many different patterns, and principles, and see how they can be applied in different ways.

Simply being exposed to the thinking, and the pureness of the backend allows you to get back to your front-end codebase and immediately see where you can use better patterns, better designed solutions and hopefully make some parts of your front-end code as pure as all of the backend.

So what can you take away from this?

Deploy something to the backend, make it meaningful, build a scraper for your favorite website, track your workouts, anything.

If you’re only on the front end I promise you’ll feel increased confidence in your skill and also learn a few new things.

If there’s anything specific you’d like me to cover with Firebase let me know, I’m currently deep in Firebase with the new tool I’m building and I’m quite excited to share how I do things over there.

Until next week,

Dane